You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

User Analysis

John the Student

John is a college junior currently taking classes in German, political science, and mechanical engineering. He frequently writes lengthy papers, both technical and non-technical, using Pages, Apple's word-processing application. He avoids Microsoft Word because the layout is too cluttered and making formatting changes is very difficult. With Pages, he can edit fonts easily, drag text and images around the document with less confusion, snap images to a grid, and insert multimedia content. However, Pages has its drawbacks too; for example, John manually inserts page numbers in his papers using text boxes because he cannot easily change page number styles from Roman numerals (i, ii, iii...) to Arabic numerals (1, 2, 3...). 

When writing, John usually makes an outline using pen and paper, then types without formatting in Pages. He frequently moves entire sections of his paper around using copy/paste keyboard shortcuts, preferring that to dragging portions of text around the screen. After the writing has been mostly polished, he begins making formatting edits, such as inserting relevant diagrams or marking new sections.

John is most frustrated by the fact that, in long documents, changes to one section of a paper often affect everything else. Moving photos around the page is a particular problem; with current word processors, all images are placed relative to text, not to the location of the page - he wants to put a picture on the page, and make it stay there! When making formatting changes, he also wants to be able to preview the paper in different formats (i.e., in multiple columns, with different spacing, etc.) and pick the best one, rather than making changes and undoing them.

What word processors currently do well:

  • snapping images to a grid
  • changing fonts

How word processors can be improved:

  • previewing formatting changes
  • moving images around the screen easily
  • anchoring images to its position on the page, rather than letting them float or placing them inline with text

Brett the Teacher

The TAs use Google Docs for the sharing features.  They like that they can comment on different parts of the document.  It's nice that they can share whole collections of documents without having to share each one.

One feature they found lacking was citations - it's hard to specify where a bit of information came from without resorting to tooltips, etc.

Embedding video in documents is nice - on Stellar the professor wanted to upload a series of introductory videos - but videos take lots of time to make and so not many users would use them.

In terms of education, there are several kinds of documents involved in teacher-student interactions:

  • presentations
  • prep documents (unseen)
  • handouts
  • assignments
  • instructor to instructor communication

His advice is to watch out for importing and exporting, since it's almost never done right.

If we can make a way to visually edit documents that are as rich and structured as Wikipedia, Brett thinks it would be a big win.

Rishi the Admissions Blogger

Rishi is currently in his first year of graduate school for business.  He is a coxswain in the crew team and also blogs for the Sloan admissions office.  When making posts for the blog, he is frustrated by the difficulty of navigating to the correct page for actually putting in content.  He finds he often has to search his email for esoteric links in order to get to the right place.  He also avoids using pictures altogether because embedding media can make the formatting too difficult to be worth the effort of using media altogether. Some issues with embedding pictures is that resizing them can be extremely difficult, and if the original image size is used, the image often overflows the editor box.

When writing new blog posts, he often finds that what he sees when he writes is not what he gets when he hits the publish button.  He would like “what you see is what you get”, or in other words, that what he sees when he’s editing text is exactly what’s published when he hits the “publish” button.  Another issue he has with formatting the text is that the spacing is often not intuitive.  Creating the correct number of spaces between different sections can often be very difficult and sometimes even require arbitrary control sequences (such as \n).

What blogging word processors currently do well:

  • easy to just write different paragraphs and put down your thoughts into text without any special formatting or using other media

How blogging word processors can be improved:

  • Would like shortcuts and more intuitive sections
  • Would like to be able to embed images easily and meaningfully
  • anchoring images to its position on the page, rather than letting them float or placing them inline with text

Task Analysis

There are three main tasks associated with solving our problem.   They are as follows:

Writing Content

  1. Why is the task being done?
    1. We want the user to be able to know what part of the paper he’s editing.  For instance, MS word and TinyMCE are actually written in XML with some very complicated parsing to display what they see.  We want the user to be able, intuitively, to be able to have different sections (headers, paragraphs) and be able to format these later easily (so all the paragraphs or headers can looks similar)
  2. What does the user need to know before doing the task?
    1.  The user should need to know nothing except what he wants to write.  The interface should be intuitive enough that the sections will make sense without knowledge of how the backend actually works.
  3. Where is the task performed?
    1. We would have some kind of backend in HTML (or something) that would have the different types of sections (paragraph, header, title) and therefore be able to format each type of section later on, so that layouts can be applied easily to the whole document.
  4. What is the environment like?
    1. Ideally the environment would be like any other word processor, but easier to understand how to use the formatting tools at hand.
  5. How often is the task performed?
    1. The task is performed whenever the user needs to create a new document of any kind (e.g. blog, paper, report, presentation).
  6. What are its time or resource constraints?
    1. The resource constraints are whatever the user needs to input, and the time constraints are whatever deadline the user has.
  7. How is the task learned?
    1. The task is learned by having the sections displayed very obviously when inputting content.  We could have different boxes the user might want to type into show up (navigable by shortcuts or tabs, for advanced users) with some kind of nesting structure being provided by indents or boldness of outline (if nesting is relevant to the section involved)
  8. What can go wrong?
    1. It might become something as hard to understand as TinyMCE or Word’s input process if we don’t make the different sections intuitive enough.
  9. Who else is involved in the task?
    1. Only the user should be involved with the task (unless the audience is considered, but that shouldn’t be part of inputting the content)
  • No labels