[Appeal] Tabs below or above the navigation toolbar?

[Iñaki]

Hello, I'd like to know your opinion about two ways of showing the tabs in
Konqueror:


1)
The first one is the mockup I did.
The tabs are below the navigation toolbar and above the specific toolbar:
http://konqueror4.linuxdevel.net

2)
The second one is a modification that a member of KDE-LOOK
called "logixoul" did.
The tabs are above the navigation and specific toolbars:
Loading Image...


IMHO both of them are better than the actual mode where the tabs are below the
navigation and specific toolbars and it's very confused when loading a Kpart.

Sincerelly I can't imagine with one is better. Could I hear your opinions?

Thanks.

Regards.

[Aaron J. Seigo]

Post by Iñaki
Sincerelly I can't imagine with one is better. Could I hear your opinions?

IMHO the first one is much better.

from a technical standpoint, it is much easier to code.

from a usability standpoint, having the tabs in between better reflects what
we see in other applications (inc outside of kde) so gets points for user
familiarity but also strengthens the relationship between "these are the
actions for this specific tab" and "these are generic actions application to
any tab". right now we have the problem of "window global" versus "kpart
specific" actions not being clearly differentiated, which having the tabs
between the toolbars sorts out very nicely.

the second option does show the relationship between the tab and the location
bar (and other actions) clearly but feels wrong visually for some reason (ok,
that's pretty vague =). i'd also note that it doesn't solve the problem -at
all- for the case when the window is split into one or more panes.

and that's a challenge with split panes. it would almost make sense to put the
location path right inside the content window itself. *shrug*
--
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/appeal/attachments/20060528/3263f908/attachment.pgp

[Iñaki]

Post by Aaron J. Seigo

Post by Iñaki
Sincerelly I can't imagine with one is better. Could I hear your opinions?

IMHO the first one is much better.
from a technical standpoint, it is much easier to code.
from a usability standpoint, having the tabs in between better reflects
what we see in other applications (inc outside of kde) so gets points for
user familiarity but also strengthens the relationship between "these are
the actions for this specific tab" and "these are generic actions
application to any tab". right now we have the problem of "window global"
versus "kpart specific" actions not being clearly differentiated, which
having the tabs between the toolbars sorts out very nicely.
the second option does show the relationship between the tab and the
location bar (and other actions) clearly but feels wrong visually for some
reason (ok, that's pretty vague =). i'd also note that it doesn't solve the
problem -at all- for the case when the window is split into one or more
panes.
and that's a challenge with split panes. it would almost make sense to put
the location path right inside the content window itself. *shrug*

And what about this picutre?
Loading Image...

I mean: a tab design that shows the user the connection between the navigation
bar and the specific bar + window content.

Of course in this way the tabs are not so "beautiful", but I'm sure a good
designer could do a great proposal.

PD: Sincerelly I prefer the first option (the original one), but it's true
that the second one shows better the relationship between tab and location
bar.

PPD: Opera browser uses the second way, and looks very nice, I can't imagine
problem for a common user because of using that way.


Regards.

[Aaron J. Seigo]

El Domingo, 28 de Mayo de 2006 02:52, Aaron J. Seigo escribi?:ow itself.

*shrug*

And what about this picutre?
http://konqueror4.home.dyndns.org/Varios/konqueror4_tab_connection.jpg

i think that makes the separation really ambiguous.

I mean: a tab design that shows the user the connection between the
navigation bar and the specific bar + window content.
Of course in this way the tabs are not so "beautiful", but I'm sure a good
designer could do a great proposal.
PD: Sincerelly I prefer the first option (the original one), but it's true
that the second one shows better the relationship between tab and location
bar.

at the cost of showing the relationship between the part's toolbar and the
tab. imagine when the kpart has a forwards/backwards button like kpdf (nee,
okular ;) does? no, i really think the separation is useful to us.

keeping the common controls separate from the content-specific controls is a
real win in mymind.

we see other browsers, other than opera (a minority browser), with tabs below
the location bar as well. this includes both firefox and vista's ie7.

that configuration also keeps it far away from content which is probably a
benefit from a fishing-protection POV.
--
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/appeal/attachments/20060528/974b82d0/attachment.pgp

[Jani-Matti Hätinen]

Aaron J. Seigo kirjoitti viestiss??n (l?hetysaika sunnuntai, 28. toukokuuta

Post by Aaron J. Seigo

El Domingo, 28 de Mayo de 2006 02:52, Aaron J. Seigo escribi?:ow itself.
PD: Sincerelly I prefer the first option (the original one), but it's
true that the second one shows better the relationship between tab and
location bar.

at the cost of showing the relationship between the part's toolbar and the
tab. imagine when the kpart has a forwards/backwards button like kpdf (nee,
okular ;) does? no, i really think the separation is useful to us.
keeping the common controls separate from the content-specific controls is
a real win in mymind.

Another issue that IMHO should be taken into account here is that several
options in the (at least current) konqueror menu are also tab specific (i.e.
affect only the selected tab) and, when you really think about it, even the
window title is tab specific. So if one were to group all _tab_ specific
controls within each tab, the current konqueror GUI (and probably the whole
GUI paradigm) would need a pretty complete overhaul (which might not
necessarily be a bad thing, per se)
The other option, which Aaron describes above, is to group the _content_
specific controls (i.e. the options, which vary depending on what's inside
the current tab) below the tabs, as also illustrated by I?aki's original web
preview.

IMHO having the location bar and other tab-specific things outside the tab is
clearly unintuitive (if you want an clear example of this, try using the
MySQL Query Browser http://www.mysql.com/products/tools/query-browser/ &
http://dev.mysql.com/downloads/query-browser/1.1.html). But, on the other
hand, if designed well (e.g. if the distance between the location bar and
tabs is small enough), it's pretty easy to get used to it.

On the other hand, while grouping all tab specific stuff within the tab is
intuitive, it would pretty much mean that the tab bar would have to be placed
into the window title, along with a menu including all the common functions
(new window, close, settings, etc.). Everything else would be situated within
the tabs.

One option (although I'm not sure if it's really doable) would be to make tabs
more generic. After all, tabs were originally created because managing a lot
of windows is a real pita. So, if one were to think of a way to group and
organise windows in a way similar to tabs, one might be able to create a more
generic solution (something like a frame/context specific taskbar, which
would also allow grouping different applications).

[Iñaki]

Post by Jani-Matti Hätinen
On the other hand, while grouping all tab specific stuff within the tab is
intuitive, it would pretty much mean that the tab bar would have to be
placed into the window title, along with a menu including all the common
functions (new window, close, settings, etc.). Everything else would be
situated within the tabs.
One option (although I'm not sure if it's really doable) would be to make
tabs more generic. After all, tabs were originally created because managing
a lot of windows is a real pita. So, if one were to think of a way to group
and organise windows in a way similar to tabs, one might be able to create
a more generic solution (something like a frame/context specific taskbar,
which would also allow grouping different applications).

Interesting proposal, but maybe too much innovative?? It could be a good idea
to have the tabs above the window title, but I think it'd be too much strange
for most of users (IMHO).


The reason I set the navigation bar above the tabs is because the navigation
bar is always THE SAME, there are not more icons in the navigation tab
depending of the showing tab.

In fact, IMHO in the navigation bar there just should be the following:
- Buttons Up, Back, Forward, Stop, Reload
- Navigation URL field
- Search box (it could show different thing depending of the tab, but just it)
- Split window (optional)

But as you say we still have the problem of the specific tab menu. IMHO the
menu should be in the top of the window, like in any common app.
Yes, it could be different with each kind of tab, but I hope that a good
content manager should avoid the common user to access the menu for common
actions (these common actions should be done just by using the specific
toolbar below the tab that contains labeled icons).

I think only advanced users should need to use the menu for more advanced
actions, and they have no problem if the menu is different in each tab (they
understand it).

In fact in my mockup I hide the menu in a "menu" button in the top-left
corner, because I hope that it is not needed for common actions in any kpart.

[Francisco Joaquín Rodríguez Prados]

Post by Iñaki
In fact in my mockup I hide the menu in a "menu" button in the top-left
corner, because I hope that it is not needed for common actions in any kpart.

This is the point of your proposal where I disagree most.

Every option should be reachable from the menu. The menu is where you
can access any feature, and hiding or reducing it reduces consequently
the functionality of the applications.

For instance, in Kubuntu they hided - by default - lots of Konqueror
options, obeying to simplicity arguments. Well, maybe Konqueror's menu
is way too crowded, but that's Konqueror: take it or leave it - or try
to organize better the menu.

If embedding Kpdf reduces the functionality of Kpdf, what's the
advantage of embedding?

In my opinion, the aim (concerning the menu) should be to get a
well-organized and clear menu - even when it changes from tab to tab.

[Iñaki]

El Martes, 30 de Mayo de 2006 10:21, Francisco Joaqu?n Rodr?guez Prados

Post by Francisco Joaquín Rodríguez Prados

Post by Iñaki
In fact in my mockup I hide the menu in a "menu" button in the top-left
corner, because I hope that it is not needed for common actions in any kpart.

This is the point of your proposal where I disagree most.
Every option should be reachable from the menu. The menu is where you
can access any feature, and hiding or reducing it reduces consequently
the functionality of the applications.

In the mockup you can lock the menu and get the classical horizontal and
always visible menu. Just press in "menu" - "lock".

[Francisco Joaquín Rodríguez Prados]

Post by Iñaki

Post by Francisco Joaquín Rodríguez Prados
Every option should be reachable from the menu. The menu is where you
can access any feature, and hiding or reducing it reduces consequently
the functionality of the applications.

In the mockup you can lock the menu and get the classical horizontal and
always visible menu. Just press in "menu" - "lock".

Yeah, I know. Ok, I should have been more precise. With "reachable" I
meant "easily accesible". The menubar is there, visible, in a standard
location and with a standard representation, and all the power of the
application is there.

Hiding the menubar is like making the toolbars be popups, just because
you reduce the number of items in the screen. I think it does not make
the interface be clearer. More on the contrary, hide the menubar means
you need to find it when you need it. I'm not saying I won't be able
to find it, but looks more intuitive to me if it is always there. In
fact, the first time I saw I?aki's work, I thought the locked menu was
part of the title window.

Btw, I don't want I?aki to think I don't like his work. I think it's
great. I have just a pair of comments because sometimes I am too
Macish :)

Cheers,

Fran.

[Iñaki]

El Martes, 30 de Mayo de 2006 21:24, Francisco Joaqu?n Rodr?guez Prados

Post by Francisco Joaquín Rodríguez Prados

Post by Iñaki

Post by Francisco Joaquín Rodríguez Prados
Every option should be reachable from the menu. The menu is where you
can access any feature, and hiding or reducing it reduces consequently
the functionality of the applications.

In the mockup you can lock the menu and get the classical horizontal and
always visible menu. Just press in "menu" - "lock".

Hiding the menubar is like making the toolbars be popups, just because
you reduce the number of items in the screen.
I think it does not make
the interface be clearer.

It saves some space and hide unnecesary options for a common user.

Post by Francisco Joaquín Rodríguez Prados
More on the contrary, hide the menubar means
you need to find it when you need it.

MacOSX's filebrowser ("Finder") doesn't have a menu bar, and I've seen nobay
complaining because of that:
http://www.apple.com/macosx/features/finder/

In fact, I'd like you to open my mockup in filebrowser mode (first tab) with
the menu hiden (and don't use the menu). And then, please tell me which are
these so necesary COMMON actions that you don't find for managing files.

And your response ask yourself "what do MacOSX users think about their
filebrowser and how can they live without a menu bar".

Post by Francisco Joaquín Rodríguez Prados
I'm not saying I won't be able
to find it, but looks more intuitive to me if it is always there.

Ok, so you just need to "lock" the menu and the next time you open Konqueror
the menu will be locked.

Post by Francisco Joaquín Rodríguez Prados
In
fact, the first time I saw I?aki's work, I thought the locked menu was
part of the title window.
Btw, I don't want I?aki to think I don't like his work. I think it's
great. I have just a pair of comments because sometimes I am too
Macish :)

I like to listen to your opinion, be sure. ;)

[Benjamin Meyer]

Post by Iñaki
MacOSX's filebrowser ("Finder") doesn't have a menu bar, and I've seen
http://www.apple.com/macosx/features/finder/

Yes it does, like all mac apps the menu is at the top of the screen. You can
configure kde to do that too if you want.

-Benjamin Meyer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/appeal/attachments/20060531/8ee9f714/attachment-0001.pgp

[Francisco Joaquín Rodríguez Prados]

Post by Benjamin Meyer

Post by Iñaki
MacOSX's filebrowser ("Finder") doesn't have a menu bar, and I've seen
http://www.apple.com/macosx/features/finder/

Yes it does, like all mac apps the menu is at the top of the screen. You can
configure kde to do that too if you want.

Moving the menubars up there and making KDE windows document-centred
is not an option, yeah?

http://developer.apple.com/documentation/mac/HIGuidelines/HIGuidelines-75.html#HEADING75-0

[Riccardo Iaconelli]

Post by Iñaki
In the mockup you can lock the menu and get the classical horizontal and
always visible menu. Just press in "menu" - "lock".

IMHO this should be default (visible menu).
It's less "confusing" for a new user who is just migrated to KDE4 from his
previous KDE3 - Win ( - Mac OS X?).

Bye,
-Riccardo
--
GPG key:
<Temporarely not availeable>
-----
A kde it translator
A plasma developer [http://plasma.kde.org]
Fellow n? 545 of Free Software Foundation Europe [http://www.fsfe.org]
-----
Pace Peace Paix Paz Frieden Pax Pok?j Fri?ur Fred B?ke ??
Hasiti Lap? Hetep Malu M?? Wolakota Santiphap Irini Peoch
Shanti Vrede Baris R?j M?r Taika Rongo Sulh Py'guapy ??
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/appeal/attachments/20060531/23bdece9/attachment.pgp

[Andrey Cherepanov]

Post by Riccardo Iaconelli

Post by Iñaki
In the mockup you can lock the menu and get the classical horizontal and
always visible menu. Just press in "menu" - "lock".

IMHO this should be default (visible menu).
It's less "confusing" for a new user who is just migrated to KDE4 from his
previous KDE3 - Win ( - Mac OS X?).

Don't forget about user who prefer keyboard instead mouse. Menubar is very
important for them.

[Francisco Joaquín Rodríguez Prados]

Post by Andrey Cherepanov

Post by Riccardo Iaconelli

Post by Iñaki
In the mockup you can lock the menu and get the classical horizontal and
always visible menu. Just press in "menu" - "lock".

IMHO this should be default (visible menu).
It's less "confusing" for a new user who is just migrated to KDE4 from his
previous KDE3 - Win ( - Mac OS X?).

Don't forget about user who prefer keyboard instead mouse. Menubar is very
important for them.

Well, I would not set a default just thinking in migration from
previous / other systems. If a feature ends up being so good that it
is worth changing the default - even if it changes the hole interface
- I'd say do it.

The problem in this case is that I don't see the benefit of hiding the
menubar and thus reducing the accessibility. And yeah, the navigation
with keyboard is not so efficient if you can't see the shortcuts.

[Kurt Pfeifle]

Post by Iñaki
The first one is the mockup I did.
http://konqueror4.linuxdevel.net

You know what sucks with your repeated pitching of that mockup,
I?aki??

--> The fact that you don't hint to the fact that it is "animated"
and that clicking on certain elements "works". ;-) ;-P

I've forwarded the URL to two different people, asking them to
look at it; had no time for more detailed hints. Guess what? They
missed to discover the main features of it, and they thought it was
just a static screenshot.

Honestly, people: please take a close look at the marvelous work
I?aki has done. He used some HTML and CSS and what-not magic to
make that thingie actually *work*, and pretend it is a functional
Konqui!

Thanks a lot, I?aki, for that marvellous work you put into this!

Cheers,
Kurt

[Iñaki]

Post by Kurt Pfeifle

Post by Iñaki
The first one is the mockup I did.
http://konqueror4.linuxdevel.net

You know what sucks with your repeated pitching of that mockup,
I?aki??
--> The fact that you don't hint to the fact that it is "animated"
and that clicking on certain elements "works". ;-) ;-P
I've forwarded the URL to two different people, asking them to
look at it; had no time for more detailed hints. Guess what? They
missed to discover the main features of it, and they thought it was
just a static screenshot.

Hummm, maybe I must add a text "You can preview the mockup by clicking in the
icons" (or similar) ;)

Post by Kurt Pfeifle
Honestly, people: please take a close look at the marvelous work
I?aki has done. He used some HTML and CSS and what-not magic to
make that thingie actually *work*, and pretend it is a functional
Konqui!
Thanks a lot, I?aki, for that marvellous work you put into this!

Thanks a lot :)

[Benjamin Meyer]

Post by Kurt Pfeifle

Post by Iñaki
The first one is the mockup I did.
http://konqueror4.linuxdevel.net

You know what sucks with your repeated pitching of that mockup,
I?aki??
--> The fact that you don't hint to the fact that it is "animated"
and that clicking on certain elements "works". ;-) ;-P

