Bug 8333

[James Richard Tyrer]

Aaron J. Seigo wrote:
> (after this reply, i'll only post to kde-usability-devel on the issue so as to 
> avoid further cross-posting)
> 
> On Wednesday 01 March 2006 15:20, James Richard Tyrer wrote:ss
>>  After considerable discussion, there is some support for two "home"
>>  buttons although I do not think that it is yet a final decision.
> 
> what we're really working around here is that we don't have a proper 
> distinction between "web browsing" and "file management" modes of using 
> konqueror. if we actually had two UI arrangements tuned to each of these 
> situations then we could keep our one button and use a profile-specific 
> value.

This issue is addressed in several of my comments to the bug. 
Currently, we have an artificial distinction between "web browsing" and 
"file management" which is not a good idea.  This could be replaced with 
a real distinction based on the protocol being used which would avoid 
the usability issues associated with the current artificial duality. 
This would mean that saving URLs or a set of tabs with several URLs 
would have to be moved to a different function other than Konqueror 
Profiles.

However, this idea has an issue.  If the home button points to a URL 
which is different for different browser modes based on the current 
protocol, you have a problem: how do you switch browser modes?  So, you 
wind up with only one home button, but you need to add two more to 
change the browser mode or require that the user resort to the menu.

I note that I feel that the artificial distinction between "web 
browsing" and "file management" is a bad idea since there is no valid 
reason for it -- Konqueror can browse the web when it is in: "file 
management" mode and browse your local file system when it is in the: 
"web browsing" mode.  Having a unified browser should be a powerful 
feature of KDE, we shouldn't screw it up just to conform.

I use only one browser configuration for all uses, I like it that way, 
and I find it very annoying that this artificial distinction is hard 
coded rather than being a user configurable option.

> advanced users could provide other UI arrangements (we call them profiles in 
> kde3, right?) and extend the concept.

Unfortunately, profiles can include more than just the browser 
configuration and a home page URL so this is a poor choice of names, and 
IMHO a bad idea from a usability perspective.  My suggestion is that the 
profile should only be a browser configuration and possibly a designated 
home URL (but the home URL should not overwrite a URL being displayed -- 
only be opened to overwrite "about:blank" or on demand with the home 
button).

> if we were continuing on with kde3 devel feature-wise this might be trickier. 
> but as we are moving on with kde4 devel, it only makes sense in my mind to 
> fix this properly instead of continuing to work around the problem.
> 
> thoughts?
> 
>>     Is having the "local home" button assigned to the "Documents" path OK?
> 
> no. GNOME recently tried this (or was it Ubuntu only? one or the other) and it 
> was not received well because of how people actually use their computer.

I note that the default for KDE is to have the Documents Path point to 
$HOME.  Are there any cases where the user would want the local home 
button to point somewhere other than $HOME or the Documents path?

> personally, i'm strongly in favour of promoting $HOME as the starting point 
> and providing a set of sensible defaults in there from which point the user 
> can customize to their heart's content.

Windows and OS/X appear to disagree with this idea.  Due to the large 
number of configuration files which accumulate in a user's $HOME 
directory, I suggest that encouraging users to use the $HOME folder for 
"My Documents" is a bad idea.  Yes, most of these files are so-called 
"hidden" files but the fact is that not all applications respect this 
distinction and show ALL of the files in the $HOME directory in their 
file chooser dialogs.  Also, the $HOME directory is the one place on a 
system where the user can easily break something -- recommending they go 
there is not a good idea (my Cat occasionally uses my key board and he 
has caused strange things to happen :-D).

>>  I don't think that using the house icon for the "web home" is a good
>>  idea. 
> 
> agreed. what we could do is check to see what kind of URL it is and switch the 
> icon based on that. we could sort out protocols between "local file", "remote 
> file" and "intarweb" for instance and switch the icon based on that. i'd 
> personally put http(s) and ftp(s) into the "intarweb" category together since 
> that's a pretty common perception amongst users (the two intermingle pretty 
> randomly).

Should we base our decisions on the misconceptions of some users?  IIUC, 
Konqueror (unlike other browsers) uses the File Manager to do FTP.

> we can allow the user to customize the icon within the profile too

The ToolBar icon can be changed, but I think that the menu icon is fixed 
by the code.

> if we wish, but differentiating between local files, remote files (e.g. fish, 
> sftp, webdav, smb) and "the web" would likely do us well.
> 
> local and remote file Home icons should very very similar however. such as a 
> house versus a house with a network pipe. essentially the base file 
> management home icon + an emblem that adds more information.
> 
>>  It is also possible to have the menu string and icon for the local home
>>  button change depending on whether it points to $HOME or
>>  $HOME/<something else>.  This would be "way cool" but I have to ask if
>>  it would violate the HIG since the icon and string for a menu item would
>>  change depending on the user's configuration.
> 
> see above ... what do the other usability folk think?
> 
>>  Please make your suggestions and I will make appropriate changes to the
>>  code in the patch.
> 
> are you working on trunk/ these days, both trunk/ and tweaking 3.5, or just 
> 3.5?

I have not yet got around to installing trunk yet so I am currently only 
tweaking 3.5.  Installing it is on my to-do list.

-- 
JRT