IPR No.: IPR2016-00500
`Patent No. 7,864,163
`
`EXHIBIT 1008
`
`

`
`Lost in Memories: Interacting With Photo Collections
`On PDAs
`Susumu Harada, Mor Naaman, Yee Jiun Song, †QianYing Wang, Andreas Paepcke
`Stanford University
`{harada, mor, yeejiun, paepcke}@cs.stanford.edu
`
`†wangqy@stanford.edu
`
`
`
`ABSTRACT
`We developed two browsers to support large personal photo
`collections on PDAs. Our first browser is based on a traditional,
`folder-based layout that utilizes either the user’s manually created
`organization structure, or a system-generated structure. Our
`second browser uses a novel interface that is based on a vertical,
`zoomable timeline. This timeline browser does not require users
`to organize their photos, but instead, relies solely on system-
`generated structure. Our system creates a hierarchical structure of
`the user’s photos by applying time-based clustering to identify
`subsets of photos that are likely to be related. In a user
`experiment, we compared users’ searching and browsing
`performance across these browsers, using each user’s own photo
`collection. Photo collection sizes varied between 500 and 3000
`photographs. Our results show that our timeline browser is at least
`as effective for searching and browsing tasks as a traditional
`browser that requires users to manually organize their photos.
`
`Categories and Subject Descriptors
`[Information
`Interfaces and Presentation]: User
`H.5.2
`Interfaces – graphical user
`interfaces,
`input devices and
`strategies, interaction styles.
`
`General Terms
`Algorithms, Management, Measurement, Design, Human Factors.
`
`Keywords
`Handheld devices, mobile computing, pen and tactile input,
`digital photos, photo browser
`
`1. INTRODUCTION
`As digital cameras become increasingly prevalent, large personal
`libraries of digital photographs are becoming more common. Like
`calendars, photographs are most useful when available at a
`moment’s notice. Personal photographs in particular are often
`shown spontaneously during the course of a conversation with
`friends and family. As portable devices with credible processing,
`storage, connectivity and display capabilities emerge, these
`
`Permission to make digital or hard copies of all or part of this work for
`personal or classroom use is granted without fee provided that copies are
`not made or distributed for profit or commercial advantage and that
`copies bear this notice and the full citation on the first page. To copy
`otherwise, or republish, to post on servers or to redistribute to lists,
`requires prior specific permission and/or a fee.
`JCDL’04, June 7–11, 2004, Tucson, Arizona, USA.
`Copyright 2004 ACM 1-58113-832-6/04/0006…$5.00.
`
`
`devices are becoming potential platforms that enable users to have
`their entire digital photo collection available to them at all times.
`Examples of devices that can potentially be used for photo
`browsing include PDAs, cellular phones, and of course, digital
`cameras. In this work, we explore the PDA as a platform for a
`photo browser application, and believe that our results can be
`extended to other similar platforms with little change. We are not
`concerned with the problem of transferring photographs to the
`PDA, but instead focus on the interface issues that arise, assuming
`that all of a user’s photographs are already available on the PDA.
`The instant access requirement presents an interface challenge: it
`is difficult to design a system that allows instantaneous access and
`retrieval of photographs, particularly on a device that has limited
`screen space. This problem is exacerbated by users’ increasing
`capacity to create digital photographs, which results in rapidly
`growing photo collections.
`Interacting with photo collections on a small device presents an
`additional problem. Most approaches to compensating for the lack
`of screen real estate involve the use of textual metadata, such as
`what the photos depict. However, casual photographers often lack
`the time and inclination to create such textual metadata. Image
`analysis techniques that generate metadata are still immature. In
`addition, the entry of search terms on PDAs is cumbersome at
`best, making the interaction with metadata frustrating.
`It is also inherently difficult for users to manipulate photo
`collections on small devices such as PDAs, making
`it
`unreasonable to expect users to manually organize their photos on
`the device itself. This problem can be tackled either by having
`users pre-organize
`their photographs on a more generous
`platform, most probably their desktop or laptop computer, before
`downloading that information onto their PDAs; an alternative
`approach uses the metadata that digital cameras embed in digital
`photos 1 to automatically induce the structure of the photo
`collection without user intervention. As the size of photo
`collections increases, the second approach will likely prove to be
`the more viable solution to this problem. In this paper, we explore
`one approach towards solving this problem of browsing and
`searching through large collections of personal photographs on a
`small screen.
`We limit ourselves to personal photo libraries; that is, all images
`that were taken or collected by the person who then interacts with
`the images on the PDA. Chronology has been shown to be a very
`
`1 Most current digital cameras embed metadata in image files
`using the Exchangeable Image File Format (EXIF).
`
`
`
`325
`
`Ex_1008: Page 1 of 9
`
`

`
`important factor in users’ interaction with their own photo
`collections [12]. Work in [3][12] confirms that events are users’
`natural way of thinking about their photos.
`In previous work [5], we confirmed that single-photographer
`photo creation time can be related to events by well-known
`mathematical methods, which we summarize below. This work
`uses the time metadata embedded in all digital photographs to
`automatically organize photo collections into events based on
`their inherent time structure.
`While [5] explored the use of photo time as a foundation for
`desktop browsers that arrange and manage photos automatically,
`we report now on our experience with the use of time as an
`organizational principle on PDAs. As is usually the case, even if
`the underlying algorithms transfer in part to the PDA, user
`interfaces need to be re-thought from scratch.
`Time, of course, is not the only, and reportedly not even the most
`powerful memory cue. Stronger memory-to-image associations
`seem to be, in order of power, the factors ‘who’ and ‘where’ [15].
`In addition to time references, visual cues in the form of
`representative photos must also have a pervasive screen presence.
`On these principles, we construct a series of time-informed
`interfaces, the first of which we call the Timeline browser (Figure
`4). Timeline is an interface designed specifically to take
`advantage of the automatically generated time-based organization
`structure. We compared this new interface to a baseline of more
`traditional, folder-based interfaces (see, for example, [9][11]). To
`this end, we pitted the Timeline browser with its automatically
`generated hierarchical structure against a traditional browser
`under two conditions. For the first condition, we had subjects
`operate the traditional browser over their own photo collections as
`they had organized them on their personal computers. For the
`second condition, we replaced the owner’s storage organization
`with one that was created automatically by our algorithm. This
`experiment allows us to test the efficacy of both our automatic
`organization and the time-informed interface. We show that, in
`most cases, a system that uses automatic photo organization can
`perform as well as one that requires users to manually organize
`their photos. In some cases, the former can even outperform the
`latter.
`The rest of the paper is organized as follows: Section 2 describes
`the photo organization algorithm; Section 3 presents the two
`photo browsers; and Section 4 describes the goals and design of
`our experiment. Section 5 presents the results of the experiment,
`and Section 6 discusses and describes the implications of the
`results. Section 7 provides an overview of related work. We
`conclude and present future work in Section 8.
`
`2. CLUSTERING ALGORITHM
`The clustering algorithm we use in this paper was originally
`presented in [5] and was slightly modified for this paper to adapt
`to the constraints of a PDA. We include a brief summary of the
`algorithm here for completeness; for details, please refer to [5].
`The clustering algorithm is based on the observation that
`photographs are taken in bursts. For example, one person’s photo-
`taking activities during a three-month period may exhibit the
`following pattern. She first takes pictures during a one-week trip
`to California. This is then followed by five days when no pictures
`
`are taken. That period of inactivity is followed by a flurry of
`photos during her daughter’s birthday.
`The clustering algorithm would partition the resulting collection
`into two clusters, A and B. Cluster A would contain the trip
`photos, and cluster B would comprise the birthday shots. Within
`each cluster, picture taking will usually again be lumpy, this time
`at a finer time granularity than trip and birthday. The algorithm
`will therefore recursively decompose A and B into smaller
`clusters. The California trip might be partitioned into three sub-
`clusters that include, respectively, images taken on a one day visit
`to San Francisco, a series of photos shot during a three-day road
`trip, and photos of the last day’s travel home. All this clustering is
`based purely on the time when images were taken, not on image
`recognition.
`More technically, the initial clusters are created by detecting gaps
`of more than 24 hours between two consecutive photos. The
`intuition behind this first pass is that picture-taking events are
`usually more than 24 hours apart from each other. Then, the
`photos in each cluster are examined further to detect outliers -
`time gaps between two consecutive photos that are considerably
`larger than the average. When such an outlier is found, the cluster
`is divided further at the detected time gap. This process is applied
`recursively for each cluster until each cluster holds less than 30
`photos and spans
`less
`than eight hours. Thirty
`is, not
`coincidentally, the number of thumbnails we can fit on one PDA
`screen.
`Of course, this algorithm is based on heuristics and is not perfect.
`If the birthday event took place immediately upon the return from
`California, the two will fall into the same high-level cluster.
`However, in most cases the clustering algorithm will detect these
`as distinct events when analyzing the cluster during the next step
`of the algorithm. In fact, often times the algorithm will actually
`split events more than necessary; it is possible, for example, that
`the algorithm will split the different days of the California trip
`into completely distinct events (i.e. resulting in four high-level
`events: the San Francisco visit, the road trip, the travel home, and
`the birthday).
`
`3. BROWSERS
`As mentioned above, we implemented two browser interfaces: the
`traditional Baseline browser, and a novel Timeline browser (TL).
`The Baseline browser was implemented in two variants, which we
`call Baseline Manual (BM) and Baseline Automatic (BA). We
`designed the interaction using three views that correspond to three
`main phases of search. This three-view framework is often used in
`search and browsing interfaces [2][16]: an opening game during
`which the user navigates to the general vicinity of the target photo,
`a middle game where the search is narrowed, and an end game
`where users examine an individual photo.
`3.1 The Baseline Browser
`The Baseline browsers are designed in a fashion similar to folder-
`based photo browsers available today for the PDA [9][11]. BM
`(Baseline Manual) is based on the user’s own organization, while
`BA (Baseline Automatic) is based on a system-generated
`organization. We present the BM interface briefly, and then
`describe the difference in photo organization between BM and
`BA, and its effect on the interface.
`
`326
`
`Ex_1008: Page 2 of 9
`
`

`
`Figure 3. End-game ("Preview") screen
`Figure 2. Middle-game screen for the
`Figure 1. Opening-game screen for
`the Baseline Manual browser
`Baseline Manual browser
`for the Baseline browsers
`opposed to BM in which photos may appear at any level.
`The opening game for BM, shown in Figure 1, lists all folders and
`Therefore, we have a distinct opening game where users only
`photos under the current folder. Instead of showing a folder icon,
`choose between subfolders to drill down into. When there are no
`each folder is represented as a button control (the first three rows
`further subfolders (middle game), users see a grid of photos in the
`in Figure 1), each consisting of three sample photos, the name of
`current folder. The second difference between BA and BM is
`the folder, number of subfolders (if any), and the total number of
`BM’s lack of folder names in the opening game. Instead we show
`photos contained in this folder. Tapping on a folder will drill
`the time span of the folder (the times when the first and last
`down into it, showing its subfolders and photos in the same
`photos in the folder were taken).
`fashion. Below the rows of the folders, we display a grid of
`thumbnails of all photos within the current folder.
`For an illustrative example, we revisit the running example of the
`California trip. In the BA opening screen, the user will see two
`At all times, the top of the screen displays a series of red
`“folders” – one corresponds to the California trip, and the other to
`arrowheads to indicate how deep the current folder is situated in
`the birthday event. Each is identified by the time span, the
`the hierarchy. The ‘back’ and ‘home’ buttons carry the usual
`beginning and end of the event. When the user clicks on the folder
`meaning of climbing one level up and returning to the top of the
`corresponding to the California trip, she drills down the hierarchy
`hierarchy respectively.
`– now the screen will show three folders corresponding to the
`In the BM browser, the middle game is just a special case of the
`three California sub-events. Clicking on one of the sub-events,
`opening game, where there are no more subfolders in the current
`say the San Francisco visit, may take the user to the middle game
`folder. As shown in Figure 2, only the grid of thumbnails is
`with all the photos taken during this San Francisco visit.
`shown. The user can scroll down the grid if it spans more than one
`screen.
`3.2 The Timeline Browser
`At any point, tapping on one of the photos in the grid will take the
`The Timeline browser (TL) presents an innovative photo-
`user into the end game (Figure 3). In this screen (‘preview
`browsing interface that relies heavily on the system-generated
`screen’), the selected photo is enlarged. Four other photos appear
`hierarchical organization described above. As in the BA browser,
`in a row at the top. These are the next and previous two photos,
`the system-generated structure is pre-computed, before being
`included for context and quicker navigation. Tapping any of the
`downloaded to the PDA. There are three main concepts behind
`four replaces the enlarged photo with an enlargement of the
`the Timeline design. First, we enhance the role of time in
`tapped photo. The context changes accordingly. Tapping on the
`browsing the collection by providing the user with maximal time
`enlarged photo causes that photo to fill the entire screen. Another
`context. Second, we reduce the number of photos shown on the
`tap will return the user to the ‘preview screen’.
`screen, using the additional screen space to provide enhanced
`time orientation instead. Third, we do not overload the screen,
`Baseline Automatic (BA) is a variation on BM that uses the
`deliberately preserving as much negative space as we can. Again,
`system-generated structure instead of the user’s own photo
`we hope this allows the user to focus on the time context and the
`organization. Note that the system-generated structure is pre-
`few photos as clues. At least one study [12] concludes that on
`computed using the clustering algorithm described in the previous
`desktops, browsers should display as many thumbnails as possible.
`section, rather than generated on the fly. There are a few
`We depart from this advice in our PDA browser on the basis of
`differences between the BA and BM browsers. First, in BA the
`page layout principles that warn of clutter. Our sense is that
`photos appear only in the lowest level of the hierarchy, as
`
`327
`
`Ex_1008: Page 3 of 9
`
`

