GNOME and Ubuntu usability issues

Think of an absolute n00b trying to use computers for first time.

--
Sridhar Ratna

for hidden files is a good idea. This helps you to identify hidden files and folders when turn on "Show hidden files".

Currently, I have 70 hidden and 50 unhidden files and directories in my home directory. As far as I can remember I have never edited any of these dot files by hand, or even looked at them.

If they were visible by default in file dialogs and in the nautilus, it would take significantly longer time to find and open the 50 files that I actually use.

Naturally, we shouldn't hide places where users normally have to enter. I don't use wine so I have no idea if its a good or bad idea to have a hidden wine directory or not. However hiding files starting with dot is standard unix behavior and most users would probably be surprised if this wasn't the default behavior. As most developers assume the dot files are hidden they often have technobabble like names and contents that would intimidate users with little unix experience.

My suggestion had nothing to do with how we handle files dot files. It was about how to hide ordinary files with names not starting in a dot. The goal was to give ordinary users a more uncluttered view of the system. The idea was to hide system related files that they usually have no reason to look at unless they are sysadmins. E.g. /etc

If the user knows enough to type /etc in a file dialog why not let him go there whitout any dialogs popping up. Not showing directories like /etc/, /usr, ... is to make directories more frequently used by ordinary users more visible, not to prevent people who really want to go there to do so.

If you ask your secretary to save a file chances are that she will not save it in /etc/, /usr/, /lib, /proc,... So why should she have to know that they even exists. To her they are just annoying technobabble. They relate to the computer rather than to the work at hand in most cases.

As long as the user keeps saving and accessing thing in his own folder or his coworkers folders the current system works OK as the user is not exposed to the full file tree where the majority of folders are places where he have no business unless he is the sysadmin.

What if a remote samba server is mounted as /Shared Files or /Projects or somethning. In this case the user need to navigate the full tree. You could solve it by adding a link in each users home directory called Shared Files, but how would you then emphhasise to the user that the area was a shared area, not totally under his control. The solution with links also puts much more burden on the sysadmin as he have to make shure that no user allready have a file with the intended link name in his home directory before he make that link.

I think that if you like this or not, depends on your attitude. If you see Gnome as a way of controlling your computer, to remove them would be annoying. If you see Gnome as a way of getting work done to have them is equally annoying. Unless of course your job is to control the computer. Most people are not sysadmins though, and sysadmins are supposed to be able to turn this off. So, have them turned off by default would be the most usable beheavvior.

Why is it a problem to hide the place where applications is? Applications that the user is supposed activate by selecting them with from nautilus should have a starter and a distinktive easily reconized unique icon. Other applications are typically used from the command line, and the system helps the user find them as they are in the path. The shell could even help the user by utilizing command line completion.

If we should have a folder for applications, the average office rat would be much better served by some virtual applications:// folder that showed all GUI apps. Such folder could also be used to simplify software installation. Just drag a software package into that folder to install it. Let each application icon have a uninstall menu item on their context menu.

If you ask your secretary to save a file chances are that she will not save it in /etc/, /usr/, /lib, /proc,... So why should she have to know that they even exists. To her they are just annoying technobabble. They relate to the computer rather than to the work at hand in most cases.

And she won't know they exist unless she clicks the "Filesystem" link. But why would she? The "Home" link is prominently displayed. Should she inadvertently click the "Filesystem" link, she will immediately realize she is in the wrong place and won't do it again.

What if I trust my secretary enought to put her in my user group and give her access to certain folders in my home directory. Now tell me how she gets there without first passing /.

There are a surprising number of reasons for a person who knows what they are doing (who may or may not be the sysadmin) to browse /etc, /bin, and /usr/bin. If you first have to dick around for 5 minutes and figure out how to turn off the hidden files "feature", it is really annoying.

First, That would be a sign that, the GUI lacks proper configuration tools. If succh needs occur freqently this have to be addressed, but showing information that is irrelevant in most everyday use is not the way to do it.

Second, the use configuration stuff usually resides in dot files, so to do such configuration he would have to turn on "Show hidden files" in Nautilus. By doing so, he will also be able to see files hidden by a listing in a .hidden file.

What if a remote samba server is mounted as /Shared Files or /Projects or somethning.

There are a number of possible solutions. Just off the top of my head...
1) You can try putting the mountpoint in /home or /mnt, which makes
it easier to find.

Putting them in /mnt would reqire the user to see the entire filesystem unless you somehow create a shortcut. (Meaning more work for the admin)

2) Add shortcuts in Places using GConf.

Would create inconsitencys between GUI and non GUI applications, and what if some users prefer to use some other GUI environment than Gnome.

3) Add links in /etc/skel so that home directories are created automatically with the link.

