Admin UI tools for OpenMRS 2.x


A while ago i sent out an email giving an update about the Admin UI module, we intend to incorporate the module into version 2.3 of the reference application and have it as the basis for adding more admin features in the future, we would love to agree on the nature of the UI so that we get it right from the start and typically we want most of similar manage/edit/add pages to have the same look and work flow. Below I have attached a screenshot of an example of the current look of one the management pages, we are welcoming ideas about how we can improve it.

We would appreciate it if you can provide mockups of how you wish the pages to look like on this thread. Alternatively, you can also attach one to the associated ticket RA-61, if you need a tool for creating mockups, JIRA does come with one, at the top of any ticket you can click on More ▼Add/Edit UI Mockup to create and add a mockup.

Looking forward to your input. Thanks!



Pinging everybody to get volunteers, or are you all satisfied with the one in the screenshot?

1 Like

For the location page specifically, this is insufficient because locations are actually in a hierarchy, so we need to display them as a tree, not a table. Here’s a snippet from the Ebola demo server (where hospital beds are locations) showing the 1.x Manage Location screen breaking down:

[image: Inline image 1]

Most metadata management screens should look generally like this though. With a few caveats:

  • Should follow the standard style, e.g. use a pencil icon for edit, instead of that button.
  • I would expect to be able to retire/unretire via an action from this page too.
  • personally I think the decoration provided by datatables is distracting and not useful:
    • are typical types of metadata so numerous that we need paging?
    • is having a search box as the most prominent feature helpful? (Any sysadmin surely knows how to do Control-F, right?)

I’m more interested in the page that leads to this one, actually. The 1.x admin screen is too cluttered; in 2.x we have set the precedent of having separate sections for System Administration vs Configure Metadata vs Data Management. That’s good.

But the next-level page for each of those shouldn’t just be a list of big icons. They should be grouped (e.g. in a fieldset) and similar things should flow vertically, and be medium or small icons.

All the look and feel concerns Darius talks about would be easier to implement if we had a powerful grid widget (be it a tag or a js function) that given a data source (list of beans, SQL query, HQL query) and a design model will render a grid like this one. Toolbar actions (typical crud + retire etc.) would be also rendered by the widget. The goal is that all grids look exactly the same, and changes (adding sorting, export to excel …) will be immediately available on all grids.

1 Like

Yes. For some examples, at AMPATH we currently have 104 encounter types, 10492 fields, 339 forms, 160 locations, and 300 privileges. Hopefully, we’ll be using the same basic approach for all metadata, so once paging is done, it will work for all types and will just be “invisible” when there are only a handful of any particular metadata.

We can’t assume that all metadata will always be on the screen, so we need more than Ctrl+F. A tool like datatables should give this for free. I agree it could be less prominent (e.g., right-aligned like in datatables examples). Personally, I think placeholders are better than labels for fields like search boxes – e.g., <input placeholder=“Search” type=“search” />. It looks like it’s recommended by our style guide too. :grinning:

@darius – could you try again to demonstrate the Ebola location hierarchy widget or point us to a demo of it? The image didn’t come through in your post.

1 Like

I agree with most what Darius suggested, definitely locations would need to be changed

1 Like

I attached screenshots for the user account page, it is definitely not looking that awesome, and this is why we are having this discussion, to get ideas to make it better

1 Like

If you look at this thread on my screenshot is there.

Just to be clear, I was saying that the Manage Location page from the 1.x UI does not work in the Ebola context, and I attached a snippet of a screenshot of what we do not want (e.g. “Bed #9” sorted alphabetically, but actually there’s one in each Ward).

We did not build a nice hierarchical UI for managing locations in the Ebola module because the configuration was set up in code, not by hand.