Vincent Gable’s Blog

April 25, 2008

Larger Displays are Better. More Displays are Better.

Filed under: Accessibility,Design,Research,Tips,Usability
― Vincent Gable on April 25, 2008

Here’s Jakob Nielsen’s economic justification for giving employees large screens,

Big monitors are the easiest way to increase white-collar productivity, and anyone who makes at least $50,000 per year ought to have at least 1600×1200 screen resolution. A flat-panel display with this resolution currently costs less than $500. So, as long as the bigger display increases productivity by at least 0.5%, you’ll recover the investment in less than a year. (The typical corporate overhead doubles the company’s per-employee cost; always remember to use loaded cost, not take-home salary, in any productivity calculation.)

Jeff Atwood has written a “one-stop-shop for research data supporting the idea that, yes, having more display space would in fact make you more productive”. But he warns us that “Having all that space can make you less productive due to all the window manipulation excise you have to deal with to make effective use of it.”He calls this the Large Display Paradox. But, there are solutions to this problem. Using software to divide the large single-display into a “grid” of virtual “monitors” is the one he proposes.

A recent and widely publicized University of Utah study concluded that people were less productive on a 26″ screen then an 18″ screen. (Unfortunately I haven’t found a better link to their actual data then this crappy PDF brochure.) However, they also found that people were more productive with two 20″ screens. Their 26″ monitor was 1920×1200 pixels = 2.3 MP, their 20″ was 1600×1200 pixels = 1.92MP, so two 20″ screens = 3.84 MP, quite a bit bigger then the 26″ screen, and with greater productivity. This supports the theory with the right windowing system, productivity increases as the number of usable pixels increases.

I’ve only found one exception to the “bigger is better” rule of workspaces. Portability (Availability) can be worth more then pure productivity. There’s an old gunslinger saying that “The best gun in the world is the the one I’ve got in my hand right now”. Similarly, having a “big iron” on your office isn’t much use if you are flying somewhere over the atlantic. There’s no substitute for having a computer in-hand. Even if you would be more productive using a 17″ laptop, it’s better to get a 13″ ultra-portable, if it means you are more likely to actually have it around when you need it.

Business travelers, and creative professionals who work better in eclectic settings, are examples of people who are better served by the smallest sufficiently-powerful laptop they can find. But for most people bigger is better. Fortunately, small laptops can be connected to large displays.

Simple Can be Faster then Powerful

Filed under: Design,Usability
― Vincent Gable on April 25, 2008

…Judy Olson and Erik Nilsen wrote a classic paper comparing two user interfaces for large data tables. One interface offered many more features for table manipulation and each feature decreased task-performance time in specific circumstances. The other design lacked these optimized features and was thus slower to operate under the specific conditions addressed by the first design’s special features.

So, which of these two designs was faster to use? The one with the fewest features. For each operation, the planning time was 2.9 seconds in the stripped-down design and 4.6 seconds in the feature-rich design. With more choices, it takes more time to make a decision on which one to use. The extra 1.7 seconds required to consider the richer feature set consumed more time than users saved by executing faster operations.

Jakob Nielsen, the day before my birthday, 2006.

April 18, 2008

Shifflett Happens

Filed under: Design,Programming,Tips
― Vincent Gable on April 18, 2008

To show that nonuniform distributions occur in real life, consider Americans with the uncommon last name of Shifflett. The 1997 Manhattan telephone directory, with over one million names, contains exactly five Shiffletts. So how many Shiffletts should there be in a small city of 50,000 people? Figure 2-4 shows a small portion of the two and a half pages of Shiffletts in Charlottesville, Virginia telephone book.

The Algorithm Design Manual, page 39.

April 15, 2008

Whozit?

Filed under: Design
― Vincent Gable on April 15, 2008

I’ve recently moved, and that means meeting new people and making new friends. And that means getting instant-messages (IM) from people for the first time. Unfortunately, no IM clients handle that initial contact as well as it should. The basic problem is that they don’t give you enough information to figure out who the person is, making for awkward situations where you know you already know the person, but you don’t have the foggiest idea who the hell they are. And if that wasn’t bad enough — you are interacting with them for the first time in a different social medium, and you know what they say about first impressions…

