-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Main navigation menu #1550
Comments
I think there are different top navigations depending on the user type (institution, health organization, manufacturer). Maybe we could do the same for some kind of users that will only work with specific sections. |
@jkicillof @diegoliberman WDYT about moving Sites, Devices, Logs, and Users under Settings? This is a very easy UI change. It doesn't require any configuration. And it immediately clears up the navigation from less frequently used items. We'd simply integrate those pages into the Settings landing page. I'd also change the Settings menu item to a cog icon. Doing this we should also consider associating Logs with Devices, because it seems to be specifically about Device logs. |
I totally agree. Go ahead in whatever gap or break you need from the current priorities. Let Johny know so that he adapts the designs. Regarding logs, perhaps for now we can start just by renaming it to Device logs. |
The screen you mentioned was an experiment I did before going with the samples menu. I agree with hiding those sections under settings. I'm not sure about the cog icon because those settings are not user settings and it might be confusing. |
Updating all the screens won't be cheap, I could update easily all the ones that I did in sketch (samples, batche, boxes, transfers, etc). |
IMO that might not really be necessary. This change doesn't really affect the main content of the screens, so I'd be fine with leaving the existing designs with the old nav. We'll need an update for the settings page, though. To include the added items. And the current implementation diverts quite a bit from the design (https://projects.invisionapp.com/d/main?origin=v7#/console/4103589/119909353/preview?scrollOffset=14351). My idea for the settings page would be to have context groups for related entries, maybe with group labels.
|
IMO it's a common pattern to have two buttons, one for user settings/actions (indicated by the user icon) and one for app settings (indicated by the cog). |
Great, I'll update the nav menu today EOD or tomorrow and I'll share the screen links |
Yes, but in this case the settings are not user setting but organization settings. My concern is that this could get confused. |
Since now we have a menu on the nav bar I think we should use the same on settings and remove the settings page. The menu will hold Sites, Devices, Logs, Users, Alert groups, Roles and Policies. I updated all the screens I have on Sketch, let me know if changing all the rest is also needed. |
Hm, I actually like the settings page. The action cards have contextual information and help texts about what the respective setting is about. IMO that's quite valuable and changing navigation to a plain dropdown menu would degrade the UX. A settings page is a good place to guide users on the available features in a better way than a list in a dropdown menu. (I suppose we could technically have both, a dropdown and an overview page.) |
Yes, I think both options could work. I'll have to work on the missing illustrations. I'll try to get them asap. |
I updated the settings screen. You should be able to donwload each icon. |
One of @jkicillof's latest designs (https://projects.invisionapp.com/d/main#/console/4103589/465275288/comments) shows a main navigation menu with very few elements.
This is actually independent from the discussions about the transfer workflow and scanner interaction, so it makes sense to discuss this separately.
I like it. I've been annoyed by the navigation menu being so big and hard to actually navigate.
After some time you're used to remember where the items are that you typically use.
But for new users it's overwhelming. And it's not great for experienced users either.
Joni's approach is to have a nested menu for samples and related things (batches, transfers).
It moves elements that are not relevant in the current context, out of sight. That makes them harder to reach, but you
typically don't need to reach them anyway from the sample page.
I had been thinking about another idea, though. The pages in the main navigation menu have very different usage characteristics.
For example, if you're working with samples, you'll spent most of the time on the samples page (and related).
In contrast, configuring a site or device is pretty rare. Many users may never have to go there after initial setup.
There is a clear difference in the frequency of these pages. Navigation should make frequently used things easily accessible,
and rarely used things can be further away.
I think the split goes right in the middle, where the first half are frequently used pages and the last half are rarely used.
Of course, this also depends on the kind of work you do. IIRC, UCSD has no patient interaction, so they probably don't use the patients page at all 1.
In any case, I believe the last half of pages (sites, devices, logs, users, settings) are probably not frequently used.
They don't need to be easily reachable there when they're only used sporadically.
They are actually all kinds of settings. So I'd suggest to move them away from the main navigation menu and summarize all of them on the Settings page.
The link to that page could also be separated from the main entries, and moved to the right, next to the account menu.
It could also become a cog icon instead of a text label.
Then in the top right corner you have two menu items, one for account configuration and the other for context configuration. That fits together very nicely.
As a result, we get a clean, small main navigation menu with all the important links easily accessible and less useful clutter tucked away, but still reachable.
Footnotes
A further improvement could be to add configuration for hiding pages when they're not used.
If an institution like UCSD doesn't use patients data, they could easily hide that button from the nav. They don't need to go there anyways. ↩
The text was updated successfully, but these errors were encountered: