User Centered

me: Now, which of the pics do I need to click?? Let's have a try - this one, please.
system: Do you really want?
me: turn monitor, click ok.
system: (font upside down) Is that ok? Please click ok within 15 seconds, otherwise I will restore the previous rotation. tick-tick-tick.
me: wind head, try to use the inverted mouse.. ok, maybe I should just wait the 15 seconds?
system: tick-tick over, old rotation restored.
me: Let's try again. turn monitor back to 0°. Which picture did I click last time?? Or was that upside down?

It's astonishing how they (nvidia/M$) fail to see a solution that appears very nice and ovbious to me. Instead, I need to guess if I need to click "turn right" or "turn left", operate dialogs with rotated text and inverted mouse, and hunt or wait for countdowns. It could all be so simple.

I imagine that we can't always predict how a user turns the display. For instance, the user might rotate the monitor while the computer is shut down, or in screensaver mode. So I thought that at least the dialog to turn the display should work in all eventual orientations.

This brings some issues we need to consider:
- The mouse depends heavily on display orientation. So we should better use the keyboard.
- The most logical keys to turn the display are the arrow keys. However, arrow symbols change their orientation, if displayed on a rotated screen.
- Rotated text is hard to read. However, if text is available in different orientations, the user will choose the one that appears in the right orientation, relative to the current display rotation.

The image on the right solves these problems by showing one piece of instruction text for each eventual screen rotation. Moreover, it turns the unreliable meaning of a rotated arrow symbol into an advantage: The arrow always resembles the key that you need in the current situation.

It can be discussed how this graphic can be integrated in a standard gui dialog. I think the "ok" button (operated with enter) should always appear in orientation that you want to confirm - while the "cancel" (operated with escape key) should appear in the orientation that you would return to if leaving the dialog.

Hitting the arrow button (one of them) would just turn the orange text (which is possible as an immediate response). Enter would turn the rest of the display, with the mouse pointer (this takes more time, usually).

If I wanted to write an hci pattern about this, I would probably call it a "multi-language hub", a "state translator" or something.

In situations where you need to change the language, display state, input device or whatever, provide view and controls that can be read and operated in all of the possible states.

Especially, we should not ask for the use of input devices that depend on the physical state of the display (like the mouse). The keyboard is clearly the better choice.

The proposed solution has even more - the arrow-button icon changes its meaning intentionally, depending on the physical state of the device. So it's more than just showing 4 redundant copies of the same information. The trick is to have 4 different versions, each suited to one of the possible states - and make sure by logical constraints (or cultural?) which one will be read.

Maybe I am not the first with this idea. I don't have that many different graphics cards, so maybe I missed a similar solution being already implemented somewhere?