Preston L. Bannister { random memes }

2008.09.19

Paper size and user interface design

Filed under: Software — Preston @ 11:12 am

In a prior post I tried to make clear why today’s common idioms in user interface design are horribly inefficient on today’s screen sizes. Thinking about this a bit later, I realized there is something I did not mention – the single common basis for why the old trade-offs once made sense, are now complete non-sense, and has to do with the size of a piece of paper.

Most of the information we present through software (content, not decorations) is organized to present well on an ordinary letter-sized piece of paper. Once the width of a screen became wider than letter-sized paper, we no longer needed to be severely constrained in our use of horizontal space. We crossed a threshold. Now even the lowest-end screens (at 1280×800) are much wider than paper.

Why should an ancient medium like paper have anything to do with modern user interface design? Common paper sizes are – in effect – the result of a centuries-long experiment in user interface design. Paper can easily be fabricated in practically any size and shape. The paper sizes we use are the result of human choice, not a limitation somehow imposed by the manufacturing process. The range of paper sizes we most commonly use today are the result of generations of humans choosing what works best.

If you compare screen size to paper size, the old trade-offs make a lot more sense. There was for a long time – as long as 800×600 (or smaller) screens were significant – a very strong motivation to place overhead elements on the top and bottom of the screen, and not on the sides. For those small screens the cases where content was wider than the screen were not rare. For anything text-like, usage that requires horizontal scrolling is horribly inefficient (for the human, not for the computer). Any design element that took away from horizontal space for content was going to force an ever larger fraction of usage into horizontal scrolling. Put simply, screens were effectively narrower than paper and best design required preserving as much horizontal space as possible for content.

The old trade-offs did in the past make a lot of sense.

A low-end 1280×800 14-inch laptop screen is about 11.9 inches wide and 7.4 inches tall. Given the content area on letter-sized is about 7.5 inches wide and 10 inches tall, the screen about 2.6 inches too short and 4.4 inches too wide. Hold a piece of paper up against the screen, and the problem is pretty clear.

Have to admit: when “widescreen” panels first started to appear on laptops, I was hoping this was an aberration, not a trend. Unless you spend all your time watching movies and playing video games, most of the content you look at is text-like, and “widescreen” is not efficient for this sort of content. By now it seems very clear that we are going to be stuck with this form-factor for a very long time, and must adjust our design-habits to match.

There is a good deep/underlying basis that justified the old design idioms on old screens. That same basis on today’s “widescreen” panels makes those old idioms horribly wrong.

2008.09.17

Covering a use-case for many screens

Filed under: General, Software — Preston @ 4:04 pm

At 45 the eye doctor told me that my vision was going to get worse with age. Nothing unusual there, as a perfectly normal part of aging, the eye gets less flexible, and range of focus gets narrower. He was right, as a few years later I needed bifocals to comfortably focus on the screen at laptop and desktop distances.

What I find at 51 is that after a long day my eyes will sometimes get tired, and have a hard time focusing on the screen – at any distance. Maybe this is just a sign that I need a new prescription. Maybe this is a simply a fact of life at this age.

There is at least some chance that focus-fatigue will be less of a problem if the screens are placed at greater than the usual laptop-screen or desktop-screen distances. The question of screen-distance is interesting as the prices for 1920×1080 HDTV screens have dipped below $1000 for 42-inch panels. The resolution is a bit lower than I would like for a single panel – but not horribly so. I can see buying two or four panels to use as my working screen surface.

Aside from the fact that my workspace would now look like a hacker’s lair from some dubious Hollywood product, there is the practical question of how to hook up the screens to whatever computer I am using at present.

It is possible (though somewhat/very tricky) to hook up more than two screens to a Windows desktop, in hardware (best performance, but sometimes difficult to get working) or in software (through MaxVista, a third party product). With a Windows laptop it is not easy to get more than one additional screen.

