From CS260 Fall 2011
Jump to: navigation, search

Bjoern's Slides


Extra Materials

Discussant's Materials


Reading Responses

Valkyrie Savage - 10/28/2011 16:17:51

Main idea:

Paper and other physical tools give us records of where they’ve been, what they used to be, and what we’ve done with them. To store that same usage information digitally requires a change in models.


The Hill et al. paper introduces an interesting manner of recording the read and edit history of a document by hijacking the scrollbar. I like how unobtrusive this approach is, and I do think that the problem they are trying to solve is important; we’ve talked at least a couple times in class about how doctors’ offices can’t effectively make the switch to electronic records without losing some of the information that doesn’t go on the forms. Adding more of the physical into the digital seems like a noble pursuit, and one I’d like to see pushed forward.

However, I’m curious what users thought of this. It’s obviously an invasion of privacy of sorts (one might argue that it’s no worse than wear on physical records, particularly since for e.g. edit wear a user’s handwriting is distinct while her typewriting is not, but people are always concerned about their privacy on computer systems far above and beyond concerns in the physical world, in part because of the Internet and its linkage and accessibility for information all across the planet. This is becoming an awfully long parenthetic phrase, but I suppose I’d also like to say that this paper came from an age that was far before the Internet reached its current penetration. So though the Internet was not a specific concern at the time, people have always found reason to distrust putting information into a form where they can’t directly handle or care for it themselves.), and I wonder if it has an effect similar to that of the haptic interfaces: “favorites.” In one of the haptics papers it was discussed how users would “land on certain channels without really knowing why”, and I expect that people would pick up on these scrollbar ticks as cues in the same way. It might be a situation where “the rich get richer”, and sections of document that get edited frequently get edited more and more frequently out of some strange perceptual tic. Although the method is subtle, it isn’t quite so subtle as worn paper. I wish they’d done a study, though admittedly I’ve no idea how they ought to’ve set it up.

The Zoetrope paper was curious. I can see that their use case of Ed looking for a way to get home that isn’t bursting with rush-hour traffic is a good one, but I don’t get what else it could be used for. I mean, isn’t keeping track of things like sports team scores the job of bloggers? Honestly, this system is taking away jobs from GOOD AMERICANS. Haha, just kidding. I don’t really feel that way. But it does seem like the ability to peer back through time on a particular page with this magical lens is a bit silly, in particular because many news websites (which is more or less what they seemed to be testing on) already maintain archives of their information, and it doesn’t seem like such a time suck to type “Toronto Blue Jays” into their search bar to see how they’ve been doing in their last several games. I do think that their process for following text, page images, and HTML structure was quite clever. I just think it might be better applied to something else.

Laura Devendorf - 10/30/2011 10:10:18

Edit Wear and Read Ware discusses methods for collaborative work to occur within single documents through representations of "wear." The Zoetrope paper discusses methods of implementation and visualizations for view changes to webpages over time.

I found the concept of this paper to be really interesting and I particularly enjoyed their somewhat poetic discussion about how wear on an object can encode important information. However, I find wear to be a somewhat negative term since it might imply loss of quality and, had I wrote the paper, probably would have gone with something like traces. I also found their implementation of Read Wear to be problematic in many settings. Calculating the time for reading could be difficult when deadline with mufti-column articles or when you're not just reading but performing multiple tasks (reading on screen, writing notes on paper). With current camera technology, it might be more feasible to track reading times by tracing eye-gaze.

As an idealized concept, Zoetrope, sounds interesting but it seems as though a significant amount of extra work needs to be accomplished to make this ideas a success. So much so that I doubt the research contribution of this paper is especially significant. First, a massive amount of webpage data needs to be collected. Second, the context of the pages and pace at which the content changes could become an issue, the authors do acknowledge this issue. Third, depending on application, the Zoetrope model could be subject to privacy concerns. The information updated on the web is not overtly intended to be back-searchable. Should you choose to hide information about yourself, company or whatever, you should have that right. How does one opt in or out of Zoetrope?

Amanda Ren - 10/30/2011 13:14:30

The Hill paper introduces the idea of computational wear and applying it to document processing, through Edit Wear and Read Wear.

This paper is interesting because the authors realize the importance of physical wear and the stories that physical objects possess through wear. They use that concept to bring about the idea of computational wear. Edit Wear uses the scroll bar to portray information that users might like to know about their document - what were new changes made, and which sections are most edited. It is nice because Edit Wear expands on existing UI, the scroll bar. Although the paper described many benefits that Edit Wear would provide for users - they did not mention any testing with users. Maybe users would find the new scroll bar a distraction. Read Wear also seems interesting too, but less intuitive in the implementation. Although it would be useful in the case where a user can see where the most important parts of an article are, by seeing where other users have spent the most time reading.

The Adar paper presents Zoetrope, a way to look through the ever changing web.

This paper is important because it acknowledges that the web is always changing - yet old information (which may actually be important) is easily lost. Zoetrope is a tool the allows the user to see these changes by narrowing down on a specific part of the webpage, drawing out a lens, and then basically see how that area has changed over time by using a slider. The system also comes with filters and other visualization tools. One issue I am skeptical about is all the data being stored given that some pages constantly change (so their one hour interval for storing would need to be modified) and new pages are constantly being created or destroyed. It would be interesting to note what users would actually use this function for - besides just changing game scores or traffic changes over time.

Alex Chung - 10/30/2011 14:42:09

“Edit Wear and Read Wear”

Anyway, the research pursues the question of how to include tacit information like agendas into digital documents. For example, with regular papers, usage leaves wear on the paper documents such as wrinkles, scribble marks, coffee stains, etc. We certainly don’t to pour coffee on our laptops, so the research explores the inclusion of “Edit Wear” and “Read Wear” through the document’s screen representation.

Positive: Making use of the scrollbar to display the frequency of edits at different locations of the document. If the document is long, then the Edit Wear markers provide a snapshot of the sections where they are most stable or most edited. Instead of having to scroll through the pages (like Microsoft Word) to look for highlights and comments, user can easily navigate to the areas of interest.

Positive: Schoen emphasizes on problem-setting over problem-solving because the more analytical approach would encourage creative problem solution thinking. Framing and reframing a problem from multiple angles give the practitioner more information to come up with the best possible solution and to minimize the number of missteps. Furthermore, it is a win-win situation for the practitioners because they will always learn something new regardless of the outcome.

Negative: Informational physics? Is that an oxymoron? Anyway, the embedded display of Edit Wear and Read Wear might divert too much attention from the new readers. It would not be applicable to documents that require unbiased feedback because of the crowding effect. The authors did not provide enough examples that would require an informational physics for documents. Without a clear value proposition, it is unclear whether we need something like this.

Negative: How valuable is this type of information? When information comes with context, it would become subjective. Thus it would lead to misinterpretation and personal judgment depending on the person. The author did not mention the deliberation process of identifying the stakeholders or their pain points. While the authors employ the OOP paradigm, they assume that writing is purely a procedure process. What happens if the writer decides to cut-and-paste a paragraph from one page to another? There is no account of how to record this type of actions.


Zoetrope is a tool that allows users to thumb through the archival of web pages from past versions through time. It addresses the issue of web pages being limited to the most recent snapshot recorded by the hosting servers.

Positive: Unlike the first paper, this paper develops a persona Ed for the interface design. It allows the designer to anticipate needs and usage.

Positive: It posts an excellent idea of how history of web pages can provide a different level of enrichment in knowledge acquisition.

Negative: Latency issue arises when the interface demands to use Zoetrope to dynamically re-render pages. There are a lot of overheads when transforming data from the database to visual elements for display. Keeping history of changes requires much storage capacity and large bandwidth to deliver content dynamically.

Negative: I’m not certain if the system can scale up. The algorithms mentioned in this paper sounds too simple to be true. There are assumptions that most webpages are XHTML formatted and everything is well formed. Explanation is needed for the indexing formula to organize the history of web pages in database. Relational database might not the best solution for this purpose.

Hanzhong (Ayden) Ye - 10/30/2011 18:11:30

The reading materials for Monday class address several aspects of the topic of history review. The first paper by William C. Hill et al describe two applications that illustrate the idea of computational wear in the domain of document processing. Using a technique called attribute-mapped scroll bars, these wears appears to users as marks mapped onto document scroll bars in positions relative to line positions. By graphically depicting the history of author and reader interactions with documents, their work offer valuable information to guide work. They also discuss how their design accords with a theory of professional work and an informational physics perspective on interface design.

