Nesedah RC2

[Jesse Ross]

I figured I'd let you guys see this first -- we can battle the default
button in a bit.

http://www.jesseross.com/clients/gnustep/ui/concepts/18/
camaelon_nesedah.png
or
http://www.jesseross.com/clients/gnustep/ui/concepts/

I think this solves the scroller issue -- it should both please the
masses and give an additional indicator that there could be a scroll
bar there.

The colors are all the same now (except for the unfocused selection,
which is a lighter shade) -- I just used the original purple because
I've been falling back on that as the default. We can have a battle
about colors in another thread (email coming soon!).


J.

[Narcoleptic Electron]

Post by Jesse Ross
http://www.jesseross.com/clients/gnustep/ui/concepts/18/
camaelon_nesedah.png
or
http://www.jesseross.com/clients/gnustep/ui/concepts/
I think this solves the scroller issue -- it should both please the
masses and give an additional indicator that there could be a scroll
bar there.

See my scroller comments in the other thread. I sent it just before
this came out.

Another comment out of left field, related to branding: one other
distinctive Next-ism is scrollers on the left. What about expanding
on this idea (stuff on the left instead of right) by putting the arrow
part of the list box on the left of the list box, and the same for the
arrow button beside the text box? I don't see a usability
disadvantage either way.

[Narcoleptic Electron]

Post by Jesse Ross
http://www.jesseross.com/clients/gnustep/ui/concepts/18/
camaelon_nesedah.png

PS: I think the radio buttons and check boxes look perfect here. Just
noticed them.

[M. Uli Kusterer]

Post by Narcoleptic Electron
Another comment out of left field, related to branding: one other
distinctive Next-ism is scrollers on the left. What about expanding
on this idea (stuff on the left instead of right) by putting the arrow
part of the list box on the left of the list box, and the same for the
arrow button beside the text box? I don't see a usability
disadvantage either way.

What arrows are you talking about?

[Jesse Ross]

Post by M. Uli Kusterer

Post by Narcoleptic Electron
Another comment out of left field, related to branding: one other
distinctive Next-ism is scrollers on the left. What about expanding
on this idea (stuff on the left instead of right) by putting the arrow
part of the list box on the left of the list box, and the same for the
arrow button beside the text box? I don't see a usability
disadvantage either way.

What arrows are you talking about?

I think he means the button parts (with up/down arrows) of the popup
menu and the combo box. I think for both it makes more sense to have
the button on the right, because we read left to right and we see the
relevant information first (in the form of the text), then we see the
button part which tells us that it is one of many options.

J.

[Narcoleptic Electron]

Post by Jesse Ross
I think he means the button parts (with up/down arrows) of the popup
menu and the combo box.

Yes... sorry for the vague terminology on my part.

Post by Jesse Ross
I think for both it makes more sense to have
the button on the right, because we read left to right and we see the
relevant information first (in the form of the text), then we see the
button part which tells us that it is one of many options.

One could say the same about text controls with right-oriented scroll
bars: we see the text, then we see the scroll part which tells us that
it is one of many lines of text. But that's not how OpenStep works,
for various reasons. I was thinking that it might make sense for the
same idea to apply to list controls, to make the UI "stand out" a bit
by embracing and generalizing an idea that is already unique to
OpenStep.

Just an idea though, for some discussion. I know this isn't my usual
"usability through consistency" sort of message, but I thought I'd try
my hand at the "branding through consistency" variety, to be
inconsistent.

[M. Uli Kusterer]

Post by Narcoleptic Electron
One could say the same about text controls with right-oriented scroll
bars: we see the text, then we see the scroll part which tells us that
it is one of many lines of text. But that's not how OpenStep works,
for various reasons. I was thinking that it might make sense for the
same idea to apply to list controls, to make the UI "stand out" a bit
by embracing and generalizing an idea that is already unique to
OpenStep.

However, it won't work nicely with the labels:

label: [ value ] [v]

or

label: [v] [ value ]

The latter requires your eyes to jump over the text. With scrolling
areas it's not as bad, because often they aren't labeled, and when
they're labeled, they're often labeled above the box, not to its left.

[Nicolas Roard]

