The Power of Defaults

January 27th, 2010

I tend to see two extremes whenever there are arguments about what should be the default (I’m speaking specifically of arguments on the Ubuntu Forums, but this could be applied to really anything in technology or anything in life in general).

One extreme is that defaults don’t matter at all. It’s not worth arguing about. Just put whatever as the default. Then people can just choose to change the default to something else if they don’t like the default. The other extreme is that defaults matter enough to have 500-post forum threads about arguing back and forth. Somewhere in the middle is some sanity.

Defaults matter. But defaults are only defaults. People can choose options other than the defaults.

Why do defaults matter? Here are some examples:

  • I love that on my wife’s Macbook Pro, you just press the function keys, and they do something right away (lower the volume, adjust the brightness). My netbook by default needs to have the blue Fn key pressed in combination with the function keys to get that behavior to happen. I can easily change that. But if I change it, it’s confusing for anyone else using my netbook, because the instructions on the physical keys themselves indicate the function keys are normal functions and that you need the Fn key in combination in order to do anything. In other words, whole products sometimes have fixed parts built around the assumption that defaults will go unchanged.
  • I use VLC for playing individual sound bits or videos. When I dug into the settings for VLC, I didn’t understand half of what that stuff is, and there were a lot of options to configure. Very confusing for a multimedia newbie like me. Good thing I didn’t have to configure all those settings. I just used the defaults. Sane defaults save the user from having to understand unnecessary minutiae.
  • As far as I can tell, every Linux user has a list of things she does immediately after a fresh installation. I usually change the wallpaper to a picture of my cat, replace Evolution with Thunderbird, add in some proprietary codecs, and delete the bottom Gnome panel. Sane defaults should make the sense for the most users. Even though I personally delete the bottom Gnome panel, the vast majority of Gnome users like to have both a top and bottom panel, so to have the top panel only wouldn’t make sense, because it would mean more people would have to take more time configuring things. If defaults are well-thought-out, less time is spent tinkering and adjusting and more time is spent using.
  • Linux live CDs can come in handy, especially if you need to help a Windows user recover deleted data. What happens in a default installation is the first impression that non-Linux user is going to have of Linux and may be the only impression she has. So if an ugly noise or splash screen appears, that’s the impression she’s going to get. It doesn’t matter if that noise or splash screen can be changed. Likewise, if you are using the live CD to show someone what Linux is like, you don’t want to have to “uninstall” and then “install” in the live session a whole bunch of software, especially if the computer you’re using has very little RAM.
  • And don’t forget that even though power users like to tinker and explore, most people just stick with defaults. 99% of Windows computers I see have the taskbar on the bottom, even though you can easily drag it to the top or the sides. 99% of Windows XP computers I see have the stupid blue theme, even though you can easily change to a silver or classic theme. Even though Firefox’s marketshare has skyrocketed in the past five years, Internet Explorer is still, globally the more-used browser over Firefox, Opera, Chrome, and Safari. It being the default web browser in Windows probably had something to do with that.

Yes, if you have an absolutely unbearable default, many people will probably just ditch it anyway, but instead of thinking “I’m so glad I have the freedom to change this setting,” they’ll most likely be thinking “What a terrible default! Who thought of that? Now we’re all going to have to change this!”

Sometimes defaults can have ethical considerations, too. For example, making people have to opt out of sharing information with a company or third-party corporation “partner” is a bad default (people should always have to opt in for that sort of thing), because it means if people forget to change the defaults or don’t investigate all of their basic settings and advanced settings, they will end up sharing more than they intended to share.

So if I see a bad default in Ubuntu, I’m going to make a point to say it’s a bad default. Good defaults matter. I will not, however, spend hours of my time arguing the point back and forth. Some things are a deal… they may not be a big deal, but they are still a deal.

The GUI v. CLI Debate

November 10th, 2009

I’ve been helping with online tech support for Ubuntu for over four years now, and every now and then the discussion comes up about whether it’s “better” to use terminal command instructions or to use point-and-click instructions when offering help.

