Projects:ImproveUIVisibility/FunctionalSpecifications
Improve UI Visibility - Functional Specifications
Overview
Purpose
This project aim to improve the feedback that Openbravo UI provides to the user.
This project has two different parts:
- Application focus visibility
- Window status and the transitions
Design Considerations
Application focus visibility
- The new 2.40 release allows to use Openbravo from the keyboard without using the mouse. There is a shortkey that allows the user to swich from the application window (edition/relation) to the application menu by typing CTRL+M. It should be easy for the user to recognize the active element so it should be highlighted. It applies to the whole UI but not all the elements are able to become active (there are elements that are not "focusable"). For example each button in the tool bar has a shortkey to be called but those buttons do not receive the focus.
- The element that are able to receive the focus are:
- Login window: Username, password and the login button.
- Application menu: All the items within the menu. The rest of elements within the application menu (User preferences, Log-out, expand/collapse, ...) do not receive the focus.
- Application window in both edition and relation mode: all the elements (Tab headers, all types of inputs: input text, text area, drop down lists, check boxes, option buttons, ..., links, buttons, auxiliar buttons such us calculator and calendar, data grid, ...). Not "focusable" elements within the application window are buttons and links in tool bar including Help, About, Linked items, ...,
- forms to call reports and processes in both embedded and popup ways: the same as Application window
- The datagrid will receive the focus as a unique element. Once the focus is in the datagrid then the active row within the datagrid will be highlighed as it is now (green background).
- The way to highlight the active element should have a common pattern among all of them to make it easier for the user to understand the concept (for example, use the same colour).
- The way to highlight the active element should be different from the onHoover style (the active element can be different from the element below the mouse pointer).
- The way to highlight the active element should be implemented by just modifying the underlying css style of the element and should not require changes in the current html design
Functional requirements
Window status and the transitions
Num
| Requirement
| Importance
| Status
|
1.1
| The time response in some window/frames is more than one second so the user sees a blank page while he is waiting for response. It would be better to show a "loading" icon (perhaps with some dynamic effect) to better explain to the what is going on. This icon should be light enough to avoid performance issues.
| Should have
| Not started
|
1.2
| When invoking processes in Openbravo there should be a UI mechanism to explain to the user that the system is "Processing" the request. For example, when the user clicks the button that launches the process a "Processing" icon (perhaps with some dynamic effect) is popped up.
| Should have
| Not started
|
1.3
| The application window (in both edition and relation modes) has different status that should be communicated to the user.
| Should have
| Not started
|
1.3.1
| Edition mode: Record edition (user has not done changes), Record editing (user has done changes), New record creation (user has not done changes), New record editing (user has done changes). Does it make sense to have different status for a new record with and without user changes?.
| Should have
| Not started
|
1.3.2
| Relation mode: Datagrid loading, Datagrid loaded.
| Should have
| Not started
|
1.4
| The solution proposed to communicate to the user the status of a window is to include an icon (perhaps with some dynamic effect) within the toolbar (in the blank space between buttons and linked items) related to the current status.
| Should have
| Not started
|