There is a really good series of articles on hierarchies and usability at the SAP Design Guild site which ever developer should read:
http://www.sapdesignguild.org/community/design/design.asp
(look in the left side menu for the hierarchy articles)
For those who don't have time to read the articles I'll just break it down to a couple simple points below.
- PEOPLE DON'T "GET" HIERARCHIES. Us computer people live and breathe hierarchies. Wonderful data structure / organising method, can't live without it. Meanwhile back in the real world, real people do not share this love affair. Most people have trouble with hierarchies. They don't understand the structure, they get lost in them, the categories seem arbitrary. Sure people understand the hierarchical structure of their company for example, but they rarely feel comfortable with the abstract concept of a hierarchy as a way of organising data. In day to day life most people don't create or deal with hierarchies.
- People don't understand other people's way of organising things. This is discussed in the first hierarchy article under "Categories' Arbitrariness". Simply put, there is always more than one way to organise information into a hierarchy and people will often not understand the system being used. The never ending Kcontrol reorganisation discussions on the kde usability list are good testament to this simple truth.
Now, getting to my point. KDE has been growing a lot of extra IO-slaves lately, system:, media:, homes:, settings:, and there are ideas floating around for more along the lines of movies:, music: and documents:. I can't help but get the feeling that by doing this we would just be supplementing one complex hierarchy (filesystem) that people have trouble with, with lots of extra smaller hierarchies that people can go have trouble with. I don't see the gain. I fear that this is exactly the wrong direction. Fixing poor organisation by adding even more poor organisation.
Not to mention the other problems that IO-slaves have. Firstly, they are hidden to the user. The user just doesn't know they are there. Secondly, the relationship between something in media: and the unix filesystem is a complete mystery. Also, people don't "get" URIs. They're for geeks.
I think that the only real structural solution is what Apple OS X and GoboLinux have done. Drop the unix filesystem hierarchy and think up a completely new one based on the user's needs.
Failing that, all I ask is that people keep KISS in mind.
Syndicate Blogs
Regarding ioslaves - I
Regarding ioslaves - I really miss the behaviour that the Amiga had with devices and aliases...
For me the ioslaves like {documents: media: music:} sound similar to assigns on the Amiga. Any real path is hidden from the user but each provides something that is very easy to remember and I think this is a good thing.
eg.
assign docs: /home/tom/work/docs/
cd docs:
Or to ease migration of lusers from other OSs - "assign c: ~/"
Doing it this way would make it extendable for the admin or vendor. I also think it's important to have ioslaves supported in a shell (can of worms, I know).
Whilst thinking about my old Amiga, it handled removable media nicely too. Put disk in, up pops icon with the disk _name_ - the device name is not important. After that a disk is the same conceptual thing as an assign - it's just a marker that is easy to remember.
bah
the UNIX fs is great for sys admins and programs. so we keep it.
ioslaves are largely hidden to users and that's good. they simply give us a programmatic way to present something less freakish to the user. this is good. there is no need for the user to understand URIs for them to work.
and yes, eventually we'll move even more away from anything resembling hierarchy with TenorKat.
Agree also
It seems some of the newer KIO slaves are just patching over problems that should be solved in the kernel.
For example, didn't KDE make media:/ because it's too hard to quickly mount/unmount a CD in UNIX for most normal people to do it? If automount et al really worked properly, the user could get the same result by just visiting /media/. Not to mention, when I plug my camera and mp3 player in in the wrong order, Linux mixes them up (because the one that's plugged in first is always /dev/sda and fstab references the device files, not what the device does)
I don't really understand why homes:/foo is simpler than /home/foo.
Re: Agree also
my feelings too.
I don't really understand why media: was invented, maybe cameras show up in media: that don't appear in /mnt.
Also for homes:/ I don't understand why it was made instead of, say, improving the way Konqueror displays directories that the user can and can not enter. Then you could just use /home/ and the user would also see which directories are 'available'. The plus with this solution is that it works for all directories in the system and not just /home dirs, and it doesn't duplicate already existing functionality (/home in this case).
more inconsistency
What about trash:/? When a users trashes something in konq. he can restore it. But what when he "trashes" (rm) something in a shell. It's gone for ever. This is the same sort of inconsistency as in media:/ (showing camera's that are not present in mount) imo.
What would mean that trash:/ also should be moved to kernel level.
behavioural changes not good
I think rm should always remove the file. That's the expected behaviour of the rm tool.
"del" on Windows also deletes directly if I remember correctly.
However an additional tool for trashing could be a nice idea for users who want to work in the commandline but have the extra safety of a trash.
Trashcans
There is definitely a good argument for a system wide trashcan facility. Accidentally blowing things away for good in the shell with no second chances, just isn't funny anymore.
Integrating a trashcan with the underlying OS means that you could make it system wide and also remove that moronic feature that most trashcan implementations have, the idea that the user has to manually and periodically "take out the trash" to free up disk space. If the OS runs out of disk space it should automatically try cleaning out the trashcan itself.
Just thinking about it now, you probably could implement a decent trashcan by hacking glibc. I swear I had seen this done somewhere...
I believe that a large
I believe that a large factor of the problem comes from the way that KDE does it's development. I do not mean to imply that OSS is an incorrect way to develop software. Rather, the general lack of structure that KDE has concerning roadmaps/etc seems to contribute.
Let me explain, using the homes:/ ioslave. The developer most likely needed a way to provide that funtionality, and it occurred to him that a custom ioslave would be a great way to do it. So, he went ahead and developed it, submitted it to the project, and it was accepted. This is generally considered a good thing. It is the way that OSS works.
However, as you have pointed out, it would have been better to devote those resources elsewhere. There are 2 different ways (that immediately occur to me) to fix this.
The first idea is to tell developers what you want them to work on. This, of course, is rather against the way that OSS is managed, and has a whole other plethora of problems.
The second is to create a group who investigates incoming features, and evaluates them. If a feature is considered worthwhile, then add it. If it needs work, spit it back out. If it is a truly awesome idea or a must-have feature, but it lacks a good UI, then forward it to the usability team. Basically, don't accept it until it's worth including.
The idea here is to have a few "KDE Visionaries" who can spot inconsistencies like the one above. When the homes:/ ioslave isn't necessary, but adds some neat features, the visionary would tell the developer "the idea is awesome, but could you port that functionality here instead?". The idea is somewhat similar to how the Linux Kernel is maintained. KDE probably uses some of these things already, but the idea would be to have a few more "Andrew Morton"s and "Linus Torvalds"s who actually coordinate everything.
I see KDE heading down that path already, with go-getters like Aaron Siego and Zack Russin (I think I spelled their names wrong
). Now that I have used some marketdroid/business-class speak, I think I'll end my comment there.
I can't back this up, but I
I can't back this up, but I suspect part of the problem might also be a lack of discourse between kernel and desktop developers. The temptation for a KDE developer is to implement/fix everything in KDE - you know the libs, the people, the process etc.
However, a lot of stuff is better implemented/fixed on a different level. That my mp3 player sometimes mounts as my camera and vice-versa is really a kernel problem, which media:/ only slightly glosses over.
I'll agree completely. The
I'll agree completely. The dirty little secret is that Microsoft and Apple have a huge advantage when it comes to the desktop because of the tight integration that they can employ. Linux on the desktop will always be somewhat hobbyist because there is no Linux operating system.
I've said it before and I'll say it again, if Linux had been developed like FreeBSD + the desktop and desktop efforts had seriously started at the time of the XFree86 port, Linux would be way ahead of either Apple or Microsoft at this time. But beause of Linux's historical Unix roots, the whole desktop has always been an afterthought.