You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

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.  Anyhow, 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 made it hard to read, so we made sure to redo the buttons such 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 it’s very learnable.  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 - gave all boxes (including images) an ‘x’ on mouseover, which is a universal symbol for deleting things, which is also very learnable.  Also made adding specific text boxes as easy as clicking a button on the left universal toolbar, and adding new paragraph boxes as easy as pressing enter in a pre-existing box, much like new paragraphs should work (which is also very learnable).

Implementation:

We mostly just used 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.

JQuery provides many useful functions as a javascript library, which were invaluable when implementing certain features (e.g. drag and drop).

HTMLCanvas provided a really easy way to make the bounding boxes for the text areas.  

ContentEditable was a very 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 weren’t 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).

  • No labels