Mehrdad MajzoobiUbo Simple GUI Software Architecture
In this document, I propose and discuss basic design principles behind Ubo GUI architecture and the driving forces behind certain decisions. This is a work in progress and this document is solely offering insights and proposals on the design. I would love to hear your thoughts and any suggestions on how to best design the UX.
The main objective behind Ubo GUI design is to offer a simplified graphical interface to the application developers so that they can easily understand and use it within minutes.
In order to accomplish that, we need to offer a very simple API and data abstraction layer as well as a set of examples that can serve as starting points for developer applications.
Simplicity must be followed in every aspect of the design (window manager, API/Interface, templates, etc). By physical design (LCD size, keypad design, etc), this GUI is only intended for simple interactions, and is not indeed to replace a desktop or mobile-like experience.
The picture below shows a high-level architecture of the proposed GUI design:
Figure 1. Proposed GUI High-level software architecture
From developers perspective, they only need to understand the JSON data structure to describe their GUI layout and function. The rest is handled by the GUI processor and the developers do not need to necessarily learn what is happening inside the GUI processor service. However, if the developer wishes to define a new GUI experience that is not offered by the SDK out-of-the-box, then they will need to dig deeper and understand the design logic and architecture of the GUI software.
As depicted in Figure 1, the proposed GUI software architecture consists of a server and clients. The server is constantly listening on a socket and whenever a client (user application) wants to interact with it, it will send a JSON object to the server. The server can also respond if certain actions are performed on the registered callback. The details of server/client implementation (what type of server/client to be used) have to be determined.
This can be implemented via POSIX socket, simple REST API, MQTT, etc.
The advantage of this server/client design is that multiple applications can send data to the display (for example, error messages, notifications, etc)
The system application will own and manage the flow of the GUI and will offer an entry point for foreground user applications. However, when applications run in the background, they would still be able to send notifications, show error messages, etc. Below is an example of entry into the application menu through the system menu.
Figure 2. Nested Navigation. System navigation can connect to app navigation
The GUI will offer the following pages and modes of interaction:
1.1 Home
The home screen is the default screen of Ubo. It is usually the landing screen after boot-up. The home screen includes a notification bar on top (or bottom) as well as some shortcuts to show some information digests or access certain items such as the opening system menu (similar to taskbar experience).
1.2 Navigation
This is the main mode of interaction with the GUI. By pressing the buttons on the keypad, the user can navigate through a linked list of items with leafnode corresponding to informational items or an action. For example, an item can initiate an action, be on/off toggle switch, or just display some info such as software version. Each application can define their own navigation instance (which would include actions and information unique to that application). App navigation can be accessed through system menu/navigation as shown in Figure 2.
1.3 Notifications and prompts
User applications must be able to show notifications and prompts to the end-user when necessary. Here's an example of prompt:
The window manager needs to understand the urgency and priority of these messages and current state of the GUI and make a decision to show the message immediately or queue it for a more suitable time to show.
In addition, the user application can claim space on the notification bar on the home screen as a shortcut.
1.4 Dedicated screens
For example, you can enter a custom landing screen that uses up/down arrows to adjust certain settings or have a completely custom interaction. For example, the volume control screen shown below can be accessed through system navigation under settings. The screen utilizes the up/down buttons to adjust the volume. These screens must have a return point (example: back to exit).
Below are some other examples of dedicated screens:
2. GUI API
The GUI logic must encapsulate keypad functions and manage the GUI states internally. It should have a routing and window management functions built-in to decide what screen to show next and on what screen to return back to.
The GUI API receives a JSON object as input and returns a response with registered callback functions to apps for initiated actions inside the GUI. Certain screens have defined built-in behavior; For example, notifications all have a dismiss action built-in that is attached to the BACK button. If the user does not press any buttons, they will time out and get dismissed automatically. A custom shortcut can be designed to allow accessing “Pending Notifications”and clearing them.
2.1 Window manager
Window Manager's job is to properly process requests coming in from applications by using stacking and queues. For example, a queue can be used for notifications coming from apps that will be displayed to the user in the order they arrive.
2.1.1 Priority concept
Notifications or messages (such as prompt) that may overwrite the screen can also have a priority attribute that puts them in front of those with lower priority. For example, critical error messages can have a higher priority. Window manager should also keep track of what GUI is currently displaying. For example certain screens have an indicator that no other screen can show another screen over them (non-overridable). For example, if the user is browning the system settings, applications must not be able to show a prompt while the user is in the settings section.
3. Kivy Layout Design
In this section, I wanted to propose some design guidelines for pages/screens in the GUI.
3.1 Navigation
The design below suggests a layout for navigation pages. The screen is laid out in different sections: The top is the header that typically holds the page title. The page title does not change during scrolls through paginated lists. The sidebar holds the scrollbar. The footer can show the back arrow or footer text. The middle section can hold three list items and is designated as a screen. The middle section will transition up/down to scroll through using the buttons on the right hand side.
Below is an example of scroll operation through a list of 6 items. During scroll, only the middle section that holds the list items transition up/down and the title and scrollbar stay in place:
The GIF image below a simplified implementation of scroll animation:
3.2 Widgets
We can also define a set of widgets that advanced app developers can use to quickly design their customs pages. Below are some examples of suggested widgets:
I would love to see what type of GUIs developers would like to see being designed. The figma board below includes the current design drafts:
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.