AUG
15
2005

Usability, hierarchies and IO-slaves

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.

  1. 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.
  2. 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.

Comments

with your sentiments. Especially, when it comes to gobolinux. People go on at length at how the unix style FS makes sense, because of x, y and z, where really they're just explaining how it works. Not giving to many reasons for it, and the ones that are given fall flat given what other options are available to sys admins.


By S at Mon, 08/15/2005 - 08:55

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.


By jimmy_h at Mon, 08/15/2005 - 10:21

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).


By simon edwards at Mon, 08/15/2005 - 10:34

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.


By you at Mon, 08/15/2005 - 14:55

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.


By jimmy_h at Mon, 08/15/2005 - 15:46

Concerning the Linux Kernel, the best way to fix the issue is with udev. Unfortunately, most distros are not offering comprehensive device mapping yet. The current mappings just duplicate ./MAKEDEV & DevFS support.


By you at Mon, 08/15/2005 - 15:58

>I suspect part of the problem might also be a lack of discourse between kernel and desktop developers.

Exactly! And I'm afraid that's one advantage that will give M$ Windows and Apple OS X an edge over Free software.

How often do you see an @kde.org email post a message on the


By vladc at Mon, 08/15/2005 - 22:49

Well, one of the tenants of KDE is choice. If the developers only put it on 1 platform, then that ability to choose starts to evaporate. Furthermore, you would still have to code for portability, due to the variance between different distros. Some decide to use 2.4 kernels, others 2.6. Some run X.Org, others XFree86... Then you can consider OSS vs ALSA, XMMS vs another media player, etc etc.

I have seen many people advocating the creation of "the linux platform". It is obvious that the lack of a solid foundation exists, as every distro is different. Conforming to LSB fixes some of these problems, but causes others (such as the general lack of intuitiveness of that structure to Joe User.

If KDE+GNU+Linux really wants to break out on the desktop, then they really do need to become a platform--a foundation for development. KDE is doing well in this regard, what with KDevelop, Cervista, Valgrind, etc, etc. However, if they really want to becme that platform, they need to set a few more strict requirements. Require x.org, a 2.6 kernel, HAL, udev, etc etc. That way you can spend your time managing a known system.

It's not a solution that would go over well with the developers, though. They consider KDE's flexibility for *nix to be one of its greatest strengths.

Maybe if a middle ground was found. Consider a KDE that works everywhere, but only works best (with all the bells and whistles) on a particular foundation. For instance, it would get good iCandy on x.org or xgl... It would get better device support when run on linux 2.6+udev+hal... It would have a better ability to manage filesystems with FUSE (or what have you). Basically, it works on many platforms, but it works the best when you have all of its tasty pieces below it.

That still rubs me a bit wrong, though. :/


By you at Tue, 08/16/2005 - 13:44

Consider a KDE that works everywhere, but only works best (with all the bells and whistles) on a particular foundation.

That's the way it is already done.

Specific features can be dependent on the platform or on some installed library or detected during runtime.


By krake at Tue, 08/16/2005 - 19:48

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.


By Dave Lopez at Tue, 08/16/2005 - 05:07

Pages