eriksmartt.com/blog

Hiding an idle mouse cursor on Ubuntu

One of the obscure features of OS X that I love is that the mouse cursor hides itself when idle. By doing so, it stays out of the way when reading on-screen. When I made the shift to using Ubuntu at work, the non-hiding cursor was one of those little details that annoyed me. Of course, like most things on linux, someone else had the same opinion and has solved the problem already. The solution is a tool called unclutter (easily installable with a `sudo apt-get install unclutter`.)

Unclutter takes a few optional parameters. I like: `unclutter -idle 1`, which hides the cursor after one second of inactivity. The hidden cursor not eliminates the potential annoyance while reading on-screen, but may also serve to remind the user that keyboard shortcuts are faster anyway ;-)

For more, see: unclutter: hide the mouse cursor after a period of inactivity

Lily: Visual programming in JavaScript

I have an odd fascination with Visual Programming languages, and while I’ve gotten so far as sketching out some UI concepts and object models for a text-processing focused, web-mashing, visual programming environment, I’m a long way from having anything that works. Much to my surprise then when David Ascher dropped a link to the Lily project on his blog today. Holy cow this is sweet. Think PD or Max/MSP written in JavaScript, running in a browser, with modules for popular Web API’s and JavaScript frameworks (ex., “Amazon, Flickr, Wikipedia, Yahoo; UI modules that wrap widgets from YUI, Scriptaculous, JQuery, Google Maps….”)

Check out one of the demo’s here:

(Via: Lily: JavaScript, visual programming, fun.)

Touchscreen keyboard (could be killer with tactile feedback)

The Optimus Tactus keyboard:

…a programmable, touch-screen that acts like a keyboard. Pretty amazing potential for experiementing with user interaction interfaces. Could be even better if merged with some of the haptic/tactile feedback work that Apple and Nokia have been doing. Ex:

• “Nokia shows off some seriously cool haptic-feedback touchscreen tech - Haptikos takes haptic feedback to a whole new level“
• “Apple patent filed for tactile touchscreen - raised, indented keys“

User error vs. machine error vs. interaction design

Why the high volume of discarded stickers? What does this tell you about the users? What about the machine?

The full context:

The design of this self-service, produce-pricing machine includes an area for discarded “mistakes”; but at what point is it an indication that it’s no longer user-error?

Interface design on Sparkfun’s new GeoChron

Interface design on Sparkfun’s new GeoChron

Sparkfun just released a new, stand-alone GPS logging device, which looks to be a slick alternative to all the “mobile-device + Python + bluetooth GPS” hacking I’ve resorted to for similar tasks. It’s a pretty tempting package if you need dirt-simple GPS logging. However, I’m a bit confused by the switches. Take a look at the picture of the device below:

There are two toggle switches: one for on/off, and one for standby/run. Take a minute to look at the switch diagrams and labels, and think about how to use this device. How do you turn it on? How do you make it start logging?

Now that you’ve thought about it, was it clear? What does the ‘1′ on each switch mean to you? What does the graphic under each switches label mean? Ignore the ‘1′ and ‘0′ and look just at the diagram. Based on the graphic alone, which switch position should “on” be?

I used to get the ‘1′ vs. ‘0′ on switches backwards when my mental model was of the ‘0′ indicating a completed circuit. Now I use a binary metaphor, where a ‘1′ bit is on, and a ‘0′ bit is off. That seems to be what the switch means. But if I take that approach on the GeoChron, then the standby/run switch is installed backwards. Personally, I think I’d drop the graphic under the switch labels (I think it’s more confusing then helpful), and flip the standby/run swtich so that ‘1′ means ‘run’, and so that the switches are both pressed in the same direction when the device is on and logging. With a device this simple, you really shouldn’t have to think about how to turn it on. (I still want one though ;-)

Any shape or size…

“when an object can be any shape or size, what shape or size should it be?”

I love following Jan Chipchase’s Future Perfect blog. It documents an amazing level of ethnographic research that most companies simply don’t have the luxury to participate in. The quote above is a closing slide in one of his presentations. It stuck me because of it’s dual use as both a design meditation, and a serious question designers of any product should be able to answer. It also begs the reverse question for existing design:

If this object could have been any shape or size, why did it end up like this?

(Via: Insight & Innovation: Design Research, Nokia Connection 2007 [ppt])

Photosynth — Navigating 2D photos in 3D space

Interesting video demonstrating Photosynth, an application for navigating 2D photos in 3D space: “Dive into the world of Photosynth.”

From the site:
“Our software takes a large collection of photos of a place or an object, analyzes them for similarities, and displays them in a reconstructed three-dimensional space.”

“Each photo is processed by computer vision algorithms to extract hundreds of distinctive features, like the corner of a window frame or a door handle. Photos that share features are then linked together in a web. When the same feature is found in multiple images, its 3D position can be calculated. It’s similar to depth perception - what your brain does to perceive the 3D positions of things in your field of view based on their images in both of your eyes. Photosynth’s 3D model is just the cloud of points showing where those features are in space.”

(Via: My Icon. Your Icon?.)

“Extreme Programming vs. Interaction Design”

Here’s a topic that hits rather close to home: In the interview, “Extreme Programming vs. Interaction Design“, Kent Beck and Alan Cooper discuss opposing views on producing better software, and unfortunately, I can’t say that either one really “wins” the argument.

The piece hits close to home because I used to work in Interaction and Information design, so I fully grok the value proposition Cooper presents. The argument is the typical Human-Computer Interaction (HCI) / User-Centered Design (UCD) pitch — that up-front interaction design will (1) produce a higher-quality product, and (2) will reduce development costs by solidifying technical requirements. However, what surprised me in the interview is that Cooper seems inflexible on how to best apply this UCD process, insisting that it is a design “phase” that starts and finishes before any development begins.

The central assumption in Cooper’s argument is that programming is expensive and programmers are unwilling to throw out prototype code. Because of this, Cooper believes that you should not allow programmers to begin working on a project until 100% of the requirements are set. I used to believe that too, but I have since seen the light.

The trouble is, rigid processes with pre-defined phases and deliverables are best used when managing a large group of low-to-moderately skilled developers. However, small teams of smart people change the rules and the outcome. Development teams that recognize the value in Agile Development and XP also understand that the assumptions driving waterfall-style development phases are based on faulty assumptions, which easily fall apart given the following findings: (1) It *is* possible to reduce the cost of developing code (see Python and Ruby on Rails); (2) Better products are often the result of iterative design (compare a forth-gen iPod to a first-gen); and (3) If your programmers aren’t capable of “sketching in code”, you need to hire better programmers (see all of Paul Graham’s and Joel Spolsky’s articles ;-)

This isn’t to say that interaction design isn’t helpful, because it most certainly is, and any company serious about serving it’s customers should at least consult a user experience and interaction designer about their products, if not have such a designer on the team; However, there is even greater value in rapid iterative development — both in interaction and implementation, and companies that understand how to utilize this advantage will produce higher-quality user experiences in a shorter time-to-market.

(via Signal vs. Noise.)