Scenario

Jennifer -- female, attends Brown, majoring in creative writing, likes writing fanfic for Harry Potter, and she’s doing a NaNoWriMo fic with her creative writing group
Troll -- a user who posts offensive comments

Jennifer creates a new project, inviting the rest of her group to be part of it.  Jennifer writes the first section of the fic, and posts it.  Troll reads Jennifer’s section and comments on it, offensively.  Jennifer uses her power as a moderator to delete Troll’s comment. 

Designs

Design 1

Analysis of the design

  • Learnability: The design uses mostly conventional arrangements(ex. sign in/sign out/my account at top right corner, click on site logo to get back to Home screen, the search box, use of familiar widgets) and most important operations are labeled, so users with some web experience would get used to it quickly. Moderator actions could take somewhat longer to get used to, but they are also well labeled so it shouldn't be too bad for people who take the role of moderators.
  • Visibility: When adding to a pre-existing chapter, there's an option to view previous portions in the chapter. Different modes of dealing with a fiction(moderate/contribute/read) are clearly visible from the sidebar and the screen arrangement.
  • Efficiency: This design takes somewhat wizard-like approach for many operations, leading users from one screen to another. While the tasks covered here(creating a new fiction, contributing to one, taking moderator actions) are not done very frequently, some frequent users might feel that the design has too many steps. You have to switch between separate modes for different operations even when you have full permission, and this might decrease the efficiency. The floating sidebar that has the mode switch buttons are supposed to help alleviate this. The sidebar also helps readers switch between different chapters efficiently as well.
  • Error prevention: Irreversible actions like deleting a fiction or deleting a comment call up confirmation dialogues so that there's slim chance of accidentally deleting things.

Overall, the design is familiar, beginner-friendly and provides a lot of guidance to users.

Design 2

  • Main. The top section contains links to recently updated projects. The lower right displays a welcome message and description of the site. The lower left has a search text field and radio buttons for the user to decide which category they want to search in (ie, Author, Title, Fandom, Genre, etc.). The search results replace the recent updates in the upper section if search is clicked. When there are search results in the upper section, there will be a cancel button and a search within results option in the search field as well as the current choices and buttons. Clicking a story title in the Recent Updates section or the search results will take the user to the read page for that project. The large button at the bottom of the screen allows users to log in or register. In the scenario, Jennifer would click this button to log herself in.
  • User Home. The left section of the user page shows all the projects the user has or can contribute to. The right section shows a list of the users favourite stories, and has a button to remove favourite stories from the list. A user can begin to edit one of their projects by clicking on the title in the left side. The large button at the bottom allows the user to create a new story. In the upper left corner is the user's username, so it is clear who is logged in, and in the upper right, there is the expected logout link.
  • Create. The large button at the bottom of the user screen redirects to this page. The user can input the details of the story into the text boxes. For attributes like genre and rating, drop down menus are used, as only one choice is necessary. For authors, moderators and fandoms, since the user may be picking several of a possibly very large number, the user types the user name or fandom into the text field and clicks add button next to it. The already chosen users and fandoms appear below the text box with small, underlined links label remove to delete an author, moderator or fandom added incorrectly. The cancel button in the lower right corner of the upper section causes a confirmation dialogue to appear ("Do you want to cancel this project? Attributes and project will not be saved."). If the user genuinely wishes to cancel the project, clicking through this confirmation will return her or him to the user home page. Jennifer creates her story by filling in the fields and boxes appropriately.
  • Edit. The left panel displays all the text that has already been posted for this story, with a drop-down chapter menu for chaptered stories. The right panel contains a rich text box which allows the user to enter their new section to the end of chapter selected from the "Add to Chapter" menu. At the bottom of the right panel, there is a text/browse box for uploading text files already written on the user's own computer into the rich text box. At the very bottom of this panel is a "Cancel" button, which allows the user to cancel their changes and return to the user home page. As expected, this choice is protected by a confirmation dialogue box. When Jennifer has finished writing her new section, she clicks the large center button to save and post the changes she's made.
  • Read and Comment. The text of the story is displayed in the large center box, with the comment listed down the right margin. Since all comments may not fit in the margin, there is a link to "see more comments". Also in the lower right, there is the chapter selection box (for multi-chapter stories) and a button for the user logged in to add the story to his or her favourites. The left margin contains other useful links, such as return to main page, and search (which returns the user to their most recent search results). The lower left corner has a text field for writing comments (such as the rude one being written their currently). The large button in the middle posts the comment.
  • If a moderator is viewing the read and comment page, the comments have small links below them labeled remove. Clicking such a link displays the comment and confirms that the moderator wants to delete it.
  • Analysis
    • Learnabilibity: On the home and user home pages, it's not necessarily obvious that the titles of stories the user contributes to will be links, as titles are usually underlined in English. Perhaps another affordance for clicking might be better. The nonstandard screen arrangement may make it difficult for new users to locate other necessary buttons and links. Similarly, the diversity of text and non-text fields may be confusing. However, the button for performing the most common action is prominently displayed, and there are various clues and links for backing out of accidental actions. The interface is internally consistent with respect to organization and placement of buttons, and the reading and editing pages resemble a book. In particular, on the edit page, the new text is entered to the right, as is natural for English speakers, who are the target users.
    • Visibility: On the user home page, there is no distinction made between stories that a user moderates and those she merely edits. The login mode, however, is persistently visible, in the upper left corner of the screen. Whether text boxes are editable is not always a very visible, though as much as possible, editable text boxes have rich text formatting buttons, which indicate the box is editable. The expected most common action for each screen is displayed very visibly at the center bottom of the screen on the large circular button. The nicest visibility feature is the ability to view the already posted text while composing the newest section. Since an author may want to refer to an event in a previous chapter or section, it is particularly nice to be able to see both the older work and the current proposed addition. The worst feature is a general inefficiency of screen real estate: the curved upper corners of the main screen area mean the there is usually dead space in the upper corners.
    • Efficiency: The interface has an internally consistent shape and location of buttons, which means that a user's default motion will usually take him or her to the necessary button. Since the button is both large and on the edge of the screen, the most common action for each page should be very efficient, according to Fitt's Law. For a logged in user to create a new project, she or he has to click the create button, fill out the form, and save the contents. This seems like an unnecessary step (having the form available on the user home page would be more efficient for this action), but creating a new project seems likely to be a less common action than reading favourite stories or editing older stories, so those actions are more efficient to perform.
    • Error Prevention: There are copious cancel buttons and confirmation dialogues for actions that may be irrevocable or destroy data. Some actions are not easily reversible – since ordinary users don't have the power to delete comments, if they post a comment accidentally, they must contact a moderator of that story to have the comment deleted. Similarly, for moderating attribute (ie, altering the title or summary of a story) is as easy as editing the content in that there are no extra confirmation boxes for saving the changes, which may lead to a moderator accidentally altering the attributes of a story. However, since the user who altered the attributes must be a moderator, they can reverse the error by changing them back.

