LoFi-Group:GGiD

From CS160 User Interfaces Fa06

Contents 1 Division of Labor 2 Introduction and Mission Statement 2.1 Introduction 2.2 Mission Statement 3 Prototype description, with sketches and a picture of the entire system 4 Method 4.1 Participants 4.2 Environment 4.3 Tasks 4.4 Procedure 4.5 Test Measures 5 Results 5.1 Queueing Documents 5.2 Sharing Documents 5.3 Outlook & Sparkler Documents 6 Discussion 7 Appendices 7.1 Consent Form 7.2 Demo Script / Instructions / Task Descriptions Given 7.3 Critical Incidents / Raw Process Data 7.3.1 User A 7.3.2 User B 7.3.3 User C 7.3.4 User D 7.4 Images

Division of Labor

Robert: Introduction and Mission Statement, Discussion, Method: Tasks, Method: Test Measures, Appendix
Vijay: Protoype, Appendix
Bryce: Results, Consent Form, Prototype Pictures, Appendix
Simon: Method: Participants, Method: Environment, Method: Procedure, Appendix

Introduction and Mission Statement

Introduction

Our project is a set of tools designed to allow employees who do news aggregation at PR firms to work away from their computers. We provide an extension for Firefox that allows for users to collect articles they would like to print in order to read offline. When they are ready to leave their computer, either to go to lunch, leave for home, or simply take a break from the screen, they print the collected articles out on Anoto paper with our extension. Using the Anoto pen, they make comments and mine data from the article to share with others at the firm the next time they go online.

We decided to implement our idea for this project after our Contextual Inquiry, when we found both that users did not always prefer doing their daily required news reading online, and that other users also would print out articles to read on their commute home. Our experiment, outlined below, allowed users to queue an article, print it, annotate it, and send the article and their comments to their coworkers.

Mission Statement

Our goal is to make employees of PR firms more productive by giving them a more flexible workflow. That is to say, we mean to help these employees work and collaborate effectively with coworkers while away from their computer.

Prototype description, with sketches and a picture of the entire system

For the purposes of the low fidelity prototype testing we named our application NewsToGo.

The interactions that the user makes while using the application take place on five different pages in our prototype. Pages 1 and 2 represent the Firefox browser and Outlook mail client on the user's personal computer. Page 3 is the actual paper interface in our prototype. The prototype is several pages stapled together to represent a lengthy article. The interface developed in our contextual inquiry write-up was duplicated on these pages. Lastly, pages 6 and 7 are prototypes for the two screens that are available through the Firefox plugin. Page 4 is the menu that appears when the user is using the Firefox browser and performs a right-click operation with their mouse. The menu has been altered by the NewsToGo plugin to add a menu item that allows the user to add an article. This functionality is duplicated by a button added to the Firefox toolbar after the "Home" button. After this button is an added button that gives the user access the the plugin interface prototyped by pages 6 and 7.

When the user adds an article to the NewsToGo queue they are asked to confirm the addition and then given a second dialogue box giving feedback that the article has been added. The user has the ability to make sure this second dialogue box is not shown in the future if they find the feedback redundant or unnecessary.

In the user testing the interviewees were asked to interacted with the computer screen prototypes with their finger and when they were interacting with the paper interface they were given the Anoto pen to simulate the feel of interacting with the true paper interface. However, the Anoto pen was not functional and the paper interface is printed on regular paper.

Method

For the actual user testing session, we headed back to Text100, the PR firm that we wished to cater our concept to.

Participants

We were very fortunate to be able to enlist the help of the same volunteers that we had interviewed for the previous assignment (contextual inquiry) several weeks ago. Although there was much less time investment, our familiarity with each other and background gained from the previous meetings definitely made the interface testing much easier and more comfortable for all parties involved. User A,B,C, and D all came back for the interface testing, and we built from where we left off by demoing the pen and delving right into the test session.

Environment