For example, iChat only shows you the screen-name of someone when they message you for the first time. (This isn’t necessarily a bad trade-off for people who are easily offended). Unfortunately screen-names are (often) totally incomprehensible. Even when you can see what they are saying, it’s often something unrevealing like “hey, what’s up?” In general, there isn’t a quick way to get meaningful information about a person before you start chatting to them — unless you do your own legwork.

Fortunately computers can do that legwork for you. The moment an unknown screen-name says something to you, your client should start researching them, presenting you with any relevant information it finds.

In my experience, just searching facebook for the person with that screen-name works most of the time. There are numerous other social-networking/directory resources that can be queried automatically. As a last-resort, goggling the screen-name can turn up posts in forums and communities that can at least give you a clue as to who the person is. (try it on your friends, it’s hit or miss).

In college I modified some dashboard widget to do facebook+google searches for me. It wasn’t as good as having the functionality baked into the chat-client, but it was pretty fast (hit F12 + click + type one thing in one place + enter), and that made it worlds better then doing the legwork through a browser. It was sometimes useful when a new semester started (unfortunately I haven’t needed it for long enough to lose it).

Instant Messaging clients could do a lot more to make first-contact easier by presenting more information about who’s talking to you. It’s just a matter of connecting parts that exist today.

April 9, 2008

Color Temperature

Filed under: Design
― Vincent Gable on April 9, 2008

What “color temperature” is, or why color is measured in degrees Kelvin.
(via Daring Fireball).

April 7, 2008

foreach For The Win

Filed under: C++,Cocoa,Design,Objective-C,Programming,Research
― Vincent Gable on April 7, 2008

I love foreach. What I really mean is that I really like dead-simple ways to iterate over the items in a container, one at a time. It goes beyond syntactic sugar; making errors harder to write, and easier to spot.

I’m using the term “foreach”, because the first time I realized the utility of simple iteration was seeing Michael Tsai’s foreach macro. I instantly fell in love with the ‘keyword’, because it greatly simplifies iterating over items in a Cocoa container. My reaction was so strong, because the (then current) Cocoa iteration idiom I was using was so bad. As Jonathan ‘Wolf’ Rentzsch says:

I have a number of issues with enumeration in Cocoa/ObjC. Indeed, I have a problem with every one of the three lines necessary in the standard idiom. It even goes beyond that — I have an problem with the very fact it’s three lines of code versus one.

Objective-C 2.0 (Leopard and later) introduced Fast Enumeration. It’s a better way of handling enumeration then Michael Tsai’s macro, but if you are stuck using Objective-C 1.0, then I highly recommend using his foreach macro.

I do not like the C++ stl for_each idiom. It’s not simple enough.

To explain what’s wrong with for_each I should explain what a “foreach” should look like. It should be a two-argument construct: “foreach (item, container)“, and no more. container should be evaluated only once. Syntax details aren’t terribly important, as long as they make sense.
foreach(child, naughtyList)
iterate(child, naughtyList)
ForEach(String child, naughtyList)
for child in naughyList:
for(NSString *child in naughtyList)
Are all fine constructs.

The most obvious benefits of a foreach is that it’s less code, easier to write, and less work to read. Implemented correctly, it also makes bugs harder to write — mostly because it minimizes side effects in the loop construct. For example, do you see the bug in the following code?

for( list<shared_ptr<const Media> >::iterator it = selectedMedias->selectedMediaList().begin(); it != selectedMedias->selectedMediaList().end(); ++it )

I didn’t; and it’s kind of a trick question. ->selectedMediaList() isn’t an accessor function — it constructs a new list every time it is called. So selectedMediaList() != selectedMediaList() because it returns a different list each time. The loop never terminates because it will never equal end(), since it is the end of a different list. But you have no way of knowing this without knowing details of what selectedMediaList() does.

