We’ve recently been working on a design proposal to simplify the O3 navigation patterns and allow for the users Location to more actively and intuitively drive their user experience. This work is inspired by recent observations with potential O3 end-users and our work with the team at @PIH .
The problems
Navigation is overcomplicated by users having two ways of switching between different things in the application - the left nav and the app switcher. Despite attempts to define use cases for each pattern, confusion reigns!
A users location, selected during login, does not currently drive efficiency of use or a more personalised experience - two key usability violations.
What are we proposing?
We would like to depreciate the App switcher (there may be a case for utilising it to for users with multiple tools, such as OpenELIS to have a place to switch out from there)
User roles will dictate which Pages a user sees in their left nav
Pages with location based content will display contextually relevant information - for example, when a Users location is set to ‘Triage’ the Patient Queue page will show the Triage queue.
Moving the location picker into the left nav - the Law of Proximity state that elements on a page in close proximity are perceived to share functionality - e.g. the displayed location will define the content of some of the pages below.
Hi, about the app switcher , I feel it has utility especially when you look at mature implementation like KenyaEMR that have and will have multiple features once they completely move to O3.
The real estate on the left nav will be insufficient and will either have to be scrollable or have accordions to accommodate all feature though their display will be controlled by user access so only the admin may have to deal with a crowded list.
Right now I can switch between apps from the patient chart without having to first navigate to the homepage.
I propose to keep the app switcher since that paradigm already exists in commonly used apps.
I’d like to understand the user story around jumping to different ‘apps’ from a Patient Chart. It is not currently possible to do that. A user would need to close the Patient Chart before being able to click a link in the App Switcher.
Which type of provider do you think would need to be able to open the App Switcher from a Chart?
What would you imagine the main benefit of that user flow would be to that provider?
I have a concern that as designers, product owners and developers we may impose our understanding of how O3 is built and structured in the UX itself and that this may be at odds with what an end user may need / expect - this concern emanates from recent user testing.
As a provider with user permissions set to view Appointments, Patient Queues, Labs and Pharmacy (as an example), is there a use case for why I should see these sections in two menus v.s. one?
I like the new change with the location being more prominently displayed. What does this mean in terms of the existing elements to indicate / switch location, at least in the context of the queues app? Will those go away?
I like it overall. Fewer location choosers means less confusion. There are definitely user roles where they rarely need to switch location, and I think this UX makes sense.
@pauladams as you may know, we do use it for its intent in Ozone. We use the app menu to switch to other components of the HIS:
Two things:
I’m definitely happy to have this moved elsewhere if the app switcher were to go away.
For instance in the left menu, with the special icon that shows that you’ll get out of O3.
This is a long lasting temporary measure, since in reality EMR users are not really subject to navigate away and switch to other “apps” like the LIMS and whatnot – this list of apps to switch to is rather there as a convenience for the Ozone demo in waiting for Ozone HIS itself to have its own UI.
Hi @pauladams , jumping a bit late on this but I have a couple of questions:
Search page: Does this mean we don’t have a “quick search” page where you can search for patients without leaving the current page?
Location switcher: In our implementations, OpenMRS locations correspond to physical location - users don’t move much from one department to another. The location display + change button seems a bit too highlighted IMO.
Do we keep the User menu in the top bar? If so, it might look a bit odd on its own now.
Are we expecting the top bar to be almost empty now?
Even though it does not look much, this will probably be quite a change for users already using O3 beta out there. I would not have expected too much changes in the UX in a beta version. This change will require re-training of users.
The fact that most (if not all) of the header and the side navigation is extension-based would seem to give us a lot of flexibility here, and I don’t really see any reason why implementations that are comfortable with and/or expecting the header and navigation to remain as they are should necessarily have to change.
@mksrom , presumably if the same extensions slots and extensions exist and are able to be wired into as they are today to offer the same experience, that would be something we’d want to continue to support, and this alternative design is just a different set of extensions added to various slots in the header and left navigation menus?
The tech design post I link to above is basically trying to figure this out:
What are done as changes to existing components (eg. the home app or style guide components)?
What are done as new components and/or new frontend modules that can be used as alternatives?
What should be the out-of-the-box refapp and module configuration (eg. extension/slot defaults) - if any?
