[GOODIE] Morph Dock Revisited version 0.1

Henrik Gedenryd Henrik.Gedenryd at lucs.lu.se
Mon Jul 10 06:59:48 UTC 2000


Jim Benson wrote:

> Scott Wallace noted that most of this functionality is
> already available with a properly configured flap, maybe that should be the
> development path.

I agree that the dock should probably be merged with the flaps. I've started
to use flaps, and I find them quite useful. Rather than duplicate the
effort, I'd suggest to use flaps instead of introducing also a dock, adding
to flaps the features you won't live without in a nice way. This will make
the project smaller as well.

> By now you've heard in the popular literature that icons, er what's the
> proper pejorative term? Oh yes, suck. The main argument against icons is
> that they don't do a very good job of representing the action or the object
> they substitute for.

The basic idea is, I guess, don't use pictures for things that are better
represented with words (as vice versa and so on, of course). Point in case:
how many weeks after M$ introduced "tool bars", did "tool tips" come out?
(innovation spurs further innovation; yeah right)

> Number 1, is
> the standard Mac/Windows icon with a text string beneath the icon. Icon
> haters point out that if you have the text on the screen, why do you need to
> have a picture there also, taking up valuable screen real estate?
> Personally, I would just tend to make the icons larger, and leave off the
> title string. The second approach, which seems more Squeak like to me, is to
> have a title pop up when the mouse enters the icon. This could be either
> balloon help, which I don't think fits here, or a title presented directly
> above/below the icon.

So my point is even rendered thumbnails don't help much for windows that
contain text--they'd have to be pretty darn big to make the text readable;
consider telling the right one out of three browsers on different methods.

Having the labels below or above is a minor issue I'd say; it comes down to
whether you'd have to move the icon to make room for the label (dynamic
labels, yes; static text: no need to). Since the flaps are retractable, you
might as well have the text there statically, but since you need to move the
mouse pointer to the icon to open it anyway, I guess it might be ok to have
mouseover behavior too.

By the way, with your argument to make icons bigger, I think we've
discovered Apple's reason for making their dock dynamicaly resizing: they
too noted that they have to be bigger-than-really-practical to be useful (or
more likely: the 'dynamic' CEO ordered icons, the smart employees objected).

David wrote:

> There have been a couple of postings that change the window titles
> to something more meaningful.  I believe the latest was from Henrik.

I was just about to say.

> Most of the system windows simply have titles like 'Transcript', or
> 'Workspace', or 'System Browser'.

As for transcript and workspace, you'd really not have more than one anyway,
would you? (So the title would be informative enough, I mean).

> They also lead to modes, which everyone insists is bad.

Here I might have been temped to yell, they DO NOT!, but since I'm in such a
gooood mood today, I'll ask, How do you mean, icons lead to modes?

> In any case, the implementation of this feature is pretty straight forward.
> I'll try to implement the "mouse enter" title here pretty soon. I'll let you
> take the "title text of the window" approach. I'm figuring that your first
> implementation would be something like a properly setup StringMoprh attached
> to the WindowIconMorph.

Jim, you might just solve this as allowing presentation styles looks for the
present BalloonMorphs, which already have the behavior. This would be a very
useful contribution  for other purposes as well, I'd say.

> I hope this doesn't get me drummed off the list, though I probably deserve
> it.
> 
> I was forced to write a 'simplified' interface for a Squeak based utility. I
> implemented a *gasp* menu bar. I know this is heresy, but I include it
> anyway so that others may not have to share my shame in writing such a
> beast.

Not at all. This reminds me (and this is of course the motivation for a
top-of-the-screen menubar) that the dock should take advantage of the
"infinite height" of things that are on the edge of the screen, so you don't
have to aim too carefully. May instead those be cursed who make a tool
palette but place it two or three pixels away from the edge of the screen!







More information about the Squeak-dev mailing list