Nesedah

[Jesse Ross]

New concept is posted at:

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

or

Loading Image...


I've made the following changes:

- Added what I personally like for the default button
- Added what I would like to use as the default color (indigo)
- Added notches in the title bar to indicate draggability
- Changed the upper left corners on the box to be rounded, to be
better unified with the rest of the container labels
- Increased the overall contrast

I'm really happy with where it's at at this point. Further changes I
make will be in an attempt to increase aesthetics.


J.

[Alex Perez]

Post by Jesse Ross
http://jesseross.com/clients/gnustep/ui/concepts/
or
http://jesseross.com/clients/gnustep/ui/concepts/21/camaelon_nesedah.png
- Added what I personally like for the default button

Does it view okay for people with various types of colorblindness? My
only concern is that the color of the text is also quite close to the
color of the surrounding background, which could be an issue for folks
with certain types of vision problems (and this is especially an issue
since the rest of the interface is much more high-contrast now.

Post by Jesse Ross
- Added what I would like to use as the default color (indigo)

Yo quiero numero 21.

Post by Jesse Ross
- Added notches in the title bar to indicate draggability

not so hot on these, but they are non-intrusive enough to not really
warrant a serious complaint.

Post by Jesse Ross
- Changed the upper left corners on the box to be rounded, to be better
unified with the rest of the container labels

*shrug*

Post by Jesse Ross
- Increased the overall contrast

Mo' betta.

Post by Jesse Ross
I'm really happy with where it's at at this point. Further changes I
make will be in an attempt to increase aesthetics.

You are the artist. I am a simple know-nothing assclown of a critic ;-)
*hands you your salt-lick*

[Jesse Ross]

Post by Alex Perez
Does it view okay for people with various types of colorblindness? My
only concern is that the color of the text is also quite close to the
color of the surrounding background, which could be an issue for folks
with certain types of vision problems (and this is especially an issue
since the rest of the interface is much more high-contrast now.

Surprisingly, I have many designer friends with color blindness. I will
have them look at it and get their opinion (although from what they've
told me before, people with colorblindness tend to be particularly
sensitive to tonal changes, which means they would probably see the
contrast better than you and I).


J.

[M. Uli Kusterer]

Jesse,

just had a look at Nesedah 21. Four comments:

1) the drag notches in the window header are nice, but I think you
may also want to try having ones at the very ends of the title bar.
Otherwise it looks like it's just some sort of eye-candy around the
title.

2) The default button's text is a little hard to read being black on
dark blue. Maybe you could offset a second, bright copy of the title
by one pixel up/left, so it'll look embossed. The additional brighter
outline should make it more readable.

3) The browser header. I've been trying to get used to it, but I just
think it's too dark, too heavy. Have you tried a variant that looks
more like the table headers? Right now it's as dominant as the window
title.

OTOH, if you want to keep it dark, maybe you could put a similarly
dark line between the bottom scroller and the actual columns. That
would be a good compromise between making it all look like one
homogeneous object and having the bottom scroller at a distance to
indicate to people that it also scrolls the vertical scrollers.

4) The group box title somehow looks "too far away" from the items it
actually encloses. Maybe we should left-align it to put it more in
the path of the eye when scanning the list of items?

On a similar note: In the rules document, you may want to refer to
items like this as "grouping" controls or so, not as "containers".
Otherwise, people will do things like create rounded scroll views,
which IMHO wouldn't be quite correct.

[David Chisnall]

People suffering from red-green colour blindness (about 90% of colour
blind people, as I recall) are unable to tell the difference between a
red and a green at the same intensity (e.g. traffic lights, or the
close and maximise buttons in OS X), but are very good at telling the
difference between different shades of red and of green. Since our
interface uses neither red nor green, this should not affect us at all.

People with complete colour blindness (I can't remember the medical
term. People who only see shades of grey) will have difficulty
distinguishing red Vs green Vs blue, but they will again have no
problem with Nesedah, since all of the different colours have different
brightness levels (see what the image looks like when converted to grey
scale to see what they would see).

The default configuration of a human has a much worse ability to
distinguish shades of blue than of either red or green (with red being
the easiest), and so it is important to keep the contrast quite high if
we are focussing on the blue end of the spectrum. Additionally, a
predominance of blue can adversely affect the brain's ability to
perceive shades of red and green, making a blue interface very bad for
anyone needing to work with accurate colours (e.g. graphic designers) -
this was why the graphite interface was added to OS X.

P.S. I still don't like the disabled scroll bars. They were a UI
mistake in Windows 3.0, and they are still one now.

Post by Jesse Ross

