here's what i have thus far:
it automatically takes the protocol and host name when viewing a non-local data set and separates them out. the protocol combo is populated with file manager relevant protocols, though to achieve that i've had to monkey with the .protocol files a bit. that part needs more thought.
what isn't there yet is display of the username (if applicable) or eye candy. the combo box will be turning into the same sort of button as the rest of the path parts i think. this will look nicer and make it seem less clunky and separate. i'm still undecided what to do with the hostname part yet; perhaps also move it to the same flat style "button" with the added "feature" of turning into an editable text area when clicked on.
i also need to de-geekify the protocols combo a bit by offering humane labels when the drop down is clicked. i'm thinking of a multi-column drop down with names like "secure ftp" or "microsoft network share" next to the actual protocol. have a cool idea for this? send me a mock up =)
the trickiest bit by far though is getting the interaction right. this includes things like switching between local and remote or remote and local transports; typing in protocols not listed; typing paths after the hostname in the host box; flipping between editable and non-editable paths (where does the cursor end up?); changing protocols (switches to the host edit automatically rather than trying to load via the new protocol) .... devil's in the details. but so far the code is staying pretty clean and not overly gross as often happens when trying to work an interface element towards human expectations.
after tomorrow i should be ready to start usability testing on some human guinea pigs i've lined up here. yay!
14 comments:
Forcing a user to specify the protocol, username, servername, and remote path of a networked file everytime he accesses that file is a bad idea. It adds unnecessary complexity.
The only time the user should care about the connection parameters is when he is setting up the remote resource (file or folder) by mounting it onto his filesystem hierarchy-- this can be achieved with an improved KIO-FUSE.
Here's how it would work:
1) KNetAttach would do everything it does now and mount the networked resource into the filesystem via KIO-FUSE. The location of the resource would be something like /home/username/net/school_ssh .
2) All the user's network resources should be listed in /etc/fstab or a per-user equivalent of this file. The networked locations that have already been set up should be mounted (perhaps by an XDG util) everytime the user logs in.
3) Every KIO-FUSE file and directory should have an extended attribute (XATTR) that holds its real world location (ie. fish://username@school.edu:/home/username).
4) When a KDE app opens a file, the app will check whether the file has an extended attribute identifying it as a remote file mounted through KIO-FUSE. If such an extended attribute exists, the KDE app will extract the real world location in order to open up a direct link to that file, bypassing FUSE altogether. It will be as if the user specified the real world path of the file. Essentially, the FUSE file is simply an organizational placeholder that contains the file’s real location and connection parameters. This real location is used by KDE apps to access that file directly through KIO, just like KDE apps currently do. Thus there will be no regressions or loss of features due to the limitations of FUSE.
5) Legacy apps however will rely on FUSE to access that file since these apps do not check for the file's extended attribute.
Cies Breijs and Simon Edwards have some great ideas for how to change Konqueror to better integrate with FUSE, which I think will lead to the optimal solution for users. Please let me know what you think.
If I get a chance in December I'm going to start implementing these changes in KIO-FUSE.
Man, this stuff is brilliant!
that's nice. in the meantime in the real world where people do need to specify remote location we have a ui that helps. and when this super amazing system that only works on linux but solves all problems magically appears in a shipping linux based OS then these features of the url navigator will simply not be seen by the blessed users of that OS.
i think those working on fuse should go ahead with all the vigor in the world. i welcome such improvements.
unfortunately i also have to write software the makes today's technology work for today's users too.
on all platforms.
Why are components of the path not simply links ? as in
/_path_/_to_/_some_/_place_
and a click would navigate to the corresponding path. a bit of spacing keeps the text easily selectable
For me it is very important that the path stays editable text...
another thought : with a little bit of service discovery, the protocol could be a simple dropdown list.
Hmm, wouldn't it be possible to turn this widget into a konqueror plugin, and have it replace the default addressbar?
I take it that it is possible to DnD a address to the field and it will automagically tokenize the protocol etc. out of it?
A FUSE-based solution would work on Linux and BSDs, but I agree that when it's not avaiable, users need to see the connection parameters.
What's the icon right to the clear-icon for? Would it perhaps show a lineedit with the full URL (that you could use for copying the current URL to the clipboard or pasting in a URL from the clipboard)?
> Why are components of the path
> not simply links ?
because this is also more readable while not making a very difficult to use combination of "editable, clickable and draggable" that is really not practical in implementation.
> it is very important that the
> path stays editable text.
it is. there is a keyboard shortcut as well as a button you can click if you're a mouse-hound. backspace deletes the last element of the path and typing paths works pretty well as the view itself is focussed after each directory change.
i've been usability testing this aspect of the widget ... will continue to refine based on that.
> with a little bit of service
> discovery, the protocol could be
> a simple dropdown list.
it is a dropdown list. i'm a little hesitant to make it non-editable though as that would imply the service discovery is 100% and that no-one ever wants to type versus select with a mouse.
> possible to DnD a address to the
> field
yes. i'll also be adding keyboard copy 'n paste support.
> Would it perhaps show a lineedit
> with the full URL
that's what the icon on the far left does, yes. the icon used sucks but oxygen to the rescue! =)
Silly question, what if one wants to edit one of the subdirs in the path? can I navigate in the path widget using the keyboard?
I ask because though I understand the attraction of having a super-clever path widget, in the end, if simply deleting the last part of the path in the "classical" url widget to go up a few dirs was way faster, than perhaps the new widget is not such an improvement.
That is, for the URL part. For the protocl, I think is is way cool.
Does this mean from now on, I can enter paths using greater than sign instead of the usual slash? Alternatively, we ppl will start asking which keyboard key can do U-25BA.
Can I also ask for * + and # as path separators (they are purty). $ will also be cool for business community.
@anonymous: "what if one wants to edit one of the subdirs in the path? can I navigate in the path widget using the keyboard?"
yes. press F6 and you are in and editing like a mo' fo'. you can also just press backspace to delete the last path element.
i haven't gotten to more fine grained keyboard control, but i'm considering per-element focus capabilities.
"if simply deleting the last part of the path in the "classical" url widget to go up a few dirs was way faster"
one key press versus several makes the url navigator a winner here.
@suslik: "I can enter paths using greater than sign instead of the usual slash"
for you baby, anything. ;)
@anonymous: "what if one wants to edit one of the subdirs in the path? can I navigate in the path widget using the keyboard?"
yes. press F6 and you are in and editing like a mo' fo'. you can also just press backspace to delete the last path element.
i haven't gotten to more fine grained keyboard control, but i'm considering per-element focus capabilities.
"if simply deleting the last part of the path in the "classical" url widget to go up a few dirs was way faster"
one key press versus several makes the url navigator a winner here.
@suslik: "I can enter paths using greater than sign instead of the usual slash"
for you baby, anything. ;)
Post a Comment