The OpenLMIS Reference-UI project will be an AngularJS v1 web application that interacts with the OpenLMIS web services. This application will consist of one primary application that contains a majority of the application framework and interface assets. There are also secondary modules that can be loaded into the primary application at build time, these modules can change interface elements or add additional functionality to OpenLMIS-UI.
To allow for modularity and customization, the Reference-UI build process will allow for custom modules to overwrite assets. This will allow for deep customization of UI elements and workflows without forking the reference-UI codebase or other UI modules that are developed.
General application requirements include
Configurable Build Process
The build process is adaptable to include files from multiple directories
URI Driven Application State
The application behaves like a website would, where pages are loaded depending on the state of the URI allowing for deep linking (and a browser’s back button to work)
Offline Application Workflow
OpenLMIS operates in low-bandwidth settings, and the OpenLMIS web application once open, should continue to function while offline preserving changes until an internet connection is detected.
This application should support complete internationalization and localization. To do this for the entire system requires OpenLMIS Services to provide translation strings, but also for the OpenLMIS to provide translatable string in case the OpenLMIS services are unavailable.
The application should be fully documented, and allow for reusable UI components to be progressively improved or replaced.
To keep the OpenLMIS user experience consistent, developers need a single resource and reference to glance at while creating features and pages. This document MUST document current OpenLMIS UX standards and how to use reusable UI components made available as part of the OpenLMIS UI.
Ideally this documentation will be updated as implementers customize and extend the UI features in their implementations.
Responsive interface design
The web application should be usable on a mobile phone or a large desktop screen. Applications may expose more functionality for larger devices, but small devices should meet basic application requirements. For 3.0.0, we deprioritized smartphone size layouts, with Product Committee involved in that discussion.
Query issues in this epic