Inevitably, some die-hard CLI (command-line interface) fans come out and say that the terminal is “more powerful” and that every Linux user should learn to use the terminal, and then some die-hard GUI (graphical user interface) fans come out and say that the terminal is intimidating and that if Linux wants more users, it has to develop more graphical interfaces for things; and then you get the hardcore Linux users who claim they don’t care if Linux gets more users or not, etc., etc., ad nauseam.

The truth is that neither CLI nor GUI is always “better” than the other. There are appropriate situations for both CLI and GUI on a support forum. I hope everyone can agree that all common tasks should be able to be done in the CLI and through the GUI. Choice is ultimately what’s most important, so that those who prefer the CLI can use the CLI, and those who prefer the GUI can use the GUI.

But if I am offering help to new users, do I give GUI instructions or CLI instructions? It depends on what kind of support I’m giving.

When is GUI support appropriate?
If a new user wants to know how to do a basic task that she will probably repeat (or, if not the exact task, then at least something similar) in the future, then I will usually give point-and-click instructions to encourage that user to explore the GUI for that kind of task. For example, if a new user asks “How do I install Audacity?” then I am not going to say “Just use sudo apt-get install audacity.” Instead, I’ll tell her to use Applications > Ubuntu Software Center or Applications > Add/Remove, or just link her to this tutorial on how to install software. There are several reasons I do this:

  • Even though the apt-get command makes perfect sense to me, it is just cryptic gobbledygook to a new user, and it will not help her to install other software in the future unless I bother to explain how the command works; and, more importantly, even if she understands how apt-get works, she’ll still need to know the name of the package she wants to install in order to use the command most efficiently.
  • A lot of new Linux users (myself included, when I first started) have an irrational fear of the terminal, even if you tell them to copy and paste the command with a mouse (no typing necessary). Eventually, as they become more comfortable with the new environment that Gnome or KDE (or Xfce or whatever other user interface they’re exploring) has to offer, they are more likely to be amenable to learning terminal commands and even liking them.
  • Among Windows power users (the most likely group to migrate to an almost-unheard-of operating system that requires download, installation, and configuration from the user and not the OEM), there is already a reputation Linux distros have of being too terminal-dependent. It’s great to advertise to new users just how many things can be done by pointing and clicking, and that will make their transition to Linux that much easier.

Ah, some veteran forum members would protest, but what if I don’t want to bother making screenshots or typing out long point-and-click instructions that can be summed up in a single command? To that, I say if you’re too lazy to offer appropriate help, don’t offer help at all. Someone else will help. Or, better yet, find a good screenshot-laden tutorial and link to the tutorial instead (that’s actually how I started up my Psychocats Ubuntu tutorials site—I got tired of constantly retyping the same support posts over and over again, so I just made one place I could keep linking new users to).

I would say something similar to those who use Fluxbox or Enlightenment and want to primarily help those who use Gnome or KDE. If you aren’t familiar with the graphical environment the user you’re trying to help is using, don’t offer help in that instance. Save your help for when the CLI is appropriate.

When is CLI support appropriate?
The GUI may be fine for common tasks (installing software, launching applications, managing files and folders), but what if someone runs into a problem? What if what she’s doing is not a common task but a one-time setup or configuration? There’s no way if a new user says “When I try to launch Firefox, it just disappears” that I’m going to offer a point-and-click solution. Problems are best diagnosed with the CLI, and terminal commands (even for GUI applications) are more likely to yield helpful error messages. Likewise, if her wireless card isn’t recognized properly or fixed by System > Administration > Hardware Drivers, it isn’t a crime to walk her through manually editing configuration files to fix the wireless problem, because once it’s fixed, she should never have to do that again.

If you do offer CLI solutions to problems, though, as much as possible try to explain what these commands mean or do. You don’t have to copy and paste in a whole man page (in fact, that probably won’t be helpful at all—I’ve been using Linux for years and have yet to find a man page I actually understand). Just keep in mind that to many new users, terminal commands are like a foreign language they can’t even say hello or thank you in.

CLI and GUI aren’t going away any time soon. One is a hammer. One is a screwdriver. No one tool will suit everyone best at all times. Use what’s appropriate. Appreciate that what you like or prefer may not be what someone else likes or prefers.

Rory Cellan-Jones recently spent 24 hours with Ubuntu:

I installed a few applications – including Skype, and a social networking application called Gwibber.

