[Bf-funboard] Re: (Guillermo) Toolbox speed

[GSR - FR]

t_w_@freenet.de (2003-11-04 at 0905.07 +0100):
> GSR / FR wrote:
> > It seems to be the method used when talking about something being
> > fast. Get some people or even yourself, and ask them to select things
> > from menus, with some randomness, measuring time required and
> > errors. Fit's Law is about this too, as the recommendation about
> > avoiding deep subnesting of levels in menus, or the one about grouping
> > of things with separators.
> I realy don't know, if I will go that far, but with my Flash Simulation 
> for comparing two or more variations I would do it this way:
> - Present a random menu item which is to be selected. But to have a 
> realy good foundation for evaluation, one would have to make sure the 
> menu items will be weighted by importance / frequency of use. So one 
> would better have statistical data first.

If you measure multiple places in the menus you get also which places
are better than others. Once that is known, you can put the real
content in the menu (the statisticall data would be about what
functions are more important only).

> - Measuring the time starting with the spacebar (or LMB/RMB hold in 
> adaption to the 2.3 preview Toolbox).
> - Log selection time (time keeps running after wrong selections)
> - present the same menu item and switch to the other variation and repeat.

That is a viable way, yes.
 
> Wouldn't make sense to use my own results, so people would need to send 
> in their times by email. I somehow doubt that enough people would do that.

That is the problem with any statistic, the size of the sample.

> I wonder if there is a easier way to compare different Toolbox designs.
> 
> How about selecting a small number of menu items and calculating 
> selection times for these for every design?

I do not understand what you exactly mean. Use a crash test dummy or
some formula? Or limit test with real people to just some menu items?
 
> But in the end I guess it's going to be presenting different designs to 
> the community and use what is liked best as the default. If differences 
> in efficiency are large enough, this should leave us with the best, 
> oherwise it might leave us with the one that only feels fastest.

That would be nice, if liked was not about trend or "it looks elite",
no matter if painful or unhealthy. Our world is full of that... if
this is going the same way, please tell me ASAP.

> > ...
> > I talked about this in some other mail already, covering a list of
> > issues, did you missed it?
> You mean your "Review of UI" post? No, and I think you're right with all 
> the problems you mentioned. With my design the mousecursor has to be 
> relocated by the app if the menu wouldn't otherwise fit on the screen. 
> But I think that is less of a problem than submenus altering direction 
> all the time.

That is one solution, Blender used it in the past. Other solution is
auto scroll, like NeXT and others do (gtk2 does for option menus, I
think).

GSR