Modern Theme UI Elements

[Jesse Ross]

Well, here's my second stab at this:

http://jesseross.com/clients/gnustep/ui/concepts/02/camaelon_nesedah.png

I've tried to make this version a bit more true to the NeXT look, but
still have it feel like a modern UI (I've taken to calling this whole
updated theme and icon project "Nesedah", rather than just "modern").

Questions, comments, suggestions, critiques and harassments are welcome
as always. :)


J.

[M. Uli Kusterer]

At 23:41 Uhr -0600 27.02.2005, Jesse Ross wrote:
>Well, here's my second stab at this:
>
>http://jesseross.com/clients/gnustep/ui/concepts/02/camaelon_nesedah.png
>
>I've tried to make this version a bit more true to the NeXT look,
>but still have it feel like a modern UI (I've taken to calling this
>whole updated theme and icon project "Nesedah", rather than just
>"modern").

Hmmm... purrty...

One question: Any chance of making slider knobs (and maybe
checkbox/radiobutton icons) larger? I seem to remember that hot
spots, to be easily clicked, must be at least 8x8 pixels large, and
16x16 is much more comfortable. And Fitts's law encourages even
larger hot spots.

I'm not quite sure about the scrollbar "thumb" or "elevator",
though. When it's at the end of its track, you have these two small
holes at the end of the bar...

But I'm nitpicking here. Great work!
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

[Stefan Urbanek]

Citát "M. Uli Kusterer" <***@gmx.net>:

> At 23:41 Uhr -0600 27.02.2005, Jesse Ross wrote:
> >Well, here's my second stab at this:
> >
> >http://jesseross.com/clients/gnustep/ui/concepts/02/camaelon_nesedah.png
> >
> >I've tried to make this version a bit more true to the NeXT look,
> >but still have it feel like a modern UI (I've taken to calling this
> >whole updated theme and icon project "Nesedah", rather than just
> >"modern").
>
> Hmmm... purrty...
>

Yes, very clean and nice.

> One question: Any chance of making slider knobs (and maybe
> checkbox/radiobutton icons) larger? I seem to remember that hot
> spots, to be easily clicked, must be at least 8x8 pixels large, and
> 16x16 is much more comfortable. And Fitts's law encourages even
> larger hot spots.
>

I think that the size on the image is just fine, if you consider 75 DPI screen.
Note that the OpenStep/Cocoa use device-independent measurement units: points,
not pixels. Therefore what you see on that image with 75 DPI screen resolution,
you should see it in the same size with 100 DPI screen resolution (or any
other).

Thing is, that GNUstep currently supports only 75 DPI resolution, therefore
assumes that 1 pixel ~= 1 point. That means, that the GNUstep UI you will see
with larger resolutions will look smaller, similar to as it does to you on that
75 DPI UI image.

<snip>

Regards,

Stefan Urbanek
--
http://stefan.agentfarms.net

First they ignore you, then they laugh at you, then they fight you, then
you win.
- Mahatma Gandhi

[Quentin Mathé]

Le 28 févr. 05, à 06:41, Jesse Ross a écrit :

> Well, here's my second stab at this:
>
> http://jesseross.com/clients/gnustep/ui/concepts/02/
> camaelon_nesedah.png
>
> I've tried to make this version a bit more true to the NeXT look, but
> still have it feel like a modern UI (I've taken to calling this whole
> updated theme and icon project "Nesedah", rather than just "modern").
>
> Questions, comments, suggestions, critiques and harassments are
> welcome as always. :)

Looks excellent :-)

Few comments… I still dislike the title bar especially the rounded
black area and I would prefer a title bar clearly distinct from window
content. The slider elements needs to be a bit bigger as Uli said, in
my opinion. The color well would probably be better with a more clear
button look. Last point, the check box should have a more distinct
check symbol (when you compare it to radio button dot in particular).

Now here is what I really like : the scrollbar look, the progress bar
look, the tabs view look too (which looks clean and more integrated
than the current one with GNUstep look and feel when you consider the
rectangular tabs).

I think I will use it as Étoilé default look when the project will
become a reality… hehe

Quentin.

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

[Alex Perez]

Quentin Mathé wrote:
> Le 28 févr. 05, à 06:41, Jesse Ross a écrit :
>
>> Well, here's my second stab at this:
>>
>> http://jesseross.com/clients/gnustep/ui/concepts/02/ camaelon_nesedah.png
>>
>> I've tried to make this version a bit more true to the NeXT look, but
>> still have it feel like a modern UI (I've taken to calling this whole
>> updated theme and icon project "Nesedah", rather than just "modern").
>>
>> Questions, comments, suggestions, critiques and harassments are
>> welcome as always. :)
>
>
> Looks excellent :-)

Yes, I really, /really/ like it as well.
>
> Few comments… I still dislike the title bar especially the rounded
> black area and I would prefer a title bar clearly distinct from window
> content.

I agree with Quentin on this point; I think it's important to have an
easily distinguishable title bar.

> The slider elements needs to be a bit bigger as Uli said, in
> my opinion.
Vote #3 for slightly larger slider elements as well.

> The color well would probably be better with a more clear
> button look. Last point, the check box should have a more distinct
> check symbol (when you compare it to radio button dot in particular).

Yeah, I thought the dot was kind of small, also.

> Now here is what I really like : the scrollbar look, the progress bar
> look, the tabs view look too (which looks clean and more integrated
> than the current one with GNUstep look and feel when you consider the
> rectangular tabs).

Yes, theese things are all very nice, and I can't wait until this is
more than a mockup.

>
> I think I will use it as Étoilé default look when the project will
> become a reality… hehe

Hehe...well, I will look foreward to the day, and hopefully I'll have
the opportunity to contribute towards making it happen.

Cheers,
Alex Perez

[Rob Burns]

On 2005-03-01 05:34:03 +0700 Quentin Mathé <gnustep-***@club-internet.fr> wrote:

>
> Now here is what I really like : the scrollbar look, the progress bar look,
> the tabs view look too (which looks clean and more integrated than the
> current one with GNUstep look and feel when you consider the rectangular
> tabs).
>

I quite like it as well. with one exception. The tabs. I find that they are similar to gnomes' tabs, which are very indstinct. It's always difficult for me to tell which one is selected. and where the divisions are. With gnustep's current tabs its very easy to see.

Rob

[Jesse Ross]

Okay, here's what I've gotten for feedback so far:

- Larger controls on radios, check boxes and sliders
- Make active tab more distinct
- Title bar should remain distinct from window content
- Scroll bars should not be rounded/should be more rounded
- Color well should be more button-like

I can easily adjust the tabs (not the shape, but making them stand out
more) and color well, I have no problem with that.

I would like more reasons either way on the scroll bar -- I personally
think rounding them slightly helps differentiate them from the progress
bar, but if you can convince me one way or the other, I'll implement
it.

With the check boxes and radios, I would like to try to keep the size
of the control as close as possible to the size of the text label. I
think that, even at a quick glance, it is easy to tell the difference
between the selected and unselected radios, so I would prefer to not
change the size of the dot (I had it bigger, and it looked really
ugly). I could work with the check box's check so it stands out more,
but I don't want it to extend past the boundary of the box if possible
(for the same reason that I want the controls the same size as the text
-- the elements flow better together that way). Also, and this isn't
apparent from the mockup, but clicking on the label should also
activate the appropriate control, so that greatly increases our hit
area beyond 8x8 or even 16x16.

A similar thing also applies with the slider. Clicking at any point in
the gutter will move the slider to that point (bigger hit area, but not
as precise). If the slider knob gets much bigger it will seem really
disproportionate to the gutter (and the gutter shouldn't get much
bigger because we don't want it to be too close to the size of the
scroll bar's gutter or the progress bar's gutter. Does anyone have any
clever suggestions beyond just "make it bigger" for giving us more hit
area on this control?


That said, keep giving me feedback, everyone. I certainly won't please
everyone, but I will try to please the most (vocal) people. :)

J.

[Randi Joseph]

Hi Jesse,

Nice going so far...

I think the widgets are a bit small. Overall it looks kind of mac os 9
ish. Hopefully you will be able to reconcile this design with the
icons that you posted earlier.

I personally like the original direction you were going in your first
mockup, colors etc.

Is there an agreed to default font and font size? The fonts dont look
like 12pt to me.

Anyways, great job so far...

-randi

BTW, i am going to need a NetworkPreferences.app icon and i am hoping
that you could design it for me. Let me know if thats possible.




On Mar 1, 2005, at 12:20 AM, Jesse Ross wrote:

> Okay, here's what I've gotten for feedback so far:
>
> - Larger controls on radios, check boxes and sliders
> - Make active tab more distinct
> - Title bar should remain distinct from window content
> - Scroll bars should not be rounded/should be more rounded
> - Color well should be more button-like

[Jesse Ross]

> Is there an agreed to default font and font size? The fonts dont look
> like 12pt to me.

I'm using Bitstream Vera Sans 11pt.

[Alex Perez]

Jesse Ross wrote:
>> Is there an agreed to default font and font size? The fonts dont look
>> like 12pt to me.
>
>
> I'm using Bitstream Vera Sans 11pt.

Pretty please, with a cherry on top, don't. The standard GNUstep font is
Bitstream Vera and/or Freefont 12pt, and this is what developers design
their gorm's around.

[Jesse Ross]

> Pretty please, with a cherry on top, don't. The standard GNUstep font is
> Bitstream Vera and/or Freefont 12pt, and this is what developers design
> their gorm's around.

Does this mean it's not possible for the user to set their font size?
Shouldn't the application layout not be dependant on a particular font
size?

I'm just curious, since I don't know all the details.


J.

[Stefan Urbanek]

On Tue, 2005-03-01 at 16:14 -0600, Jesse Ross wrote:
> > Pretty please, with a cherry on top, don't. The standard GNUstep font is
> > Bitstream Vera and/or Freefont 12pt, and this is what developers design
> > their gorm's around.
>
> Does this mean it's not possible for the user to set their font size?
> Shouldn't the application layout not be dependant on a particular font
> size?
>

In OpenStep/Cocoa environment it is not recommended, as GUI is precisely
designed. Therefore the users get exactly what the UI designer created.

I think that changing font sizes to improve readability is big UI hack
and poor magnifier glass replacement. Yes, we can see that in many
environments, but it is just because of historical reasons or because
"others do that too". I hope that GNUstep will avoid this path.

If the designer designs an UI, he is supposed to know the positioning
and size ratios best. It is like newspaper or a nicely designed layout
of a book to match certain aesthetical and readability (in UI it is
usability) criteria. If you were able to change font size, then you will
break those criteria. So how to make it larger/smaller but keep the
criteria? Use magnifier glass! What an invention!

A virtual magnifier glass is no problem for today. With some 'scaling'
ratio, you can get UI of sizes as you like, where you will still
preserve the criteria mentioned before.

To sum it up: font size is part of the default UI design. It shold not
be changed by the user. If user wants to improve readability by
enlarging, then he should use a magnifier glass (be it another
application, desktop feature or GNUstep scale coeficient).

Stefan Urbanek
--
http://stefan.agentfarms.net

First they ignore you, then they laugh at you, then they fight you, then
you win.
- Mahatma Gandhi

[Alex Perez]

Jesse Ross wrote:
>>Pretty please, with a cherry on top, don't. The standard GNUstep font is
>> Bitstream Vera and/or Freefont 12pt, and this is what developers design
>> their gorm's around.
>
>
> Does this mean it's not possible for the user to set their font size?
> Shouldn't the application layout not be dependant on a particular font
> size?
Eh, well, here you go:

The user can set their default system font to anything they so desire.
The /default/ system font size is 12 points. If the user sets his font
smaller, things will look okay. If the user sets the font larger,
however, things start to look really bad really quickly. This is because
Gorms do not resize dynamically if the font size is larger. This is
intentional. I am not qualified enough to answer the question I am sure
you will ask, which is "why?" UIs are, or at least always should be,
designed around the most-spacious 12 point font (the two big ones which
are most commonly used are either Bitstream Vera or Freefont, depending
on the needs of the user (the standard Vera font, for instance, does not
have any Cyrillic characters, so it's useless for Russian speakers)

> I'm just curious, since I don't know all the details.

It's a perfectly reasonable question. I hope you found my answer adequate.

Cheers,
Alex Perez

[Jesse Ross]

> It's a perfectly reasonable question. I hope you found my answer
> adequate.

Yep -- between you and Stefan, it makes sense to me. 12 does seem a bit
large, but if that's what we're working with, then that's okay. I will use
12pt in the next set of mockups and adjust the sizing of other elements
accordingly. I suppose having a higher than normal monitor resolution
makes 12pt make sense.

Since I'm here, are there any other built in defaults or things I should
be aware of when working on the next version? Anything you guys would know
but I might not?


J.

[Nicolas Roard]

Le 1 mars 05, à 23:00, Jesse Ross a écrit :

>> It's a perfectly reasonable question. I hope you found my answer
>> adequate.
>
> Yep -- between you and Stefan, it makes sense to me. 12 does seem a bit
> large, but if that's what we're working with, then that's okay. I will
> use
> 12pt in the next set of mockups and adjust the sizing of other elements
> accordingly. I suppose having a higher than normal monitor resolution
> makes 12pt make sense.

Well, having different *screen resolutions* shouldn't change the real
size of the font -- we're talking of 12 points, not 12 pixels. Bigger
resolution just means more refined drawing.

About the mockup:
I'm not entirely convainced about the buttons -- they look a bit
blurry; although ok.
The headerview (on the tableview and outlineview) is too small (that
would perhaps be sorted with a 12pt font size) and I'm not sure about
their color.. how would the "selected" state of a column look by the
way ?
The nssliders are a bit small but otherwise I like them; the switch
buttons looks a bit small too.. On the scrollbar, I like the bar (and
the point image), but the bar looks a bit out of place compared to the
buttons for the scrolling (perhaps just because the gradient isn't the
same). I like the scrollbar background, it nicely contrast.
The popup list button shouldn't be "outside" the frame of the popup
imho..
I'm also not very fond of the Tabs : looks too square, I really prefer
tabs like on http://www.roard.com/screenshots/screenshot_theme44.png
;-) -- tabs like GNOME.. don't like them.. ;-)

Else, I'll try to make a Camaelon theme with it, to see how it renders
in real apps..

Cheers,

--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke

[Quentin Mathé]

Le 2 mars 05, à 00:51, Nicolas Roard a écrit :

> About the mockup:
> I'm not entirely convainced about the buttons -- they look a bit
> blurry; although ok.

hmm, now you have pointed the blurry look… I'm not sure either myself.

> The headerview (on the tableview and outlineview) is too small (that
> would perhaps be sorted with a 12pt font size)

True.

> and I'm not sure about their color..

They should look much more different than progress bars, right.

> The popup list button shouldn't be "outside" the frame of the popup
> imho..

yep

> I'm also not very fond of the Tabs : looks too square, I really prefer
> tabs like on http://www.roard.com/screenshots/screenshot_theme44.png
> ;-) -- tabs like GNOME.. don't like them.. ;-)

The selected tab needs to be more evident. May be you are right,
rounded tabs would look much more "branded" than tabs in various widely
used UIs and would induce a break in the "square feel", break which
could help readability. … Well, rounded push buttons sparingly used
could improve readability in a similar way.

Last point…
We probably want more distinct colors between background color and
control color otherwise…

Quentin.

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

[M. Uli Kusterer]

At 2:28 Uhr +0100 02.03.2005, Quentin Mathé wrote:
>We probably want more distinct colors between
>background color and control color otherwiseŠ

You really mean *color* or contrast?
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

[Jesse Ross]

Okay -- here's the newest version:

http://jesseross.com/clients/gnustep/ui/concepts/03/camaelon_nesedah.png


I haven't updated scroll bars, scroll arrows or the header section
(above scroll areas) yet, but I've done the following:

- increased text size to 12pt
- made buttons less blurry
- changed pop-up icon to up/down arrows
- increased size of sliders, radios and check boxes
- rounded tabs for increased visual contrast
- increased border width and added drop shadow on color well to make
it a bit more button like


Things people have requested but I likely will not do, since I like
them the way they are:

- remove the line dividing the pop-up's text area from the button area
- use a line or some other device to divide the title bar from the
rest of the window


If you're just joining our regularly-scheduled program, feel free to
compare against the old one here:

http://jesseross.com/clients/gnustep/ui/concepts/02/camaelon_nesedah.png



