[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: simpler UI for konqy
From:       Leo Savernik <l.savernik () aon ! at>
Date:       2004-01-08 15:46:47
Message-ID: 200401081646.55100.l.savernik () aon ! at
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Donnerstag, 8. Januar 2004 15:54 schrieb Carlos Leonhard Woelz:
> On Thu, 8 Jan 2004 14:32:09 +0100, "Leo Savernik" <l.savernik@aon.at>
[...]
> >As
> > 99.9999% of sites don't implement it, the navigation bar's up button's
> > functionality would come close to that of non-existance.
>
> If no rel up exist, the current behavior could be a fall back.

Hmm, this merges two functionalities into one action with no way for the user 
to predict which action is about to take place. Imagine an incompetent web 
designer using rel=up improperly (and there are *many* incompetent web 
designers out there). Dir up and rel=up should always be two different 
actions (see also the recent discussion about merging stop and reload, which 
at least had a visual indication).
>
> You see, this is not a easy subject. This is complicated in many ways.

Indeed
>
[...]
> - You usually dont browse files when you fire up the web browser.
> - When you do browse files, you usually browse down, so the back button
> is the up button
> - You will still have the option to use the file manager profile to
> browse files and the web, with the up button.
> - The up button does not present consistent results when browsing the
> web. Also, its funcionality is provided by the web site (in usually more
> consistent way). And this is about the web browser.

This should be handled by the navigation toolbar's up button. The dir up 
button handles a different task and can therefore stand on its own.

> Someone could think these reasons are enough. I don't. To remove the up
> button, the file list should include at least the ".." If it does, than
> we *think* about removing. (Maybe for 3.3?)

".." has usability problems in long file lists:
- - Either one has to move the hand from the mouse to the keyboard and press 
ctrl+pos1, them move it back to the mouse and click ".." (so Ctrl+Up is 
actually faster).
- - Or one has to move the mouse to the upmost position directly beneath the 
scroll button of the scrollbar, click the middle mouse button to place the 
viewport there, and then select ".." (but how many users know about mmb 
actions in scroll bars?)
>
> [...] It should have
> *at least* (for 3.2) a different icon type. (This one could be the same
> of the navigation ones). 

I don't disagree on this one. But it should be distinct from either the 
current icon and the proposed navigational icon. Maybe a folder with an 
upward arrow. Any skilled artist volunteering to draw a new dir up icon?

> [...] Kate has navigation left and right (they go
> from one file to the next). The icons ate the same! Open Kate with the
> filedialog tab and see what I mean.

Indeed, it overloads the meaning of the symbols. It should use the 
navigational icons (when they are ready, do they exists at all yet?)
>
> And the navigation bar could be used to browse directories, even when
> there is no rel up, down, left and right. It could merge in these cases.
> This *could* be a solution, (I do not claim it is a solution, it is only
> something to think about). It would be an original solution.

This would again mean an overloading of actions. The navigation bar would work 
differently in file manager mode than in browser mode. (And what would next 
and previous mean there? Next sibling directory? I think that'd confuse ppl 
to hell.) These are only my thoughts about it.
>
> As a side note, since this has little to do with the above discussion, I
> don't think we are talking about removing funcionality. We are talking
> about _adding_ a more specialized web browser. The web browser as is
> today is essencialy the same application as the file manager.

Yes, that's because protocols are tightly intermingled.

I'm not conviced by these many discussions that have come up about the subject 
that a more specialized web browser is necessary. If it is, shouldn't it be 
an application of its own?

mfg
	Leo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE//Xtnj5jssenUYTsRArgdAKCwWB+/0qLkKjKgVNYSke6E4qp85ACfQSK2
mgwfGZ0s+Kx697KQSElymsY=
=/uNO
-----END PGP SIGNATURE-----

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]