Mon, 05 Nov 2012
Windows usability: followup.
Yesterday, I posted a blog post containing a list of issues with Windows, in response to a similar list for Linux, which has received quite some response; I've seen people +1 it on google+, and I've received a number of replies on the blog post itself. One of these replies was by the author of the original list; and as expected, he totally and utterly failed to see the point. He also has the audacity to claim I haven't installed Linux yet—what?!? The last time I used anything other than Linux on my personal machine for any real work was on Windows 98. And no, that was not because I was too cheap to buy the latest and greatest. I have used Windows in some cases since then, but never on my own hardware.
First of all, I should note that the list which I posted was only semi-serious (with tongue in cheek); the fact that it refers to Windows as the operating system which "attempts to replace Linux as the major operating system" should have been a pretty big clue to that effect. Like the original list that it was a reply to, my list contains things that are only true in a particular context (e.g., the one about requiring recent hardware), it contains things that don't matter for the large majority of Windows users (e.g., the point about focus-follows-mouse) but that are major arguments for why I don't use Windows, it contains things that are so alien to what most of us are used to that even most Linux users don't use it, while on the other hand some swear by it (like the SELinux argument), and it contains some things that a seasoned Windows user will call bullshit on but that are real actual problems for the non-seasoned Windows user that I am (such as the mouse argument). It also contains some actual facts, like the statement about most crashes being a direct result of faulty drivers—that's pulled directly from a scientific study on the subject conducted by Microsoft, together with some independent researchers. Like the original list, I don't expect this list to change anything for the better, precisely because it is flawed in exactly the same way.
But whether the items on that list were right or wrong isn't the point. This is:
Nobody (except nutcases) ever said Linux is perfect, or that it's useful for everyone; and while the issues Artem lists may be bugs or may be design flaws or any of a number of other things that could be real problems, the fact is that creating a long "list of issues" isn't going to solve anything.
If you find that there are problems with Linux, you basically have three options: fix the problem, get someone to fix it for you, or stop using Linux. Really.
Rather than better or worse, Linux is different. It will have its own set of problems, and it will have its own set of advantages. Some of the design decisions cause problems, but also have serious advantages, and focussing on only these problems (the existence of which I'm not denying) isn't very helpful.
A good example is the library model: under Linux, libraries are typically installed in a system-wide location, and use a SONAME which is (part of) the filename of that library and which defines the binary interface exported by that library. In contrary to the situation under Windows, Linux libraries also must use position-independent code.
The result is a more robust library model. The downside to that model, however, is that when you install older applications that require older SONAME versions of a particular library, getting those older versions may be a challenge. While in theory, installing an older version of a library is not going to cause any problem if the SONAME is different, in practice you'll often find that you'll need to go to (unsupported) older packages from older versions of the distribution, which may not install due to missing or conflicting dependencies, or which may expect data files in a different format in the same location that newer versions of the same library do, or which may have any number of other issues. When that happens, the solution is to either use an older version of the distribution in a chroot or some such, or to patch and/or compile the needed libraries yourself, and install them alongside the newer version of the same library. That's perfectly possible, after all, precisely because of the SONAME.
Another good example is the development model: where Windows has a central authority (Microsoft) which defines what it is to be "Windows" and what is and isn't part of that, the same simply isn't true about Linux. Yes, Linus defines what the official Linux kernel has, but he doesn't have any say about the user interface, the boot process, or any number of other things; other people make decisions there. As a result, in effect, who decides what it means to be a "Linux system" is, really, you, the user. If you believe that the Linux user space is completely wrong, you can just change it to something else entirely; and that's precisely what Google did when they created Android.
Since there's no central authority making decisions about what will and won't go into the system, this means that inevitably, at any given time, there will be many competing options for many subsystems. Usually this will be an advantage; e.g., the competition between KDE and Gnome benefits both. Sometimes, however, the competing options are so confusingly interwoven that even those who should know the system inside out can't make heads or tails of it, and debugging issues then becomes quite a challenge. Unfortunately, the Linux sound subsystem is currently an example of the latter.
I'm not saying that all the items in Artem's list are invalid; a minority are, in fact, actual problems for a majority of Linux users. Most however, are personal opinions, issues affecting only a small minority of Linux users, or, as above, things where he only talks about the downsides of a design decision that also has major advantages. As an example of something in the second category: it's easy, for example, to list hundreds if not thousands of issues relating to particular pieces of hardware that don't work under Linux, simply because the manufacturer doesn't provide any information, and the people developing drivers for Linux have to reverse engineer how everything works. If you're a bit careful in what you buy, however—much like MacOS users need to be careful, too—then using Linux isn't an issue. My Lenovo Thinkpad X220, for instance, has no parts that don't work; and this includes things like a docking station, and the fact that my (9-cell) battery life is over fourteen hours, which (I believe) is more than on the same laptop with the same battery under Windows.
So how is making a list of issues useful? The answer to that is simply, not at all. If you want to help, don't look for other people's problems; we can all do that. Instead, try to look for solutions to these problems. That's not always easy, and in many cases requires that you first understand why something is done in a particular way. If you don't want to spend time doing that, that's perfectly fine; but then don't expect that open source developers (who are already strapped for time, usually) will suddenly jump up and fix the problems you think are most important, as opposed to what they think should be worked on most urgently.
After all, most Open Source developers have their own sets of priorities what they think requires most work, and that's what they'll work on—not what's shown in a particular list by someone they don't know and have no reason to respect, somewhere on the Internet.
Finally, I'd like to note that any statement which claims that Linux isn't "ready" to be used on the desktop, when hundreds of thousands (if not millions) of people are using it in exactly that way for their day-to-day work, is insulting these people's intelligence. Since that includes me, it's also insulting my intelligence. And I don't like to have my intelligence insulted...
Sun, 04 Nov 2012
Why Windows is not ready for general usage
There's this new Windows thing that people keep talking about, and which attempts to replace Linux as the major operating system. I've given it a look, but there's a wide range of problems with using it:
- When you buy some hardware for your Windows machine, it hardly ever works out of the box: you first have to fiddle with some CD-ROM or manually (as opposed to through your software manager) download something from the Internet, or any number of other things (and in some cases even all of the above), before it'll even do anything useful. This is even true for keyboards and mice: the first time you plug in a USB keyboard to a Windows machine, it'll take about 30 seconds before they will work. It's much easier to have drivers for everything shipped with the operating system, so that things become really plug-and-play.
- According to Microsoft, faulty hardware drivers are the main cause for Windows crashes. It would be better if Microsoft were to develop all (or almost all) hardware drivers for Windows themselves, like the Linux kernel people do; by doing this, the quality assurance for the drivers could be guaranteed as is the case for Linux drivers, and Windows users would have much a more stable system.
- There is no public bug tracking system for Windows. What this means is that if you've got a problem with Windows that you'd like the developers to take a look at, you're out of luck.
- Many Windows programs and drivers come with an "updater" which every so often checks online for newer versions of the software. While this is something Linux distributions also do, in Linux distributions this is done through a central updater; in contrast, Windows applications all have their own updater. The result is a situation where you have something like 5 to 10 updaters running in the background, eating memory and other resources, and slowing your system down.
- Every major update of Windows since Windows 2000 has seen a complete overhaul of the user interface. As a result, everything you've learned goes out the door, and you have to relearn how to use the system all over again. This is about things like "where in the control panel is <foo>" or "what does my desktop look like"
- Windows does not support focus-follows-mouse without manually calculating bit masks in a registry key.
- Windows does not support virtual desktops without extra software.
- If you don't like the Windows interface, it's almost impossible to swap it out entirely for something else, like you can switch from Gnome to KDE and back under Linux. Different people have different preferences, so should be able to swap the user interface for something that better suits them. This is child's play under Linux, and impossible under Windows.
- While much of the Windows interface can be controlled without the use of a mouse, parts of it cannot be. If you're doing the same tasks every day, then using the mouse will slow you down; a keyboard is so much faster. Under Linux, it's perfectly possible to use the system without the use of a mouse, and without losing any functionality (except if you want to play games, but this list is about Desktop usage, not about game console stuff)
- It is impossible to try out the new Windows without investing large amounts of money into a recent computer. In contrast, this blog post is being typed on a 7-year-old Macintosh PowerBook running a recent version of Linux.
- It is very difficult to use a single Windows application (i.e., not an entire desktop) over the network. In Linux, you can just use SSH to log in to a server and start the GUI administration console there, but run your desktop environment (and whatever else) on your local machine. Windows doesn't have that, so you need to add large amounts of memory to Windows servers just so they can run a full (unneeded) desktop just so that you can maintain them.
- Windows doesn't have mandatory access control subsystems like SELinux or AppArmor. What this means is that anyone who knows of a bug in a part of the system that runs with administrator or system privileges, has the ability to take over your entire system. With mandatory access control, this isn't possible. There is "Mandatory Integrity Control", but it uses a simplistic level-based system, and is only supported on the desktop; so on servers, where it would be most needed, this isn't available.
- Windows cooperates very badly with other operating systems. If your company has a hybrid environment, you'll always need to special-case the Windows systems in the environment for one reason or another. What this means is that if you're the first user in your company to use this Windows, you'll probably not get much work done.
- The new Windows only runs on the x86 processor family. If you have invested in, say, a mainframe, or in a rack full of PowerPC or MIPS processors, you're out of luck and had better stuck with Linux instead.
- Windows has bad backwards compatibility. When I have this old Linux application that I still need to run for one reason or another and which doesn't run on a recent Linux installation (which is very rare in and of itself), I can install an older version of Linux in a chroot without having to run a full emulated machine, and the older application can then run in that chroot. Windows has a "compatibility mode" for older applications, but it doesn't work in all cases; when it doesn't, you would need to run a full virtual machine in which you run the older Windows just so you can run the older application. That's just a terrible waste of resources. It's also not possible to do this without installing extra sofware.
- The standard Windows installation doesn't contain a lot of software. there is a basic word processor, but it doesn't have many features. There are almost no games, other than a few boring card games. There is a graphics editing program, but its feature set is fairly limited.
- Unbelievably, you need to pay for most Windows software. This is just strange; you can do many useful things on a Linux system without ever having to pay anything for off-the-shelf software. While some of the tried and true Linux software that we all know is now also available for Windows, if you want to use, e.g., Microsoft's productivity suite, you'll have to pay for it.
- Speaking of that productivity suite: there's a well-designed and widely accepted open standard, called ODF, describing the file formats that productivity suites should use. Yet, Microsoft chose to design their own; their description of this file format encompasses more than 5000 pages, and is in general fairly badly documented. What this means is that once you start using Microsoft's productivity suite, you'll have a very hard time moving away from it again. I recommend against ever starting to use it in the first place
- And last but not least, Windows doesn't come with the source code. What this means is that you can't just look at the code and learn how things are done, or develop your own extensions, or audit the code for bugs, or any of a number of other things that you'd want to do with a regular operating system. Instead, you'll have to trust that Microsoft did the right thing, and beg, hope, and pray that they'll fix your bugs if you ever need to. I'm not sure what the hell they were thinking when they decided that.
In short, while this Windows thing has some promise, the above list shows that there's clearly still quite some work to be done before anyone can even think about starting to use it seriously. Hopefully the Windows developers will understand that and work on the above list of serious issues; otherwise, I'm afraid Windows will not be used by many people.
Update: before you go all berserk and start commenting on this list, please read my followup to this post, which explains the point I was trying to make.
Sat, 30 Dec 2006
f-spot vs digiKam
Since I have been having a digital camera since a few weeks now, I've had a need for an application to manage my pictures. The two applications that people have pointed me to are f-spot and digiKam, which also seem to be the most popular applications in this category for Linux. Since I use neither KDE nor GNOME as my user interface, it doesn't matter much to me which I install; so I've tried them both. Their feature set is quite different; unfortunately, though, they both have some features which the other doesn't, which makes choosing for one or the other rather hard.
Since their on-disk format is rather different, it's impossible to use them both at the same time—at least not if I don't want to enter commentary and tags each and every time; so I'll have to choose one or the other based on their features. Since that requires me to actually compare them, I thought I might as well make a blog post out of that. Note, though, that this comparison is in no way intended to be complete; it only compares those features which I really care about.
Features
digiKam
- Stores pictures in
albums
; these albums can be created hierarchically, and are created on disk as the directory lay-out in which to store pictures. One picture can be chosen as anexample
picture per album. - Pictures can have tags, comments, and a score (on a scale of one to five stars) applied to them. Tags can be created hierarchically; the default tagset is empty. Tags can be made to have icons that are otherwise available to KDE attached to them, to make them more immediately visually recognizable, but selecting pictures to fulfill that function seems impossible.
- Has an interface to manage pictures in gallery and gallery 2; it can view, add, and remove pictures in that gallery.
- The selector dialog which is used to upload pictures is rather spartanic; it allows one to select pictures by filename and by album; pictures aren't even shown before upload (bug filed).
- Pictures can be filtered by tag, album, or date; I haven't been able to find an interface to filter pictures by score (it is possible to sort them by score in any view, though).
- A KDE application, so written in C++, which is a compiled language; i.e., rather fast.
F-spot
- Does not know the concept of
albums
- Pictures can have tags and comments applied to them. Tags can be
created hierarchically; the default tag set contains (amongst others)
People
,Places
, andEvents
, suggesting that f-spot encourages the use of tags where Albums would be used in the case of digiKam. Tags can have icons which are otherwise available to gnome selected as their icon, or one can select a picture to fulfill that function (in fact, it selects the first picture which receives a tag to do that by default) - Does not know the concept of scoring; instead, the default tagset
contains a tag
Favourites
, suggesting a scoring system with a binary scale. - Uploading pictures can be done by selecting them, and choosing the right option in the menu system. As a result, all filtering options otherwise available can be used to select which pictures to export (just filter the view, then select all pictures in the view).
- Uploading pictures will optionally also export comments that were applied to it.
- Since it does not know the concept of
albums
, pictures cannot be stored in a one-directory-per-album lay-out. Instead, pictures are stored in a one-directory-per-day layout, using a yyyy/mm/dd format. Unfortunately, this also means that no picture metadata (tags, comments) is easily available to command-line applications. - Apart from the ability to upload pictures to gallery or gallery 2,
does not interface with it in any way; gallery is a
write-only
storage medium to f-spot. - Written for mono, a system that requires a runtime environment to translate instructions at runtime from some sort of virtual machine code, and which uses garbage collection all over; i.e., rather slow, especially after you've been using it for a while.
My opinion
After having used f-spot for a few weeks before I tried digiKam, I
have to be honest and say that I don't like the concept of
albums
. They do not add value; everything they allow you to
express can equally well be expressed with tags. Additionally, one can
categorize a picture in only one album
, whereas it's possible to
categorize pictures in as many tags as you would want. Just creating one
album which contains all my pictures, with tagging used for
categorizing, doesn't help either; that way, digiKam would store all my
pictures in a single flat directory, which would become problematic when
the number in the picture filenames wraps around.
I do love the scoring thing in digiKam. A favourites
tag just
doesn't cut it; and creating five tags for scoring would make things
like find all pictures that have a score of three or above
rather
cumbersome, and sort by score
outright impossible. However, the
fact that it's not possible to filter by score makes it all rather
useless.
The export to gallery
function in digiKam is horrible. I have
to select my pictures blindly; none of the metadata which I tack on them
can be used to help select which pictures I want. Workaround: use
whatever filtering is available to select the right pictures and add
them to a temporary album from which I then upload all pictures, but
that's silly (and requires disk space for no good reason). Additionally,
there seems to be a bug in
the interface, which means that I have to babysit an upload (with no
workaround). And I can't even
view my pictures to spend the time waiting. Bah.
F-spot isn't without problems of its own. Due to a bug in mono, it crashes rather often on my PowerPC laptop. When that happens, it can't be restarted until the X server is restarted. Workaround: use Xnest, but that makes it impossible to view pictures in full-screen mode.
Also, since f-spot is a GNOME application, its options
dialog
is as helpful as a pair of soccer shoes when you're out swimming. No
surprises there.
Conclusion
Which one do I prefer? I'm not sure. The digiKam upload interface is
positively annoying, especially the bug which requires me to click
continue
after every picture. For that alone, I might ditch it.
On the other hand, it has a slew of interesting features (the scoring,
to name one) that f-spot lacks, and that pull me more towards
digiKam.
I guess I'll have to give it a few days of thought. But hey, at least I know where I stand now.
Thu, 25 May 2006
Edge flipping.
So, in my previous blog post, I mentioned that Enlightenment, bug-ridden as it is, is the only application I've seen thus far that implements edge flipping the right way. Since it's been a long time since I last used the only windowmanager that actually implements it the right way, I've been able to give it quite some thought by now. Here's my take at it:
The central thing to remember is that the edge flipping interface will trigger accidentally. No matter how well you implement your interface, sometimes a user will accidentally move his or her mouse, or he/she will want to click somethin near the edge of the screen and touch it. Therefore, there are two things an implementer should do:
- Make every effort to avoid accidental edge flipping where possible, and
- Make it as easy as possible for the user to correct an accidental triggering of the interface.
The best way is to make sure your interface has the following characteristics:
- The code should not trigger if the mousebutton is pressed down. The reason for this is that many people like to maximise their windows, and that many interfaces keep their scrollbars near the edge of the window. Scrolling is often accomplished by moving the mouse over the scrollbar; and since human beings are not machines, it's usually impossible for them to move their mouse in a straight line. It's fair to say that when you're holding your mouse down, you're usually not interested in edge flipping. GNOME's brightside gets this wrong, which makes it a horrible nightmare.
- The code should not trigger immediately. When you move your mouse, it's fairly common to touch the edge of the screen. Thus, edge flipping should only happen after a delay. However, when it is happening, it should continue to do edge flipping until the mouse has not touched the edge anymore before another delay has passed (otherwise moving two or three workspaces at once takes too much time). While I haven't seen any implementation get this horribly wrong, I've seen implementations get this wrong in their default configuration (again, brightside).
Getting the above two right will ensure that accidental edge flipping is reduced to a minimum. This is the first step, and one that only Enlightenment and IceWM got right. The final step, however, is something that IceWM does not get right; and this is what makes Enlightenment's edge flipping implementation such a natural thing to do:
- After edge flipping, warp the mouse to the opposite side of the screen, just far enough away from the edge so that it will not immediately flip back again.
Some people will find that last point evil, I'm sure. I'll admit it took me a while to get accustomed to it as well. But it's the only natural thing to do. You should think of your virtual workspaces as one large desktop; if you're using four workspaces next to eachother, that means one large desktop four workspaces wide. When you move the mouse one quarter to the left, it's normal that it ends up about the same place on that same desktop. In other words, warp the mouse.
Additionally, the mouse warping will have the effect that it makes recovery from accidental edge flipping easy and fast. If the mouse stays where it was after edge flipping (as in the case of brightside and IceWM), then if I accidentally hit my mouse, by the time I've moved my arm towards the mouse and started moving it back, I've moved away three workspaces from where I was already (because of the second bullet point in this post). If, however, the mouse does warp to the opposite side of the screen (i.e., the side where it was coming from), then going back to where you were is just a matter of moving the mouse a few millimeters in the opposite direction. Very easy to accomplish, that...
Oh, and finally, you also shouldn't segfault at random. Again something that brightside did not get right when I used it—did I mention that brightside is crap? Well, I did now. Hopefully it's changed for the better in the mean time.
Back in my Enlightenment days, I used workspaces a lot, because Enlightenment made it so natural with its excellent edge flipping implementation, and with the help of the pagers which would always, at any time, give me a snapshot of all my workspaces, helping me to remember where this or that application was running. IceWM doesn't replace that, but it sure gets close.
IceWM
I had been an Enlightenment user for a long time—halfway the Summer of 2000 up to the early fall of 2004—before someone finally decided to pick up the pieces where they were left somewhere around 2000 and restart its development. Unfortunately, that also meant causing #219925, which was irritating me more and more each day. Eventually, in the early fall of 2004 (almost a year after I filed that bug), I gave up and started looking for something else.
The problem, of course, was that I'd grown so accustomed to using Enlightenment and its way of doing things that I felt at a loss. I wanted to be able to move windows above the upper edge of my screen again. I needed focus-follows-mouse. I was having a hard time without edge-flipping. Eventually I found that there was functionality for all of the above, but it wasn't flawless. Especially not the edge flipping—GNOME implements that in a truly horrible way1. Not to mention the fact that brightside, the application which implements edge-flipping for GNOME, segfaulted on me an annoyingly high number of times, sometimes even taking away my entire session with it. Even Enlightenment never did that; it would just misbehave instead.
Apart from that, of course GNOME also had some extra annoyances that I didn't get rid of. The fact that it insists on mucking with my keyboard settings, to name just one example. Even so, I used it for about nine months. Then, slightly after DebConf5 in Helsinki, I realized what the true horror of GNOME is: not the fact that they hide away features or try to make the desktop void of superfluous options; the fact that they remove features that are critical to some of its users. I know I was horrified to find out that something I really used a lot had been removed in that new release. I kept using it for three more months before I threw in the towel and tried something totally different.
Ion3.
After coming from the mostly mouse-oriented interfaces that GNOME and Enlightenment were, ion3 was truly different. I liked it at first; it was a welcome change from what I'd previously been doing. Eventually, though, I found that the ion way of doing things just wasn't my way. The fact that, by default, it puts new windows right in front of the window you're working on was rather offputting. Any serious attempt at configuring the thing involves learning lua which, though supposedly not hard to do, is not something I ever found the time for. In the end, I discovered that I disliked working with ion, as I often felt that it gave me a fragmented and tunneled view on the world, and that it was working with me instead of the other way around. In short, it was getting the fun out of computing for me. Which wasn't good, at all.
So that's when I started looking for something else again. When I'd made the decision to move way from ion3, I didn't want to keep using that "until I'd found something else"; instead, I quickly installed IceWM instead—which I still knew from back when I had a Yopy YP3000—and used that until I had found something better.
Little did I know the beaty of IceWM. I've decided, by now, that it does all I need, and more: By default, it tries the best it can to put a window on your screen so that it overlaps with as little other windows as possible. I can have it not focus a new window by default. I does focus-follows-mouse, if enabled. It even does edge-flipping. Of course it's not perfect—the edge-flipping, though not as horrible as the GNOME implementation, can still use some improvement. As if to prove my point, I accidentally closed the window in which I was writing this very post before it had been written to disk, the cause of which could be described as an interface problem in IceWM (though it's more likely an example of PEBMAC (Problem Exists Between Mouse And Chair). But, all in all, using IceWM feels like finally coming home.
Thanks, Marko and Mathias, for a truly wonderful piece of software.
1 I know that there are a lot of people who dislike edge-flipping. I am 99% sure that this is because they've never seen it implemented right. Edge-flipping is great, if done right; it's nightmare if done wrong. GNOME does it horribly wrong. IceWM does it better, though not perfect. The implementation in Enlightenment is perfect. I'll discuss the details in another post.
Thu, 30 Mar 2006
Usability on the command line.
-g, --generate Unpack, but do not generate a new package.
Hmm.
Thu, 02 Mar 2006
Gnome 4.23...
If the GNOME people keep going on the track they are currently on...
... This is where they'll end up:
Wed, 15 Feb 2006
Bye bye ion3
I just decided to move away from ion3. It was bothering me too much, and getting in the way of things that needed to be done. Back in the days with Enlightenment, I had my system configured so that new windows would, by default, not overlap with the one that currently has the focus, and that new windows would never get the focus. Ion3 does none of those; new windows receive the focus and appear in the currently-active frame, thereby overlapping whatever was active in that frame already.
I've accidentally hit "OK" too soon on an ssh-agent window once or twice because of that. Which is bad, very bad.
There were more annoyances. The frames, and the fact that a window cannot resize itself does have its advantages, but it certainly does have its disadvantages as well; I found that I had to move windows around all the time when they weren't terminal windows. If the idea of switching to ion3 was to avoid having to move around windows all the time, then it failed. Horribly.
So what I needed was a window manager that, by default, does not overlap windows or give out the focus to new windows; that allows me to move around using the keyboard only (and not the mouse); that is not too heavy; and that would allow me to configure shortcut keys for starting common applications (such as an x-terminal-emulator).
I've switched to icewm for the time being. Not sure it supports all those features, but most of them seem to be in order. Which is good. The docs can wait for tonight...
Tue, 04 Oct 2005
Gnome followup
Funny how people start to get all defensive if people start giving their opinion about software they like very much, and that opinion is quite negative. I've had a rather high number of comments on my blog, on IRC, and have seen some in other blog posts on Planet Debian, too.
For clarity: I didn't claim that the Gnome people need to do this or that; I just explained why I dislike it. If people are interested in my opinion, great; if not, too bad. I couldn't care less. After all, I didn't marry Gnome or anything—I used to be an Enlightenment user for three years before I started using Gnome, and switched to ion now after using Gnome for less than a year.
And yet, so many comments... it would seem that at the very least, the Gnome policy to constantly hide away features which used to be there is quite controversial.
Why I left GNOME
There's a heated discussion going on over on Planet Debian currently about how Galeon 1.3.x dropped a lot of configuration items as compared to Galeon 1.2.x, and how this is disappointing some of the more advanced users. The claim is that by dropping some of the more advanced features, you won't scare off novice or casual users who don't know what all those thing actualy mean.
This is all backed by usability test such as one done by Sun, in which people who've never used the system before are put in front of a GNOME desktop, are being asked to do a few things with the system, and their progress on that is monitored; also, they're being interviewed afterwards, so that they can give their opinion.
While such work is probably tremendously important to make sure the system is useful for those who don't use it all that often, it's horribly important that you don't forget that such people do not make up the majority of your users. Creating a system that's tremendously useful for people who only use it for ten minutes in their whole life but tells advanced users to go fuck themselves and delve into some obscure and hardly documented gconf-tool frobnitz if they want their email program to stop making sound if they get new mail is horrible. Having a website that links to all sorts of community and developer information, but doesn't even have a fucking 'documentation' link on the front page (or on any of the pages linked to from that page, except the 'Developers' one which contains links to developer documentation) is completely and utterly useless. Someone once pointed me towards where the users' documentation is, but I forgot to bookmark it, and have lost the link.
Contrast to ion. Granted, I could start using GNOME a few minutes after I'd logged on (two minutes for GNOME to start up, five seconds for me to have a look at everything there and to start clicking away), and the same wasn't actually true for ion3. However, ion does point me towards its documentation with its very first message, and while I needed more than a few minutes to read it, I already had everything I needed: the manpage is concise, clear, and to-the-point; and down the bottom, there's a link to the ion website, which contains a 'Documentation' link in the second paragraph—the first paragraph being a short and concise explanation of what ion is.
Of all the bad things I've got to say about Windows, there's one thing I'll have to give them: at least they got it right that you shouldn't fucking mess with the registry. I don't know how gconf is supposed to work (even after googling for the documentation, and studying it as well as I could a while back), and I wouldn't call myself a novice user; so how is such a novice user then supposed to understand all this gconftool and gconf-editor whiz-bang-hoopla?
The main argument seems to be that this is wrong:
Which is a good point. But the solution that the GNOME people seem to push is not, in fact, a solution:
Because it misses at least this:
or, even better, this:
But, well. Since it's utterly clear that the GNOME people are not interested in anyone who's been using their system for more than 10 minutes, I guess the best thing to do is to use something else...
Some mail is welcome in /dev/null. Real mail, however, is welcome at my email address
|
|
|
|