← Back to team overview

unity-design team mailing list archive

HUD: questions about using parent menu items as default actions.

 

Hi.

I'm writing an application for Quickly to enable HUD navigation. The prototype proved to be an extremely comfortable way of using Quickly, so I'm going ahead with the project. However, it also presented a few questions that I need to get answered by someone more deeply involved in HUD. In order for you to follow, I'll quickly provide a heads-up on the design :)

I export a menu structure such as this;

- Quickly
- - Create
- - - Ubuntu Application
- - - Other template
- - Add
- - - Dialog
- - - Something else
- - Edit
- - - Project 1
- - - Project Kewl
- - Design
- - - Project 1
- - - Project Kewl
- - Commit
- - - Project 1
- - - Project Kewl


Ok. So when I create a new project, I add it to the commands that the template supports, and extra for bzr and other things you'll always want. So this means that I'm able to things like "edit kewl" and it'll fire up GEdit for that project, or "commit kewl" to do a bzr qcommit. This is very nice. However, it turns out that the item for the parent menus are also presented. So when I enter "quickly edit", I'll get

Quickly > Edit > Project 1
Quickly > Edit > Project Kewl
Quickly > Edit

Now, in the application itself, I track the most recently used project and use the parent item for that action. This allows me to enter "edit" or "comm" and not provide any part of the project name, which makes it even faster to use. So I change the parent items label so that it looks like this:

Quickly > Edit > Project 1
Quickly > Edit > Project Kewl
Quickly > Edit (Active: Project Kewl) <--- parent item

The reason I do this is because HUD is supposed to remember the most frequently used actions, and in this case, that will always be the action for the current project. If I understand correctly, the more frequently you use an action, the faster it should be to look up. This is very important to me, because currently, the HUD searches are not fast enough to really be comfortable.

But this also means when I create a new project and then enter "edit", it'll point to the old projects first, since those will have been used more frequently than the newly created one, which I've only used once (to make it the active project). This is obviously not what I want. In other words; you should really only use the project name when switching to a different project, and use the short/generic command when working on a single project.


So, the three main questions are;
1) Should I be doing this, or are parent items supposed to be hidden in the HUD and this is a bug that will go away at some point? I hope that's not the case, because I'm designing this purely for the HUD. I'm not even displaying menus at all. Using the parent item as default is very comfortable when using the HUD. I also think it makes very good sense, at least as long as you ignore the past.

2) If it's not a bug, and it's ok for me to rely on this; can I ask that the parent item gets a higher default priority than the submenu items? Because currently, it gets the lowest priority, which means you'll have to actively choose it until it gets a high enough priority to become default. In my use-case, that means that the default is not the default by default, which makes the feature less user friendly, and certainly less "intuitive".

A potential problem with this is that most other applications won't use the parent item for anything at all, since that hasn't fitted well with traditional menu styles. This means that by default, the default selection won't have any associated action. The question is whether users would think that the "Edit" menu itself would do anything, or if they would simply consider it a header for the listings below. In any case, this would change as the user uses the application, since he or she will select other items, which gives them higher priority than the parent item.

Perhaps we could get a property to set when designing specifically for the HUD, allowing us to make use of parent items? It wouldn't affect other applications at all, but would present new opportunities to applications that wants to take advantage. I don't think a normal menu-based application would ever use the parent item to initiate any action? If that assumption is correct, then I think it would make sense to hide the parent item unless you specifically ask for it to be visible, in which case it should also have a higher priority than its children.

3) In classical menus, it is assumed that if the parent item is deactivated, then all children are as well, since it would be impossible to reach them. This makes sense for classical menus, but does it make sense for the HUD, and if it doesn't; what could be done to allow the HUD to make use of them differently without breaking current apps? Again, I think adding some properties for HUD-specific features will make sense.


If the parent item should be displayed, then it should be possible to use it for something. If you hide it or set it insensitive in client code, then you also remove all children from the HUD. Using it to point at the last used child action, possibly regardless of depth, seems like a useful feature. This is a way to use menu structures that isn't common for visible menus, but I imagine this will be quite useful for many applications that has deep structures and wants to optimize for the HUD. So I hope I can get some feedback on this.

Thanks.

--
Jo-Erlend Schinstad



Follow ups