Fog Creek Software
Discussion Board




GUI sketch... flame away my design!

ok, here it is:
http://plasma-gate.weizmann.ac.il/~ido/GUI2.gif

now i have some explaining to do...

the icons on the bottom left of the screen function like that:
the trash can is, well - a trash can... no need to explain that 'new' idea i hope. the skull and cross bones are the same as xkill under UNIX. the hand pointing to the right is for ejecting removable media - just drag&drop the removable media's icon on it and it will be ejected. the paper clip icon is for 'always on top': drag&drop it on the windows that you want to keep 'on top'. the first 3 icons to the left are shortcuts:
1. a file browser
2. a terminal
3. the 'tool box' - something like LinuxConf.
the next 4 are for the virtual desktop, and all the rest (3 in our case) are for active programs (like windows [9x/NT4/2K/XP]'s application bar)

the radar: just drag the blue rectangle to change position (instead of using scroll bars)

shortcuts menu (not shown in the picture): just right click on the desktop to see it (like in NeXT)

mile high menu bar: just like MacOS, no need to do any explaining here...

title bar icons: the X to the left is for closeing the window (surprisingly enough), the _ is for minimizing, the square is for maximizing and the two squares inside one another is for fitting the window size to the content.

right click the 'help' menu in the top left of the screen to enable ballon help.

so, what do you think?

Ido Yehieli

Ido Yehieli
Sunday, June 23, 2002

Yes, but may I be prudent enough to ask what is this configuration
(OS + Desktop + Whatever)?

I dare say I don't recognize it. But as long as you are not going to ship this
thing - it's quite all right. You are entitled to customizing your desktop
anyway you please.

Shlomi Fish
Sunday, June 23, 2002

1) windows without titlebars -- how is the user supposed to deal with these?  For example, if you're supposed to hide the Magellan tree window by by clicking on the toolbar or right-clicking, is that too many levels of indirection?

2) text + icons.  You've chosen to use icons over text.  But there is the tradeoff that the toolbar symbols may not make sense to the user.  So there likely should be localized text under the icons, or the text appears when user puts the mouse over the icon.  This can be turned off if the user doesn't want distraction.

3) the radar is a cool idea.  Though it adds a level of indirection.  There has to be an elegant way to handle large sequences of things.

pavel
Sunday, June 23, 2002

(btw -- I was going to write an intro that I liked the clean, sparse look of the windowing system, but the form sent before I could write this.)

pavel
Sunday, June 23, 2002

Nice prototype. I've got a few of my own lying about. Maybe I'll have the courage to publicly display them sometime. On to some comments.

I dont see what the advantage of the radar view over a well designed scroll bar would be for regulary formatted textual data (like a file listing). Such views are great for CAD programs, Image editors and RTS games, but with shrunken text you don't have any more reference to where you are beyond what a scroll bar would provide.

Also, would there be a radar for each windows that needs one, or one that is shared amongst all windows? That could become either cluttered or confusing.

I would probably put the paper-clip on the window titlebar, it being a property of the window and all.

IIRC, with xkill, you click xkill and then click the window to kill. This is backwards from the surrounding icons, where you drag the target of the action onto the icon. Also, I don't know if having a function that says "your programs will be so unstable that you will need to kill them off unceremoniously so often that we provide this function prominently in the interface" is a good message to send :)

Other random thoughts:

