Archive | Tech RSS feed for this section

Android should get rid of the back button.

13 Nov

I made the longer argument here, but let me make it more succinctly. The chain of logic goes:

  1. The back button should only be used for navigating between apps, not within any application.
  2. The recent apps screen serves application switching more predictably than the back button (even under its most favorable circumstances), except…
  3. …the recent apps menu is not quick enough for the common case of switching back to the last app, so we need a quick button/gesture for this. I suggest a swipe up motion from the recent apps button (similar to the swipe up on the home button that currently takes you to Google Now). It’s debatable whether repeating this gesture should cycle you through all recent apps or just between the current and last app (I suspect current and last is the better behavior). Either way, this back-to-last-app allowance covers the most useful case for the back button: when an application switches you to another app–such as to display a link in the browser, compose an email in the mail app, or play audio in the music player–you should be able to get back to what you were doing previously with little effort or thought.

So the recent apps button with a simple new allowance is a better back button than the back button itself.

Now of course, claim (A) requires substantiation, which two members of the Android team do a well enough job providing here. The odd part is that they as much admit in passing that the back button is a bad in-app navigation mechanism and then spend the rest of the talk proudly describing the surprisingly convoluted scheme Android and its apps must conform to to deliver non-maddening  back button behavior. Why subject developers and users to such headaches?

Android should ditch its too-clever-by-half task/activity paradigm in favor of the app/screen model expected by developers and users alike. If my app wants to open a link in the browser, that’s not a new activity, its just an app switch to the browser, just like on the desktop; going back to the app should be an ordinary matter of app switching requiring no special cooperation on any app’s part.

A problem that remains is deciding when apps should open to their last viewed screen or their ‘root’ screen: when I switch back to the app I was using 2 minutes ago, I usually expect the screen I was just looking at; but when I switch back to an app I haven’t used in a long while, I usually expect the app’s root screen. I’m not sure what exactly the timeout period should be, but I do know what screen I see shouldn’t depend upon how I open or switch to an app, whether through the launcher or recents list. It should be the responsibility of apps, not Android, to make their root screens easily accessible from any state.

Again, strangely, the Android team seems to have caught on to this, at least going by the example they’re setting in their own apps with the ‘Up’ navigation element now in the Gmail, Caldendar, and Youtube apps. Obviously some legacy apps rely upon the back button, so it should get deprecated like the menu button: back should only contextually appear on the bottom bar within those legacy apps. And of course, some applications might have their own in-app need for history navigation, e.g. the web browser. This in-app navigation, though, should be done with app-specific, in-app controls, not a universal button. Again, the Android team already sets the precedent here by including a proper back button in Chrome for Android.

The last remaining piece is to make app-initiated app switches visually distinct from mere in-app screen switches so as to keep the user oriented (and so the user can utilize the back-to-last-app action when it’s most needed). If an action in an app takes me to the web browser, Android should make it very clear that I’m switching to another app. One solution would be to replace the ‘recent app’ button icon with the icon of the current app, such that the user can always get a visual indicator of the current app; when switching apps, this icon would pulse or glow for a brief time to make the switch more noticeable.

Other people’s choices matter

13 Feb

PC vs. Mac, XBOX vs. Playstation, iPhone vs. Android, my programming language vs. your programming language—these are not idle disputes. Contrary to popular moralizing, you’re perfectly justified complaining about what other people in the market choose because what they choose affects you. No market is infinite, so without a critical mass of consumers that share your preferences, your preferences may not get met.

For example, an ever growing tide of Apple-fawning consumers at some point may ruin things for the rest of us as the Apple model of locking everything down gets duplicated by its competitors. Who knows what an Apple-dominated world of computing then looks like: does the price-performance ratio improve as steadily as it has in the PC era? Does the cost of assembling a PC from parts go up? Does the ability remain at all?

If it were a good idea, it would exist already

8 Feb

Re my previous post, I should acknowledge that ‘Lisp without parens’ is a very old idea. Old enough that any time it comes around again, long-time Lispers leap out from their parenthesis-girded fortresses to ridicule the idea. This raises a good question: if Lisp without parens is a good idea, why hasn’t it become a reality? I have three explanations:

  1. The Lisp-without-paren solutions of the past made the fatal mistake of trying to infuse Lisp with infix notation. See, for example, Dylan. This is just a bad idea, as it solves the too-many-parens problem but complicates (at best) Lisp’s homoiconicity, making macros much harder to write and thereby defeating Lisp’s one remaining unique feature.
  2. Indentation-sensitive syntax was an old idea before Python, but before Python took off, everyone ‘knew’ it was a bad idea. (And in fact, some still insist that indentation-sensitive syntax doesn’t work.) And it wasn’t until Python was well established that a few people began to suggest using indentation to leave Lisp parens inferred but keeping the S-expression structure intact. So the idea of Lisp-without-parens is maybe 50 years old, but the idea of Lisp-without-parens-but-keeping-S-expressions is less than a decade old. As the Python example illustrates, sometimes good ideas just take time and a few failed starts to become reality.
  3. A more general problem is that having one good idea often isn’t enough: existing technologies and their accompanying ecosystems have a lot of inertia, and the current set of users will resist the pain changes bring as long as the benefits are unclear or seemingly minor. The applicable lesson from this is that the first successful Lisp that gets rid of parenthesis will most likely include other compelling features.

I’ll submit that Animvs avoids these problems. It cleans up the parens and indentation style, but keeps the syntax homoiconic and reductively simple (simpler, in fact, than any existing Lisp, what with their hacky reader macros polluting the nice clean symbols). It also introduces new ideas other than just a new syntax.