Post by Jesse Ross
I figured I'd let you guys see this first -- we can battle the default
button in a bit.
http://www.jesseross.com/clients/gnustep/ui/concepts/18/
camaelon_nesedah.png
or
http://www.jesseross.com/clients/gnustep/ui/concepts/
I think this solves the scroller issue -- it should both please the
masses and give an additional indicator that there could be a scroll
bar there.

NO, that's imho wrong. Having "disabled" scrollbar is not good, as for
many people, they will just want to click on them. I really don't see
what's the problem with having NO buttons at all when you can't click
on them ! it makes the interface cleaner, with less noise. Well,
that's my take..

Post by Jesse Ross
The colors are all the same now (except for the unfocused selection,
which is a lighter shade) -- I just used the original purple because
I've been falling back on that as the default. We can have a battle
about colors in another thread (email coming soon!).

I'm not too fond of this pink color, but well.. I preferred #17 .

[Jesse Ross]

Post by Nicolas Roard

Post by Jesse Ross
I think this solves the scroller issue -- it should both please the
masses and give an additional indicator that there could be a scroll
bar there.

NO, that's imho wrong. Having "disabled" scrollbar is not good, as for
many people, they will just want to click on them. I really don't see
what's the problem with having NO buttons at all when you can't click
on them ! it makes the interface cleaner, with less noise. Well,
that's my take..

This is a good point. What is more important: controls not appearing
and disappearing, or putting controls on the screen that exist only to
inform the user of a potential state?

When I look at them as they are in 19/RC2Alt, I do want to click on
them. It might be better just to go back to 17/RC1 (which is also the
way that NeXT and Rhapsody and OS X work).


J.

[Alex Perez]

Post by Nicolas Roard

Post by Jesse Ross
I think this solves the scroller issue -- it should both please the
masses and give an additional indicator that there could be a scroll
bar there.

NO, that's imho wrong. Having "disabled" scrollbar is not good, as for
many people, they will just want to click on them. I really don't see
what's the problem with having NO buttons at all when you can't click
on them ! it makes the interface cleaner, with less noise. Well,
that's my take..

This is a good point. What is more important: controls not appearing and
disappearing, or putting controls on the screen that exist only to
inform the user of a potential state?

If you can't click on them, why have them there?

When I look at them as they are in 19/RC2Alt, I do want to click on
them. It might be better just to go back to 17/RC1 (which is also the
way that NeXT and Rhapsody and OS X work).
J.

[Quentin Mathé]

Post by Alex Perez

Post by Jesse Ross

Post by Nicolas Roard
NO, that's imho wrong. Having "disabled" scrollbar is not good, as
for many people, they will just want to click on them. I really
don't see what's the problem with having NO buttons at all when you
can't click on them ! it makes the interface cleaner, with less
noise. Well, that's my take..

This is a good point. What is more important: controls not appearing
and disappearing, or putting controls on the screen that exist only
to inform the user of a potential state?

If you can't click on them, why have them there?

because they are disabled ;-)
Like traditional buttons can be too and in disabled state you cannot
click on them; the problem on my side would probably more related to
the fact we are adding a second disabled state to the one used with
push buttons etc.
I admit I'm not sure that we really need this variant.

Quentin.

--
Quentin Mathé
***@club-internet.fr

[Narcoleptic Electron]

Post by Quentin Mathé
Like traditional buttons can be too and in disabled state you cannot
click on them; the problem on my side would probably more related to
the fact we are adding a second disabled state to the one used with
push buttons etc.
I admit I'm not sure that we really need this variant.

I was not suggesting that the disabled scrollers look different than
all other disabled controls -- rather, as per the results of my
impromptu usability test, that the appearance of all disabled controls
(including scrollers) is modified uniformly. For 19, for example, all
disabled controls would look like the scrollers. (Uli and I have
since suggested a lighter grey.)

[Karsten Schneider]

Post by Nicolas Roard
NO, that's imho wrong. Having "disabled" scrollbar is not good, as for
many people, they will just want to click on them. I really don't see
what's the problem with having NO buttons at all when you can't click
on them ! it makes the interface cleaner, with less noise. Well,
that's my take..

This is a good point. What is more important: controls not appearing and
disappearing, or putting controls on the screen that exist only to
inform the user of a potential state?

I still agree with Nicolas here.
If you have a textmenu for example it is important to not change the item's
order by throwing away disableed options. But I don't see this problem with the
scrollbar/button. *Every* user will klick on it at least one time and will
think: "hhmmm. disabeled" ;-)
Removing the scrollerbuttons when they are not needed won't waste any thougt
about it.