We conducted the tests in one of Text100’s conference rooms. The rooms were glass-enclosed and were composed of one large conference round-table and side counters where we stored our extra supplies. We set up a particular corner of the table for the user to sit, and had the Computer (Rob) sitting straight opposite with all of the interface materials. The Facilitator (Simon) had a seat on the right of the user’s chair, and could both engage the user as well as pull auxiliary supplies from the Computer’s area when necessary. On the user’s left side, we had a Macbook Pro set up with video recording aimed straight at the region of the table where the user’s attention would be focused. With this angle, the camera caught all of the user’s hand movements over our interface, as well as the conversations the user would inspire with the Facilitator. Behind the camera, the two Observers (Bryce and Vijay) sat taking notes and watching the scene intently. Occasionally, when we wanted parts of our interface adjusted or added to on the fly, the Observers would create them during the session.

Tasks

After the Contextual Inquiry, we did some critical thinking on the presentation of our tasks, and we decided to change them somewhat. The tasks themselves are still fundamentally the same, but we changed how they are organized and described in an effort to make things more clear and accurate.

In our Low Fidelity Prototype, our users tested just about every aspect of our system. We ended up doing this as each tasks segways nicely into another. The three main tasks outlined below generalize the specific types of tasks we had users do. Specific tasks are subsections of the general task. Footnotes are denoted as [1]-they reference pictures in the appendix.

• 1. Queueing documents, Managing the Queue, and Printing documents
  • a. Queueing documents (Easy): We had a low-fi version of a Firefox page already at an article the user wanted to queue for this task. We did so because our users already knew how to find news articles online; this was their job. Given that the user had just "found" a news article they wanted to read offline, they would add it to our queue in one of two ways-- they could either click on a "Queue Article" button we had on the Firefox toolbar, or they could right click somewhere on the page and choose to add the current page to the queue this way[1]. We had lofi pop ups for confirmation and contextual menus for each of these tasks. [2,3]
  • b. Managing the Queue (Medium): When the user was ready to print the news articles, they would click a "View Queue" button on the Firefox toolbar, and a new window would show up. Users would select articles by checkboxes, and could eiter remove them [5] (we would put a blank sheet of paper over them) or print them [4].
  • c. Printing documents (Easy): At this point users would just hit the print button. This segways immediately to task #2 and its component parts.
• 2. Annotating news articles with the Anoto pen and paper interface [6]
  • a. Highlighting and annotating (Easy): Here we usually had to tell users how to select different tooltips, at which point they would just start underlining as they always did. As is discussed in detail in other sections, and which caused us to improvise a revision, users tended to ignore our comment box and write comments in the margin or in line.
  • b. Sparkler notes (Hard): Sparkler notes are basically factsheets about a company that employees of the PR firm could use to quickly give figures about a company over the phone. The data for these sheets was aggregated from articles the users read had. At this point it would help to point out that we had a thematic problem of sorts with task #2. Since the task was all done on the Anoto paper, there was no help from tooltips or any contextual hints a computer might normally provide. We especially ran into this problem with this specific task. Most users had their own way of marking figures they wanted to later add to their notes, and since we did not provide a specific guideline except to first change to the "Sparkler" tooltip, we got a variety of results.
  • c. Tagging and marking the article for delivery (Medium) [7, 8]: This task corresponds to our interface on the last page of an article. Users were not told much here, except that the goal was to prepare the article for email delivery. Users would "tag" their article, in this case by writing how they wanted the article tagged on the lines provided. Originally this was to help categorize the articles somehow automatically, but by the end of our testing we found it to be most useful for now as part of our improved auto-generated Subject field for the email to be sent out. In addition to tags, users could write final comments or a summary, and then check either check Send Now (later changed to just "Send"; see Discussion section) or Draft. Send now would send the Anoto annotated article immediately upon docking the pen, if possible. Draft would just save the email as a draft in case they wanted to send it later. If Send Now and Draft were checked, a dialog box would come up when they docked the pen, asking what they wanted to do [8].