Reinventing the desktop (part 2): I heard you like lists…

2 Aug

In part 1, I made a negative case against the desktop interface as it currently exists, but I promised to make a positive case for my solutions. Because it would take at least a few weeks to put together a complete presentation, I thought it more timely if I instead present the ideas in installments (and hey, more reddit karma whoring this way). Most of the pushback to part 1 (both constructive and vitriolic) concerned my ideas about lists, so I decided to start there.

Rather than writing this up, I thought a screencast would be more appropriate for presenting these visual ideas. The run time is 37 minutes. (Yes, I know that’s long, and it starts slow, but if I’m not thorough, I just leave myself open to superficial dismissals.)

(I apologize for some parts where my narration gets a bit difficult to follow: I heavily edit the audio and end up removing awkward gaps and pasting together sentences from different takes; this works surprisingly well most of the time, but sometimes the result sounds a bit like Max Headroom.)

Video cards I have owned

19 May

In chronological order:

  • ATI WinMach64
  • ATI Rage II
  • Voodoo 1
  • Voodoo 3 3000
  • Voodoo 5 (yeah, that was a mistake)
  • Savage 3D (another mistake; think I returned this one)
  • Riva TNT 1
  • Matrox G400
  • Geforce 2
  • Geforce 3
  • Geforce 4
  • Radeon 9800 Pro
  • Radeon X800 XT
  • GeForce 6700
  • GeForce 6800 (a warranty replacement for the cooked-itself-to-death 6700)
  • GeForce 7800
  • GeForce 8800
  • Radeon 4850

That’s 18 cards in about 15 years. I justified this shameful consumption by usually pawning my current card off on a family member as an excuse to get an upgrade.

The cards that made me the most happy were the Voodoo 1, the TNT, the GeForce 2, the 9800 Pro, and my current 4850. The 4850 actually seems to have cooked away its thermal paste or something and now runs really hot under load—often over 100 degrees Celsius! Shockingly, I haven’t seen any stability or artifact issues despite this, so I’m going to hold off on replacing it until I really have to.

How to make a decent screencast

20 Feb

A lot of screencasts suck, and it’s quite apparent why: the typical sucky screencast is thoughtlessly produced in about the same amount of time as it takes to watch it. If you want to produce a decent screencast, you should expect the production-time-to-viewing-time ratio to be more like 20 to 1 rather than 1 to 1. (I arrive at the figure 20 based on the fact that screencasts I’ve produced in the past with a ~10 to 1 ratio still sucked quite badly. I suspect, however, that the correct figure is closer to 30.)

Anyway, to produce decent screencasts, I’ve settled upon a quite involved process:

The content

  1. First, create slides. If your screencast really requires full-motion video, we’ll insert that later. For now, just use the slides as a kind of outline or guide, even if they aren’t going to appear on screen in the end. For presentations, I’ve gotten accustomed to PowerPoint 2007, as OpenOffice Impress is just too clumsy, and the presentations that Impress produces are much harder to make look decent.
  2. Second, record your narration. If you’ve written out everything, try improvising with the words a bit to help give the illusion that what you’re saying is extemporaneous. If you’re just making it up as you go along, that’s fine and in fact the way I do it, but understand that you should record in short intervals (~15-30 seconds) with as many retakes as it requires to get it right. Do not expect to deliver even just a few minutes of talk off the top of your head in one take. If you’re doing it right, working without a script goes quite slow. Each minute of narration I’ve produced this way has taken about 5 to 10 minutes of recording.
  3. Third, edit your narration. If you worked without a script, you’ll likely have many flubs and odd pauses to remove, even if you properly did retakes. You’ll also likely need to add appropriate breathing space between topics. Even if your performance is perfect, you still probably need to normalize and compress to help even out variances in volume, and you may want to try noise reduction (just don’t use too much because you’ll then end up sounding robotic).
  4. Fourth, use desktop recording software to record the slides. I’ve found the automatic slide timing in PowerPoint too clumsy to match the slides to the narration, so I just click through the slides myself while listening to the narration. To do this well, I find I need to first listen to the narration and create a list of the times at which I need to click. If you need full-motion clips of your desktop, simply produce them individually to be edited in later.
  5. Fifth, use video editing software to put the video and sound together and to compress it all into a deliverable format. If the sound doesn’t match perfectly to the video, try duplicating and remove frames as necessary.

The technical bits

Rather than use a deskstand mic, I use a headset-style mic. Because I find the headphones uncomfortable, I wear them around my neck with the mic bent in place in front of my mouth. Understand that small changes in the mic position relative to your mouth will produce very noticeable changes in the acoustics of your voice, so try to find a single position and head angle to use every time.

To record and edit the audio, I use Audacity. Hit R to record, space to stop. (Be careful because if you hit R and space too quickly after each other, Audacity–on Windows at least–tends to crash. I suggest saving to WAV for every minute you produce.) Unfortunately, Audacity starts a new track every time you hit R, so you’ll have to manually consolidate the tracks, but it’s thankfully not too bothersome to do this: just cut and paste by highlighting with the mouse and using ctrl-x, ctrl-v. (Tip: after consolidating, delete the empty tracks by clicking the small x in the top left of each track.)

While recording, I prefer to start a new WAV file for every 4 or 5 minutes of audio so as to diminish the chance of losing work. I number the tracks like so: blabla-000.wav, blabla-001.wav, blabla-002.wav, blabla-003.wav, etc. (where blabla is the name of the screencast).

