Konqueror 4

[Aaron J. Seigo]

On Thursday 02 November 2006 2:31, Martin Konold wrote:
> Just to reasure you: I personally indeed felt confused when I tried it. In
> additon I was never sure if I see the whole picture or if some "smart"
> developer is hinding things (like the infameous hinding of /tmp/ im
> kubuntu).

heh .. what, don't trust the developers? ;)

btw, i started the usability testing with Real Life Users as of last night. i 
have been testing all the issues raised in this list (as much as possible 
anyways) including repeating fragments, switching to editable and back to BC 
(and discoverability of those features/functions), navigating 
up/down/sideways/up+sideways, comparing performance to hand editing ... so 
far it's working very well, particularly for those who aren't familiar with 
concepts like $HOME (more on that below)

i have quite a few notes about the usability of dolphin (also covering some of 
the other concepts in it such as the info side bar) but need to do at least 
another half dozen or so tests. i'm heading to a local coffee shop today to 
see if i can find some more random people.

btw, if you ever want an exercise in frustration, try usability testing 
sometime. having to sit there calmly without offering input while the test 
subject does the most amazingly unexpected things while explaining why they 
are doing that with the oddest (to a techie) streams of 'logic' is .... 
trying. =) it's also very eye opening and while it is a bit hard on the 
patience and even ego (if you're testing stuff you wrote) it certainly helps 
me understand a lot better the needs of people who will hopefully one day use 
this stuff. anyways, enough ramble: on to the meat of the subject.

> As the web matured and turned more and more into web applications things
> became broken. The more modern web applications have "state". This
> statefulness of the web was not intended by the very early design of the
> web. Due to the statefulness using the back button become dangerous.

we have an analogous situation with the explosion of hot plug storage and 
networked resources on the desktop. i'd personally like to experiment with 
features like "if the user is browsing their usb key and then moves to 
another area in the file system, note this and automatically cause a fs sync" 
which would help make "safe unmounting" buttons less necessary

> Last but not least URLs cannot be arbitrarily translated and localized.

this is true with /home/konold as well. /home is english and not translatable. 
the first button in the filemanager BC when viewing $HOME (even if it isn't 
in /home) is i18n("Home"). ditto for protocols like remote://. see, same 
issues =)

> - Navigation can be controlled by the server as opposed to fiddling with
> the URL manually which simply does not work anymore.

which is what we have with system:/, remote:/, media:/ etc ... and those came 
into being because the URLs for file systems were becoming beyond the reach 
of mere mortal computer users.

> - users don't need the back button anymore

in my usability testing i'm turning off the toolbar for part of it to force 
usage of the BC and nobody is complaining about a "back" button even though 
its used when the toolbar is visible. there have been requests for "up" 
though. so again, similar sorts of gains.

> - applications which are technically a complicated mesh (due to the links)
> can be presented to the user like a simpler hirarchical structure.
> Hirarchical structures are easier to navigate and understandable compared
> to the more complex mesh structure.

i agree with kevin here that our file systems have become mesh like, though 
not in a "this links to that" way. when we have network attached storage, 
digital cameras, usb pens, fish://, $HOME and $TMP ... we have a swarm of 
concepts that create a large "netting" of paths; unfortunately those paths 
are not consistent across platforms nor are they consistent with the concepts 
(e.g. $HOME might be /home/aseigo but $TMP may 
be /home/aseigo/.kde/tmp-hostname which is a symlink to /tmp/kde-aseigo/. oi 
vey!)

> Summary
> =======
>
> Breadcrumbs got developed in order to improve the usability of web
> applications. In general BC are successful for websites which are unable to
> provide a proper URL or which habe problems with the back button due to
> statefulness.

we have similar challenges, don't you think? you are right that they are not 
identical but they are similar from a complexity and user-understandability 
point of view.

> E.g. it is possible to directly click on "Systems" in the above example.

just as it possible to directly click on i18n("Home") =)

> BUT
> ===
>
> A traditional filesystem like on an USB stick or on a ftp server is
> _already_ hirarchical. Up and Back Actions are _well_ defined in
> traditional filesystems. (Yes there are also unidirectional links in unix
> filesystems). Offering a proper URL/path is trivial with filesystems.

it's not about linkage, it's about layout and dynamic setups.

> The usability gains from BC as known from web applications don't apply for
> filesystems as the problem that the web moved away from the filesystem
> structure does not exist for filesystems!

true. we have other challenges. like how users don't understand URLs 
fish://aseigo@bddf.ca/home/aseigo =)

> Conclusion: BC are a big improvement for web applications but for
> filesystem "If it ain't broke, don't fix it" and don't "improve for the
> worse".

if we use BCs it will be predicated on being able to prove it improves things 
for the better.

and as much as it is probably mystifying to most people on this list, editable 
url bars are quite broken for anyone who isn't technically advanced because 
urls are very inhumane. i've never had problems with them, but i can't deny 
the feedback i and others receive consistently from real world usage 
scenarios on this point.

> Aaron: I hope it is not too frustrating for to read this.

not at all ... this thread has added a number of testing points to the 
usability tests i'm running and is helping me understand what are the main 
points of contention for those used to traditional editable urls. this in 
turn helps me understand what the BCs should avoid and should implement, as 
well as what needs to be clearly communicated to our community if we do move 
to BCs in the filemanager.

IOW, it's been (and continues to be) quite useful for me as a developer.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20061102/4e4376a6/attachment.sig>