Post by Alex Perez
Does it view okay for people with various types of colorblindness? My
only concern is that the color of the text is also quite close to the
color of the surrounding background, which could be an issue for
folks with certain types of vision problems (and this is especially
an issue since the rest of the interface is much more high-contrast
now.

Surprisingly, I have many designer friends with color blindness. I
will have them look at it and get their opinion (although from what
they've told me before, people with colorblindness tend to be
particularly sensitive to tonal changes, which means they would
probably see the contrast better than you and I).
J.
_______________________________________________
Gnustep-ui mailing list
https://mail.gna.org/listinfo/gnustep-ui

[Alex Perez]

David Chisnall wrote:
[snip]

Post by David Chisnall
P.S. I still don't like the disabled scroll bars. They were a UI
mistake in Windows 3.0, and they are still one now.

Since you have refused to back up your opinion with any form of actual
evidence, you do your statement a disservice in that you state something
as fact, yet it is merely your opinion. Do you have any evidence to
support your position?

[David Chisnall]

There's a passage in The Humane Interface about disabling controls
without explaining what they need to re-enable them clearly to the
user. I would look it up, but I lent my copy to someone who has not
yet given it back.
Beyond that, I had all sorts of problems explaining to novice users
back in the windows 3.x days that they couldn't use the disabled scroll
bars, and that there really was nothing hidden beyond their view.
Perhaps computer users today are less naive, but I don't think that's a
good basis for user interface design.
When something is scrollable, it should have scroll bars. When it is
not, it should not. To add disabled scroll bars is confusing and
inconsistent (unless you are going to put disabled scroll bars around
the entire window and any another canvas that can't be scrolled). By
all means, keep the trough for them to prevent other UI elements moving
mysteriously, but do not put disabled buttons on a user interface as
anything other than a last resort.

[Narcoleptic Electron]

Post by David Chisnall
I had all sorts of problems explaining to novice users
back in the windows 3.x days that they couldn't use the disabled scroll
bars, and that there really was nothing hidden beyond their view.

It seems that your complaint about disabled scrollers is that they may
mislead users into thinking that they are enabled. However, this
argument extends to *all* disabled controls. There *are* going to be
disabled controls elsewhere in the interface, and removing disabled
scrollers does nothing to address these.

The proper solution to your objection is to make all disabled controls
look less like enabled controls. This is why I suggested making the
disabled scroller (and all other disabled controls) darker than
enabled controls, in addition to removing the bevel.

Post by David Chisnall
When something is scrollable, it should have scroll bars. When it is
not, it should not. To add disabled scroll bars is confusing and
inconsistent (unless you are going to put disabled scroll bars around
the entire window and any another canvas that can't be scrolled).

Disabled scrollers indicate a property of the view: that it will
scroll if necessary (i.e. content gets added to the view or the view
gets resized). Not all controls have this property.

Post by David Chisnall
By all means, keep the trough for them to prevent other UI elements moving
mysteriously, but do not put disabled buttons on a user interface as
anything other than a last resort.

That would be inconsistent use of a trough. Troughs can be clicked,
and indicate an area of travel for a scroll handle or slider. None of
these apply.

Also, the trough solution does nothing to address the scenario that I
described in my previous email on the subject. For convenience, and
since it is on another thread, I include it below:

1. What happens to the arrow buttons when the scroll handle reaches
one end of the track? For example, when the scroll handle in a
horizontal scroller reaches the left side of the track, does the left
arrow button get disabled, considering that it no longer does
anything?

- If it stays the same, it will mislead the user into thinking that it
can be clicked, and something will happen.

- If it disappears, the right arrow button would move to the left, and
active controls that automatically move around on the user are very
bad. (I don't think I need to go into all the reasons here.)

I can see only one alternative: to disable the left scroll button.

2. When the window is enlarged a bit, the scroll handle gets bigger.
If it ends up bumping against one end of the track, the corresponding
arrow button would become disabled (assuming that my first conclusion
above is correct).

3. When the window is enlarged enough, the scroll handle would
eventually get large enough that it bumps up against both sides of the
track, taking up the full length of the track. It then makes sense
that:

a. Both arrow buttons are disabled (again, assuming correct logic above);
b. The scroll handle is disabled (because it can no longer be dragged,
being the full length of the track).

In other words, the disabled scroller would consist of (a) disabled
arrow buttons, and (b) a disabled scroll handle. In the current
mockup, that would simply mean modifying the colour of the
non-arrow-button part to be the same as the arrow buttons.

Is there a hole in this logic?

[M. Uli Kusterer]

Post by Narcoleptic Electron
The proper solution to your objection is to make all disabled controls
look less like enabled controls. This is why I suggested making the
disabled scroller (and all other disabled controls) darker than
enabled controls, in addition to removing the bevel.

Actually, intuitively, making objects lighter, not darker, would be
the way to go. Dark makes items look heavy and more important, more
physical. So, you're actually emphasizing disabled controls by making
them darker (because you're increasing contrast).

To make objects look less important, you usually make them harder to
distinguish, e.g. by reducing their contrast and brightness. This
way, these items blend in with the background, and, in result,
enabled controls stand out even more clearly.

Post by Narcoleptic Electron

Post by David Chisnall
When something is scrollable, it should have scroll bars. When it is
not, it should not. To add disabled scroll bars is confusing and
inconsistent (unless you are going to put disabled scroll bars around
the entire window and any another canvas that can't be scrolled).

Disabled scrollers indicate a property of the view: that it will
scroll if necessary (i.e. content gets added to the view or the view
gets resized). Not all controls have this property.

I agree here. Hiding the whole scroller doesn't work well. Less
because it confuses users, but rather because of the fact that
content tends to re-wrap when the scroller is added/removed, thus
possibly necessitating another scroller.

Post by Narcoleptic Electron

Post by David Chisnall
By all means, keep the trough for them to prevent other UI elements moving
mysteriously, but do not put disabled buttons on a user interface as
anything other than a last resort.

That would be inconsistent use of a trough. Troughs can be clicked,
and indicate an area of travel for a scroll handle or slider. None of
these apply.

True. Especially with an attention-grabbing dark trough like we have
it in Nesedah. For Apple it works, because the scrollers there are
mainly white, but for Nesedah this isn't an option.

Post by Narcoleptic Electron
In other words, the disabled scroller would consist of (a) disabled
arrow buttons, and (b) a disabled scroll handle. In the current
mockup, that would simply mean modifying the colour of the
non-arrow-button part to be the same as the arrow buttons.

I guess I'm agreeing with you. We need to make inactive scrollers
look more disabled, and your approach might actually work. Right now,
they look too dominant, too active, even when disabled.

Just a (genuine) question: Is a scroller with nothing to scroll
because the entire canvas is visible different from a scroller that
has actually been disabled? Does disabled mean "some outside
influence makes this option not applicable in this case", while a
scroller with nothing to scroll indicates "you're already seeing
everything"?

*should* there be a distinction of these two, or is that the
programmer in me that's just gotten used to this?

[Narcoleptic Electron]

Post by M. Uli Kusterer
Cluttering is an important
usability concern that prevents users from distinguishing groups of
objects or locating them.

That's a very good point.

I have thought about this some more, and taken with David's (and
Raskin's) point, I've been convinced. When scrolled to one end, it
makes sense for the corresponding arrow button to be disabled, as it
is obvious what needs to be done to re-enable it: simply click the
enabled arrow button. This is easy for the user to discern. However,
if scrolled to *both* ends (i.e. there is no scrolling possible), and
both arrow buttons are disabled:

- It is difficult to know how to re-enable the arrow buttons, because
the action to do so is not directly related to the buttons (eg.
resizing the window smaller). When only one arrow button is disabled,
it is easy to know how to enable it: click the other arrow button.
Not so when they are both disabled.

- The arrow buttons do not need to be there as placeholders. Contrast
this with when only the left arrow button is disabled: it still needs
to be there so that the right arrow button doesn't move to the left to
fill the space. However, there is no need for placeholders when both
are disabled; they can simply be removed.

Therefore, I have changed my mind on arrow buttons: for the disabled
scroll bar, get rid of them.

I still disagree that using an empty trough is the answer, though, for
reasons I've given previously. Therefore, instead of an empty trough,
what do you think of using a disabled, full-sized scroll handle (no
bevel, etc.) with no arrow buttons? I think that solution would
satisfy everyone.

[Jesse Ross]

New version of Nesedah is posted at:

Loading Image...

Most of the changes I've made are aesthetic ones, although I have tried to
take into account many of the suggestion given lately regarding scroll
bars. It seems that many people do like the OS X style ones. Take a look
and let me know what you think!


J.

[Jonathan Isom]

Post by Jesse Ross
http://jesseross.com/clients/gnustep/ui/concepts/22/camaelon_nesedah.png
Most of the changes I've made are aesthetic ones, although I have tried to
take into account many of the suggestion given lately regarding scroll
bars. It seems that many people do like the OS X style ones. Take a look
and let me know what you think!

Now its perfect
Later
Jonathan

[Nicolas Roard]

Post by Jesse Ross
http://jesseross.com/clients/gnustep/ui/concepts/22/
camaelon_nesedah.png
Most of the changes I've made are aesthetic ones, although I have tried to
take into account many of the suggestion given lately regarding scroll
bars. It seems that many people do like the OS X style ones. Take a look
and let me know what you think!

looks goo, but could you remove the stripes ? they hurt my eyes..
and it's a bit too bright too, don't you think ?

Cheers,

[Alex Perez]

Post by Jesse Ross
http://jesseross.com/clients/gnustep/ui/concepts/22/camaelon_nesedah.png
Most of the changes I've made are aesthetic ones, although I have tried to
take into account many of the suggestion given lately regarding scroll
bars. It seems that many people do like the OS X style ones. Take a look
and let me know what you think!
J.

HARDY HAR HAR HAR!

[Frederico Muñoz]

Post by Jesse Ross
http://jesseross.com/clients/gnustep/ui/concepts/22/camaelon_nesedah.png
Most of the changes I've made are aesthetic ones, although I have tried to
take into account many of the suggestion given lately regarding scroll
bars. It seems that many people do like the OS X style ones. Take a look
and let me know what you think!

Best April 1st story that I've seen.

The casual tone you put into it, exactly like the previous
annoucements, plus the fact that I have only actually seen OSX live
twice in my life for a total of 10 minutes made me jump of my chair
when I clicked the link. It didn't immediatly sunk in what it really
was, for a split second I was really thinking "I knew that all this
talk would end up similar to Aqua, bloody hell!".

Cheers,

fsmunoz

[Narcoleptic Electron]

Post by Jesse Ross
http://jesseross.com/clients/gnustep/ui/concepts/22/camaelon_nesedah.png
Most of the changes I've made are aesthetic ones, although I have tried to
take into account many of the suggestion given lately regarding scroll
bars. It seems that many people do like the OS X style ones. Take a look
and let me know what you think!

OK, everyone. Enough is enough.

You've probably been wondering who this "Intermittently Slumbering
Sub-Atomic Particle" is that has been making insane, outlandish
suggestions on this list under the guise of "usability" and
"consistency". I may as well let you know: I'm here under specific
orders to eliminate any possibility of GNUStep ever looking good
enough to compete with Aqua.

Well, Jesse, you've really gone too far this time. I've informed Mr.
Jobs personally about your latest "mock-up" and you can expect a
letter from our attorneys by Monday. I just wanted to give you a
heads-up.

It was nice knowing you all,

N. Electron

[M. Uli Kusterer]

Post by Jesse Ross
http://jesseross.com/clients/gnustep/ui/concepts/22/camaelon_nesedah.png
Most of the changes I've made are aesthetic ones, although I have tried to
take into account many of the suggestion given lately regarding scroll
bars. It seems that many people do like the OS X style ones. Take a look
and let me know what you think!

I still think the default button doesn't go well with the regular ones.

[Narcoleptic Electron]

Looking great, Nicolas:

Loading Image...

OSNews discussion about it here:

http://osnews.com/comment.php?news_id=10182&limit=no

N. Electron

[Fabien VALLON]

On 2005-04-04 20:21:18 +0200 Narcoleptic Electron

Post by Narcoleptic Electron
http://www.roard.com/screenshots/screenshot_theme48.png

Sorry but Loading Image...
is still better

What about good icons and good UI/guidelines/suggestion for GNUstep ?

Fabien

[Jesse Ross]

Post by Fabien VALLON

Post by Narcoleptic Electron
http://www.roard.com/screenshots/screenshot_theme48.png

Sorry but http://www.levenez.com/NeXTSTEP/Mail.gif
is still better

May I ask what it is about the new interface that you're not particularly
happy with? If you have some suggestions for ways of improving it to
provide the best experience for users who like the original NeXT look,
that would be appreciated.

Post by Fabien VALLON
What about good icons and good UI/guidelines/suggestion for GNUstep ?

We're working on those as well -- I've been a bit busy lately so I haven't
gotten to all the icons I have on my plate (hang in there, guys!). I will
also be working out solutions to the problems like margins and padding
that some of the controls have. If you have other suggestions where the UI
could use a boost, let me know and we'll see if we can provide a solution.


J.

[Fabien VALLON]

Post by Jesse Ross

Post by Fabien VALLON

Post by Narcoleptic Electron
http://www.roard.com/screenshots/screenshot_theme48.png

Sorry but http://www.levenez.com/NeXTSTEP/Mail.gif
is still better

May I ask what it is about the new interface that you're not
particularly
happy with? If you have some suggestions for ways of improving it to
provide the best experience for users who like the original NeXT look,
that would be appreciated.

Of course :
It is just about the mili-seconds you lost to have to think about what
to do

Menu :
- No separator into seral items
- Too clear

Buttons :
- Round button or maybye not bordered ( with no "volume")
- Toolbar : buttons are not bordered : you have too guess where to clic
- Should maybye be bigger : more space on the top & the bottom of the
text


Icon :
- Outline : the arrow should maybye different color to indicate the
state ( collapse / expand ) : not just the form

Browser /TableView ... :
- Indicate when you are editing it

Controls Focus
- We should know what a control ( textfield for example ) have the
focus : add a black (your color )
border (required GNUstep code )

Outline : more contrast between lines

Post by Jesse Ross
We're working on those as well -- I've been a bit busy lately so I haven't
gotten to all the icons I have on my plate (hang in there, guys!). I will
also be working out solutions to the problems like margins and padding
that some of the controls have. If you have other suggestions where the UI
could use a boost, let me know and we'll see if we can provide a solution.

Good to hear !

Fabien

[Jesse Ross]

Post by Fabien VALLON

Post by Jesse Ross
May I ask what it is about the new interface that you're not
particularly happy with? If you have some suggestions for ways of

improving it to

Post by Fabien VALLON

Post by Jesse Ross
provide the best experience for users who like the original NeXT look,
that would be appreciated.

It is just about the mili-seconds you lost to have to think about what

to do

I think many of your concerns are due to the new theme not being fully
implemented yet. Here's what the theme should look like when it's
completed:

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

Post by Fabien VALLON
- No separator into seral items
- Too clear

The menu may look something like the menu here:

Loading Image...

We haven't really made a decision on the appearance of it yet, so the
version you see in Nicolas' screenshot is what he decided to do to get it
close to the theme. I personally have some other devious ideas for the
menu that I haven't discussed with the group yet... stay tuned... ;)

Post by Fabien VALLON
- Round button or maybye not bordered ( with no "volume")

What do you mean by this?

Post by Fabien VALLON
- Toolbar : buttons are not bordered : you have too guess where to clic

Even though I think they make the interface cleaner this way, they
probably should be bordered and beveled, just like a regular button... I'm
sure Narcoleptic Electron would throw a fit if they weren't.

Post by Fabien VALLON
- Should maybye be bigger : more space on the top & the bottom of the
text

Yep -- we need to work on the spacing of buttons and tabs and headers
and... you get the point. I still need to come up with specs/guidelines
for that. Look at the concept 21 screenshot above to see how buttons and
tabs margins *should* look in the final implementation.

Post by Fabien VALLON
- Outline : the arrow should maybye different color to indicate the
state ( collapse / expand ) : not just the form

That's a good idea... we haven't even talked about the collapse/expand
arrows yet.

Post by Fabien VALLON
- Indicate when you are editing it

Do you mean indicating the control focus as per your suggestion below?

Post by Fabien VALLON
Controls Focus
- We should know what a control ( textfield for example ) have the
focus : add a black (your color ) border (required GNUstep code )

Totally agree -- we need to get to that still. I assume it will use the
highlight color as a border around the focused control.

Post by Fabien VALLON
Outline : more contrast between lines

The new mockup has a higher contrast, and will probably be pushed even
more based on some other recent suggestions.



Thanks for the feedback -- keep us posted if you have more!


J.

[Fabien VALLON]

Post by Jesse Ross

Post by Fabien VALLON

Post by Jesse Ross
May I ask what it is about the new interface that you're not
particularly happy with? If you have some suggestions for ways of

improving it to

Post by Fabien VALLON

Post by Jesse Ross
provide the best experience for users who like the original NeXT look,
that would be appreciated.

It is just about the mili-seconds you lost to have to think about what

to do
I think many of your concerns are due to the new theme not being fully
implemented yet. Here's what the theme should look like when it's
http://jesseross.com/clients/gnustep/ui/concepts/21/camaelon_nesedah.png

Suggestion :
More contrast for the dots into for the split bar please :)

Post by Jesse Ross

Post by Fabien VALLON
- No separator into seral items
- Too clear

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

Better
Notes :
- too much antialising for me, too much blur ( like Aqua )
- Please Keep the scrollbar at the bottom of the path view ( into the
FileViewer ) : it is easier to use

Post by Jesse Ross

Post by Fabien VALLON
- Round button or maybye not bordered ( with no "volume")

sorry for my english.
I mean this button are too flat !

Post by Jesse Ross
What do you mean by this?

Post by Fabien VALLON
- Toolbar : buttons are not bordered : you have too guess where to clic

Even though I think they make the interface cleaner this way, they
probably should be bordered and beveled, just like a regular
button... I'm
sure Narcoleptic Electron would throw a fit if they weren't.

Yes it is not efficient / easy to use without border ...
You don't know where to clic ( well you need more times ... )

Post by Jesse Ross

Post by Fabien VALLON
- Should maybye be bigger : more space on the top & the bottom of the
text

Yep -- we need to work on the spacing of buttons and tabs and headers
and... you get the point. I still need to come up with
specs/guidelines
for that. Look at the concept 21 screenshot above to see how buttons and
tabs margins *should* look in the final implementation.

Post by Fabien VALLON
- Outline : the arrow should maybye different color to indicate the
state ( collapse / expand ) : not just the form

That's a good idea... we haven't even talked about the collapse/expand
arrows yet.

Post by Fabien VALLON
- Indicate when you are editing it

Do you mean indicating the control focus as per your suggestion below?

When you edit a row. it should be clearly indicate.

Post by Jesse Ross

Post by Fabien VALLON
Controls Focus
- We should know what a control ( textfield for example ) have the
focus : add a black (your color ) border (required GNUstep code )

Totally agree -- we need to get to that still. I assume it will use the
highlight color as a border around the focused control.

We should bug repport it to GNUstep

Post by Jesse Ross

Post by Fabien VALLON
Outline : more contrast between lines

The new mockup has a higher contrast, and will probably be pushed even
more based on some other recent suggestions.

OK.
Thanks

Fabien

[Nicolas Roard]

Post by Fabien VALLON

Post by Jesse Ross

Post by Fabien VALLON

Post by Jesse Ross
May I ask what it is about the new interface that you're not
particularly happy with? If you have some suggestions for ways of

improving it to

Post by Fabien VALLON

Post by Jesse Ross
provide the best experience for users who like the original NeXT look,
that would be appreciated.

It is just about the mili-seconds you lost to have to think about what

to do
I think many of your concerns are due to the new theme not being fully
implemented yet. Here's what the theme should look like when it's
http://jesseross.com/clients/gnustep/ui/concepts/21/
camaelon_nesedah.png

More contrast for the dots into for the split bar please :)

... and still the scrollbar things..
;-)

Post by Fabien VALLON

Post by Jesse Ross

Post by Fabien VALLON
- No separator into seral items
- Too clear

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

Better
- too much antialising for me, too much blur ( like Aqua )
- Please Keep the scrollbar at the bottom of the path view ( into the
FileViewer ) : it is easier to use

hm yes you're probably right on that.
No real work was done on the menus in Camaelon yet (well, I started,
but nothing on cvs)

Post by Fabien VALLON

Post by Jesse Ross

Post by Fabien VALLON
- Round button or maybye not bordered ( with no "volume")

sorry for my english.
I mean this button are too flat !

Too flat ??? I think the buttons are ok and you can easily see the
"volume"..

Post by Fabien VALLON

Post by Jesse Ross
What do you mean by this?

Post by Fabien VALLON
- Toolbar : buttons are not bordered : you have too guess where to clic

Even though I think they make the interface cleaner this way, they
probably should be bordered and beveled, just like a regular
button... I'm
sure Narcoleptic Electron would throw a fit if they weren't.

Yes it is not efficient / easy to use without border ...
You don't know where to clic ( well you need more times ... )

I think it's a case where readability is more important ...
Not having borders don't really annoys people imho, and the UI is
cleaner.

Post by Fabien VALLON

Post by Jesse Ross

Post by Fabien VALLON
- Outline : the arrow should maybye different color to indicate the
state ( collapse / expand ) : not just the form

That's a good idea... we haven't even talked about the collapse/expand
arrows yet.

Post by Fabien VALLON
- Indicate when you are editing it

Do you mean indicating the control focus as per your suggestion below?

When you edit a row. it should be clearly indicate.

Isn't it the case ??

Post by Fabien VALLON

Post by Jesse Ross

Post by Fabien VALLON
Controls Focus
- We should know what a control ( textfield for example ) have the
focus : add a black (your color ) border (required GNUstep code )

Totally agree -- we need to get to that still. I assume it will use the
highlight color as a border around the focused control.

We should bug repport it to GNUstep

gni ?

bug report what ?

The code is there to display the selected textfield/button. It's just
that I don't have
the pixmaps for theses states, so I use the default one..

[Fabien VALLON]

Post by Nicolas Roard

Post by Fabien VALLON
We should bug repport it to GNUstep

gni ?
bug report what ?
The code is there to display the selected textfield/button. It's just
that I
don't have
the pixmaps for theses states, so I use the default one..

Do you need a pixmap to have black ( or other color ) around a
textfield ?
Why not put it in GNUstep CVS ?

Fabien

[Nicolas Roard]

Post by Fabien VALLON

Post by Nicolas Roard

Post by Fabien VALLON
We should bug repport it to GNUstep

gni ?
bug report what ?
The code is there to display the selected textfield/button. It's just
that I
don't have
the pixmaps for theses states, so I use the default one..

Do you need a pixmap to have black ( or other color ) around a
textfield ?

Yes. Simply because you don't automatically want just a mere colored
frame (for example, see the selected textfields on osx). And the frame
anyway can depends on the default look. It's just better to have a set
of pixmaps for the normal textfields, and another set of pixmaps for
the selected textfields.

Post by Fabien VALLON
Why not put it in GNUstep CVS ?

?

[Fabien VALLON]

Post by Jesse Ross

Post by Fabien VALLON

Post by Jesse Ross
May I ask what it is about the new interface that you're not
particularly happy with? If you have some suggestions for ways of

improving it to

Post by Fabien VALLON

Post by Jesse Ross
provide the best experience for users who like the original NeXT look,
that would be appreciated.

It is just about the mili-seconds you lost to have to think about what

to do
I think many of your concerns are due to the new theme not being fully
implemented yet. Here's what the theme should look like when it's
http://jesseross.com/clients/gnustep/ui/concepts/21/camaelon_nesedah.png

Oh and I forgot :
Please keep the Shelf into the File Viewer :
It is a Workspace regretion to not keep it .

Fabien

[Kory T]

I think the new themes looks great.

It's time Gnustep moved on to a new look and feel while keeping the
original OpenStep purpose. There seems to be two types Gnustep users,
ones that insist the orginal NeXT look is superior, and others that
realize we're in the 21st century now and need to move on. I don't
want to say GnuStep needs to compete with Gnome or KDE, but it would be
nice if it had the same kind of userbase. More users usually = more
apps,devs,sponsors,etc. I think the Nesedah concepts are a good start
for the UI part becoming more attractive for new users (and long-time
users like myself). Apple had a lot of complaints from OS 9 users when
aqua first came out, but I don't see too many complaining about OS X
now ;-).

Kory T

PS. A few comments on the Nesedah concepts. I personally like the
overall feel of concept 01 and 10 the best. I especially like the menu
and dock/sidebar? on concept 01, and concept 10 is what I image a
modern nextstep ui to look like. It's very nice because it still kinda
resembles nextstep, but much more modern looking.

Post by Jesse Ross

Post by Fabien VALLON

Post by Narcoleptic Electron
http://www.roard.com/screenshots/screenshot_theme48.png

Sorry but http://www.levenez.com/NeXTSTEP/Mail.gif
is still better

May I ask what it is about the new interface that you're not
particularly
happy with? If you have some suggestions for ways of improving it to
provide the best experience for users who like the original NeXT look,
that would be appreciated.

Post by Fabien VALLON
What about good icons and good UI/guidelines/suggestion for GNUstep ?

We're working on those as well -- I've been a bit busy lately so I haven't
gotten to all the icons I have on my plate (hang in there, guys!). I will
also be working out solutions to the problems like margins and padding
that some of the controls have. If you have other suggestions where the UI
could use a boost, let me know and we'll see if we can provide a solution.
J.
_______________________________________________
Gnustep-ui mailing list
https://mail.gna.org/listinfo/gnustep-ui

[Fabien VALLON]

Post by Kory T
I think the new themes looks great.
It's time Gnustep moved on to a new look and feel while keeping the
original
OpenStep purpose. There seems to be two types Gnustep users, ones
that
insist the orginal NeXT look is superior,

The problem is that the look interact with the feel and the speed how
you do / understand
things.

And yes NeXTSTEP is still superior of all I have seen ( including
MacOSeX stuff ) :
dock / Finder / (none) Toolbar / NSMenu etc .. is still far better

The problem is that most gnustep-ui people never used NexSTEP, and
don't even use GNUstep but OSX
( see Mailer in headers )

The goal is not to have a nicer UI, the goal is to not make the same
errors that Apple does.
An odd hybrid (mix OS 9 / OPENSTEP ) UI paragnism

The good point is : Yes we/you can do better ( better than NeXT of
course , choose the hardest :) )

Fabien

[Jesse Ross]

Post by Fabien VALLON
And yes NeXTSTEP is still superior of all I have seen ( including
dock / Finder / (none) Toolbar / NSMenu etc .. is still far better
The problem is that most gnustep-ui people never used NexSTEP, and
don't even use GNUstep but OSX
( see Mailer in headers )

GNUstep doesn't have a decent replacement for Photoshop, Flash,
SubEthaEdit or Safari. Once it does, and I can install everything without
having to touch the command line, I will switch to GNUstep as my primary
personal development system.

Post by Fabien VALLON
The goal is not to have a nicer UI, the goal is to not make the same
errors that Apple does.
An odd hybrid (mix OS 9 / OPENSTEP ) UI paragnism

The goal is not just to make the UI more functional. There definitely is
an aesthetic issue to battle here as well. Making the UI "sexier" in order
to attract new users, I believe, is a valid goal. Not at the expense of
functionality, but as a balance. A more beautiful interface was not the
sole focus of Nesedah, but it's something to consider and to try to work
in.

While many users of NeXT might have a fondness for that look and feel,
there is a much larger population of users which will say (and have said,
see the postings on Slashdot from the LiveCD announcement) that the NeXT
interface is outdated. People will and do compare the interface to the
likes of OS X as their measure of beauty -- and this is something worth
working on. I have received more than one email stating that if Nesedah
were implemented as the out-of-the-box theme on a GNUstep-derived distro,
they would be more tempted to try GNUstep and try Linux or another Free
OS. We might not win all those people over, but even getting a few more
bodies in the mix would be helpful.


J.

[Fabien VALLON]

Post by Jesse Ross

Post by Fabien VALLON
And yes NeXTSTEP is still superior of all I have seen ( including
dock / Finder / (none) Toolbar / NSMenu etc .. is still far better
The problem is that most gnustep-ui people never used NexSTEP, and
don't even use GNUstep but OSX
( see Mailer in headers )

GNUstep doesn't have a decent replacement for Photoshop, Flash,
SubEthaEdit or Safari. Once it does, and I can install everything without
having to touch the command line, I will switch to GNUstep as my primary
personal development system.

I can understand that but "some people on the list" should try GNUstep
/ NeXSTEP
and try to understand what (and why) GNUstep developpers have done.

Post by Jesse Ross

Post by Fabien VALLON
The goal is not to have a nicer UI, the goal is to not make the same
errors that Apple does.
An odd hybrid (mix OS 9 / OPENSTEP ) UI paragnism

The goal is not just to make the UI more functional. There definitely is
an aesthetic issue to battle here as well. Making the UI "sexier" in order
to attract new users, I believe, is a valid goal.

It is a valid goal is it is too make a better thing to work with.
The goal of a computer is to work not to wank or to feel cool.

The goal of a desktop is to work better and faster so you can do
other things more intersting.
It is like a simple device or tools othing more.

The goal of an UI is too help users.

Have more users that does really use applications will not help.

Those users who wants something sexier won't help.
They will switch when something will be sexier ...

Users who want help are user that *use* tools apps we will develop.
Those users will help because they *work* with the app, they know
what they need to work with, they know their job and what could be
improve
to do the job just right.

Have more developpers will help too.

Post by Jesse Ross
Not at the expense of
functionality, but as a balance. A more beautiful interface was not the
sole focus of Nesedah, but it's something to consider and to try to work
in.

That good to hear.

Post by Jesse Ross
While many users of NeXT might have a fondness for that look and feel,
there is a much larger population of users which will say (and have said,
see the postings on Slashdot from the LiveCD announcement) that the NeXT
interface is outdated.
People will and do compare the interface to the
likes of OS X as their measure of beauty -- and this is something worth
working on.

the goal of GNUstep developper is not to do something like MacOSX.
It is to do something to do better than OPENSTEP ( and that not the
same challenge )
It is easier in some way, harder in other

Post by Jesse Ross
I have received more than one email stating that if Nesedah
were implemented as the out-of-the-box theme on a GNUstep-derived distro,
they would be more tempted to try GNUstep and try Linux or another Free
OS. We might not win all those people over, but even getting a few more
bodies in the mix would be helpful.

Win what ?
You have something to sell ?

I'm not saying that you should not do this.
I just want to be sure that you don't follow the Apple errors and that
you are ready
to do something that will be
better than OSX
better than OPENSTEP
... for work with !

Fabien

[Jesse Ross]

Post by Fabien VALLON

Post by Jesse Ross
I have received more than one email stating that if Nesedah
were implemented as the out-of-the-box theme on a GNUstep-derived
distro, they would be more tempted to try GNUstep and try Linux or another
Free OS. We might not win all those people over, but even getting a few
more bodies in the mix would be helpful.

Win what ?
You have something to sell ?

I think the goal of open source is to make really great software that
people want to use. If no one knows about your project, then no one will
use it. It's important, then, to try to get mindshare: to get people to
look at, try, and talk about your project. If you don't have mindshare,
you don't have people using your software.

You get mindshare by making demos of things that are so cool (from either
an aesthetic standpoint or a functional one) that people want to try them
out. I don't use a Mac just because it's pretty -- I use it because
underneath all that glitz is a system that helps me get stuff done. But I
first installed OS X on my system because it had eye candy and things I
wanted to try out. I checked out the Luminocity videos <
http://www.gnome.org/~seth/blog/xshots > because I wanted to see what all
the buzz was about -- and now I want to try it!

It's hard to advertise technical merits to a non-technical crowd, and
that's the problem I see with GNUstep. It's got most of the same features
as OS X under the hood -- so why does it have such a smaller userbase?
It's certainly got OS X beat on price. And it's got it beat on the fact
that you can run GNUstep on your old PC at home. Part of the issue might
be that Apple can spend tons of money on marketing, but part of it is also
the fact that GNUstep doesn't make for as good of a demo as OS X does, and
is thus harder to sell your average user on. If you show Joe Shmoe Aqua
and GNUstep, side by side, which will they want to try first? Maybe
GNUstep (and NeXTSTEP by that account) is more functional that Aqua, but
if you don't get people to try your software, you'll never have a chance
to keep them around for them to see the productivity advantages it gives
them.

It's not about making money or selling products. It's about how do you get
someone to use your software. Every new user is a win for you and a boost
in the life of the project. And some of those users might be developers,
who will make more software, which will attract more users, etc, etc. It's
a good cycle we need to encourage, and I think improving the look of
GNUstep is a good step down that path.


J.

[M. Uli Kusterer]

Post by Jesse Ross
It's hard to advertise technical merits to a non-technical crowd, and
that's the problem I see with GNUstep. It's got most of the same features
as OS X under the hood -- so why does it have such a smaller userbase?
It's certainly got OS X beat on price. And it's got it beat on the fact
that you can run GNUstep on your old PC at home. Part of the issue might
be that (...)

While I agree with Jesse, there is one point I find odd:

Many people in the GNUstep community don't seem to have noticed that
GNUstep isn't finished. I mean, even the libraries. In Cocoa, you can
actually scale an NSImage. Last I worked with GNUstep, that didn't
work. Same for NSImages used as patterns. There are also still lots
of problems installing GNUstep on various systems, and most apps are
still so new that they're still quite buggy.

There's a reason why GNUstep isn't 1.0 yet. GNUstep is great, but
good things take time to develop, especially huge stuff like
OpenStep. GNUstep is very close to being suitable for a first release
to developers. As soon as Gorm and DevCenter are more complete
(they're making incredible progress in leaps and bounds, but they're
not yet there).

Post by Jesse Ross
It's not about making money or selling products. It's about how do you get
someone to use your software. Every new user is a win for you and a boost
in the life of the project. And some of those users might be developers,
who will make more software, which will attract more users, etc, etc. It's
a good cycle we need to encourage, and I think improving the look of
GNUstep is a good step down that path.

I agree. It will also help to keep/raise interest among developers.
While GNUstep is one of the most modern usable designs for
programming environments out there, it looks eighties. By making it
look more modern, you may attract very busy developers who so far
looked at the screen shots and went: I've used 1987-era tools, I have
better stuff now. Yes, that may have been a premature decision on
their part, but there are good people you'd *want* on a project that
make such decisions, and by showing in the UI that we actually *are*
modern, people will come close enough to actually look at the design.

The NeXT look is good, but it was designed with certain efficiency
and display constraints. Few colors, 30MHz or so... Aqua's drop
shadows may look gratuitous, but they actually made OS 9's thick
borders obsolete. Aqua Windows *don't have borders* (try it -- turn
off the shadows). They only have the shadow, through which you can
see other windows. So, it actually makes more effective use of screen
space in that regard.

[Nicolas Roard]

Post by M. Uli Kusterer

Post by Jesse Ross
It's hard to advertise technical merits to a non-technical crowd, and
that's the problem I see with GNUstep. It's got most of the same features
as OS X under the hood -- so why does it have such a smaller userbase?
It's certainly got OS X beat on price. And it's got it beat on the fact
that you can run GNUstep on your old PC at home. Part of the issue might
be that (...)

Many people in the GNUstep community don't seem to have noticed that
GNUstep isn't finished. I mean, even the libraries. In Cocoa, you can
actually scale an NSImage. Last I worked with GNUstep, that didn't
work. Same for NSImages used as patterns. There are also still lots
of problems installing GNUstep on various systems, and most apps are
still so new that they're still quite buggy.

Well, of course things aren't perfect, far from it. Though the libs
are largelly useable,
and to take your example of NSImage scaling, that works very well, and
I use it in my programs..
(heck, even in Camaelon). About NSImages used as patterns, I guess you
means with NSColor ? yes, that doesn't work, and that would require
backend support. On the other hand, it's not much needed.
But yes, the libs aren't all finished, etc., even if things improves daily.
That's why there's a bug report system :-)

Post by M. Uli Kusterer
There's a reason why GNUstep isn't 1.0 yet. GNUstep is great, but
good things take time to develop, especially huge stuff like
OpenStep. GNUstep is very close to being suitable for a first release
to developers. As soon as Gorm and DevCenter are more complete
(they're making incredible progress in leaps and bounds, but they're
not yet there).

Yes, things are in progress..

Post by M. Uli Kusterer

Post by Jesse Ross
It's not about making money or selling products. It's about how do you get
someone to use your software. Every new user is a win for you and a boost
in the life of the project. And some of those users might be developers,
who will make more software, which will attract more users, etc, etc. It's
a good cycle we need to encourage, and I think improving the look of
GNUstep is a good step down that path.

I agree. It will also help to keep/raise interest among developers.
While GNUstep is one of the most modern usable designs for
programming environments out there, it looks eighties. By making it
look more modern, you may attract very busy developers who so far
looked at the screen shots and went: I've used 1987-era tools, I have
better stuff now. Yes, that may have been a premature decision on
their part, but there are good people you'd *want* on a project that
make such decisions, and by showing in the UI that we actually *are*
modern, people will come close enough to actually look at the design.

I fully agree to that. It's not even illogical -- you look at a
project which tell "hey we're great and powerful", yet they look like
something done in the 80's. Your first opinion is, if they don't
bother with their look, it's probably because their stuff isn't that
great / not finished. Which is not all that wrong :-)
-- you should bother about the look after you at least have something
good to show.

