[wingide-users] Tiny feature request
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
> the same name. The full file path is in the window title bar. You
> 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
> 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
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
> 3) For those who don't like remembering numbers, the tooltips work
> as a reminder. Since you're using the mouse to click on the tab
> 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
> well to large projects. Both schemes violate common pathname
> conventions. Neither seems appropriate as a default, although they
> be valuble to users who habitually edit many files with identical
> As you pointed out, feature creep and excess configurability have
> 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
> on specialized tweaks for power users with rare use cases. I would
> 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 :-) .
More information about the wingide-users