The second paper is a more interesting one to me because I also have experience in designing and developing apps on history retrieval of Web content. The work called Zoetrope is designed and developed upon the notion of ‘The Ephemeral Web’, and gives a constructive solution to enable us to interact with historical Web. Based on a set of operators for manipulating content streams, they developed several useful prototypes such as different kinds of lenses, filters and ways to visualize the changes. I really like their tools designed for visualization because these prototypes have great potential application in web-based service monitoring and analysis process. I also consider this paper to be a very pioneering work in this field and it also gives substantial description in implementation process, helping me learn about the underlying architecture of the system.

Steve Rubin - 10/30/2011 19:25:19

The two papers we read for today featured two different applications that emphasize histories in user interfaces. The first application annotates a text editor with information about commonly read or written segments, and the second provides a framework for querying the history of web sites.

The first paper, "Edit wear and read wear" really needed an evaluation section. Although their application is based in the Theory of Professional Activity, it was unclear to me how useful their interface modification would actually be. For example, if I am working on a document, I might like to know not just which parts had changed recently, but _how_ they had changed. I see a definite advantage to collaborative systems like Google Docs and Wikipedia that allow you to look back in time and see how things have changed. The new interface tweaks may be too intrusive for the minimal amount of information that they reveal.

Histories are difficult to deal with in general because they are not very prevalent in interfaces at the moment. People are not used to dealing with multiple versions of a document--I would guess it takes a significantly increased cognitive load to reason about documents with time as an added dimension. While the first paper seemed to not reveal enough information about the history of the document, the second paper may have revealed too much.

"Zoetrope" is a novel system for querying the history of web pages. Much of the paper focused on the actual implementation, which I don't is unfortunate. Granted, the paper is from UIST, so that's to be expected. I have two primary critiques of this paper. First, their system is powerful but very complicated. It's unclear to me whether the average user would have the patience to learn how to extract the desired historical information from Zoetrope. This goes back to the problem I mentioned above, that people are not used to dealing with histories. It may make sense to persuade users to work with histories in a more limited system (possibly a subset of Zoetrope). For example, rather than learn how to use this system to find traffic during home baseball games, couldn't I just Google it and find the (inevitably) existing forum discussion about the topic?

Second, the paper skirts around the issue of scalability. In order for this system to achieve its maximal utility, it would essentially need to constantly record the internet. As this seems to be too big for even Google to do, Zoetrope may not be able to exist beyond this experimental application.

Hong Wu - 10/30/2011 22:50:52

Main Idea:

The two papers talked about how to make the interface more interactive and more informative for users.


“Edit Wear and Read Wear” described a system which showed the frequency of editing in a side scroll bar. The bar helped the following reader to decide which part is more important and needs more focus. In my opinion, the application is not wide adopted in modern text editors because it distracts users’ attention in most of the cases. However, we can also see a lot of derivation from the paper. In programming IDE such as Eclipse, the editor shows the error or warning on the side bar so that user can track these issues by clicking on the indicated location.

“Zeotrop” extended web pages along time direction. User can observe the previous web pages by a scroll toll. However, it required the web pages to show related content in the specific area all the time. Nowadays, websites tend to change along the time so that the tool is hard to use for general purpose. If the tool capture the content based on html code rather than the display, it may have more application.

The two techniques are helpful to design a richer and more user-friendly interface. More user study may be needed to understand the reflection of the users.

Ali Sinan Koksal - 10/30/2011 23:28:29

This week's first paper explores graphical representations of the history of edits and reads on files by collocating their display with navigation control areas. Examples include visualization of edits and reads of text files on scroll bars, as well as on cells of spreadsheets. Further discussion emphasizes the importance of this kind of "unnamed" information in fostering the task of problem-setting, as well as its advantages in the context of CSCW by offering self-updating artifact which do not require extra user effort.

As was discussed earlier in the context of CSCW, there is great value in integrating these features into existing application in an unobtrusive manner. The augmented scroll bars help setting a useful framework for deciding which problems to address next. I think that problem setting is indeed essential and deserves no less attention than problem solving itself.

As addressed in the work itself, the extensive logging of edit and read actions has implications in security: mechanisms to ensure privacy of individual actions are crucial if history is recorded in such a way.

The second paper proposes a system for adding temporal dimension to web browsing, by periodically crawling websites and providing constructs such as "lenses" that allows one to move a slider to consult earlier versions of a selected region of a webpage. The computational model consists of content streams that can be generated with lenses, constrained with filters, and presented graphically in different ways by visualizers.

