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

List:       kde-usability
Subject:    Re: View modes in konqueror
From:       Peter Postmus <p.postmus () st ! hanze ! nl>
Date:       2004-04-20 8:44:39
Message-ID: 200404201044.39662.p.postmus () st ! hanze ! nl
[Download RAW message or body]

On Tuesday 20 April 2004 00:42, Jamethiel Knorth wrote:
> Due to how much this thread grew so swiftly, I'm not entirely sure who I'm
> replying to, so I'll just state my points.

Sometimes, I also don't know who to reply to ;).

>
> 1) Plugins in KDE cause a problem because they add themselves to a button
> merge, which users cannot remove in part. Thus, I must have a Cervisia
> button even though I only use it once every month or two. (It is possible
> to remove by editing a text file, not through the toolbar editor, if I
> recall correctly.) Thus, these plugins need to be better integrated into
> that button merge.

Good idea.

>
> 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.

>
> 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 :).

>
> 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.

>
> 5) The multicolumn view needs to have its zoom level split apart from the
> zoom level is the icon view. Probably a lot of hassle, as Konqueror
> currently only tracks that once, but it would make the multicolumn view
> useful.
>
> 6) Why is KFileReplace even listed as a view part? It doesn't even view
> files. It does search-and-replace in multiple files. It does not display
> files for use. Shouldn't that be accessible by selecting groups of files,
> then right-clicking and choosing it from the actions context menu?

My guess is because it affects the user interface of the file viewing pane.


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.

-- 
Met vriendelijke groeten,
With kind regards,

Peter Postmus

WWW: http://starbase218.ath.cx
_______________________________________________
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]