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