You know what to do...


J.

[Nicolas Roard]

Le 2 mars 05, à 13:20, Jesse Ross a écrit :

> Okay -- here's the newest version:
>
> http://jesseross.com/clients/gnustep/ui/concepts/03/
> camaelon_nesedah.png

_very_ nice :-)
I much prefer it, because, even if the previous version looked good,
this one looks better _and_ is more original, _and_ is more readable
:-) ...

I like the new buttons, clearly more readable..
the tabs are much better like that too (although the "bump" effect on
the selected tab is perhaps a bit too pronounced ??)

overall the widgets looks more contrasted/readable, the bigger
switch/radios/sliders are a good thing too.

I like the "gradient" separation on the popup button..
the color well looks better with the drop shadow too :-)

The only thing I'm not really convainced is the nscombobox -- either
the button should be included in the combobox textfield frame (ie, no
shadow), or either the textfield should end before the button..
(perhaps a better idea) ?

About the titlebar... I like the black/rounded rectangle.. but having
the titlebar rectangle not including the button remind me too much of
KDE ;-) but well, that's ok. What do you think ?

Now I'm just wondering about updates on
tableview/outlineview/scrollview ;-) (btw, on the original screenshot I
gave you, http://www.roard.com/screenshots/camaelon-default.png , there
was no nsbrowser headers, but we should have them too -- you can see
how they look at the moment on this screenshot for example:
http://www.roard.com/screenshots/screenshot_hv18.png )

keep continuing your excellent work !!

Cheers,

--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke

[Jesse Ross]

> _very_ nice :-)
> I much prefer it, because, even if the previous version looked good,
> this one looks better _and_ is more original, _and_ is more readable
> :-) ...

Thanks!

> The only thing I'm not really convainced is the nscombobox -- either
> the button should be included in the combobox textfield frame (ie, no
> shadow), or either the textfield should end before the button..
> (perhaps a better idea) ?

Yeah -- I admit, it does still look a bit weird. I'll see what I can do on
that.

> Now I'm just wondering about updates on
> tableview/outlineview/scrollview ;-) (btw, on the original screenshot I
> gave you, http://www.roard.com/screenshots/camaelon-default.png , there
> was no nsbrowser headers, but we should have them too -- you can see
> how they look at the moment on this screenshot for example:
> http://www.roard.com/screenshots/screenshot_hv18.png )

Yep -- I prefaced my last email with the fact that I still need to work on
these -- I just wanted to get the biggest points of contention out of the
way first. I'll probably get a chance to update those tonight or tomorrow.

J.

[M. Uli Kusterer]

At 7:20 Uhr -0600 02.03.2005, Jesse Ross wrote:
> - increased text size to 12pt
> - made buttons less blurry
> - changed pop-up icon to up/down arrows

I know this is probably not what you wanted to hear, but personally,
I kinda liked the NeXT-style popup icon. :-/ Gave it more
personality. But I can live with either. The double-arrows may be
more intuitively grasped.

> - increased size of sliders, radios and check boxes

Have you tried using a black check mark and radio "dot"? Since those
are important parts of those buttons, an increase in contrast that
way would probably add just enough to make them stand out enough.

But it's a good now. Like it.

> - rounded tabs for increased visual contrast

I forgot to mention this last time: The grey text for the inactive
tab makes it look like it's disabled. Maybe keep the text black, and
instead make the "fill" of the tab a little darker (maybe like the
average of the progress bar)? Though that *would* probably make it
look more like MacOS 9 ...

It may also help if you added a third tab to the box, so we can see
how it looks when the middle tab is active, which is probably the
more common case.

> - increased border width and added drop shadow on color well to
>make it a bit more button like

Well, make it flush left with the combo box, and the button, too,
and I won't tell your mom ;-)

>Things people have requested but I likely will not do, since I like
>them the way they are:
>
> - remove the line dividing the pop-up's text area from the button area
> - use a line or some other device to divide the title bar from the
>rest of the window

Ever played with the thought of having a similar 3D effect as on the
buttons at the top of the window? Might look too much like Apple's
new "snow" look (or whatever the white windows in Tiger will be
called), though.

Oh, and I think the "close X" could stand to be moved up just a pixel.

And before I forget: We'll probably also need rectangular variants
of the buttons. Cocoa has both, and there are often cases in an app
where you need to have certain buttons line up and "touch", so this
would be really handy. Not to mention NeXT used to have *all* buttons
rectangular, and for quick porting of older apps it'd be handy to
have a rectangular button variant for that.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

[Karsten Schneider]

Hello, Steppers!
I just want to contribute some thoughts even from a useres point of view. I am
not a developer nor a designer; so if you think tis ist jus noise please feel
free to ignore my post.
At first I like to thank Jesse for his fine work and all the motion his
appearance has brougt to the Steppers lists. :-)
So here are some points I thougt about:

Jesse Ross schrieb:
> I haven't updated scroll bars, scroll arrows or the header section
> (above scroll areas) yet,

As mentioned before, scroll bars and column headers should be of a more
different color.

but I've done the following:
> - made buttons less blurry

fine!

> - changed pop-up icon to up/down arrows

I actually liked the NeXT-Style better because it creates some different
identity for the interface.

> - rounded tabs for increased visual contrast

Does anybody know how tabs are shown in the Camino-Browser? I like them very
much, because they are not so tab-like. Maybe this could become another inspiration?

Here are some other thoughts:
- about color:
I agree as already mentioned before, that there should be more contrast in the
whole interface.
About the main interface: You chose a light greyish-blue as color for the main
interface. I am not sure, if this is the right way, because any other color
which is not as neutral as white/grey/black will make some people feel
unconfortable. I for example do not like cold colors very much, I prefer the
warm ones like ocre or something like light orange or amber.
maybe some other hates that and likes green better ...
Think of Apples Aqua-Interface. They cose the white and grey stripes which gave
the interface a very strong identity; but - as colorful as Aqua may be - for the
main interface they used two totally neutral colors.
Another thing is, that on a light grey interface the icons will get much more
attention from the user.

-about rounded/angular
I like the "rounded-edges-paradigm" in Mac OS X very much, because it is
consequently implemented. But please note, that rounded edges in the
GNUstep-interface will cause some inconsistensies.
A user may ask why the scrollbar with its rounded edges may not fit into its
background or why we have rounded tabs, but the "tabbox" or the "Box" which
contains the Radio-Buttons for example is not rounded.
I think the clear and simple angularity creates the *very* strong Identity of
the NeXTSTEP interface. Think of an application window in context of the
NeXT-Desktop:
How does a window with rounded edges on the top and a rounded title-area (and of
course with rounded widgets in it) fit into a Desktop with the square
miniwindows, the Dock with its objects or docked objects on the GWorkspace Fiend
which are all angular?

Just some thoughts. Please do not consider them as offensive, even if they are a
bit different from the way we go now.

Karsten

[Jesse Ross]

> Hello, Steppers!
> I just want to contribute some thoughts even from a useres point of
> view. I am
> not a developer nor a designer; so if you think tis ist jus noise
> please feel
> free to ignore my post.

Thanks for the feedback -- I'm trying to take into account anything
that anyone says.

> At first I like to thank Jesse for his fine work and all the motion his
> appearance has brougt to the Steppers lists. :-)

Sometimes that motion has been backpedaling, I think :)

>> I haven't updated scroll bars, scroll arrows or the header section
>> (above scroll areas) yet,
>
> As mentioned before, scroll bars and column headers should be of a more
> different color.

Agreed -- does it make sense for the headers to look more like buttons?
That's what I'm trying on this version, but if they can't be used as
buttons (for sorting, and such), then it will create a bad metaphor?
Any ideas, anyone?

>> but I've done the following:
>> - changed pop-up icon to up/down arrows
>
> I actually liked the NeXT-Style better because it creates some
> different
> identity for the interface.

I do too, and because the arrows (well, just one arrow, actually) were
originally used for pull-down lists in the OpenStep spec.

>> - rounded tabs for increased visual contrast
>
> Does anybody know how tabs are shown in the Camino-Browser? I like
> them very
> much, because they are not so tab-like. Maybe this could become
> another inspiration?

I also like the new Mac "tabs", but I think most people on the list
want tabs that actually look like tabs.

>
> Here are some other thoughts:
> - about color:
> I agree as already mentioned before, that there should be more
> contrast in the
> whole interface.

I can work on that -- getting things less "blurry" overall seems to be
helping with that.

> About the main interface: You chose a light greyish-blue as color for
> the main
> interface. I am not sure, if this is the right way, because any other
> color
> which is not as neutral as white/grey/black will make some people feel
> unconfortable. I for example do not like cold colors very much, I
> prefer the
> warm ones like ocre or something like light orange or amber.
> maybe some other hates that and likes green better ...
> Think of Apples Aqua-Interface. They cose the white and grey stripes
> which gave
> the interface a very strong identity; but - as colorful as Aqua may be
> - for the
> main interface they used two totally neutral colors.
> Another thing is, that on a light grey interface the icons will get
> much more
> attention from the user.

The original design (mockup on the desktop, if you saw it) used a
blue-gray. The new one is all pure grays. My hope, if it might be
possible to do with Camaelon one day, would be to be able to apply a
tint over any neutral theme and color it however you want.

> -about rounded/angular
> I like the "rounded-edges-paradigm" in Mac OS X very much, because it
> is
> consequently implemented. But please note, that rounded edges in the
> GNUstep-interface will cause some inconsistensies.
> A user may ask why the scrollbar with its rounded edges may not fit
> into its
> background or why we have rounded tabs, but the "tabbox" or the "Box"
> which
> contains the Radio-Buttons for example is not rounded.

Here's my paradigm -- it's not totally implemented yet, but it's mostly
there:
- Anything that's a container or that you type in, is angled
- Anything that's clicked on, is rounded

The only exceptions right now (that I see) are the arrows on the scroll
bar, which will be a bit more "button"-like in the next version, and
the arrow in the browser, which I think is clearer when angled.

> I think the clear and simple angularity creates the *very* strong
> Identity of
> the NeXTSTEP interface. Think of an application window in context of
> the
> NeXT-Desktop:
> How does a window with rounded edges on the top and a rounded
> title-area (and of
> course with rounded widgets in it) fit into a Desktop with the square
> miniwindows, the Dock with its objects or docked objects on the
> GWorkspace Fiend
> which are all angular?

I'm hoping that once we build a new Dock.app we'll be able to theme it,
and it will have similar stylings as this mockup.

> Just some thoughts. Please do not consider them as offensive, even if
> they are a
> bit different from the way we go now.

Definitely not offensive -- thanks for all the input!


J.

[Karsten Schneider]

Jesse Ross schrieb:

> Agreed -- does it make sense for the headers to look more like buttons?
> That's what I'm trying on this version, but if they can't be used as
> buttons (for sorting, and such), then it will create a bad metaphor? Any
> ideas, anyone?

I agree with you. The headers are a kind of passive widgets. Making them look
like active widgets may confuse users.
Maybe doing the contrary is better. What I mean is making active widgets more
noticeable. Think of a button which might say to the user: "Hey, user! Klick
me!" or the progress bar which would say "look at me; I am at 92%" ;-)
These widgets should get the users attention.

Again I want to take a look at Apples Aqua-Interface. In a dialog-window the
"default-button" is blue, while the other ones are greyed out. So this button
which is mostly used or which is the most important gets the users attention first.

Another thing about "users attention" on Aqua:
I realized, that the focused window (content) has more colors than the other
ones; they are greyed out. We have that behaviour on X11 windowmangers too. This
helps concentrating on the focused window. Just a thougt to implement something
like that.

> I do too, and because the arrows (well, just one arrow, actually) were
> originally used for pull-down lists in the OpenStep spec.

so let's get back the NeXT style ;-)

> I also like the new Mac "tabs", but I think most people on the list want
> tabs that actually look like tabs.

okay, maybe the kind of tabs I described will also not fit very well into the
new GNUstep interface. I liked the old tab style very much, too, only thing that
I disliked was that they were not smooth but very "pixeled". The old style with
the shadows and smoothness you gave them in the new mockup will probably fit
well into it. The new ones are *very* round ;-)

> I can work on that -- getting things less "blurry" overall seems to be
> helping with that.

Yes, that makes things much better!
Maybe we should think about if we want to risk some more color in the interface
in the context I mentioned above (buttons, active/unactive windows/title-bars,
etc.). But this should not look too much like the Mac OS X - Bonbon interface. I
think more about something like the OpenStep violett/blue (background-default)
for example. Gradients with 3e3076 may be a good choice.

> The original design (mockup on the desktop, if you saw it) used a
> blue-gray.

Oh, yes! Sorry about that. I stared so much upon it that I even thought it is
the same color. ;-)

> The new one is all pure grays. My hope, if it might be
> possible to do with Camaelon one day, would be to be able to apply a
> tint over any neutral theme and color it however you want.

sounds best.

> Here's my paradigm -- it's not totally implemented yet, but it's mostly
> there:
> - Anything that's a container or that you type in, is angled
> - Anything that's clicked on, is rounded

ah, yes, I understand.

> The only exceptions right now (that I see) are the arrows on the scroll
> bar, which will be a bit more "button"-like in the next version, and the
> arrow in the browser, which I think is clearer when angled.

agreed.

> I'm hoping that once we build a new Dock.app we'll be able to theme it,
> and it will have similar stylings as this mockup.

I may not imagine if these objects would really look good with rounded edges.
But maybe here I am a bit old-fashioned; I like the simple angular structures
very much, but this is just my personal opinion. ;-)

> Definitely not offensive -- thanks for all the input!
>
>
> J.

:-)
regards, Karsten

[Jesse Ross]

> Again I want to take a look at Apples Aqua-Interface. In a dialog-window
> the "default-button" is blue, while the other ones are greyed out. So
> this button which is mostly used or which is the most important gets
> the users attention first.

Yes -- I think this is a very good idea. How does GNUstep implement this
now? I could probably look through screenshots if no one has one
immediately available.

> Another thing about "users attention" on Aqua:
> I realized, that the focused window (content) has more colors than the
> other ones; they are greyed out. We have that behaviour on X11
> windowmangers too. This helps concentrating on the focused window. Just
> a thougt to implement something like that.

Yep -- the black titlebar version will be for the main focused window. The
other window will look more like my original mockup (gray with black
text).

>> I do too, and because the arrows (well, just one arrow, actually)
>> were originally used for pull-down lists in the OpenStep spec.
>
> so let's get back the NeXT style ;-)

Anyone totally in disagreement over this? If not, I'm going to switch it
back.

> Maybe we should think about if we want to risk some more color in the
> interface in the context I mentioned above (buttons, active/unactive
> windows/title-bars, etc.). But this should not look too much like the
> Mac OS X - Bonbon interface. I think more about something like the
> OpenStep violett/blue (background-default) for example. Gradients with
> 3e3076 may be a good choice.

I could try a version with default buttons and other controls with color,
just to see how it looks. Let's get all of the control shapes finalized
first though.

>> I'm hoping that once we build a new Dock.app we'll be able to theme
>>it, and it will have similar stylings as this mockup.
>
> I may not imagine if these objects would really look good with rounded
> edges. But maybe here I am a bit old-fashioned; I like the simple
> angular structures very much, but this is just my personal opinion. ;-)
>

Once we get this mockup set in stone and we begin to convert it to an
actual theme, I will start working on an overall desktop refresh, with an
updated dock and menu palette. BTW, for all those who hated my "taskbar"
in the original mockup, the current dock is starting to grow on me :)


J.

[Nicolas Roard]

Le 3 mars 05, à 18:29, Jesse Ross a écrit :
>
>>> I do too, and because the arrows (well, just one arrow, actually)
>>> were originally used for pull-down lists in the OpenStep spec.
>>
>> so let's get back the NeXT style ;-)
>
> Anyone totally in disagreement over this? If not, I'm going to switch
> it
> back.

Personally, I prefer the double-arrow, it's prettier.. the NeXT icon
was just a 3d box...

--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke

[Randi Joseph]

On Mar 3, 2005, at 5:33 PM, Nicolas Roard wrote:

>
> Le 3 mars 05, à 18:29, Jesse Ross a écrit :
>>
>>>> I do too, and because the arrows (well, just one arrow, actually)
>>>> were originally used for pull-down lists in the OpenStep spec.
>>>
>>> so let's get back the NeXT style ;-)
>>
>> Anyone totally in disagreement over this? If not, I'm going to switch
>> it
>> back.
>
> Personally, I prefer the double-arrow, it's prettier.. the NeXT icon
> was just a 3d box...