But when I tried to install a free open-source audio editing program, Audacity, it appeared more complex to get hold of an Ubuntu version than the one I’ve used on a Mac.

So it was simpler than this on Mac?








What was tripping you up? Not knowing a sound recording and editing program would be in the Sound & Video category? Or not realizing how silly it is to have to open a web browser to install a program? Do you find the iTunes App Store difficult to use? Because that’s pretty much the same thing, isn’t it?

I very much look forward to reading your next article, “24 hours learning to ride a bicycle.” The wheels must just not be worth the effort.

Further Reading
Know why software installation is difficult on Linux? It’s a secret. I can’t tell you.

Ubuntu Linux gets released twice a year—once in the spring, once in the fall. The releases are numbered to indicate the month of release. Most spring releases (with the exception of Ubuntu 6.06, also known as Dapper) were released in April (5.04, 7.04, 8.04, 9.04), and all fall releases so far were released in October (4.10, 5.10, 6.10, 7.10, 8.10).

I’ve always been a bigger fan of the April releases than of the October ones. That’s changed with this next release (9.10) nicknamed Karmic Koala. I just installed the beta release (it had gone through six alpha releases previously), and all the standard disclaimers apply, of course (if you install beta, you do so at your own risk, don’t use it on a production machine, you may lose data, blah blah blah. There is no warranty, real or implied.) Nevertheless, I’ve generally found (with few exceptions) that Ubuntu beta releases are more or less stable. I haven’t had anything catastrophic happen with a beta Ubuntu release (your mileage may vary).

And I like this October one. I think Ubuntu is finally heading in the direction Mark Shuttleworth has said for years that it should head in. It’s focusing on usability. It’s focusing on looking better. It’s focusing on hardware compatibility and working out a lot of the little bugs that make a big difference.

Speed
With the last release (Jaunty, 9.04), boot time was a little over a minute from the moment I pressed the power button to being actually able to use the system (that’s what I consider boot time, not when you see your desktop). With Karmic (9.10), boot time is only 37 seconds. It’s not the 10 seconds some people have been touting (and, yes, I have a solid state drive, too). Still very impressive.

More importantly, the interface is more responsive. I don’t know how to do actual timing benchmarks. I’m sure the difference is just a matter of milliseconds, but it feels much snappier. There is no lag switching windows or clicking on a button. In Jaunty, there would be a barely noticeable delay in rendering when simply closing a tab in Firefox and having the next tab appear in focus. In Karmic, no delay at all. It’s nearly instantaneous (not as fast as Chromium, but for all intents and purposes fast enough). I’m using a crappy Intel Atom processor, by the way.

Appearance
Aesthetics is, to a large degree, subjective. Nevertheless, there are certain visual implementations in interfaces that are in vogue in the corporate and consumer computing worlds, and I think Ubuntu is moving in a good direction here. The boot-up is so fast that there isn’t even a loading boot screen (there is in the live CD session, though, and it looks nice). The icons are much cooler-looking. It’s pretty clear, though, that much has been copied from Mac OS X, including the applets for wireless and power management, which now have a simple light-gray iconization instead of pixelated blue bars and complicated graphics that don’t always render well.

One gripe I have is that there is still text displayed during bootup. Granted, if you want text displayed during bootup (some kind of verbose mode), that’s good. The default should have only graphics, though. The Grub boot menu is all text (white text on black background), and then there are little boot messages that scroll by very quickly (visible for only a couple of seconds). I’m hoping that’ll be fixed in Ubuntu 10.04.

Along with the Macification of icons, there is also the simplification/Macification of the interface. System > Administration > Login Window no longer brings up a multi-tabbed preferences window with lots of options. It now has basically two options (autologin or not, show the screen to log in or not). System > Preferences > Sound shows a sound dialogue that looks an almost exact carbon copy of the Mac sound preferences dialogue.

Most importantly, the new Ubuntu Software Center is even easier to use than Add/Remove or Synaptic. It just puts all the options in your face and filters things quickly. You don’t have to mark things for installation and then apply. You just click to install each item, and it does it right away. The progress bar is inline instead of a new pop-up window. It just seems fast.