With Unix and the X Window system there is another very interesting possibility. This is especially relevant to me, as I have switched both my desktop and laptop computers to running Unix (specifically Ubuntu Linux … even though my paid-for time is to develop applications that run on Microsoft Windows).

The old X11 protocol inherent in every version of the X Window system assumes that a window may be displayed on a screen remote from the computer on the program is running. This is really very old stuff. The original version of the X Window system assumed that when a program puts up a window, the window may appear on the screen of another machine on the network.

This is incredibly cool as I could walk into a room with a wall of flat panel screens, sit down, fire up my laptop, and open windows on the wall-screens.

…. in theory ….

In practice, as far as I can tell, this would take a lot of tedious one-time setup. Not really a surprise as to be practical this use-case requires a fast CPU and a fast wireless network. Before performance might not have been nearly good enough. With current hardware, this case is feasible.

This is where the success of Linux is an impediment. How would you search for someone else who had solved the same problem? Linux, X11, X Windows, and “remote” are far too generic to return any sort of selective results, and most of what comes back is as answers is of poor quality.

How can you dynamically associate a computer with network-connected screens in the same room?

2008.09.15

Google’s Chrome: Bet your enterprise on it

Filed under: Javascript, Software, Web — Preston @ 1:10 am

Have to credit an article for a bit of insight – though at all not what the author intended.

There is an aspect I had previously missed. The Google Chrome web browser is an excellent platform for company intranet applications.

Lots of companies have internally-used applications. Lots of developer-hours went into those applications, and some of those applications end up being mission critical. The average level of programming talent that went into creating those applications is often less than first rate, and so they tend to be somewhat inefficient, and somewhat unreliable.

Google Chrome is probably the best platform for those not-entirely-performant and not-entirely-reliable internally developed applications. The fast Javascript engine means less efficient applications will run better on Chrome, and isolation of Javascript engines within means less-reliable applications will cause less trouble when run within Chrome.

Is this what the Google-folk expected? My guess is not.

Organizations with a long enough history will almost certainly have had to deal with vendor-forced upgrades that interacted badly with important in-house applications. The fact that Chrome is open source means that companies now have more of a choice – they could choose to opt-out of any changes that disrupt important internal applications.

Google may have accidentally created the ideal platform for large organizations that are looking at deploying internally developed web applications.

2008.09.14

Design for standard screen sizes

Filed under: Software — Preston @ 3:11 pm

An observation that should be obvious – the universe of common screen sizes has changed.

When you design a graphical user interface (GUI), you want make your design optimal for current and near-future screen sizes. You want your design to be at least passable on less common smaller screen sizes. Over time the range changed:

  • 320×200 (color), 640×200 (mono), 720×348 (mono) … yes, I’ve been doing GUIs for a LONG time
  • 640×350 (EGA), 640×480 (VGA), 800×600 (SVGA)
  • 640×480, 800×600, 1024×768, 1152×864, 1280×1024, 1600×1200

The last range stayed around for a rather long time. The most-probable resolution went up over time, but VGA resolution stayed around as probable on low-end laptops, or on servers (which often inherited old VGA-only monitors). Note that all the common screen sizes shared similar aspect ratios: 1.3̅ (640×480, 800×600, 1152×864, 1600×1200), and 1.25 (1280×1024). Wikipedia has a rather nice picture at the bottom of the Super Video Graphics Array article.

Rather recently – due in large part to the rise of “digital” television – the set of common screen sizes has changed, and are now essentially all “widescreen”.

  • 1280×800, 1440×900, 1600×1080, 1920×1080, 1920×1200

Note that the ratios are generally “wider”: 1.7̅ (1920X1080), 1.6 (1280×800, 1440×900, 1600×1000, 1920×1200), 1.48 (1600×1080). This is for designers in fact a very big deal. Designs that once made sense are now badly non-optimal. The existence of a huge mass market for 1920×1080 (television) means that we pretty much are going to have a permanent “notch” in the price curve around that resolution, and that notch means a large “bump” in the number of screens at that resolution.