My main question about this work is: "how should we select which sites to track regularly for crawling?" It seems to me like either a global crawling system should be centrally available, or an interface to enable users to track which sites should be considered and presented. It is also possible to infer the crawling sources based on usage traces, in a way that will not result in great storage overhead.

Yun Jin - 10/30/2011 23:54:00

The first paper describes two applications that illustrate the idea of computational wear in the domain of document processing. By graphically depicting the history of author and reader inter- actions with documents, these applications offer otherwise unavailable information to guide work. And the paper also discusses how their design accords with a theory of professional work and an informational physics perspective on interface design. The second paper presents Zoetrope, a system that enables interaction with the historical Web (pages, links, and embedded data) that would otherwise be lost to time. Using a number of novel interactions, the temporal Web can be manipulated, queried, and analyzed from the context of familiar pages. Zoetrope is based on a set of operators for manipulating content streams. And it describes these primitives and the associated indexing strategies for handling temporal Web data. They form the basis of Zoetrope and enable the construction of new temporal interactions and visualizations.

Derrick Coetzee - 10/31/2011 0:03:42

Today's readings discussed systems for visualizing the history of a document and how it changed over time.

"Edit wear and read wear", a 1992 work by Hollan et al, described an extension to a text editor that augmented the scrollbar to show how much each portion of the document was edited (or read) in a selected time period. They can simultaneously visualize different categories of wear depending on attributes like the editor/reader identity. Although this particular interface was discarded (except for find interfaces, which use it to indicate where matches are found), in-place visualization of changes in applications like Microsoft Word has become commonplace.

The use of wear as a metaphor - an embedded information byproduct that accumulates without effort - is interesting in itself and extends to many computational histories, like change histories in version control, play counts in iTunes, and Google's "you visited this page on <date>" notice for logged in users in search results. However, effective embedded visualization of this type of data in a way that does not clutter or distract remains a challenge. Hollan et al's scheme, while unobtrusive, also lacked visual cues making it clear what the visualization represented, which is particularly troublesome for a modal interface that can be configured to display several different types of wear.

Hollan et al extol the virtues of artifacts over process as an organization mechanism for CSCW work. In my own experience with Wikipedia, the use of an artifact (articles) to help organize CSCW is highly effective (including such features as associating a discussion page with every artifact), but does not eliminate the need for overarching process to broadly guide collaboration on artifacts.

Zoetrope, a 2008 system built by Adar et al, allows users of web browsers to easily view a page as it existed at a past time. Portions of old pages are viewed through rectangular "filters" with attached slider controls. I really liked the intuitive interface for basic queries, and was especially impressed with visualizations that re-interpreted changes in pages over time, such as charts, animations, and the export feature. I can imagine some features, like bound filters, having utility even without history data.

On the other hand, the system is fragile: they were forced to cache images of rendered pages to support an interactive experience, but this cache is not invalidated properly when the browser, window size, or browser settings such as text size changes. The DOM based schemes used in structural lenses are also fragile, as their study points out - users have little recourse if their query fails other than viewing history of the entire page. Because old versions of pages are stripped of Javascript, they may lack dynamic features or even become impossible to navigate effectively. I don't see a clear solution to these problems.

Zoetrope also did not explore very long-term histories, only looking at about a one-month time frame. Data exists to support browsing, for example, Wikipedia articles over a span of many years. Internet Archive data could also be useful here. I'd like to see what new challenges arise on this timescale.

Peggy Chi - 10/31/2011 0:52:47

Tracking editing history has been an important (but not fully solved?) issue. Hill et a. introduced their designs that presented the history of authoring/editing and reading interactions in a graphical way. Adar et al. designed a system called Zoetrope that enabled users to navigate the history of web content with a "temporal lens."