Post by M. Uli Kusterer
The NeXT look is good, but it was designed with certain efficiency
and display constraints. Few colors, 30MHz or so... Aqua's drop
shadows may look gratuitous, but they actually made OS 9's thick
borders obsolete. Aqua Windows *don't have borders* (try it -- turn
off the shadows). They only have the shadow, through which you can
see other windows. So, it actually makes more effective use of screen
space in that regard.

Agree, again.

[Kory Talmage]

Post by Jesse Ross
You get mindshare by making demos of things that are so cool (from either
an aesthetic standpoint or a functional one) that people want to try them
out. I don't use a Mac just because it's pretty -- I use it because
underneath all that glitz is a system that helps me get stuff done. But I
first installed OS X on my system because it had eye candy and things I
wanted to try out. I checked out the Luminocity videos <
http://www.gnome.org/~seth/blog/xshots > because I wanted to see what all
the buzz was about -- and now I want to try it!

You're right, that Cairo Stuff is really interesting. Moving the UI
load to the GPU is a good idea in my opinion. Anyone know if this is
something implemented under X11 or the WM? So for example, can GnuStep
make use of this technology? Not just for eyecandy, but a vectorized
UI seems to have a lot of benefits. Displays are becoming more and
more Hi Def ;-)

All modern UIs seems to be heading this direction. Like with Quartz 2D
on Mac OS, Longhorns copy of SVG, and Cairo on X11. I know, it
probably started with nextstep + postscript.