Personally, I once hoped that 1200×1600 (and similar ratios) might become dominant. That would better suit the content that we have to present. Most content (outside movies) is much taller than wide. Instead things have gone, er, sideways. (Old movies have an oddly dominant effect on the world in which GUI designers must exist.) Unfortunately, portrait-mode screens are rare, and there is no reason to expect this to change. Given the mass-market, designers can expect an overwhelming number of screens at the 1920×1080 resolution for at least the next decade – if not longer.

As designers we need to design for the screens on real customer desktops. That means designing for screens that are much wider than tall, when the content we have to present is usually much taller than wide. This mismatch has got to push us powerfully away from the once-reasonable trade-offs of the past.

The sum of which means that the design of current desktop GUIs are all badly wrong. Common/standard design elements that occupy scarce vertical space are not optimal. Design elements that occupy the entire horizontal extent of the screen – mostly as empty space – are not optimal.

What does all this mean? Standard window title bars that occupy the entire horizontal extent of a window are a really bad idea. Standard menu-bars that occupy the entire horizontal extent of a window are a really bad idea. Standard tool-bars that occupy the entire horizontal extent of a window are a really bad idea. Standard status-bars that occupy the entire horizontal extent of a window are a really bad idea.

If you are a smart, younger guy – for whom Microsoft Windows has been around for your entire life – you might feel uncertain questioning standard design elements. Might there be good reasons for standard elements of which you are unaware? Let me help you. Put a standard Window title bar on a VGA screen. When you add the horizontal extent for [icon for Windows menu] plus [document name] plus [application name] plus [icons for window size & close] … the horizontal extent of the title bar is pretty full, if not a bit over-full. At SVGA resolution the title bar is still full, and only at 1024×768 do we start to see a consistent (but not overwhelming) bit of wasted space. For a rather long period of time this standard design element was reasonably efficient.

The same argument applies to menu-bars and tool-bars, as both made reasonably efficient use of the then-available horizontal space.

Horizontal scroll-bars were rarely an efficient use of space, but (when used) were simple to understand as due to the near-exact similarity with vertical scroll-bars. Even as far back as the early 1980’s there were interaction-designs for scrolling that avoided horizontal scroll-bars as an inefficient use of scarce screen space.

At one time the value of small personal computers to the average human was not a certain thing. As designers – much of the time – we had to aim for the human who was not at all convinced he wanted to use a computer. This has changed. Due largely (and oddly) to the rise of the Internet, the overwhelming consensus is now that use of computers is at least of value, if not of primary importance. What this means for designers is that we can afford to be a little more arcane. This is NOT an excuse to be arcane without reason! What it does mean is that users are more willing to make a greater initial investment in learning than we could expect in the past.

What does all this mean? Current standard design elements that occupy the entire vertical extent of the screen are insane – given what we have now and can expect in the near future. We need to allow for user-relevant content to occupy the entire vertical extent of the screen (or nearly so). Today even on low-end laptops the width of the screen is a little to wide for reading text comfortably. What this means is that we afford to use horizontal space on various “overhead” elements, without negative impact on the presentation of end-user content.

The above argues for pushing design elements (outside of end-user content) to the sides, and away from the top or bottom of the screen.

When you place a variable or optional element on the left side of the screen, for text-like end-user content, when that element changes size (or disappears) the main content shifts horizontally. This is not optimal. By shifting the horizontal placement of content, you force the end-user to visually re-examine that content to see if it has changed.

This argues for placing overhead elements always to the right (at least for users whose written text reads left-to-right).

Note that some current designs are starting to push toward more efficient use of space. On Microsoft Windows the we have Internet Explorer 8, and Google’s “Chrome” web browser as examples. (I would hope this is due to designer’s explicit awareness of the space in which they must “fit” their designs, but have no basis to assume.) At least some designers are pushing for change in the, er, right direction.