Vincent Gable’s Blog

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).

March 18, 2008

Finding your laptop’s location with a shell command

Filed under: MacOSX,Programming,Sample Code,Tips,UNIX | ,
― Vincent Gable on March 18, 2008

Every wireless access point has a MAC address — a 48 bit number that uniquely identifies it. By checking the MAC address of the wireless access point your computer is connected to, you can figure out if it is being used at home, in your office, etc.

You can read this value from the shell with the command:
arp `ipconfig getoption en1 router`
Here’s how it works. The command ipconfig getoption en1 router gets the IP address of the router for the interface en1, which is the name of the Airport interface. If you want to get the router connected to the ethernet port use en0. The output of the command looks like:
128.62.96.1

arp prints information about the IP address, including the MAC address. arp is a little tricky in that it needs to take the address as an argument, you can’t pipe the output from ipconfig into it — that’s why ipconfig getoption en1 router is surrounded in “. Output from arp 128.62.96.1 looks like:
cisco-128-62-96-1.public.utexas.edu (128.62.96.1) at 0:12:44:f:5f:0 on en1 [ethernet]

The MAC address is in there, but you may need to use a regular expression to get at it. Here is an example of a perl script which prints just the MAC address of the wireless access point, or an error message.

if (qx{arp `ipconfig getoption en1 router`} =~ /([0-9A-Fa-f]{1,2}:[0-9A-Fa-f]{1,2}:[0-9A-Fa-f]{1,2}:[0-9A-Fa-f]{1,2}:[0-9A-Fa-f]{1,2}:[0-9A-Fa-f]{1,2})/){
   print "$1\n";
} else {
   print "Error; wireless internet is most likely unavailable\n";
}

This is essentially how IMLocation determines location.

In summary: Using the shell commands: arp `ipconfig getoption en1 router`, and the regular expression ([0-9A-Fa-f]{1,2}:[0-9A-Fa-f]{1,2}:[0-9A-Fa-f]{1,2}:[0-9A-Fa-f]{1,2}:[0-9A-Fa-f]{1,2}:[0-9A-Fa-f]{1,2}) on it’s output, you can get the MAC-address of the wireless access point your computer is using. This gives you the computer’s location in about a 150 foot radius.

EDITED TO ADD: Another way to get this information is to use the private tool: /System/Library/PrivateFrameworks/Apple80211.framework/Resources/airport
-s gives a list of surrounding networks; -I gives information about the current network.
Try /System/Library/PrivateFrameworks/Apple80211.framework/Resources/airport --help for more information.

You can even get the MAC address of all visible base-stations this way. Unfortunately, any system update could change the Apple80211.framework enough to break your code.

Red is a Magnet

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

…a study done at Apple almost ten years ago found that the user’s mouse gravitates toward red objects almost as though they were possessed with magnetism. The study forced us to abandon the idea of making close boxes and the Shut Down option red.

Ask Tog, February, 2000

I am interested to know if this is still true when you are using your own finger to directly touch a red screen element. I expect it still is true, but you never know for sure until you test. Real fingers don’t tend to be drawn towards real flame, even if cursors are drawn to animations of flame.

March 15, 2008

Standard Error Messages

Filed under: Programming,Research,Usability | , ,
― Vincent Gable on March 15, 2008

UPDATE 2010-04-08 CLANG/LLVM comes through!. OK, I can believe I’m living in the 21st century now :-)

All languages should include well-written error messages as part of their specification. These messages should include a link to a good explanation of the problem, and anything someone learning the language might want to know, like the design behind the error.

Every standards-compliant compiler would be required to emit the readable error messages.

This could eliminate inscrutable error messages, in one fell swoop.

(The old MPW Compiler had some
quirky and humorous error messages. “This struct already has a perfectly good definition”, for example. Unfortunately, I don’t know of any compiler that had different but more useful error messages. It’s time somebody wrote one.)

vgable@mail.utexas.edu is dead

Filed under: Announcement |
― Vincent Gable on March 15, 2008

Yesterday at about 8:30 AM CDT, my email account vgable@mail.utexas.edu was deactivated, with no forwarding service provided, cutting me off from an unknown number of contacts. What did I do to deserve this? Well, I graduated, but my alma mater is too cheap to offer forwarding.

The email address I check the most often is:

vincent period gable a-in-a-circle gmail period com

UPDATED 2008-11-13: I also had mail sent to HireVincent.com forwarded to the utexas account; that was taken down too, but I didn’t find out until now.

March 13, 2008

Useful Mac OS X Text-Editing Shortcuts

