Efficiency

There used to be a time when the choice of car influenced significantly the probability that the trip from A to B could be completed. Nowadays all manufacturers have implemented a common set of reliable functionalities. Any car can complete the trip. The critical issue is no longer to get from A to B but to do so in the most efficient way, maximizing output and minimizing the scarce input factors. Environmental and economical consideration make some factors more relevant than others. Driving time (miles per hour, MPH) is no longer relevant. Fuel (miles per gallon, MPG) is one of the most critical input factors today and has a significant impact on the choice of the car.

There used to be a time when the choice of computer influenced significantly the user’s ability to complete the intended task. Nowadays all boxes are the same and there are enough mature software packages that offer equivalent functionality across operating systems. Almost any system does the task. If all systems have sufficient functionality and development focuses on efficiency, what are the scarce input factors? how do we measure them? how do we weight them? which one have an impact on the choice of software?

Unlike cars there is no speed limit. Raw speed still counts and time is of essence. In recent years energy efficiency (e.g. FLOPS/Watt) has become a factor of consideration, but time still is the most relevant measurement. And in my opinion the most important. Not CPU-time, user-time.

The best software is the one that reduces human interaction time (including time waiting to interact) to the minimum.

Human interaction time can be categorized in:

• Time to prepare the operation: the shorter the better. While for frequent users with a good memory can enter a command line with a few parameters (out of a few dozens) very quickly, an intuitive GUI shortens this time for the occasional user that would have to call the command’s man page or other help text, read it, scribble down on paper while composing his command until it can be triggered.
• Typing on the keyboard: the smaller number of keystrokes for an input, the better.
• Reading from the screen: the less there is to read, the better (but the relevant information must still be there).
• Interaction with the pointer. Positioning the pointer on a target, dragging, clicking, are all operations that require dexterity and accuracy. Like typing on the keyboard, there is a trade-off between speed and accuracy; and between simplicity of the movements and speed.
• Waiting for the computer to request additional input, but only if the interaction is supposed to be in or near real-time. Batch processing time does not count – the user can do other things while the computer processes the batch.

Good software design aims to minimize those interactions. If an operation can be completed with the nine key strokes, completing it in ten is a 10% efficiency-loss. This is what happens when renaming layers in Photoshop compared to the same operation in GIMP; or when renaming a file in  Windows Explorer compared to Nautilus. The inefficiency cost? find it out for yourself. Take the typing test and find out your accuracy and speed. Multiply your words per minute by 7 to estimate the number of such operations that you need to perform to loose one minute. Estimate it across the days, weeks, months, years you sent at your computer. Extrapolate on the millions of users of the software, and you’ll know what is the waste resulting from such a simple bad design.

Extra-bonus: how fast can you target a single random pixel in the middle of your display? And the single pixel at the corner of your display? And a single pixel on the border of your display? Now you should know why positioning the application menu on top of the display (as done on the Mac) is superior to positioning it on top of the window (as typically done on Windows or on Linux). And wich single pixel on your display is the fastest one to target? Hint: context menu.

Ah, and time is still the most relevant factor also when getting from A to B too: I’d rather read a book comfortably seated in a train, airplane, but or taxi and let somebody else do the driving. As in: program the journey and sit back, while somebody else does it for you. Batch processing, wherever possible, is my favorite type of processing.

Disk Space

I can’t believe the Ubuntu Desktop Team Meeting Minutes. They are dangerously close to drop the GIMP from their CD. Read the detailed transcript further below in that document, between [17:33] and [17:45] how the team leader tables the motion to drop the GIMP. Either they didn’t discuss all their sources of information or they are using the wrong criteria. Disk space?

Amongst Wakoopa users GIMP is the most popular image editor and #24 most used software on Linux. Dropping it would make the CD nearly useless. And when looking on Wakoopa at the top software list, the top applications are, unsurprisingly:

1. web browsing (25% of the apps listed in the top twenty are web browsers!)
2. file browsing
3. instant messaging
4. word processing
5. social networking
6. gaming
7. email
8. image editing (it’s Adobe Photoshop, #16, but nevertheless: users want image editing)

Granted, Wakoopa may not be the most reliable source. It’s a subset of the consumers world. Canonical can and should afford professional analysis of the kind offered by NPD. Or it could do some aggregate usage statistics on its own user base. Why a random roll of dices?

If the Ubuntu Desktop Team is really concerned about user experience and disk space, maybe they should consider how the system overall affect disk usage (not only the CD).

At some point in the recent past I ran out of space on my Ubuntu install. My workstation’s disk is partitioned for multiple operating systems and within Ubuntu there are a few user accounts. Investigating the issue I found that the .thumbnail folder was bloated beyond 2GB. Multiply this over the half dozen users and you get the picture.

$ cd
$ rm -fr .thumbnails

Temporarily solved the problem. Unfortunately I did not find any system-wide option to prevent this from happening again. I had to resort to heavy-handed methods:

$ ln -s /dev/null .thumbnails

or

$ chmod 000 .thumbnails
$ sudo chown root:root .thumbnails

Repeat for each user. I am missing a way to kindly ask the system not to waste my resources. Indeed in both cases the first reaction of the applications was that this must be an error. Can’t they imagine that this is intentional choice?

F-Spot is useless (it quits after the error message). At least the GIMP continues and work well. It has even a preference setting:

And in the Ubuntu Desktop Team F-Spot is considered as a replacement for the GIMP? Oh, please! What will we see next? Winbuntu? Ubuvista?

What I would like to see next is the GIMP taking seriously the criticism about its user interface. Make it more efficient (i.e. it should take less clicks, less keystrokes, less moving time, less thinking time to accomplish a task);  make it modular so that it is possible to present a “light” basic interface to the casual user and a fully fledged interface for the heavy user. Not a new idea, but it does not have to be new to work?

Criticism

An article about criticism worth reading. Although it is already a few months old, I came across it only today. I think it applies to many Free Software projects and is one of the key reasons why those projects fail to reach a two digits market share.

One Month With Ubuntu

I’ve been traveling the last four weeks, away from my workstation. My notebook is slowly dying from a dry joint under the ICH7 that seems to affect many similarly designed models. It is no longer usable in Windows where a CPR-like ritual around the touchpad is required to unfreeze the machine every few key strokes. Ubuntu deals better with the issue, disabling the faulty component and going on with life:

[  191.052015] uhci_hcd 0000:00:1d.0: host controller process error, something bad happened!
[  191.052076] uhci_hcd 0000:00:1d.0: host controller halted, very bad!
[  191.054019] uhci_hcd 0000:00:1d.0: HC died; cleaning up

So how was life with Ubuntu? Mostly good! I rebooted into Windows only once in an attempt to diagnose a wireless connection (the problem turned out to be incompatiblity between my North American gear and my friend’s European gear. Changing the access point’s channel solved it and I could continue to use Ubuntu as usual).

Keeping in touch with the office was easy. OpenOffice, Firefox, Thunderbird, Skype are mostly the same across platforms. There is no reason for a small business to spend on office sofware licenses nowadays.

My experience with scripting / web dev tools was mixed. There is an alternative to every tool I use in Windows, but it is not the same, requiring the user to adapt. Some of the adaptation is painelss and actually pleasant: Gedit (Ubuntu) and Kate (Kubuntu) are much better than the default text editor that comes with Windows. But I still miss PuTTY’s convenient copy&paste interface (I know about the third mouse button, but that button does not exist on the notebook). I am also missing the sleek integration of Subversion (TortoiseSVN) and Secured Copy Protocol (WinSCP) in the system’s file browsers. I ended up using more of the command line (CLI), particularly rsync over ssh.

Over four weeks I produced about 47 GB of media – mostly video. I did not compromise on quality (1920×1080 AVCHD 24Mb/S). Because of the broken USB I could not get the videos onto the notebook. The 32GB flash memory of the camcorder lasted until the last week, and then I used an additional SD card. It would not have made a difference anyway – the notebook is too weak to edit FullHD video.

I did copy the pictures from the digital camera to the notebook, using a Compact Flash to PCCard interface.

I processed the RAW files with RAWstudio. I built the latest stable release (1.2) from source (Ubuntu currently distributes version 1.1) and I was pleasantly surprise by the speed of the interaction, the clean interface and the pleasant results. I also noticed some other positive details such as sensible default storage locations. I did not convert / process fisheye images because correction of chromatic aberration is not activate yet; and I bumped into a minor glitch: Hugin reported a few of the pictures from the same batch as being rotated 90°, although at the time of shooting they had the exact same orientation. I will investigate and eventually provide the RAWstudio developers with a complete analysis  / bug report.

Hugin performed heavy duty, including the stitching of 294 pictures. Disk space was the only limit. I have ordered a new hard disk and will re-process the images on the workstation once it arrived.

I will also have to do most of the image editing on the workstation. I tried hard to use the GIMP for masking, but I ended up being frustrated at how slow I am with it, so I did other things in the meantime, leaving the image processing task for home.

I’ve tried to get tha antipasto-arduino IDE to build on Ubuntu because I wanted to implement a few new ideas on the Arduino + TouchShield. The guys at Liquidware were very supportive and together we came close, but it still does not build. I will have to use the Windows workstation for this one as well. The experience helped me discover the joys of git, and I also enjoyed this talk by Linus Torvalds.

Last but not least, I’ve participated on and off to the discussion on Hugin’s mailing list and I codified a collaborative policy for the bug tracker. I hope it will draw more community members into the task of sorting out bugs and help the developers keep the overview.

That was it for my first month ever with Ubuntu only. Did it work? Yes. Did it make a difference? a little. Operating systems are interchangeable nowadays, there are equivalent applications on any of them and the choice boils down to user preference (i.e. Usability with a capital U) and the limited availability of a few killer apps (which again are defined by the users and what they want to accomplish). And what count most for a user on the road is battery life, and after years of average 2-3 hours (with the occasional outlayer) there finally is some good news for the mainstream on that front. Other than battery life, my killer app at the moment is still Photoshop.

Home Sweet Home – Almost

The main leg of our trip back home was meant to be a simple non-stop transatlantic flight, from Basel-Mulhouse to Montréal. Roughly eight hours. 24 hours and two hotel rooms later we’re still on the road because of a massive delay at the airline – the second one I experience with this same airline (on a different route).

To be fair, the people around us have been forthcoming and have tried to help within the limits of the competences given to them. They have also given priority to travelers with babies and children when it made sense.

There were seven babies on this airplane, and given what I have seen from the other six I feel blessed with ours who went patiently through the horrible day and even slept through the flight.

Even traveling “Club” (the airline’s attempt equivalent to business class) did not shield us from the discomfort of waiting without knowing. I’ve been on delayed flights many time, but what really struck me throughout this experience is how much of the uncomfortable waiting could be avoided if the impromptu problem solving would be replaced with proper contingency planning.

Most telling was the moment I witnessed just after landing from my first row one seat. When the flight director opened the plane’s door, he briefed the ground personnel. They were visibly surprised and overwhelmed by the task at hand. The plane was due for 16h55. Instead it landed at 1h38. It does not take Einstein to understand that connecting passengers will need a place to stay overnight. It took over two hours to organize hotel rooms for about 30 stuck passengers. Couldn’t the relevant information be gathered and relayed on departure? Couldn’t the eight hours in the air be used to prepare things?

I used a hotspot at Basel airport to inform our family not to pick us up and not to worry. Can’t wake them up at 2AM. Had I known that it would take the airline ground stuff two additional hours to figure out things, I would have done this myself at the same hotspot and presented the airline with the bill. I wonder if the airline is aware that the extra time is not only inconvenient for passenger, but also expensive overtime to be paid? Or maybe it is intentional, to dissuade passengers from using the “service” and send them away, on their own?

The Ergonomics Of Panoramic Interactions Continued

Bruno’s comment about touch-screens got me thinking. While most users still interface with the computer via mouse, keyboard and a one-way display, things are going to change fast in the coming years. The old KVM (Keyboard/Video/Mouse) user interface is being replaced by more powerful and natural tools. The point&click / drag&drop metaphors popularized by Apple’s Macintosh since 1984 after the invention of the ball mouse at the Xerox Parc are due for an update. Ever smaller and powerful mobile devices, accelerometers, touch screens, 3D screens. How will they interface between the user and the VR Panorama?

The solutions I have observed so far simply hard wire the behavior of these new devices to the mouse. This is no different than my 1998 Wacom Tablet (which still works!). The simulation of the mouse limits the interaction designer to define the device in relationship to mouse behavior and either mimic it or its inverse.  After half a century it is time to break those limits; to look at the interactions anew and to design device/context specific metaphores; to mold the intearction around the human. I see a combination of relevant factors, including the device’s physical characteristics and the context in which it is used. A touch-screen on a desktop requires a different metaphore than one on a smartphone. And what to do when two competing input devices with conflicting metaphores are attached, such as an accelerometer (3D mouse) and a touch-screen?

For the desktop touch-screen and for the laptop touch-screen I tend to agree with Bruno that the Google StreetView metaphore is the way to go, at least until the computer can discern if the index finger is at a nearly perpendicular angle and fully straightened as in a pointing; or it has a smaller angle and a slightly more curved posture as in a natural dragging movement.

Things become more touchy (pun intended) with mobile devices which typically have an accelerometer and a touch-screen. Which one should drive the VR panorama interaction and how? To me the most natural would be to use the accelerometer and point the iPhone in the direction I want to see, but in some situation such explicit movements are embarassing, unconvenient, inappropriate, or all of the above; and the more discreet dragging by finger on the touch-screen is the right way to go.

Whichever it is, I think modern panoramic viewer should make provisions to accommodate both behaviors – dragging and pointing. Ideally the system would tell the VR player in what context it is playing and the VR player would adapt, using an appropriate metaphores. Currently the browser only let the VR player assume the presence of a pointing device, and the devices all interface by mimicking the mouse. In the current situation making the mouse behavior a parameter, as implemented in the KRpano viewer, is the best thing to do. When a reliable detection mechanism can tell the player what device is attached, the choice may be automated.

I look forward to see the results of León’s Google Summer of Code project adding QTVR playback and Wiimote interaction capabilities to the VLC media player. In the meantime I got help from the Liquidware guys in my still unsuccessful attempts to make their Antipasto Arduino IDE work on my Ubuntu notebook. The TouchShield Slide touch-screen rocks and I am keen to toy on new interfaces with it.

Revisting Old Places

I’m currently at my parents in southern Switzerland. Usually this is a wonderful place with plenty of sunshine (there is an institute for solar research just around the corner). For the past three days it was under torrential rain (more than 150 liters per square meter in 12 hours). The rain has not stopped Fulvio Senore and Alessandro Ugazio from giving us a warm welcome on a train stop in Domodossola, Italy (restaurant panorama is in the making; the RAW files have been converted with RAWstudio; Hugin has stitched them; I’m struggling with the masks and layers in GIMP). My parents are enjoying their grandchild.

I had plans to meet old school friends and to take some pictures in old and familiar places. No pictures under the rain. Instead, I revisited a different kind of old and familiar places. It has been about a year since the last time I’ve looked back at the effort I initiated to document the Hugin build process. My hope for that page (and for the build and release process) was that it would take care of itself over time. While there is now a thriving community of builders and testers, some part of that effort had not materialized as I hoped. During the last LGM I discussed some of the learnings with Pablo and we’ll start implementing them after the 0.8.0 release. In the meantime, I started updating the page.

That page, with the pages linked from it, represent an important step to me: the stepping stone from user to contributor. When I joined Hugin, I was just a user. Actually, I was a pain in the neck user, asking for stuff all the time. I wish I could have contributed stuff, but I lacked the necessary knowledge and the learning curve looked daunting steep. So I contributed my chutzpah and organized our first participation to the Google Summer of Code in 2007. One feedback we got from the first crop of GSoC students was that the learning curve is daunting steep. So I’ve pushed and pulled around the community to ask those with the knowledge to document it into that bare structure I’ve started. With the help of many community members, and support from the core developers, we put together a documentation self-explaining enough to get more users over that stepping stone. It did not take long until it was picked up and we now have a thriving community of builders and testers. Moreover the instructions helped new developers (such as the 2008 and 2009 Google Summer of Code students) to get faster over the learning curve and become productive faster.

The build process is now self-sufficient. When dependencies change or features are added, the feedback loop between developers and builders is fast and efficient. The documentation still needs updating now and then. I look forward for the 0.8.0 release so that we can move on to improve the release cycle (and the closely related debugging cycle) along similar lines. But first, I look forward for the weather to clear, and to spend some quality time in the place of my youth.

The Ergonomics Of Panoramic Interactions

Google StreetView has contributed immensly to the popularity of virtual reality (VR). Kudos to them. They keep adding smart and complex navigation improvements. When will they realize that the single most effective and easy to implement improvement to StreetView’s navigation would be to invert the movement of the mouse? To the vast majority of humans it is more intuitive to move the mouse to the point of interest. With StreetView today it is the other way around: to look up you have to drag the mouse down and to look right you have to drag it to the left. In the past decade Apple understood the ergonomics very well and established the best practice with QuickTimeVR, the ancestor technology underlying VR interaction. The vast majority of panorama viewers use this intuitive way of navigating the panorama. Why not StreetView?

MathMap for Windows

So you want to do perspective manipulations as shown on this video but you’re stuck with Windows? Now you can say thank you to Mark Probst.

Grab the latest GIMP for Windows installer. Install it (all into default locations).

I have prepared an installer of MathMap (v 1.3.4-alpha2). Grab it and install it. That’s it: start the GIMP and MathMap should be in the menu Filter -> Generic -> Mathmap. Have fun!

Note that Windows support is experimental and some functionalities may not work as they do in Linux. Also I am currently traveling and my notebook only has Ubuntu available. I produced this installer remotely and could not test it. For details, check the MathMap GoogleGroup.

First Arduino Attempt

Inspired by Joergen Geerds, I decided that during the coming travel I will play with an Arduino to control my camera. Before departure I needed to:

• get the necessary hardware
• assemble and test it
• get the integrated development environment (IDE) up and running

The user interface was the critical bottleneck of the process. Joergen uses a single button and a Nokia LCD. Besides that I could not find the parts close enough to be delivered in time, I wanted something more expandable. I found the TouchShield Slide from Liquidware. The rationale behind buying a touchscreen (and the bigger of the two available) is flexibility in designing the user interface.

The guys at Liquidware have been very helpful. Justin Huynh made an extra run to UPS for me, to get the hardware delivered in time. Mike Gionfriddo patiently helped me on the learning curve with very fast reply to my email support requests. When I had an issue with the IDE Christopher Ladden  helped me understand the errors and correct them. Liquidware, highly recommended!

In the end, rather than using the downloadable binary IDE for OSX and Windows, I built it straight out of github. This had the extra bonus that I could build it for my Ubuntu notebook as well, although I have not had time to test the Ubuntu build – the “hello world” was all done on a Windows workstation.

Assembling the hardware went OK despite me having two left hands. I had not done soldering work for years. The difference between my setup and Joergen’s is that I put a 10kOhm resistor on the transistor’s base, and I put it on pin 12.

A quick “hello world” on the touchscreen before packing. Too bad there was no power outlet in the plane, so I’ll have to wait for the next free moment to start coding.

Right now this hardware is just for an intervallometer. Beyond this, there are many shields in the Arduino universe and my intention is to use a few of them.

There is a shield to control stepper motors. One step closer to an automated pano head.

There is a USB host shield. With a little bit of digging and/or reverse I hope for finer control my Canon dSLR via USB.

There is a GPS shield for geolocation, and a wireless shield, and an ethernet shield, and… the sky is the limit. Open Source hardware, so great!

I was finished just in time for packing. I did not have a neat box for it, though. It will be fun at border control, with all those wires.