When done editing the audio, I use the compressor effect in Audacity to get consistent volume. I set the threshold to -30db, and if the end result doesn’t look even, I’ll run the compressor again one or two times until it does. Then I find a bit of audio where I’m not talking but which has some noise, select it, click ‘noise removal’, click ‘get noise profile’, then select the whole audio, click ‘noise removal’ again, slide the slider all the way left, then click ‘remove noise’.

Through this whole process, save everything as at least 44.1khz 16-bit stereo in WAV format. If we’re going to degrade, we can do that later.

To capture video of the desktop on Windows, I use CamStudio, an open source tool. Some Vista users will find that the 2.5 beta has fixed sound recording for them, but because we’re not using it to record sound, I recomend just using 2.0. Also be sure to download and install the CamStudio lossless codec (latest is 1.4, at the moment), which I find is the best for pristine full-motion desktop capture. I do my presentations in 16×9, so I set the desktop to 1280×720, run the presentation in full screen, and use CamStudio to record the full screen without any audio. Handily, CamStudio has an option to disable recording of the cursor.

To edit and compress the video, I use VirtualDub. Using the CamStudio codec with VirtualDub requires installing the DirectShow plug-in (which does not work with 64-bit VirtualDub, so be sure to use 32-bit).

Open the video file, then under “Audio”, specify “audio from other file…” to get audio from the appropriate .wav file. You may have to adjust the sync under “interleaving”. Because we’re compressing to mp3, first select “full processing mode”. While your original mic recording in Audacity will be in mono, you at least want it to be mono coming out of all of the listener’s speakers. Otherwise, even a decent narrative will come off as sounding tinny, dull, and lifeless. So under Audio->Conversion, be sure to select stereo. Then under “compression”, I suggest 44100 Hz 128kbps stereo mp3. (Also, stick to CBR as it will further reduce the possibility of sync issues. If you need an mp3 encoding codec, LAME mp3 is the obvious choice.)

Under “Video” select “fast recompress”, then select a compression codec. I recommend x264vfw, an h.264 codec. (VitualDub requires Video For Windows encoding codecs, so if you already have an h.264 codec, you may still need x264vfw.) Experiment with the compression levels until you find something acceptable.

Assuming your video is mostly still images, the video data should run at well under a megabyte per minute such that the audio data will most likely outweigh the video data in the final file. A 10 minute video produced this way takes about 15 megabytes. I’m sure with greater compression expertise, this could be cut substantially, but if your end target is Youtube and other video services, I strongly recommend aiming for quality first and letting them handle any further compression.

Personal Rapid Transit (yeah, the People Mover thing at Disneyland)

17 May

How’s this for blogging on the cheap? Below is a paper I wrote for English 101 a while back. I’ve reworked it slightly (removed the silly Chicago citations), but it retains the stilted prose and mechanical structure of any good My First Research Paper. In any case, I’m fond of its clarity. Perhaps in some future post, I’ll follow up with a lengthy discussion of the political and aesthetic obstacles keeping PRT’s from being taken seriously.

In 2002 in the United States, approximately forty-three percent of the oil we consume—making sixteen percent of the total energy we consume—is consumed by personal cars and light trucks. In the same year, cars and light trucks accounted for thirty-three percent of the carbon dioxide, fifty-one percent of the carbon monoxide, and thirty-four percent of the nitric oxides emitted in the United States. Were Personal Rapid Transit (PRT) systems built in America’s large- to medium-sized cities, America could greatly reduce its use of energy for personal transport and reduce its air pollution.

In a Personal Rapid Transit system, vehicles for two-to-four persons travel on a fixed track. The vehicles always travel one way down a particular length of track, only changing course at bifurcations in the track which resemble freeway off-ramps; two pieces of track might merge into one, like a freeway on-ramp. In most PRT designs, the track is elevated off the ground to make traffic interference a non-issue.

At many small stations along the track, passengers pay their fare and enter the first empty vehicle waiting in line; the station track is a detour off the main track to allow traffic to by-pass the station without stopping, just like freeway on-ramps and off-ramps allow traffic to flow uninterrupted. The vehicles are controlled by their own individual computers, using a small command vocabulary: ‘go’, ‘stop’, ‘take the left/right track’; each vehicle receives its macro-level directions from a central network, e.g. ‘go to this station’, but the set of micro-level actions necessary to carry out that directive are left to the individual vehicle. The central system is responsible for distributing unused vehicles to stations where they will most likely be needed based upon projected traffic patterns. PRT designers consider any kind of stoppage or slow-down in the system as a failure and not to be tolerated as part of normal operation; a properly implemented PRT system would never have traffic jams except in isolated cases. At worse, an influx of demand should only result in waits to board vehicles. (Here’s a nice graphic of the whole thing.)

How the vehicles are propelled varies greatly among different PRT designs. In the PRT design of prominent PRT proponent and designer, J. Edward Anderson, an engineer and former professor at the University of Minnesota, a linear induction motor in the vehicle is powered from the track. Some propose supplementing the track’s power supply by having the track double as a place to put solar panels.

The first reason a PRT system would save significant amounts of energy compared to cars is that the vehicles are significantly lighter. Small vehicles don’t need the acceleration of larger ones, and when powered from the track, they aren’t further weighed down by fuel. Similarly, the smaller volume and lower traveling speed of the vehicle reduces the comparative amount of drag.