Filed under: MacOSX,Tips,UNIX,Usability | , , ,
― Vincent Gable on March 13, 2008

Here is a handful of lesser-known Mac OS X keyboard shortcuts that I’ve found to be very useful for working with text. They work in all standard text-fields, which means they work in most programs. Sadly, they don’t work in Microsoft products, and a few other apps that use non-standard text fields.

option = you will see the mouse cursor into a + , and you can now select columns of text! Unfortunately it only seems to work in editable text-fields, which is a great shame.

ctrl + d = forward delete, even if you don’t have it on your MacBook’s keyboard.

ctrl + a = Go to the beginning of the line the insertion-point is on.

ctrl + e = Go to the beginning end of the line line the insertion-point is on.

ctrl + k = “kill the current line”, deletes everything from the right of the insertion point to the next newline. This is very useful in Terminal, because you can delete the tail of a long command

command + delete = “Delete To Beginning Of Line”. Just like ctrl+k, but backwards, not forwards. (It even puts the killed text on the yank-pasteboard — don’t worry if that makes no sense, it’s an emacs-ism I don’t find useful.)

And yes, that’s ctrl, not command, because these are shortcuts inherited from the old UNIX text-editor emacs. There are more emacs “key bindings” that are available, but I have never found them useful. This long list of Mac OS X keyboard shortcuts includes them.

command + ctrl + d = look up the word under the mouse in the dictionary. I can’t believe that other operating systems haven’t done this for decades, it’s that useful.

It is unfortunate when programs use text-fields that do not support commands the operating system should give to every application. It’s always a mistake. Fundamentally, not supporting ctrl+a (go to beginning) is no different then not supporting command+c (copy).

If you find these commands useful, please teach them, and let developers know it’s a problem when you can’t use them. That will improve computing for everyone.

March 10, 2008

Red Fire Bar

Filed under: Cocoa
― Vincent Gable on March 10, 2008

I shared a “Red Fire Bar” with some coworkers today, and we all agreed it was very good. It tasted a lot like Mexican Hot Chocolate, with the chili peppers rounding out the flavor quite nicely. I do not normally like dark chocolate, but peppers add a “richness” that compliments it well.

Despite the name, the candy was not spicy — I’d rate it about the same as mild salsa.

March 7, 2008

Low Level Optimization Decays With Time

Filed under: MacOSX,Programming,Tips
― Vincent Gable on March 7, 2008

Did you know that hand-optimized assembler is slower then allegedly “slow” languages, say, Lisp or JavaScript? It’s true, if you wait long enough.

Imagine you have found some old hand-tuned Lisp code, and a hand-tuned PDP-1 assembly language version. If you executed both programs today, using a modern Lisp interpreter and a modern PDP-1 emulator, the Lisp code would perform much better. That’s because it could take advantage of all the improvements in Lisp interpreters and computers since the 1960’s, while the PDP-1 code would be held back by trade-offs made long ago to appease obsolete hardware.

I expect that ultimately JavaScript will outperform contemporary SSE code, because hardware inevitably becomes obsolete over time.

When assembly code becomes obsolete, you are stuck with two slow options. Use obsolete hardware to execute the code, or emulate your obsolete hardware on a new computer (since computers keep getting faster, emulation will become the fastest choice). Meanwhile the high-level code will still be executable, and able to take advantage of all subsequent hardware improvements.

Some x86 instructions are already obsolete; by which I mean they give worse performance then more common instructions.

Assembly/Compiler Coding Rule 31. (ML impact, M generality) Avoid using complex instructions (for example, enter, leave, or loop) that have more than four µops and require multiple cycles to decode. Use sequences of simple instructions instead.

Intel®64 and IA-32 Architectures Optimization Reference Manual

You could say that this is all academic, because in half a century the code you wrote today will be irrelevant, and I would agree. PDP-1 vs Lisp was hypothetical hyperbole, show that the benefits of low-level optimization decrease the longer the code is in use, because the advantages compared to high-level code decrease over time.

What really drove this home for me was Apple’s switch from PPC to x86. Suddenly all the AltiVec code I’d ever written was obsolete. If someone bought a new Mac, my AltiVec code would be emulated, and slower then unchanged (but recompiled) C code! I could have reused existing AltiVec code to create SSE code, but then I would be stuck doing optimization work every time a sufficiently new computer came out.

Algorithmic-level optimization holds it’s value over time; low-level optimization does not. However, software is such a rapidly-changing environment that a short-term investment can still make a hell of a lot of sense.

Older Posts »

Powered by WordPress