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