regards,

Karsten

[Nicolas Roard]

Post by Jesse Ross

Post by Nicolas Roard

Post by Jesse Ross
I think this solves the scroller issue -- it should both please the
masses and give an additional indicator that there could be a scroll
bar there.

NO, that's imho wrong. Having "disabled" scrollbar is not good, as
for many people, they will just want to click on them. I really don't
see what's the problem with having NO buttons at all when you can't
click on them ! it makes the interface cleaner, with less noise.
Well, that's my take..

This is a good point. What is more important: controls not appearing
and disappearing, or putting controls on the screen that exist only to
inform the user of a potential state?
When I look at them as they are in 19/RC2Alt, I do want to click on
them. It might be better just to go back to 17/RC1 (which is also the
way that NeXT and Rhapsody and OS X work).

Count my vote for #17 scrollbars :-)

[Jesse Ross]

A new version of Nesedah is available for your viewing pleasure at:

http://jesseross.com/clients/gnustep/ui/concepts/
or
Loading Image...

Outstanding issues:
- to show or not to show disabled scroll bar buttons
- color

This version has the slightly lighter buttons as suggested by both N.E.
and Uli. Nicolas and Karsten want the scroll bar buttons to disappear,
but we already know what that looks like. I personally can see the
validity in either side -- does anyone feel like convincing me either
way?

Also, the color in this version is closer to a true indigo, as
suggested by Alex. My personal requirements for the default color are:

- high chroma (but provide a desaturated version as an option, like
Aqua does with the Graphite variation)
- not red or yellow (warning colors)
- not blue (Aqua, Luna and Aero)
- attention grabbing
- playful

It definitely works on the first three grounds, but I think it's a bit
heavy. I'm actually starting to prefer the purple I've used in most of
the rest of the mockups... maybe that's just proximity affection,
though. Suggestions?


J.

[Narcoleptic Electron]

Post by Jesse Ross
http://jesseross.com/clients/gnustep/ui/concepts/
or
http://jesseross.com/clients/gnustep/ui/concepts/20/camaelon_nesedah.png
- to show or not to show disabled scroll bar buttons
- color
This version has the slightly lighter buttons as suggested by both N.E.
and Uli.

I like the colour of the disabled arrow buttons. It is definitely
clear that they are disabled, and I think that this treatment would
work for all disabled controls.

One thing, though: I was envisioning the entire disabled scroller to
be the disabled arrow button colour. It would be more in the spirit
of the Next solid-colour disabled scroll area, while still conveying
my idea of a full-sized, but disabled, scroll handle.

Please do not feel that you need to go out of your way to incorporate
my ideas. I haven't contributed anything concrete to the project yet,
so feel free to ignore me. Your designs are great, with or without
me.

Post by Jesse Ross
Also, the color in this version is closer to a true indigo, as
suggested by Alex.

I like it.

[Henrik Mikael Kristensen]

On Tue, 22 Mar 2005 23:53:38 -0500, Narcoleptic Electron

Post by Jesse Ross
http://jesseross.com/clients/gnustep/ui/concepts/
or
http://jesseross.com/clients/gnustep/ui/concepts/20/camaelon_nesedah.png

It's great looking. :-)

How would the column view look with multiple columns? I see the header
corners are curved.

Would adjacent headers come like:

/ header 1 \/ header 2 \

or

/ header 1 | header 2 \

Inspirational screenshot:

Loading Image...

[Alex Perez]

Post by Jesse Ross
http://jesseross.com/clients/gnustep/ui/concepts/
or
http://jesseross.com/clients/gnustep/ui/concepts/20/camaelon_nesedah.png

hm, cool. I actually think I like the first one the most. (blue)

Post by Jesse Ross
Also, the color in this version is closer to a true indigo, as suggested
- high chroma (but provide a desaturated version as an option, like
Aqua does with the Graphite variation)
- not red or yellow (warning colors)
- not blue (Aqua, Luna and Aero)