Only works when adding new users, adding a new directory to the home folders would still require the sysadmin to check that existing users didn't have a file named like the intended comman resource to link. Not to mention that the users may think that putting files in their home folder is evasion of privacy.

4) Use GnomeVFS to access the share instead of smbmount. Then you can use the Connect to Server function in Gnome.

Considering how many bugs there are in GnomeVFS and samba this is probably not an option at the moment. It would also be a problem in none Gnome applications.

And if your user is momentarily confused about what he/she has control over, the system will calmly remind them with an error message when they try to overwrite a file they don't have access to.

A usable system should guid the user to do the right thing, so that errror messages can be avoided whenever possible.

If you see Gnome as a way of getting work done to have them is equally annoying.

Really, it isn't annoying unless you get lost. And you shouldn't get lost if your sysadmin has done his job.

It's not a matter of getting lost or not. It's a matter of adding garbage to the users cognitive map of the system. You could argue that the user can learn to cope with this, but why should he have to do that. The user should be presented with all the information he needs, when he needs it.

This is how userinterfaces to mission critical systems usually are done. Imagine a fighter pilot in a combat situation loosing altitude. In this situration a calm female voice will probably say: "altitude", "Altidude", "ALTIUDE", "EJECT!","EJECT!!".

In a fighter designed by Gnome developers it would say "altitude","15 minutes of fuel left", "tail light malfunction", ...,"Altitude", "14 minutes of fuel left", "tail light malfunction", "ALTITUDE",...And from a hole in the ground you would finally hear the word "EJE.."

Even if the user isn't confused, unneeded information wastes time that could be used for something better.

It is more annoying to have a legitimate reason to go look for something in /usr/share and find that it isn't there.

As said before, you could turn on "show hidden files" from the view menu in nautilus, and it would still be there for you. If you frequently need to go there in your line of work I'm certain that the sysadmin would agree to remove its listin in the .hidden files involved.

Also, you are only considering a managed computer situation.If I am fiddling around on my personal computer, I don't want it randomly hiding files from me The first thing I do with every Windows installation is Show System Files, Show Hidden Files, and Show File Extensions, even if it is a multi-user computer.

Then I suppose you turn on "show hidden" files in Nautilus. In that case you would not be affected at all by this change.

I would also say that Unix is an extremely poor single user OS. It have lots and lots of features that only will get in your way. E.g why have permissions, logins etc. Old MacOS-9 or Windows 98 would do a much better job at this, not to mention that you would have more games to play with.

The main reason for people using Unix as single users are because they want to play sysadmins, in this case the more complicated the system is the better. It makes the user feel intellectually superior to people that spend their nights with their girlfriends instead of in front of the computer. Even in this situation, the more simple solution is better as the sysadmin wannebe now can bragg about how he managed to unhide the folders.

Applications that the user is supposed activate by selecting them with from nautilus should have a starter and a distinktive easily reconized unique icon.

Well, I suppose this is more a desktop integration problem. Not all apps are Gnome or KDE apps for one, so they don't necessarily create icons. When you go to create a launcher or associate a file type with an application, you usually have to select the binary because the Known Applications list is only ever partially complete. Some applications get installed into /usr/local, and either aren't in the PATH or need to be run from their installation directory, so guess what happens if /usr is hidden?

If the program isn't in the PATH I would say that it isn't correctly installed. Similar could be said if its a GUI application and it have no application starter. To create such starter you should get a list of applications in the PATH, you or the sysadmin should not have to browse to it.

If we want Gnome on ordinary users desktops we need to think like ordinary users, and surprise surprise, ordirary users don't think in Unix

First, MacOS-X is a system that enables the user to focus on the work at hand instead of computer related stuff. This is a good thing. I can't see why Gnome shouldn't do the same.

Second, MacOS-X is only available on a limited set of platforms, Gnome could run on intel, sparc,... you name it. Not to mention that Gnome can be used as a frontend to many OSes not just Linux.

If I follow your line of reasoning we don't need Linux either as there already are Unixware, AIX, HP-UX and Solaris. The difference between Linux and the other alternatives is that Linux is free. The same difference would exist between the MacOS-X GUI and Gnome.

Gnome have allready borrowed a lot from Apple. Not surprising as
Andy Herzfeld was the original desinger of Nautilus, so why not borrow some more if it makes Gnome better, and we can do away with it without violating some Apple patent. In fact Gnome should assimilate whatever good features we can find in other systems, improve on them and adapt them to make them true Gnome features.

Hiding certain folders from people who do not need to see them is hardly patentable. This is something that would be obvious to anyone with a background in usability. Hidden files and folders have been available in Unix as long as I can remember, even before the first incarnation of MacOS. So I doubt Apple would have much of a case.