Taking a look, can anyone find a justification for the left sidebar?

Starting from the bottom with "Workplaces" it just look like a bunch of
bookmarks or fast links. Really it is just redundant of what is already in
the first and third tab. The second to the bottom is Bookmarks which seems
to be the web browser bookmarks. Would they just open the webbrowser? Isn't
it kind of confusing for them to be there? Why would you even want your web
browser bookmarks to show up here? If they are file system bookmarks they
they are again redundant with what is already in the local tab ("fast links"
section). Yes you "can" browse the web using your file manager, but the
experience is kind of crappy, and a list view is a horrible way to interact
with your bookmarks. I mean how many people do you know that have less then
20 bookmarks? File management and web browsing are two different beasts.
Moving on the second tab is "Remote", I assume this is remotely mounted
filesystems. As a user why do I care if they are local or remote? They
really belong in the "local" tab with the rest of the devices. And sidenote
shouldn't that be renamed volumes rather then devices?

-Benjamin Meyer

P.S. kick ass html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/appeal/attachments/20060529/625fcd6c/attachment.pgp

[Iñaki]

Post by Benjamin Meyer

Post by Kurt Pfeifle

Post by Iñaki
The first one is the mockup I did.
The tabs are below the navigation toolbar and above the specific
toolbar: http://konqueror4.linuxdevel.net