`
`Figure 6. Middle-game ("Thumbnail")
`Figure 5. Four-month-view of the
`Figure 4. Year-view of the Timeline
`browser
`Timeline browser
`screen for the Timeline browser
`adjacent albums that fall into this time range, only the former are
`clutter is at least as detracting on a small screen as, for example,
`highlighted while the latter are not. Another way to display a finer
`on print media.
`grained time range is to drag the stylus on the timeline to select
`The opening game for the Timeline browser is shown in Figure 4.
`the desired time range. The selected time range will expand to fill
`The screen is partitioned into three columns. In the middle is a
`the screen, showing in more detail the albums contained in it. For
`vertical timeline, and both to the right and left of the timeline is
`example, dragging the stylus over the April to July period of
`one column of pictures. Each picture represents a system-
`Figure 4 will bring the browser to a state shown in Figure 5.
`generated cluster (“album”). The time range that an album covers
`We also implemented a way to quickly “peek” into the photos in
`is shown next to the picture. You also see how many photos are in
`an album during the opening game. The user can hold the stylus
`the album. For a quick overview there is also a row of dots - the
`on a photo, and then start circling the stylus around the photo.
`more dots, the more pictures are in the album.
`This allows the user to flip in place through all the photos in that
`The timeline in Figure 4 spans one year. At any screen, we
`album. Users can circle forwards or backwards, by moving the
`display the time range that is covered by this screen at the top.
`stylus in a clockwise or counterclockwise direction.
`There are never more than 10 albums shown on the screen. If the
`Eventually, the user navigates and taps on a leaf album that
`clustering algorithm generates more than 10 albums, we merge
`contains just photos. Hopefully, she had done so when getting
`the closest ones until we have 10 albums. Again, keeping a
`very close to the photo she was searching for. This final tap takes
`limited number of clusters is geared towards maximizing the time
`the application into the middle game. In the middle game (Figure
`context, trading it off with narrower representation of albums and
`6), the user is presented with a grid of thumbnails. The thumbnails
`photos on the screen.
`of the tapped album are aligned on the top, and are highlighted.
`Back to our running example, now the California and the birthday
`From this point, the user can navigate back and forth (using the
`event may be merged, in the opening game, to one cluster. Say
`arrow icons at the bottom of the screen) through thumbnails of her
`this event is represented on the screen using a photo from
`entire collection, ordered by time. To aid in the navigation, dates
`California. Hopefully, the time context will be strong enough to
`are displayed above the thumbnails wherever the date changes.
`remind the user that this is where she has to look for her birthday
`The range of dates represented on the screen appears on the top of
`pictures. The user memory cues are both the calendar data, and
`the screen; the current position within the entire collection
`the proximity to the California event.
`appears on the bottom.
`A white line runs from each album to the timeline. The point at
`There is also a shortcut that allows the user to switch quickly
`which the line touches the timeline corresponds to the time when
`from the opening game into the middle game. From any level of
`the photos in that album were taken. If there is a thick vertical line
`the hierarchy in the opening game, tapping the thumbnail icon
`at the point of their intersection, the height of the vertical line
`(second button from the left on the bottom row of Figure 4 and
`indicates
`the
`time span during which
`the photos
`in
`the
`Figure 5) will take the user to the middle game, showing
`corresponding album were taken. For example, you can easily see
`thumbnails beginning from the start date of the previous screen.
`the top left album in Figure 5 spans the first few days of April.
`We decided not to implement the end game for the Timeline
`Tapping on an album will drill into a finer grained time range: the
`browser as we thought it might not be required. Thus, in the TL
`best range (in integral number of month, weeks or days) this
`middle game, tapping a photo will simply cause it to fill the entire
`album fits in. We are still in the opening game, only now we see
`the lower-level albums inside the tapped album and possibly other
`
`328
`
`Ex_1008: Page 4 of 9
`
`

`
`screen. Tapping again will return the user to the middle game
`view of thumbnails.
`
`4. DESIGN OF EXPERIMENT
`We wanted to test our photo browsers on large personal
`collections of digital photos. Since digital cameras have only
`become popular in the last few years, it was difficult to find
`subjects who had sufficiently large digital photo collections, and
`at the same time felt comfortable about giving us access to them.
`Our clustering algorithm also required that the metadata of the
`digital photos contain valid timestamp information. This made our
`subject search even harder, as this requirement disqualified
`subjects whose collections consisted of scanned images, rather
`than pictures taken with digital cameras, and subjects who had
`processed
`their photos using software which dropped
`the
`timestamp metadata.
`At the end of the subject search process, we were able to recruit
`17 subjects for our experiment, which is possibly the most
`extensive published research study, in terms of subject pool size,
`of photo browsers to date. The most important criterion for
`subject selection was that each subject was required to have a
`sizeable collection of digital photographs. Subject ages ranged
`from 19 to 48, with the highest representation in the 20s. Twelve
`subjects were male, and five were female. One of the photo
`collections comprised 474 photographs, but all others were
`significantly larger. Nine exceeded 1,000 photographs, and the
`largest collection contained 2972 photographs. The average
`collection size was 1,200 images.
`For the experiment, we loaded the subject’s photo collection onto
`a Hewlett-Packard H5500 Pocket PC. The relevant hardware
`specifications for this PDA are 128 MB of RAM, a 400MHz Intel
`XScale processor, and a 240x320/64K-16 bit (65K) color display
`with a viewing area of 57.6mm x 76.8mm (WxH). The operating
`system was Microsoft Windows Mobile 2003. We used a 512MB
`SecureDigital memory card for storing all the photos.
`We reduced all photos to a resolution that fits the PDA screen, so
`photos are not difficult to manage and do not require too much
`unnecessary memory. At 240x320, each photo required about 20
`KB of space, small enough to allow our memory card to store
`more than 25,000 photos. Since the price of memory cards
`continues to drop and their capacity continues to increase, we are
`not concerned (as we mentioned above) with issues of storing or
`transferring the photos onto the PDA, even if the resolution is not
`reduced.
`The thumbnails we generated for the photos were 40 pixels long
`on one edge and about 30 pixels long on the other edge
`(depending on the photo’s original ratio). The large image in the
`Baseline browser Preview Screen (Figure 3) was a 190x143
`rendition that was not stored separately, but instead generated by
`scaling down the full-screen image file.
`Our experiment followed a within-subject design. We exposed
`each subject to three experimental conditions: the Baseline
`browser with
`the subject’s own, manually created photo
`organization (BM); the Baseline browser with the time cluster
`based organization that our system generated automatically (BA);
`and the Timeline browser (TL); also with the system generated
`organization.
`
`Each subject completed two tasks on each browser. The first was
`a Search Task. We showed the subjects one of their own photos
`on a computer monitor and asked them to find that photograph in
`their collection by navigating on the PDA. We set a three-minute
`time limit for this task, and asked subjects to work as efficiently
`as they could.
`In order to minimize experimenter bias during the selection of
`photos for the Search Task, we had a computer randomly select
`the photos from each subject’s collection. The computer presented
`one random photo after another to one of the experimenters. The
`experimenter accepted or rejected each photo based on the
`following criteria: a photo was rejected if (1) the picture was
`taken at the same event as one that had already been chosen, or
`(2) the photo did not display any recognizable context, and the
`subject was therefore not likely to identify it in her collection. All
`other photos were accepted. The study in [10] followed a similar
`procedure and reports positive experience with this approach.
`The second task was a Browsing Task. We asked the subject to
`select ‘good’ pictures for a collage that represented some portion
`of the subject’s life. For example, we asked for pictures that
`would make a collage of the subject’s friends. Other collage
`assignments were family, trips, special events, and scenery. We
`asked subjects to select photos from as broad a time span and set
`of occasions as possible. For this task we imposed a time limit of
`two minutes.
`For each browser we had subjects complete the photo Search Task
`four times, having each subject find a different photo each time.
`We asked subjects to perform the Browsing Task once for each
`browser. The collage target (friends, events, etc.) was different for
`each browser.
`Each time subjects completed both tasks under one of the
`conditions, they were asked to complete a questionnaire. We
`asked questions such as the helpfulness of the photo organization,
`the subject’s degree of satisfaction, the amount of frustration, and
`adequacy of the allowed time. Answers were encoded on a 10-
`point Likert scale.
`Notice that had we simply run subjects through the three
`conditions, BM, BA, and TL, the subjects would have been
`exposed to the Baseline user interface twice, while interacting
`only once with the Timeline interface (recall that BM and BA
`differ only in the organization of the folders, not in their
`interface). To avoid disadvantaging the Timeline interface we had
`subjects perform the Search and Browsing tasks twice on the
`Timeline interface. In addition to the fairness issue, this double
`exposure (TL1 and TL2) allowed us to study learning effects on
`the Timeline
`interface. The
`two exposures were never
`administered in immediate succession. We counterbalanced BM,
`BA, TL1, and TL2 by rotating the order in which successive
`subjects were exposed to these conditions.
`Throughout the experiment we recorded quantitative data, such as
`the amount of time subjects spent in each view of the respective
`browser, the number of view switches they initiated during the
`tasks, and the number of times the subjects made use of special
`features, such as the photo flipping facility. We also recorded the
`completion time for each trial of the Search Task and the number
`of photos collected within the allotted two minutes in the
`Browsing Task.
`
`329
`
`Ex_1008: Page 5 of 9
`
`

`
`Year
`
`Day
`Week
`Month
`Timeline browser levels
`
`Thumbnail
`
`140
`120
`100
`80
`60
`40
`20
`0
`
`Time (sec)
`
`Figure 7: Average time subjects spent in each level of the
`Timeline browser hierarchy
`
`difference between BM and TL. We again see improvement from
`TL1 to TL2. The difference in backtracking between TL2 and BM
`is significant.
`5.2 Subjective Measures
`Subjective measures also revealed familiarity effects from TL1 to
`TL2. The perceived easiness of the search task was higher for
`TL2 than TL1 (highly significant). TL2 and BA drew even for
`‘ease’ of use. No difference was found between TL and BM.
`We asked the subjects to rate how well they knew where to look
`for each picture when they started the search. With BM, subjects
`reported to have known best, at the outset, where the picture was,
`followed by TL2, TL1 and BA. The difference between BM and
`BA was significant, and the difference between TL2 and BA was
`marginally significant (p=0.07).
`For the browsing task, most users felt that their own organization
`(i.e., BM) was more helpful than the system’s organization (TL
`and BA). However, the performance data mentioned above did
`not reflect this perceived helpfulness. And there was no difference
`between the conditions in terms of satisfaction or perceived
`completeness of the browsing task.
`Data from our questionnaires further shows that users did not
`show much preference between the different conditions. None of
`the photo organizations or interfaces was perceived as being more
`‘satisfying’, ‘helpful’, or as enabling a more ‘organized search
`process’, except for the reported preference for BM with the
`browsing task.
`5.3 Usage of Timeline Browser Features
`Figure 7 shows the average total time users spent at each level of
`the Timeline application during the four Search Tasks. For
`example, users spent an average aggregate of 44 seconds in the
`year level (11 seconds per task, 17% of the time). In total, users
`spent an average of 58% of the time in ‘timeline’ view (the
`opening game on its different levels) and the rest (42%) in
`‘thumbnail’ view (the middle game). The numbers were a little
`different for the Browsing Task, where users spent relatively
`more time (48%) in the thumbnail view than during the Search
`Task. The relative times spent in day and year views are similar to
`the Search Task, while the relative times spent in week and month
`view are reduced.
`The subjects used the drag-zoom feature on average 3.8 times
`during TL1, and 2.9 times during TL2. Recall that this feature
`
`5. RESULTS
`In this section, we present the results of our experiments. We first
`list results that concern the speed and performance of the different
`tasks. We then present the users’ subjective evaluation of the
`browsers and the tasks. We conclude this section with statistics
`about the usage of the features of our Timeline browser. Further
`discussion of the results will be presented in Section 6.
`To summarize, the questions the experiment was designed to
`answer were as follows: (1) With a traditional PDA thumbnail
`interface, can an automatic, time-based photo collection analysis
`even approach the effectiveness of an organization that was
`created manually by the collection’s owner? (2) How well can our
`novel Timeline
`interface with
`its underlying automatic
`organization support users in search and browsing tasks? (3) Do
`users of the Timeline interface improve their search and browse
`performance if they use the interface repeatedly?
`Unless explicitly stated, all results in the following section are
`significant at the level of p < 0.05. We use the term ‘highly
`significant’ for results with p < 0.01.
`5.1 Speed Performance
`There was no statistical difference in search performance, i.e. the
`mean time to find a photo in the Search Task, between Baseline
`Manual (BM), Baseline Automatic (BA), and the first Timeline
`exposure (TL1). However, when subjects operated the Timeline
`for the second time (TL2), we observed a significant learning
`effect. The mean search time dropped by 24% when comparing
`TL1 and TL2. This performance gain lifted the Timeline
`significantly beyond both BM and BA. Comparing TL2 with BM
`brought TL2’s search performance
`to a significant 29%
`improvement over BM.
`We also tried to gauge how much the Baseline interface profited
`from learning. For this analysis we separated out the data of nine
`subjects who had first been exposed to BA and then to BM. This
`data thus maximally favored the Baseline interface in tha