At most Apple could object to the method of controling the hiding with a .hidden file. Something that probably could be done better in the first place. For one thing, the .hidden files applies in the same way to all users. Such folder hiding should be controllable on a per user/group level, as different users may have different needs. E.g. will the sysadmin probably want to see it all.

Besides, the MacOS like ability to hide folders is allready part of Gnome. You can start hiding folders tommorow if you like. So why not have some sane defaults. Hiding at least /etc/, /proc, /dev, /usr,
/initrd, /bin, /lib, /sbin, /boot, /root, /lost+found /sys would be an improvement for ordinary everyday users that just want to get the work done.

Root could use "show hidden" files and be in full control.

The file structure visible to users should reflect the business sitation. That's why its good to hide folders that are related to the computer. This gives you the possibility to have easy to find directories outside of /home. E.g. for shared resources as I menitoned in the previous answer.

The problem with the free desktop is that, the people developing see themselves in the role of the sysadmin. To be successful we need to look at the problems from the ordinary users and the organizational point of view. There is really no need to wrap the world around to fit Unix/Linux. Unix/Linux is flexible enough to be wrapped round the world.

The reason root should see everything is that nobody should be able to hide things from him.

If you think that forcing root to see all files would make people think root had all power, that could be easily fixed. He could have an option to hide hidden files.

this is like the age old suggestion of "switch OS" when someone asks a question about Windows.

Here, the solution is simply to fix the bug. Regular focus follow the mouse is NOT the solution. It is highly confusing for new users and a potential usability nightmare. Do not make the mistake of assuming that what you find usable is a good solution for everyone. I call this the "Slashdot syndrome".

However, during a drag operation, sloppy focus follow mouse might be a very good idea indead. OS X certainly uses it, but only switches focus to windows that can accept the data being dragged.

It does however not change the problem if the window you drag FROM completely covers the window you want to drag to.

Solution:
* Do not change window layer when starting a drag operation.
* Use sloppy focus follows mouse during drag operations, but only to windows that will accept the data you are dragging.
* Keep click to focus as the normal default.

You are right, clicking on un unselected icon, or the icon text should select the icon and the text. But if you click on the text of an allready selected icon, the text should become editiable so the user esily can change the name. As far as I know, this works well in both MS-Windows an Mac OS.

I'm sure that sombody have renamed a file by mistake sometimes in OSes that have that feature, but not more frequently than some people accidentally move a file to trash, by hitting the wrong menu in the right mouse button popup menu.

The advantage of being similar to other frequently used OSes shouldn't be underestimated. Just like most people have a feel for how the controls in a car should look and act like, a similar feel have evolved for desktop environments. We can be depressed all day that Gnome wasn't around 15 years ago when that common feeling was formed, but there is not much we can do about it now. In cars we know that the steering wheal can cause damage to the upper torso in an accident. This could probably be avoided by using a joystick between the front seats instead. Yet new cars are not built like that. Instead they put in an airbag to protect the driver.

So if other OSes isn't terribly wrong we should try to be different.
This is not a case of terribly wrong, and if they are terribly wrong we should try to cover for their mistakes in a way that requires as little relearning as possible. In this case, the equivalent of the airbag in cars, could be making file moves and renames undoable.

> So if other OSes isn't terribly wrong we should try to be different.
> This is not a case of terribly wrong,

I disagree. I just got finished teaching a bunch of newbies the ins and outs of Windows. This 'click the filename to rename' feature caused more confusion, and indeed outright panic, than any other feature, including the Capslock key, which the author of the piece rightly complains about.

Considering how eager UI experts are to label features as being 'confusing to newbies', I find it remarkable that he didn't notice how confusing this feature is.

One of the reasons that it is confusing in windows is that if you change the file suffix, the application mapping doesn't work anymore.

It is becomes even more confusing to the windows user as windows in its default configuration hides the file suffix from the user. How would a windows user renaming a file know he should have a suffix, if he can't see it and even if he knew how would he know what suffix to use.

In Unix there are things like magic numbers that can be used to determine the filetype instead of file suffixes, so much of the confusion would probably be avoided.

Another problem is that windows have much more characters that is not allowed in a file name than Unix. This means that users more often get error messages when trying to rename files.

If you had teached Gnome instead of windows, your users would probably been just as bewildered on how to find the right menuitem to rename a file as they were confused in windows.

I have seldom seen MacOS users having problems with direct manipulation, so I suspect that the problems you have experienced are related to the quirks in windows rather than to direct manipulation in itself.

The direct manipulation method also fits well in the desktop methaphore. You don't have to do anything special to write a name on an evelope on your real desktop do you. You just start writing.

I think you've missed the point, though. The users didn't have trouble renaming files -- they had trouble because they ended up renaming files when they didn't intend to. That is why they became confused and panicked.

In the end, I would have to place this feature in the same category as the capslock key. The basic idea is good, but it ends up doing more harm than good because it's simply too prone to accidental activation.