• 3. The Outlook interface and compiling Sparkler notes
  • a. Editing the email (Easy) [9]: If users chose to save the email as a draft, we took them to an Outlook window with a lowfi interface for editing the email. Users were already familiar with outlook, so this was a mostly trivial task, but especially helpful in that we got much critique on our proposed look of the email itself (see Results and Discussion).
  • b. Sparkler note editing (Medium) [10,11]: We did not go over this task with users. We have a mockup the interface, but we are still discussing the extent to which this feature is feasible. Meaning, sparkler notes at this point would be saved as images of text and users would have to manually retype them. Our interface, however, basically assumes text recognition of typed text, so that the user would not have to retype it, and could simply manage the compiled notes from our interface. Because of this ambiguity, we excluded this task from our tests.

Procedure

Each test session began with all four of us acting as Greeters to bring the user in, sit her down in her pre-assigned seat, and generally make her feel comfortable while expressing our gratitude for her appearance. The Facilitator would begin the actual session by presenting the consent form, letting the user sign it, and then confirming the confidentiality of the test as well as asking permission to begin the video recording. Once that was out of the way, the Facilitator would continue to explain the purpose behind the testing, going through the routine to make sure the user understood her role and reassuring her that the test was on us and our prototype, not her or her abilities. The Facilitator would give an over-arching view of our project so as to let the user know what she was to be testing, and suggested the user to act naturally and explore the application as she thought proper.

We started the actual test by laying out our prototype of the browser interface where most users would begin the first task of collecting and printing a news article. The Facilitator would explain the new buttons we created on the browser, and then explain the first task we wanted the user to do. Because the task was so straightforward, we did not do a demo in hopes that the user would be able to figure out intuitively how to add an article to a print queue and print it. As we thought, the user (after playing around with our queue interface) would typically be savvy enough to print the queued article effortlessly.

We moved on to the paper interface, which was more complex due to the options we envisioned that the users would want after our Contextual Inquiry. It was here that the user would often get lost and not know what to do; here, it was necessary for the Facilitor to explain each of the buttons on our paper interface in succession, and suggest that the user use each of them as necessary. Similarly, the Facilitator was required to explain some parts of the end-form of the article (where the user would be asked to mark the article with “tags” and send it off to a co-worker); this usually sparked a lot of conversations about how we could improve that part of the form. While the user figured out some parts of the form easily (i.e. the Send To), she was usually confused about the “tags” and wanted more options to fine-tune the message.

Going back to the computer (after “returning to work and docking the pen”), the next step was to review the e-mail that was sent to see how it would look to the recipient (alternatively, it was a look at the draft e-mail that would be saved before sending, if the user so chose it). This part of the test was less interactive, and mostly consisted of a dialogue between the user and the Facilitator (and the other group members, who had little to do during this period) about the e-mail. We learned the most about what the user’s expected in their typical e-mails from these exchanges.

Test Measures

Process Data

• At any point did the user not know why they were doing what they were doing?
  • Interviewee A: Didn't understand the purpose of tagging articles.
  • Interviewee B: No.
  • Interviewee C: Had a hard time getting started; didn't quite get the overall idea when we started.
  • Interviewee D: No.
• Out of order task completion (did user attempt to do a sequential task out of sequence):
  • Interviewee A: Got distracted by the sparkler notes tab when she just needed to be looking at the View Articles tab.
  • Interviewee B: Visited the sparknotes tab early.
  • Interviewee C: None.
  • Interviewee D: Visited the sparknotes tab early.

Bottom-line Data

• Errors made by each user:
  • Interviewee A: 2. Went to the sparkler note tab when trying to print and didn't quite know how to do sparkler notes on the paper.
  • Interviewee B: 3. Went to the sparkler note tab when trying to print and didn't quite know how to do sparkler notes on the paper; didn't use the comment box.
  • Interviewee C: 1. Didn't use the comment box for comments.
  • Interviewee D: 1. Went to the sparkler note tab when trying to print.
