Payment BB will like to speak with other BBs to align on certain flows in the specs, and expectations from other BBs that the Leads might not be aware of. Have time in the next meeting for presentation.
ID BB - starting the next wave for ID management, will be addressing the user ID onboarding, reuse of existing form of ID e.g., migration or document reuse.
Lawrence and Betty are the only members of the WG that are active.
There are three phases and currently working on phase 1
Phase 1 - draft and test specifications based on existing guidance for implementing accessible responsive building blocks and providing consistent services.
Phase 2 - prototype use case journeys
Phase 3 - develop tools for implementation
Looking for organisations that have developed patterns that work, will be collecting the patterns, and also looking for standards that already exist in collecting those.
Not building tools for GS BBs but the patterns that will be developed will be useful for frontend. Not building frontend APIs, more of a working group than a building block at the moment, and not building a design system.
A consideration might be to involve users with disabilities and users from diverse background in usability testing and gathering feedback.
Focusing on the registration user journey for pattern and guidance.
The frontend content has not been defined.
The group is more of a UX working group at the moment.
Next steps
Tech workshop to develop points technology choices and interoperability
Get feedback from the community and specific BB e.g., Consent BB.
Test guidance with in country partners
Wes - what is UI/UX for? Is the intention for these guidelines will be applied to the software that is being used for BBs or for something else?
Lawrence - It is for the in country teams and other governments who are using these building blocks as part of their service. This is more aimed at small team with developers (frontend) who have not considered design or design thinking as part of their way of working.
Wes - We need to be crystal clear that there is a separation between what the UI BB is intended to support and then the actual building blocks themselves. The user experience between mobile device and the desktop should be different, and that should be taken into account.
Steve - UI/UX BB could connect with the sandbox team who are doing a lot of UX design for some of the demos to ensure the concepts are compatible.
Taylor - If someone wants to build a digital service using the "GovStack approach", they'll do so using:
an information mediator providing secure data transport,
some registry-bb-candidate,
some scheduler-bb-candidate,
some payments-bb-candidate
and probably some low-code-form-builder application to handle SOME SMALL PART OF THE DIGITAL SERVICE that requires a real-time user flow.
for that last one, when they use this low-code-form-builder application, they will try to adhere to design standards listed out in the "UI/UX spec". is that right?
On how to collaborate - if my "is that right" is right then I think there probably isn't a HUGE amount of collab needed right now. except maybe with folks who run applications with form-builders like UNCTAD eReg, Pega, BudiBase, etc
Ain - The UI should be inclusive wether it's web, paper, or offline. If we are developing the next version of the specifications, are there some quasi technical components that are related to the user experience and the complexity of those workflows; what is the right way to address that?
Wes - This BB (UI/UX) may require a different type of spec than the rest. We should likely set up some time (collectively or as a smaller group) to determine what outputs are required from this BB. (I'll note that this may be increasingly true for the more guidance-based and application-focus BBs)
Steve - it will probably sit alongside the non-functional requirements and security requirements and can have its own format.
PhD on Role-oriented Software Infrastructures (RoSI) offered to join for evaluating best modelling language to ease deriving Implementation Model from GovStack Reference (e.g. Business Role-Object Specification (BROS)