You know what sucks with your repeated pitching of that mockup,
I?aki??
--> The fact that you don't hint to the fact that it is "animated"
and that clicking on certain elements "works". ;-) ;-P

Taking a look, can anyone find a justification for the left sidebar?
Starting from the bottom with "Workplaces" it just look like a bunch of
bookmarks or fast links. Really it is just redundant of what is already in
the first and third tab.

It's obvious that you haven't read the explanation document. Read it first,
please:
http://konqueror4-explain.linuxdevel.net

Post by Benjamin Meyer
The second to the bottom is Bookmarks which seems
to be the web browser bookmarks. Would they just open the webbrowser?
Isn't it kind of confusing for them to be there? Why would you even want
your web browser bookmarks to show up here? If they are file system
bookmarks they they are again redundant with what is already in the local
tab ("fast links" section).

Please, read before criticize.

Post by Benjamin Meyer
Yes you "can" browse the web using your file
manager, but the experience is kind of crappy, and a list view is a
horrible way to interact with your bookmarks.

Please, see the specific toolbar in web browser mode: there is a
classic "Bookmarks" button.

Post by Benjamin Meyer
I mean how many people do
you know that have less then 20 bookmarks? File management and web
browsing are two different beasts.

Not in my opinion. But it's just my opinion. Konqueror can now manage files,
documents and web, why eliminate it?