Kory

[Nicolas Roard]

Post by Kory Talmage

Post by Jesse Ross
You get mindshare by making demos of things that are so cool (from either
an aesthetic standpoint or a functional one) that people want to try them
out. I don't use a Mac just because it's pretty -- I use it because
underneath all that glitz is a system that helps me get stuff done. But I
first installed OS X on my system because it had eye candy and things I
wanted to try out. I checked out the Luminocity videos <
http://www.gnome.org/~seth/blog/xshots > because I wanted to see what all
the buzz was about -- and now I want to try it!

You're right, that Cairo Stuff is really interesting. Moving the UI
load to the GPU is a good idea in my opinion. Anyone know if this is
something implemented under X11 or the WM? So for example, can
GnuStep make use of this technology? Not just for eyecandy, but a
vectorized UI seems to have a lot of benefits. Displays are becoming
more and more Hi Def ;-)

Well.. we *already* have a vectorized UI :-D (remember, we started with
DPS)
-gui doesn't work with pixels, and the graphic operations are just
rendered by a backend at a certain DPI.
that's why you have antialiasing for everything using the art backend,
and no antialiasing with the xlib backend.

Post by Kory Talmage
All modern UIs seems to be heading this direction. Like with Quartz
2D on Mac OS, Longhorns copy of SVG, and Cairo on X11. I know, it
probably started with nextstep + postscript.

yup.

Banlu started a Cairo backend -- it kinda work, apart for the font
drawing afaik, but he put it on hold until the Cairo api stabilise. In
fact he started it way before GNOME, but I guess GNOME will have
something working before us (yup, not many programmers on GNUstep
doesn't help ..)

[Kory Talmage]

Post by Fabien VALLON
The problem is that most gnustep-ui people never used NexSTEP, and
don't even use GNUstep but OSX
( see Mailer in headers )

You're right, I have never used NextStep on NeXT hardware, I've only
used OpenStep on "white" hardware. And yes I use OS X for email since
GnuStep doesn't exactly come with any Japanese input methods, and I
need Japanese for work reasons. I really wish GnuStep came with
language input methods (native obj-c one), and maybe we will in the
future as Japanese and other international developers gain interest in
the GnuStep project.

Post by Fabien VALLON
The goal is not to have a nicer UI, the goal is to not make the same
errors that Apple does.

Yup, I totally agree. But there's nothing wrong with implementing some
good Apple has done as well. They have attracted a lot of users since
they brushed up OS X, not just by eyecandy. I'm not saying Aqua is
what GnuStep needs, but a modern look and function would help while
maintaining the NeXT legacy. And I really think that is what Nesedah
is getting close at doing. If old NeXT users insist on continuing the
exact NeXT look, NeXT hardware is available on ebay ;-). But for
GnuStep to continue to improve, the UI is most definitely a part that
needs to change.

Post by Fabien VALLON
An odd hybrid (mix OS 9 / OPENSTEP ) UI paragnism

Rhapsody? Now, that was a mistake ;-)

Post by Fabien VALLON
The good point is : Yes we/you can do better ( better than NeXT of
course , choose the hardest :) )

Sure, GnuStep Project should aim to beat both NeXT and Apple.

I love GnuStep, and use it on most of my newer x86 hardware. But
seriously, if it looked like some of the Nesedah mockups I'd be a LOT
happier.

Post by Fabien VALLON
GNUstep doesn't have a decent replacement for Photoshop, Flash,
SubEthaEdit or Safari

Hopefully, when GCC4 is released (or was is 4.1), we can compile Camino
with just a few tweaks. I'm more concerned about office applications.


Kory

[Fabien VALLON]

Post by Kory Talmage

Post by Fabien VALLON
The problem is that most gnustep-ui people never used NexSTEP, and
don't
even use GNUstep but OSX
( see Mailer in headers )

You're right, I have never used NextStep on NeXT hardware, I've only
used
OpenStep on "white" hardware. And yes I use OS X for email since
GnuStep
doesn't exactly come with any Japanese input methods, and I need
Japanese for
work reasons. I really wish GnuStep came with language input methods
(native
obj-c one), and maybe we will in the future as Japanese and other
international developers gain interest in the GnuStep project.

Post by Fabien VALLON
The goal is not to have a nicer UI, the goal is to not make the same
errors
that Apple does.

Yup, I totally agree. But there's nothing wrong with implementing
some good
Apple has done as well. They have attracted a lot of users since
they
brushed up OS X, not just by eyecandy. I'm not saying Aqua is what
GnuStep
needs, but a modern look and function would help while maintaining
the NeXT
legacy. And I really think that is what Nesedah is getting close at
doing.
If old NeXT users insist on continuing the exact NeXT look, NeXT
hardware is
available on ebay ;-).

If you want something sexy you have OSX or enlightenement :)
Be carefull those old NeXT users are often GNUstep developers :)

Post by Kory Talmage
But for GnuStep to continue to improve, the UI is
most definitely a part that needs to change.

I agree

Post by Kory Talmage

Post by Fabien VALLON
The good point is : Yes we/you can do better ( better than NeXT of
course ,
choose the hardest :) )

Sure, GnuStep Project should aim to beat both NeXT and Apple.
I love GnuStep, and use it on most of my newer x86 hardware. But
seriously,
if it looked like some of the Nesedah mockups I'd be a LOT happier.

Sorry but
Loading Image...

is still better:

- Icons are quite good and the look is really clear
- There is a shelf
- There is a real path view
- minimized windows don't bloat the dock ( they should not be there :
this is OSX / Windows mess )
- no blur on fonts
- There is not way to logout
- Fiend with workspace switcher would be better than the "Workspace
switcher"

Post by Kory Talmage

Post by Fabien VALLON
GNUstep doesn't have a decent replacement for Photoshop, Flash,
SubEthaEdit or Safari

Hopefully, when GCC4 is released (or was is 4.1), we can compile
Camino with
just a few tweaks. I'm more concerned about office applications.

I don't think Obj-C++ is into the gcc-4 yet.
Is it ?

Cheers
Fabien

[Nicolas Roard]

Post by Fabien VALLON

Post by Kory Talmage
If old NeXT users insist on continuing the exact NeXT look, NeXT
hardware is
available on ebay ;-).

If you want something sexy you have OSX or enlightenement :)

Come on, fabien, that's irrelevent ..

Post by Fabien VALLON
Be carefull those old NeXT users are often GNUstep developers :)

