Page Comparison

Agenda

Presenter

Duration

Discussion

Review pending action items

 Esther Ogunjimi

 10 minutes

• GovStack UI

• Cross building block integration

Jaume DUBOIS

15 minutes

Lawrence - its most likely most citizen users will be using mobile devices

its most likely most citizen users will be using mobile devices. There should be recommendations over wether an app is appropriate

Jaume - when someone wants to interact with GS, what are the options for consent?

Option could be a self-service on computer web browser, cell service on smartphone, a kiosk somewhere in front of an operator which is having a computer, an interactive with smartphone to give and sign consent. All these are options to consider and not narrow on just web form. We might implement all the forms of the UI, but we need to be ready for them.

Ramkumar - The challenge with implementation; will people tilt toward mobile as the most easy platform for people to use without too much of computer literacy. The UI/UX guidelines must be able to address

Marcus - If we start describing what the mobile BB would be, are we going to describe this as a BB that will not be Use Case specific?

Wes - We have operated up till now that this concern (UI/UX) is more of an implementation responsibility than something we would provide ourselves. The guidelines that the UI/UX team are working on get us started to help implementations in this effort and this seems like a good initial step.

While building a functioning app/site might be potentially helpful, it is a large amount of work that I would see as significant risk because:

• We don't know if implementations would actually want this

• It is a significant expansion of the scope of GovStack at a time when our resources are reducing (at least in the short term)

Jaume - There is no standard out there. It is part of GS mission to fill the standard gap when there is one.

Steve - There is value in outlining some standards and envision the UX flow of a citizen facing application. With the UX BB, we could build out some examples of how implementation should look, and how it ties to the various BBs.

Do we want to provide guidance on native mobile vs responsive web apps?

Vasil - Consider progressive web apps which are installable on any device. A bit of concerns for native app development, the platforms are currently not well aligned. The requirements changed from the initial one from version to version as every vendor of an application are supposed to align because the smart phones are getting older and do not support certain features or the applications cannot install.

Wes - is this something that we want to figure out how to do? And if so, at what time scale can we actually do that?

If we want to think about this and have a realistic plan of doing something in this space, we might want to partner with an actual implementation that would be willing to work with us so that their mobile app or system could be used for real world implementation - a portion of it could be used as example implementation.

Ramkumar - Platform agnostic was mentioned as part of UI/UX guideline but this has not been elaborated. Can we stop at the level of guidelines?

If we have to take this up, we could have few guidelines inside the UX guidelines that is being developed.

Vasil - The Sandbox team is developing scenario application which can be transformed into progressive web app with less effort. If we decide that this is essential and is in the stack of development for the next few months, it could be done then. Every application that we are developing case scenario for can to be immediately installable on any device as a progressive web app. This could be a design concept for every scenario that we develop in the future.

Wes - The priority on the technical side of things is to facilitate the easy inclusion of new Use Case - having the structure and process in place to support that. The priority is not create a progressive web app to be installed on a mobile device, it is nice to have and not a core requirement of being able to implement new UCs without requiring much development time to do it.

Agreed that PWAs are probably a good approach

Margus - there is point to that but would need to identify what it would be. from community perspective there is big EU community and guidelines for wallets, so its worth to discuss

Status Update

Leads

30 minutes

https://govstack-global.atlassian.net/jira/plans/reports/6EFAz

Testing

• Making progress with openIMIS implementation into test harness

• Waiting for ID BB to final review the test; this is required to finalise the test.

USCT Use Case

• Working on the last data verification steps

Online Construction Permit Use Case

Steve - working to streamline the template so the process will be quicker.

V1.0 Feedbacks

Jaume - A feedback cannot create a Jira issue into a BB. It has to be qualified first to determine if the information captured is precise and relevant, and if it is addressed the a specific BB. We should organise level 1 support for receiving feedback, ask for clarification if required and eventually create an issue

Steve - Will work with Rachel to define the process to vet incoming issues.

UI/UX BB

Working on the spec. It has two sections; guidance section and pattern library.

Will be collaborating with the Sandbox team on prioritising patterns for the construction permit journey UC.

Wes - Should the UI/UX BB be more of a guidelines that would get documented in the same way like a security guidelines and the non functional requirements are?

Lawrence - Yes, it is a guiltiness and not BB because UI/UX is not building a frontend API.

Steve - the UI/UX team should figure out the template for the cross cutting document to structure the content, and present it at the TC for feedback.

There will be some guidance from the Architecture team.

GIS BB

Working on the specs and in the process of completing the key digital functionality section.

Rewritten the UCs that was used initially to guide the development.

Will be working next on the GIS BB intersection with other BB and workflow, as well as API mapping.

eMarketplace BB

Image Added

Image Added

Most of the content is published in GitBook.

All UCs documentation and publication is completed in GitBook

Blockers

Need help in building class diagram for data structure section

Markdown syntax not getting read on GitBook when pasted.

Steve - Could possibly edit the markdown files directly in the GitHub repository

Taylor - if something has been added in GitBook then, go see what it did in the markdown and GitHub, and take that as syntax.

Sandbox team

Completed the first sprint on development and accomplished the sprint goal

Discuss / define process for decoupling BBs into smaller pieces

Steve Conrad

10 minutes

Also discussing how to approach existing DPGs which

fulfil multiple BB requirements.

The potential approaches are;

• To identify these smaller building blocks and break them down into separate specifications?

• To take some of those building blocks that have subcomponents and figure out a way to structure the template in a way that the different component functionalities are clearly sectioned and would be understood as consumable by other BBs?

• Do we want to continue to keep these larger concepts like payments and ID together?

Marcus - Some BB are actually big and go beyond the idea of being a BB. If these BB are decoupled, each specification that will put forward will draw bigger community to support and more people wanting to join the WG.

The bigger UCs would be delivered in consortium of smaller products if it goes into procurement in the beneficiary country.

Vasil - Is it realistic to be able to decouple these BBs? Currently tackling the same problem in the sandbox as the knowledge of a building block, e.g., the MiFos one is so huge that it cannot be acquired internally, and manage it properly.

The team is trying to move it on and give it to the people by creating separate environment for the people that developed the application to install and make sure that it is compatible with the sandbox and then to be able to automatically move it into sandbox. We cannot as an initiative to decouple work done by others and divide their application into pieces.

Alex - Decoupling is possible for IM BB. The API description could be in multiple files and has to be supported by the BB itself.

Ramkumar - There are existing DPGs which partially matches and fix adaptor for. The challenge is, if it disintegrates further into smaller pieces, there may be lesser DPG to match a particular BB.

Margus - The decoupling process should be initiated as certain BB are monolithic, big and UC specific. We are leaning toward vendor lock in by illustrating them as BBs.

API Optional Fields

Steve Conrad

5 minutes

Ensuring that any fields that are specific to a use case are tagged as optional in our API specifications.