Another reason a PRT trip consumes less energy than the same trip in an automobile is that PRT’s typically travel at lower cruising speeds, thus requiring less energy to maintain speed. For safety reasons, most PRT designs propose a speed between twenty-five and forty miles-per-hour; while safety at greater speeds is most certainly possible, greater speed is not as desirable as you might think because the lower travel speeds are made up by the vehicles never stopping on route between origin and destination.

That PRT vehicles only accelerate up to speed once per trip is the most important factor in why PRT’s consume less energy. In a typical car trip, the many accelerations from a dead stop account for a disproportionate amount of the energy consumed even though they only account for a small fraction of the time and distance traveled.

Because the vehicles are powered from the electrical grid rather than gasoline or diesel, there is zero local pollution. This does not solve the problems of air pollution—energy is only as clean as its total amount of emissions at the point where it is both generated and emitted, not just where it is emitted—but prospects for producing clean energy at electrical plants are much more promising than the prospects for our automobiles.

Unlike other solutions for reducing the pollution and energy consumption of personal transport, PRT systems don’t gamble upon uncertain future advances in technology. Electric-powered, hydrogen-fueled, and bio-fueled cars—the prospects for making these technologies economical (or, in some cases, work at all) are unknown. The problem is that science is not magic: some of these technologies may simply turn out to be dead-ends. Of course, the PRT idea hasn’t yet proven itself either, but the engineering required to make the system work consists wholly of combining well-understood technologies. For instance, probably the greatest area of uncertainty surrounding PRT’s is how such systems will handle heavy traffic loads. Though Anderson and other researchers have performed statistical analysis, this is the sort of thing where the details can only be worked out given a real-world system.

The closest analog to this kind of work is the writing of a computer operating system: an important component of an operating system is its “scheduler”, the code which allots processing time to the many programs running at one time on your computer; if the scheduling algorithm is not well-designed, human users will feel their system is unresponsive, and time-sensitive tasks (interactive games, audio, video, and so forth) will lag and stutter because their programs aren’t getting processor time often and long enough to do their jobs on time. The academic literature produced in the 1970’s and 1980’s on scheduling algorithms, while hardly worthless, turned out largely to be wrong (or at least inadequate) when multi-processing operating systems finally arrived to the masses in the 1990’s. So too will research on PRT traffic patterns be flawed until we have real-world systems to observe and tinker with. Still, that such kinks in the system can be worked out is a better bet than a “Manhattan Project” for energy, where engineers would be working on the edge of our understanding of how the universe works. Just as faster-than-light travel may simply not be possible, sufficiently efficient and green car motors may not be possible, so it would be foolish to stake our future entirely on the prospect of sufficient advances in automobile tech.

The failure of the United States to successfully adopt mass-transit in most of its cities is widely attributed to Americans’ dislike for riding mass transit. The usual objections to mass transit largely don’t apply to a PRT system, as it offers these advantages over other transit systems like buses and light-rail:

  1. Because PRT track is much smaller than light-rail track and PRT stations are much smaller than light-rail stations, the construction of PRT track and stations is much faster and less obtrusive and requires less man-power.
  2. PRT stations can economically be placed at short intervals along the track (one at every half-mile in Anderson’s design), meaning a station is much more likely to be within easy walking distance of passengers’ departure points and destinations.
  3. The system can operate around the clock, and passengers never need worry about train or bus schedules.
  4. More often than not, an empty vehicle will await passengers when they arrive at their departure station; even in peak hours, waits for vehicles should rarely be longer than a few minutes.
  5. No driver or other staff need be employed per vehicle, as with buses and trains.
  6. PRT’s occupy less land than light-rail systems, and consequently, they are less visually intrusive and free up space for other purposes.
  7. The vehicles travel non-stop between origin and destination, never picking up other passengers or requiring passengers to make a transfer.
  8. PRT vehicles produce far less noise than cars, let alone buses or trains.
  9. Passengers in a PRT have a private car to themselves, so they can relax, read, talk on their phones, use their laptops, or do their makeup while in transit without consideration of other passengers.
  10. Despite the lower cruising speed, transit by PRT would be significantly faster than by other mass transit systems because of its (usually) low waiting times, the non-stop travel, and the fact that origin and destination stations are likely closer to passengers’ points of travel.

Even with all these comparative advantages to current mass transit, PRT’s still must compete with Americans’ fondness for cars. Fortunately, transit by PRT is in many ways even more appealing than travel by personal car.

  1. Passengers in a PRT don’t have to drive, allowing transit time to be used for entertainment, chatting, or work.
  2. Passengers don’t have to find parking or pay for parking at their destinations.
  3. In a city with a PRT system that covers a wide enough area, more people can live without the cost and hassle of owning, licensing, insuring, and maintaining a car; at the very least, families could get by with fewer cars.
  4. On the whole, PRT’s would be much safer than other forms of transportation, as there are only three plausible safety concerns: malfunctioned vehicles breaking or stopping unexpectedly, vehicles not breaking when entering a station, and collisions at merge points. To mitigate these possibilities, the proposed cruising speed for most PRT’s is below forty miles-per-hour; also, sensors on each car engage the breaks when the car ahead is detected doing something abnormal, removing human delay and error. These factors greatly reduce the frequency and severity of accidents, especially compared to what we tolerate today on our roads.
  5. A PRT would increase the mobility of those unable to drive: the young, the elderly, and the handicapped (in Anderson’s design, the vehicles provide easy embarking and disembarking of wheelchairs).
  6. PRT’s offer quieter rides for their passengers and create significantly less street noise.
  7. Transit by PRT would be faster than car trips for routes with many traffic lights and stop signs along the way.