i second that. The little 3d box looks weird when you are rounding
corners on everything else. You should invert the colors of
the arrows and the background behind them for a subtle sweet effect.....

pushing it.......

[Alex Perez]

Randi Joseph wrote:
>
> On Mar 3, 2005, at 5:33 PM, Nicolas Roard wrote:
>
>>
>> Le 3 mars 05, à 18:29, Jesse Ross a écrit :
>>
>>>
>>>>> I do too, and because the arrows (well, just one arrow, actually)
>>>>> were originally used for pull-down lists in the OpenStep spec.
>>>>
>>>>
>>>> so let's get back the NeXT style ;-)
>>>
>>>
>>> Anyone totally in disagreement over this? If not, I'm going to switch it
>>> back.
>>
>>
>> Personally, I prefer the double-arrow, it's prettier.. the NeXT icon
>> was just a 3d box...
>
>
> i second that. The little 3d box looks weird when you are rounding
> corners on everything else. You should invert the colors of
> the arrows and the background behind them for a subtle sweet effect.....

To quote a certain flash animation: "double-arrows GOOD! Funky box thing
BAD!"</vote>

Cheers,
Alex Perez

[Jesse Ross]

Okay, everyone! Round 4 is available for your perusal here:

http://jesseross.com/clients/gnustep/ui/concepts/04/camaelon_nesedah.png

I've updated the browse text box (separated the button from the text
box), added a browser header, increased the size on the matrix headers,
lightened up the area within the matrix and browsers, added thumbs to
the scroller, added a third tab on the notebook, added division in the
matrixes, and kept the arrows on the popup (the people have voted!).

I've also tried a version using Lucida Grande instead of Bitstream Vera
Sans:

http://jesseross.com/clients/gnustep/ui/concepts/04/
camaelon_nesedah_lucida.png

I think it looks much cleaner -- if I create an LGPL'd version of
Lucida, would there be support for using it?


Feedback, flames, blah blah blah :)


J.

[Nicolas Roard]

Le 5 mars 05, à 16:39, Jesse Ross a écrit :

> Okay, everyone! Round 4 is available for your perusal here:
>
> http://jesseross.com/clients/gnustep/ui/concepts/04/
> camaelon_nesedah.png

Very nice :-)

> I've updated the browse text box (separated the button from the text
> box), added a browser header, increased the size on the matrix
> headers, lightened up the area within the matrix and browsers, added
> thumbs to the scroller, added a third tab on the notebook, added
> division in the matrixes, and kept the arrows on the popup (the people
> have voted!).

as always, the following are just my comments, we're here to discuss..

not sure about the very different header look between
NSBrowser/NSTableView ..
also, the space between the nsbrowser and its bottom scrollbar looks
too big to me (should be the same as the space between the nsscrollview
and the header).

I like the change on the nscombobox (the button outside the textfield);
more or less, the left part of this mockup looks very nice to me :-))

I'm not very fond of the new nstableview headers though; a slight
gradient could perhaps help ? I don't know.. the previous one looked
too small, but thoses looks a bit too tall..
And how a selected header looks like ?

On the scrollbars, I find the rounded buttons a bit strange looking...
and the header above shouldn't be rounded then, it looks strange (the
"rounded part" should be below the header, imho.. like on OSX).

> I've also tried a version using Lucida Grande instead of Bitstream
> Vera Sans:
>
> http://jesseross.com/clients/gnustep/ui/concepts/04/
> camaelon_nesedah_lucida.png
>
> I think it looks much cleaner -- if I create an LGPL'd version of
> Lucida, would there be support for using it?

well, we could distribute it I guess. Not sure it's worth the work for
the moment though..

> Feedback, flames, blah blah blah :)

done :-)

thanks,

--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke

[Jesse Ross]

> as always, the following are just my comments, we're here to discuss..
>
> not sure about the very different header look between
> NSBrowser/NSTableView ..
> also, the space between the nsbrowser and its bottom scrollbar looks
> too big to me (should be the same as the space between the
> nsscrollview and the header).

Oops -- sorry. I didn't realize that was the bottom scroll bar... it
will be attached to the box in the next version.

> I like the change on the nscombobox (the button outside the
> textfield); more or less, the left part of this mockup looks very nice
> to me :-))

Thanks!

> I'm not very fond of the new nstableview headers though; a slight
> gradient could perhaps help ? I don't know.. the previous one looked
> too small, but thoses looks a bit too tall..
> And how a selected header looks like ?

I will add a selected one in the next one for comparison. And the
headers are the same height as the button, since they'll all use the
same font height. It probably won't look as tall with letters that
descend the baseline (like g, j, p, q and y).

> On the scrollbars, I find the rounded buttons a bit strange looking...
> and the header above shouldn't be rounded then, it looks strange (the
> "rounded part" should be below the header, imho.. like on OSX).

I'm not totally happy with it either, yet. I could try rounding the
scroll bar more so that the button rounding looks more deliberate; more
like how Mac OS X is. I like detaching the top rounding from the header
-- I'll probably do that in the next version. I tried flattening the
side of the scroll bar opposite the arrow buttons, so there wasn't just
two little pixels poking down, but it looked a little odd. Anyone have
any other suggestions for improving the scroll bar?

>> I've also tried a version using Lucida Grande instead of Bitstream
>> Vera Sans:
>>
>> http://jesseross.com/clients/gnustep/ui/concepts/04/
>> camaelon_nesedah_lucida.png
>>
>> I think it looks much cleaner -- if I create an LGPL'd version of
>> Lucida, would there be support for using it?
>
> well, we could distribute it I guess. Not sure it's worth the work for
> the moment though..

True, it would be a lot of work -- but once the theme gets finalized,
that is one area where I think the UI could use a big improvement, and
I would certainly be willing to do it if there is agreement from the
developers that we could use it as the default font at some point (and
tweak Gorm files around it). A good selection of free and freely
distributable high quality fonts is one place where open source
desktops are severely lacking.


J.

[Alex Perez]

Jesse Ross wrote:
[snip]
> True, it would be a lot of work -- but once the theme gets finalized,
> that is one area where I think the UI could use a big improvement, and
> I would certainly be willing to do it if there is agreement from the
> developers that we could use it as the default font at some point (and
> tweak Gorm files around it).
In this case, that's actually not necessary, because Lucida is more
narrow than Bitstream Sans Vera. Because of this, if a gorm is
constructed around BSV, you can be guaranteed to not have sizing issues
with most other 12 point fonts. Also, if you really /do/ end up making a
lucida font, I suggest you get on the freedesktop-xdg mailing list and
have some sort of informal polling with regards to which charsets you
should do first...obviously, the traditional latin1+2 ranges (please
make it a unicode font) should obviously come first, but after that, you
might want to do some querying into what seems to be the most needed
script (cyrillic, perhaps?). Also, make sure the font includes decent
hinting, because this is a problem with a lot of

> A good selection of free and freely
> distributable high quality fonts is one place where open source
> desktops are severely lacking.
Amen, brother!

[Quentin Mathé]

Le 5 mars 05, à 18:04, Nicolas Roard a écrit :

> Le 5 mars 05, à 16:39, Jesse Ross a écrit :
>
>> Okay, everyone! Round 4 is available for your perusal here:
>>
>> http://jesseross.com/clients/gnustep/ui/concepts/04/
>> camaelon_nesedah.png
>
> Very nice :-)

Yes :-)

>> I've updated the browse text box (separated the button from the text
>> box), added a browser header, increased the size on the matrix
>> headers, lightened up the area within the matrix and browsers, added
>> thumbs to the scroller, added a third tab on the notebook, added
>> division in the matrixes, and kept the arrows on the popup (the
>> people have voted!).
>
> as always, the following are just my comments, we're here to discuss..
>
> not sure about the very different header look between
> NSBrowser/NSTableView ..

I think the different header look are welcome because you cannot click
on NSBrowser header unlike NSTableView headers.

> also, the space between the nsbrowser and its bottom scrollbar looks
> too big to me (should be the same as the space between the
> nsscrollview and the header).

hmm the inactive scroll bar below has probably nothing to do with the
browser part in Jesse mockup.

> I like the change on the nscombobox (the button outside the
> textfield); more or less, the left part of this mockup looks very nice
> to me :-))

Well, there is a real problem her, because when I rewrote the combo box
six months ago, I decided to draw the button cell inside the text field
cell because previously it looked ugly and I wasn't able to achieve a
clean look (because button and text field borders uses different
gradients with NeXT theme)…
May be I should add a boolean flag you could edit with each theme in
order to decide whether the button is drawn embedded or not.

> I'm not very fond of the new nstableview headers though; a slight
> gradient could perhaps help ? I don't know.. the previous one looked
> too small, but thoses looks a bit too tall..

… he I really love the new table view headers, their shadowed flat look
is very smart in my opinion :-D
May be the selected header could be rendered a little bit darker.

> And how a selected header looks like ?

The right headers are selected in the mockup, no ?

> On the scrollbars, I find the rounded buttons a bit strange looking...
> and the header above shouldn't be rounded then, it looks strange (the
> "rounded part" should be below the header, imho.. like on OSX).

I admit I'm not really convinced by the rounded scroll bar buttons me
too… I'm not sure if I would prefer them more rounded or just square
like in previous mockups.

>> I've also tried a version using Lucida Grande instead of Bitstream
>> Vera Sans:
>>
>> http://jesseross.com/clients/gnustep/ui/concepts/04/
>> camaelon_nesedah_lucida.png
>>
>> I think it looks much cleaner -- if I create an LGPL'd version of
>> Lucida, would there be support for using it?
>
> well, we could distribute it I guess. Not sure it's worth the work for
> the moment though..

I agree with Nicolas for this point. It's true Vera sans is somewhat
ugly, but I'm not sure a Lucida clone is the right idea, because it
would take time to clone it and would look too much inspired by Aqua;
then it is be probably better to wait and to decide later for new
system font with strong readability and personality (probably a font
clone like your Lucida proposal).

Thanks,
Quentin.

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

[M. Uli Kusterer]

At 10:39 Uhr -0600 05.03.2005, Jesse Ross wrote:
>Okay, everyone! Round 4 is available for your perusal here:
>
>http://jesseross.com/clients/gnustep/ui/concepts/04/camaelon_nesedah.png

Here's my comments:

1) Checkbox, Radios: A-OK!

2) Tab view: Much more obvious where tabs begin/end and what one is
current. Great!

3) Browser: Scroll bar is too far away. I'm not sure whether there's
a usability reason for browser headers being a different colors than
those on list boxes, but I could see the same style used for both.

4) Scroll bar: I know I suggested that, but I don't think the way the
scroller buttons extend into the track so the thumb can "dock" into
it works. Go back to the old one. Maybe you can just change the
drawing code so the rounded end gets "tucked under" the buttons, or
you could just slightly flatten the thumb. I've drawn up a few quick
ideas:

http://custosHK.bei.t-online.de/thumbideas.png

I wouldn't go for a more rounded variant, simply because this looks
too much like Aqua, and GNUstep will have to fight being a GNU MacOS
X knockoff anyway, so the GUI is a place where can prevent this most
easily.

That's pretty much it. Great work!
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

[Nicolas Roard]

Le 5 mars 05, à 19:20, M. Uli Kusterer a écrit :
>
> 4) Scroll bar: I know I suggested that, but I don't think the way the
> scroller buttons extend into the track so the thumb can "dock" into it
> works. Go back to the old one. Maybe you can just change the drawing
> code so the rounded end gets "tucked under" the buttons, or you could
> just slightly flatten the thumb. I've drawn up a few quick ideas:
>
> http://custosHK.bei.t-online.de/thumbideas.png
>
> I wouldn't go for a more rounded variant, simply because this looks
> too much like Aqua, and GNUstep will have to fight being a GNU MacOS X
> knockoff anyway, so the GUI is a place where can prevent this most
> easily.

I like the one on the far right -- perhaps just change the buttons to
have them with the same gradient than the knob ? so they will "fit"
better ?
Anyway I quite agree with your comment -- we don't want to be an OSX
ripoff.

--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke

[M. Uli Kusterer]

At 11:26 Uhr -0600 05.03.2005, Jesse Ross wrote:
>True, it would be a lot of work -- but once the theme gets
>finalized, that is one area where I think the UI could use a big
>improvement, and I would certainly be willing to do it if there is
>agreement from the developers that we could use it as the default
>font at some point (and tweak Gorm files around it). A good
>selection of free and freely distributable high quality fonts is one
>place where open source desktops are severely lacking.

While Lucida is a great font, I'd rather if you spent your time on
GNUstep-specific things right now. :-)

Also, Lucida is Apple's font. Cloning some other similar sans-serif
font for GNUstep would probably give it more of an own personality.
In that regard, cloning an Apple font probably is exactly what we
don't want. And fonts are another area where one can often be
individualist without damaging usability (if it isn't a fancy
headline font, that is).

That having been said, if, once the theme is finished, you still
feel like cloning a font, I've always been kind of partial to Gill
Sans Condensed or Futura Medium ... ;-)

Oh, and BTW: from my tests, Lucida actually runs wider than Vera...
(<http://custoshk.bei.t-online.de/fonts.png> - they're all at 50
points)
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

[Jesse Ross]

> 4) Scroll bar: I know I suggested that, but I don't think the way the
> scroller buttons extend into the track so the thumb can "dock" into it
> works. Go back to the old one. Maybe you can just change the drawing
> code so the rounded end gets "tucked under" the buttons, or you could
> just slightly flatten the thumb. I've drawn up a few quick ideas:
>
> http://custosHK.bei.t-online.de/thumbideas.png

I really like the idea of tucking it behind the boundaries, but how
feasible is that from a technical standpoing? Although the angled off
scroll bar works well, I didn't want to use that, because I was trying
to use a paradigm of "if it's rounded, it's something clickable". Of
course, the arrows and the table headers kind of go against that...

> I wouldn't go for a more rounded variant, simply because this looks
> too much like Aqua, and GNUstep will have to fight being a GNU MacOS X
> knockoff anyway, so the GUI is a place where can prevent this most
> easily.

Right, and as others have said, that would also be a good reason to
avoid using Lucida. Maybe trying to get a new font into the system can
be my mission next year :)


Well, if no one has any further issues, I'm going to freeze the left
side of the mockup in this list. We'll see how "discuss" responds...



J.

[Jesse Ross]

> That having been said, if, once the theme is finished, you still feel
> like cloning a font, I've always been kind of partial to Gill Sans
> Condensed or Futura Medium ... ;-)

Gill Sans is a very nice font, although I think the bold version may be
a bit too heavy. Good suggestion.

Futura is also nice, but part of what I don't like about BSV on the
desktop is that it's (mostly) a consistent line weight font, just like
Futura.

> Oh, and BTW: from my tests, Lucida actually runs wider than Vera...
> (<http://custoshk.bei.t-online.de/fonts.png> - they're all at 50
> points)

That's weird, because when I flip between the two in the mockup, Lucida
is subtly smaller. Look, for example, at the Radio labels (not the
titlebar, because there Lucida is at 13 and BSV is at 12). We must have
slightly different versions of the same font, because here's my font
test with everything at 50pt:

http://jesseross.com/clients/gnustep/ui/fonts/font_test.png

Craziness.


J.

[Jesse Ross]

Revision 5, for your viewing pleasure:

http://jesseross.com/clients/gnustep/ui/concepts/05/camaelon_nesedah.png

The table headers are using a coloring scheme similar to the tabs. I
think this makes sense and prevents confusing them with the browser
header. I'm personally not too psyched about the browser header. It
feels a bit clunky to me... I'll probably play with that some more.

If you look at the table with "Toy" in it, you can see that the letter
'y' is keeping me from making the header shorter. I did add the
gradient in, though, which helps indicate that these are clickable
elements.

The scroll bar uses Uli's tuck-behind concept -- I'm not sure about
implementation, though. And scroll arrows now have the same gradient as
the buttons and scroll bar.


J.

[Narcoleptic Electron]

Jesse Ross wrote:
> Revision 5, for your viewing pleasure:
>
> http://jesseross.com/clients/gnustep/ui/concepts/05/camaelon_nesedah.png
>

It looks very good to me. My comments to follow come from more of a
"usability" angle than a "design" one, simply because that is where my
abilities lie. Of primary importance to me are consistency and
discoverability.

