6/11/20151 Multiple Windows Strategies CIS 577 Bruce R. Maxim UM-Dearborn

Windows User dialogs are not displayed on paper any more (all terminals are CRT’s) Users are shown a large screen covered with smaller windows containing information or supporting user interaction Designers need to develop a set of strategies to reduce the time the user spends dealing with distracting clutter and extra hand-eye movements 6/11/20152

Windows Systems It was apparent that early designers were happy to let users open as many windows as they wished on the desktop The notion of allowing windows to be assembled into rooms was a first step Both HP-Vue and Sun Solaris offered virtual workspaces with strategies to navigate among clusters of windows several years ago 6/11/20153

Window Components Rectangular screen areas that contain software application output or document files Titles (various poistions) Borders or frames (needed to locate) Scroll bars (various styles) Buttons or icons (need at least one to close) 6/11/20154

Window Actions Open (type command or click on icon) Open, place, and size (use mouse) Close (icon or function key) Resizing Move (mouse or cursor keys) Bring forward or activate (mouse click) 6/11/20155

Challenges Multiple Windows Designs Multiple monitors –Users don’t like gaps Rapid display flipping –Burden on user to remember information location Split screens –Reduced screen real estate for each application Fixed size, space filling, tiled –Reduced screen space for each application Variable size, space filling, tiled –Requires overlapping and surprising auto resize 6/11/20156

Challenges Multiple Windows Designs Variable size, non-space filling, tiled –Blank screen space allowed Piles of tiles –Mouse selection of exposed corners Automatic panning –Some windows forced off top of screen Window zooming –Temporarily enlarging selected window 6/11/20157

Challenges Multiple Windows Designs Arbitrary overlaps –2.5D display to allow mouse selction Cascades –Microsoft windows 6/11/20158

Coordination of Multiple Windows Tasks Synchronized scrolling Hierarchical browsing Direct selection Two dimensional browsing Dependent windows opening Dependent windows closing Save or open windows state 6/11/20159

Image Browsing in Tightly Coupled Windows Vertical and horizontal scroll bars only work for images 3 to 5 times screen size Zoom-in and Zoom-out techniques work better on larger images Keep overview on screen with enlarged subsection Zoom and replace (easy to implement, sometimes users find it disorienting) Fisheye view nice alternative to zoom and replace 6/11/201510

Next 10 slides from Sneiderman and Plaisant 6/11/201511

Windows Design Users need to consult multiple sources rapidly Must minimally disrupt user's task With large displays, eye-head movement and visibility are problems With small displays, windows too small to be effective Need to offer users sufficient information and flexibility to accomplish task, while reducing window housekeeping actions 6/11/201512

Windows Design Windows housekeeping –Distracting clutter, eye-head movement –opening, closing, moving, changing size –time spent manipulating windows instead of on task Can apply direct-manipulation strategy to windows Rooms - a form of window macro that enables users to specify actions on several windows at once 6/11/201513

Coordinating Multiple Windows Designers may break through to the next generation of window managers by developing coordinate windows, in which windows appear, change contents, and close as a direct result of user actions in the task domain Such sequences of actions can be established by designers, or by users with end-user programming tools 6/11/201514

Coordinating Multiple Windows A careful study of user tasks can lead to task- specific coordinations based on sequences of actions Important coordinations: –Synchronized scrolling –Hierarchical browsing –Opening/closing of dependent windows –Saving/opening of window state 6/11/201515

Image Browsing A two-dimensional cousin of hierarchical browsing Works with large images Overview in one window (context), detail in another (focus) Field of view box in the overview Panning in the detail view, changes the field of view box Matched aspect ratios between field of view box and the detail view 6/11/201516

Image Browser Design The design of image browsers should be governed by the users’ tasks, which can be classified as follows: –Image generation –Open-ended exploration –Diagnostics –Navigation –Monitoring 6/11/201517

Copyright © 2005, Pearson Education, Inc. Zoom factors: 5-30 –Larger suggests an intermediate view is needed Semantic zooming Side by side placement, versus fisheye view

Personal Role Manager (PRM) Role-centered design - emphasizes user's tasks rather than documents Docucentric design - focus on user's document 6/11/201519

Personal Role Management A role centered design emphasizes the user tasks rather than the applications and documents –Vision statement –Set of people –Task hierarchy –Schedule –Set of documents 6/11/201520

Personal Role Management Allows for fast switching and resumption of roles Frees user cognitive resources to work on task domain actions rather than interface domain actions Uses screen space efficiently and productively for tasks 6/11/201521

PRM Requirements Support for unified framework Provide visual, spatial layout that matches task Support multiple information access for fast rearrangement of information Allow fast switching and resumption among roles Free user's cognitive resources to work on task- domain actions Use screen space efficiently and productively for tasks 6/11/201522

Slides from Dix 6/11/201523

Elements of windowing systems Device independence –programming the abstract terminal device drivers image models for output and (partially) input pixels PostScript (MacOS X, NextStep) Graphical Kernel System (GKS) Programmers' Hierarchical Interface to Graphics (PHIGS) Resource sharing –achieving simultaneity of user tasks –window system supports independent processes –isolation of individual applications

Roles of a Windowing System

Windowing System Architectures Three possible software architectures –all assume device driver is separate –differ in how multiple application management is implemented Each application manages all processes –everyone worries about synchronization –reduces portability of applications Management role within kernel of operating system –applications tied to operating system Management role as separate application maximum portability

Client-Server Architecture

X Windows Architecture - 1

X Windows Architecture - 2 Pixel imaging model with some pointing mechanism X protocol defines server-client communication separate window manager client enforces policies for input/output: –how to change input focus –tiled vs. overlapping windows –inter-client data transfer