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