GR6 - User Testing and Reflections

Design:

The paper prototype seemed fairly simple for users to use, so most of the modifications to our final design from our planned design were just restrictions on what we were able to accomplish.  For the most part, we implemented all the features we intended to allow with the original design and paper prototype. Undo/redo and dragging-and-dropping images were the most noticeably absent features that would have contributed to more positive user experience.

A basic blog post would look something like this:

page 1: 

page 2:

After the heuristic evaluations, we almost completely overhauled the color scheme of most of the buttons.  Our evaluators mentioned that the contrast of the colors in the "+ New ____" buttons made it hard to read, so we made sure to chance the text color so that they would be easy (and hopefully pleasing) to look at. Other than that, we made it so that users would have as little trouble as possible when trying to create a comprehensive blog post.  The details of the user evaluations are discussed later, but some of the design choices we made are as follows:

Colors: Designed such that we would have an overall aesthetically pleasing color scheme (that fit in with our logo), but also such that users would have an easy time reading things and looking at the screen.

Images: Resizing and dragging are the same as in any other text editor, so there is high learnability through similarity.  Also, unlike other text editors, the text reflows nicely and seamlessly around the image, which is almost more learnable and usable than other text editors, which is a bonus perk.

Text/Section boxes: All bounding boxes had a red "x" in the upper right-hand corner to afford deletion; all image bounding boxes also had 8 image-resizing "handles" that afforded dragging. Both of these elements would only display on its bounding box upon mouseover. We also made adding specific types of text boxes (title, section title, paragraph) as easy as clicking the appropriate button on the left universal toolbar, and adding new paragraph boxes as easy as pressing enter in a pre-existing box. This way, every time a user wants to add a new paragraph, a new text box would be created for them.

Formatting toolbar: A formatting toolbar appears across the top of the main page screen whenever a user is editing some body text.  We made sure that the toolbar would remain across the top of the screen no matter where the user was scrolled on the page (absolute positioning).  We also made sure the buttons in the toolbar acted like buttons, and would have obvious activated (pressed down), deactivated, and mouseover effects.  After the heuristic evaluation, we took many of the suggestions on improving the formatting toolbar to meet the specifications of a robust toolbar.  The evaluator gave us helpful feedback about the buttons affording clickability, the effects being consistent, and making sure everything was implemented correctly.  We tried to bring everything up to all these specifications with our final design.
Above: the formatting toolbar.

Above: A pressed button in the formatting toolbar.

Implementation:

We used mostly JQuery and ContentEditable.  Other useful software tools we used were HTMLCanvas and Coffeescript.  We had a backend in Ruby on Rails but never really got into implementing much of the overhead required to use it; as a result, our image upload worked via entering an existing image URL rather than uploading an image to our servers, and users could not save or publish their posts.

JQuery provides many useful functions as a Javascript library, which were invaluable when implementing certain features (i.e., dragging boxes around).

HTMLCanvas provided an easy way to draw bounding boxes for sections of text, particularly non-square sections.  

ContentEditable provided a clean place to write, unlike using something such as TinyMCE.  However, we discovered that implementing even the most basic functionality (e.g. basic text formatting) was much more difficult than anticipated, and made even more difficult by the fact that ContentEditable and Javascript were not designed to make word processing simple.  If done again, we might try to use a predesigned text area like TinyMCE instead of trying to rewrite even the most basic word processing functionality on our own.  This somewhat negatively affected the text formatting part of the final implementation we had planned to implement.

Finally, Coffeescript made some of the brute coding faster, since it’s somewhat easier to write than raw javascript if you’re familiar with the language.  This didn’t really affect our design, but made it faster and easier to write.

We had planned to use Ruby on Rails to save individual users' blog posts, but ended up spending all of our time getting the necessary functionality for the page to work at all instead.  If/when we continue work on the project, we'll use the rails backbone to save things in a database with relative ease, as well as keep track of each users' posts and contribution to the site, providing some authentication so each user can only modify his/her own posts.  

In conclusion, since we used a web app, much of the complicated overhead of mobile apps wasn't necessary to consider.  We used the most basic tools available to us and built up from them, which proved difficult in some cases (especially text editing).  If we were to do it again, we might try to use a few more sophisticated tools to minimize the headache of reinventing the wheel (or, in our case, most of the functionality of TinyMCE).

User Testing:

User 1 (JW, Course 6-3 and 18)

• User tried to position text in relation to whitespace so that it would be below an image.  Eventually figured out how to move around images to create the desired layout effect.
• User originally tried to drag images into the page from the drawer which is not currently supported, but then tried clicking, which did work.
• Other than that, had a fairly successful time interacting with the software, managed to produce a fairly good-looking article with good organization and sections
• Used features such as section titles naturally
• Primarily hand-typed text rather than using copy/paste
• Used images that were providedFinished screenshot for user 1:
  