• Did they use all the buttons provided?
  • Interviewee A: Yes.
  • Interviewee B: No. Never tried removing articles from the queue.
  • Interviewee C: No. Didn't use the sparkler notes tab and never tried removing articles from the queue.
  • Interviewee D: No. Never tried removing articles from the queue.
• How did they annotate articles?
  • Interviewee A: Underline; starred beginning and ennd of sparkler notes data.
  • Interviewee B: Underline; vertical lines in margin for larger sections.
  • Interviewee C: Underline; circled author's name; starred sparkler notes data.
  • Interviewee D: Underline.
• Task completion time: times for task completion were somewhat muddled by the fact that users would often stop and want to discuss their thoughts on what they were doing and how they were doing it. Additionally, the time taken for the task of reading and annotating was somewhat aribtrary, as we would just have the user annotate the first page (one page was all we needed to observe their annotation habits).

Results

Queueing Documents

Fortunately, the translation from objective to action for queueing and printing documents was a very straightforward task for the participants. This ease is grounded in our integration of our solution into current tools such as firefox. While there are some issues to be worked out, such as software incompatibilities with firefox at the test company, the basic idea of utilizing existing tools and preconceived concepts appears to be effective. The button interface proved to be very intuitive for most of the users with the exception of one participant, who was unsure whether it was necessary to highlight text in order for it to be included in the printout. Eventually, we pinpointed the confusion over if one had to navigate to a printer friendly version of the page before selecting it to print, in order to avoid ads and odd formatting. Most of the issues at the article selection stage were mostly cosmetic, such as confirmation windows. Many of the participants commented how this extra window was tedious; interestingly, they did not find the confirmation windows generated from the email portion of the solution to be tedious in the last task. Despite being informed on the enhanced option, none of the participants tried the right click option. Therefore development of this extra functionality may be unnecessary. More substantial confusion arose over "View Queue" window, where the tab for sparkler notes distracted the participants. One participant's suggestion to move the sparkler notes into a separate application is a valid solution, as the web browser analogy for gathering sources of information does not fit for post processed data such as sparkler notes. However,once refocused on the printing task and window, the participants intuitively located the print button without prior instruction.

Sharing Documents

As anticipated, the paper portion of this solution showed the most need for improvement. Based on our contextual inquiry, we had implemented features based around the individual ideas. As a result, there were features which were highly personalized around an individual response or were based off of false assumptions. A clear example of this issue can be seen in the quoting capability. When presented with the option, the participants informed us that quoting was synonymous with the sparkler functionality, a close connection which was not made during the contextual inquiries. The system also ran into issues when users selected the highlighting capability due to the different usages of pens and highlighters. Individuals were unsure whether they should draw lines through or under the text they wished to highlight. Additionally, there were numerous styles for highlighting we had not accounted for, such as drawing vertical lines next to paragraphs to signify highlighting the entire area. Concerning the comments operation, the section at the bottom of the page was not an intuitive location to write commentary. The participants saw this area as a summary section of the entire page, which was not a desired functionality. Discussing this issue further, we later revealed that users needed comment space on a paragraph basis. Therefore, we modified our printouts some of the experiments to include spaces in the page's vertical page margins. Also, individuals tried to write comments inline with the printed text, a capability we did not account for. Thus, acceptable comment usage must be conveyed more clearly in future revisions. One of the most critical problems brought out by this study was a lack of an overall comment area. While only some users made comments on individual pages, all participants requested an area which would pertain to the entire document. There were also feature requests, such as an "action item" operation, which would produce a special set of comments related to steps others were to take from this article. Nomenclature was another problem for the printouts. For example, some participants were unaware of the term 'sparkler notes' (which we later discovered was an IBM term) and no one understood the relation of 'tags' to the sparkler notes. Labeling on buttons were also problematic, as users suggested renaming them to fit the true underlying actions, such as "save as draft" instead of "save draft" and "send email" instead of "send email now". In addition, there were numerous requests for more control over the email format. Participants wanted to add custom prefixes to the subject line, along with adding Outlook flags, directly from the paper interface. Lastly, the participants felt export functionality, such saving a document format of the article on the workgroup server, would be another useful addition. Despite these points of improvement, there were also good points about the interface. For example, the pen operation palette was intuitive; the users tapped on areas to switch pen functionality without us teaching them this process.