aww :(

[Jesse Ross]

Post by Alex Perez

Post by Jesse Ross
http://jesseross.com/clients/gnustep/ui/concepts/
or
http://jesseross.com/clients/gnustep/ui/concepts/20/
camaelon_nesedah.png

hm, cool. I actually think I like the first one the most. (blue)

Which blue? The one used in 20 (indigo), or the blue used in 14?

J.

[Alex Perez]

Post by Jesse Ross

Post by Alex Perez

Post by Jesse Ross
http://jesseross.com/clients/gnustep/ui/concepts/
or
http://jesseross.com/clients/gnustep/ui/concepts/20/
camaelon_nesedah.png

hm, cool. I actually think I like the first one the most. (blue)

Which blue? The one used in 20 (indigo), or the blue used in 14?
J.

concept 20, although the color in concept 17 is also very nice

[Jesse Ross]

Post by Alex Perez

Post by Jesse Ross

Post by Alex Perez
hm, cool. I actually think I like the first one the most. (blue)

Which blue? The one used in 20 (indigo), or the blue used in 14?
J.

concept 20, although the color in concept 17 is also very nice

That's not really blue to me, as I meant it in my "rules". When I say no
blue, I mean more of the greenish blue that Aqua and Aero are using. The
color in 20 is okay -- it's not too blue.

J.

[Frederic Stark]

Post by Jesse Ross
Also, the color in this version is closer to a true indigo, as suggested
- high chroma (but provide a desaturated version as an option, like
Aqua does with the Graphite variation)
- not red or yellow (warning colors)
- not blue (Aqua, Luna and Aero)
- attention grabbing
- playful
It definitely works on the first three grounds, but I think it's a bit
heavy. I'm actually starting to prefer the purple I've used in most of
the rest of the mockups... maybe that's just proximity affection,
though. Suggestions?

What about green ? As it would also be used for the default options, and
that default options should always be the safest choice, it wouldn't
clash with its already existing meaning. It may even convey the notion
of a 'safe' ui.

Cheers,

--fred

[Jesse Ross]

Post by Jesse Ross
- to show or not to show disabled scroll bar buttons

I think showing the disabled scroll bar buttons is a bad idea. If a
user starts in the state where the object in question is not
scrollable, then there are no scroll bars. This is logical. If the
scroll bars were shown but disabled, then they have an inactive
control and no visual clue as to how to re-enable it. This is very
bad (see Raskin). When moving in the opposite direction, once the
scroll bars have no meaning, if they are disabled then it conveys the
impression to the user that there is still something hidden, but that
they are not allowed to see it. Hiding the scroll bars completely, in
contrast, shows that there is nothing ooutside the visible window.

We also don't want to get into the habit of creating the "Amazing
Disappearing Controls". If a scroll bar completely disappears, as they
sometimes do in OS X, when it does appear it often appears inside the
area of the text, causing the text to rewrap, and _that_ is a really
bad idea. I do agree that it makes for a cleaner interface, as you
aren't presenting your user with a "dead" control, but I'd rather have
something there to at least take up that space so we don't have
controls popping in and out of existence and moving other controls or
content around.

J.

[Narcoleptic Electron]

Post by Jesse Ross
We also don't want to get into the habit of creating the "Amazing
Disappearing Controls". If a scroll bar completely disappears, as they
sometimes do in OS X, when it does appear it often appears inside the
area of the text, causing the text to rewrap, and _that_ is a really
bad idea. I do agree that it makes for a cleaner interface, as you
aren't presenting your user with a "dead" control, but I'd rather have
something there to at least take up that space so we don't have
controls popping in and out of existence and moving other controls or
content around.

I agree with this 100%. The worst thing a UI can do is automatically
move things around on the user. Human beings rely primarily on
spatial cues, and when these are always changing (i.e. disappearing
scrollers causing wrap in entire window to change), it is a far worse
problem than the only alternative, which is simply disabling the
scrollbars.

Post by Jesse Ross
If the
scroll bars were shown but disabled, then they have an inactive
control and no visual clue as to how to re-enable it. This is very
bad (see Raskin).

It is true that disabled controls are sometimes a bad idea, but I
doubt that Raskin would disagree here. He was probably the biggest
proponent of spatial interfaces ever (cf. The Humane Interface). I
would be interested to see the specific footnote.

[Banlu Kemiyatorn]

Post by Jesse Ross
We also don't want to get into the habit of creating the "Amazing
Disappearing Controls". If a scroll bar completely disappears, as they
sometimes do in OS X, when it does appear it often appears inside the
area of the text, causing the text to rewrap, and _that_ is a really
bad idea. I do agree that it makes for a cleaner interface, as you
aren't presenting your user with a "dead" control, but I'd rather have
something there to at least take up that space so we don't have
controls popping in and out of existence and moving other controls or
content around.
J.

Hi,
I love disabled scroll buttons but I don't like that it didn't use the
bottom left area (where 2 slider meet - X)

#
#
#
X###

A waste, isn't it? Aqua didn't use it because they put their
scrollbar on their right side. And then the X space is being
used for window resizing.

[Frederic Stark]

Post by Jesse Ross
We also don't want to get into the habit of creating the "Amazing
Disappearing Controls". If a scroll bar completely disappears, as they
sometimes do in OS X, when it does appear it often appears inside the
area of the text, causing the text to rewrap, and _that_ is a really bad
idea. I do agree that it makes for a cleaner interface, as you aren't
presenting your user with a "dead" control, but I'd rather have
something there to at least take up that space so we don't have controls
popping in and out of existence and moving other controls or content
around.

There was a nice occurence of that in NeXTstep, which AFAIK, is still
present in Mac OS X:

The IB palettes can be resized. If the content don't fit, it magically
adds scrollers. This can't be seen with default palettes, because they
dont need a scroll pane, even at the minimum size.

The problem is, when you make your window smaller *vertically*, there is
a *vertical* scroller that appear. Such scroller take something like 20
*horizontal* pixels, and, suddently, the window content can't fit
*horizontally*, and an *horizontal* scroll bar appear, so the user can
scroll the content 20 pixels left and right. Ugly (I can reproduce the
behaviour using the Cocoa-Sherlock palette, in my Mac OS X).

Such problem will even be worse under GNUstep, as the scroll bar are on
the left, and most people expect things to be anchored left.

Cheers,

--fred

[Jesse Ross]

Extremely gratuitous, but so pretty!

http://www.stanford.edu/~niran/luminocity/

Make sure you download VLC Media Player from videolan.org if don't have
something that can play ogg videos.


J.

[David Chisnall]

D'Oh. Failed to reply to the list. Again. Is there any reason why
the list doesn't set reply-to to the list address? This is usually the
default for discussion lists.

Post by Jesse Ross
We also don't want to get into the habit of creating the "Amazing
Disappearing Controls". If a scroll bar completely disappears, as
they sometimes do in OS X, when it does appear it often appears
inside the area of the text, causing the text to rewrap, and _that_
is a really bad idea. I do agree that it makes for a cleaner
interface, as you aren't presenting your user with a "dead" control,
but I'd rather have something there to at least take up that space so
we don't have controls popping in and out of existence and moving
other controls or content around.

I agree that resizing components of the UI is bad. The best example
of this is Apple's Preview, which sizes the window based on the
horizontal image size, then adds a vertical scroll bar if the image
will not fit vertically, causing the usable area of the window to be
too small, causing it to need to display a horizontal scroll bar (I
filed a bug about this several months ago, and it was marked as a
duplicate, but not fixed). I have no problem at all with leaving the
space the scroll bar would live in as a gutter, because it does not
look like something which should be able to be clicked on. Instead,
it looks like something that is there to space out the UI a bit, and
hence far less jarring.

[Jesse Ross]

Post by David Chisnall
D'Oh. Failed to reply to the list. Again. Is there any reason why
the list doesn't set reply-to to the list address? This is usually the
default for discussion lists.

I've just gotten into the habit of hitting Reply all, then I get rid of
all the addresses except the mailing list address. It's a bit of a pain,
but at least then you know it's going to the list, and then by removing
the other addresses, you do the kindness of that address's user not having
to sort through duplicates.


J.

[MJ Ray]

Post by Jesse Ross
I've just gotten into the habit of hitting Reply all, then I get rid of
all the addresses except the mailing list address. It's a bit of a pain,
but at least then you know it's going to the list, and then by removing
the other addresses, you do the kindness of that address's user not having
to sort through duplicates.

Recent versions of mailman let users select not to get copies of emails
they were cc'd on, if I recall correctly.

Good email clients (such as GNUMail) let people select whether to reply
only to the list, if a List-Post header is present.

Setting Reply-To to point to the list is a pain in the backside, with
most implementations destroying some data.