Also, I am a GNUstep newbie, so you may need to take my suggestions
with a grain of salt...

First, I like your idea of separating the combo box into a regular
text field and a drop-down button. It replaces the additional concept
of a "combo box" with two existing concepts, the "text field" and the
"drop down button".

Jesse wrote:
> The table headers are using a coloring scheme similar to the tabs. I
> think this makes sense and prevents confusing them with the browser
> header. I'm personally not too psyched about the browser header. It
> feels a bit clunky to me... I'll probably play with that some more.
>
> If you look at the table with "Toy" in it, you can see that the letter
> 'y' is keeping me from making the header shorter. I did add the
> gradient in, though, which helps indicate that these are clickable
> elements.
>
> The scroll bar uses Uli's tuck-behind concept -- I'm not sure about
> implementation, though. And scroll arrows now have the same
> gradient as
> the buttons and scroll bar.

The scroll button isn't really clickable in the same way that buttons
or table headers are; if so, you could say that almost everything is
clickable.

Instead, I would categorize visual elements in the following way (as a
first stab):

1. Clickable. Two types:
a) Mouse location within control matters. Two types:
i) Cursor appears at location (text box).
ii) No cursor appears (scroll trough, slider trough).
b) Non-pinpoint. Three types:
i) Control depresses, then pops back up (button, table header).
ii) Control changes state and keeps it (check box, radio button).
iii) Control doesn't do either (deselected tab).
2. Draggable. Two types:
a) Single draggable unit (scroll button, slider button).
b) Attached to something else (window resize handle).

Note that it is the deselected tabs that are clickable, but not the
selected one. As such, I believe the "non-selected" tabs and headers
should look like regular buttons, whereas the selected tabs and
headers should look like the "default" button. OS X has done
something like this, which uses the blue colour for the latter.
However, they err by making the selected tab look clickable.

Also note that the above categorization applies to window parts (close
button, window resizer, title bar, etc.) as well.

If there could be some sort of consistent visual distinction for each
of the element-types listed, it would be the ultimate in discoverable
interfaces.

In fact, as someone new to GNUstep, I have the following potentially
ludicrous additional suggestions, which go slightly beyond design:

- Could the line in the slider button move within the button to
indicate exactly where on the slider we are? For example, if the
slider button is in the middle, the line is in the middle of the
button. When all the way to the left, the line is on the left side of
the button. This way, when you click the trough, the line goes right
underneath the mouse, exactly.

- Could the scroll button use the same line as the slider, as
described above, instead of the dot?

- Could the slider use the trough, with arrow buttons, from the scroll
bar? This would simplify the interface by removing redundant
concepts, and allow fine-grained control of the slider via the arrow
buttons. It would be obvious that it is not a scroll bar, because it
isn't attached to the edge of a scroll view.

[Narcoleptic Electron]

I wrote:
> - Could the line in the slider button move within the button to
> indicate exactly where on the slider we are?
>
> <snip>
>
> - Could the scroll button use the same line as the slider, as
> described above, instead of the dot?
>

Except that the line wouldn't be visible when at the end of the
slider/scroller...

On second thought, change "line" to "arrowhead" to indicate where its
scrolled to. For a vertical scroller, for example, the arrowhead
would point to the right. When scrolled to the top, only the bottom
half of the arrow head would be shown, at the top of the scroller.

[Jesse Ross]

First of all, welcome to GNUstep! We've been in need of someone with a
good background in UI!

> The scroll button isn't really clickable in the same way that buttons
> or table headers are; if so, you could say that almost everything is
> clickable.

Oops -- I didn't fully explain in the last email. Things that are
"button"-like (changing the state of something through user
interaction) should have rounded edges. Things that have angled edges
are containers for other controls or containers for text. Currently the
scroll buttons and the table headers go against that paradigm.

> Instead, I would categorize visual elements in the following way (as a
> first stab):
>
> 1. Clickable. Two types:
> a) Mouse location within control matters. Two types:
> i) Cursor appears at location (text box).
> ii) No cursor appears (scroll trough, slider trough).
> b) Non-pinpoint. Three types:
> i) Control depresses, then pops back up (button, table header).
> ii) Control changes state and keeps it (check box, radio button).
> iii) Control doesn't do either (deselected tab).
> 2. Draggable. Two types:
> a) Single draggable unit (scroll button, slider button).
> b) Attached to something else (window resize handle).

Seems like a good breakdown to me.

> Note that it is the deselected tabs that are clickable, but not the
> selected one. As such, I believe the "non-selected" tabs and headers
> should look like regular buttons, whereas the selected tabs and
> headers should look like the "default" button. OS X has done
> something like this, which uses the blue colour for the latter.
> However, they err by making the selected tab look clickable.

That's a very good point. We haven't decided yet on how the "default"
objects should look (color or some other indicator). Perhaps once we
finalize on all the control shapes and make that decision, we can
revisit the tabs and table headers.

> In fact, as someone new to GNUstep, I have the following potentially
> ludicrous additional suggestions, which go slightly beyond design:
>
> - Could the line in the slider button move within the button to
> indicate exactly where on the slider we are? For example, if the
> slider button is in the middle, the line is in the middle of the
> button. When all the way to the left, the line is on the left side of
> the button. This way, when you click the trough, the line goes right
> underneath the mouse, exactly.

I think it's a good idea -- the only problem I see is that if you're
using "ticks" or something like a volume control where you might have
fixed intervals that you're lining up to (volume at 10%, 20%, 30%,
etc), then the line in the middle wouldn't line up to the tick unless
you had an exponential distance between labels. Could someone tell me
if this is something we could accomplish technically?

> - Could the scroll button use the same line as the slider, as
> described above, instead of the dot?

It could, but I think the dot has historical significance :)

> - Could the slider use the trough, with arrow buttons, from the scroll
> bar? This would simplify the interface by removing redundant
> concepts, and allow fine-grained control of the slider via the arrow
> buttons. It would be obvious that it is not a scroll bar, because it
> isn't attached to the edge of a scroll view.

From a design standpoint, unless you decreased the size of the scroll
well, you end up with a very clunky control. I like the idea of having
fine arrow control, though.


J.

[Jesse Ross]

> Note that it is the deselected tabs that are clickable, but not the
> selected one. As such, I believe the "non-selected" tabs and headers
> should look like regular buttons, whereas the selected tabs and
> headers should look like the "default" button. OS X has done
> something like this, which uses the blue colour for the latter.
> However, they err by making the selected tab look clickable.

I think this is a really valid point. Does anyone see any qualms with
redesigning the tabs to fit into this model? Similar to what is being
done here:

http://www.aci.com.pl/mwichary/guidebook/pics/gui/settings/keyboard/
rhapsodydr2.png

I think that image makes it clear which button is currently selected,
and keeps the rest of the buttons looking like clickable objects.


J.

[Nicolas Roard]

Le 6 mars 05, à 10:45, Jesse Ross a écrit :

>> Note that it is the deselected tabs that are clickable, but not the
>> selected one. As such, I believe the "non-selected" tabs and headers
>> should look like regular buttons, whereas the selected tabs and
>> headers should look like the "default" button. OS X has done
>> something like this, which uses the blue colour for the latter.
>> However, they err by making the selected tab look clickable.
>
> I think this is a really valid point. Does anyone see any qualms with
> redesigning the tabs to fit into this model? Similar to what is being
> done here:
>
> http://www.aci.com.pl/mwichary/guidebook/pics/gui/settings/keyboard/
> rhapsodydr2.png
>
> I think that image makes it clear which button is currently selected,
> and keeps the rest of the buttons looking like clickable objects.

Personally, I disagree. Sure, tabs are clickable, but it's just a
completely different metaphor than buttons ! not everything clickable
is a button and/or should behave like one. You're presenting the users
with tabs, and that's why it make sense to have the selected tab in
front of you, etc.
I personally loathe what Apple did with their tabs on 10.3 ... they
completely broke the metaphor. Sure you know you can "click" on the
buttons, as they look like buttons, but you don't know what will
happens. I much prefer a real tabs analogy, it makes sense.

--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke

[Jesse Ross]

I got too ambitious...

http://jesseross.com/clients/gnustep/ui/concepts/06/camaelon_nesedah.png

I reversed the tabs and the table headers so that the deselected ones
look clickable.


J.

[Nicolas Roard]

Le 6 mars 05, à 11:00, Jesse Ross a écrit :

> I got too ambitious...
>
> http://jesseross.com/clients/gnustep/ui/concepts/06/
> camaelon_nesedah.png
>
> I reversed the tabs and the table headers so that the deselected ones
> look clickable.

Turns out it looks great :-)

--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke

[Nicolas Roard]

Le 6 mars 05, à 11:00, Jesse Ross a écrit :

> I got too ambitious...
>
> http://jesseross.com/clients/gnustep/ui/concepts/06/
> camaelon_nesedah.png
>
> I reversed the tabs and the table headers so that the deselected ones
> look clickable.

oops sorry, I was too quick ^_^ -- didn't see at first glance that the
tabs are impacted too.. I very much like the table headers that way,
but on the other hand I don't really like the tabs. Just my opinion
though. :-)

--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke

[Jesse Ross]

> oops sorry, I was too quick ^_^ -- didn't see at first glance that the
> tabs are impacted too.. I very much like the table headers that way,
> but on the other hand I don't really like the tabs. Just my opinion
> though. :-)

Yep -- tabs could use some work... I think it works well for the table
headers, though.

:)


J.

[Nicolas Roard]

Le 6 mars 05, à 11:13, Jesse Ross a écrit :

>> oops sorry, I was too quick ^_^ -- didn't see at first glance that
>> the tabs are impacted too.. I very much like the table headers that
>> way, but on the other hand I don't really like the tabs. Just my
>> opinion though. :-)
>
> Yep -- tabs could use some work... I think it works well for the table
> headers, though.

Well.. I'm not entirely fond of the gradient on the non-selected tabs..
But well, it's ok.. the thing in fact that I don't like is that the
selected tab doesn't look selected at all ;-) -- same color as the
window background color, doesn't stand out, etc.
opinions ?

--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke

[Jesse Ross]

>>> oops sorry, I was too quick ^_^ -- didn't see at first glance that
>>> the tabs are impacted too.. I very much like the table headers that
>>> way, but on the other hand I don't really like the tabs. Just my
>>> opinion though. :-)
>>
>> Yep -- tabs could use some work... I think it works well for the
>> table headers, though.
>
> Well.. I'm not entirely fond of the gradient on the non-selected
> tabs.. But well, it's ok.. the thing in fact that I don't like is that
> the selected tab doesn't look selected at all ;-) -- same color as the
> window background color, doesn't stand out, etc.
> opinions ?

Visually, I think it's off too. If it's closer to you, it should be
lighter, not darker. Let me play with it over the next couple of days
-- but if anyone has any suggestions, I'll totally take them.


J.

[M. Uli Kusterer]

At 5:00 Uhr -0600 06.03.2005, Jesse Ross wrote:
>I got too ambitious...
>
>http://jesseross.com/clients/gnustep/ui/concepts/06/camaelon_nesedah.png
>
>I reversed the tabs and the table headers so that the deselected
>ones look clickable.

Problem with that is that it destroys the color perspective. "dark"
means in back, "light" means in front. Here the frontmost one looks
like it's cut out of the theme :-(
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

[Jesse Ross]

>> I got too ambitious...
>>
>> http://jesseross.com/clients/gnustep/ui/concepts/06/
>> camaelon_nesedah.png
>>
>> I reversed the tabs and the table headers so that the deselected ones
>> look clickable.
>
> Problem with that is that it destroys the color perspective. "dark"
> means in back, "light" means in front. Here the frontmost one looks
> like it's cut out of the theme :-(

Totally agree. I'm going to see if there is some other solution to the
tabs.

> One more suggestion? Give the deselected headers a gradient style
> like the selected ones, so they still look clickable. However, keep
> them in that darker shade.

What do you think of the new version where the deselected headers look
more like buttons, and the selected one is depressed?

> Oh, and BTW: Is the gradient in the scrollbar arrows new? I didn't
> notice that before, and it looks classy. Especially how the separator
> between the arrows seems to brighten in the middle. Great work on the
> details there!

Yep -- it's new. Thanks for noticing! :)


J.

[M. Uli Kusterer]

At 8:41 Uhr -0600 06.03.2005, Jesse Ross wrote:
>>>I got too ambitious...
>>>
>>>http://jesseross.com/clients/gnustep/ui/concepts/06/camaelon_nesedah.png
>>>
>> One more suggestion? Give the deselected headers a gradient style
>>like the selected ones, so they still look clickable. However, keep
>>them in that darker shade.
>
>What do you think of the new version where the deselected headers
>look more like buttons, and the selected one is depressed?

Is there a newer one than #6? I'd still put a gradient on them, so
they look like a darker and thus down-pressed version of the
unselected ones. Having them flat when they're pressed IMHO doesn't
make it obvious that it's the same object.

--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

[Randi Joseph]

Hi Jesse,

Quick question. What the name of the font that you used in the first
mockups that you showed on discuss-gnustep?

[Jesse Ross]

> Hi Jesse,
>
> Quick question. What the name of the font that you used in the first
> mockups that you showed on discuss-gnustep?

Most of it was Veranda, 11pt. Veranda is just a repackaging of
Bitstream Vera Sans and is part of the Arkpandora font set. I think BSV
and Veranda are pretty much exactly the same. You can get Veranda (as
well as Tymes and Aerial) here :

http://www.users.bigpond.net.au/gavindi/


J.

[Narcoleptic Electron]

Jesse Ross wrote:
> I got too ambitious...
>
> http://jesseross.com/clients/gnustep/ui/concepts/06/camaelon_nesedah.png
>
> I reversed the tabs and the table headers so that the deselected ones
> look clickable.
>

Those tabs and headers are excellent in my opinion. It clearly
indicates what's clickable in a very consistent way. And it's
definitely unique.

I can see the point others have made about colour perspective issues
(foreground light, background dark). One solution that has been
suggested is to make the deselected tabs darker. I would argue
against this, because this would make them look inconsistent with
every other clickable item.

I think the solution, rather, is to put the deselected tabs in the
foreground. They look to be in the background now because they appear
"tucked behind" the selected tab, due to the curves. As such, I
suggest removing the inner curves, and only keeping the outer ones
(top left of Item 1 and top right of Item 3). This would have several
advantages:
- The deselected tabs would no longer looked "tucked behind" the selected tab.
- The entire tabbed area would have the shape of a window, thus
looking like a unit and adding consistency.
- The tabs would fit together perfectly, indicating that they work
together (selection of tabs being mutually exclusive). It also makes
them look a little less like buttons without losing the clickability
of the deselected tabs (due to the gradient and colour).

About the rounded scroller and slider: I think that rounded corners
are unnecessary, as the gradient already communicates the quality you
are going for. In fact, square corners remove the complexity of
tucking the rounded parts away when scrolling to the end, and they
make it crystal clear how far from the end of the trough the
scroller/slider is (user: am I supposed to measure from the end of the
curve, or the middle of the curve?). This is a usability issue.

I would, however, change sliders and scrollers to indicate in some way
that they are draggable. Perhaps you could give draggable items a
slightly darker hue. You could also give them a bigger shadow to
indicate that they float, making them look less "attached" to the
window and thus more draggable.

I want to emphsize that you have a fantastic design here and it keeps
getting better. This is an interesting discussion too -- nice to find
a bunch of people as interested in usability as I am.

[Narcoleptic Electron]

I wrote:
> I think the solution, rather, is to put the deselected tabs in the
> foreground. They look to be in the background now because they appear
> "tucked behind" the selected tab, due to the curves. As such, I
> suggest removing the inner curves, and only keeping the outer ones
> (top left of Item 1 and top right of Item 3). This would have several
> advantages:
> - The deselected tabs would no longer looked "tucked behind" the selected tab.
> - The entire tabbed area would have the shape of a window, thus
> looking like a unit and adding consistency.
> - The tabs would fit together perfectly, indicating that they work
> together (selection of tabs being mutually exclusive). It also makes
> them look a little less like buttons without losing the clickability
> of the deselected tabs (due to the gradient and colour).
>