Outlook & Sparkler Documents

In Outlook, most issues stemmed from the format of the email. The comment layout described to the users did not fit their needs. First, there was too much disconnect, having all the page comments above the text. To solve this, we will explore embedding the comments into the text, which will be even more effective if the granularity increases to a paragraph level. Also, the participants wanted an overall comment section at the top of the page with action items listed below them, both of which are not present in the current iteration. Another issue in Outlook was the storage of drafts. With the number of emails they handled daily, the participants were wary of storing the produced emails in the Drafts folder. While some claimed that a separate application would be best, we are hesitant to pursue this option, since the test users have not easily adopted completely new technology, such as RSS readers. Unfortunately, sparkler documents did not get the attention we had hoped for. This negligence could be partially due to its location in the web browser, as mentioned in the first set of tasks. The users did interact with the system at the queueing stage; however it was out of order and held little significance to them. Additionally, the connection between tags and sparkler notes was not established properly in the paper stage. A few participants mentioned an automatic generation of these documents as a useful feature. Therefore, an automatic, background conversion to actually documents may be a useful alternative to the ill-placed viewer.

Discussion

We learned from our experiment exactly what users liked and disliked of our project so far. It seems that the idea, which we hatched based on our Contextual Inquiry, still resonates with our target group, but we have a lot of work to do on the details after showing them our lofi prototype.

We made lowfi prototypes of nearly every part of our project, including the three we sketched in the Contextual Inquiry. Most users found the process of adding and printing articles to be very intuitive - the only common complaint seemed to be the lack of a "Don't notify/warn me again" checkbox for a certain popup.

However, we had a lot of commentary on the interface where they actually use the Anoto pen. One of the biggest issues was where comments could be written. Everyone wanted to be able to do inline comments, or at least write in the margins. We found users did not like having a per page comment box at the bottom, as they could not get a precise correspondence between their comments and the text they were commenting on. Although making comments in the margins would be easy, implementing some of the more advanced features such as comments in the middle of the article or being able to link comments to a paragraph seems a bit more daunting. A request that was universal among our readers was a summary or general comments box that would show up at the beginning of the email. We will probably convert our "final comments" box at the end into this.

In the Anoto interface we had three buttons that users could tap to get a new "brush" - either a highlighter, a "Sparkler notes" creator, or a badly defined Quote brush. The Quote brush got a lot of criticism, as users said given inline comments, the only thing they would Quote would be data for Sparkler notes. Based on this we will probably get rid of the Quote brush. The highlight brush seemed to work well; single users had feature requests, such as highlighting sections via vertical lines in the margins or being able to make certain words appear bolded as well. If we can work out paragraph parsing for the earlier issue with comment-paragraph linking, perhaps it could also be used to highlight whole paragraphs with a vertical line in the margin. The latter request about bolding was not found to be a universal issue, and it was unclear where the text would eventually be bolded, so this probably won't be implemented. The sparkler notes brush went once users were clear on how to use it - interestingly, in trying to uess, two users tried putting stars around what they thought should be quoted. It would probably be better for consistency if they just underlined everything, but on paper it would then be difficult to differentiate between the two. Obviously this is something we're going to have to think about as we develop higher fidelity versions of our project. Finally, our users requested an "Action Item" feature. An action item may be adding the author of an article to a list of authors to watch, sending the article to a relevant client, etc. We may work on a solution to have metadata for the article (title, author, date) parsed and embedded into the articles used so that action items such as the first one can be realized as a feature. Implementation of more generic action items, such as simply "Read immediately" or "Reply immediately" for urgent or priority articles is discussed in the next paragraph. I think it was lost on our users that they likely wouldn't be queueing up articles marked "Read/reply immediately" to read later on their commute or at home, but at the very least this kind of article classification would be necessary to enable articles read via our project to fit in better in user's inbox with articles they read at work. We are basically using the "plagiarism is good" argument here. To be sure, one type of action item was "low priority read" for generic industry news, which user would be more likely to use with our project.