I understand the rationale for the global mac-style menu bar (Fitts' Law), but I wonder if maybe per-window menu bars are easier psychologically/conceptually. When you run a Mac app, it feels like it is taking over the screen sometimes. With most Windows/X Window apps, everything for each app/document is self contained in indvidual windows. It becomes more disorienting when Mac apps don't follow the guidelines and leave the menu bar active with no windows open (or, like screen grabbers, don't have windows).

It would seen to me to be easier to think of 1 window = 1 instance of an app. If you are editing multiple documents with the same app, you run multiple window-instances (even if they are all managed by the same app instance behind the scenes).

I see this becoming more important when more people start using larger (or multiple) displays. Imagine when we have wall sized displays and are hand gesturing our windows about (ala Minority Report or the Oxygen Project). Will you want your menu to be against the ceiling or near the content it applies to?

I guess I need my own usability lab to see if this hunch bears out :)

Where to put icons for active windows? When I used WindowMaker as my desktop for a few years, I set it to stack my active window icons starting from the upper left and going down the side of the screen. This made more sense to me as I usually wanted more vertical space for my apps than horizontal (1280x1024 at 21"). If you had window title on mouseover functionality like MacOS X, you could turn on all the title simultaneously with this arrangement rather than have to scrub the task bar. In your case, stacking from the lower left would be a more balanced arrangement. I kept the switch-desktops thingy there because the button that did the switching was in the lower left of the icon (Fitt's Law again).

I too, like the clean sparse look. Simple color/font scheme preferences and a desktop wallpaper are fine by me if the desktop is clean and well proportioned (ie: it doesn't look like the aerial shot of an ancient Mayan city).

Chris Altmann
Sunday, June 23, 2002

Anoher thing. I noticed you have a launch icon for the file manager and another one for the running instance. How about removing the close icon from the title bar of the first running instance of the file manager and only representing that instance using the launch icon? In other words, always have at least one (uncloseable) file manager window always accessable from the same location in the interface (and by being in the lower left, taking advantage of Fitts' Law again). I think NeXT did the no-close-button thing.

Chris Altmann
Sunday, June 23, 2002

Just my 2c. I think the radar might be good for some complex diagrams or latex docs which might take a lot of time to render the visible part.

If that 's the case, scrolling by scrollbar is either terribly slow (when the visible part updates while the user is scrolling) or not responsive (otherwise).

Another possibility is that the diagram or doc is big in both horizontal and vertical direction. In this case, scrolling in, say, a Northeast direction is difficult by scrollbars.

But for a list of text, a scrollbar is definitely better (and much easier to code and debug, I bet).

Anyway, I believe letting the user to choose between scrollbars and the radar is necessary. After all, all of us are so used to scrollbars.

Sam Wong
Sunday, June 23, 2002

[quote]1) windows without titlebars -- how is the user supposed to deal with these? For example, if you're supposed to hide the Magellan tree window by by clicking on the toolbar or right-clicking, is that too many levels of indirection? [/quote]

i assume you mean that the title bars of the windows that are not active have no 'close', minimize, etc. bottons on them? well, it's just to differentiate between active an inactive windows. once a window becomes active, it gets all of his icons back...

[quote] 2) text + icons. You've chosen to use icons over text. But there is the tradeoff that the toolbar symbols may not make sense to the user. So there likely should be localized text under the icons, or the text appears when user puts the mouse over the icon. This can be turned off if the user doesn't want distraction.[/quote]

I've choose the second option, and when you enable ballon help by right clicking 'help' on the menu bar, you'll get just that.

[quote]I dont see what the advantage of the radar view over a well designed scroll bar would be for regulary formatted textual data (like a file listing). Such views are great for CAD programs, Image editors and RTS games, but with shrunken text you don't have any more reference to where you are beyond what a scroll bar would provide.  [/quote]

well then - are you saying that in some cases it's better then the scroll bars and in others it's just as good? no problem here... :-)

[quote]Also, would there be a radar for each windows that needs one, or one that is shared amongst all windows? That could become either cluttered or confusing.[/quote]

it's shared amongst all windows. once a window becomes active, that window 'gets' the radar. i don't think it'll be more confusing then the omny present menu bar(MacOS), and that one isn't very confusing, is it? i can see how it'll take new users a bit of getting used to, but the advantages far exceed the disadvantage(s?) IMO.

[quote] I would probably put the paper-clip on the window titlebar, it being a property of the window and all.[/quote]

good idea. the next version might do just that, but i still need to think about it.

[quote]Anoher thing. I noticed you have a launch icon for the file manager and another one for the running instance. How about removing the close icon from the title bar of the first running instance of the file manager and only representing that instance using the launch icon? In other words, always have at least one (uncloseable) file manager window always accessable from the same location in the interface (and by being in the lower left, taking advantage of Fitts' Law again). I think NeXT did the no-close-button thing. [/quote]

and then drag the running app's icon to the xkill or trash to close it? [spock]intersting... [/spock] [/quote]

[quote]Anyway, I believe letting the user to choose between scrollbars and the radar is necessary. After all, all of us are so used to scrollbars. [/quote]

i've been ohhing and ahhing about letting the user decide, but i'm not sure if it's won't give the user a bit to much choise... I'll need to think about that.

i'll come back and give some mor answers soon.

Ido Yehieli
Monday, June 24, 2002

Could you tell us your Goals with your gui?  In terms of the problems you want to solve and your solutions?

The Radar looks like it solves the problem of the thin rectangular scrollbar.  Normally it is solved partly by mousewheel (and by full-screen windows making it Mile-Wide).  Maybe another solution is having an expanding scrollbar when you mouseover it?  That would keep the well-known scrollbar Metaphor while making it actually usable.

If you stay loyal to the radar, there should be some obvious sign that it's bonded with a window.  Maybe they should have a physical connection, or touching one window will make the other blink.

For always-on-top...  Is this a commonly needed utility?  Consider making it a titlebar option, in a menu?

On windows and osx...  The program shortcut bar is visually distinct from the app bar.  OSX just does it with a small divider that has no other meaning.  Consider this?

Sammy (Criticizing is very easy, and fun)
Monday, June 24, 2002

I'd just like to comment your icons and the way the user
is supposed to use them.
Without your explanation, I wouldn't have grasped their
meanings - except for the trashcan, which is common on
desktops today.

First, the icons are inconsistent in their usage: Some of
them require that the user drags the icon to the object
he wants to work with: The "xkill" icon and the "paperclip"
icon. The others want it just the other way round:
Drag the object to the icon. (the trashcan and the remove
media icon) This is not obvious, there's no clue what to
do for the user.

Second: The symbols have either a distracting or no
meaning at all (at least for my taste). I know that designing
"good" icons is far from easy. But I wouldn't like a skull
residing on my desktop. I'm not a  pirate, you know. ;-)
Also, as someone else already pointed out, why should
I need to have "xkill" always one click away - aren't there
more peaceful ways to exit applications which let them
at least do their cleanup work?

Then the pointing hand icon has not much to do
with ejecting a removable media. And this is another
function that I don't need to have in such a prominent
position. I don't eject my CDs and DVDs that often,
and I usually use the drive's knob for that, because I
have to reach to the drive anyway to take the CD out.

Then, the paperclip means "clipboard" to me.
To "pin" a window to the foreground, I'd use a
"pin" symbol.

Please note: No flames intended. Just my impressions
and humble opinions.

Christian Knapmeyer
Monday, June 24, 2002

I like the idea of drag-droppable titlebar mini-icons, pioneered on BeOS, I believe, and sneakily implemented on MS IE (but AFAIK no other Windows app).

With IE, you can right-drag the mini icon in the title bar and drop it to the desktop or any directory to create a shortcut for it. That icon represents the document displayed in the window. Or more accurately in the case of IE, the URL which is the source of the document

I believe that's all you can do on IE, but to expand this idea, you could drag the mini-icon to the trash to delete the document. In the case of a text editor, it would delete the file. For a file manager, the window represents a directory, and displays the contents of that directory. So dragging the mini-icon to the trash would delete that entire directory.

In addition to the mini-icon for the document, there could be another mini-icon for the process. You could then drag this to the trash to kill the process (instead of using xkill, which was obviously designed before the idea of drag-and-drop). Granted, this would overload the meaning of the trash icon in a questionable way. Dragging the process mini-icon to a terminal would print out the path to the program name, the same way you can drag a file/folder to a command prompt in Windows.

To identify the mini-icons, the document would be placed with a folded-corner frame and process would be... hmm, I 'm not sure. But just to be cool, the process icon frame would change background color from green to red to indicate CPU usage.

With drag-droppable titlebar mini-icons, all four of  those tiles (top-level, eject, kill, trash) could work consistently as drop targets.

Paul Richter
Monday, June 24, 2002

[quote] Then, the paperclip means "clipboard" to me.
To "pin" a window to the foreground, I'd use a
"pin" symbol. [/quote]

alas, the pin icon does have a meaning in Linux... it basicly means that the same window appears in all virtual desktops. i would have used it if it wasn't so.

[quote] Also, as someone else already pointed out, why should
I need to have "xkill" always one click away?

Then the pointing hand icon has not much to do
with ejecting a removable media. And this is another
function that I don't need to have in such a prominent
position. [/quote]

ok then... should i just 'hide' these in the Windows 2k/XP style? and show them only if mouse 'hovers' over an expander icon? (an expander icon is just that little arrow we've grown so used to)

[quote]First, the icons are inconsistent in their usage: Some of
them require that the user drags the icon to the object
he wants to work with: The "xkill" icon and the "paperclip"
icon. The others want it just the other way round:
Drag the object to the icon. (the trashcan and the remove
media icon) This is not obvious, there's no clue what to
do for the user. [/quote]

let me try and repair that: i'll let all four icons act in both ways.
1. you can: drag the trash icon (when dragged it'll be just the green trash can, without the gray background) and drop it on the file you want to put in it, AND: you can drag the file and drop it in the bin for the same functionality.
2. you can: drag the cross bones & skull icons on a window/ app icon to kill it, AND drag the active app's icon (not the shortcut icon) to the skull& cross bones to do the same thing.
3. you can: drag the hand icon and drop it on the drive icon you want to eject, AND: you can drag the drive icon and drop it on the hand for the same functionality.
4. you can: drag the clip icon and drop it on the app's icon/ window you want to put 'on top', AND: you can drag the app's icon and drop it on the clip for the same functionality.

[quote] Without your explanation, I wouldn't have grasped their
meanings - except for the trashcan, which is common on
desktops today. [/quote]

that's why enabling ballon help is so easy - just right click 'help' on the menu bar, and then when your mouse hovers over something it shows you an explaination.

[quote]On windows and osx... The program shortcut bar is visually distinct from the app bar. OSX just does it with a small divider that has no other meaning. Consider this? [/quote]

sure, if you think it's necessary.

[quote]If you stay loyal to the radar, there should be some obvious sign that it's bonded with a window. Maybe they should have a physical connection, or touching one window will make the other blink. [/quote]
the blinking idea is a good one. thanks,

Ido Yehieli
Monday, June 24, 2002

@Paul Richter:

can you please post a screen shot showing the mini icons?
i really have no idea what your talking about...

Ido Yehieli
Monday, June 24, 2002

Ido,

It's the 16x16 icon in the far left of every window title bar. (On your GUI as well as Mac OS, it's where you'd find the close button.) Left-clicking on it brings up the window menu, right-clicking lets you drag and drop. Remember, on Windows this works ONLY with Internet Explorer, no other application.

I now realize that the functions of a process mini-icon can be assumed by the taskbar icon (what you call the "app's icon"). But I like the process mini-icon because it's right there in the window, while the taskbar icon is somewhere else, and the user has to associate it with the icon image.  In windows, the taskbar has a mini-icon identical to that in the window titlebar, but it still makes more sense to drag drop from the window than from some other icon/button representing the window.

Regarding the radar, how about a zooming rect emanating from the radar window, when you focus on it, out to the target window? (And then blinking the target.)

Paul Richter
Monday, June 24, 2002

ok, i'm back (i've just finished debuging a peice of really nasty code... and now not only have all the bugs been ironed out, it looks real tight and small aswell!)

[quote] It's the 16x16 icon in the far left of every window title bar. (On your GUI as well as Mac OS, it's where you'd find the close button.) Left-clicking on it brings up the window menu, right-clicking lets you drag and drop. Remember, on Windows this works ONLY with Internet Explorer, no other application. [/quote]

hey, that's not a bad idea! how come i didn't think of that?...

[quote] it still makes more sense to drag drop from the window than from some other icon/button representing the window. [/quote]
that's a good point.

[quote] Regarding the radar, how about a zooming rect emanating from the radar window, when you focus on it, out to the target window? (And then blinking the target.) [/quote]

hmmm... i'll need to think about that one.

Ido Yehieli
Monday, June 24, 2002

If you want to actually build this as a working desktop then you could use something like Object Desktop and Window Blinds. 

http://www.stardock.com

Simon Lucy
Tuesday, June 25, 2002

thanks Simon,
but it's for an OS project of mine.
though i might build the alpha/beta version in the form of a linux window manager.

Ido Yehieli
Tuesday, June 25, 2002

*  Recent Topics

*  Fog Creek Home