To take this even further: when clicking a tab, it becomes depressed,
and the whole content area under the tab also appears depressed, at
the same level as the selected tab. This would make it incredibly
consistent with headers, and in fact would allow me to remove an
entire class from my UI element category list (Non-pinpoint clickable
control that doesn't depress or change state), simplifying it to the
following:

1. Clickable.  Two types:
  a) Mouse location within control matters.  Two types:
     i) Cursor appears at location (text box).
     ii) No cursor appears (scroll trough, slider trough).
  b) Mouse location doesn't matter.  Three types:
     i) Control depresses, then pops back up (button, table header).
     ii) Control depresses, and stays down (tab, check box, radio button).
2. Draggable.  Two types:
  a) Single draggable unit (scroll button, slider button).
  b) Attached to something else (window resize handle).

(Sorry for responding to my own message... I always get brainwaves
right after clicking "Send").

[Jesse Ross]

> I think the solution, rather, is to put the deselected tabs in the
> foreground. They look to be in the background now because they appear
> "tucked behind" the selected tab, due to the curves. As such, I
> suggest removing the inner curves, and only keeping the outer ones
> (top left of Item 1 and top right of Item 3). This would have several
> advantages:
> - The deselected tabs would no longer looked "tucked behind" the
> selected tab.
> - The entire tabbed area would have the shape of a window, thus
> looking like a unit and adding consistency.
> - The tabs would fit together perfectly, indicating that they work
> together (selection of tabs being mutually exclusive). It also makes
> them look a little less like buttons without losing the clickability
> of the deselected tabs (due to the gradient and colour).

We have two issues here -- making the current (selected) tab visually
distinct from the other tabs and attached to the tab container, and
keeping the UI internally consistent (clickable things all have similar
style).

In an earlier incarnation of this mockup <
http://jesseross.com/clients/gnustep/ui/concepts/02/
camaelon_nesedah.png >, we had tabs that were more square and fit
together more snugly, but it wasn't instantly apparent which tab was in
the foreground.

Nevertheless, here's a new version of the mockup where I've
incorporated (most of) your suggestions and made the selected tab
depressed like the table headers:

http://jesseross.com/clients/gnustep/ui/concepts/07/camaelon_nesedah.png

Uli, take a look at the selected headers -- is this more what you were
looking for?

> About the rounded scroller and slider: I think that rounded corners
> are unnecessary, as the gradient already communicates the quality you
> are going for. In fact, square corners remove the complexity of
> tucking the rounded parts away when scrolling to the end, and they
> make it crystal clear how far from the end of the trough the
> scroller/slider is (user: am I supposed to measure from the end of the
> curve, or the middle of the curve?). This is a usability issue.

This is a good point. Anyone else have an opinion on this? Should the
scroll bars be angled?

> I would, however, change sliders and scrollers to indicate in some way
> that they are draggable. Perhaps you could give draggable items a
> slightly darker hue. You could also give them a bigger shadow to
> indicate that they float, making them look less "attached" to the
> window and thus more draggable.

Drop shadows might be an issue, but I could try other options.

> I want to emphsize that you have a fantastic design here and it keeps
> getting better. This is an interesting discussion too -- nice to find
> a bunch of people as interested in usability as I am.

Thanks -- we hope you stick around!


J.

[M. Uli Kusterer]

At 11:01 Uhr -0600 06.03.2005, Jesse Ross wrote:
>Nevertheless, here's a new version of the mockup where I've
>incorporated (most of) your suggestions and made the selected tab
>depressed like the table headers:
>
>http://jesseross.com/clients/gnustep/ui/concepts/07/camaelon_nesedah.png
>
>Uli, take a look at the selected headers -- is this more what you
>were looking for?

Yes, perfect.

>>About the rounded scroller and slider: I think that rounded corners
>>are unnecessary, as the gradient already communicates the quality you
>>are going for. In fact, square corners remove the complexity of
>>tucking the rounded parts away when scrolling to the end, and they
>>make it crystal clear how far from the end of the trough the
>>scroller/slider is (user: am I supposed to measure from the end of the
>>curve, or the middle of the curve?). This is a usability issue.
>
>This is a good point. Anyone else have an opinion on this? Should
>the scroll bars be angled?

I think a very subtle angling should still be in there, but maybe
not as much as the rightmost one in my sample image. If we made it
rectangular, it'd start feeling like Apple's System 8.

>>I would, however, change sliders and scrollers to indicate in some way
>>that they are draggable. Perhaps you could give draggable items a
>>slightly darker hue. You could also give them a bigger shadow to
>>indicate that they float, making them look less "attached" to the
>>window and thus more draggable.
>
>Drop shadows might be an issue, but I could try other options.

Don't use color for this. Just use the little circular depression we
already have on scrollbar thumbs and on the split views. That's what
is for, after all, to indicate draggable surfaces.

As to the tab control: I have one *big* issue with this. While it
may look sensible from a highlight-consistentcy point of view, it
completely throws over board the metaphor (almost as badly as Apple's
10.3+ tab view). A tab view is supposed to be a stack of different
pages with tabs at the top, like you have them on a Rolodex.

The current color scheme completely breaks the physicality. It looks
like someone took a cookie-cutter and cut the frontmost tab out of
the others. If you ask me, I'd just go with the old color scheme. To
make the tabs look more clickable, just give the ones in the back a
gradient. After all, if you look at the current design, what all
clickable items seem to share is actually the gradients, not rounded
corners.

Which is analogous with the real world, where pushbuttons, by
nature, are usually characterized by being raised slightly and having
a strong outline.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

[Narcoleptic Electron]

M. Uli Kusterer wrote:
> At 11:01 Uhr -0600 06.03.2005, Jesse Ross wrote:
> >Uli, take a look at the selected headers -- is this more what you
> >were looking for?
>
> Yes, perfect.

I agree.

M. Uli Kusterer wrote:
> Don't use color for this. Just use the little circular depression we
> already have on scrollbar thumbs and on the split views. That's what
> is for, after all, to indicate draggable surfaces.

This would do the trick. Anything to indicate draggable stuff
uniquely and at a glance.

As such, I would suggest adding it to the slider and the window resizers.

M. Uli Kusterer wrote:
> As to the tab control: I have one *big* issue with this. While it
> may look sensible from a highlight-consistency point of view, it
> completely throws over board the metaphor (almost as badly as Apple's
> 10.3+ tab view). A tab view is supposed to be a stack of different
> pages with tabs at the top, like you have them on a Rolodex.

Yes, that is the traditional metaphor. I am questioning the utility
of that metaphor, if it comes at the expense of consistency and
learnability.

M. Uli Kusterer wrote:
> It looks
> like someone took a cookie-cutter and cut the frontmost tab out of
> the others.

Yes, the tab control isn't quite what I was thinking: I would remove
all curves except for the ones on the top-left corner of "Item 1", and
the top-right corner of "Item 3".

I think this change might address Uli's cookie-cutting concerns above.
Everything else about the tabs looks great to me.

M. Uli Kusterer wrote:
> If you ask me, I'd just go with the old color scheme. To
> make the tabs look more clickable, just give the ones in the back a
> gradient. After all, if you look at the current design, what all
> clickable items seem to share is actually the gradients, not rounded
> corners.

But it would be the opposite of the headers, in which the selected one
is the dark one. This would be very confusing... consider a tabbed
area with 2 tabs, next to a table with 2 headers. One tab and one
header are selected. It needs to be obvious to the user which tab,
and which header. If they are opposite, this will be a nightmare.

[M. Uli Kusterer]

At 17:32 Uhr -0500 06.03.2005, Narcoleptic Electron wrote:
>Yes, that is the traditional metaphor. I am questioning the utility
>of that metaphor, if it comes at the expense of consistency and
>learnability.

Consistency, maybe. But learnability? People already know tabs from
real life. Tell them it's a tab as in a rolodex or in a drawer of
hanging folders, and they'll say: "Yeah, I have those in my office."
They did the learning when they were maybe 10. Nothing new to learn
here.

>Yes, the tab control isn't quite what I was thinking: I would remove
>all curves except for the ones on the top-left corner of "Item 1", and
>the top-right corner of "Item 3".
>
>I think this change might address Uli's cookie-cutting concerns above.
> Everything else about the tabs looks great to me.

It wouldn't. My complaint was about color perspective, not about the
outside shapes of items. Those are fine to me. Moreover it would
annoy all those people who complained about the tabs not being
distinguishable enough a couple messages back.

>M. Uli Kusterer wrote:
> > If you ask me, I'd just go with the old color scheme. To
>> make the tabs look more clickable, just give the ones in the back a
>> gradient. After all, if you look at the current design, what all
>> clickable items seem to share is actually the gradients, not rounded
>> corners.
>
>But it would be the opposite of the headers, in which the selected one
>is the dark one. This would be very confusing... consider a tabbed
>area with 2 tabs, next to a table with 2 headers. One tab and one
>header are selected. It needs to be obvious to the user which tab,
>and which header. If they are opposite, this will be a nightmare.

Well, if it looked the way I imagine, the tab that comes out of the
"card" on which the controls sit is the current one. As long as those
two parts are the same color, it will be obvious. If the other tabs
clearly appear to be behind the active one, it'll be obvious which
one is active. And they would, since they are "cut off" from the card
(or partially covered by it) and they're darker and thus take
advantage of color perspective.

I can understand your idea of attempting to color-code selected and
unselected elements, but in this case doing that would open more
usability problems than it'd solve. It's perfectly okay to have this
use different colors, though, because there are real-world items that
look and behave similarly. And the whole point of a GUI is to take
advantage of the user's familiarity with real-world items and with
the brain's ability to navigate in three-dimensional space.

The table headers are like pushbuttons, where the ones that have
been pressed sink in and lock, like the buttons on some tape
recorders. On the other hand, the tab view looks like a rolodex,
where each of the small tabs is in reality a card with that tab
extending out of the top in a different spot so you can pull each one
out directly and put it on top instead of having to flip through them
sequentially.

So, in that case, it's entirely natural to have the frontmost one be
"on top" and thus be brighter than items in the back. If we achieve a
simulation of a physicality of real-world items, users won't see this
as "different colors". Rather, they'll see it as the same color, just
one being in front and under the lights, and the other being in back
and covered by shadow. If we can pull of that illusion, it'll work
fine this way, and the users won't even notice it's not 100% logical
or consistent by itself, because it's logical when compared to the
real world they interact with all day long.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

[MJ Ray]

http://jesseross.com/clients/gnustep/ui/concepts/05/camaelon_nesedah.png

I've been away for a bit. I've looked through the drawings and
I feel that 05 is the high point so far. I can appreciate the
points that you've reacted to in producing 06, but it does look
a bit odd to have selected column headers with *less* contrast
than the deselected ones.

Actually, after noticing that, I'm not comfortable with the
level of contrast on the darker headers at all. In 03 and 02,
it was a much darker background, although no text then. Have
you tried a full reverse on the selected headers? I guess that
doesn't work so well for the tabs, though.

I think the alternative approach of a reversed (so "inward bend")
gradient on the unselected tabs might be worth a look too.

--
I hope this is some help,

MJR/slef

[Alex Perez]

Jesse Ross wrote:
> I got too ambitious...
>
> http://jesseross.com/clients/gnustep/ui/concepts/06/camaelon_nesedah.png

muuuch better :)

Thanks a lot for your iterative toil!

Cheers,
Alex Perez

[Nicolas Roard]

Le 6 mars 05, à 04:19, Narcoleptic Electron a écrit :

> - Could the line in the slider button move within the button to
> indicate exactly where on the slider we are? For example, if the
> slider button is in the middle, the line is in the middle of the
> button. When all the way to the left, the line is on the left side of
> the button. This way, when you click the trough, the line goes right
> underneath the mouse, exactly.

hm, I don't really understand ?.. the line is always centered to the
actual value ?

>
> - Could the scroll button use the same line as the slider, as
> described above, instead of the dot?

sure; but the dot is a good reference to the NeXT UI, plus it looks
better (imho) and as anyway in a scrollbar you don't need a very
precise information of where you are, a line isn't really mandatory..
(still imho).

>
> - Could the slider use the trough, with arrow buttons, from the scroll
> bar? This would simplify the interface by removing redundant
> concepts, and allow fine-grained control of the slider via the arrow
> buttons. It would be obvious that it is not a scroll bar, because it
> isn't attached to the edge of a scroll view.

hmm.. it's an idea.. we can do it, but the control will perhaps be too
small for that in most uses ..

Thanks,

--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke

[Narcoleptic Electron]

Nicolas Roard wrote:
>
> Le 6 mars 05, à 04:19, Narcoleptic Electron a écrit :
>
> > - Could the line in the slider button move within the button to
> > indicate exactly where on the slider we are? For example, if the
> > slider button is in the middle, the line is in the middle of the
> > button. When all the way to the left, the line is on the left side of
> > the button. This way, when you click the trough, the line goes right
> > underneath the mouse, exactly.
>
> hm, I don't really understand ?.. the line is always centered to the
> actual value ?

Even when the scroll handle is at the end of the track?

Nicolas Roard wrote:
>
> Le 6 mars 05, à 04:19, Narcoleptic Electron a écrit :
>
> > - Could the scroll button use the same line as the slider, as
> > described above, instead of the dot?
>
> sure; but the dot is a good reference to the NeXT UI, plus it looks
> better (imho) and as anyway in a scrollbar you don't need a very
> precise information of where you are, a line isn't really mandatory..
> (still imho).

As Uli mentioned, the dot represents that the element is draggable.
However, the dot also does double-duty in a scroll handle or slider
handle (if used there): it also indicates scroll/slide position. And
for the slider handle, at least, it must do so with precision.

What about using an indented circle when no precision is required
(i.e. window resize handle, other resizers) and an indented arrowhead
when precision is required (i.e. scroller, slider), which would point
in the direction of the thing being scrolled or slid (i.e. scroll
view, slider ticks)? For example, for a vertical scroll bar, the
arrow head would point to the right.

Nicolas Roard wrote:
>
> Le 6 mars 05, à 04:19, Narcoleptic Electron a écrit :
>
> > - Could the slider use the trough, with arrow buttons, from the scroll
> > bar? This would simplify the interface by removing redundant
> > concepts, and allow fine-grained control of the slider via the arrow
> > buttons. It would be obvious that it is not a scroll bar, because it
> > isn't attached to the edge of a scroll view.
>
> hmm.. it's an idea.. we can do it, but the control will perhaps be too
> small for that in most uses ..

That argument doesn't really apply to the trough, which seems to have
no reason to be different between slider and scroller, but may apply
to the buttons.

However, the usability benefit of having buttons to control
fine-grained sliding may be worth fitting them in. Especially if the
slider is so small that it would be difficult to slide accurately.

[M. Uli Kusterer]

At 18:12 Uhr -0500 06.03.2005, Narcoleptic Electron wrote:
> > > - Could the slider use the trough, with arrow buttons, from the scroll
>> > bar? This would simplify the interface by removing redundant
>> > concepts, and allow fine-grained control of the slider via the arrow
>> > buttons. It would be obvious that it is not a scroll bar, because it
>> > isn't attached to the edge of a scroll view.
>>
>> hmm.. it's an idea.. we can do it, but the control will perhaps be too
>> small for that in most uses ..
>
>That argument doesn't really apply to the trough, which seems to have
>no reason to be different between slider and scroller, but may apply
>to the buttons.

There's one huge reason for the trough on a scroller looking
different than that of a slider: They're different objects for
different purpose. While their actual implementation in code is
nearly identical, they fulfill different purposes: A scroller is
there to let you change the visible part of an object, and indicate
how much and what you're looking at. Since a scroller indicates a
whole visible *area*, there is no point in showing a precise *point*
to which it is said right now.

OTOH, a slider is there for specifying one out of a continuous range
of values. I'm tempted to do sliders with a little "nose" to one
side, like some machines have them (and Aqua has that as well).

>However, the usability benefit of having buttons to control
>fine-grained sliding may be worth fitting them in. Especially if the
>slider is so small that it would be difficult to slide accurately.

Actually, in that case I'd rather suggest using a numeric input
field. There's nothing better for a precise number You can enter it
directly, instead of forcing users to use a visual representation.
Sliders are useful for getting a general impression of what values
cause what result (especially when they offer live feedback). Once
you have the general range, you'd rather want to be able to directly
access that value by typing it in. Up/down buttons on sliders are
just a workaround for cases where the slider doesn't have enough
resolution.

It's different on scrollers, where you often want to scroll down one
line (or equivalent unit), which is what the up/down arrows should do.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

[Nicolas Roard]

Le 6 mars 05, à 23:12, Narcoleptic Electron a écrit :