Yes, but not all of them absolutely wants the EXACT same *look*.
They want the same feel, surely. The same look ? not so sure.
Actually, LOTS of ex-NeXT developers are now on OSX (certainly more
than on GNUstep), and their reaction to GNUstep contradicts your
opinon: they think it's ugly and old looking.

Personally, I LIKE the NeXT UI, but I also acknowledge that it looks dated;
we should try to keep the same feel as in NeXTSTEP, I agree, but frankly if
we can improve the look, the better it is. And Nesedah, while not perfect, is
imho a good step in that direction. Critics like "it's too blurry /
uncontrasted"
can and will be worked out..

Post by Fabien VALLON

Post by Kory Talmage
But for GnuStep to continue to improve, the UI is
most definitely a part that needs to change.

I agree

So ?..

Post by Fabien VALLON

Post by Kory Talmage
if it looked like some of the Nesedah mockups I'd be a LOT happier.

Sorry but
http://www.macobserver.com/columns/whatsnext/screenshots/desktop1.gif
- Icons are quite good and the look is really clear

You know we are working on the icons :-)
and yes, the NeXT icons were really nice, but they also look a bit dated now.
Furthermore, we CAN'T use them ... so we need to create new ones, as the
currents icons packaged by GNUstep are.. well... you know :-)

Post by Fabien VALLON
- There is a shelf

Uh, that's unrelated to Nesedah.. so I guess you're talking about the
mockup #1 ..

Post by Fabien VALLON
- There is a real path view

Here I really think the "small" path is a better idea. At least it
should be configurable.

Post by Fabien VALLON
this is OSX / Windows mess )

depends; with a NeXT dock they surely shouldn't be in; with other
solutions, it depends.

Post by Fabien VALLON
- no blur on fonts

Unrelated..

Post by Fabien VALLON
- There is not way to logout
- Fiend with workspace switcher would be better than the "Workspace
switcher"

What do you mean ?

Post by Fabien VALLON

Post by Kory Talmage
Hopefully, when GCC4 is released (or was is 4.1), we can compile
Camino with
just a few tweaks. I'm more concerned about office applications.

I don't think Obj-C++ is into the gcc-4 yet.
Is it ?

No, it's not. There's chances it will be in 4.1, but we're at 4.0 right now.

[Fabien VALLON]

Post by Nicolas Roard

Post by Fabien VALLON

Post by Kory Talmage
If old NeXT users insist on continuing the exact NeXT look, NeXT
hardware is
available on ebay ;-).

If you want something sexy you have OSX or enlightenement :)

Come on, fabien, that's irrelevent ..

irrelevent like "If old NeXT users insist on continuing the exact
NeXT look, NeXT hardware is
available on ebay " ? ;-)

Post by Nicolas Roard

Post by Fabien VALLON
Be carefull those old NeXT users are often GNUstep developers :)

Yes, but not all of them absolutely wants the EXACT same *look*.
They want the same feel, surely. The same look ? not so sure.
Actually, LOTS of ex-NeXT developers are now on OSX (certainly more
than on GNUstep), and their reaction to GNUstep contradicts your
opinon: they
think it's ugly and old looking.

Yes GNUstep looks ugly ! I agree.
OPENSTEP looks alittle bit dated but clear, and easy to work with.

Post by Nicolas Roard
Personally, I LIKE the NeXT UI, but I also acknowledge that it looks dated;
we should try to keep the same feel as in NeXTSTEP, I agree, but frankly if
we can improve the look, the better it is. And Nesedah, while not perfect, is
imho a good step in that direction. Critics like "it's too blurry /
uncontrasted"
can and will be worked out..

This is suggestions ...

Post by Nicolas Roard

Post by Fabien VALLON

Post by Kory Talmage
But for GnuStep to continue to improve, the UI is
most definitely a part that needs to change.

I agree

So ?..

So what (tm) ?

GNUstep need to have a working AppKit first isn't it ?
A working Workspace
A good session manager
A minimalist & good Window Manager ...
A guidline ( there is mockup an no guideline :) ..

And probably and refreshing UI but don't forget that user don't use
mockup ;-)

Post by Nicolas Roard

Post by Fabien VALLON

Post by Kory Talmage
if it looked like some of the Nesedah mockups I'd be a LOT happier.

Sorry but
http://www.macobserver.com/columns/whatsnext/screenshots/desktop1.gif
- Icons are quite good and the look is really clear

You know we are working on the icons :-) and yes, the NeXT icons were
really
nice, but they also look a bit dated now.
Furthermore, we CAN'T use them ... so we need to create new ones, as the
currents icons packaged by GNUstep are.. well... you know :-)

Yes I know !:)

Post by Nicolas Roard

Post by Fabien VALLON
- There is a shelf

Uh, that's unrelated to Nesedah.. so I guess you're talking about the
mockup #1 ..

Yes.
The mockup show that you are ready to make the same error that Apple
did.

Post by Nicolas Roard

Post by Fabien VALLON
- There is a real path view

Here I really think the "small" path is a better idea. At least it
should be configurable.

it shoud have a scrollbar :)

Post by Nicolas Roard

Post by Fabien VALLON
- There is not way to logout
- Fiend with workspace switcher would be better than the "Workspace
switcher"

What do you mean ?

Something like Fiend.app ( or WindowMaker clip )
or part of the dock that are workspace centric and another part that
is the same on all workspace.
Need more brain storming .. :)

Fabien

[Nicolas Roard]

Post by Fabien VALLON

Post by Nicolas Roard

Post by Fabien VALLON

Post by Kory Talmage
If old NeXT users insist on continuing the exact NeXT look, NeXT
hardware is
available on ebay ;-).

If you want something sexy you have OSX or enlightenement :)

Come on, fabien, that's irrelevent ..

irrelevent like "If old NeXT users insist on continuing the exact
NeXT look, NeXT hardware is
available on ebay " ? ;-)

Well, that was irrelevant but for other reasons : mainly because the NeXT
look will still be available for GNUstep, whatever we do with Camaelon !

Post by Fabien VALLON

Post by Nicolas Roard

Post by Fabien VALLON
Be carefull those old NeXT users are often GNUstep developers :)

Yes, but not all of them absolutely wants the EXACT same *look*.
They want the same feel, surely. The same look ? not so sure.
Actually, LOTS of ex-NeXT developers are now on OSX (certainly more
than on GNUstep), and their reaction to GNUstep contradicts your
opinon: they
think it's ugly and old looking.

Yes GNUstep looks ugly ! I agree.
OPENSTEP looks alittle bit dated but clear, and easy to work with.

Well, as the only differences between GNUstep and OPENSTEP are the
icons ... I would say that most people argue abot the widgets looks, not
the icons (but yes, the icons plays a very important part, of course).

Post by Fabien VALLON

Post by Nicolas Roard
imho a good step in that direction. Critics like "it's too blurry /
uncontrasted"
can and will be worked out..

This is suggestions ...

But at least thoses are constructive critics :-) -- Nesedah is pretty, but
it's also right that it's a bit uncontrasted/fuzzy when you use it in real life.
I think using a more contrasted Nesedah will probably solve that though.

Post by Fabien VALLON

Post by Nicolas Roard

Post by Fabien VALLON

Post by Kory Talmage
But for GnuStep to continue to improve, the UI is
most definitely a part that needs to change.

I agree

So ?..

So what (tm) ?

So why are you advocating against Nesedah, which is an effort to
change the UI *look* ?

Post by Fabien VALLON
GNUstep need to have a working AppKit first isn't it ?
A working Workspace
A good session manager
A minimalist & good Window Manager ...
A guidline ( there is mockup an no guideline :) ..

Of course, but all of that is beyond Nesedah itself !
For the guideline, we have one : the NeXT guideline. At the moment
it's still our "default" guideline.

Post by Fabien VALLON

Post by Nicolas Roard

Post by Fabien VALLON
- There is a shelf

Uh, that's unrelated to Nesedah.. so I guess you're talking about the
mockup #1 ..

Yes.
The mockup show that you are ready to make the same error that Apple
did.

That mockup was the first thing jesse sent to the mailing list, and it
was just that, a mockup.
Not a "plan" of what we want to do. Particularly, lots of people
voiced concerns against the "dock"
shown into that mockup. It's not because it's in the mockup that
something will automatically turns
up in real life :-)

Post by Fabien VALLON

Post by Nicolas Roard

Post by Fabien VALLON
- There is a real path view

Here I really think the "small" path is a better idea. At least it
should be configurable.

it shoud have a scrollbar :)

And I think I already answered that :-)

Cheers,

[Fabien VALLON]

Post by Nicolas Roard

Post by Fabien VALLON
So what (tm) ?

So why are you advocating against Nesedah, which is an effort to
change the UI *look* ?

I am not.

I am just saying : "don't forget that GNUstep has grow with the NeXT
spirit"
The mockup already show that you are in another one.
This is a good startup but I only said that it currently not
" better than than NeXT was (tm)"
but only
" worse than Aqua is".

I know it is just the start and I will be really pleased to test,
suggest , patch it ..


Fabien

[Jesse Ross]

Post by Fabien VALLON

Post by Nicolas Roard

Post by Fabien VALLON
- There is a shelf

Uh, that's unrelated to Nesedah.. so I guess you're talking about the
mockup #1 ..

Yes.
The mockup show that you are ready to make the same error that Apple
did.

Post by Nicolas Roard

Post by Fabien VALLON
- There is a real path view

Here I really think the "small" path is a better idea. At least it
should be configurable.

it shoud have a scrollbar :)

Concept 01, the mockup, was only in the beginning stages when I showed it
to the list. Please, DO NOT take anything from there as the current
direction of the UI developers. It was my work, and mine alone, to start
to get some initial ideas on paper (er... on screen :). The only interface
any of us in the UI team is actively developing upon is the latest,
concept 21 <
http://jesseross.com/clients/gnustep/ui/concepts/21/camaelon_nesedah.png

Post by Fabien VALLON
. We've made a lot of decisions in the name of usability that are

definitely not reflected in 01.

The goals of Nesedah (as I see them) are:

- To modernize the look of GNUstep, but retain as much of the NeXT *aura*
as possible
- To refine control appearance so controls with similar interaction
methods are similar in style (which will make the interface more
discoverable)
- To fix aesthetic problems with GNUstep (margins, padding)
- To increase the attractiveness of the interface for better
"demo-ability" (to make people say, "I want to try that out")

The UI team is not yet to the point of redesigning applications for
increased usability. That will come after Nesedah is finalized. As such,
we can't really make any predictions as to how apps like GWorkspace will
look. Concept 01 was just my creative doodlings, to get the point across
that we *can* make a new appearance for GNUstep, and that I am a
professional designer and can help the team. It is by no means our Bible
for what we want GNUstep to look like.

I hope that clears things up.


J.

[Kory T]

Post by Fabien VALLON

Post by Nicolas Roard

Post by Fabien VALLON

Post by Kory Talmage
If old NeXT users insist on continuing the exact NeXT look, NeXT
hardware is
available on ebay ;-).

If you want something sexy you have OSX or enlightenement :)

Come on, fabien, that's irrelevent ..

the smiley implies it was a joke guys.

I agree that a lot of the other parts of GnuStep need work, but the UI
should be worked on now. Unfortunately better UI does = more users. I
do wish people would just notice how great the OpenStep Dev environment
is, but as a first step into OpenStep/GnuStep, an attractive look will
be a big help. But then again, I'm not a GnuStep Developer, just an
user. This is all an user opinion.

Post by Fabien VALLON
- no blur on fonts

Do you mean anti-aliased? I personally think this is a must now days.
Anti-Aliased looks so much better on LCD, and a lot easier on the eyes.
As resolutions on displays get larger and pixels get smaller and
smaller it will become a requirement for UIs to use good AA.

Kory

[Charles Philip Chan]

Post by Nicolas Roard
Here I really think the "small" path is a better idea. At least it
should be configurable.

Here I disagree with- the large icons are much better drop targets.

Charles

[M. Uli Kusterer]

Post by Fabien VALLON

Post by Kory Talmage

Post by Fabien VALLON
The good point is : Yes we/you can do better ( better than NeXT of
course , choose the hardest :) )

Sure, GnuStep Project should aim to beat both NeXT and Apple.
I love GnuStep, and use it on most of my newer x86 hardware. But
seriously, if it looked like some of the Nesedah mockups I'd be a
LOT happier.

Sorry but
http://www.macobserver.com/columns/whatsnext/screenshots/desktop1.gif
- Icons are quite good and the look is really clear
- There is a shelf
- There is a real path view
- minimized windows don't bloat the dock ( they should not be there
: this is OSX / Windows mess )
- no blur on fonts
- There is not way to logout
- Fiend with workspace switcher would be better than the "Workspace switcher"

