Toolbox Flash Simulation, R2

The interface, modeling, 3d editing tools, import/export, feature requests, etc

Moderators: jesterKing, stiv

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Toolbox Flash Simulation, R2

Post by thorwil »

Hello!

Edit:
Flash simulation, release 2!
Please test it and report about your experience with it. But don't judge it before having spent a little time playing with it. It's a new kind of menu, therefore you will need a little training to get used to it.

If you realy don't like it I want to hear that too, but then please tell me exactly why!

My design could be adapted to the look of broken's menus, with spacing and all. And of course hotkeys listed in the menus.

http://wrstud.urz.uni-wuppertal.de/~ka0 ... ui/toolbox
Last edited by thorwil on Wed Nov 05, 2003 4:09 pm, edited 2 times in total.

Etna
Posts: 0
Joined: Sat Mar 29, 2003 1:18 pm

Post by Etna »

Looks great!! a bit inspired by houdini, isn't it? =)
i wanted a stuff like that, maybe more rounded.

see you

thornae
Posts: 44
Joined: Mon Nov 04, 2002 11:53 am

Submenus should be radial, too

Post by thornae »

The whole point of a radial menu is to increase speed of common operations by making them gestures that can be "spinal reflex" memorised. Mixing radial and vertical menus gets confusing, and defeats the point somewhat. There's lots of good info available via a google search, but basically, the easiest mousing directions (right handed) are, in order, diagonal up to right, diagonal down to left, diagonal up to left, diagonal down to right. Common operations should use alternating directions, so your most common operation, two levels down, should be accessed by moving up right, down left, up right.

The advantage of vertical menus is that you can fit much longer lists of options. Radial menus really shouldn't have more than eight options. There are workarounds to this, like having option eight be "More options", or the somewhat more elegant but harder to work "spiral menu" (as you move around the radial circle, more options 'spiral up').

Hope this is useful. If you wish, I can go and look up some of the better references and post them here. Radial menus can be a real speed booster if done correctly. It's good to see someone working on it.

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Re: Submenus should be radial, too

Post by thorwil »

thornae wrote:The whole point of a radial menu is to increase speed of common operations by making them gestures that can be "spinal reflex" memorised. Mixing radial and vertical menus gets confusing, and defeats the point somewhat.
Maybe it looks confusing as layed out on my page. I don't think it will be confusing in action, because you will imediately see what happens.

My design will increase speed of operation because you select first and second level with one movement (and no click up to that point).

It might not lead to "spinal reflex" memorization. But after some usage you will know in what direction you have to move and will have a feel for the distance to move you mousepointer quickly to the desired item.

The reason it isn't all radial is simply, that there's no way to organize all the items in nice sets (I tried it, long and hard!). The number of items under any title various too much. And using such things as "More Options" is just ugly and makes it hard to find what you're looking for.

And than there are so many commands, varying with mode and selection, that memorizing gestures will be hard anyway.
Hope this is useful. If you wish, I can go and look up some of the better references and post them here. Radial menus can be a real speed booster if done correctly. It's good to see someone working on it.
Thanks, but I think I've done my homework !-)

thornae
Posts: 44
Joined: Mon Nov 04, 2002 11:53 am

Re: Submenus should be radial, too

Post by thornae »

First of all, I've just been looking through the funboard archives, and seen that you've already discussed a lot of this there. My apologies for not checking earlier. Also, note that I think your actual categories and menu organisation is fine. It's just the layout I have issues with.
So, regarding that:
thorwil wrote:My design will increase speed of operation because you select first and second level with one movement (and no click up to that point).
This is not necessarily an advantage. Radial menus are good because it's easier to move a mouse back and forth several times than it is to move the same distance all in one direction.

thorwil wrote:The reason it isn't all radial is simply, that there's no way to organize all the items in nice sets (I tried it, long and hard!). The number of items under any title various too much. And using such things as "More Options" is just ugly and makes it hard to find what you're looking for.
Granted, it may not be easy, but as has often been noted, one of Blender's strengths is its UI consistency. If you're going to go with a particular UI choice, it should be consistent - the UI shouldn't need to change because something is inconvenient. If it does, you've got the wrong UI. Consider the Mozilla radial context plugin, which is an excellent example of a well implemented radial menu. Their advantage is that they've got a limited set of commands to implement.
thorwil wrote:Thanks, but I think I've done my homework !-)
Mmh. Nonetheless, I think I'll throw out some links for those who might want to catch up, and for reference.
First, http://www.piemenus.com/ is pretty much the central resource for this topic, and Don Hopkins is the pie menu guru. As such, you should read his seminal paper, The Design and Implementation of Pie Menus. You should follow that up with Natural Selection, about the evolution of pie menus. Of particular interest are the notes at the end.
For more scientific research, The Limits Of Expert Performance Using Hierarchic Marking Menus is an excellent study, and Anne Ratzer's thesis Use of Design Principles in Advanced User Interface Design, as well as being well worth reading overall, has a section on so-called "marking menus", which are basically radial menus where the mouse movement leaves a trail showing your movement. Note, however, that Alias|Wavefront have patented or copyrighted or something "Marking Menus", and will vigourously sue you for using them, so we'd best stick to radial menus. For the record, though, there's another useful paper by Bill Buxton and friends about Marking menus and how well they work. (Tidbit: Pie menus are not trackball friendly).
If you've got ACM access, you can also read a widely referenced paper, An empirical comparison of pie vs. linear menus.