Finally there was the issue of what to do with the notes when they were ready to be sent. We had a number of syntatical things to change on button or field labels to make them more clear - "Send Now" was changed to "Send" (since the document is not sent immediately when they check said box); "Tags" will be changed to "Company", "Category", or something sligthly more descriptive, as no one was sure what was meant by tags. The subject of the email formed a point of contetion among users. Initially we were just going to have it be "<<Title>>, sent by <<User>>". Pretty much everyone agreed this was too long and not informative enough. In the end, through discussion with users we decided that something like "<<Action Item Priority>>: <<Category>>" would be better. All users told us their decision to read articles in their inbox from coworkers were based on the priority of the article, not the title. To give the users a briefer and more relevant idea of what the article is actually about, we use the categories they tag the article with. A sample subject for an article emailed might now be "Rapid Response: Adobe, Acrobat Reader" which is all the user needs to know. One user suggested that certain action items, such as adding the author to a company database, responding to it, or other actual tasks besides simply reading the article should show up under initial comments in the email as a kind of to do list (either bulleted or with some kind of checkbox for each item). This is a neat idea, but we will have to do some signifcant thinking on how to really implement this. Interestingly, the user didn't seem to mind when we mentioned that the list of action items in the email would really end up being a bulleted list of images with the user's handwriting in them.

There were a few things the experiment could not reveal. Probably the biggest one is some details when users are actually emailing the articles they read. The other two main tasks, queuing/printing articles and reviewing them with the pen, were pretty straightforward to do with a lowfi interface. We didn't really get a chance to see what users do if they send the email as a draft and then start modifying it in Outlook. The suggestion for action items was not too well tested as we thought it better to give each user the same initial design and get their comments for it (we couldn't draw new ones on the fly, and we thought it would be sloppy if we wrote over our original interface too much). Nor did we get to do too much with sparkler notes modification and review; our interface for sparkler note reviewing was somewhat unused because at the time of mak‌ing the lowfi prototype we didn't quite know enough about sparkler notes (specifically what final compiled versions looked like - we have a sample now, but without one it's hard to make an app that helps users make a final compiled version).

Appendices

Consent Form

Image:GGID Consent Form.pdf

Demo Script / Instructions / Task Descriptions Given

Talk given by the Greeters/Facilitator as planned out before the actual testing sessions: Thank you for participating in our prototyping test. Before we begin, I just want to tell you again that everything that we do here and all the information we collect will be held confidential and only for research purposes. There is a consent form that we would like for you to fill out to ease any liabilities on our part. [signs form] Also, we would like to ask your permission to video record your time here, for further reference later on.

Let me tell you what you’re looking at before we begin, and what this is all about.

So, we were here a few weeks ago doing interviews about work flow and how information is moved around at this company. One of the things we noticed was that some people like to or prefer to print out news articles to take home and read, either because of a lack of time at work or just a desire to not read off of a computer screen. The product that we are prototyping today is something we believe may assist some of you if you choose to work with paper copies of your articles.

