How usable is WordPress? (Part VIII – Iteration 2)
In Part VII, I made some paper prototypes of quick fixes to usability problems that came up in my analysis of the WordPress.com interface. Now, in my second iteration, I’ve prioritized changes I’d like to have made based on the level of impact I suspect they’d have for the user, again focusing on the novice user. This focus on novice users is what drove me to do the cognitive walkthrough (a method that identifies issues with learning an interface) and to do a user study with a WordPress novice. Normally, in a real redesign or user experience project, I’d base my priorities for redesign on this matrix in order to balance priorities and cost. For this simulated experience, however, “cost” is actual nil, since I won’t be coding any changes to the interface, only presenting simulacrums thereof. (Although there is “cost” in my effort to create these mock-ups, it’s a little different than in “real” life.)
So, my priorities in iteration 2 were to make changes to the dashboard and the WYSIWYG editor – both vital and frequently-used elements of the interface that rise to the top since they are indispensable in the user goal of blogging.
A few notes on process – this is a learning blog, after all:
- The last time I did rapid paper prototyping, I worked with a group. I found the experience of doing this redesign alone much less rich, and suspect the outcomes are similarly limited for lack of other designer’s perspectives.
- I continue to struggle with how novice-friendly to seek to make the WordPress interface. While my user test clearly indicated that beginning users struggle mightily with the interface, it is useful to remember, as Jakob Nielsen says on p. 78 of Usability Engineering: “Users will not stay the same. Using the system changes the users, and as they change they will use the system in new ways.” So I am seeking design fixes that can accommodate both the beginner and expert, as Nielsen suggests on page 42 of the same book – “…expert users would not be hurt by such a concession to the novices.” It is this last advice that I had in mind while opting to add in the downward facing arrows to show menu expandability on the dashboard and most page’s left navigations – it is a concession that harms no one while benefiting the beginners.
In each of the below iterative changes, I’ve included 3 images – the original interface, the changed interface, and a third image highlighting the changes with a brief rationale of WHY the change was made.
Changes to the dashboard (click images to see full size – will open in new window)
A few additional notes on the dashboard redesign:
- In the paper prototypes, I had thought that re-organizing the left navigation to give the user fewer options might help decrease the clutter of the interface. Yet after conversations with Sunah Suh, the TA for my class, and re-examining Nielsen’s thoughts on broad vs. deep navigations (p. 56 of Usability Engineering), I opted to drop this plan. Nielsen similarly notes, on p. 46, that “Interfaces for users with extensive domain knowledge can use specialized terminology and a higher density of information in the screen designs.” This helped reassure me that, with the shallow learning curve likely with blogging software, a this slightly more dense menuing was not as negative as I had originally thought.
- I was also heartened by the quote from Steve Krug, as used in the third edition of the Web Style Guide (print edition, p. 94):“Navigation isn’t just a feature of a web site, it is the web site, in the same way that the building, the shelves, and the cash registers are Sears. Without it, there’s no there there.”
Changes to the WYSIWYG editor
In the Web Style Guide, 3rd Edition, authors Lynch and Horton assert, on page 18, that blogs exist for 3 core functions, the first of which is “easy publication of text, graphics, and multimedia content on the web.” So the user’s main goal – publishing text/media – is accomplished in the WYSIWYG editor. These oft-tricky editors need to strike a balance between being easy enough to not overwhelm the user new to online publishing, but not so limited that more experienced users can’t do basic functions. I was inspired in looking over my fellow classmates’ redesign projects to remember the words of Clayton Lewis and John Reiman: “Plagiarize…find existing interfaces that work for users and then build ideas from those interfaces into your systems as much as practically and legally possible. This kind of copying can be effective both for high-level interaction paradigms and for low-level control/display decisions.”
In looking at the WordPress WYSIWYG (as shown on the “posts page”):
I was feeling a little overwhelmed…I like the interface, but I knew that for novice users, the page could be overwhelming. How to simplify? I decided to revisit Blogger’s WYSIWYG, since I knew from my cognitive walkthrough that Blogger excelled at being novice-friendly:
So I spent some time comparing the options – yes, Blogger’s was very clean, but it lacked many options that would be useful in a robust editor. I decided that perhaps all of WordPress’ options seemed important, but again, I was faced with the “disappearing” option – the “kitchen sink” option that causes a somewhat random half of the options to disappear. Why, for instance, did the Underline option and the Full Justify option need to be hidden, while the Strikethrough options and the other justify functions should be easily seen?
More interesting, however, were the icons for adding images and media. In WordPress, these options (to the immediate right of the words Upload/Insert) hover above the main WYSIWYG tool area, and when using the “full screen” option, users cannot access these functions. I also knew from my user test that novice users were not likely to know that they needed to either upload or insert images – so I opted to change the verbiage to “Add”. See the original, changed, and design rationale below:
I’m feeling invigorated by these changes, and have more forthcoming – see the next installment in this series – Part IX – Iteration 3
This post is part of the ten-part series called Is WordPress Usable?
- Part I – Introduction
- Part II – Picking a Method
- Part III – Preparing for the Cognitive Walkthrough
- Part IV – Analysis by Cognitive Walkthrough
- Part V – Conclusions from the Cognitive Walkthrough
- Part VI – The User Test
- Part VII – Rough Paper Prototypes
- Part VIII – Iteration 2
- Part IX – Iteration 3
- Part X – Conclusions
The series documents my learning process in attempting to systematically identify usability problems in, and suggest improvements to, the WordPress.com blogging software as might be done in the emerging field of User Experience. This project was undertaken as part of LIS590IIL, a class held in the Graduate School of Library and Informaton Science (GSLIS) at the University of Illinois during Fall of 2009.