Post by Benjamin Meyer
Moving on the second tab is "Remote", I
assume this is remotely mounted filesystems.

Yes.

Post by Benjamin Meyer
As a user why do I care if
they are local or remote?

The users understand the different between "local" and "remote". If there are
many computers in an office and one of them has a shared resource the users
know that that is a REMOTE resource, not local one. And they understand that
they don't have to look for it between the pendrive and CD (IMHO).

Post by Benjamin Meyer
They really belong in the "local" tab with the
rest of the devices.

Local? really?




I hope you read the entire explanation before criticize next time.

[Benjamin Meyer]

Post by Iñaki

Post by Benjamin Meyer

Post by Kurt Pfeifle

Post by Iñaki
The first one is the mockup I did.
The tabs are below the navigation toolbar and above the specific
toolbar: http://konqueror4.linuxdevel.net

You know what sucks with your repeated pitching of that mockup,
I?aki??
--> The fact that you don't hint to the fact that it is "animated"
and that clicking on certain elements "works". ;-) ;-P

Taking a look, can anyone find a justification for the left sidebar?
Starting from the bottom with "Workplaces" it just look like a bunch of
bookmarks or fast links. Really it is just redundant of what is already
in the first and third tab.

It's obvious that you haven't read the explanation document. Read it first,
http://konqueror4-explain.linuxdevel.net