My guess is that they got panic because thye couldn't get the old filename back if it was accidentally changed. Panic and confusion increases, when they find out that they can't open the file to find out what its about, or see the original filetype, to give it a new suitable name or restore the old one. The result is that the user feels that he has seriously broken the system and he gets afraid to accidentally rename files. In this respect Gnome recovers much more gracefully from errors, as file type information remains even if the file suffix is removed. An undo method would make it even better.

I also guess that, the problem was more common in file trees than in the desktop, or in icon views. In trees the icon size is about equal to the text size and the chances are that the user will select the files by their name tag is bigger.

In Gnome the default view is a spatial icon view. In such views users typically go for the icon and not the text to select a file. This means that newbies would be in much less trouble regarding accidental file renaming, than they are in i windows or MacOS... Gnome could also get a better visual cue that the filename was going to be alteed, by changeing the rounded text box to a square one when filename is editable.

By the way, I have also done a fair share of windows and macos training and I have never seen this as a big problem among the students. However, I'm an old MacOS user and would not use tree
wiews very much in windows, as it usually ends up with me
dropping files in the wrong place in the file system, never to be found again. (Easy to do on a laptop in a moving train or bus)
So I may subconsiously train my students to work in a similar way.

So, here is an experiment for you. The next time you teach windows, show the explorer tree view, and tell your students that its error prone, and then do the rest of the training without using it. I think you will find that you have less problems with accidental renames as well as less problems with misplaced files.

I didn't teach them tree view, either. The problem was more pronounced in the file selector, however, but it happened on the desktop as well.

(BTW, I wouldn't object if the feature was present, but there was an option to turn it off. It's not just newbies -- it messes me up, too.)

I'm a big fan (and daily user) of Ubuntu and Gnome, I really like these systems, and the article in question was without doubt the best Ubuntu/Gnome related article I've read since I started using the two.

I was really pleased to see that it found it's way up to footnotes, but I'm really disappointed to see the way that most people commenting here are reacting.

Okay, you don't have to agree with every one of his comments, there were a couple I didn't agree with and a couple for which I was aware of at-least-as-convincing counter arguments, but the large majority of the points he makes are very good points. I doubt anyone could post a point-by-point rebuff of the article and convincingly disprove most of it.

Lets treat this article for what it clearly is - it's a damn good article, and a damn good contribution to Gnome/Ubuntu. The guy has gone out of his way to produce something useful - this sort of stuff from a user is far better for Gnome than congratulations. Not just anyone could write an article like that - the guy has done an excellent job of putting himself into the position of a user, rather than a developer or enthusiast with his/her head 'inside' the system, and doing an objective evaluation.

Ubuntu and Gnome need this sort of thing - one of the basic things you need to do when writing programs is be able to criticise what you write so you can then improve on it. The criticising is not a trivial task, and one kind of input that Gnome and Ubuntu need is criticism.

Another one of the key things you need to be able to do as a developer is react positively to criticism - see things from the point of view of the critic, learn the lessons that are to be learned from this criticism, and figure out how to respond by improving your system.

Gnome is a really good desktop, but if too many contributors lack the ability to respond well to a really valuable piece of criticism like this, then it's doomed.

That sounds dangerous. I expect typing in a nautilus window to find a file. If I had an icon selected by accident, my search would start renaming files.

I think the point is that this guy has lots of *specific* places where Ubuntu (and GNOME) can be improved. I certainly don't agree with all of them. (I like the menu+plus icons and the menubars). But I'm really impressed that someone is being paid to complain like this.

This kind of feedback is *exactly* what GNOME and Linux needs.

I especially like the *laptop won't suspend* which is my bigest gripe with Linux right now.

As with most lists of complaints, a few of these appear reasonable (trying to play/copy audio CDs with nautilus, network configuration slowing down startup immensely, etc...), a few are obvious Macintosh-biased complaints which have already been debated countless times (menus, etc...), and a few seem to be entirely wrong. At least for me, Evolution caches all of my 2000 archived emails on IMAP. Is he confusing the check for changed messages with downloading all messages?

As for sleep, if you are using Ubuntu, have you tried running /etc/acpi/sleep.sh (as root)? You will need to edit /etc/default/acpi-support first in self-explanatory ways. Unfortunately, support for sleep/resume in various kernel drivers isn't very good (probably due to lack of development documentation on these features). Binary only drivers also appear to commonly lack support for this, even though these companies have the information required to support this: Linuxant's hsfmodem must be removed prior to sleep, and ATI's driver will apparently not sleep at all.

Yeah, good idea. Totally denigrate *all* of his complaints and gain zero wisdom from them by deriding him as an "Apple Fanboy". That's a great attitude toward criticism.

-jag