Using BOOST_FOREACH avoids the problem:
BOOST_FOREACH(shared_ptr<const CSMediaLib::Media> media, selectedMedias->selectedMediaList())
works regardless of how selectedMediaList() is implemented, because it is only evaluated once. It’s also easier to write, and to read. I haven’t used BOOST_FOREACH much, but it’s been totally positive so far. (Yes, the name is ugly, but that’s not important).

Loops are a staple of programming. Simplifying and error-proofing the most common kind of loop is a huge productivity win. foreach regardless of it’s flavor, is worth a try.

April 6, 2008

Yes

Filed under: Design,Programming,Research,Usability | , ,
― Vincent Gable on April 6, 2008

Just a curiosity, but it happens that in a yes-no binary response test, the reaction time to select “no” is longer than for “yes.”

Source

I haven’t taken the time to verify this, or see if anyone has quantified the difference in response times.

UPDATE 2009-12-18: The technical term for this is Acquiescence Response Bias — the tendency to agree with any assertion, regardless of its content.

March 31, 2008

Resolution Independence

Filed under: Accessibility,Design,MacOSX,Programming,Research,Usability | , , ,
― Vincent Gable on March 31, 2008

Displays are getting sharper all the time. Sharpness is very important, because things don’t just look better on high-resolution displays; they are measurably faster to use.

according to Jakob Nielsen:

Low-resolution monitors (including all computer screens until now) have poor readability: people read about 25% slower from computer screens than from printed paper. Experimental 300 (PPI) displays (costing $30,000 (in 1998)) have been measured to have the same reading speed as print, so we will get better screens in the future.

The resolution of a display is measured in PPI, Pixels Per Inch, the number of pixels used to draw a one inch long, one pixel thick, line. A higher PPI means smaller pixels, and clearer images. You can calculate the PPI of your screen by

PPI ≅ sqrt(pixels_across^2 + pixels_down^2) / diagonal_inches

I am writing this article on an iMac with a 24″ screen, showing 1920 x 1200 pixels, so my PPI ≅ sqrt(1920*1920+1200*1200)/24 ≅ 93 PPI.

The resolution of a printer is measured in DPI, or Dots Per Inch. Unfortunately, DPI is often used as another term for PPI. That is technically inaccurate, but even Microsoft does it. SPI, Scans Per Inch, is another term that is used instead of PPI, but fortunately is correct when describing digital displays.

Bitmapped images are smaller on high-resolution displays, because the pixels the picture is made of are smaller. This can be a big problem for interface elements.

For example, today Apple’s interface guidelines say “The standard Help button is 20 pixels in diameter and should be placed at least 12 pixels from other interface elements.” On my iMac, a 20-pixel wide circle is about 0.21″ in diameter — roughly 1/3rd the diameter of a Dime. help_button_today.png But on a 300 PPI display, it would be 0.07″ in diameter — roughly as thick as three pieces of mechanical pencil lead help_button_300ppi.png. As you can see, it’s way too small to comfortably click!

Just scaling bitmapped images, so a 20-pixel wide picture is always drawn 0.21″ wide, isn’t a good work around. It’s just emulating a low-definition, low-readability, display on a more expensive high-definition display. Another problem is that it looks terrible when everything else on the system is crystal clear.

help_button_300_scaled_up.png

It gets more ugly when the scaling-factor is higher, say for a display that matched the print fidelity of the tawdry magazines you see in the grocery check-out isle.

A resolution independent interface can be usably, and pleasantly, displayed on high-definition or standard-definition screens. There are two ways to build a resolution-independent display.

You can use vector images, which can be resized without problems. SVG and PDF are two popular formats. This sounds like an elegant “design once, show anywhere” solution. But in practice today building a vector image of the same quality as a bitmapped image can be very difficult, especially with complex images. This will change in time. Today designers create bitmap images by embellishing a vector image with bitmap-effects. As vector-imiging tools improve, they will be able to perform equivalent effects, but in a resolution-independent way.

Alternately, your app can carry-around a set of bitmapped images and draw the one that most-closly matches the current resolution. If you only have to support a handful of well-definied resolutions, this might be the best choice with today’s tools. The only caveat is that all signs point to vector-images being the future. Loading one vector image is also easier the selecting one of many bitmapped images to load. (And theoretically a vector image won’t have to be tweaked if we suddenly get one million PPI displays).