Finally, there's Chris Houser's excellent page Pie Menus for all, where there's a pertinent summary of design guides for pie menus:
How to layout pie menus.
  • * Partition the commands into logical submenus. "The primary goal for menu designers is to create a sensible, comprehensible, memorable, and convenient semantic organization relevant to the user's tasks" (Shneiderman 92 p99). Deeper hierarchies with many submenus require longer marks, but this makes each submenu narrow, and hence each selection rapid. Experiments prove menu breadth and depth an even trade for total selection time (Kurtenbach 94). However you arrange your pie menus, they'll be fast, so arrange them logically, and they'll be easy to remember.
    * Give each menu an even number of commands. In particular, 4, 8, and 12 are fastest, perhaps because users remember them as analog compass and clock faces.
    * Put the most common commands on the axes (i.e., at 3, 6, 9, and 12 o'clock) since these positions are the easiest to select.
    * Find spatial mnemonics - commonalities between direction of menu items and the edited substance (e.g., text, files, graphics).
    * Place opposing commands at opposite sides (e.g., Open and Close, Cut and Paste).
    * Use the start and end points of strokes to indicate positions, selections, destinations, and extents - combining command invocation with selection and dragging.
Now then - on the funboard, you reject a "compass direction" layout because it's not as compact. This is my other big problem with your current proposal - all the research indicates that compass directions are easier to work. Remember, form follows function - trading ease of use for compact design is not wise. For example, in your current system if I went to MouseOver "Relation", it's very easy to go across the "Object" tab, which would bring up the submenu, covering the button I want to actually get.

So, there's some of my thoughts. As you've said, it's not an easy thing to do, so I'll fire up Sodipodi and see if I can implement some of what I've discussed. Watch this space.

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Re: Submenus should be radial, too

Post by thorwil »

thornae wrote: First of all, I've just been looking through the funboard archives, and seen that you've already discussed a lot of this there. My apologies for not checking earlier.
No, no, thank you for checking the archive!
thorwil wrote: My design will increase speed of operation because you select first and second level with one movement (and no click up to that point).
This is not necessarily an advantage. Radial menus are good because it's easier to move a mouse back and forth several times than it is to move the same distance all in one direction.
How about not thinking of it as a radial menu? I'm sure my design allows faster selection than a linear menu would. No need to cry after all the advantages of true radial menus, when it's not feasible to use one for the stated reasons.
The reason it isn't all radial is simply, that there's no way to organize all the items in nice sets (I tried it, long and hard!). The number of items under any title various too much. And using such things as "More Options" is just ugly and makes it hard to find what you're looking for.
Granted, it may not be easy, but as has often been noted, one of Blender's strengths is its UI consistency. If you're going to go with a particular UI choice, it should be consistent - the UI shouldn't need to change because something is inconvenient. If it does, you've got the wrong UI.

The Toolbox is going to be context sensitive. Whatever it will look and behave like. I don't think of this as a lack of consistency. If you refer to the architecture as beeing inconsistent, well traditional menubars work in a special way on the top level too!
Consider the Mozilla radial context plugin, which is an excellent example of a well implemented radial menu. Their advantage is that they've got a limited set of commands to implement.
Beatyful isn't it? But it' works in a completely different situation.
thorwil wrote: Thanks, but I think I've done my homework !-)
Mmh. Nonetheless, I think I'll throw out some links for those who might want to catch up, and for reference.
Ok, I take that back, at least partly! I went to piemenus.com and some other places I forgot about. But my interest faded after I realised that I can't organize Blender's commands into nice sets.

Now then - on the funboard, you reject a "compass direction" layout because it's not as compact. This is my other big problem with your current proposal - all the research indicates that compass directions are easier to work. Remember, form follows function - trading ease of use for compact design is not wise.
The question is then, how big is the loss because of the directions in relation to the advantages of the easier layout? I think the menu can be scanned faster with all pairs of items on the same height.
But I will reconsider the layout.
So, there's some of my thoughts. As you've said, it's not an easy thing to do, so I'll fire up Sodipodi and see if I can implement some of what I've discussed. Watch this space.
Great!

Thunderbolt16
Posts: 3
Joined: Wed Oct 16, 2002 10:58 pm

Post by Thunderbolt16 »

First of all, I'd like to say that you did a fantastic job prototyping the new toolbox layout. I've been one of the biggest Pie Menu zealots on the funboard list, and I approve whole heartedly of you use of a radial top level with linear submenus. With the number and nature of the various context items of the toolbox, I doubt there would be much speed increase with radial menus, since they loose quite a bit of there advantage when you have a ton of entries, or even worse, donut, or 'overflow' menus. Also display compactness would suffer greatly since there are so many sub-items in a radial form, not to mention that overflow menus are just plain ugly!

Altough the eight compass directions style of menu is much quicker for 'blinded' i.e. no visible queue for the user, the speed for visible menu items in a radial forum just more or less goes up linearly. shown here http://www.billbuxton.com/PieMenus4.gif.

Thank you so much for going through the trouble to create such a complete proposal!

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Post by thorwil »

Thunderbolt16 wrote:First of all, I'd like to say that you did a fantastic job prototyping the new toolbox layout.
Thanks!
Altough the eight compass directions style of menu is much quicker for 'blinded' i.e. no visible queue for the user, the speed for visible menu items in a radial forum just more or less goes up linearly. shown here http://www.billbuxton.com/PieMenus4.gif.
Could you please explain that in a little more detail?

matt_e
Posts: 410
Joined: Mon Oct 14, 2002 4:32 am
Location: Sydney, Australia
Contact:

Post by matt_e »

The problem with using radial menus for all levels of operation is that it's very difficult to extend. Particularly with things like modelling tools for example, new features are being added all the time. You can nicely lay out a radial menu with the current features, but then when you want to add a new menu item, it is very hard to fit in (especially when there are a lot of items already), plus it disrupts the angles/locations of the current items, which negates all the advantages of arranging the menus radially anyway (spatial/angular memory).

I think thorsten's latest mockup is a very good compromise that suits the requirements well. It doesn't have to be compared against "pie menus" or "linear menus" and make it fit a certain mould - we can take the positive parts from many systems and apply them to a design that is customised for our particular requirements. As long as it is the best (or at least a good) solution we can think of for the problem at hand, there's no need to worry about whether it's a 'true' pie menu or not.

I've got a couple of organisation comments I should get around to posting on the funboard. Argh.. so slow right now.

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Post by thorwil »

Edit, see first post.
Last edited by thorwil on Sun Oct 26, 2003 4:07 pm, edited 1 time in total.

Monkeyboi
Posts: 251
Joined: Tue Nov 26, 2002 1:24 pm
Location: Copenhagen, Denmark
Contact:

Post by Monkeyboi »

Wow, I'm sorry but that is seriousely bad!
Why it is bad:

It is very difficult to hit the right menu items. I tried for a minute to hit the Linking menu item without luck! I always ended inside the Image menu item. Edit, Transform, Relation and Linking are especially difficult to hit. It is obviousely VERY important that it is easy to hit the different menu items, otherwise the idea of the spacebar menu is gone.

I'm sorry, because I know you have used lots of time on the Flash thing.

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Post by thorwil »

Monkeyboi wrote: Edit, Transform, Relation and Linking are especially difficult to hit.
I think the problem is your targeting at the labels, but you should follow the guiding lines. A design failure, I will see if I can find a better layout.

My own problems with the menu went away after I started to navigate up or down and only slightly to the left or right for those 4 items. Please retry!

I know that the Toolbox shouldn't require any explanation, but if my current design doesn't work at all or works with some hints makes the difference between forgetting about it or to try to improve it.

Mats78
Posts: 100
Joined: Thu Oct 17, 2002 5:06 pm
Location: Vantaa, Finland

Post by Mats78 »

I had the same kinds of problems testing this. The bottom and top menus seem hard to hit - I've got the hang of it but it somehow doesn't feel quite natural. I don't like small exact mouse movements when in a hurry.

Also, an annoying point is that the sub-menus cover lots of the parent menu. I really can't see what's underneath and have to come back to the center before being able to find my way again! This is something that absolutely should be avoided.. it feels like navigating a web page. Maybe we shouldn't concentrate so much on the looks of it, still, that's not in any way important!

And once more, don't feel bad about this =) I too try to help you out by throwing in my feelings.

Regards,
Mats

Carnivore
Posts: 0
Joined: Thu Jan 30, 2003 6:27 pm

Post by Carnivore »

Didn't read through it all, but the first thing that I noticed was how hard it is to add a cube (my most common task in the toolbox). You have to move waaaay up to the mesh menu and then waaaay down again to the cube option. I think the menus need a bit of rearrangeing. Other than that, nice work. Of course it will take some getting used to, but it will all be for the better. Keep it up! ;)

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Post by thorwil »

Carnivore wrote:You have to move waaaay up to the mesh menu and then waaaay down again to the cube option.
The ordering is partly backwards, because I didn't pay enough attention to anything besides the general working of my Toolbox:-(

Will fix this on the next version. Also planned: improved layout and use of the top level items as labels in the submenus, so that the submenu items start on second positions.

Post Reply