Design 3

  • Home page.  Displays quick links to fics she has viewed recently, and also displays fics that she may be interested in.  To create a new fic she clicks on the "My Fics" tab.

  • The "My Fics" tab displays any fics that Jennifer is the author of, sorted by last date modified.  She can interact with them, but chooses to click the "Create new" button at the top of the page.

  • After clicking the "Create new" button, a modal dialog pops up and displays the options for creating a new fic.  The background is grayed out until she clicks the "Create" or "Cancel" button.  The textboxes for adding authors/readers will have smart autocomplete based on people Jennifer has worked with before and other factors.  The only two features that are not self-explanatory ("collaboration" and "timeout") have a help button next to them that will pop up helpful descriptive text.

  • After creating the new fic, Jennifer decides to edit it.  From the "My Fics" tab, she clicks on the new entry and it pops up another modal  The editor will also periodically auto-save, and prompt to save any unsaved changes when Jennifer clicks "Close".dialog box.  This box displays a rich text editor with the ability to save her progress and return later.

  • After writing on the fic, Jennifer goes back and discovers some comments.  The sidebar now displays some information on the fic, as well as quick chapter navigation buttons.  Comments are found at the bottom of the page.  Since Jennifer is logged in as a moderator, the "Block User" link appears in the upper right of all comments.  This allows her to remove the comment and prevent that user from commenting on the fic in the future.  

  • Analysis: The good points of this design are that it closely matches the design of websites that users will be familiar with.  Tab navigation is well-known, and helps simplify the layout.  Navigation is at the top, information is under the tabs, and the sidebar has quick navigation and, when viewing a fic, metadata about the fic.  In addition, the rich text editor will somewhat resemble Google Docs, which in turn closely resembles a very streamlined version of Microsoft Word.  In general, all actions are reversible.  The editor has an auto-save feature, accidental fics can be deleted, and navigation errors can easily be fixed.  Any mistaken configuration of a fic during its creation can be modified later from the "My Fics" tab.  Overall, this design is familiar, simple, and user-friendly.  The only part that may be problematic is the sidebar.  It may be confusing for the user for it to be displaying different information when reading a fic than at all other times.  At the same time, that information does need to be available, and the sidebar was the only place with space.
  • No labels

1 Comment

  1. Unknown User (glittle@mit.edu)

    excellent!

    thoughts:

    - with this sort of project, there are two big interface sides. Side A is how to find stuff in the system. Side B is how to interact with stuff in the system. For your domain, both sides could be complicated. I would focus mainly on one side. I think you care most about side B. That is, you want an interface that makes it really easy for people to collaborate around a single story, but it may not be as important to you how people find that story. Maybe I start a story, and the site gives me a URL that I e-mail to all my friends, and we can start collaborating, and there is no way in the site to find stories (this is similar to Google Docs and Etherpad). That is fine.