The mockup you see before you [we begin with a browser] is just the beginning of a system we put together conceptually - it will allow you to collect articles as you find them, print them out at the end of the day, and take the paper copy with you as you leave. Using a special kind of pen, you can actually mark up the copy with your notes, comments, and messages - and then even send that information out to your co-workers if you want to. So, essentially - when you’re away from your computer, you can still be productive! Here in this test session, we just want to get a feel for how you might use such a system, and feedback on how we can design it better. I want to make sure that you know that if you’re ever confused or make a mistake, it’s really not your fault - it’s ours! It’s not you who is being tested - it’s our interface, and we want to know if you find anything hard to use about it.

The way this is going to work generally revolves around a few tasks that we’re going to ask you to do with the system. You’re free to do whatever you want here - you see a browser window in front of you, and you can choose to take whatever actions you normally would. I’ll tell you first off that we’ve added two buttons to the typical browser button lineup - the first one over here will add whatever web page that is currently shown to the list of articles that you’re collecting. The second one next to it will let you review your list and manage or print it. With these in mind, we’ll ask you to do your first task - which is to simply collect the article that you see before you and print it to take home with you, while exploring whatever you want to along the way.

Remember, you can do whatever you want - Rob will be acting as the computer that reacts to your suggestions. You can click, look around, or whatever - just let the computer know what you want!

Task Description 1: Please try to collect the article you see here into your list (or queue) of articles and then print them using our interface.

Segway between tasks: Okay, so now the printer has printed out your stack of articles - here is just one of them. As you can see, there are a lot of things to the page that provide tools for you to use. We’d like you to try to use them as you see fit; do what you would want to do with a paper article, and at the end, we’d like you to attempt to share this article with a co-worker who you think might be interested in this.

Task Description 2: Please mark up the paper copy of the article using the tools provided on the paper. Then use the interface as you see fit to send the article to a co-worker, as if you were wanting to share it.

Segway between tasks: So, [based on whether the user selects Send Now or Save As Draft] we are taken to Outlook back at your computer. You can just look over the resulting e-mail that was sent, and let us know what you think of it. Are there any things you would like to see in the e-mail? Are the locations of things making sense? Can you interpret the e-mail for us?

Task Description 3: Please look over the resulting e-mail in this Outlook interface and tell us what you think.

Critical Incidents / Raw Process Data

Format: [Priority (1-5)] "Comment" [See this picture in Appendix]

User A

• Task 1: Queuing
  • [1] User clicked the back button in the browser; we didn’t have a previous page prepared because we assumed the user already was familiar with the browsing of articles
  • [2] “Oh, sparkler notes - how cool! Although, maybe you could just call it something like “highlights”? The highlights of the article?”
• Task 2: Annotating
  • [4] “So when I make a note, do I make the comments down here? Instead of in the margin?”
  • [3] User wrote a bracket + star to denote a sparkler, whereas we only supported underline
  • [3] “Oh, did I just write with the highlighter?” while in the bottom region
  • [3] User made big circles over the text, whereas we only supported underline
  • [2] “Tag..? What’s that mean?” led to an explanation of how sparklers tied to tags
  • [3] “So, can I write a specific note to them? the Adobe team? I want there to be a first thing/comment they read when they first open the e-mail.”
  • [3] “I have to remember the e-mail address? I wish there was some sort of way for there to be shortcuts or aliases.” - only possible with Outlook ties
  • [4] “I might want a way to undo sending; if I check it and then not realize I really want to send it? How about if there was a cancel button? But then what if you clicked cancel, then the send button?” - a prompt is probably needed at dock-time
• Task 3 - Reviewing the Outlook interface
  • [2] “I’d think I want to add a ‘first impressions’ section. Something at the top of the e-mail to make people want to read it.”
  • [1] “This is really impressive!” - just in reference to our Outlook mockup
  • [4] “Would you use the page specific comments at all?” “Well, if I did, I’d do it in the margins.”
  • [2] “Is Sparkler a widely used term?” “Well, my team calls it ‘fast facts’, and the term really varies by the company account the project is under.”
  • [4] “I’d also like a way to save a a file - perhaps not saving as a draft or sending to an e-mail. I often just save as an article without sending it to anyone.”

