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.
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.
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.
@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.
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
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.
