ImageHBrowser
`Taxonomy and
`Guidelines for
`Designers
`
`CATHERINE PL~AVT, DAVID CARR, and BEN SHIVEIDERMAN
`University of Maryland
`
`~
`
`quickly acconmiodate these differences,
`scroll bar is a bvell-estahlished fixture in
`research on scroll bars is limited.'.'
`con tcm pora1-y graphical user in terhces.
`Building on user familiarit!, with
`on e - d i m e ns i o n a1 scro 11 11a rs , III a n y
`For esarnple, in \\ ord processors one-
`ditiiensional scroll bars help users navi-
`designers simply use two one-dimen-
`sional scroll bars when the application
`gate long docunicnts. i17ithout a scroll
`har users must remeniber their position
`requires independent control over the
`;ind use some coiiiniantl to jump within
`horizontal and vertical directions, as in
`the docunieiit (for example, "173,193p"
`panning a map. This is effective if users
`t o display lines 1 7 3 through 193).
`frequently move in a single direction
`by small increments of less than one
`Scroll hars let users riiovc through the
`document incrementally and hy jiinips, ' screen.
`But in many cases this solution is
`and they indicate the current position
`of the screen. T h i s visual feedback
`inadequate:
`t In painting and drawing pro-
`prol)al)ly reduces memory and cogni-
`l grams, the image is often much larger
`tive load.
`Although all one-dirn~nsional scroll
`than a screen, redisplay times arc long,
`overviews are needed,' zooming is
`bars have a cointiion core fiinctionaliq,
`their indir.idual features ;ind operation 1 desirable, diagonal panning is required,
`differ suhstantiall~.. But tiecause users ' or multiple detailed views are needed.
`
`~
`
`~
`
`4b In many iipp lications useu
`mzm b n "
`la7-g-e iwng-es. h f o s t
`designivs mevdy use two one-
`dimensional scroll ban o r nd hoc
`designsfor two-dimensional
`scf-oll ban. Houievey; the
`complexity of tw 0-dim ensionid
`broulsing suggests that mwe
`cm-efid nnalysis, design, and
`eualnntion might leiid to
`sipijicmf impmuernents.
`
`~~
`~~
`
`I E E E S O F T W A R E
`
`GOOGLE EX. 1038
`Google v. Philips
`
`