Hardware Recognition
Jaunty was pretty good at recognizing hardware. There was a little regression, though, that made it so that certain Intel sound chips didn’t work and Alsa had to be recompiled from source… oh, and for my set-up anyway, PulseAudio (the default sound management system) always had to be uninstalled to get sound to work. There was also a bug that had wireless take “forever” (between 30 seconds and a minute) to come back after resume from suspend (or “sleep”).

In Karmic, sound worked with PulseAudio (I just had to change the input from Microphone 1 to Line-In), wireless worked after resume within seconds, and everything else worked, too (no regressions for screen resolution, power management, or hotkey recognition, etc.).

One little bug (which I filed) is that the hardware drivers for Broadcom 4312 install fine during the live CD session, but once you install Karmic, the drivers need to be uninstalled and reinstalled to work, and then only after a reboot. Hoping that gets fixed before final release.

Conclusion
Overall, this is a totally awesome Ubuntu release. If my friends would just stop using iPod Touches and iPhones (or if Apple would play nice with other systems or port iTunes to Linux), then I could actually recommend Linux to people.

Introduction
Add key for Chromium daily build repositories
Add Chromium daily build repositories
Install Chromium
Enable plugins
Use system GTK theme
First 4 steps with one terminal command

Introduction

Chromium is still in testing. It has not been officially released, so please do not expect it to run well. In the minimal use I've made of it, it appears to run okay, but daily updates could just break it at any moment.

So please be prepared to have a backup browser ready to use (like Firefox) and do not do anything critical in Chromium at this time (e.g., something you'd be really sad about if you were in the middle of doing it and your browser randomly crashed).

Click on any of the screenshots below in order to see a larger image.

Add key for Chromium daily build repositories

First, add the GPG key for the Chromium daily build repos.

Visit the Chromium daily builds section of Launchpad.


Copy the line of code to add the key.


Open up a terminal.


Paste in the code.

Add Chromium daily build repositories

Now we need to add the actual repositories.


Go back to the PPA page, select your version of Ubuntu, and then copy the first line of text.


Go to System > Administration > Software Sources and enter your password when prompted.


Under Third-Party Software click Add. In APT line: paste in the line, and then click Add Source.


Do the same thing for the second line.


When prompted to reload the the repositories information, do so and wait.

Install Chromium

Now that we have the daily builds repositories enabled, we can actually install Chromium.


Go to System > Administration > Synaptic Package Manager and search for chromium


Mark chromium-browser for installation and then confirm the Mark.


Click Apply and then confirm again by clicking the second Apply when prompted.


Wait for Chromium to finish installing.


Quit Synaptic and quit Firefox.

Enable plugins

Even though Chromium is installed and ready to use now, it doesn't come with the browser plugins enabled (no YouTube... no anything involving Flash).


If you want to enable plugins, go ahead and launch Chrome.


Copy the little phrase --enable-plugins


Right-click the Applications menu and select Edit Menus


Then, under Applications > Internet, double-click Chromium Web Browser and under Command, paste --enable-plugins right after chromium-browser and right before %U, so the whole command will read

chromium-browser --enable-plugins %U

Use system GTK theme

By default, Chromium will have the same blue border that Chrome has in Windows.


If you want to blend it in with your GTK theme, click on the wrench and select Options


Then, under Personal Stuff, select Set to GTK+ theme


That's it. You're ready to go now and use Chromium!

First 4 steps with one terminal command

If you've never added the daily builds repositories and if you're using Ubuntu 9.04 (Jaunty Jackalope), you can do all the first four steps (sans getting Chromium to use your GTK theme) by just pasting this one command into the terminal:
sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 4E5E17B5 && echo "deb http://ppa.launchpad.net/chromium-daily/ppa/ubuntu jaunty main" | sudo tee -a /etc/apt/sources.list && echo "deb-src http://ppa.launchpad.net/chromium-daily/ppa/ubuntu jaunty main" | sudo tee -a /etc/apt/sources.list && sudo apt-get update && sudo apt-get install chromium-browser && mkdir -p ~/.local/share/applications && cp /usr/share/applications/chromium-browser.desktop ~/.local/share/applications && sed -i 's/Exec=chromium-browser/Exec=chromium-browser --enable-plugins/g' ~/.local/share/applications/chromium-browser.desktop