...
| Feature | Ticket | ||||||||
|---|---|---|---|---|---|---|---|---|---|
Error finding component Many forms in OpenLMIS are multiple pages, and users have trouble finding an error if the input element isn't on a visible part of the page. To make fixing errors easier for users, we can add a control to guide users to the next visible error. |
| ||||||||
Responsive Layout Currently the OpenLMIS-UI is built for two browser screen sizes, but the layout becomes problematic (and ugly) when the screen size gets much larger or smaller. Responsive layouts generally include mobile layouts, and most developers approach a responsive layout using a mobile first design. The design approach for our responsive layout will follow a "Desktop first" design process, as the design of OpenLMIS workflows focused around data entry that wouldn't translate well to a mobile device. |
| ||||||||
Sort order is documented For users, being able to understand how a large list is sorted makes navigating that list (ie not searching/filtering) possible. |
| ||||||||
In-App Documentation Creating and maintaining user documentation in a separate workflow than application development an expensive and error prone process. In-App Documentation is useful because:
|
| ||||||||
Usability Values Documentation Creating workflows that are 'easy,' 'simple,' or 'intuitive' is extremely difficult because there is no specific guidance for what a user would find 'useful'. The OpenLMIS community should develop consensus around values that promote usability. | |||||||||
User Research Without user research there isn't information that can be used to make value based decisions about how to structure workflows or form elements for users. The user research process is also not a feature that can be done once, iterative testing and re-testing is necessary. Ideally, this body of work includes capacity building within the OpenLMIS community to carry-out research and present actionable outcomes. User research would help answer the following questions:
|
...