User B

• Pre-tasks
  • [4] "(Firefox) messes up my computer every time"
  • "I don't like keeping a lot of windows open" + solution helps alleviate this
• Task 1: Queueing
  • "This is where I go and click (to queue)?" + user knew exactly where to click after brief introduction
  • upon prompting, immediately hit save + dialog boxes were intuitive
  • [2] "you need to have that box that says do not appear again (on the confirmation window) [3]
  • wanting to see what it looks like, hit the "view queue" button without reminder + intuitive interface
  • [3] "I thought my mission was to print the article" (confused about the queue window)
• Task 2: Annotating
  • first instinct to hit the palette area. "all I have to do is underline to highlight?" + intuitive interface
  • writes comments inline with the text (unsupported feature)
  • [4] comments should be formatted like Microsoft Word change tracking
  • [2] "something that could be added would be action items like call this person." (We could capture and aggregate them)
  • [4] would like information to go to another program, because everything gets lost in outlook
  • [1] "don't know if you can do highlighting down the row?"
  • [4-strays from original goal] "is there some way you can do automatic file in outlook contact"
  • [4] "the quote thing and spark thing are the same thing to me"
  • [4] "I think if you quote something it would be something that you would highlight"
  • [5] unsure how to use tags
  • [4] "you should have a converter in the tag to convert to a word document"
  • [4] "would be nice to prioritize (the article response)"
  • [3] "what if I was ready to send it to a device but not really read to send to my coworker?"
  • [1-Save feature not intuitive] "I wouldn't mind using it as a separate thing from email"
  • [4-Should further look into the outlook setup] "It's hard for people to route things"
  • [3] "If it's one of those buttons" [6]
  • [4-Useful feature] "can you convert (the article) to a word doc too?"
  • [4-Useful addition] "you should attach the URL to the document"
  • [5-Confusing button] "you should do save as draft and send instead of send now"
• Task 3: Reviewing the Outlook interface
  • [2] "This is where (the top) it would be good to have the action items
  • [2] "it would be even cooler to have the exclamation mark"
  • [2] "I think that (the title) needs to be worded differently"
  • [2] "tags is something (wording) that we don't use - I would use client or industry"
  • [2] a big star and initials for action items

User C

• Pre-tasks
  • [1] "I would usually just put all the articles into Word and print them.."
• Task 1: Queuing
  • [2-Maybe change "Remove" to "Delete"] "Is there a delete button?" [4]
  • [2] "Can there be an option, to like, not show this again." [3]
• Task 2: Annotating
  • [2-More intuitive name] "Maybe [Sparkler Notes] can be called fastfacts.." [10,11]
  • [4-Will probably add "Action Item" palette] "In terms of action items, if I click on this what happens?"
  • [3-Alias support] "So can I write their name or do I do full email address
• Task 3: Reviewing the Outlook interface
  • [1-Users need their own e-copy of notes] "There's a copy in my sent file right?"
  • [2-Currently not useful at bottom] "So my summary and final comments will appear at the top [of the email]?" [9]
  • [4] "Action items should appear as a bulleted list under the summary... maybe they could have checkmark boxes.."

User D

• Pre-tasks
  • No issues
• Task 1: Queuing
  • No issues
• Task 3: Annotating
  • [2] "I would like to star sentences to highlight."
• Task 3: Reviewing the Outlook interface
  • No issues

Images

1. Right click menu	2. Confirm add dialog	3. Adding articles confirmed with "Don't show again dialog"	4. Document Queue window
5. Removing articles from queue notification	6. Print out ready for annotation	7. Last annotated page with tags and final comments	8.Last annotated page set to be emailed
9. Outlook window layout with preview of message in right pane	10. Sparkler notes window	11. Sparkler notes drop down menu	12. Revised printed annotation page (side comment area added)

---