> Nicolas Roard wrote:
>>
>> Le 6 mars 05, à 04:19, Narcoleptic Electron a écrit :
>>
>>> - Could the line in the slider button move within the button to
>>> indicate exactly where on the slider we are? For example, if the
>>> slider button is in the middle, the line is in the middle of the
>>> button. When all the way to the left, the line is on the left side
>>> of
>>> the button. This way, when you click the trough, the line goes right
>>> underneath the mouse, exactly.
>>
>> hm, I don't really understand ?.. the line is always centered to the
>> actual value ?
>
> Even when the scroll handle is at the end of the track?

yes, because the tracks don't go as far. But even if that wasn't the
case,
a moving line would imho be bad, even if I understand your point.

> As Uli mentioned, the dot represents that the element is draggable.
> However, the dot also does double-duty in a scroll handle or slider
> handle (if used there): it also indicates scroll/slide position.

Well, the dot is generally used to significate a scrollable area --
it's also
used in the NSSplitView <for instance. You can say it indicates the
position,
but this is a rather unprecise indication in that case..

> And for the slider handle, at least, it must do so with precision.

hm.. no, I disagree. Most of the time you don't need an absolute
precision; a slider
is not a good widget to provides that.
You can have a range of discrete values rather than continuous values;
in that case
the slider will just "snap" (well, it doesn't do that for the moment,
but it should ;-)
If you want precision, in general you just add a textview on the side
-- so the user
can enter immediately its values, or fine-tune them.

>
> What about using an indented circle when no precision is required
> (i.e. window resize handle, other resizers) and an indented arrowhead
> when precision is required (i.e. scroller, slider), which would point
> in the direction of the thing being scrolled or slid (i.e. scroll
> view, slider ticks)? For example, for a vertical scroll bar, the
> arrow head would point to the right.

Well, why not.. but I disagree on the premise that a scrollbar and a
slider are used to provide precision -- that's really not the case..

> That argument doesn't really apply to the trough, which seems to have
> no reason to be different between slider and scroller, but may apply
> to the buttons.
>
> However, the usability benefit of having buttons to control
> fine-grained sliding may be worth fitting them in. Especially if the
> slider is so small that it would be difficult to slide accurately.

Well, I'm really not convainced about the accuracy argument -- if you
want accuracy, you use textfield to enter the correct values, you don't
want to click fifty time to reach the correct value. And moreover, you
need to display the value if precision is so important; in that case
why not using a textfield..

--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke

[Jesse Ross]

>>> hm, I don't really understand ?.. the line is always centered to the
>>> actual value ?
>>
>> Even when the scroll handle is at the end of the track?
>
> yes, because the tracks don't go as far. But even if that wasn't the
> case,
> a moving line would imho be bad, even if I understand your point.

Yep -- that's how I've designed them in the screenshot. You can't tell,
but just believe me. :)


Here's what I still see as outstanding issues/things that may still
change on the UI:

- The nightmare that has become tabs
- NSBrowser header (mostly it's just me who has a problem with it)
- Scrollbar: to angle or to round
- Slider: give it a "nose", leave it as is, or provide both

I, and most of the others on the list, seem to be happy with the table
headers, so they are now effectively frozen unless a lot of people give
me a really good reason to change them. I think we're also all in
agreement on the rest of the controls, so they will stay as is.

I've been doing a bunch of searching online for various tab
implementations, but everything pretty much sucks. Windows tabs are
typically all the same color, classic Mac tabs are similar to my
version 05 (with deselected tabs darkened), and OS X 10.3 tabs are
universally despised on the list. At this point, I'm about ready to go
back to version 05, but with deselected tab labels at 100% opacity, and
give all tabs a slight highlight and shadow. I don't think that having
the selected tab depressed is a good idea -- it looks odd visually. It
does make everything in the UI fit a standard metaphor, but it just
looks wrong. I'm willing to try anyone's suggestion for the tabs,
though. If it takes a hundred iterations, so be it.

I'm really not angry... this is the most fun I've had in a while ;)


J.

[Rob Burns]

On 2005-03-07 09:49:37 +0700 Jesse Ross <***@jesseross.com> wrote:

> I've been doing a bunch of searching online for various tab
> implementations,
> but everything pretty much sucks. Windows tabs are typically all the
> same
> color, classic Mac tabs are similar to my version 05 (with deselected
> tabs
> darkened), and OS X 10.3 tabs are universally despised on the list.
> At this
> point, I'm about ready to go back to version 05, but with deselected
> tab
> labels at 100% opacity, and give all tabs a slight highlight and
> shadow. I
> don't think that having the selected tab depressed is a good idea --
> it looks
> odd visually. It does make everything in the UI fit a standard
> metaphor, but
> it just looks wrong. I'm willing to try anyone's suggestion for the
> tabs,
> though. If it takes a hundred iterations, so be it.
>

why don't you start with the tabs here:
http://www.roard.com/screenshots/screenshot_theme44.png and determine
what could be improved. I think that if the tabs increased in width to
fill the top of the tabview regardless of the number of tabs, it would
be a good thing, but other than that, I think those are pretty nice.
maybe more contrast?

Rob

[Jesse Ross]

Version 08, with the modified 05 implementation I discussed in the last
email, and with the slider with a "nose":

http://jesseross.com/clients/gnustep/ui/concepts/08/camaelon_nesedah.png

I don't like how the table header and tabs use different metaphors, but
I also don't think that it makes sense for the tabs to be depressed.
Argh. I'm open to suggestions.


J.

[Narcoleptic Electron]

Jesse Ross wrote:
> Version 08, with the modified 05 implementation I discussed in the last
> email, and with the slider with a "nose":
>
> http://jesseross.com/clients/gnustep/ui/concepts/08/camaelon_nesedah.png
>
> I don't like how the table header and tabs use different metaphors, but
> I also don't think that it makes sense for the tabs to be depressed.
> Argh. I'm open to suggestions.

I think if you remove the gradient from the selected tab (to show that
it's not clickable), I think consistency issues would be solved.

To summarize the remainder of my suggestions:
- Replace lines on slider handles with dots.
- Make troughs on sliders wider (i.e. as wide as the handle, minus the
arrow) to create a larger click target.
- Blacker blacks; specifically text and arrow heads. Looks a little
"soft" rather than "crisp".
- The "full" part of the status indicator shouldn't have a gradient;
it isn't clickable. Maybe make it the colour of a deselected tab,
minus the gradient, as there seem to be too many different greys.

P.S. About the detached scroller: is there ever a situation in which a
scroller shouldn't be attached to a scroll view?

[Narcoleptic Electron]

I wrote:
> To summarize the remainder of my suggestions:
> - Replace lines on slider handles with dots.
> - Make troughs on sliders wider (i.e. as wide as the handle, minus the
> arrow) to create a larger click target.
> - Blacker blacks; specifically text and arrow heads. Looks a little
> "soft" rather than "crisp".
> - The "full" part of the status indicator shouldn't have a gradient;
> it isn't clickable. Maybe make it the colour of a deselected tab,
> minus the gradient, as there seem to be too many different greys.

Sorry: a couple more:
- A trough without a slider in it shouldn't have a gradient either...
not clickable.
- I liked the tabs better without the extra curves at the bottom, and
still think they would look best with only 2 curves: on the top-left
of "Item 1" and top right of "Item 3".

I will try to resist pestering the list further. I just really enjoy
hashing out the interface. Thanks for listening to an outsider.

[Quentin Mathé]

Le 7 mars 05, à 05:45, Narcoleptic Electron a écrit :

> - A trough without a slider in it shouldn't have a gradient either...
> not clickable.

May be, but ultimate consistency isn't always the best, that's was
precisely the NeXT UI problem inho : too much consistency then less
readability and efficiency in some way too.

When you are using a very limited of concepts, you obtain a very
powerful and evolved conceptual model but it's not always convenient;
when you add extra concepts, the behavior could look less united (or
logical) but could imply faster recognition on the user side (because
UI concepts become probably structured/related in less hierarchical way
or self referencing way)…

That's a problem we encounter everyday in various stuff, I mean not
specific to UI :-)

> - I liked the tabs better without the extra curves at the bottom, and
> still think they would look best with only 2 curves: on the top-left
> of "Item 1" and top right of "Item 3".

What's the extra curves at the bottom ?

Quentin.

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

[Jesse Ross]

On Mar 8, 2005, at 3:34 AM, Quentin Mathé wrote:

> Le 7 mars 05, à 05:45, Narcoleptic Electron a écrit :
>
>> - A trough without a slider in it shouldn't have a gradient either...
>> not clickable.
>
> May be, but ultimate consistency isn't always the best, that's was
> precisely the NeXT UI problem inho : too much consistency then less
> readability and efficiency in some way too.

Keeping the gradient in the scroll trough solves two problems and
introduces one.

The problem in introduces is overall UI consistency: gradients in this
UI typically imply that something is clickable.

Where it is a good solution, though, is that it keeps the widget
internally consistent: a scroll trough is a scroll trough, whether or
not there's something in it, and since clicking within it when there is
a scroll bar provides a useful action, it should have a gradient. The
additional solution it provides is visual depth: the trough shadow goes
opposite the shadow on the scroll bar, thus indicating that the trough
is "carved into" the window and behind the scroller.

> When you are using a very limited of concepts, you obtain a very
> powerful and evolved conceptual model but it's not always convenient;
> when you add extra concepts, the behavior could look less united (or
> logical) but could imply faster recognition on the user side (because
> UI concepts become probably structured/related in less hierarchical
> way or self referencing way)…
>
> That's a problem we encounter everyday in various stuff, I mean not
> specific to UI :-)
>
>> - I liked the tabs better without the extra curves at the bottom, and
>> still think they would look best with only 2 curves: on the top-left
>> of "Item 1" and top right of "Item 3".
>
> What's the extra curves at the bottom ?

The ones that overlap tabs 1 and 3 -- he would like it to look more
like the tabs' shapes on this version:

http://jesseross.com/clients/gnustep/ui/concepts/07/camaelon_nesedah.png


J.

[Quentin Mathé]

Le 7 mars 05, à 05:40, Narcoleptic Electron a écrit :

> I think if you remove the gradient from the selected tab (to show that
> it's not clickable), I think consistency issues would be solved.

Yep, it would be an acceptable consistency break when you take in
account nobody has found a better solution for tabs within the last
decade.

> To summarize the remainder of my suggestions:
> - Replace lines on slider handles with dots.

Nice idea I think.

> - The "full" part of the status indicator shouldn't have a gradient;
> it isn't clickable. Maybe make it the colour of a deselected tab,
> minus the gradient, as there seem to be too many different greys.

What do you mean by "status indicator" ?

> P.S. About the detached scroller: is there ever a situation in which a
> scroller shouldn't be attached to a scroll view?

For NSBrowser, however Apple avoids spaces between NSBrowser parts
unlike GNUstep, I have no opinion on what's better.

Quentin.

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

[Narcoleptic Electron]

Nicolas Roard wrote:
> yes, because the tracks don't go as far. But even if that wasn't the
> case,
> a moving line would imho be bad, even if I understand your point.

Since reading the responses, and after thinking some more about my
moving line/arrowhead idea for the scroll handle, I've been convinced
that it's a dumb idea. An indented circle on a scroll handle is good.

However, I still hold that it should go on the slider handle and
window resize handles as well to indicate that they're draggable.

Nicolas Roard wrote:
> but I disagree on the premise that a scrollbar and a
> slider are used to provide precision -- that's really not the case..

Not for a scrollbar, but definitely for a slider. See further response below...

Nicolas Roard wrote:
> Well, I'm really not convainced about the accuracy argument -- if you
> want accuracy, you use textfield to enter the correct values,

A numeric value doesn't always naturally apply to a slider range. For
example, in the Dock preference pane in OS X, there is a slider for
Dock Size and one for Magnification. Any numerical range added for
any of these would be completely artificial. What would the numbers
be, other than conceptual clutter in the interface?

I tend to think that forcing the user to enter values by the keyboard
is a bit of a UI hack. And I think that forcing the user to do a very
fine-grained drag to get the slider to exactly the position they want
scores very low for accessibility.

Nicolas Roard wrote:
> you don't
> want to click fifty time to reach the correct value.

Almost every time I use a slider on Windows, I first drag it to the
general area I want, or click the general area in the trough, then
need to resort to holding down my left mouse button and "nudging" it
with the arrow keys on the keyboard. No fifty clicks required.

OS X provides no way to do this, by the way: I must drag exactly to
the position I want, fine motor skills be damned.

Arrow buttons would be very handy in this case; this would be far more
discoverable than the Windows arrow-keyboard-key approach.

Nicolas Roard wrote:
> And moreover, you
> need to display the value if precision is so important; in that case
> why not using a textfield..

Or just use a text-based interface altogether and forget about this
GUI stuff. ;-)

[M. Uli Kusterer]

At 23:00 Uhr -0500 06.03.2005, Narcoleptic Electron wrote:
>Nicolas Roard wrote:
>> Well, I'm really not convainced about the accuracy argument -- if you
>> want accuracy, you use textfield to enter the correct values,
>
>A numeric value doesn't always naturally apply to a slider range. For
>example, in the Dock preference pane in OS X, there is a slider for
>Dock Size and one for Magnification. Any numerical range added for
>any of these would be completely artificial. What would the numbers
>be, other than conceptual clutter in the interface?
>
>I tend to think that forcing the user to enter values by the keyboard
>is a bit of a UI hack. And I think that forcing the user to do a very
>fine-grained drag to get the slider to exactly the position they want
>scores very low for accessibility.

Exactly. Which is why it is not good for fine-grained numeric input
at all. Sliders are good for picking between few choices. If you have
too fine-grained a range, sliders can be used to make it easier to
get in the general range of a value, but that's as far as it should
go.

>Nicolas Roard wrote:
>> you don't
>> want to click fifty time to reach the correct value.
>
>Almost every time I use a slider on Windows, I first drag it to the
>general area I want, or click the general area in the trough, then
>need to resort to holding down my left mouse button and "nudging" it
>with the arrow keys on the keyboard. No fifty clicks required.
>
>OS X provides no way to do this, by the way: I must drag exactly to
>the position I want, fine motor skills be damned.
>
>Arrow buttons would be very handy in this case; this would be far more
>discoverable than the Windows arrow-keyboard-key approach.

IMHO the Windows arrow-key approach is:

a) a holdover from Windows' keyboard-centric heritage, newly
legitimized by Section 508 (the US's disability-support law)
b) bad UI design that's being used by people smart enough to work
around UI bugs

Your use case above demonstrates how bad the current sliders are
when it comes to entering fine grained values. If it's numbers, a
text field or a custom view that displays a ruler and allows you to
zoom in is a much better choice to enter precise values, depending on
how important these precise values are to you. Moreover, in this case
often people will already have the number in their heads, or as a
result in the calculator, so allowing them to copy/paste it into a
text field of similar is a much better choice.

If you have so many non-numeric choices that you need more
precision, you're using the wrong control. Either use direct
manipulation (e.g. if you drag along the separator in the Mac's dock,
you can directly resize the icons until they're the size you want),
or a list box of options, or maybe even an outline view that helps
you cut down on the complexity of the list of options.

Or (but this can be dangerous if done needlessly) try to find a way
to reduce these hundreds of options into a few smaller,
interdependent options, and have separate sliders for their smaller
ranges. But in many cases, when you have large numbers of options,
the question should be: Do people really need all of this
flexibility, or would the user be served better by just providing
those options that don't conflict, or those that are actually used in
practice. There are enough apps that tell you all their life's story
even though you needn't know it. (If you want to know more about
this, read: http://www.zathras.de/angelweb/x2005-03-07b.htm)

>Nicolas Roard wrote:
>> And moreover, you
>> need to display the value if precision is so important; in that case
>> why not using a textfield..
>
>Or just use a text-based interface altogether and forget about this
>GUI stuff. ;-)

True. In that case, I'd want my scrollbar to look thus:

+---+---+--------+-------------------+-----+
| < | > |%%%%%%%%| o |%%%%%|
+---+---+--------+-------------------+-----+

:-)
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

[Alex Perez]

