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

List:       kde-usability
Subject:    Re: View modes in konqueror
From:       "Jamethiel Knorth" <jamethknorth () hotmail ! com>
Date:       2004-04-20 20:19:45
Message-ID: BAY7-F73w4hVJbrzvsT000462e6 () hotmail ! com
[Download RAW message or body]

>From: Peter Postmus <p.postmus@st.hanze.nl>
>Date: Tue, 20 Apr 2004 10:44:39 +0200
>
>On Tuesday 20 April 2004 00:42, Jamethiel Knorth wrote:
> >
> > 2) This could be solved by having one button with several utilities. 
>First,
> > if single-clicked, it would toggle between the current icon-type and
> > listing-type views, remembering which one was last used of each type.
> > If clicked and held, a drop-down menu would be given as follows:
> >
> > Icon View
> > Multicolumn View
> > < separator >
> > Tree View
> > Info List View
> > Detailed List View
> > Text View
> > < separator >
> > FSViewPart
> > Cervisia
> > [Other Plugin Viewers]
> >
> > On the one hand, that's a fairly long menu. On the other, it condenses
> > everything down to a single button on the toolbar and gives immediate
> > access to the most common action (toggling between list view and icon
> > view). Due to the current crowded mess of the toolbar, I think the value 
>of
> > a single button outweighs the value of short menus. Also, it does place
> > everything into one menu, so it can be dealt with all at once, as 
>opposed
> > to several menus which may or may not have what is needed.
> >
> > Nine items in a toolbar menu really is a lot, but they can usually 
>remain
> > hidden. It also allows all the extra plugins to be used fairly quickly
> > without them severely crowding the menus.
>
>You're right, but IMHO we still need to find a way to reduce the number of
>view modes appearing in the list, while maintaining functionality.

You suggested elsewhere to move some of them into KDE-Addons. I think that 
might be the best solution. Text-view and info-list-view should be moved.

> >
> > 3) If anyone could possibly implement my directory association idea, the
> > Cervisia in CVS directories problem would be largely alleviated. Of 
>course,
> > I don't really expect anyone to, but I really do not have the ability, 
>so
> > I'll keep asking with hope every time it comes up. (Search for 
>'directory
> > editor' in the archives)
>
>Yes, that is a very good idea IMO. Unfortunately, I'm not able to implement
>it. Most of my programming skills are in Java (which IMHO is a good, 
>"clean"
>language with an excellent API, although it's probably too slow for KDE at
>the moment). Although C++ looks a lot like Java, there are still 
>differences
>(what's with the :: and ->?), and I still have to master the KDE/Qt API.
>However, I'm learning :).

Oh well. Hopefully I'll find a willing soul eventually. (Or, even better 
yet, my abilities will progress far enough that I can do it myself.)

> >
> > 4) Several people mentioned views which need to stay or go. Each view
> > genuinely has different uses, despite the similarities, and I don't 
>think
> > anyone will convince the maintainers to trash one of them. As a general
> > rule, usability is to make a program easy to use, not to make a program. 
>If
> > the idea calls for something to be removed, it needs a really strong 
>reason
> > to get put through, and I don't think there is quite enough reason in 
>this
> > case.
>
>If that's the case, I would really like to know the rationale for having 
>Tree
>View, Detailed List View and Text View as separate views.

I do not know why others want text-view, but I have found that it is very 
easily readable if just put at a high font-size on bad screens and loads 
enormously faster. I used it exclusively when I was on a really slow system, 
because the lack of icons made a noticeable difference.

Detailed View is the basic way to view the extra information about all the 
files in a directory. Tree view is significantly different in that it has a 
tree. This is better or worse, merely different. Many users find tree views 
to be very complex and confusing. The tree view also changes the browsing 
model by allowing directories to be opened without changing the current 
directory. The reason the tree-view has all the extra details is just that 
there is nothing else to put in that space, so why not.

I'm not entirely against trying to clean them up, I just don't think it will 
happen so I'd rather not dwell on it.

>I think that having a single-button view mode chooser is only half the 
>work,
>because - like you said - the list of view modes would become pretty 
>crowded.
>IMHO the other thing we need to do is to find a way to reduce the number of
>view modes appearing in the list, while maintaining the functionality we 
>have
>now. And we need to keep the toolbar consistent (while choosing file view
>modes, disappearing buttons should not affect the position of the file view
>mode button). Although I understand this could be a problem wrt plugins, 
>it's
>the end-result that eventually matters most: the user interface has to
>satisfy the needs of the user (or most users), both in terms of 
>functionality
>and ease of use.

Although I would love to do so as well, I do not think it is feasible to 
keep the position of the file-view button consistent. An effort should be 
made, though, so it could at least be moved up in the listing to be closer 
to the core buttons that never move.

_________________________________________________________________
>From must-see cities to the best beaches, plan a getaway with the Spring 
Travel Guide! http://special.msn.com/local/springtravel.armx

_______________________________________________
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]