User 2 (AK, Course 6-1)

• Noted that design of the interface was appealing, said it was “pretty”
• Had some trouble figuring out how to create text and paragraphs - first tried clicking below the title, then pasted text into the title; eventually tried to press enter which made a new text section below, then understood that the large text section was meant to be a title
• Tried to drag an image into the page just like the previous user
• Initially copied the URL of the wikipedia page that contained an image instead of the direct url to the image
• Had kind of a tough time adjusting to the differences from other editors - just seemed a bit disoriented in generalFinished screenshot for user 2:
  

User 3 (JD, Course 2)

• Immediately discovered, upon making a new section, that pressing “tab” didn’t indent, as user had intended, but rather just scrolled the page down.  
• User noted that the browser default spellcheck disappeared when you clicked out of a text section.  User also suggested that we might want to implement more comprehensive automatic punctuation behavior, like automatic capitalization.
• Similar to other users, JW tried to begin a section after the title by clicking on the page beneath it (instead of pressing enter or clicking “add a text section”).
• Also, like all user testers, JW tried to drag the images into the document instead of clicking them.  This clearly indicates a critical implementation flaw.
• User discovered that it’s not possible to delete pictures with “delete” or “backspace” key, only by clicking on the ‘x’.
• User noted that pressing enter doesn’t always position the new text in the right place, especially when the previous box is right above an image.  
• Finally, user showed us a cool video of Kingdom Hearts, which most of his blog post was about.

Finished screenshot for user 3:

Future Work

Functionality Required from User Testing

• Definitely implement dragging images into the text.  All the users had trouble with clicking initially, so that is something that we would want to add for sure.  
• Adding more keyboard shortcuts, and make keyboard input do more (such as deleting entire boxes that are highlighted with delete/backspace key).  
• Fix some bugs that came out, like pressing enter in the middle of a text box or pressing enter in a text box that is right above an image.
• Make spelling suggestions/punctuation suggestions more automatic or at least consistent when text box is/isn’t in edit mode.
• Make some of the keys that people normally use in word processing, like tab, have the expected behavior (indent instead of page down).
• Allow users to click on the page in order to add new sections in addition to clicking on the “add x section” button.
• Have some way for first time users to realize they need to use the buttons on the side bar.

Other Ideas

• More text formatting options such as colors and highlighting

Reflection

Due to time and energy constraints, after each iteration in the iterative design process, we re-evaluated our goals and had to narrow our area of focus and could only focus on the core functionality. While we were not able to implement as many features as we wanted, this allowed us to think more about the heart of the user's experience - since we only had time to implement core features, how could we make those features good? The results of this mindset are particularly shown in the small, easy-to-implement details that greatly improved usability (i.e., automatic new text section when the user presses "Enter") at low cost in time. It also forced us to consolidate our vision for the main features of the product, which ultimately helped us focus our goals. For example, the automatic new text section on "Enter" feature reflects a clarification of our previous vision for Editr. We had originally not given much thought to exactly how much text would be placed in one text section - whether it would be a paragraph or the entire body of text. In intermediate user testing, users did not seem to mention any issues with the way the bounding-box system worked, but perhaps they did not even consider what exactly a bounding box with text meant to the editing process. After some discussion with the group towards the end of the implementation process, we realized that a main reason we wanted a draggable-box setup for Editr was the need for easy rearrangement of different sections in a block of text - something that can be annoying to do in TinyMCE. It was astounding how, through a series of these apparently-minor changes to Editr, we actually managed to shape our goals and visions for our project. Not overextending ourselves in terms of feature implementation (i.e., not worrying too much about text alignment features) also allowed users to better explore core dragging-boxes function and give us more valuable, focused feedback.

The limitations of paper prototyping

We actually didn’t notice the need for these small features when we were conducting our paper prototype studies; because paper prototyping doesn’t involve an actual keyboard, it turned out to be not incredibly helpful in determining new directions for a project centered around text editing. Most of the feedback pertained to layout and the image insertion process; without the actual computer to interact with, many usability details and potential feedback on those details were lost.

Computer prototyping, on the other hand was much more helpful in gathering substantive user feedback. Not only did users catch many implementation bugs (which are inevitable in a project that has built so much from scratch), they also had the freedom to explore parts of Editr on their own and now could give us feedback on small details or possible features to implement.

We realize that our perspective on paper and computer prototyping is only applicable to this specific project; most products, which focus more on novel user tasks rather than changing a commonly-accepted one, may benefit more at the initial planning stages from a cost-efficient paper prototype.