The wear paper reminds me of how EtherPad (http://etherpad.com/ acquired by Google) succeeds in showing collaborative document editing history with an intuitive interface design. Though tracking history is usually a painful task, it is often important to know the larger pattern or trend, and details of revisions. However, from the Zoetrope paper I sort of doubt how useful it can be to track the content. Do people want to know more about the pattern of higher level information such as topics, user comments, or number of discussions, rather than content revision history?

In addition to visualizing the history data, I'm also interested in more interactive ways using multimedia or animation to explore such information. One good example is from Chevalier et al. (2010) who used transition to show the text history. Personally I often get lost in the traditional "undo" list in Photoshop or MS Word. I'm curious to know if there is any general principle how to present history in different domains.

Reference: Chevalier, F., Dragicevic, P., Bezerianos, A., & Fekete, J.-D. (2010). Using text animated transitions to support navigation in document histories. CHI '10: Proceedings of the 28th international conference on Human factors in computing systems.

Galen Panger - 10/31/2011 1:14:36

I’m intrigued and inspired by the Edit Wear and Read Wear piece. I do love the wear and tear aspect of physical objects, such as recipes which show lots of happy splatters where the recipes have been in heavy use. The scroll bar implementation for the read/write visualization I think is clumsy because it overloads what is a simple interface element and forces the data to fit within the narrow strip of space (this is especially bad on the bar that attempts to show three dimensions of wear over time—way too much). A separate visual indicator would be fine. I could see some really wonderful implementations that attempt to show physical (though, admittedly, fake) wear on blog posts, tweets, or articles that are heavily read and shared online. Some company with a wonderful sense of design could do this; perhaps a company like Square could age its Card Case app so that the cards you use for restaurants you visit most often show some wear.

Edit/Read Wear and the Zoetrope piece share and discuss the problem of archival explosion; this is certainly a problem when histories are recorded in individual files that must be transferred back and forth (witness exploding Word doc file sizes using Tracked Changes), but in a cloud world where storage is nearly infinite and only necessary data is downloaded, these problems go away.

Overall, I didn’t find the Zoetrope concept to be compelling in the Wear context; as its own interface, perhaps it could be helpful for students or history buffs, but as an interface element it must be called up on its own and does not embed any of that history directly in the current webpage. This is what the Wear article does well; the information is embedded in the document, and you can glance at it or not; it’s there to provide meaning but doesn’t require that you actively think of and call up the data so that it can be displayed. The “passive” approach, when done simply and tastefully, I think has more day-to-day advantages.

Yin-Chia Yeh - 10/31/2011 2:01:49

Two papers about history are read. The edit/read wear paper presents a technique of collecting edit/read history statistics and visualizes them by scroll bar. The zoetrope paper presents a system to browse contents of web page temporally and also provides some useful operators such as binding or filtering. For the edit/read wear paper, the first application comes to my mind is source code version control system. Though this idea is really interesting, after a second thought I still cannot figure out how incorporating it will help programmers. The second application is the online document system. It would be beneficial for document writers to know which part of document is read most. One possible issue is some users might download the document and only read their local copy, which the read history will not be recorded. One last application I have in mind is dynamically changing the mouse scroll speed of document according to the read wear so the document tends to stop at most viewed positions. As mentioned in the paper, physical wear could help people browsing documents. It would be interesting to see if this application can improve the usability of digital documents because I really feel reading some kinds of digital document is truly painful as comparing to read physical books. The authors did provide an interesting point of problem setting is more important than problem solving, but I would like to see a real world scenario of how these history statistics could help on problem setting. The demo of zoetrope is pretty impressive. The temporal lens seems to be very smart in capturing the data user really wants to see. Besides browsing temporally, I think the idea of binding different lens and time series visualization is also pretty cool. One question I have in mind is that if this system can scale up. Suppose it is going to be used by public, could some popular websites be paralyzed by the heavy network traffic causing by crawler? One alternative is that the website itself providing this function, but in that case network speed could still prevent real-time feedback.

Donghyuk Jung - 10/31/2011 6:40:07


In this paper, the authors presented a novel way to maintain and exploit object-centered interaction histories. They implemented two types of functionalities on existing editor. Edit Wear and Read Wear represent the document’s authorship and readership history respectively by modifying the document’s screen representation.

I think that it’s good idea displaying useful graphical abstractions of the accrued histories as parts of the objects themselves. Edit Wear and Read Wear can show users accumulated information how many times they edited or read contents without using additional user interfaces.

However, Edit Wear and Read Wear have some critical defects. Their implementation didn’t carry users’ intent. Scroll bars only show quantitative data but users edit or read a certain portion of their work with some purpose. These Wears cannot answer the question “why did they do so?” In terms of transmitting context to others, annotation features that most editing tools support are probably much better than showing historical information.

Zoetrope: Interacting with the Ephemeral Web

Zoetrope is a system that enables interaction with the historical Web (pages, links, and embedded data) that would otherwise be lost to time. It allows people to interactively access and manipulate a historical record of the evolving Web.

I really enjoyed reading this paper because it reminds me what is the real value of historical web contents? Are we missing a lot of valuable information? Although Zoetrope gave me some ideas regarding their implementation, I think they didn’t study much about how general users deal with ephemeral web space.

First of all, they didn’t conduct usability test in detail. Users really concern about past data? I believe that past data only give users sort of statistical information about the content but how many people can utilize it? Web service companies already manage the content types that many people really care about. The financial data such as a stock list is the best example of this. NYSE might invest tremendous amount of money on IT resources in order to keep their historical data as well as transactions. The bulletin boards on the Web including social web services, forums, or blogs also well manage it. If we can easily (time or money) retrieve historical information (generally we care about) from web sites, this tool might loose momentum.

The underlying Zoetrope data is generated by crawling web pages at semi-regular intervals. Additionally, it uses MD5 checksum to check for changes of web contents such as CSS and images files. This series of processing require a huge amount of resources on client side. What if the remote web site changes a significant amount of user interface? Zoetrope depends on DOM structure of a web page when it recognizes some changes on the page. I doubt that Zoetrope keep track of semantic information of a page when UI had been changed.

Jason Toy - 10/31/2011 8:11:53

Edit Wear and Read Wear

This paper is about two applications that graphically depict the history of author and reader interactions with a document.

The system described is similar to the real life examples of svn source control and Google Docs' history feature. In both cases a user can see past changes of other editors. However Google Docs may be similar due to the fact it regularly records history even without being prompted for commits. Schon's idea of professionalism, described in this paper as the rational for this system, prioritizes problem setting and conversations over problem solving. It is similar to the idea of Epistemic actions, actions which make the problem easier to solve rather than directly solving the problem, described in "On Distinguishing Pragmatic from Epistemic Action".

The idea of using a graphical representation to show edits is unique even today, and perhaps a better way of drawing the users' attention to hot spots which have been frequently edited, something that svn logs and Google Docs' history has trouble doing. Another thing the experimenters did well was to build the edit and read systems into a word processor, as per design principles in the paper: "Groupware and Social Dynamics". A less used feature should be built into a frequently used software. Not the other way around. One problem with this paper is the lack of linking the rationale to the end result. If you want to learn about "conversations" editors had about the paper, is that likely to be in the edits they make to the paper? Would they more likely be found in the margins of drafts? How does this system help discover the patterns the paper claims exists in documents? Do users have to sift through the recorded data and interpret it themselves? In addition, the paper is not particularly detailed on the implementation of the system. Given that a user wants to look at recorded data, does he or she end up looking at a snapshot like an svn commit, or some playback through time of what other authors have edited? How does the system display the flow of changes? Finally the paper describes other use cases, but how does this system apply to non-word-documents? Do we really care about edits people make to graphs and diagrams the same way we might be interested in how an essay has evolved over time?

Zoetrope: Interacting with the Ephemeral Web

This paper is about Zoetrope, a system that allows users to view and interact with streams of historical data on the web.

Zoetrope is a new system that allows users to filter out parts of websites they are interested and watch how they evolve over time. The current internet paradigm is perpetually evolving, and for many sites, this means that what you see today will not be what you see tomorrow. There are many ways that this project can affect future design of products. For example, some sites might be interested in integrating such a feature in their site, rather than having to build a historical system themselves. Whether they are interested in directly using such a product or not, a site could better improve its compatibility with Zoetrope by following industry standards such as creating restful sites or ensuring their code is not badly formed. Future research could be done to expand on the idea of Zoetrope and the use of multiple filters at a time. For example, a user could be interested in comparing two different baseball teams on Yahoo instead of just one. They might be interested in seeing how current events affected stock prices of a single company, or an entire industry.

The paper did a good job considering the use of their product: neither google caching nor internet swayback machine create a comprehensive history of a webpage. They also discuss alternatives and assumptions of time. One thing I like about Zoetrope is that the creators allowed for data exporting. This would allow many other products, especially of the visualization type to take advantage of this system. One thing I did not like about the design of Zoetrope was their filter input. All the examples in the paper assumed a normal user, however the filter input was in a format that was similar to a cron job, which few if any non-programmers know about. In terms of execution and usability, I feel that the authors could have done a better job.

Allie - 10/31/2011 8:29:10

In "Edit Wear and Read Wear" by Hill and Hollan examines three perspectives: how they embody an interpretation of Schoen's theory of professional work; how they exemplify an information physics viwe of interface design; and judges a problem-setting by the quality and direction fo the reflective conversation to which it leads. The experimenters find that physical wear in the world considered as an interface often succeeds in the implied surface evaluation scheme. Schoen how they illustrate a computer-supported cooperative work thesis, rather that small group cooperation is better organized by shared artifact than by group process control. From an information physics perspective the same techniques allow us to create virtual worlds that give concrete existence to abstract entities operating under the physics of our choice. which is based on a set of operators for manipulating content streams.

In "Zoestrope: Interacting with the Ephemeral Web" by Adar et al discuss Zoestrope, which provides visual lenses that can be filtered with keyword and other queries to explore correlated historical data. In so doing, it maintains the interactivity of the live webpage. Filtering on time, keyword, amounts, duplicate elimination, compound filters, and trigger filters are conditions used for selection in Zoestrope. Zoestrope eintroduces novel semantics for dealing with temporal web data and shows a sall number of operators that can be utilized for different tasks.

Am curious how Zoestrope compares with archive.org. The Zoestrope paper as a lot more approachable than the Edit Wear/Read Wear paper, which was more theoretical in nature.

Vinson Chuong - 10/31/2011 8:37:15

Hill and Hollan's "Edit Wear and Read Wear" give an example of how a digital workflow can be enriched by incorporating affordances provided by its physical counterpart--in this case, the concept of wear on a physical document. Adar, Dontcheva, Fogarty, and Weld's "Zoetrope: Interacting with the Ephemeral Web" takes this idea of tracking the history of a document to the web by allowing its users to data mine the history of web pages on the fly.

In "Edit Wear and Read Wear", Hill and Hollan compare the digital and physical workflows for the task of document editing and observe that the artifacts produced by the physical workflow have many useful affordances not present in the digital artifacts. In particular, they note that a lot of useful information can be inferred from the amount of wear accumulated on parts of a physical copy. They go on to demonstrate a text-editing interface which tracks the frequency of edits/reads of each line of a document.

In "Zoetrope: Interacting with the Ephemeral Web", Adar, Dontcheva, Fogarty, and Weld demonstrate a system which allows users to execute data mining queries on the history of a web page on the fly. They observe that at any given moment we are only able to see the newest version of web pages and that useful insights can be derived from examining their history. They go on to discuss ways in which histories can be queried and visualized.

Both of these systems seem targeted for general-purpose use, not assuming much about the data given as input. I believe that the usefulness of such history tracking and querying systems is mostly determined by the semantics that can be inferred from the data. For example, in "Edit Wear and Read Wear", the system is limited to tracking lines and characters. What if we're editing a more structured document, say a LaTeX document. Then, what useful insights can we derive about the history of paragraphs, subsections, or sections? Given a web page which strictly adheres to the HTML spec, what kind of inferences can we make? More concretely, given the XML output of some web service, what can we infer from how it changes over time? More specialized systems include Chronicle (in the extra materials) and version control systems like Subversion or Git. Those systems are tailored to handle specific types of data and offer specialized features that are only useful for those types. I'm interested in seeing what kinds of inferences more specialized systems can make.

Shiry Ginosar - 10/31/2011 8:53:29

These two papers deal with capturing the usage histories of artifacts. While Edit Wear and Read Wear focuses on emulating physical-like wear and tear that annotates the artifact and is visible to a passive user, Zoetrope creates an active visualization of the history of webpages activated by a user's choice of a historical lens on a site.

Hill et. al. are correct to point out that in the physical world the wear and tear of objects often provides additional crucial information to users. Such is the case of creases and pencil scribbles on a medical record or paperback books that lend themselves to be open in the most often read page. Their suggested virtual wear is an appealing one and reminds me of the use of tkdiff to look for edits in source code and track changes in a Word document. While the former example only extracts edits from the last snapshot to the previous one, even this shallow information proves extremely valuable when reviewing code. However, as the authors pointed out, their system lacks the ability to highlight character by character information that is crucial for this usage. The latter example allows for incorporating multiple changes from multiple users and has a useful color coding system, but does not provide the useful side bar summary proposed in this paper. Both examples given here do not implement the idea of read wear. After reading this paper I believe that this could actually be a welcomed improvement to text editing software as it would allow collaborators to focus on issues that interested their peers.

The examples above illustrate the benefits of a passive visualization of wear and tear. It would be tedious for a reader of a shared document to query every line in order to check whether it has been recently edited. In a similar manner it is my opinion that the Zoetrope system would be tiring to use. While I agree that the rich history of the web does not lend itself easily to be presented in a passive way, the activity of polling parts of a webpage, while novel at first, would seem like extra work after a while. It may well be that for business analysts or for particular situations where histories are of high importance users would turn to Zoetrope for help, but for casual browsing the interaction on the part of the user seems to be too involved to be justified.

Rohan Nagesh - 10/31/2011 8:55:28

This week's readings focused on maintaining and visualizing histories of usage patterns. The first paper "Edit Wear and Read Wear" discusses visualizing document edit and read history as tick marks/bands on the scrollbar. The second paper describes Zoetrope, a tool to interact with web sites and browse historical versions of the content.

I agree that there are indeed certain situations where usage history is pretty important. For instance, a budget spreadsheet's read history could show which areas of the budget are most concerning for the finance guys. An archive of weather data from the Web would allow analysts to make predictions and better understand weather patterns. Thus, I do agree with the two papers that there is a fundamental need to store and retrieve history.

However, I don't like the visualization of scroll bars with tick marks/bands. I think this is a bit awkward to interpret for certain analyses--like I couldn't instinctively tell which bands corresponded to what attributes. I didn't know what the dark shading vs. light shading signified. I do think the second paper touched on some cooler visualizations, and I would like to see these visualizations transferred to the Edit and Read Wear implementation as well. Visualization is a core piece of history in my opinion. What good is having the history if I can't make sense of it?

Apoorva Sachdev - 10/31/2011 8:56:17

This week’s reading were both based on some sort of data collection applications, in one case we were recording the editing and reading patterns of a document while in another we were recording the past versions of webpages.

The paper “Edit Wear and Read Wear” by William C.Hill and James D.Hollan seems like an interesting application for group (co-authored editing), however, there are a lot of issues that they didn’t deal with. How useful is per line editing over multiple sessions? When people make additions to various parts of the document and all the line placements change (how would that be reflected)? Would this be better than the track changes option on Microsoft word that also provides a visual display of all the edits another person makes and enables people to provide their comments with the edits as well? My other biggest concern was data storage. The paper seems to hope for memory becoming cheaper and more accessible rather than suggesting a solution. Storing data about each line makes the data storage for each document almost 2x – 3x as big as a regular document and I don’t know if this would ever be memory efficient. Additionally, I felt the authors should have probably done some kind of user – study to evaluate their system and actually find out if people were really interested in tracking the read and edit patterns of their documents.

The other paper “Zoetrope: Interacting with Ephemeral Web” allows you to view “a time-stamped” version of web rather than just the latest copy. It is a version of caching but extended over a longer time range and with a lot of additional features like lenses. Again, the biggest concern with this paper is data-storage, storing multiple versions of a page over time (they haven’t defined a horizon for their page storage) despite compressing would still take a lot of space. The system design seems fun and useful in the sense of adding lens and seeing how that information has changes over time. I really like the filters idea to find information in the past that is the most relevant to what you are looking for. A combination of filters and lens would help redefine “searching” the web in a sense. However, how much analysis would have to be done on several webpages to realize how often the data on them changes? For instance in the traffic example, would the website state be stored every hour of the day every day (for how many days?) The mixture of lens and filtering reminds me of another web application “if this than that”, that allows you to define various conditions that need to be satisfied on various sites and if they are the application will inform you in some way.

Sally Ahn - 10/31/2011 9:02:51

In "Edit wear and read wear," Hill et. al. introduce the notion of "computational wear," and tools that add visualization of this information to the interface of Zmacs. In the second paper, the authors present Zoetrope, a tool that allows users access to the "historical Web."

My reaction to the edit wear and read wear visualizations are rather mixed. The notion of computational wear is intriguing, and it reminded me of the drawbacks of digitized medical records that failed to capture the physical properties of doctors' scrawled notes and the tell-tale wear of often-consulted notes. Nevertheless, the scrollbar visualizations presented seem limited. One doubt I have is that it may not be scalable; scrollbars are quite small (and recent trends favor minimizing their size or hiding them all together), and at some point the resolution of data become too small for users to make useful distinctions, especially in the multiple-column view for different categories.

I also had initial doubts about Zoetrope. It seems like both of these papers focus on providing access to as much information as possible, but that can lead to information overload. However, the authors later describe visualization techniques that help to alleviate this overload as well as some scenarios (such as temporal "videos" of changing web page) that do seem well-motivated.