PATCH - HOME URL and profiles

Dawit A. adawit at kde.org
Tue Sep 21 03:50:00 BST 2004


To all,

Please please please stop discussing all the supposed ills and/or benefits of 
Konqueror in this thread. This is neither the correct thread nor the 
intention of the patch. If you want to discuss usability with Konqueror that 
has nothing to do with the Home URL issue, please start another thread or 
stick to the usability lists. As I stated in the original post my intention 
is not to start an endless debate about tangential issues. I do not want to 
see this thread go on forever. Thanks.

On Monday 20 September 2004 19:42, Frans Englich wrote:
> 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

-- 
Regards,
Dawit A.
"Preach what you practice, practice what you preach"




More information about the kfm-devel mailing list