Patternfly User Dropdown
I’m back with more about Patternfly’s navigation bar user dropdown.
More from developer
I’ve done a brief, remote, contextual interview with the developer who originally asked for this to be researched. With this, I confirmed a few things about what his concerns are:
- Accessing items within a dropdown takes more time and more clicks than without one
- Dropdowns can be extra slow to interact with when on a slow network connection, especially when animations are involved
- It’s easier to remember where to go to get to menu items that are top-level rather than under a dropdown
- Frequent use items need to be easily accessed and easily discovered
Discussion with patternfly UX researcher
I’ve started a conversation with the UX researcher at Patternfly, Sara Chizari. In large part, I wanted additional perspectives on the problem. I was also hoping to learn if there is existing research on this topic that I’d missed.
My inclination is that the major goal of this research is two-fold:
- In the specific case of the developer I’m working with, what are the best guidelines for the use — or lack of use — of navigation bar dropdowns.
- In general, we need guidelines for the use of dropdowns.
I expect that these will also change with the display screen size: limited space constrains what can be at the top level.
How do we figure this out?
I’m not yet certain of the best way to go about figuring this out, which is part of what I’m discussing with Sara.
In this particular case, the dropdown is not expected to contain high-use items. While useful, I wouldn’t expect things like ‘settings’ and ‘log out’ to come up during the course of everyday use of an application or webpage. It’s difficult to be sure what other categories of items people are likely to wait to use here, but the real-world examples I have are suggestive:
It looks like basically everyone includes settings and sign (or log) out. Many also include help. Of these, I would expect that sign out would be highest use, especially for those folks who access the applications on computers that are not their own.
Because these won’t be high use items, I’m not yet sure how best to create tasks for people to do during a usability session. I don’t think I want to overemphasize actions that they might not otherwise do, as it’ll make it somewhat difficult to identify the highest use items. At the same time, I need to have people try different prototypes of the menu and menu area to see how they turn out in practice.
What do I think so far?
My instinct suggests that we will specifically want to test the usability of a few different things:
- Dropdown of 3 or fewer items vs not being in a dropdown.
- Logout, settings, and/or help being inside or outside of a dropdown.
- Mobile vs tablet vs computer monitor
These feel like they will address the ‘dropdown vs not dropdown’ item number cuttoff point on various screen sizes, and the specific menu items that I believe to be the most frequent use.
I may want to identify the most used items in those dropdowns, before I go into more specific testing as per the above list. I’m not yet certain of the best way to approach this, however.
Sara will be doing some literature research this coming week, and will then be busy until mid-Sept on her own projects. I’m hoping to figure out the kinds of things to be testing with the aim of starting usability sessions in September.
UX Newbies and career changers group?
In the meantime, due to conversations with the local UXPA group on Facebook, I’ve started investigating both problems and potential solutions facing UX newbies and career changers within the Boston area. The major goal here will be to figure out what types of things are interfering with getting new people into UX jobs, coming up with concrete things to do about them, and figuring out how to make those things available to people locally. I’d love additional perspectives and ideas, since I am only one of many folks trying to get into UX, and will definitely not have thought of all the obstacles (or possible solutions!).