Thanks, never seen that before, only ever got the other link.

Starting with "local"

What if a hd has two partions, it is still a device or two volumes in one
device? Three of the examples present are all temporary, just like network
drives/volumes/devices (whatever they are called) and can be ejected. To me
as a user I treat my camera drive just like a remote network drive that it
can be disconnected. At the end of the day in the OS they are all just
Filesystems mounted somewhere. The only advantage I see presented is that
the network tab has a new button, but that should be an action in the menu
anyway.

collections, when I had a OS X 10.3 laptop I saw no point in music, videos and
pictures (work laptop) and quickly deleted them. Later on that year when
doing a video test I did add it back. There is no advantage to separating
them from the fast links. Users might think they can't remove them, hide
them or add to them.

Why does fast links have a "new fast link..." button? It is much simpler to
just let them drag and drop folders there and takes up less space.

With bookmarks if one wants to squeeze them all into a list one has to add a
search bar to the top. Remote bookmarks are nice, but what about urls from
the addressbook, rss feeds, and browser history? Where do they go? And if
they are so usefull why when clicking on the Kubuntu tab is there a bookmarks
button?

Workplaces looks a lot like project management. It is a good idea and
implemented well could be very usefull, but I don't see any core reason for
it to be in konq. Konq is about file management (or web browsing).
Workplaces deals with abstract application things like task lists, mail
filters, and address book entries. Yes some of these do deal with files, but
that isn't its main purpose. Konq already does enough with just web browsing
and the filesystem.