`
`Figure 1. Illustration of some t e m i s iised to descaibe hrowsers. Fii-st, a global
`vie?;. (A) gives a v i m of'the entire u n i ~ e n e tkiit can be explored. One pmpose of
`the global view is to give a sense ofulhnt in$omnation will be in the image - and
`what i.s not. For example, a world iitlus global Srieu~ wight shoul id rnap oj- the
`eayth, telling the user that this %odd" doesn't include the vi0011 or the galaxy.
`An intemediate view (B) of the wodd map zodd include mitp (!f Europe and
`France. The detailed view (C), also called the local s.ic;l:, shows a part of' an
`overz~iew (D), usi~ally magnified. The level of detiril t-et/ciir-ed depends on the task
`to he pe6ormed. The zooming firtor describes the l e i d of miignijicntion between
`t a o -Lliez;:s. The field-of-vie.u! (E) indicates on the o v e i v i m the lociitiori iznd shape
`the coordinated detailed viez. Taken together., nn ooc'tziieu: irnd detailed vieu>
`of
`are cahd a coordinated pair (F). I n u coo?*dinated pair, both the o-L,eniew arid
`detail are shown, letting risers keep a seme of context while they zliew detail.
`Seuet-al coordinated p a k r caii puxiidc a hieiw-chy of niexs, in xhic-h the detiriled
`
`(See Figure 1 for short definitions of
`some key terms we use in this article.)
`t In geographic information sys-
`tems, users browsing a world map may
`want to see detailed views of a country,
`county, or city. T h e world map pro-
`vides a helpful - possibly necessary -
`overview, and the system must then
`support a zooming factor of 1 to 10, 1
`to 10,000, or even 1 to 10,000,000. In
`addition, users may want to follow the
`route of a river, border, o r highway
`(diagonal panning), compare two har-
`bors (multiple detailed views), o r siinul-
`taneously view highways and popula-
`tion-density maps (related vieii s).
`t In medicine, a doctor may need
`to see a full spinal X-ray and close-ups
`of vertebra pairs (an overview and mul-
`tiple detailed views) o r to examine a
`tissue boundary (pan a detailed view).
`t In large applications such as
`power di s t r i b u t i on, t e 1 e p h on e net -
`works, system administration, trans-
`p o r t a t i o n systems, and c I1 e in i c a 1
`plants, managers typically use an
`overview diagram to monitor the sys-
`tem and detailed views to focus on
`anomalies. S o m e problems can he
`solved with local information only, but
`o t h e r p r o b 1 e Ins re q u i re 111 u 1 ti p I e
`
`detailed views o r an understanding of
`the big picturc.
`All thesc situations call for hrowsing
`in two or more dimensions, and their
`requirenients suggest that more careful
`analysis,4 design, and evaluation might
`lead t o significant improvements.
`Indeed, our exploration of existing 21)
`hrowsers has led lis to i(1entify many
`features and a wide variety of tasks per-
`formed with the browsers. H e r e we
`introduce an informal specification
`technique to tlcscrihe 1D 1)rowsers and
`a task taxonomy, suggest design fea-
`tures and guidelines, and assess existing
`strategies. W e focus here on the tools
`to explore a sclccted image and so clo
`not cover techniques to browse a series
`of images (via. for exainple, a radiology I.
`works-tation t h a t sho-\cs dozens of
`images) or to I)rowse Ix-gc-image data-
`bases (via thumbnails o r graphical
`searches, for eunlple).
`
`BROWSER SPECIFICATION
`
`When we hegan to explore brows-
`ers, we found it difficult to even tliscuss
`our findings because there was no ade-
`quate method to describe browser fea-
`
`tures. 'This led us to expand a sketch-
`i n g technique, DMsketch (direct-
`inanipulation sketch),' being developed
`in o u r laboratory. W e had created
`IlMsketch to help designers exchange
`and record ideas iiiore quickly and
`clearly than a formal specification lan-
`guage.
`0 r i gin a I1 y , D M s ke t c h i n c 1 U d e d
`icons to represent single clicking, dou-
`Me clicking, dragging, and so on. But
`this detail i s too lou--level for our pur-
`poses, so we extended DiLlsketch to
`show the major differentiating charac-
`teristics of browsers. U'ith I>Msketch,
`designers can informally specify
`t a browser's inost significant
`g-raphical eleinents,
`
`actions.
`DMsketch is hased on a technique
`from both Scott Hudson and Shamin
`Mohamed's graphical specification of
`layout constraints in the Opus system.'
`Hudson and Mohanied introduced the
`idea of graphically representing ;I con-
`straint on the layout of a user interface.
`They used an arrow to represent the
`presence of a constraint, \vhich is a
`hidden equation. T h e lalrout designer
`views the equation by pointing at the
`constraint arrow.
`EIowever, we believe that equations
`do not convey meaning as clearll- and
`quickly as a few specialized graphics.
`Moreover, equations cannot specify
`that an area in one windoc\. will be
`viewecl in greater detail in another. In
`specifying browsers, we are n o t s o
`much concerned with the details of
`interfiace operation at the keystroke
`level as we are with the relationships
`among windows.
`
`Primitives. Figure 2 shov.s a few
`primitives used in our notation. As we
`describe 1)rowset-s in this article, we
`will add new primitives and define
`composite objects as necessarq..
`t i ~ f o i ~ ? n r . r z t cowsti.nint. 'I'he inore-
`nient-constraint operator in Figure 2a
`specifies that the object at its tail i s
`
`GOOGLE EX. 1038
`Google v. Philips
`
`

`
`Composite obiects. To simplify the
`specification, we defined composite
`objects, gave then1 their own symbol,
`and used them in subsequent specifica-
`tions. F o r example, t h e object in
`Figure 3a specifies a standard coordi-
`n a t i o n b e t w e e n a n overview a n d
`detailed view of fixed sizes, as illustrat-
`ed in F i p r e 3b.
`In defining this composite object,
`we add the convention that unless oth-
`erwise specified all objects presented
`will be of fixed size. In Figure 3b, the
`left window is the source view of some
`image. As indicated by the movement-
`constraint operators, this field of view
`can move both horizontally and verti-
`cally. T h e image it encloses is project-
`ed or, a second window, which has
`scroll bars. T h e horizontal and vertical
`scroll bars are linked to the field of
`view by the movement constraints.
`Thus, moving the field of view will not
`only change the image in the second
`window, it will change the scroll bar
`positions as well. And moving a scroll
`bar will change the position of the field
`of view and modify the projection dis-
`
`T h e contents of the field of view
`movable. If the arrow is horizontal, it
`are projected i n t o a new window,
`is movable in the horizontal direction.
`which is identified by <in arrow that
`If vertical, it is vertically moveable. An
`points from the source field of view
`object without a movement-constraint
`tu the destination window-.
`operator attached is not movcable.
`Figure 2c shows the generic field
`T h e movement of the object at the tail
`of view; F i p r e Zd shows a generic
`is limited to be within the context of
`field of view curistructed by defining
`the object at the head of the arrow.
`+ I’r.oportiona1 size iovlstr-dint. T h e
`two points that represent its corners.
`This rectangle is typically defined by a
`proportional size-constraint-operator
`in Figurc Zh joins two objects by its
`“mouse down, drag, mouse up” oper-
`ation. T h e field of vieM- in Figure 2e
`circle end points. T h e proportional
`is similar to one in Figure I d , except
`size constraint forces the two ioined
`that the point defines the center of
`ohjects to maintain the same relative
`the field of view instead of one cor-
`size, For example, a line whose maxi-
`ner. T h e field-of-view operator in
`inuni length is four might be joined to
`Figure 2f represents a window that is
`a line whose inaxiinuni length is nvo. If
`always the saint‘ size and is defined
`the longer line Is shortened to two, the
`by o n e point. ‘The field o f view in
`srnaller line is automatically shortened
`Figure 2g represents a view with sev-
`to one. This constraint operates h t h
`eral magnifications available, and
`ways, so changing the shorter line
`Figure Zh shou,s a field of view with
`changes the longer as well.
`a shape that matches the destination
`T h i s operator is not confined to
`lines; 2 11 objects and ~noveine~it-con-
`window.
`+ Fitred pi-ojtwion. T h e syinbol in
`straint operators may also be joined.
`Figure 2 i shows that the image with-
`Vi% characterize the existence of such
`in the field of Lieu, is projected to a
`bidirectional links hetween user-inter-
`face elements by the concept of tight
`window- that the arrow- points to.
`coupling.
`+ 1:ielrl of viea. T h e field of view
`encloses an area of an irnage and is dis-
`played on the window that contains the
`image. They detine a clipping rectan-
`gle for the image in its underlying rep-
`resentation. This means that irnages
`enclosed by a field of view do not auto-
`matically becoiiie coarser as they are
`magnified. T h i s happens only when ’ Figure 2. DiZlSketch primitives. (A) ;~ovenzent-constra-aint operator; (B) pro-
`poi.tional-size coruti-aint operator; (C tbrougb H) six variations on the field-of-
`the inaxirnurn resolution of the under-
`uieul operator.; (I) .fitted pmjectiorz.
`lying representation is reached.
`
`Figure 3. (A) Composite 0bjec.t for o w recommejzded jtandnni coo?-dination Figure 4. Zoom commaizd spec$ca-
`bemwti two fixed-size windows; (B) bnmcer vpecification.
`tzon.
`
`I E E E S O F T W A R E
`
`2 3
`
`GOOGLE EX. 1038
`Google v. Philips
`
`

`
`F i p r e 5. Sivgle-vieu! browser.
`
`played in the second window.
`This is our recommended standard
`coordination for fixed-window. brows-
`ers and its sytnhol (the “S” in 1;igure 3a
`means “standard”). It is used frequently
`in specibing browsers. (Note that if die
`windows were resizeable, the shape of
`the field of view would have to be coil-
`pled to the shape of rhe detailed view.)
`
`Commands. Currently, DXZsketch
`provides only a rudirnentar), way of
`describing commands. As Figure 4
`illustrates, the “before” and “after”
`
`but it is satisfactory onlj. when the
`zooming factor is relatively small or if it ’
`is unnecessaq’ to see the global view.
`For example, if the zooniiiig factor is
`two, you can see a quarter of the image
`a t once, s o there is not much navigation
`required to sec everything. However,
`.,
`if the zooniinc factor is much larcer,
`navigation is tlifficult. Imagine looking
`at a map that details all of Europe at
`street level. \\‘ith this technique, it
`coulcl take you some time to realize that
`the view j OLI are sccing is Brussels,
`when what you reall! w;intcd was to
`
`Figure 6c adds additional levels of mag-
`nification.
`Of course the first two methods can
`be combined (global viea., zoom,
`replace, scroll, as in Aldus PageAlaker;
`or scroll, with option to zooni out to
`global view o r in to inore detail, as in
`MacPaint).
`
`Single coordinated pair (overview-detail).
`Many ZD browsers are vari;itions on
`our standard coordinated pair. These
`hrowsers c o m b i n e displa!.s of t h e
`overview and a local magnified \iea..
`T h e most c o m m o n screen layout,
`shown in Figure 721, reserves a small
`part of the screen for the glot)al view.,
`but others use windows of equal size,
`shown in Figure 7b, o r reserve the
`large part of the screen for the global
`view, as shown in Figure 7c.
`
`Tiled multilevel browser. ’These brows-
`ers combine global, intermediate, and
`detailed views, as the specification in
`Figure Xa shows. T h e glohal view is
`related to the intermediate 1 iew using
`our standard coordin;ition, as is the
`in te rin e d i a t c t o the d e t a i I e d view .
`Figure 8b shows a sample application.
`In this technique, moving the glohal
`view o r scrolling the intermediate view
`updates both views. Siniilx-l!.. scrollins
`the intermediate view or the detailed
`view updates hoth.
`
`Free zoom and multiple overlap. This is
`
`24
`
`M A R C H 1 9 9 5
`
`GOOGLE EX. 1038
`Google v. Philips
`
`