Aside from direct benefits for passengers, a successful PRT that reduces car traffic would thereby increase quality of life by reducing the amount of noise and air pollution and allow the diversion of resources from road maintenance. After a number of years, cities may even begin reducing the width of existing roads and the size of parking lots, reclaiming space for sidewalks and other purposes. Asphalt surfaces capture heat in hot weather, leading to heavier use of air conditioning; reducing the amount of paved surface in our cities would lead to a surprisingly significant reduction in energy consumption.

Other hidden costs of our roads include traffic cops, traffic courts, traffic accidents, traffic reports, traffic schools, traffic lights, traffic engineers, traffic signage. In particular, there are often over-looked societal and economic costs just associated with parking: parking structures and the extra parking lanes on the sides of streets not only must be built and maintained, they take up prime real-estate. Perhaps least obvious are the psychological tolls, such as the aggravation of finding parking or the danger of cars (even when we’re not in a car ourselves, most of us must be wary of being hit by a car just twenty steps from our doorstep).

Of course, operation of a PRT will introduce many such hidden costs of its own, not all now foreseen, but on the whole, they seem relatively modest. For instance, emergency crews and equipment will be needed to occasionally clear malfunctioned cars and rescue stranded passengers. The track and vehicles themselves, of course, will need upkeep. And so forth.

In the last thirty years, several attempts at constructing PRT systems failed, mostly due to lack of funding and political support and inadequacies of the day’s computer and electric-engine technology. As of yet, there is no PRT success story, and until there is, municipalities and governments won’t take the idea seriously. At the moment, two PRT’s are scheduled to start operation in 2008: the “ULTRa” system at Heathrow Airport in London and another system at the International Finance Center in Dubai. By proving itself in a localized capacity, hopefully the PRT idea will begin to see adoption as a city-wide transit system.

Gutsy Gibbon: the first real desktop Linux

15 Nov

Ubuntu 7.10 (codename “Gutsy Gibbon”), released last month, is for me the first really usable Linux, which is saying a lot considering I’ve made a serious attempt to switch to Linux about once a year for the last six years. The last 3 of those attempts have been with Ubuntu, and while I could always get my system dual-booting into Ubuntu, there was always some essential functionality I couldn’t get working such that, when the GRUB menu came up, I would always choose to boot into Windows. With Gutsy, I can finally say that the only compelling reason I have for booting into Windows is to play games.

What follows is a rundown of various issues hindering Linux desktop adoption, most of which I can happily report are solved–or on their way to being solved–in Ubuntu.

For reference, my desktop specs are:

  • MB: Asus P5NSLI (nvidia nforce Intel Sli)
  • CPU: Core 2 E6400 (LGA775)
  • RAM: 2 gigs
  • HD: Western Digital 7200 rpm 250gb SATA
  • Sound: Creative Labs X-Fi Gamer and ADI AD1986A onboard audio
  • Video: geforce 8800 GTX 768mb
  • Monitors: Gateway FPD2485W (24″ 1920×1200) and Samsung 215TW (22″ 1680×1050)

My laptop is a Gateway M-6816, which has Intel PRO/Wireless 3945 and Intel Graphics Media Accelerator X3100 (up to 384MB shared).

Installation media

I start with the issue of installation disc integrity because, in my experience, it is not a rare problem. My first torrent of the Gutsy amd64 DVD was faulty, apparently, and this caused the live CD boot to hang early in its process. I’ve experienced similar problems with previous releases. I suggest always running the media check (an option in the boot CD splash menu) before installation.

386 vs amd64

The 386 DVD version installed without a hitch, but sadly, I’ve yet to get the amd64 version to work. The trouble seems to be graphics related, as the boot CD stops before it gets to the graphical login screen. I successfully installed in text mode, but booting from that install exhibits the same problem.


A non-destructive partitioner is essential for Linux’s success on the desktop because most users coming from Windows wish to dual-boot and don’t want to reinstall Windows or lose any Windows partitions. Also really important is a smart installer that helps users pick the right set of partitions to create for Linux. With previous releases, I’ve had to turn to external solutions, like GParted and the Ultimate Boot CD, to mixed results. With Feisty, Ubuntu started to integrate GParted into the install process, but the result was still sketchy. When installing Gutsy, I already had free space on hand for a new primary partition and so basically by-passed the issue, but I’d be very interested to hear how others fared with setting up partitions for Gutsy where they had to resize NTFS. One thing I’d like is a manual/auto mode so I can have the installer recommend a partition layout but still see what exactly it’s doing and modify its plan.

Reading and writing NTFS

Just as important as easy non-destructive partitioning, users coming from Windows want to read and write their NTFS partitions. (Reading and writing Linux partitions from Windows is less pressing, but can be done with explore2fs.) With Feisty, users had to know they needed to install a package to get NTFS support, and I myself couldn’t get writing to NTFS to work, only reading. With Gutsy, my 3 NTFS partitions are readable and writable out of the box in Nautilus just by double clicking them and entering my password (this just mounts the partition: you must click again to view the root of the partition, a behavior which should be changed or made clearer with user feedback).

Boot loader

On the laptop I bought a few months ago, the first thing I did was make room for Linux by clean re-installing Vista from the included install disc into a smaller partition. Gutsy installed with no hassle, and GRUB allowed me to boot into Vista. On my desktop with XP and Vista already installed, installing Gutsy replaced the XP loader with GRUB, but strangely this left XP bootable from GRUB but not Vista. My guess is that GRUB tried starting Vista as if it were XP because that’s how it listed the partition in the menu; this may have arose from the unusual case of a Vista partition existing on a drive with the XP loader installed (it got that way because I installed XP after Vista). Only after reinstalling Vista and then a second install of Gutsy (amd64) could I boot into any OS from GRUB (even though, as mentioned, Gutsy amd64 won’t boot). Hopefully my unusual case will be accounted for in future releases.

