PATCH - HOME URL and profiles

Frans Englich frans.englich at telia.com
Tue Sep 21 00:42:24 BST 2004



Some think tabs are a bad idea because it at large parts duplicates the window 
manager. In Konqueror we have also views, small windows inside the main 
window. For every Konqueror window, we have the Navigation Panel which houses 
everything from storage devices to bookmarks. 

It's not difficult to find opinions stating that Konqueror is complex or have 
an identity crisis, and there are those who replace it with their own file 
manager -- simpler and easy-to-use, according to their own words.


While Waldo was largely misunderstood, I don't think it is a good idea to give 
the user impression of two different applications, for the same reason I 
think profiles is a wrong approach: It locks the user into modes. It also 
goes away from a document oriented approach, to focus on what tool is used 
for accessing documents.

However, I think the need of splitting is real and valid. All the other 
troubles we from time to time have with getting profiles right, or making 
Konqueror really good at one thing, is also serious usability issues. I think 
we have on our own have brought us in this situation by making Konqueror an 
MDI application.

Konqueror is its own little universe: It is an /entry point/ to documents, you 
launch applications, you browse the web, you browse your files -- wherever 
you go, everything follows you.

Since Konqueror invents its own way of doing things, such as not letting the 
windows manager take care of arranging content, that then becomes our 
vocabulary, our options, when it comes to solving problems. For example, 
navigation is also Konqueror's task(MDI, device view, views), and from that 
rises an enormous complexity, and a difficultness of doing one thing well.

Let's play with the thought of not going MDI; in my eyes it has the same 
positive effects of splitting. For example, if:

* The Navigation Panel, which have many usability issues in itself, was 
removed, combined with;
* Navigation and the central entry point to files&devices was taken care of by 
kmenu or kdesktop; such as an icon on the desktop which opens a Konqueror 
window, containing an slave which lists devices and central directories,

Then, Konqueror would be an SDI application without the file manager 
properties built in, and Konqueror is hence not restricting for the user, and 
listing a local/FTP directory works just as well as visiting a web site. If 
there still was a need for specialization, it could be achieved with a slight 
customization with user profiles(as an implementation method). In other 
words, I don't think our usability problems are caused by KParts or KDE's 
network transparency.

That would be a document oriented approach(SDI), and use the window paradigm 
for arranging content, instead of almost reinventing it. It would add to the 
freedom of KParts -- anything can be clicked without thinking of the system, 
and the navigation wouldn't hinder that.

The road splits at MDI: Views for example, requires navigation in each and 
every window. The alternative is to use multiple windows instead of views, 
and have navigation separated.

I don't think views and profiles is good for another reason: it requires too 
much user configuration. It requires tuning, setting it up, and rigging for 
one particular use. It should just work out of the box. 


I have no solution in my pocket(and if I had, I have more productive things to 
do than proposing it), but our severe problems are not solved by doing an 
ad-hoc solution, or finding a fix as soon an urge for change is expressed on 
one of our lists, as it daily is.

We need to take a step back and see what roles Konqueror and all other KDE 
parts play in the Desktop Environment. This involves what icons to put in 
Kicker, how the kmenu is designed, kdesktop, and Konqueror, and what tasks 
each one of them are responsible for -- the interaction at large. If we do 
not have a conceptual idea, and know what roles and purposes the components 
have, we can't deny/accept suggestions, and are hence doomed to the floating 
state we currently have, where design largely depends on who's on the list 
and what their personal preferences are -- feature bloat, and creeping 
featurism is the result of such an approach.

In other words, I don't think we can reach a long-term result by fixing one 
obvious problem right now.


Cheers,

		Frans





More information about the kfm-devel mailing list