This document is under development, and might not completely fit into the functional specification category.
*NOTE:* All features are in priority order, but the categories or work are not prioritized.
Consistency
User interfaces are often judged on consistency, as a lack of consistency can indicate un-maintainable code and become problematic for users. Maintaining consistency requires coordination between business requirements and the development team. "Broken window theory" encourages prioritizing fixing inconsistency, as it will discourage additional inconsistent work.
Feature | Tickets |
---|---|
Buttons Button text and colors through the OpenLMIS-UI are inconsistent. Most buttons on the openlmis-ui should be a simple gray, but we have many instances where there are too many "primary" (blue) buttons. | |
Icons Icons can create visual inconsistencies very easily, and should be avoided in the OpenLMIS-UI as much as possible. When icons are need, they must be added in an extendable way so the icon can be universally changed though the entire UI by an implementer quickly, or removed entirely. | |
Better integrate and socialize OpenLMIS-UI Styleguide into design and development processes A reason that inconsistencies come up is because the OpenLMIS styleguide is hidden away and needs simplification to be useful for business analysis, not frontend developers. The first step in this process is getting design and workflow agreement in our prototyping tools, and then moving that language into the OpenLMIS-UI Styleguide. |
Performance
Current performance issues are badly understood and are not consistently detected by manual testing. The best way to improve performance is by adding automated tests to understand which areas need improvement, and then use those same tests to ensure that the work done to improve those areas is actually improving performance.
Feature | Tickets |
---|---|
Automated Memory Tracking By tracking memory usage for a browser while using the OpenLMIS-UI application, we can:
NOTE: This work could be done in manual testing, but automation makes long term tracking and "human variabilities" out of the problem. | |
Automated Crash Reports Currently the OpenLMIS-UI hardly uses google analytics. Getting data from the client to detect error situations in production will help detect and determine the cause of bad performance on a system level. | |
Minimizing File Downloads Many of the large libraries that are used within the OpenLMIS-UI can either be avoided or built "modularly" such that only the features we use are included. By making the OpenLMIS filesize smaller, we will increase download and start-up time of the OpenLMIS-UI. | |
Webpack code-splitting and lazy load The OpenLMIS-UI code base will bloat as more features and logic are added, and it doesn't make sense for a user to wait for files to download that they might never use. Lazy-loading is a term that refers to loading the application logic that a user needs only when they actually need it. Lazy-loading will make the OpenLMIS-UI load faster. The best way to implement this is with webpack. Other libraries are able to manage code-splitting, but they often create more configuration work which becomes unmaintainable as the application continues to grow. |
Usability
Creating easy and intuitive experiences for people who use software is difficult, but extremely important to building a platform that will actually be used. The following features either look to make specific changes or help understand what would make logistics management "easy and intuitive".
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.
Feature | Tickets |
---|---|
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. | |
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.
Feature | Tickets |
---|---|
UI Architecture v7 Add better structures to UI logic, and start using them in new application code. This will add support for ES6 and webpack. | |
Update UI Coding Conventions The OpenLMIS-UI has a long coding conventions document, that needs to be updated for the v7 architecture, but also needs to be shortened as its too long to be useful. | |
Update existing UI logic to use UI Architecture v7 As there is time available, existing OpenLMIS-UI modules built before the v7 architecture was designed need to be incrementally updated. This work can proceed slowly, as removing AngularJS support is not a priority. | |
Move openlmis-ui modules to NPM Its all Javascript, it should live in NPM. Publishing in a public repository will allow other developers to reuse our application code in ways we can't expect. | |
Remove AngularJS specific mark-up from HTML files UI Architecture v7 doesn't include updating or changing logic within HTML files, as there is less value in making our HTML reusable than creating a framework for reusable business logic. HTML is useful for simple configuration of design, and is generally treated as an item that doesn't need specific unit tests. Unfortunately, the OpenLMIS-UI incorperates some complex UI logic within the HTML; which is enabled by AngularJS. Removing AngularJS mark-up from forms, and using standardized HTML5 syntax will make sections of our code easier to maintain. Additionally, if the HTML is standard, we will be able to use linters to enforce code quality in development which further increases maintainability. | |
Remove AngularJS Completely AngularJS is going to stop being supported by Google at an unknown point in the future, and while AngularJS still adds lots of value to the OpenLMIS-UI, there will be a time when the library will need to be removed and a replacement for the core features that the OpenLMIS-UI uses will need to be replaced. |
Extention and Branding
The OpenLMIS-UI needs to support implementers being able to change the presentation and business logic that is provided by the OpenLMIS-UI. A simple example of this would be changing brand colors and logos, while more complex extensions could be changing the scrolling direction of a single page or adding additional validation to a form.
Feature | Ticket |
---|---|
OpenLMIS Branding as a module During the Malawi implementation of OpenLMIS, there was confusion about how to brand OpenLMIS to meet Malawi's requirements. This was caused primarily by the simplicity of changing fonts, colors, and icons within the OpenLMIS-UI application - all you need to do is set a variable or add a little CSS. To make sure these changes were still available, there were discussion of adding unit tests - but these approaches were more complicated and brittle than the actual implementation or customization. A more maintainable way of supporting and documenting these customizations is to seperate OpenLMIS's own branding into a forkable library. This will force the core openlmis team to dogfood their own branding system, and force a seperation of content and presentation for developers contributing to OpenLMIS. | |
Extension Documentation The OpenLMIS-UI is very extendable, but meaningful documentation and code samples don't exist. Creating code samples and documentation will help prove to implementers and funders that the OpenLMIS-UI is extendable. The v7 Architecture is designed to allow more grainular extension than what was available with AngularJS. The documentation for these methods needs to be clear and well documented. Ideally additional work in OpenLMIS-UI will use existing extension stragedgies. |
Features Under Discussion
The following are features that could be built into the OpenLMIS-UI, but don't support a specific area and need to be broken down before work is started.
Feature | Questions |
---|---|
Progressive Web Application Two of the major web browsers (Chrome and Edge) and many web developers have started to build progressive web applications as an alternative to building native mobile or desktop applications. The reason for this switch | |
Native Mobile Application Using application frameworks like Cordova or React Native, its possible to build applications that act like native applications, but use the same logic and design as the OpenLMIS-UI. This saves lots of development and maintenance cost. | |
Native Desktop Application ElectronJS enables web applications to act like a native application. | |
Peer-to-peer document sync The OpenLMIS-UI could either have a small companion application or independently network with other OpenLMIS-UI instances on the same local network, so that multiple users can work on the same documents in real time without an internet connection. There are issues with version control that could become problematic. |