M. Uli Kusterer wrote:
> At 23:00 Uhr -0500 06.03.2005, Narcoleptic Electron wrote:
>
>> Nicolas Roard wrote:
>>
>>> Well, I'm really not convainced about the accuracy argument -- if you
>>> want accuracy, you use textfield to enter the correct values,
>>
>>
>> A numeric value doesn't always naturally apply to a slider range. For
>> example, in the Dock preference pane in OS X, there is a slider for
>> Dock Size and one for Magnification. Any numerical range added for
>> any of these would be completely artificial. What would the numbers
>> be, other than conceptual clutter in the interface?
>>
>> I tend to think that forcing the user to enter values by the keyboard
>> is a bit of a UI hack. And I think that forcing the user to do a very
>> fine-grained drag to get the slider to exactly the position they want
>> scores very low for accessibility.
>
>
> Exactly. Which is why it is not good for fine-grained numeric input at
> all. Sliders are good for picking between few choices. If you have too
> fine-grained a range, sliders can be used to make it easier to get in
> the general range of a value, but that's as far as it should go.
>
>> Nicolas Roard wrote:
>>
>>> you don't
>>> want to click fifty time to reach the correct value.
>>
>>
>> Almost every time I use a slider on Windows, I first drag it to the
>> general area I want, or click the general area in the trough, then
>> need to resort to holding down my left mouse button and "nudging" it
>> with the arrow keys on the keyboard. No fifty clicks required.
>>
>> OS X provides no way to do this, by the way: I must drag exactly to
>> the position I want, fine motor skills be damned.
>>
>> Arrow buttons would be very handy in this case; this would be far more
>> discoverable than the Windows arrow-keyboard-key approach.
>
>
> IMHO the Windows arrow-key approach is:
>
> a) a holdover from Windows' keyboard-centric heritage, newly legitimized
> by Section 508 (the US's disability-support law)
This is important if you happen to not have a second hand, or even a
first, or dozens of other serious disabilities.

> b) bad UI design that's being used by people smart enough to work around
> UI bugs
Just because you do not feel that keyboard navigability does not have
inherent value (OS X has a fully keyboard-navigable mode, which must be
explicitly turned on, which I use because it's the only way to enable
tabbing through all visual elements, which is extremely convenient and
saves me tons of time) does not mean that it is not valuable to others.
You're crossing a fine line when you claim something is "bad UI design"
just because you happen to disagree with it. As the sticker on my
comparative religion professors' office door said, 'People often confuse
"the thought crossed my mind" with "because God said so"'.
>
> Your use case above demonstrates how bad the current sliders are when
> it comes to entering fine grained values. If it's numbers, a text field
> or a custom view that displays a ruler and allows you to zoom in is a
> much better choice to enter precise values, depending on how important
> these precise values are to you. Moreover, in this case often people
> will already have the number in their heads, or as a result in the
> calculator, so allowing them to copy/paste it into a text field of
> similar is a much better choice.
I agree. The correct way is to have a text field, which is tied to the
slider so either effects the other.
>
> If you have so many non-numeric choices that you need more precision,
> you're using the wrong control. Either use direct manipulation (e.g. if
> you drag along the separator in the Mac's dock, you can directly resize
> the icons until they're the size you want), or a list box of options, or
> maybe even an outline view that helps you cut down on the complexity of
> the list of options.
>
> Or (but this can be dangerous if done needlessly) try to find a way to
> reduce these hundreds of options into a few smaller, interdependent
> options, and have separate sliders for their smaller ranges. But in many
> cases, when you have large numbers of options, the question should be:
> Do people really need all of this flexibility, or would the user be
> served better by just providing those options that don't conflict, or
> those that are actually used in practice. There are enough apps that
> tell you all their life's story even though you needn't know it. (If you
> want to know more about this, read:
> http://www.zathras.de/angelweb/x2005-03-07b.htm)
>
>> Nicolas Roard wrote:
>>
>>> And moreover, you
>>> need to display the value if precision is so important; in that case
>>> why not using a textfield..
>>
>>
>> Or just use a text-based interface altogether and forget about this
>> GUI stuff. ;-)
>
>
> True. In that case, I'd want my scrollbar to look thus:
>
> +---+---+--------+-------------------+-----+
> | < | > |%%%%%%%%| o |%%%%%|
> +---+---+--------+-------------------+-----+
>
> :-)

ehehe ;-)

Cheers,
Alex Perez

[Narcoleptic Electron]

M. Uli Kusterer wrote:
> IMHO the Windows arrow-key approach is:
>
> a) a holdover from Windows' keyboard-centric heritage, newly
> legitimized by Section 508 (the US's disability-support law)
> b) bad UI design that's being used by people smart enough to work
> around UI bugs
>
> Your use case above demonstrates how bad the current sliders are
> when it comes to entering fine grained values.

I agree that the Windows approach is a flawed solution to the problem.

M. Uli Kusterer wrote:
> Exactly. Which is why it is not good for fine-grained numeric input
> at all. Sliders are good for picking between few choices. If you have
> too fine-grained a range, sliders can be used to make it easier to
> get in the general range of a value, but that's as far as it should
> go.

But some people lack the ability to drag with any precision at all;
getting the slider even within the general range of a value may be
difficult for some.

What my argument really boils down to is this: why do scrollers have
arrow buttons, and not sliders? It seems to me that the reason
scrollers have them is to allow for another means of scrolling that
doesn't require dragging with any precision (eg. within a centimetre).
Why should the same courtesy not be extended for sliders? This is
something that has bothered me about sliders, in every implementation
I've seen, for a long time.

It seems that if there is a reason for scrollers to have arrow
buttons, the same reason would apply to sliders. And if not, neither
should have them.

M. Uli Kusterer wrote:
> read: http://www.zathras.de/angelweb/x2005-03-07b.htm)

Great website.

M. Uli Kusterer wrote:
> True. In that case, I'd want my scrollbar to look thus:
>
> +---+---+--------+-------------------+-----+
> | < | > |%%%%%%%%| o |%%%%%|
> +---+---+--------+-------------------+-----+
>
> :-)

I think the arrow buttons need some sort of text-based gradient... :-o

[M. Uli Kusterer]

At 12:57 Uhr -0500 07.03.2005, Narcoleptic Electron wrote:
>But some people lack the ability to drag with any precision at all;
>getting the slider even within the general range of a value may be
>difficult for some.

If you can't drag with any precision, you fall into the area of
disabilities. In that case, you'd *need* the built-in disability
support, even if we had the arrows.

>What my argument really boils down to is this: why do scrollers have
>arrow buttons, and not sliders? It seems to me that the reason
>scrollers have them is to allow for another means of scrolling that
>doesn't require dragging with any precision

Scrollers have arrows to support the common use case of e.g. a text
field, where you type into it and then want to go down one line. If
you look at most OSs, the scroll arrows don't provide for
pixel-precise scrolling. They usually scroll by one line at a time.

There are other behavioral differences in scrollers and sliders that
support this: when you click in the trough or track of a scroller, it
will usually scroll down one "page" (i.e. by the height of the
visible area), while clicking a slider's through will cause the knob
to jump to that position.

The reasoning behind this is that scrollers are intended to view
something in small steps, to read through text and see each screenful
*in sequence*, while a slider is much more a direct-access data entry
device. In a good UI, there's never a need to see each value of a
slider in sequence. Rather, you just drag, or point and click. If you
ever have a situation where you need to

>(eg. within a centimetre).
> Why should the same courtesy not be extended for sliders? This is
>something that has bothered me about sliders, in every implementation
>I've seen, for a long time.
>
>It seems that if there is a reason for scrollers to have arrow
>buttons, the same reason would apply to sliders. And if not, neither
>should have them.

Does my explanation above make my reasoning clearer?

--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

[Narcoleptic Electron]

M. Uli Kusterer wrote:
> Scrollers have arrows to support the common use case of e.g. a text
> field, where you type into it and then want to go down one line. If
> you look at most OSs, the scroll arrows don't provide for
> pixel-precise scrolling. They usually scroll by one line at a time.

Yes, vertical scrollers attached to text controls do this, because
that is the minimum amount of vertical movement for the cursor within.
But what about scrollers for controls that contain no cursor? How
much do they scroll per arrow button press? (I would check, but I
haven't installed GNUstep yet; that is the subject of another
thread...)

M. Uli Kusterer wrote:
> There are other behavioral differences in scrollers and sliders that
> support this: when you click in the trough or track of a scroller, it
> will usually scroll down one "page" (i.e. by the height of the
> visible area), while clicking a slider's through will cause the knob
> to jump to that position.

I thought that in GNUstep, clicking the trough brought the scroll
handle there, just like in the slider.

If this isn't the case, I think it should be. I always set OS X to
use this behaviour. It is much more predictable than the alternative,
which changes depending on the control, and I'm a firm believer in the
Principle of Least Astonishment.

M. Uli Kusterer wrote:
> The reasoning behind this is that scrollers are intended to view
> something in small steps, to read through text and see each screenful
> *in sequence*, while a slider is much more a direct-access data entry
> device. In a good UI, there's never a need to see each value of a
> slider in sequence. Rather, you just drag, or point and click. If you
> ever have a situation where you need to

...to what? Don't leave me hanging!

M. Uli Kusterer wrote:
> Does my explanation above make my reasoning clearer?

Your opinion is well informed and thought out, and has caused me to
re-evaluate my own opinion (a little). And I'm learning a lot about
the GNUstep UI rationale.

[M. Uli Kusterer]

At 16:05 Uhr -0500 07.03.2005, Narcoleptic Electron wrote:
>Yes, vertical scrollers attached to text controls do this, because
>that is the minimum amount of vertical movement for the cursor within.
> But what about scrollers for controls that contain no cursor? How
>much do they scroll per arrow button press? (I would check, but I
>haven't installed GNUstep yet; that is the subject of another
>thread...)

Well, I can only talk OS X here, and there it depends on the
developer. Text fields usually scroll in line intervals. For other
contents it depends on what the developers did. Some just make it
scroll pixel-wise, but in well-rounded apps, it's the height of a
table row, or whatever unit makes sense for what's being scrolled.

>M. Uli Kusterer wrote:
> > There are other behavioral differences in scrollers and sliders that
>> support this: when you click in the trough or track of a scroller, it
>> will usually scroll down one "page" (i.e. by the height of the
>> visible area), while clicking a slider's through will cause the knob
>> to jump to that position.
>
>I thought that in GNUstep, clicking the trough brought the scroll
>handle there, just like in the slider.
>
>If this isn't the case, I think it should be. I always set OS X to
>use this behaviour. It is much more predictable than the alternative,
>which changes depending on the control, and I'm a firm believer in the
>Principle of Least Astonishment.

Is there really a difference in astonishment in the two? In the real
world, only when you actually grab an object and move it, it changes
position. So, that the thumb (or "scroll handle") moves at all when
you click the trough is astonishing in and of itself. Same applies to
real-world sliders.

Now, since I can personally already achieve the result of getting
the thumb into a certain position by grabbing and dragging it, I
personally don't see much advantage. OTOH, the page up/down
functionality provides a tangible advantage.

>M. Uli Kusterer wrote:
>> The reasoning behind this is that scrollers are intended to view
>> something in small steps, to read through text and see each screenful
>> *in sequence*, while a slider is much more a direct-access data entry
>> device. In a good UI, there's never a need to see each value of a
>> slider in sequence. Rather, you just drag, or point and click. If you
>> ever have a situation where you need to
>
>...to what? Don't leave me hanging!

Sorry, must have accidentally deleted part of the message:

If you ever have a situation where you need to see all slider values
in sequence, it's very likely that the developer's using the slider
for the wrong purpose. So, IMHO the reason for there being arrows on
the scroller but not on the slider is that the former is designed for
sequential access as the main metaphor, while sliders are designed
for direct access mainly.

Both aren't designed for much precision. They're designed for
letting users give the computer a number in the right ballpark
instead of having to type in exact percentages when all they want is
to get near where they left off. Remember, the computer always
"thinks" in numbers, but humans actually usually think in much more
vague terms, which are okay in most cases.

>And I'm learning a lot about
>the GNUstep UI rationale.

Note that It's been ages since I've even seen a NeXT box (I tried
out GNUstep, but for various reasons I couldn't make it work on my
computer), and many things tend to blend into each other, so what I'm
saying is "my UI rationale", not that of the GNUstep project. I'm
fairly new to this project myself.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

[Frederic Stark]

2 cents:

> What my argument really boils down to is this: why do scrollers have
> arrow buttons, and not sliders? It seems to me that the reason
> scrollers have them is to allow for another means of scrolling that
> doesn't require dragging with any precision (eg. within a centimetre).

No. The arrow means scrolling one line at a time.

A scroller adjust the visible part of a view. You can move one page, or
one line.

Such concepts don't apply to sliders.

Scrollers also have the possiblity to scroll a full page (in NeXTstep
you could scroll one page at a time by alt-clicking, IIRC. I think this
behavior have been lost in Mac OS X).

A behavior that have not been lost in Mac OS X, is the possibility of
smooth scrollbar adjustment by alt-dragging the thumb. This is not
present on sliders, for reasons I fail to understand.

> Why should the same courtesy not be extended for sliders? This is
> something that has bothered me about sliders, in every implementation
> I've seen, for a long time.

Cheers,

--fred

[Frederic Stark]

> Scrollers also have the possiblity to scroll a full page (in NeXTstep
> you could scroll one page at a time by alt-clicking, IIRC. I think this
> behavior have been lost in Mac OS X).

Oops. Just checked. The behavior is still here. Alt-clicking in the
empty space or in the line buttons will scroll by a full page.

Cheers,

--fred

[Alex Perez]

Narcoleptic Electron wrote:
> Nicolas Roard wrote:
>
>>Well, I'm really not convainced about the accuracy argument -- if you
>>want accuracy, you use textfield to enter the correct values,
>
>
> A numeric value doesn't always naturally apply to a slider range. For
> example, in the Dock preference pane in OS X, there is a slider for
> Dock Size and one for Magnification. Any numerical range added for
> any of these would be completely artificial. What would the numbers
> be, other than conceptual clutter in the interface?
Uh, they'd be pixel size (up to 128, presumably) and the magnification
factor. This seems obvious to me.

Alex Perez

[Narcoleptic Electron]

Alex Perez wrote:
> Uh, they'd be pixel size (up to 128, presumably)

I assume you mean number of points.

Alex Perez wrote:
> and the magnification
> factor. This seems obvious to me.

Yes, this was a bad example... they were the first sliders I found.
But there are sliders out there for which exposing the underlying
number to the user would only add useless clutter to the interface.

[Jesse Ross]

Sorry I've been out all day... crazy day.

Anyways, here's the latest version:

http://jesseross.com/clients/gnustep/ui/concepts/09/camaelon_nesedah.png

I think using the circular notch to indicate draggability is a smart
idea. In the current GNUstep interface, it is not obvious that the
corners or bottom of the window are draggable (in fact, it took someone
on the list mentioning to me that the whole middle section of the
window could be pulled to make the window taller). Using the notches
makes that symbol have special meaning over the whole of the UI.

I also think I've discovered the problem of how to make the table
headers indicate which is the selected.

If you were to look at (to use a test by Narcoleptic Electron) a tab
interface with only two tabs, and a table header with only two headers,
how would you know which was selected? On the tabs, we have two
"hints": the real world and our ability to see and think in three
dimensions. The real world tells us that the current tab we're looking
at is the one that has the contents we want; thus, we can see that the
body of the tab is attached to the lighter tab, and because the tab's
body contains the elements that we're looking at, it must be selected.
Additionally, because that tab looks to be in front of the other tabs
(through overlapping), we have another cue that it is the currently
selected tab.

With table headers, it's a bit more difficult. We don't really have a
real world analogy, so we have to use the visual cues in the rest of
the interface. Assuming there are only two tabs, the selected one will
have to be "extra" different. Color differentiation between the two
tells us nothing (if you saw the OS X table headers for the first time,
before anything else on the interface, how would you not know that the
blue headers weren't the deselected tabs?) I think (or hope) that it is
safe to assume clicking on a table header will both select and _sort_
that column. The sorting is the key here. Sorting can either be
ascending or descending, thus we need some indicator of the direction
the column is being sorted. Since, logically, we can only be looking at
a table with one _primary_ sort column, that is our hint. The sorting
icon tells us which is the selected column. It's maybe not the most
obvious hint, but it's a hint that's easily learned and that is
logical.

Also, selected table headers should still be somewhat button-like,
since you can click on them again to sort in the opposite direction.


Okay, my hard work for the day is done... I will start gathering my
fire extinguishers...


J.

[Nicolas Roard]

Le 8 mars 05, à 05:34, Jesse Ross a écrit :

> Sorry I've been out all day... crazy day.
>
> Anyways, here's the latest version:
>
> http://jesseross.com/clients/gnustep/ui/concepts/09/
> camaelon_nesedah.png

Looks better every day ;-)