`
`a coimiion design for applications run-
`n i n g o n fast platforms with large
`screens. Figure 0 shows the specifica-
`tion. Users are free (hut required) to
`specify, niove, reshape and delete every
`window as they wish. Any side-by-side
`comparison is possible.
`T h e overview of the entire image is
`always presented first. T h e user must
`mark an area in the current view (top
`frame) and the t~oundaries for ;I new
`window (hottorn frame). 'The system
`then creates the window and twoiects F i p r e 6. Threv iw,iations of zoom-and-replace. (A) Zoom o d y ; (B) zoovi then
`
`~
`
`played plohal view (not shohvn). Re-
`cause there is no coordination between
`the user has two indepcndent
`the vie,,,,
`browser$ a t different magnifications.
`T h i s design is flexible, hut users
`must spend a significant amount of time
`managing the display becausc win-
`dows constantly obscure one another.
`
`Bifocal view browser. A variant of the
`classic ovcrview-detail hrowser is the
`hi fnca 1 h 1-0 ws e r ,' spec i fi ed in I i gu re
`IO. 'l'his hrowser uses a magnifying
`glass mctaphor: It places a moiiit'd
`image on top of the area i n which the
`
`Figure 7. Single cool-dinated pairs. (A) Fmed snznll oz'enwvl; (B) O z w w e a . m d
`detazl oj-eqiial si: e, (C) i2loi'eitble miall detailed i . w ~ j .
`
`
`
`GOOGLE EX. 1038
`Google v. Philips
`
`

`
`Figure 9. Sprcrfiration of zooming in an ovedapped vinilou! brorsrr
`
`.
`
`. .
`
`Figure 10. Bifocal viem OY magnijjhg-glass b1-owser, r i t h (A) awm hidden
`under detail L t i e x aiiil (B) areas visible TO usen.
`
`TASK TAXONOMY
`
`W e have identified five classes of
`tasks users accomplish with image
`browsers. Applications must often pro-
`vide for different types of tasks, but
`usually one task is either performed
`repetitively o r gets first priority
`because of safety requirements.
`
`Image generation. W h e n users draw
`or paint a large image o r diagram,
`their attention is on a sinall part of the
`image but they often need to step back
`to look a t the entire image. W i t h a
`painting program a painter might con-
`centrate on the drawing of a h e , then
`return to view the entire scene. LVith a
`CAD/CLWI program a boat designer
`might spend an hour drawing the bow
`of a boat then check the overall shape
`of the hull. Here units and sizes are
`often important. When a large docu-
`ment is autoniatically digitized by a
`scanner, progress is shown on a view
`of the whole document, but the refin-
`ing work will be done in the few areas
`of the image that need retouching.
`For image generation, an oreniew
`is important, but most of the time is
`spent a t a detail level. Users tend to be
`experts.
`
`Open-ended exploration. A tourist ex-
`plores a remote city by navigating a
`map and accessing information on the
`local attractions. An adventure game
`player moves quickly around an iniagi-
`nary space to become familiar with
`it. In both scenarios, the space is un-
`kntnm to the user, so it's easy to get lost.
`T h e overview of the space being ex-
`plored is not always complete or even
`available because it is explored for the
`first time.
`I n these applications, navigation
`must be fast and the user interface
`quickly mastered.
`
`~
`
`Diagnostic. -hi example of this special
`case of exploration is a pathologist
`who explores a digitized sample of tis-
`sue a t low o r high resolution, o r a
`VLSI circuit specialist exploring a
`-
`
`M A R C H 1 9 9 5
`
`magnified object is located, thereby
`covering the neighboring objects.
`
`Fish-eye view. An interesting exten-
`sion of the bifocal view is the fish-eye
`view,' illustrated in Figures I la and
`1 lb. This browser distorts the magni-
`fied image so that the center of inter-
`est is displayed at high magnification,
`and the rest of the image is progres-
`sively compressed. In this way. it uses
`a single view to show a distorted glob-
`
`~~~
`~~
`
`~
`
`~~~~
`
`~. .-
`-
`
`~
`
`~~
`
`~~~
`
`~~
`
`~
`
`a1 view, so n o morning or scrolling is
`required, but users must specify the
`focus of the magnification. However,
`di5tortion can be sevcre. e5pecially
`with large images
`For example. Figiirt 11 IS a small,
`hierarchically clu5tered telephone net-
`work with four letels of \ulistations
`T h e map in Figure 1111 15 'I fish-eye
`view of San Frdncisco (the 5176: of each
`color-coded a m 15 made proportional
`to the 1980 white male population)
`_ _
`-~
`
`GOOGLE EX. 1038
`Google v. Philips
`
`

`
`Figure 11. Fish-eye view f o ~ (A) network diuLgram;' (B) geographical i-llfomation.
`
`magnified view of a circuit. In these 1 windows can b e c o m e very large.
`Window management is an important
`applications, panning speed and coin-
`issue: an overlapping window can hide
`plete coverage is crucial because users
`important changes in another w-indow.
`spend most of the time panning the
`image and looking for patterns. T h e
`coverage must be complete o r t h e
`other hand, a complete automatic scan 1
`wrong diagnosis can result. O n the
`Figures 12 and 13 present a taxono-
`can also lead to boredoni and errors,
`m y of the points of comparison we
`50 the application must let thc. user
`save iiiinortant location\ for later 1 have identified among image browsers.
`Figure 12 shous presentation aspects,
`re\Tiew. Several browsers might be
`Figure 13 operation aspects. M'e sepa-
`needed to compare cases.
`rated static and dvnaniic Dresentation
`aspects and manual and automated
`operations.
`
`BROWSER TAXONOMY
`
`~
`
`~
`
`L
`
`C
`
`
`
`Navigation. Here users more o r less
`know the environment, h i t need to
`know how to get around. A delivery-
`truck driver uses a geographic infor-
`mation system to get directions. In
`this case, a global view must show the
`current position to provide context
`and point :it the destination. Then the
`relevant information is presented a t
`thc niinim~ini magnification level nec-
`essary to view the route. Zooming and
`panning occur onll. occaknally.
`
`~
`
`Monitoring. Here users must keep an
`eve on ever1,thinq and always have
`information . s t a t i o n tlie entire sys-
`ten1 they are nionitoring. Examples
`include the nianaqement o f a large
`network, the central monitoring of the
`securit), or temperature of a large set
`of buildings, and the monitoring of a
`production plant. I\'licn a pro bleni
`occurs, the user must be ahle to allo-
`cate soine attention to loc-'il aspects while
`still \arching the oven iew. Multiple
`views c:in he associated with a gi\,en
`problem that should be globall) saved
`o r retriewd, tiecause the nuinher of
`
`~~
`
`~
`
`~
`
`~
`
`~~~
`
`~~
`
`~~~~~~
`~~~
`
`-
`
`~~~~
`
`~
`
`I E E E S O F T W G F E
`
`that fits on the screen; they are inap-
`propriate when users must compare
`several distant parts of an image.
`W e identified three variations of
`the single-view browser:
`+ Detail-only: Does not support
`zooming, only panning. T h e default
`for most windowing systems if the
`image is larger than the window, but
`seems to work well only when the
`entire image is not much larger (niag-
`nification< of tour o r less)-than t i e
`\ l e u . These are common for image
`generation because most work is done
`at the detail level. They are not appro-
`priate for monitoring.
`+ Zoow-om-replure: More appropri-
`ate as the difference in size between
`the entire image and the detailed view
`i ncre a se s an d n avi ga t i o n be c o in e s
`more difficult. Some do not offer pan-
`ning, which can be annoying because
`users must zoom out and
`zooni in to adjust the de-
`tailed view. Some zoom-
`and-replace browsers do
`n o t update the hidden
`overview as the detailed
`view is panned, which
`causes confusion when
`zooming out. This large
`family of browsers is
`a p p r o p r i a t e for image
`generation anti tliagnos-
`tics if the display-update
`speed is sufficient.
`+ Fzd-<ye: Gives detail and context
`in a single view but severely distorts
`the image and requires constant reori-
`entation. Distortion is a severe prob-
`lem in applications in which size and
`g e o m e t r y a r e i m p o r t a n t . T h e s e
`
`Static presentation. Under this catego-
`ry, we classified single- and multiple-
`view techniques, but hybrid browsers
`are common. For example, a global
`view can be provided along a second
`window that functions as
`a zoom-and-replace, the
`field ofview ofihe global
`view always providing
`feedback about the size
`and
`location of
`t h e
`m o m e d area. Another
`nice hybrid is the free
`overlapping of niultiple
`chained pairs of coordi-
`nated views.
`
`I
`I ASPECTS.
`
`OUR BROWSER
`TAXONOMY
`SEPARATES
`AND DYNAMIC
`PRESENTATION
`
`browsers.
`Single-view
`These browsers dedicate all the screen
`space to a single view. They are very
`efficient when panning is limited and
`are the most commonly used browsers
`when display space is scarce. Ap-
`propriate when the task requires users
`to concentrate on the part of an image
`
`.
`
`~
`
`..
`
`~
`
`GOOGLE EX. 1038
`Google v. Philips
`
`

`
`~
`
`~
`
`Figzcre 12. Browser- tnmnonzy fbi- pr-eseiztntioii asprsts.
`brou.sers seem more appropriiite for I and context simultaneously, when fish-
`eye distortion is not appropriate, when
`viewing atistract representations such
`view can he tailored for a user or a task ! parison, or when the display speed is
`as network diagrams, in which the
`parallel \.iewing. is required for coni-
`!,ut does n o t c h a n g e constantly. 1
`insufficient to allow continuous zoom-
`Although transformations are complex 1
`ing and panning.
`M'c identified three important con-
`and coinputationally demanding,'
`siderations when designing niultiple-
`these hrowsers can he very effective
`view browsers.
`(for hierarchically clustered networks,'
`+ If i'/irlo~-plircem~71t strutegy; T o o
`for ex;i in p 1 e). D e s i g n e r s s h o u I d
`often, designers rely on window man-
`remeintier that fish-eye views can he
`inappropriate u.hen fidelity to stan- ' agers to handlc the overlapping and
`dard layout is i i n p r t m t . '[he map in i resizing o f windows. .\Ithough it is
`F i p r c I Ib, for example, was rciected
`easier to inipleinent a multiple-view
`tirowser without a window-i,lacement
`by epitlemiologists because they could
`not compare it with the inany other , strateE!, bve believe such 1)rowsers are
`maps they are trained to tneniorize I more difficult t o use. Research has
`(such as maps of diseases).
`i shown that managing the overlapping
`Three techniques modify the fish-
`u.indows can take considerable effort
`and tiine for the users. '"' \Ire tielieve
`e1.e t-iew: graphical distortion of the
`designers should proviclu an automatic
`image, filtering to remove una.anted
`objects from the focus, and abstraction , window-iiiana~ement strategy t h a t
`to replace blocks with symbols. Fish-
`limits the need t o niove and resize
`eye vi ew s re sen1 bl e domain -s peci fic w i t i d 0 W S i n ce s 5 a n t I !,. Pl a 11 y si ni p 1 e
`strategies (like the classic overview-
`layout programs because the!, allow
`detail pair ) are available; researchers
`interactively generated custwn layouts.
`are investigating more cornplex strate-
`gies.' ' T h e ~iiore elahorate strategies
`are likely to be task-dcpentlent, and
`designers would txmcfit from research
`
`~
`
`~
`
`Multiple-view browsers. These browsers
`displa), several views. They- arc used
`when it is important to view details
`
`into guidelines and tools for the speci-
`fying a n d customizing of U indow-
`management strategies.
`For now, the standard ovcr\.iew-
`detail pair described in Figure 3 is easy
`t o implement and addresses many
`users' needs. M'e recommend it for all
`tasks. The paired views should have
`the same shape (hoot-shaped in Figure
`i a ; rectangular in Figure ib).
`W e compare systems using this
`technique by the ratio of the screen
`space devoted t o the overview and
`detailed views (the SSROD -- screen
`space ratio: overview, detail.). T h i s
`ratio should be a function of the task.
`For example, drauiing or open-ended
`exploration requires a large detailed
`large
`view, m o n i t o r i n g requires :I
`ove rvi e U', n a vi g a ti o ti r c q u i re s a n
`overview and a detailed view of similar
`size, and an application that includes
`different tasks requires an adjustable
`ratio.
`In addition to the SSROD, these
`systems can he compared according to
`view layout. Tiling windows frees the
`user f r o m m a n a g i n g t h e t iews.
`O v e r l a p p i n g windows g i v e s in o r e
`flexibility hut forces the user t o d o
`
`2 8
`
`M A R C H 1 9 9 5
`
`GOOGLE EX. 1038
`Google v. Philips
`
`

`
`~'
`
`~
`
`1
`
`ple rectangle). Explosion is regularly
`I
`used for hierarchical o r hierarchically I (
`clustered data s e t s x I t simplifies the
`overview., but it can cause disorienta-
`tion because t h e iniage is always
`changing. Il'hen using a n explode
`zoom. designers should consider what
`subset of information appears on the
`overview. 'This is especially important
`for monitoring applications, in which
`alarms s h o u l d b e visible o n t h e
`overview. I n addition to expansion and
`explosion, the zoomed image can he
`distorted, as is the case in fish-eye
`browsers.
`
`'1
`
`I
`
`1
`
`~
`
`II
`
`are the "fly-over" interfaces that are
`m o r e management. S o m e systems
`provide the specification in Figure possible only on fast hardware. At the
`7a: overlapping windows that cannot
`other end are the slow, jumpy updates
`that can be disorienting, if not dizzy-
`he itioved and that block access to part
`of the overlapped inuge (an early ver- 1
`ing. Smooth scrolling plus rapid and
`sion of Publishers Paintbrush, for I continuous zooming are the secrets of
`esample). O f course, designers should 1 success for single-view browsers.
`+ iVatiirt of
`the update: An area that
`avoid this.
`+ C'oovdiii/itii)/i: T h e a m o u n t of ,
`is zoomed can be simply expanded
`coordination between views can be I (similar to the way a caineril zoon1s in)
`o r "exploded" to reveal an internal
`nonexistent (there is no (iverview), uni-
`directional ( m o v i n g t h e overview i structure not apparent in the ovewiew
`updates the detailed view) or hidirec-
`(such as zooming in o n 1 network
`tional (unidirectional, phis scrolling the
`node to reveal the internal structure of
`
`~
`
`~
`
`clctailed view updates the overview). , a node that was represented a s a sini-
`
`\ire I)elieve there are miny opportuni- '
`.~
`ties for 1)eneticial coordination. Indeed,
`our st;iiid;ird overview-detail pair in
`Figire i a includes a hidirectional coor-
`dination: .Voving the field of I iew in
`the o\.enicw updates the detailed view.
`Si in i I ;I r I?, p:i 11 n i ng the de tai I e (1 view
`should update the ovenicw. This is an
`cxaniple of bidirectional tight coupling
`t)et\v-een two views.
`+ (;Iohd :~im~: A glol)al view shows
`t h e e n t i r e information space a n d
`allows quick access to any part. Just as
`11 table of contents is required in print,
`a gIol)al view is requiretl when brow.s-
`ing an image larger than one screen.
`This in e n k can he niade simple and
`attractive for novice users o r f i r pub-
`I i c- a c c e s s i n for ti1 a ti o 11 a J.' s t e 111 s. For
`experts, the g l o l ~ l \.ie\v sho~t1~1 be as
`tletniled as permitted hy the tlisplay.
`Ilense glolial views provide experts
`with direct ;access to details that woiild
`othcru-ise require se\ era1 zooming
`operationa (even if these glohl views
`appear- unreadal)le to others!).
`
`Dynamic aspects. Under this catego-
`F, we classified the srnoothness of the
`screen u p d a t e when t h e image is
`panned o r zoomed, thc tiaturc of the
`update, antl the zooniing factor.
`+ Qiitility a f ' t h r i,pJntc,: A fast,
`stnooth, and continuous imagc update
`niakes navigation and cxploration nat-
`ural antl simple, even over rclatively
`long distances. I t lets users concen-
`tratc on their tasks, n o t on the n a v i p
`tion tool. At one end of this spectrum
`
`Figure 13. Brozxer taxonomy jiv- opwation aspects.
`
`GOOGLE EX. 1038
`Google v. Philips
`
`