Already Solved

I think it’s important to note that Fonts have been facing an even more severe resolution-independence problem for decades, and have mostly solved it. The same font can be rendered well on a 1200 DPI printer, and a 72 PPI display. That’s a much bigger resolution disparity then a computer interface will ever have to deal with, because by the time a screen close to the resolution of a 1200 DPI printer is common, nobody will be using 72 PPI displays anymore (they aren’t even sold today).

Early fonts were bitmap fonts — a collection of bitmaps of what the font should look like at a particular scaling. But today vector fonts have replaced bitmapped fonts on the desktop, and even the iPhone. Vector fonts let us do amazing things with scaling (font specific stuff starts at 1:18). Vector fonts have been such an unqualified success, that it’s hard to imagine vector images not replacing bitmapped images for interface elements.

When Will It Happen

Jeff Atwood “did some research to document how far we’ve come in display resolution over the last twenty years.”


Year

Model

Resolution
Size DPI
1984
Original Macintosh
512 x 342 9″ (8.5″) 72
1984

IBM PC AT

640 x 350 13″ (12.3″) 60
1994
Apple Multiple Scan 17 Display
1024 x 768 17″ (16.1″) 80
2004

Apple Cinema HD display

2560 x 1600 30″ 100

I used the Tag studios Monitor DPI calculator to arrive at the DPI numbers in the above table. I couldn’t quite figure out what the actual displayable area of those early CRT monitors were, so I estimated about 5% non-displayable area based on the diagonal measurement.

Regardless, it’s sobering to consider that the resolution of computer displays has increased by less than a factor of two over the last twenty years. Sure, displays have gotten larger– much larger– but actual display resolution in terms of pixels per inch has only gone up by a factor of about 1.6.

I can’t think of any other piece of computer hardware that has improved so little since 1984.

It certainly doesn’t not look like we will get 300 PPI displays anytime soon! At the present rate, it will be decades before a $2000 display matches the clarity of a $20 printer.

However today’s smarphones and small-devices have much sharper screens then computers. The first generation iPhone is 160 PPI, the Kindle is 167 PPI. Now these are much smaller screens then full-sized computers use, and I don’t know how cost-effective it is to scale the screens up from 3.5″ to 30″. But I do know that significantly higher resolution displays are being produced in increasing volume today for smartphone. So we may be fortunate enough to have, say 180 PPI, displays many years sooner then Atwood’s data suggests.

UPDATE 2009-02-11: Wikipedia’s list of devices by PPI lists some very high PPI devices. The Sony Ericsson X1
phone has broken the 300 PPI “readability threshold”
. The Fujitsu Lifebook U820 has a 270 PPI display. But the screen is only slightly bigger then the Osborne 1 “portable” computer of 1981. Still, if history is any indicator, once better technology is actually sold, it catches on very quickly.

March 26, 2008

Fitts’ Law

Filed under: Design,Research,Usability
― Vincent Gable on March 26, 2008

time = a + b*log2(distance/target_size + 1)

This is far and away the best article on Fitts’ Law I’ve seen.

Here’s how you can apply it.

The Accot-Zhai “Steering Law”, which predicts how quickly a person can “steer” something down a 2-dimensional road without “crashing” can be derived from Fitt’s Law. As you would expect, the wider the road, the faster it can be traveled. This might be my favorite implication of Fitt’s Law, since it implies that my small car may have a higher “usable speed” then a bulkier muscle car. :-p

March 25, 2008

Japanese Advertisers Switching from URLs to Search Terms

Filed under: Design,Research
― Vincent Gable on March 25, 2008

Within minutes of riding on the first trains in Japan, I notice a significant change in advertising, from train to television. The trend? No more printed URL’s. The replacement? Search boxes! With recommended search terms!

A very interesting observation from Cabel Sasser (with lots of pictures).

« Newer PostsOlder Posts »

Powered by WordPress