[wingide-users] Tiny feature request

Danny Bloemendaal danny.bloemendaal at informaat.nl
Fri Jun 23 07:48:05 EDT 2006


On 23-jun-2006, at 2:11, Martin Frankel wrote:

> Your original complaint was that you edited the wrong file of many  
> with
> the same name. The full file path is in the window title bar. You  
> don't
> have to touch your mouse or wait for any tool tip to know what file
> you're working on.
>

This is only the case if you already have such a file selected. Then  
you can see which it is. But not when you need to edit another that  
is part of a group of equally named files. So it only serves half or  
less of the use cases because the tab selection is usually the moment  
when the problem arises.


> Now you're talking about selecting which tab to click on to edit  
> one of
> many files with the same name. You claim that "anything is better than
> the current solution." So let's examine that assertion.
>
> 1) Any solution which increases the size of the tabs in the common  
> case
> in order to give a small benefit in the uncommon case is a terrible
> design tradeoff. This includes non-adaptive paths of any sort in the
> tab. I think we agree on this.

Re: uncommon case. I (and many others I know) work with Zope and  
Plone. The products/modules have a specific file and folder  
structure. There are many of these products and each product has more  
than one __init__.py or install.py and other files that can be found  
in any of them. Working on products usually involve that you work on  
some of them at the same time. Either copying functionality or  
whatever. In any case, it is very likely that you have files open  
with the same name. I disagree that this is a rare case.

Your argument doesn't stand. If it is a rare case and if the tab- 
label-expansion only takes place in this rare case, then hardly every  
will you notice this since, in your belief, it only happens in a rare  
case. (Please note: my suggestion to extend the label is just a start  
in trying to figure out a good way to solve the problem. Maybe other  
solutions are better (not unlikely!)).

> 2) The number provides a mnemonic that is better than nothing, and far
> more compact than a full path.

Compactness is not argument for gui design. We talk about  
performance, error proness and stuff like that when we design UIs  
(our company is specialized in UI design for more than 15 years). It  
turns out that larger click areas increase efficiency and eventhough  
users claim they work better with smaller toolbars, tests with these  
specific users show that they work a lot more efficient with larger  
buttons. Just as an example.

> It costs nothing in the common case where
> files have descriptive names.
> It costs very little in the uncommon case,
> just a few characters in the tab. Users often remember the sequence in
> which files were opened, so this has good mnemonic value for just a  
> few
> characters.

Again, the commoness is no argument since we talk about just the  
situation WHEN this happens. So this is the situation that we have to  
deal with. The number postfix doesn't mean a thing if you have  
several files open. I always find it hard to figure out which number  
represents what. It must be the order that you opened the files in  
but this order has no meaning. I can think of other meanings that  
are  much more convenient. Like you have an example/original on the  
left and the new one on the right. That is a meaningful disctinction  
and I can think of more. Just a number coz of its sequence makes no  
sense. Especially since users have to carefully open files in a  
specific order to make the number match in a more meaningful way (and  
also remember the numbers). Numbers as triggers is bad usability.

> I find this the correct tradeoff as do (for example) the
> authors and users of Emacs over the 20 year history of that editor.

An argument for a UI just because technical skilled users have built  
it like that is not valid either. The worst UI designers are  
programmers and software developers. They managed to create an editor  
(like emacs and vi) that has one of the steepest learning curvers of  
software apps that you can find around there. It is the worst example  
of easy to use programs. It may be very powerful once you get to know  
it but it will never win any UI price. So please let's not use that  
argument either.

> 3) For those who don't like remembering numbers, the tooltips work  
> fine
> as a reminder. Since you're using the mouse to click on the tab  
> anyway,
> you've already spent the time to move your hands from the keyboard to
> the mouse, and maneuver to the correct button. All you have to do is
> wait a half second. This method also has no cost in the common case.

That is also a terrible scenario. The intention with clickable  
targets is that you know up front what to click. These are almost  
laws in UI design. (for this reason the magnification in the OSX Dock  
is terrible because you do no not know in advance where your click  
target will be because it changes while you move towards the target  
(see Fitt's law). The need to hover over tabs just to find out what  
to click is even worse. Why use labels at all on the tabs? Let's get  
rid of them! just use numbers instead. According to you they are easy  
to remember and makes it possible to display 20 or 30 tabs in a  
window. And in the rare case where you didn't learn the number you  
can just hover of maybe 20 or 30 tabs to help you figure out which  
you need. Very efficient!

Well, you get my point. Your argument for commoness isn't valid.  
Maybe it is for you but for a lot of other users/usecases it isn't.

> 4) There are various possibilities for adaptive paths to resolve
> ambiguities. "Eclipse" and "ellipses" seem to be the two proposals on
> the table. It is easy to come up with corner cases that are misleading
> with either scheme. For example "bar/baz/baz/foo.py" and
> "bar/baz/foo.py" are misleading with both schemes. Neither scheme  
> scales
> well to large projects. Both schemes violate common pathname
> conventions. Neither seems appropriate as a default, although they  
> could
> be valuble to users who habitually edit many files with identical  
> names.
> As you pointed out, feature creep and excess configurability have  
> their
> own costs, which needs to be weighed against the marginal advantage  
> in a
> generally uncommon use case.
>

There you have the common-factor again. And I agree that the path- 
scheme may not be ideal either. But the software can easily determine  
of ambiguity takes place when determining tab labels. In that case  
you may have to revert to another solution.

> It's interesting that you bring up Apple's UI design which has always
> placed high value on consistency and orthogonality, and much lower  
> value
> on specialized tweaks for power users with rare use cases. I would  
> argue
> that these values have been instrumental to Apple's success.
>

Apple has a lot of knowledge about GUI design and it uses a lot of  
scientific studies to back it up (except for a few apps like the Dock  
but that is a different story). Generally speaking it does a good job  
with consistency and it makes sure the user doesn't EVER EVER have to  
hover over widgets and click targets just to determine which it needs  
to click on.

> The real solution of course is to choose unique file names. It's not
> like this is a big hardship. __init__.py's can and (arguably) should
> contain just a few lines of imports.

Not the case with Zope products and Plone products. They can contain  
a lot more code which also looks very similar making it even harder  
to distuingish them.

In any way, the way tabs are implemented now in Wing is far from  
ideal. Spacing is wrong, there are too many of them, accessing tabs  
that aren't displayed is inconvenient, distinguishability is far from  
ideal. This distinction problem is just one of them and all I want is  
a simple way to prevent user error and annoyance. Wing does a good  
job but still has a few hurdles to take in my opinion :-) .

Danny.




More information about the wingide-users mailing list