HUMAN-COMPUTER INTERACTION
SECOND EDITION
(i) Large high-resolution colour VDU (20 inch or bigger) -- these tend to be enormously big (from back to front). LCD screens, although promising far thinner displays in the long term, cannot at present be made large enough.
If we turn to video, things are even worse. Imagine we want to store moving video using 12 bits for each pixel (4 bits for each primary colour giving 16 levels of brightness), each frame is 512 ¥ 512 pixels, and we store at 25 frames per second. This is by no means a high-quality image, but each frame requires approximately 400 kbytes, and our disk will overflow in less than 2 minutes. Even a jukebox of optical disks would only manage an hour or so (even assuming we could transfer it fast enough). Lowering our sights to video stills or simple screen snapshots, we see that main memory is soon swamped, although we could manage a fair few frames on disk.
A typical configuration of user input--output devices would be a screen with a keyboard for typing text and a mouse for pointing and positioning. Depending on circumstance, different pointing devices may be used such as a light pen (for more direct interaction) or a trackball (especially on portable computers).
A similar problem, icon wars, occurs on window systems. The user clicks the mouse on a menu or icon, and nothing happens; for some reason the machine is busy or slow. So the user clicks again, tries something else -- then, suddenly, all the buffered mouse clicks are interpreted and the screen becomes a blur of flashing
Whereas it is immediately obvious that slow reponses can cause problems for the user, it is not so obvious why one should not always aim for a system to be as fast as possible. However, there are exceptions to this -- the user must be able to read and understand the output of the system. For example, one of the authors was once given a demonstration disk for a spreadsheet. Unfortunately, the machine the demo was written on was clearly slower than the author's machine, not much, at worst half the speed, but different enough. The demo passed in a blur over the screen with nothing remaining on the screen long enough to read. Many high-resolution monitors suffer from a similar problem when they display text. Whereas older character-based terminals scrolled new text from the bottom of the screen or redrew from the top, bitmap screens often 'flash' up the new page, giving no indication of direction of movement. A final example is the rate of cursor flashing: the rate is often at a fixed frequency, so varying the speed of the processor does not change the screen display. However, a rate which is acceptable for a CRT screen is too fast for an LCD screen which is more persistent, and the cursor may become invisible or a slight grey colour.
Computation bound This is rare for an interactive program, but possible, for example, when using find/replace in a large document. The system should be designed so that long delays are not in the middle of interaction and so that the user gets some idea of how the job is progressing. For a very long process try to give an indication of duration before it starts, and during processing an indication of the stage that the process has reached is helpful. This can be achieved by having a counter or slowly filling bar on the screen that indicates the amount done, or by changing the cursor to indicate that processing is occurring. Many systems notice after they have been computing for some time and then say 'this may take some time: continue (Y/N)?'. Of course, by the time it says this the process may be nearly finished anyway!
Modern graphical interaction consumes vast amounts of processing power and would have been completely impossible only a few years ago. There is an extent to which systems have to run faster to stay still, in that as screen size, resolution and colour range increase, so does the necessary processing power to maintain the 'same' interaction. However, this extra processing is not really producing the same effect, screen quality is still a major block on effective interaction.
Section 2.4 dealt mainly with the screen as a direct output device. We discussed several different technologies, in particular CRT and LCD screens. Auditory output is still comparatively rare, and this will be discussed in detail in Chapter 15.
For example, while writing a paper with some word-processing package, it is necessary at times to see both the immediate surrounding text where one is currently composing, say, the current paragraph, and a wider context within the whole paper that cannot be easily displayed on one screen (for example, the current chapter).
In particular, the field of ergonomics addresses issues on the user side of the interface, covering both input and output, as well as the user's immediate context. Dialog design and interface styles can be placed particularly along the input branch of the framework, addressing both articulation and performance. However, it is most usually associated with the computer and so is biased to that side of the framework. The entire framework can in turn be placed within a social and organizational
processed in 0.009 seconds
| |
HCI Book 3rd Edition || old HCI 2e home page || search
|
|
feedback to feedback@hcibook.com | hosted by hiraeth mixed media |
|