UI Suites
Context
Microservices are being adopted. Each microservice potentially delivers its own user interface. The existance of multiple user interfaces should not be hidden from the user. Users don't have to switch between the user interfaces frequently.
Problem
- The user interfaces are not integrated to provide the user a cohesive user experience.
Solution
Integrate the user interfaces by using hyperlinks for interaction among then. The separate user interfaces will be perceived as separate products that coherse in a suite of products.
Popular examples for this approach are Office Applications like Google G-Suite and Microsoft Office 365. They offer separate applications for text documents, for spreadsheets, one for presentations, one for organizing all kinds of documents in a folder structure, and so on.
Technically, this approach can be implemented by using simple hyperlinks between the user interfaces. Communicating context information can be facilitated by using URL parameters. If some data gets out of data because it was updated in another user interface, the user has to refresh the page. If this consequence is not acceptable, consider using server-sent events or web sockets to synchronize between the user interfaces.
This approach works well for applications where
- users don't have to change back and forth between user interfaces very frequently, and
- the existance of multiple user interfaces has not be hidden from the user.
Otherwise, consider the use of microfrontends.
Maturity
More data required (only 2 sources).
Sources of Evidence
L34:
- Microservice approach (Fig 4b): UI is maintained by separate team
- Independent depeloyment, but changes may influence UI and other teams
- => argument for SCS (considered as next variant of microservice)
- Figure 4b: 2 UIs - Event+Billing UI forwards to SSO UI User managenemt
Interview E:
- Questions need for integrated UI solution
- Instead multiple small solutions that interact over hyperlinks with each other
- Product-Suites like Office 365, Google G-Suite => consist of separate products
- Each product for its own domain, each product with an expert team
- Google maps: experts for maps and route planning
- Google docs with different experts
- probably different technologies used
- only works if user don't change back and forth
- user stays longer time in product
- use of hyperlinks is unobstrusive, easy to build
- no meta framework, use what the web has to give anyway if hide from user that there are multiple applications / need for an integrated solution => rather go for a shell-based solution
- Good for non-customer facing applications: business applications
- conversions are not important
- supporting processes in companies
- SPAs, client-side integration makes sense
- Context: communication of user context in UI suites
- over backend: server-sent events / web sockets
- or using URL parameters
- usually sufficient, just refresh if something feels out of date