`
`Again, designers can combine tech-
`niques. For example, when a user se-
`lects an object for zooming, the neigh-
`borhood around t h e object can be
`expanded and t h e object itself ex-
`ploded to show its interior structure.
`+ Zooming factor: T h e zooming fac-
`tor is the level of magnification bet-
`ween two views. Zooming factors can
`be fixed or specified. Fixed factors are
`set by the designer. This is a delicate
`task that requires designers t o com-
`promise between speed of access to
`details and the preservation of context
`information. No validated guidelines
`exist; designers must rely on usability
`testing with real users and tasks t o
`adjust the zooming factors. For coor-
`dinated pairs, our experience suggests
`that t h e magnification between an
`overview and a detailed view should be
`less than 20. Once the zooming factor
`between screens gets to be more than
`2 0 t o 1, users have difficulty using the
`overview for navigation’’ and perhaps
`intermediate views are called for.
`
`Operation. W e separated manual and
`automated operations. Figure 13 lists
`and classifies all the techniques and
`features we found. Under the manual
`
`operations category, w e classified
`zoom and pan techniques. Under the
`automated operations category, we
`classified saving, navigating, window-
`management, and searching t e c h -
`niques.
`Manual operations. Browsers sup-
`port two principal manual operations,
`zooming and panning. Panning and
`zoom can be readjusted simultaneous-
`ly by redrawing the field of view o r
`adjusting its size, placement, and even
`aspect ratio.
`+ Zooming: Users specify a zoom
`location by the cursor location o r by
`drawing a field of view o n the over-
`view. Fixed-size rectangles specify a
`fixed zooming factor; user-controlled
`variable rectangles specify variable
`zooming. T h e new detailed view can
`be placed either by the user or by the
`system. Zooming out can be implicit
`by undo or it can be explicit, by step
`or by zoom-factor specification.
`I n specifying zooming operations,
`designers must find the appropriate
`compromise between complexity and
`flexibility. Browsers intended for pub-
`lic access or occasional users will ben-
`efit from simple designs (zooms at cur-
`sor location and fixed zooming factor),
`
`while expert users will demand more
`control over zooming. It is unrealistic
`to implement every possibility in a sin-
`gle system. Instead, designers should
`carefully