>
> I think using the circular notch to indicate draggability is a smart
> idea. In the current GNUstep interface, it is not obvious that the
> corners or bottom of the window are draggable (in fact, it took
> someone on the list mentioning to me that the whole middle section of
> the window could be pulled to make the window taller). Using the
> notches makes that symbol have special meaning over the whole of the
> UI.

agree, it's quite ok..
For the sliders, the "nosed" buttons are ok, but we need both --
"nosed" and normal buttons ! (like Aqua should I say). "nosed" buttons
are useful when you have discrete values; normal buttons are useful
when you don't really care and it's more continuous values, imho.

>
> I also think I've discovered the problem of how to make the table
> headers indicate which is the selected.
>
> If you were to look at (to use a test by Narcoleptic Electron) a tab
> interface with only two tabs, and a table header with only two
> headers, how would you know which was selected? On the tabs, we have
> two "hints": the real world and our ability to see and think in three
> dimensions. The real world tells us that the current tab we're looking
> at is the one that has the contents we want; thus, we can see that the
> body of the tab is attached to the lighter tab, and because the tab's
> body contains the elements that we're looking at, it must be selected.
> Additionally, because that tab looks to be in front of the other tabs
> (through overlapping), we have another cue that it is the currently
> selected tab.

The actual tabs looks fine for me.. As you say, we can easily infers
which tab is selected because the analogy helps here -- it's the one
presenting us with the whole content, obviously, regardless of its
color.

>
> With table headers, it's a bit more difficult. We don't really have a
> real world analogy, so we have to use the visual cues in the rest of
> the interface. Assuming there are only two tabs, the selected one will
> have to be "extra" different. Color differentiation between the two
> tells us nothing (if you saw the OS X table headers for the first
> time, before anything else on the interface, how would you not know
> that the blue headers weren't the deselected tabs?) I think (or hope)
> that it is safe to assume clicking on a table header will both select
> and _sort_ that column. The sorting is the key here. Sorting can
> either be ascending or descending, thus we need some indicator of the
> direction the column is being sorted. Since, logically, we can only be
> looking at a table with one _primary_ sort column, that is our hint.
> The sorting icon tells us which is the selected column. It's maybe not
> the most obvious hint, but it's a hint that's easily learned and that
> is logical.
>
> Also, selected table headers should still be somewhat button-like,
> since you can click on them again to sort in the opposite direction.

that looks ok for me, indeed.

>
>
> Okay, my hard work for the day is done... I will start gathering my
> fire extinguishers...

:-)

--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke

[Jesse Ross]

> For the sliders, the "nosed" buttons are ok, but we need both --
> "nosed" and normal buttons ! (like Aqua should I say). "nosed" buttons
> are useful when you have discrete values; normal buttons are useful
> when you don't really care and it's more continuous values, imho.

Fixed!

http://jesseross.com/clients/gnustep/ui/concepts/10/camaelon_nesedah.png


J.

[Jesse Ross]

> hi,
>
> would it be possible to put all designs on a single page so one can
> compare them?

Yep -- here you go:

http://jesseross.com/clients/gnustep/ui/concepts/


J.


> thanks,
>
> stefan

[Narcoleptic Electron]

M. Uli Kusterer wrote:
> There's one huge reason for the trough on a scroller looking
> different than that of a slider: They're different objects for
> different purpose. While their actual implementation in code is
> nearly identical, they fulfill different purposes: A scroller is
> there to let you change the visible part of an object, and indicate
> how much and what you're looking at. Since a scroller indicates a
> whole visible *area*, there is no point in showing a precise *point*
> to which it is said right now.
>
> OTOH, a slider is there for specifying one out of a continuous range
> of values.

I realize all of that. I'm looking at all of this from a lower level,
purely from a "how can my mouse interact with this interface"
perspective: "Can I drag this thing? Can I click this thing? If I
click this, what will happen?"

In that sense, the slider and scroller have the following in common:
- There is a handle that can be dragged within the trough.
- There is a trough that can be clicked, which brings the handle to
the click location.

>From this standpoint, the slider and the scroller are identical.

As far as the differences you describe, these are already clear from
the context: if the slider/scroller is in the middle of a dialog, it's
a slider, whereas if it's attached to a scroll view, it's a scroller.

M. Uli Kusterer wrote:
> I'm tempted to do sliders with a little "nose" to one
> side, like some machines have them (and Aqua has that as well).

Sounds cool to me. They should contain a drag dot as well, though.

> Actually, in that case I'd rather suggest using a numeric input
> field. There's nothing better for a precise number You can enter it
> directly, instead of forcing users to use a visual representation.
> Sliders are useful for getting a general impression of what values
> cause what result (especially when they offer live feedback). Once
> you have the general range, you'd rather want to be able to directly
> access that value by typing it in. Up/down buttons on sliders are
> just a workaround for cases where the slider doesn't have enough
> resolution.

See my previous response to Nicolas Roard about this.

[M. Uli Kusterer]

At 23:13 Uhr -0500 06.03.2005, Narcoleptic Electron wrote:
>I realize all of that. I'm looking at all of this from a lower level,
>purely from a "how can my mouse interact with this interface"
>perspective: "Can I drag this thing? Can I click this thing? If I
>click this, what will happen?"
>
>In that sense, the slider and scroller have the following in common:
>- There is a handle that can be dragged within the trough.
>- There is a trough that can be clicked, which brings the handle to
>the click location.
>
>From this standpoint, the slider and the scroller are identical.
>
>As far as the differences you describe, these are already clear from
>the context: if the slider/scroller is in the middle of a dialog, it's
>a slider, whereas if it's attached to a scroll view, it's a scroller.

To a pro, yes. But most beginning users will be thankful for any
differences you can have between these two that additionally help
distinguish those. There are solid, practical reasons why Apple for
instance *actively warned* its developers not to use a scroll bar
when a slider was needed. (Of course, they then continued to use a
scroll bar in their color picker for years, but I digress).

>M. Uli Kusterer wrote:
> > I'm tempted to do sliders with a little "nose" to one
>> side, like some machines have them (and Aqua has that as well).
>
>Sounds cool to me. They should contain a drag dot as well, though.

Of course. Drag dot sounds like a good idea.

--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

[M. Uli Kusterer]

At 19:39 Uhr -0600 05.03.2005, Jesse Ross wrote:
>Gill Sans is a very nice font, although I think the bold version may
>be a bit too heavy. Good suggestion.

Well, Gill Sans used to be rather expensive, so bold is the only
variant I have.

>Futura is also nice, but part of what I don't like about BSV on the
>desktop is that it's (mostly) a consistent line weight font, just
>like Futura.

Futura definitely is. But yeah, I prefer Futura for headlines. Looks
so clean. Ummm... I think we're heading off-topic here :-)

>That's weird, because when I flip between the two in the mockup,
>Lucida is subtly smaller. Look, for example, at the Radio labels
>(not the titlebar, because there Lucida is at 13 and BSV is at 12).
>We must have slightly different versions of the same font, because
>here's my font test with everything at 50pt:
>
>http://jesseross.com/clients/gnustep/ui/fonts/font_test.png
>
>Craziness.

Odd. I did my image on Mac OS X in Photoshop Elements. Maybe you're
using a different engine? My Lucida definitely seems to be larger.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

[Nicolas Roard]

Le 6 mars 05, à 03:10, Jesse Ross a écrit :

> Revision 5, for your viewing pleasure:
>
> http://jesseross.com/clients/gnustep/ui/concepts/05/
> camaelon_nesedah.png

Very nice :-) -- it starts to look well-balanced imho..

> The table headers are using a coloring scheme similar to the tabs.

Hm, I'm not sure about the non-selected headers.. that way they don't
look like something clickable... would it be better to have a similar
look than the selected header, but with the selected header either
using a different color/gradient ? (a bit like what we have now and
what apple does)

> I think this makes sense and prevents confusing them with the browser
> header. I'm personally not too psyched about the browser header. It
> feels a bit clunky to me... I'll probably play with that some more.

Hm, one thing about the nsbrowser: the scrollbar shouldn't be like
that, because you can have multiple columns; without separation it will
look weird (here it's not very notable because we have only one column,
and thus it looks ok), because the bottom scrollbar is not a scrollbar
for the column contentview, but for scrolling columns.

have a look on this example:
http://www.roard.com/screenshots/screenshot_hv21.png

>
> If you look at the table with "Toy" in it, you can see that the letter
> 'y' is keeping me from making the header shorter. I did add the
> gradient in, though, which helps indicate that these are clickable
> elements.

yep, I like it :-) -- the only thing would be perhaps for non-selected
table headers to have the same look, minus the gradient, for example..
I duno..

>
> The scroll bar uses Uli's tuck-behind concept -- I'm not sure about
> implementation, though. And scroll arrows now have the same gradient
> as the buttons and scroll bar.

they look very nice to me :-)

Cheers,

--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke

[Jesse Ross]

> Hm, one thing about the nsbrowser: the scrollbar shouldn't be like
> that, because you can have multiple columns; without separation it
> will look weird (here it's not very notable because we have only one
> column, and thus it looks ok), because the bottom scrollbar is not a
> scrollbar for the column contentview, but for scrolling columns.
>
> have a look on this example:
> http://www.roard.com/screenshots/screenshot_hv21.png

Is it a bad idea and/or problematic to put the browsers right next to
one another, like OS X does? They'll have a clear separation from one
another with the scroll bars.

That said, it probably makes sense to ditch the little box in the lower
left, because it does look like the scroller is for that specific
content area.


J.

[M. Uli Kusterer]

At 21:10 Uhr -0600 05.03.2005, Jesse Ross wrote:
>Revision 5, for your viewing pleasure:
>
>http://jesseross.com/clients/gnustep/ui/concepts/05/camaelon_nesedah.png
>
>The table headers are using a coloring scheme similar to the tabs. I
>think this makes sense and prevents confusing them with the browser
>header. I'm personally not too psyched about the browser header. It
>feels a bit clunky to me... I'll probably play with that some more.

One more suggestion? Give the deselected headers a gradient style
like the selected ones, so they still look clickable. However, keep
them in that darker shade.

The browser header looks a little heavy, being almost as dark as the
title bar, but as the browser is a control that's easily mixed up
with a list/table, but works quite differently, I think making it
stand up may actually help people recognize it.

>If you look at the table with "Toy" in it, you can see that the
>letter 'y' is keeping me from making the header shorter. I did add
>the gradient in, though, which helps indicate that these are
>clickable elements.

I think that's okay. If you made them any shorter, it would look
rather crammed. Margins and creative whitespace are needed in a good
design.

>The scroll bar uses Uli's tuck-behind concept -- I'm not sure about
>implementation, though. And scroll arrows now have the same gradient
>as the buttons and scroll bar.

Well, I guess we'll have to ask the Cameleon implementors to allow
that. I don't think it'd be hard to implement, but of course it's
relatively much work for no real gain in functionality. But it'd
probably be possible to e.g. have "special" bitmaps that get
displayed for the bottom or top ends when they get within a certain
distance of the end of the scrollbar track. That would even allow for
effects in other themes, like the thumb "flowing" into the arrows or
whatever...

Oh, and BTW: Is the gradient in the scrollbar arrows new? I didn't
notice that before, and it looks classy. Especially how the separator
between the arrows seems to brighten in the middle. Great work on the
details there!
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

[Randi Joseph]

I agree with the others also....

-randi

On Mar 1, 2005, at 6:00 PM, Jesse Ross wrote:

>> It's a perfectly reasonable question. I hope you found my answer
>> adequate.
>
> Yep -- between you and Stefan, it makes sense to me. 12 does seem a bit
> large, but if that's what we're working with, then that's okay. I will
> use
> 12pt in the next set of mockups and adjust the sizing of other elements
> accordingly. I suppose having a higher than normal monitor resolution
> makes 12pt make sense.
>
> Since I'm here, are there any other built in defaults or things I
> should
> be aware of when working on the next version? Anything you guys would
> know
> but I might not?
>
>
> J.
>
>
>
>
>
>
>
>
> _______________________________________________
> Gnustep-ui mailing list
> Gnustep-***@gna.org
> https://mail.gna.org/listinfo/gnustep-ui

[Randi Joseph]

Hi Jesse,

Try substituting the popup menu "thumb-tack" with the "up down" arrows
that Nicolas uses here:

http://www.roard.com/screenshots/screenshot_theme44.png

-randi

[M. Uli Kusterer]

You asked for it, you'll get it. Warning, these are various
over-zealous nitpicks.

At 23:20 Uhr -0600 28.02.2005, Jesse Ross wrote:
>I would like more reasons either way on the scroll bar -- I
>personally think rounding them slightly helps differentiate them
>from the progress bar, but if you can convince me one way or the
>other, I'll implement it.

Well, I mainly commented on the "thumb" being round while the track
isn't. That kinda made the edges of the track "peek out" from under
the thumb, which IMHO looked a little odd. Generally, I like the
rounded corners.

>With the check boxes and radios, I would like to try to keep the
>size of the control as close as possible to the size of the text
>label. I think that, even at a quick glance, it is easy to tell the
>difference between the selected and unselected radios, so I would
>prefer to not change the size of the dot (I had it bigger, and it
>looked really ugly).

Well, it's black, as opposed to the white when it's not checked, so
IMHO the radio button isn't really that much of a problem *visually*.

>I could work with the check box's check so it stands out more, but I
>don't want it to extend past the boundary of the box if possible
>(for the same reason that I want the controls the same size as the
>text -- the elements flow better together that way).

Well, IMHO as long as the box stays the size of the text, the check
mark can be larger without problems. In fact, I'd think this would
make the checked checkbox's shape more distinct. But I haven't seen
how this looks in relation to the rest of the theme. If you say it
doesn't fit, then I'll take your word for it.

>Also, and this isn't apparent from the mockup, but clicking on the
>label should also activate the appropriate control, so that greatly
>increases our hit area beyond 8x8 or even 16x16.

Well, the trouble is that the concept of direct manipulation may
make people unaware they *can* click the title. And the part of a
check box that stands out the most *is* the image itself. So, while
we could have a tolerance around the icon to accept clicks there,
too, that is sort of cheating.

I also think the hook is just too small. There's only one pixel
difference between the two sides, making it look like a "v". It
doesn't look like a check mark if you don't know it's supposed to be
one. Real check marks are much more asymmetric.

Maybe this is one of those moments where it'd help to take a step
back and look at real-life election ballot sheets, your shopping
lists or lottery tickets again. Try to recall the defining
characteristics that make out real-life checkmarks and make another
attempt at integrating them into your design? Kind of like when you
draw humans from memory, you have to go back to doing portraits after
a while or your drawings will get too stylized?

After all, all these GUI ideas come from real life, and sometimes we
find ourselves getting inspiration from existing GUIs, which are
dangerous, because they're already second-generation knockoffs of the
real thing.

>A similar thing also applies with the slider. Clicking at any point
>in the gutter will move the slider to that point (bigger hit area,
>but not as precise). If the slider knob gets much bigger it will
>seem really disproportionate to the gutter (and the gutter shouldn't
>get much bigger because we don't want it to be too close to the size
>of the scroll bar's gutter or the progress bar's gutter. Does anyone
>have any clever suggestions beyond just "make it bigger" for giving
>us more hit area on this control?

Well, I personally think the slider track or "gutter" can still gain
two pixels without looking like the scrollbar track or the progress
bar. Especially since the knob stands out at the sides, and thus
causes an optical illusion of narrowness anyway.

>That said, keep giving me feedback, everyone. I certainly won't
>please everyone, but I will try to please the most (vocal) people. :)

*starts screaming madly* ;-)
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

[M. Uli Kusterer]

At 10:30 Uhr +0700 01.03.2005, Rob Burns wrote:
>I quite like it as well. with one exception. The tabs. I find that
>they are similar to gnomes' tabs, which are very indstinct. It's
>always difficult for me to tell which one is selected. and where the
>divisions are. With gnustep's current tabs its very easy to see.

My vote for that, too. Maybe some stronger lines or stronger
shadows? Use of color perspective to make sure the back tab looks
more "behind" the active one? Round the corners at the top some more
to make them more distinct from each other?

Just some suggestions. I'm sure Jesse will find the right blend.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de