However, most of these things have *nothing* to do with Nesedah.
Font anti-aliasing is already available in GNUstep right now and can
be turned off. It uses FreeType, AFAIK, so it's as good/bad as the
anti-aliasing in all other open-source desktops.

The icons are debatable. IMHO especially the house is way too busy
as an icon, as is the calendar. And the icons have several different
styles and perspectives.

Shelf, Workspace etc. are mainly the domain of the GWorkspace etc.,
so I won't go into those either. Nesedah may provide button designs
for those, but it's their decision whether they'll work like Apple's
dock (which I agree is trying to do too many things at once), or
WindowMaker (which confuses the hell out of me because application
tiles keep popping up anywhere on the screen, some don't pop up at
all that I want to, and I don't understand at all which ones dock and
which ones don't...) Of course, I may make suggestions to them, but
it's their projects.

Logout/Login: Also not really a Nesedah issue. I personally think
"Quit" and "Hide" are too prominent in the NeXT main menu (and there
should only be submenus in the main menu, no actual items, to make it
less dangerous for newbies to use), and Logout and Quit especially
are so rarely used (compared to all other menu items, which are used
*several times* during the lifetime of an app, after all), that I'd
make them less easily accessible. I could see an argument made for
"Hide", which is a very convenient feature, and used constantly by
many NeXT users.

[Alex Perez]

Post by Fabien VALLON

Post by Kory Talmage

Post by Fabien VALLON
The good point is : Yes we/you can do better ( better than NeXT of
course , choose the hardest :) )

Sure, GnuStep Project should aim to beat both NeXT and Apple.
I love GnuStep, and use it on most of my newer x86 hardware. But
seriously, if it looked like some of the Nesedah mockups I'd be a LOT
happier.

Sorry but
http://www.macobserver.com/columns/whatsnext/screenshots/desktop1.gif
- Icons are quite good and the look is really clear
- There is a shelf
- There is a real path view
this is OSX / Windows mess )
- no blur on fonts
- There is not way to logout
- Fiend with workspace switcher would be better than the "Workspace switcher"

However, most of these things have *nothing* to do with Nesedah. Font
anti-aliasing is already available in GNUstep right now and can be
turned off. It uses FreeType, AFAIK, so it's as good/bad as the
anti-aliasing in all other open-source desktops.
The icons are debatable. IMHO especially the house is way too busy as
an icon, as is the calendar. And the icons have several different styles
and perspectives.

The House is most definately far too "busy". Seriously, what does a tree
have to do with your home directory? Nothing. Not a damn thing. Also,
that calendar icon is just IMHO ugly.

Shelf, Workspace etc. are mainly the domain of the GWorkspace etc., so
I won't go into those either. Nesedah may provide button designs for
those, but it's their decision whether they'll work like Apple's dock
(which I agree is trying to do too many things at once), or WindowMaker
(which confuses the hell out of me because application tiles keep
popping up anywhere on the screen, some don't pop up at all that I want
to, and I don't understand at all which ones dock and which ones
don't...) Of course, I may make suggestions to them, but it's their
projects.

If actual windowmaker appicons are not appearing in the lower-left of
your screen by default, that is a bug in WM. Please file a report.

Logout/Login: Also not really a Nesedah issue.

Correct, this is a desktop issue, and has essentially nothing to do with
Nesedah. Join the etoile lists and have those discussions there, not
here. This is a list for UI discussion, not general GNUstep desktop
discussion.

I personally think
"Quit" and "Hide" are too prominent in the NeXT main menu (and there
should only be submenus in the main menu, no actual items, to make it
less dangerous for newbies to use), and Logout and Quit especially are
so rarely used (compared to all other menu items, which are used
*several times* during the lifetime of an app, after all), that I'd make
them less easily accessible. I could see an argument made for "Hide",
which is a very convenient feature, and used constantly by many NeXT users.

Hm, I have to strongly disagree here, especially WRT to the "there
should only be submenus in the main menu". The vertical menus work best
when there are more items in the root and fewer items in the menu tree
(ie more than one or two levels deep). There's nothing wrong at all with
having a root item called "new" for instance, in a contact management
app where that feature is going to be used all the time.IMHO, if you're
only going to have two items in a submenu, it should probably not be in
a submenu. I think part of the reason why people say they don't like the
vertical menus is because GNUstep programmers to not use them
properly, as many NeXT programmers did. Look at some screenshots of
older NeXT apps, and you will often see the menus of complex apps have
many, many items in the root menu. This is the way it was designed to
be. Obviously, every situation has excess, but honestly, this is how it
was meant to be used. This is a VERY different philosophy from the
OSX-ish horizontal menu paradigm, and this is also why runtime hacks
like WildMenus (which I think is cool) don't always work very well. The
way menus are designed needs to be differeent in a lot of cases (but not
all) depending on whether you've got horizontal or vertical menus.

Also, IMHO, quit needs to be on the root menu because in most steppish
apps, you can close the main app window without closing the program (as
opposed to windows, where, when I close the firefox window by clicking
on the X button in the upper right, it's closed, end of story.

Food for thought.

Cheers,
Alex Perez

[Alex Perez]

Post by Kory T
I think the new themes looks great.
It's time Gnustep moved on to a new look and feel while keeping the
original OpenStep purpose. There seems to be two types Gnustep users,
ones that insist the orginal NeXT look is superior, and others that
realize we're in the 21st century now and need to move on. I don't want
to say GnuStep needs to compete with Gnome or KDE, but it would be nice
if it had the same kind of userbase. More users usually = more
apps,devs,sponsors,etc. I think the Nesedah concepts are a good start
for the UI part becoming more attractive for new users (and long-time
users like myself). Apple had a lot of complaints from OS 9 users when
aqua first came out, but I don't see too many complaining about OS X now
;-).

Okay, Mr. "two different capitalizations of GNUstep in one
paragraph"...it's GNUstep or gnustep (for the lazy), not Gnustep, or
GnuStep ;-)

As for the "default theme", I hate to burst your bubble, but this will
be the default theme of Etoile, not of GNUstep. We do not have any
control over the default theme of GNUstep.

Post by Kory T
Kory T
PS. A few comments on the Nesedah concepts. I personally like the
overall feel of concept 01 and 10 the best. I especially like the menu
and dock/sidebar? on concept 01, and concept 10 is what I image a modern
nextstep ui to look like. It's very nice because it still kinda
resembles nextstep, but much more modern looking.

Post by Jesse Ross

Post by Fabien VALLON

Post by Narcoleptic Electron
http://www.roard.com/screenshots/screenshot_theme48.png

Sorry but http://www.levenez.com/NeXTSTEP/Mail.gif
is still better

May I ask what it is about the new interface that you're not particularly
happy with? If you have some suggestions for ways of improving it to
provide the best experience for users who like the original NeXT look,
that would be appreciated.

Post by Fabien VALLON
What about good icons and good UI/guidelines/suggestion for GNUstep ?

We're working on those as well -- I've been a bit busy lately so I haven't
gotten to all the icons I have on my plate (hang in there, guys!). I will
also be working out solutions to the problems like margins and padding
that some of the controls have. If you have other suggestions where the UI
could use a boost, let me know and we'll see if we can provide a solution.
J.
_______________________________________________
Gnustep-ui mailing list
https://mail.gna.org/listinfo/gnustep-ui

[MJ Ray]

Okay, Mr. "two different capitalizations of GNUstep [...]

Can you leave the sniping at the door, Mr "user-hostile
whole-quote emails"?

[Nicolas Roard]

Post by Narcoleptic Electron
Therefore, I have changed my mind on arrow buttons: for the disabled
scroll bar, get rid of them.

hurrah ;-)

Post by Narcoleptic Electron
I still disagree that using an empty trough is the answer, though, for
reasons I've given previously. Therefore, instead of an empty trough,
what do you think of using a disabled, full-sized scroll handle (no
bevel, etc.) with no arrow buttons? I think that solution would
satisfy everyone.

No, because it will attract unnecessary attention and furthermore it
will look
like a button. I prefer it to be clearly distinct that the normal state
so there's no
confusion.

[Narcoleptic Electron]

Post by Nicolas Roard

Post by Narcoleptic Electron
I still disagree that using an empty trough is the answer, though, for
reasons I've given previously. Therefore, instead of an empty trough,
what do you think of using a disabled, full-sized scroll handle (no
bevel, etc.) with no arrow buttons? I think that solution would
satisfy everyone.

No, because it will attract unnecessary attention and furthermore it
will look
like a button.

Not if it is a *disabled* scroll handle.

[M. Uli Kusterer]

Post by Narcoleptic Electron
I still disagree that using an empty trough is the answer, though, for
reasons I've given previously. Therefore, instead of an empty trough,
what do you think of using a disabled, full-sized scroll handle (no
bevel, etc.) with no arrow buttons? I think that solution would
satisfy everyone.

No, because it will attract unnecessary attention and furthermore it will look
like a button. I prefer it to be clearly distinct that the normal
state so there's no
confusion.

Nicolas,

it won't look like a button. He asked to remove the gradient etc. In
that case, it would look more like an empty progress bar (though
we'll obviously have to make sure they aren't easily mixed up).

As to attracting attention, it would actually look less prominent,
because the scroller handle is lighter, and thus doesn't have as much
visual impact as the current, dark trough.

[M. Uli Kusterer]

Post by Narcoleptic Electron
I still disagree that using an empty trough is the answer, though, for
reasons I've given previously. Therefore, instead of an empty trough,
what do you think of using a disabled, full-sized scroll handle (no
bevel, etc.) with no arrow buttons? I think that solution would
satisfy everyone.

As you probably saw from my previous message, I can live with that.
Essentially, it's what I suggested there, even though I probably
didn't phrase it as concisely.

That said, I do think it should be noted that what we're doing here
is still a trade-off. The trade-off is between cluttering the
interface by disabling the scroller arrows, and removing GUI elements
when they are unavailable. Both aren't desirable, and in all other
cases I usually tend towards not removing objects from the screen. In
the case of a scroller, it could be argued that it's only small
elements of the scroller, and not the entire scroller, which *might*
confuse users less.

However, this is a point that would probably best be solved by doing
end-user testing, or by finding an example of end-user testing that
someone else has already performed on this topic.

[Narcoleptic Electron]

Post by M. Uli Kusterer
As you probably saw from my previous message, I can live with that.
Essentially, it's what I suggested there, even though I probably
didn't phrase it as concisely.
That said, I do think it should be noted that what we're doing here
is still a trade-off. The trade-off is between cluttering the
interface by disabling the scroller arrows, and removing GUI elements
when they are unavailable. Both aren't desirable, and in all other
cases I usually tend towards not removing objects from the screen. In
the case of a scroller, it could be argued that it's only small
elements of the scroller, and not the entire scroller, which *might*
confuse users less.

Yes, it seems we are in complete agreement here.

Post by M. Uli Kusterer
However, this is a point that would probably best be solved by doing
end-user testing, or by finding an example of end-user testing that
someone else has already performed on this topic.

I agree completely.

[Narcoleptic Electron]

Post by Narcoleptic Electron

Post by M. Uli Kusterer
As you probably saw from my previous message, I can live with that.
Essentially, it's what I suggested there, even though I probably
didn't phrase it as concisely.
That said, I do think it should be noted that what we're doing here
is still a trade-off. The trade-off is between cluttering the
interface by disabling the scroller arrows, and removing GUI elements
when they are unavailable. Both aren't desirable, and in all other
cases I usually tend towards not removing objects from the screen. In
the case of a scroller, it could be argued that it's only small
elements of the scroller, and not the entire scroller, which *might*
confuse users less.

Yes, it seems we are in complete agreement here.

I would also like to point out that if the disabled placeholder arrow
buttons are removed to eliminate clutter and extra lines, the line
between the disabled scroller and the empty bottom-left corner
placeholder square, if there is one, should also be removed for the
same reason.

I would also suggest, in the same vein, that disabled controls
(including the disabled scroll handle) are given a similar appearance
to this bottom-left placeholder square: same colour as the window,
flat, no gradient, and no drag notch.

[M. Uli Kusterer]

Post by Narcoleptic Electron
I would also like to point out that if the disabled placeholder arrow
buttons are removed to eliminate clutter and extra lines, the line
between the disabled scroller and the empty bottom-left corner
placeholder square, if there is one, should also be removed for the
same reason.