GRUB could stand a few basic improvements. First, the default names given to the Ubuntu boot options should be simplified, as they are currently quite scary. Second, there should be an obvious GUI way to edit the boot menu, especially for changing the default partition.

Boot time

From hitting the power button, it takes Windows XP 60 seconds before the desktop appears. From that point, it takes another 90 seconds before Firefox will open and I can interact with it.

On the same machine, booting Gutsy cold also takes 60 second before I see the desktop. However, at that point, it only takes 5-7 seconds to fully load Firefox.

(I’m sure a few programs I have installed on XP hinder it compared to a clean XP install’s baseline performance, but I don’t have anything that major loading with XP; the only significant startup daemons I have are nvidia’s ntune panel, dtools daemon, and Valve’s Steam.)

Ethernet and Internet connectivity

In previous Ubuntu’s, I had issues getting wired and wireless internet connectivity, and I don’t think I have to tell you how useless a system without an internet connection is. Thankfully with Gutsy, I haven’t had one problem whether wired or wireless. I’ve yet to try networking to other Ubuntu installs or to Windows, so I can’t speak to those issues.

Pointer feel

If your mouse doesn’t feel right, your whole user experience is severely degraded. For instance, I probably wouldn’t dislike Macs so much if it weren’t for the fact that every time I’ve ever used one, the mouse motion was way off (and lets not even mention Apple’s “innovations” in mouse body shape and clicking mechanisms). Even when configuring my MacMini (the first and last Mac I’ll ever own) with mice of my own choosing, I’ve never gotten close at all to the quick, accurate control I’m used to in Windows, where I have a high DPI mouse (the Logitech G3) set to high sensitivity and low acceleration with “enhanced mouse precision” enabled. (Jeff Atwood ellaborates on mouse acceleration in Windows vs. Mac.)

The mousing in previous Ubuntu releases was similarly unsatisfying (though Kubuntu was considerably better). Compounding the problem in Ubuntu, the sliders for acceleration and sensitivity in the Gnome mouse control panel never seemed to do anything, as if they were just included for placebo effect. Well, in Gutsy, I still can’t tell if the sliders are doing anything, but happily the mousing feel out of the box is nearly up to par with Windows. My laptop’s touchpad is similarly satisfactory. While still not perfect, the mousing in Ubuntu is sufficiently good I rarely notice it (unlike in OS X). Still, the fact that the motion adjustments don’t seem to work worries me: I could have just gotten lucky this time with my choice of hardware while other people might not be so lucky.

