unity-design team mailing list archive

[Jo-Erlend Schinstad <joerlend.schinstad@xxxxxxxxx>]

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