I don't really like that, as I've mentioned before. If we merge two
objects that, when active, are distinct, it will destroy the illusion
that this thing is simply the scroll bar that has changed. It will
actually look as if the scroller had disappeared.

Not to mention that it isn't really technically feasible, as in many
cases this little box isn't even an object, but rather just a hole
left where two scrollers and the window border meet.

Post by Narcoleptic Electron
I would also suggest, in the same vein, that disabled controls
(including the disabled scroll handle) are given a similar appearance
to this bottom-left placeholder square: same colour as the window,
flat, no gradient, and no drag notch.

I'll leave that one to Jesse. I'd personally prefer if disabled
objects remained slightly distinct from the window, but it did work
for MacOS 9's Platinum. It also still remains to be seen whether it's
a good idea to have non-applicable scrollers and disabled scrollers
look that similar.

But again, this is a job for the graphics designer and actual
usability studies.

[Narcoleptic Electron]

Post by M. Uli Kusterer
It also still remains to be seen whether it's
a good idea to have non-applicable scrollers and disabled scrollers
look that similar.

I don't think it's a problem; they are both disabled scrollers.

I think the terms are confusing. To make it easier to differentiate,
we could say that scrollers have the following properties:
- Enabled or disabled. Like any control, they can be enabled or
disabled (no gradient, etc.).
- On a track, or trackless. When no scrolling is possible (i.e. all
of the scroll view's contents fit inside the viewable area), no track
is shown (just scroll handle). Otherwise, it has a track.

A scroller with a track showing may be disabled (i.e. if the window is
not the main window). However, just because the scroller is disabled
doesn't mean it has to be trackless: in this case, the track serves to
show how the view is scrolled.

However, a trackless scroller has no choice but be disabled because
there is no way to interact with it. Actually, it is more specific to
say that the scroller isn't disabled, but the scroll handle, which is
its only visible element, is.

This latter part is why I suggested that disabled controls could look
like flat parts of the window: they act the same way as any other flat
part of the window, like labels and group boxes (and even the window
itself), which is to say that no interaction is possible. That's the
consistency angle; Jesse can incorporate that viewpoint into his
design angle as he sees fit.

[David Chisnall]

Post by Alex Perez
Does it view okay for people with various types of colorblindness? My
only concern is that the color of the text is also quite close to the
color of the surrounding background, which could be an issue for folks
with certain types of vision problems (and this is especially an issue
since the rest of the interface is much more high-contrast now.

People suffering from red-green colour blindness (about 90% of colour
blind people, as I recall) are unable to tell the difference between a
red and a green at the same intensity (e.g. traffic lights, or the
close and maximise buttons in OS X), but are very good at telling the
difference between different shades of red and of green. Since our
interface uses neither red nor green, this should not affect us at all.

People with complete colour blindness (I can't remember the medical
term. People who only see shades of grey) will have difficulty
distinguishing red Vs green Vs blue, but they will again have no
problem with Nesedah, since all of the different colours have different
brightness levels (see what the image looks like when converted to grey
scale to see what they would see).

The default configuration of a human has a much worse ability to
distinguish shades of blue than of either red or green (with red being
the easiest), and so it is important to keep the contrast quite high if
we are focussing on the blue end of the spectrum. Additionally, a
predominance of blue can adversely affect the brain's ability to
perceive shades of red and green, making a blue interface very bad for
anyone needing to work with accurate colours (e.g. graphic designers) -
this was why the graphite interface was added to OS X.

P.S. I still don't like the disabled scroll bars. They were a UI
mistake in Windows 3.0, and they are still one now.

[M. Uli Kusterer]

Post by David Chisnall
P.S. I still don't like the disabled scroll bars. They were a UI
mistake in Windows 3.0, and they are still one now.

Can you elaborate on that? Maybe a link, or a reference to a book
and quick summary? I'm not sure myself, so I'm looking for hard data
to back this up.

[Nicolas Roard]

Hi,

Post by Jesse Ross
http://jesseross.com/clients/gnustep/ui/concepts/
or
http://jesseross.com/clients/gnustep/ui/concepts/21/camaelon_nesedah.png
- Added what I personally like for the default button

Still not frankly fond of it.. :-/

Post by Jesse Ross
- Added what I would like to use as the default color (indigo)

looks ok for me -- blue/indigo is imho neutral enough.

Post by Jesse Ross
- Added notches in the title bar to indicate draggability

hmm... the idea is good, but I don't think it works -- as it is, we
don't really see them, and if we realize they are there, I doubt that
we associate them with "draggability". You would either have to continue
them all along the titlebar, or don't use them at all..

Post by Jesse Ross
- Changed the upper left corners on the box to be rounded, to be
better unified with the rest of the container labels

it's coherent, but I'm not too fond of it.. mainly because a lot of programs
expect square NSBox and this won't work that well with them.. but well..

In fact, there's a problem with the theming in general -- if we want the themes
to work transparently on any current gnustep apps, we need to stay as much as
possible within the current widgets sizes (because GNUstep uses fixed
positioning, like Cocoa).

Although I would say, we shouldn't bother with that, considering Nesedah will be
the default theme for Étoilé, and thus applications will be "required"
to look good
with it. Not that complex in fact as it just requires loading the gorm
files, do some
modifications, and save them. For non-étoilé apps, well, it will
depends on their
authors...

Post by Jesse Ross
- Increased the overall contrast

I agree with the previous mail from rob, as I also started to use
Nesedah, it looks ok,
but a bit too bright/uncontrasted. This #21 is slightly more
contrasted and it helps, but
I think you can push a little bit more the contrast.

Post by Jesse Ross
I'm really happy with where it's at at this point. Further changes I
make will be in an attempt to increase aesthetics.

I still find the "disable scrollbars" an horrible idea :-)

Cheers,

[Jesse Ross]

Post by Nicolas Roard

Post by Jesse Ross
- Changed the upper left corners on the box to be rounded, to be
better unified with the rest of the container labels

it's coherent, but I'm not too fond of it.. mainly because a lot of
programs expect square NSBox and this won't work that well with them..
but well..

As long as we leave the proper amount of spacing for the padding, it
should look okay.

Post by Nicolas Roard
In fact, there's a problem with the theming in general -- if we want the
themes to work transparently on any current gnustep apps, we need to
stay as much as possible within the current widgets sizes (because
GNUstep uses fixed positioning, like Cocoa).
Although I would say, we shouldn't bother with that, considering Nesedah
will be the default theme for Étoilé, and thus applications will be
"required" to look good
with it. Not that complex in fact as it just requires loading the gorm
files, do some
modifications, and save them. For non-étoilé apps, well, it will
depends on their
authors...

I think you're totally right. The whole point of the theme is to improve
the look of the interface. Making a theme that locks itself into retaining
the sizes of the old controls isn't really solving the problem. Improving
the appearance includes modifying things like margins and positioning.
Issues like the spacing around the text on tabs <
Loading Image...> needs to be
addressed and corrected, not hacked around.

If there is enough support, and the application developers enjoy and use
the theme, I think they will want to redesign their Gorm files to make the
best use of the theme. And if they don't and there is someone who wants
the app to be themed, then a modified version of the app will surface.

We just need to make sure that margins and spacing between controls are
clearly defined (or even defined within Gorm, if possible), to make it
extremely easy for application developers to design interfaces that
conform to the theme's new specifications. (And I will be working on this
shortly, as soon as Nesedah's controls are completely finalized).


J.

[M. Uli Kusterer]

Post by Jesse Ross

Post by Nicolas Roard

Post by Jesse Ross
- Changed the upper left corners on the box to be rounded, to be
better unified with the rest of the container labels

it's coherent, but I'm not too fond of it.. mainly because a lot of
programs expect square NSBox and this won't work that well with them..
but well..

As long as we leave the proper amount of spacing for the padding, it
should look okay.

Not to mention that any rectangular object shouldn't need an NSBox
anymore. It is its own box and can just be labeled. I really don't
think this should be a problem in any well-designed app.

Post by Jesse Ross
We just need to make sure that margins and spacing between controls are
clearly defined (or even defined within Gorm, if possible), to make it
extremely easy for application developers to design interfaces that
conform to the theme's new specifications. (And I will be working on this
shortly, as soon as Nesedah's controls are completely finalized).

Great! This is one of my main gripes with current GNUstep apps, that
there seem to be no coherent guidelines for sizing and spacing.

[Quentin Mathé]

Post by Nicolas Roard

Post by Jesse Ross
- Added what I personally like for the default button

Still not frankly fond of it.. :-/

Sorry, but I agree with Nicolas here. :-/

Post by Nicolas Roard

Post by Jesse Ross
- Changed the upper left corners on the box to be rounded, to be
better unified with the rest of the container labels

it's coherent, but I'm not too fond of it.. mainly because a lot of programs
expect square NSBox and this won't work that well with them.. but well..

I'm not sure it is coherent, as I explained in a previous mail, browser
headers and group boxes share a similar role, but this role isn't the
one used by tabs and window title bars.
From an aesthetic point of view, the UI in this mockup is starting to
look too much rounded for my taste, in my opinion this is an error
Apple has done with Panther UI (tabs, group boxes etc.), the result is
controls are less standing up (the roundness of controls become less
distinctive).

Post by Nicolas Roard

Post by Jesse Ross
- Increased the overall contrast

I agree with the previous mail from rob, as I also started to use
Nesedah, it looks ok,
but a bit too bright/uncontrasted. This #21 is slightly more
contrasted and it helps, but
I think you can push a little bit more the contrast.

yep may be.

Quentin.

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

[Narcoleptic Electron]

Post by Jesse Ross
http://jesseross.com/clients/gnustep/ui/concepts/
or
http://jesseross.com/clients/gnustep/ui/concepts/21/camaelon_nesedah.png
- Added what I personally like for the default button

I agree with others' comments about contrast of text.

Post by Jesse Ross
- Added what I would like to use as the default color (indigo)

I really like it.

Post by Jesse Ross
- Added notches in the title bar to indicate draggability

I like it. About the suggestion of adding notches all along the title
bar: that would actually be inconsistent, as no other draggable item
puts notches all along its length. I think that Jesse's way is great;
note that there are 4 notches horizontally, as there are in the split
pane resizer.

The only thing I would change would be to make them more visible.
Maybe lighter than the title bar, rather than darker. In fact, if you
make them the "inactive title bar" colour, then they disappear when
the title bar becomes inactive, which might be good.

Post by Jesse Ross
- Changed the upper left corners on the box to be rounded, to be
better unified with the rest of the container labels

I like it.

Post by Jesse Ross
- Increased the overall contrast

I definitely like it.

About disabled scrollers: I'm not happy with the current look either.
I would like to try to give this whole discussion a different
perspective by illustrating a couple of scenarios:

1. What happens to the arrow buttons when the scroll handle reaches
one end of the track? For example, when the scroll handle in a
horizontal scroller reaches the left side of the track, does the left
arrow button get disabled, considering that it no longer does
anything?

- If it stays the same, it will mislead the user into thinking that it
can be clicked, and something will happen.

- If it disappears, the right arrow button would move to the left, and
active controls that automatically move around on the user are very
bad. (I don't think I need to go into all the reasons here.)

I can see only one alternative: to disable the left scroll button.

2. When the window is enlarged a bit, the scroll handle gets bigger.
If it ends up bumping against one end of the track, the corresponding
arrow button would become disabled (assuming that my first conclusion
above is correct).

3. When the window is enlarged enough, the scroll handle would
eventually get large enough that it bumps up against both sides of the
track, taking up the full length of the track. It then makes sense
that:

a. Both arrow buttons are disabled (again, assuming correct logic above);
b. The scroll handle is disabled (because it can no longer be dragged,
being the full length of the track).

In other words, the disabled scroller would consist of (a) disabled
arrow buttons, and (b) a disabled scroll handle. In the current
mockup, that would simply mean modifying the colour of the
non-arrow-button part to be the same as the arrow buttons.

Is there a hole in this logic?

[Narcoleptic Electron]

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

One more thing: what colour would the inactive title bar be?

[Jesse Ross]

Post by Narcoleptic Electron
One more thing: what colour would the inactive title bar be?

The same color as the window background.


J.

[Narcoleptic Electron]

(Sorry for replying to myself... bad habit.)

Post by Narcoleptic Electron
About disabled scrollers: I'm not happy with the current look either.
I would like to try to give this whole discussion a different
1. What happens to the arrow buttons when the scroll handle reaches
one end of the track? For example, when the scroll handle in a
horizontal scroller reaches the left side of the track, does the left
arrow button get disabled, considering that it no longer does
anything?
- If it stays the same, it will mislead the user into thinking that it
can be clicked, and something will happen.
- If it disappears, the right arrow button would move to the left, and
active controls that automatically move around on the user are very
bad. (I don't think I need to go into all the reasons here.)
I can see only one alternative: to disable the left scroll button.
2. When the window is enlarged a bit, the scroll handle gets bigger.
If it ends up bumping against one end of the track, the corresponding
arrow button would become disabled (assuming that my first conclusion
above is correct).
3. When the window is enlarged enough, the scroll handle would
eventually get large enough that it bumps up against both sides of the
track, taking up the full length of the track. It then makes sense
a. Both arrow buttons are disabled (again, assuming correct logic above);
b. The scroll handle is disabled (because it can no longer be dragged,
being the full length of the track).
In other words, the disabled scroller would consist of (a) disabled
arrow buttons, and (b) a disabled scroll handle. In the current
mockup, that would simply mean modifying the colour of the
non-arrow-button part to be the same as the arrow buttons.

In other words, Concept 19...

Some have suggested a slightly lighter colour for disabled controls
(i.e. the whole disabled scroller)... I wouldn't argue with that.

[Quentin Mathé]

Post by Narcoleptic Electron

Post by Jesse Ross
- Added notches in the title bar to indicate draggability

I like it. About the suggestion of adding notches all along the title
bar: that would actually be inconsistent, as no other draggable item
puts notches all along its length. I think that Jesse's way is great;
note that there are 4 notches horizontally, as there are in the split
pane resizer.

I like it, but are they really needed… not sure ?

Post by Narcoleptic Electron
The only thing I would change would be to make them more visible.
Maybe lighter than the title bar, rather than darker. In fact, if you
make them the "inactive title bar" colour, then they disappear when
the title bar becomes inactive, which might be good.

Yep. They clearly have to be a bit more visible : I needed to slow my
breath in order to see them :-)

Post by Narcoleptic Electron
About disabled scrollers: I'm not happy with the current look either.
I would like to try to give this whole discussion a different
1. What happens to the arrow buttons when the scroll handle reaches
one end of the track? For example, when the scroll handle in a
horizontal scroller reaches the left side of the track, does the left
arrow button get disabled, considering that it no longer does
anything?

No I would say (at least currently). There is a problem here I agree
with you.

Post by Narcoleptic Electron
- If it stays the same, it will mislead the user into thinking that it
can be clicked, and something will happen.

May be especially when you take in account the fact there is a special
disabled state.

Post by Narcoleptic Electron
- If it disappears, the right arrow button would move to the left, and
active controls that automatically move around on the user are very
bad. (I don't think I need to go into all the reasons here.)

True.

Post by Narcoleptic Electron
I can see only one alternative: to disable the left scroll button.
2. When the window is enlarged a bit, the scroll handle gets bigger.
If it ends up bumping against one end of the track, the corresponding
arrow button would become disabled (assuming that my first conclusion
above is correct).

I don't understand this point, because when you enlarge a window with a
view inside it (I suppose view hasn't a locked size), the view scroll
handles become smaller.

Post by Narcoleptic Electron
3. When the window is enlarged enough, the scroll handle would
eventually get large enough that it bumps up against both sides of the
track, taking up the full length of the track. It then makes sense
a. Both arrow buttons are disabled (again, assuming correct logic above);
b. The scroll handle is disabled (because it can no longer be dragged,
being the full length of the track).
In other words, the disabled scroller would consist of (a) disabled
arrow buttons, and (b) a disabled scroll handle. In the current
mockup, that would simply mean modifying the colour of the
non-arrow-button part to be the same as the arrow buttons.

It looks similar to your previous proposal with disabled scroll bars,
no ?
But I admit I'm really not sure to understand what you mean here.

Quentin.

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

[Narcoleptic Electron]

Post by Quentin Mathé

Post by Narcoleptic Electron
About disabled scrollers: I'm not happy with the current look either.
I would like to try to give this whole discussion a different
1. What happens to the arrow buttons when the scroll handle reaches
one end of the track? For example, when the scroll handle in a
horizontal scroller reaches the left side of the track, does the left
arrow button get disabled, considering that it no longer does
anything?

No I would say (at least currently). There is a problem here I agree
with you.

Post by Narcoleptic Electron
- If it stays the same, it will mislead the user into thinking that it
can be clicked, and something will happen.

May be especially when you take in account the fact there is a special
disabled state.

All disabled controls should look like the arrow buttons in Concept
21... there should be no "special" disabled state.

Post by Quentin Mathé

Post by Narcoleptic Electron
- If it disappears, the right arrow button would move to the left, and
active controls that automatically move around on the user are very
bad. (I don't think I need to go into all the reasons here.)

True.

Post by Narcoleptic Electron
I can see only one alternative: to disable the left scroll button.
2. When the window is enlarged a bit, the scroll handle gets bigger.
If it ends up bumping against one end of the track, the corresponding
arrow button would become disabled (assuming that my first conclusion
above is correct).

I don't understand this point, because when you enlarge a window with a
view inside it (I suppose view hasn't a locked size), the view scroll
handles become smaller.

Are you sure about that?

Post by Quentin Mathé

Post by Narcoleptic Electron
3. When the window is enlarged enough, the scroll handle would
eventually get large enough that it bumps up against both sides of the
track, taking up the full length of the track. It then makes sense
a. Both arrow buttons are disabled (again, assuming correct logic above);
b. The scroll handle is disabled (because it can no longer be dragged,
being the full length of the track).
In other words, the disabled scroller would consist of (a) disabled
arrow buttons, and (b) a disabled scroll handle. In the current
mockup, that would simply mean modifying the colour of the
non-arrow-button part to be the same as the arrow buttons.

It looks similar to your previous proposal with disabled scroll bars,
no ?
But I admit I'm really not sure to understand what you mean here.

Yes... it is my same proposal (i.e. Concept 19), but illustrated from
a different perspective. I've given it more thought, and it is the
only consistent and logical way that I can see to implement scrollers.

[M. Uli Kusterer]

Post by Narcoleptic Electron
I like it. About the suggestion of adding notches all along the title
bar: that would actually be inconsistent, as no other draggable item
puts notches all along its length. I think that Jesse's way is great;
note that there are 4 notches horizontally, as there are in the split
pane resizer.

If this is referring to my suggestion: I actually meant something
else: My intention was to have notches at both ends of the title bar
and maybe around the name, but nothing in between.

Post by Narcoleptic Electron
The only thing I would change would be to make them more visible.
Maybe lighter than the title bar, rather than darker. In fact, if you
make them the "inactive title bar" colour, then they disappear when
the title bar becomes inactive, which might be good.

Doesn't work. Get a good book about drawing and color perspective
for the details, but essentially dark stuff looks distant, while
light stuff looks nearer. If you light up the notch, it will look
like a bump. People won't recognize it as being the same thing.

Post by Narcoleptic Electron
1. What happens to the arrow buttons when the scroll handle reaches
one end of the track? For example, when the scroll handle in a
horizontal scroller reaches the left side of the track, does the left
arrow button get disabled, considering that it no longer does
anything?
- If it stays the same, it will mislead the user into thinking that it
can be clicked, and something will happen.
- If it disappears, the right arrow button would move to the left, and
active controls that automatically move around on the user are very
bad. (I don't think I need to go into all the reasons here.)
I can see only one alternative: to disable the left scroll button.

When the scroll handle reaches the end of the track, that doesn't
necessarily mean you can't scroll anymore. Imagine a 100-pixel-high
scroller for a canvas that is actually 10 000 pixels tall. That'd
essentially mean that each pixel on the track corresponds to more
than 100 pixels on the canvas. So, if you click the arrow, with a
line height of 10 pixels, the handle will only move about every 10
clicks. So, the handle will have reached the bottom and you'll still
be able to scroll down.

I'm definitely against having it disappear. I could see it being
disabled in that case, though with some postings made by David that I
just saw scroll up (I'm backlogged, sorry), I'd rather not decide on
that until I've read the relevant literature.

Post by Narcoleptic Electron
In other words, the disabled scroller would consist of (a) disabled
arrow buttons, and (b) a disabled scroll handle. In the current
mockup, that would simply mean modifying the colour of the
non-arrow-button part to be the same as the arrow buttons.
Is there a hole in this logic?

Except David's point of disabled scrollers and non-obvious ways to
re-enable them? No, You're making perfect sense. But since most OSs
these days seem to only show a dead trough for scrollers that can't
scroll anything, and the disabled scroller *does* still feel too busy
to me, I'm inclined to vote the conservative route right now and go
back to the old empty trough. At least until I've been able to do
some more reading. It *does* unclutter the UI significantly, and the
scrollers are only dead weight and distraction in that case anyway.

[Narcoleptic Electron]

Post by M. Uli Kusterer

Post by Narcoleptic Electron
I like it. About the suggestion of adding notches all along the title
bar: that would actually be inconsistent, as no other draggable item
puts notches all along its length. I think that Jesse's way is great;
note that there are 4 notches horizontally, as there are in the split
pane resizer.

If this is referring to my suggestion: I actually meant something
else: My intention was to have notches at both ends of the title bar
and maybe around the name, but nothing in between.

It was Nicolas that suggested notches all along the title bar.

Post by M. Uli Kusterer
Get a good book about drawing and color perspective
for the details, but essentially dark stuff looks distant, while
light stuff looks nearer. If you light up the notch, it will look
like a bump. People won't recognize it as being the same thing.

I've got a few books about this already. You're not necessarily
right: for a counter-example, take a look at the drag notch in
Safari, between the URL field and the Google search field in the
toolbar. The key here is light source placement.

Either way, my comment about improving the contrast of notches in
title bar still stands; the details of "how" are better left up to
Jesse than me.

Post by M. Uli Kusterer
When the scroll handle reaches the end of the track, that doesn't
necessarily mean you can't scroll anymore. Imagine a
100-pixel-high
scroller for a canvas that is actually 10 000 pixels tall. That'd
essentially mean that each pixel on the track corresponds to more
than 100 pixels on the canvas. So, if you click the arrow, with a
line height of 10 pixels, the handle will only move about every 10
clicks. So, the handle will have reached the bottom and you'll still
be able to scroll down.

That is a good point, but it doesn't change the meat of what I'm
saying: in this case, the arrow button would remain enabled until you
can't scroll anymore -- even if the scroll handle is at the bottom.

Post by M. Uli Kusterer
I'm definitely against having it disappear. I could see it being
disabled in that case, though with some postings made by David
that I
just saw scroll up (I'm backlogged, sorry), I'd rather not decide on
that until I've read the relevant literature.

If you find any literature about this, I would be interested to see it too.

Post by M. Uli Kusterer
You're making perfect sense. But since most OSs
these days seem to only show a dead trough for scrollers that can't
scroll anything, and the disabled scroller *does* still feel too busy
to me, I'm inclined to vote the conservative route right now and go
back to the old empty trough. At least until I've been able to do
some more reading. It *does* unclutter the UI significantly, and the
scrollers are only dead weight and distraction in that case anyway.

I can't argue with aesthetics.

[M. Uli Kusterer]

Post by Narcoleptic Electron
for a counter-example, take a look at the drag notch in
Safari, between the URL field and the Google search field in the
toolbar. The key here is light source placement.

Actually, that always looked like a bump to me. :-/

Post by Narcoleptic Electron
Either way, my comment about improving the contrast of notches in
title bar still stands; the details of "how" are better left up to
Jesse than me.

I can agree with that :-)

Post by Narcoleptic Electron
That is a good point, but it doesn't change the meat of what I'm
saying: in this case, the arrow button would remain enabled until you
can't scroll anymore -- even if the scroll handle is at the bottom.

Sure, just wanted to clarify before we get an unusable implementation :-)

Post by Narcoleptic Electron

Post by M. Uli Kusterer
You're making perfect sense. But since most OSs
these days seem to only show a dead trough for scrollers that can't
scroll anything, and the disabled scroller *does* still feel too busy
to me, I'm inclined to vote the conservative route right now and go
back to the old empty trough. At least until I've been able to do
some more reading. It *does* unclutter the UI significantly, and the
scrollers are only dead weight and distraction in that case anyway.

I can't argue with aesthetics.

Actually, I didn't mean aesthetics. Cluttering is an important
usability concern that prevents users from distinguishing groups of
objects or locating them.

[Rob Burns]

Post by Jesse Ross
- Increased the overall contrast

looks better to me, and I might agree with Nicolas that it could be
more. But, I think its very hard to guage by looking at the mockup.
After seeing it in use with a variety of applicaion, It's easier to
tell.

Thanks
Rob