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

List:       kde-usability
Subject:    Re: simpler UI for konqy
From:       "Max O'Shea" <maxo_lists () yahoo ! co ! uk>
Date:       2004-01-14 19:10:46
Message-ID: 200401141910.47622.maxo_lists () yahoo ! co ! uk
[Download RAW message or body]

I actually find the up button quite useful in Konqueror, especially on sites 
like the web CVS on KDE. But I think there are some buttons that aren't 
necessarily needed, eg. cut/copy/paste . Konqueror should change the buttons 
depending on whether it's being used for file management or web browsing. 
Another thing that needs to be changed is the home button when web browsing - 
it shouldn't go to ~ 

On Wednesday 14 January 2004 18:54, Carlos Leonhard Woelz wrote:
> On Wed, 14 Jan 2004 11:55:10 -0500, "Navindra Umanee"
>
> <navindra@cs.mcgill.ca> said:
> > Carlos Leonhard Woelz <carloswoelz@imap-mail.com> wrote:
> > > Nobody is suggesting that. People are suggesting to remove it only for
> > > web browsing.
> >
> > The Up arrow key is useful!  Just put it after <- and -> and it should
> > be fine.
>
> He he, you are playing with fire bringing the subject again...
>
> To sum up the discussions about the up button, and Konqueror in general:
> (If you think you know what I will say, well, Leo changed my mind)
>
>
> 1) The up button problems:
>  - a)The up button (dir up) (when clicked once) does not bring
>  meaningfull results when used in most complex sites. The user is
>  presented with junk, and the user gets confused.
>  - b)The up button is graphicaly the same as the left and right button,
>  and yet performs a very different function.
>
> 2) The konqueror web browsing problems:
>  - a)Too many sidebar options not related to web browsing
>  - b)Too many configurations not related to to web browsing
>  - c)Some toolbar buttons not related with web browsing
>  - d)Menu items not related to web browsing
>
> 3) The broad problems:
>  - a)If the user know what he is doing, he will know this is the site
>  fault. The sites should organize  in a meaningful way, but they don't.
>  - b)Other KDE applications make the same mistake confusing trail and
>  navigational buttons. (see the Kate example:  open Kate and the Kate's
>  file tab. Open more than one button. Use the left and right buttons from
>  the file tab and the main toolbar. See the different meaning?)
>
> 4) The complications:
>  - a)There are other navigational actions, defined by REL UP, LEFT and
>  RIGHT. REL up is not the same as dir up. We currenly don't present this
>  options as Mozilla does, and I don't think we can present them today in
>  a non confusing way.
>  - b)The simplicity versus uniformity dillema: If you open a web page in
>  filemanager profile, should the buttons change? If they don't how to
>  acces the button more suitable for file management or won't we get a
>  overcrowded toolbar? If they do, won't we end up with a "dancing
>  toolbar", maybe in the future a "dancing menu" or "dancing
>  configuration"?
>
>
> OK, here is my take in the solutions:
>
>
> The solutions:
>
> There is nothing we can do about 3a.
>
> To the up button problem: Today's icons show the same icon type for
> different functions. It confuses the trail meaning with the navigation
> (up) meaning. To solve this, I propose:
>
> 1) Create a new set of directional buttons for navigation. They should be
> different from the trail left and right buttons. use the up button from
> this set to the up button. (would solve 1b and 3b)
> or
> 2) Create a dir up button. Use it in konqueror for both profiles. The
> user is not confused anymore, problem solved. In addition, you can create
> navigational buttons. These would be used in the "navigation bar" (REL
> UP, RIGHT and LEFT), like mozilla's, and in other KDE apps. (would solve
> 1a, 1b and help 3b)
>
> To the specialization problem:
>
> Ideal solution: Separation.
> Use konqueror technology to create a lean specialized web browsing
> application, and *keep* the konqueror web browsing profile with close
> resemblance to the file manager profile. (As it is today). Solves (2
> a,b,c and d, 4a and don't incur in 4b, as it would be a different app in
> the user perspective). Keep the konqueror web browsing profile as it is
> today, with minimum differences from the file manager profile.
>
> The "Frank Stein" ;) intermediate solution (what probably will be done
> for 3.2):
> Make the view profiles have different toolbars:
>  - Won't solve (2a, b and d). Will solve 2c, but that can turn using the
>  web profile for power users into a pain, if too many generally used
>  buttons are removed. (But, hey, they can use the file browsing profile
>  for power using ;))
>  - Won't solve 4b, it will only choose sides (the simplicity side) and
>  will make 4a complicated, mixing director navigation and logical (REL)
>  navigation as it will still be mixing file management and web browsing
>  all over, not only in the toolbars.
>
> The botton line is: I think Konqueror as a power tool has to stay, with
> minimum differences between the view profiles. But there is room for a
> specialized browser, using Konqueror technology, with its own menus,
> configuration, toolbar, etc... It should have another name, and different
> so people would not be confused with different funcionality between the
> two. Going only with the toolbar is IMHO a frankenstein solution because
> it would mean a slow migration from the power user web browsing profile
> to the new application that would kill the power user web profile in the
> middle of the way. Better start already as a new application.
>
> And about the up button: the up button is a graphic problem. Once it has
> a new icon, showing what it does (go up in the directory structure), it
> is not confusing anymore, and I am neutral about keeping it even in the
> web browsing view. (Not that my opinion is important).
> --
>   Carlos Leonhard Woelz
>   carloswoelz@imap-mail.com
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]