[To be fair, after a few minutes spent playing with a new model iMac, I must confess the mousing was quite good, even with the gimicky mouse (the fact that I was using a fast, responsive system rather than the under-powered MacMini probably made the difference here). Also, Apple's new ultra-thin keyboards work surprisingly well considering they appear horridly anti-functional.]

Graphics driver, 3D acceleration, and multi-monitor

Unlike in previous Ubuntu’s, installing working 3D drivers in Gutsy for my latest and greatest nvidia card was effortless. On the downside, the “new” nvidia driver is proprietary, but I’m OK with this, as I don’t think the strategy of boycotting proprietary hardware will pressure the graphics chip makers to release open specs or drivers. Features like Compiz need to get in front of users for proper attention to be paid to 3D among the develeper community, let alone the chip makers, and as long as no one is actually using 3D hardware on Linux, nvidia, ati, and intel will feel little pressure to advance the platform. Hopefully, ati will fulfill their promises of open source drivers and specs for R500 and later hardware, and hopefully success there will prompt nvidia to do the same. (Like with Samba and proprietary multimedia codecs, the basic strategy here needs to be the FOSS version of “embrace and extend”: supporting proprietary technologies gets Linux out of the gutter while interoperability increases use of free technologies. FOSS needs market power first before it can make demands. But that’s a whole post unto itself.)

Getting my second display configured was frustrating at first, but running ‘nvidia-settings’ got everything in order (run it as root so that it can overwrite xorg.conf). The Linux multi-monitor situation is a bit confused at the moment because of limitations in the underlying X window system that have yet to be corrected or worked around. This results in some unsatisfactory behavior: currently, my desktop is a 3600×1200 virtual desktop such that it extends off the top and bottom of my 1680×1050 display; while maximization on that display thankfully works correctly, some oddities occur, such as desktop icons hiding off screen.


My Audigy X-Fi is not supported in Linux except by proprietary beta drivers from Creative Labs for 64-bit Linux only. As I have yet to get 64-bit Gutsy working, I can’t report on that support. Rather than swap back in my Audigy 2 ZS, I turned on the onboard audio in my bios. This got sound working, though I did have to fiddle a bit in the sound panel. Also, I can’t get anything beyond 2-channel sound to work, likely because the onboard audio’s jack sensing is not supported by the drivers, so the 3 jacks from my motherboard are stuck as line-in, line-out, and microphone (hmm, except then you would think I could get sound to record, though I can’t).

These driver issues are understandable considering I’m using a relatively new proprietary sound card and a not-so-common generic onboard solution. Really though, the biggest failing of Linux sound-wise at this point is not any lack of hardware or lack of auto-configuration but simply that the sound situation is so damn confusing. In trying (and failing) to get 6-channel sound working and in (successfully) fixing the lack of sound in Flash on my father’s system, I was confronted with a mess of OSS, ALSA, ESD, OpenAL, PulseAudio, and a whole array of opaque options I didn’t understand. Hopefully these projects will coalesce or at least learn to better exist side-by-side so they can be configured to work simultaneously on the same system. The situation feels like GNOME vs. KDE of several years ago when getting KDE apps to work in GNOME and vice versa was tricky.

Font rendering

In previous releases, smoothed font-rendering was tricky to get working, but now it is turned on in GNOME by default. You can even select between “best shape rendering” (OS X -like rendering) and “subpixel rendering” (Windows-like rendering). (Here’s the difference between the two.)

On the downside, the selection of fonts out of the box is a bit lacking: too many almost identical sans fonts, not enough quality serifs, not enough monospaced fonts. On the upside, most of the included fonts are quite good, especially the great Monospace, which is very similar to Microsoft’s new Consolas font but with a few changes that make code even more readable.

Multimedia codecs

On all Windows installs, I install mplayer, vlc, and the K-lite mega pack because doing all that seems to cover all bases, codecs-wise. In previous Ubuntu releases, I’ve been lucky to get MP3 support working, but in Gutsy, I finally don’t have to worry about codecs. I simply open any media file in mplayer or vlc, and GStreamer detects which codec I need and downloads it, and then the file plays (though sometimes only after restarting the player). Dubious legality aside (OK, not so dubious illegality—I’m in the US, and it definitely ain’t legal), the only way for codecs to work better is to simply have the whole lot installed by default.

Portable music players

My Creative Labs Zen Microphoto (8gb) used to work fine on Windows XP before Creative discontinued its original drivers (which they pig-headedly don’t offer for download) and upgraded its firmware to use Media Transfer Protocol. Now, Zen users on XP must use Media Player 10 to interface with their device, but it’s never worked for me. Since then, I have had to use my laptop to charge and interface with the device.

In Linux, applications can use libmtp to interface with MTP devices. Ubuntu installs by default Rythmbox, a stripped-down but slick iTunes-like player, which supports libmtp via a plug-in. I just wish it were clearer that you must enable the MTP plug-in (in the plug-in preferences) before your device will be recognized, as it was days before I noticed the option.

So here’s a case where something works for me in Linux but not Windows (XP).

(I should also remark how much I like Rythmbox, which is surprising considering I dislike iTunes. The key thing that makes Rythmbox acceptable to me is that it keeps your music files in place rather than presumptuously duplicating and re-encoding your entire media collection the way iTunes is wont to do.)

Package management and application installation

In the previous Ubuntu, I had trouble with Apt (the package manager) getting buggered right out of the box such that its database got locked, causing Apt and Synaptic (the GUI front-end) not to work at all because they couldn’t access the database. This happened consistently immediately after a clean install, rendering Ubuntu basically unusable.

It’s annoying that many packages in the repository are for old versions, even for major programs, like Eclipse and Azureus. Azureus, for instance, wouldn’t work for the version I got from Apt; only the latest version, gotten manually from the Azureus site worked. So there are many cases where you must go fetch a lot of apps by means other than Apt.


Now that Java is free, I assumed it would be included by default, but that didn’t seem to be the case (or at least, I had to manually install Sun’s Java 6 to get Eclipse and Azureus working). It’ll be nice when this situation gets resolved so users can simply have Java apps working out of the box.

Web browsing

Firefox in Ubuntu is much slower at rendering than in Windows. In Windows, my habit is to ctrl-mousewheel to change font size, and Firefox resizes in real-time as I scroll the wheel with all but the most complex pages. In Ubuntu, even simple pages can take a moment to resize the text, so I had to train myself not to reflexively resize pages. You can also see Firefox’s slow rendering in pages like Google Maps, where dragging the map is far from smooth. It’s likely this slow rendering is tied to inefficiencies in GNOME, X, or maybe the new font rendering, as I can’t imagine that Firefox’s rendering path changes much between Linux and Windows. It’s possible the new font rendering is causing this slow down, ormaybe something similar is the culprit, but I see the problem on all machines I’ve installed Gutsy. Hopefully Firefox 3′s new rendering engine (with a Cairo backend) will bring this back up to par.

(Sadly, my favorite Compiz plugin, Enhanced Zoom, causes animated cursors to disappear after the first time you zoom in, and this is most aggravating in Firefox, where the cursor animates as pages load; the only fix is to restart X (by ctrl-alt-backspace), but this closes all your programs, so the only real solution for now is to just disable Enhanced Zoom.)

User switching

A panel widget included by default is “fast user switching”. I’ve experienced debilitating bugs with this widget, so I suggest you not use it.

Gnome desktop

Finally, I have some assorted thoughts on GNOME:

Thankfully, the application menu has been cleaned up since Ubuntu’s last release: rather than listing apps by their project names—names which are meaningless to most people—most apps now are just given simple descriptive names that reflect their functionality. The menu editor, however, could stand some more work, as it’s a bit hard to discover and awkward to use.

In previous GNOME’s, the icons ranged from acceptable to ugly turd. Now, the default set of icons in the menus and file browser not only do not look like crap, they are actually very attractive and exemplary models of clean design, better even than many icons seen in OS X. And speaking of bling, I do wish there were more color themes and bundled wallpapers with the stock system in the vain of Windows. It would be neat if they included some of the great photos from Wikipedia’s photo of the day, which includes some very neat panorama shots.

The default panel config of Gnome is a silly attempt to split the difference between the Windows / Mac desktop, and too many unnecessary panel widgets are included by default. At the very least, a quick panel config wizard should allow me to choose the standard Windows taskbar layout.

Unfortunately, my biggest irritations with GNOME can’t be fixed with a lick of paint. First, windows with scroll panes inside open too small to see the content of the scroll pane, forcing me to resize or maximize these windows to properly see this scrolled content. This problem is exasperated by my other grievance: grabbing window corners is too tricky, and I often accidentally click with the horizontal or vertical resize cursor when I wanted the 2-axis resize cursor.

Portals: window management for those who hate window management (mockups in Javascript)

17 Jul


Jeff Atwood discusses the way Mac OS X windows don’t really have ‘maximize’ buttons, and he comes to the right conclusion: better to have overly large windows than to make users futz with the dimensions of their windows. He says:

Apple’s method of forcing users to deal with more windows by preventing maximization is not good user interface design. It is fundamentally and deeply flawed. Users don’t want to deal with the mental overhead of juggling multiple windows, and I can’t blame them: neither do I. Designers should be coming up with alternative user interfaces that minimize windowing, instead of forcing enforcing arbitrary window size limits on the user for their own good.

As it happens, minimizing the hassle of windows—both main application menus and pop-up dialogues—is the major design goal of my desktop UI design, which I’m calling ‘Portals’. Back in this post in March, I promised to present the Portals design, but I never quite finished the mockup demos in Javascript. Still, there’s enough there to convey the biggest ideas. Eventually I’ll fill in the notes and the rest of these demos and perhaps also finish the screencast about Portals which I started.

The mockups come with lots of (rambling) notes, but one thing they oddly fail to make clear is that Portals has no desktop, i.e. no flat empty surface on which to dump icons and files.

Better tabbing in Firefox (mockup in Javascript)

16 Jul

In response to a challenge by Aza Raskin to come up with a better way of tabbing in Firefox—in particular a solution that scales better the more tabs you have—I produced this mockup in Javascript. Be clear that, because of the way the tab previews are done, the performance is creaky and not representative of what a proper implementation would be like. Please, use your imagination and pretend the previews pop-up instantly. Also understand, it ONLY WORKS IN FIREFOX. (While it won’t work at all in IE, it should mostly work in other non-Firefox browsers, though I haven’t tested any).

The rationalization is given on the page, so I’ll simply discuss here why I rejected some ideas proposed by others and also consider some variants on my design which might be even better.

In the comments of Aza’s post, a number of people expressed a desire to introduce alternative ways of conceptually ordering the tabs other than the default order in which you opened them, e.g. some wished to be able to group their tabs (which you can kind of do already by reordering), some wished to see their tabs listed by chronology of the pages (as opposed to of the tabs), and some wished to see their tabs in a web displaying heritage (which page was opened from which other page). While there might be something to these ideas, I avoided them as there seemed to be easier gains to be made that didn’t involve conceptual changes for the user. I wanted to improve the tactile experience of dealing with many tabs.

Others have proposed some kind of zooming UI. Again, there may be something to this idea, but until hardware support can be implemented consistently across platforms, I don’t see this happening. Besides, it’s a tricky thing to get right, as many users are easily disoriented.

Others mention multiple tab rows. This idea is problematic for the same reasons displaying any one-dimensional information in rows is problematic: things move around in unexpected ways when the bounds gets resized and tabs are added and removed, messing with the users spatial memory of where their tabs are. (Of course, text has the same problem, but text has paragraph breaks that help a large section of text mostly retain some recognizable shape as it is edited and its bounds resized.)

As for variants on my design:

A major flaw of the current Firefox tabbing which my design doesn’t really conquer is that I find myself often confronted with having to do multiple searches to find a tab: by reflex, I first search through those tabs I can see, then I’ll mousewheel back and forth, then occasionally I’ll go into the full list on the right if I still haven’t found the tab. The problem here is that the worst-case scenario searches are very expensive and distracting, but they wouldn’t be if I simply went to the full list to begin with. As nearly good would be if I couldn’t scroll the tab bar at all, forcing me to go into the full list of tabs sooner; in this scenario, we’re actually better off keeping the number of tabs visible in the main bar rather low, say 7-9 at most.

If we embrace the idea that the full tab list should be used more often, it then makes sense to better purpose the main bar. Rather than show tabs which occur consecutively in the full tab list, the main tab bar could display the last viewed tabs in the order they were viewed. In this design, you actually wouldn’t ever see the current tab in the main tab bar as you don’t need to click on it, but you’d still find it in its proper place in the full tab list.

If this is too confusing, perhaps get rid of the main tab bar altogether and have the full tab list button sit by itself to the right of the search box.

I’ve also considered simply having a single vertical sidebar for tabs. This would be like having the full tab list always open. While you might object to the loss of screen space, I’m not sure it would be so bad, especially for wide screen users, who often have to artificially make their Firefox windows narrower for reading, anyway. The Vertigo extension already offers Firefox users vertical tabs, but it could be improved:

  • The tabs bar should not be as wide as the history and bookmarks sidebars are by default, not really for functional reasons (at least on big widescreen monitors) but rather aesthetic ones.
  • Each tab should be two lines high for easier clicking and so that titles can wrap onto two lines if needed.
  • Hovering over a tab should display a preview (as in the demo) and any part of the title cut off should appear extending out of the tab bar into the page. (In fact, I’m thinking that hovering over the vertical tab bar should make all cut off titles appear in this manner; even with the titles extending out of the sidebar, you would still be able to see where the sidebar ends, so when you mouse out of the sidebar, the titles would all go back to normal.)