...
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.
...
- 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.
...
- 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.