...
| 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. |
| ||||||||
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:
|
Offline
OpenLMIS is developed to support "the last mile," which means that internet connectivity can be extremely inconsistent. The following features seek to improve the performance of client applications that are operating offline.
...
Add build date to UI
By adding a build date to the UI, we are helping people understand how recent the version of the OpenLMIS-UI they are using is. This will also help service desk staff debug of escalate bugs.
...
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
...
Service workers for file caching
Service workers are a relatively new API that is built into Chrome, Firefox, and Edge. A service worker can do many things, but it makes caching and updating the cached files in a browser extremely easy. Updating the website is done in a background process of the browser.
NOTE: Caching and updating files can be accomplished with an appcache.manifest file, which the OpenLMIS-UI currently uses. The primary reason to change the OpenLMIS-UI's approach to saving documents is that many browsers are warning that support for appcache.manifest will be dropped (eventually).
...
Download of facility and program data
Generally the OpenLMIS-UI downloads and stores data only when it needs it, which could leave users in situations where they need to connect to the internet to take an action that needs information associated with a facility or program.
Allowing users to decide if they want to store the products and stock levels associated with a program and or facility will create a faster user experience when doing data entry. If the user has requested to store this data, the OpenLMIS-UI can periodically update the stored information while the user is using the application.
...
Background HTTP Requests
A common approach to offline applications is to communicate information to the server using background HTTP requests. This is ideal for environments where internet latency is high, and users don't want to wait for requests to complete before moving on to a secondary task.
To meaningfully enable background HTTP requests, the OpenLMIS-UI will need a page (or section of the UI) to show the state of background HTTP requests and a workflow that will allow the user to retry the request they were working on. It's reasonable that this page in the OpenLMIS-UI could also show users "in-app" notifications.
Technically, allowing the UI to complete a HTTP request in the background is not much different than how other HTTP requests are implemented. The challenging part of implementing these features will be choosing when a HTTP request should be completed in the background, rather than locking the user experience.
...
Document Sync Conflict Resolution
Documents, like requisitions or physical inventories, can have different states
Reusable Business Logic
Reuseable code is maintainable and well documented code. Supporting a reusable code base is a good practice.
...