To counter with some obvious file management features that are missing:
- local file system searching
- Smart folders
- Extended meta data editing/adding (such as your origin in the info column)
- How about a konsole that can drop out of the bottom ala OS X drawers?
- cd/dvd burning
- Backup system
- Column View (OS X finder view that shows a hierarchy in columns)
- Ok, konq already has it, but maybe the information dialog could be
improved/reworked too.

I don't want to come off completely negative, I am only taking about the
sidebar. I know that a lot of work went into this. Some stuff I loved:

- The Info column is slick, clean, useable, perfect, love the default actions
at the top, this should have been here a long time ago. Why is there even
options at the bottom?

- Love the hide info button :)

- Drop shadows and full blue box selection in icon view. About time we
ditched the dotted lines for selection.

-Benjamin Meyer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/appeal/attachments/20060530/906a59d1/attachment.pgp

[Kurt Pfeifle]

Post by Benjamin Meyer

Post by Iñaki
It's obvious that you haven't read the explanation document. Read it first,
http://konqueror4-explain.linuxdevel.net

Thanks, never seen that before, only ever got the other link.

The "explanation" link is in the lower left corner of the "the
other link" (the "live" one).... :-)

Cheers,
Kurt

[Manik Chand]

Francisco Joaqu?n Rodr?guez Prados wrote:

The problem in this case is that I don't see the benefit of hiding the
menubar and thus reducing the accessibility. And yeah, the navigation
with keyboard is not so efficient if you can't see the shortcuts.

Agreed! However most graphical system users should be using their mouse. If somebody thinks otherwise there should be a way to suppress this behaviour globally by an accessible setting. Why not use a welcome sprite or configuration walkthrough where users can change/skip configurations (mostly general features/annoyances).

By the way less frequently used menus items creates graphical noise and the mock-up effectively clears up the area. After all icons are generally used frequently in a file manager along with a shortcut menus. A full-blown menus features power and clutter together.

Manik


---------------------------------
Yahoo! India Answers: Share what you know. Learn something new Click here
Send free SMS to your Friends on Mobile from your Yahoo! Messenger Download now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/appeal/attachments/20060531/17515fe9/attachment.html

[Torsten Rahn]

Post by Manik Chand
By the way less frequently used menus items creates graphical noise and
the mock-up effectively clears up the area. After all icons are generally
used frequently in a file manager along with a shortcut menus. A full-blown
menus features power and clutter together.

Seconded. And although I like the fact that the menu gets moved out of the way
I fear that people will abuse the chance and make an even more feature loaden
registry out of it.

Torsten

Post by Manik Chand
Manik
---------------------------------
Yahoo! India Answers: Share what you know. Learn something new Click here
Send free SMS to your Friends on Mobile from your Yahoo! Messenger Download now