How usable is WordPress? (Part X – Conclusions)

In the course of this project, and over these 10 blog posts, I’ve explored both the back-end interface of the free, hosted version of WordPress from WordPress.com as well as tried my hand at some of the usability techniques that make up the field of interaction design/user experience/usability/et al:

• I chose one method of evaluation,
• I conducted a comparative cognitive walkthrough,
• I did one user test,
• I made three iterations of possible improvements,
• and throughout I called on readings and ideas from those with more experience in the field than me.

And yet…there are always weaknesses.

This work, as illustrative as it has been for my personal learning (I can’t say it enough, this blog is a personal learning space), cannot come close to understanding all the weaknesses and development areas inherent in the WordPress interface. In fact, usability is something that is truly never done – as a systematic and ongoing process, usability for WordPress has streteched long before this series and will continue long after it. Issues in my process have included:

• This work was done alone. Working in a team would surely have produced stronger results.
• Personas were not fully developed for this work and as such, at times, the analysis has likely bent in favor of my own biases.
• Many other methods and tools – such as heuristic analysis, further user studies, et al. – could have been applied here. Knowing which tools to use and for what ends is perhaps the key to effective usability/user experience work.
• This work was done, in many regards, without the formal and explicitly stated constraints normally imposed on user experience projects – be those constraints time, money, human energy, et al. As my lecture notes say, design is a balance of constraints, opportunities, goals, and it always has issues. A context in which to conduct this work (beyond for a class assignment, and to learn, and maybe get a little low-hanging fruit) and an awareness of *real* constraints (as would happen in interaction with coders) would surely impact the thinking done here.

There were also things I wish I’d had time to get to.

It’s always hard to end a project – but thank goodness for deadlines – lest work never be finished! There are several things for me – and heck, for you, and the whole WordPress community – to address, both with the interface and with my own process.  Each of these areas are as complex as the issues I was able to address in my redesign, and some more so:

Color & White Space

The WordPress interface is very gentle when it comes to colors – and perhaps rightfully so – but the judicious use of contrast could help the user navigate the interface better by providing more memorable navigation signposts. Gently contrasting and complimentary colors – such as those found on page 186 of the Web Style Guide – could help give the back end more memorability than the nearly monochromatic to two-toned options now available. There’s also the online Color Scheme Designer to help in choosing a scheme. (Thanks to my classmate Carrie for that resource.) This may also help the display on laptops and mobile devices, both of which have known problems with low-contrast interfaces. The work I’ve begun to do with color is only a small start.

I definitely want to underscore the point above about memory – after all, memorability is one of Nielsen’s 5 areas of usability (p. 26 – the others being learnability, efficiency, errors, and satisfaction). Because there is so much to remember in the interface – where was that setting again? – one use of color may be in helping the user navigate – maybe making wayfinding easier through use of contrasting color. WordPress is very subtle right now in its indication of “where you are” – could color be a solution? Or breadcrumbs?

Might using more overt signals to let users know "where they are" in the site navigation - like breadcrumbs - be helpful to users?

Those Tricksy Disappearing Bits!

I can only assume that WordPress makes use of “disappearing” elements in an attempt to de-clutter what is already a busy interface (e.g. the arrows that indicate a menu can be expanded). And yet important menu options such as depicted below also exhibit this annoying appear-on-mouse-over/disappear otherwise behavior. In the trade-offs between novice, infrequent user, and expert, I believe the scales tip in favor of leaving these items visible. They’re very helpful to novices and infrequent users, and cause the expert no harm. (Also note the helpful use of color in the “Trash” text – and yet this color is hidden most of the time!)

The above menu (near arrow) only appears there when mouse is there. Is this necessary, and would novices be less frustrated if they did not vanish?

Things I haven’t done but (am guiltily admitting) I should

Surely if you haven’t already thought “Why isn’t she engaging the WordPress community on this? Doesn’t she know there’s a lot of discussion about this on the Forums?” you ought to think it now. One of my main reasons for choosing an open-source project was so that I could (potentially) impact the larger user community, but that the inevitable demands of life have prevented me from engaging there. I very much look forward to starting to engage in the WordPress community and look forward to reading about many of these issues that have surely already been discussed.

I have not yet delved into the WordPress community forums - but may dip my toe in and see what, if anything, I can contribute.

Helping the Help Section

As found in my user study, the help section is confusing and would likely be a candidate for redesign efforts.

So, ultimately, how usable is WordPress?

The answer to the question posed by the title of this series is, as can be expected, not straightforward. WordPress is a robust tool for blogging, and even a lightweight CMS. It represents a next step in blogging software with its use of CMS, the open-source community’s contributions in templates, and the ability to customize nearly everything (though the back end remains relatively static!). The trade-off made is that the interface has a steeper learning curve, and with so many options, “even an expert user may be quite novice with respect to many parts of the system” (Nielsen, p. 45). In a day and age where any prospective blogger has myriad options for tools, WordPress may be daunting and frustrating for beginner users or those who use the interface infrequently. Considering these user groups may be in the interest of WordPress if it seeks to attract more users and continue to be “competitive” in this market.While WordPress may intentionally enjoy a niche populated by more savvy users, the perception of difficulty can hinder it. As Nielsen says on p. 34, “User have been known to refuse to use a program because the manual was too big,” – or in this case, the interface to busy. Or as Cooper puts it, on page 45 of About Face 3:

Our goal should be neither to pander to beginners nor rush intermediates into expertise. Our goal is threefold: to rapidly and painlessly get beginners into intermediacy, to avoid putting obstacles in the way of those intermediates who want to become experts, and mos of all, to keep perpetual intermediates happy as they stay firmly in the middle of the skill spectrum.

I have even started to wonder – is “How Usable is WordPress” even the right question? If usability and user experience design is a continuum of processes that precedes, overlaps, and can continue indefinitely through the iterative process, perhaps a more savvy question would be “What are current usability challenges in WordPress?” or “A Usability Check-Up for WordPress.” Both these questions get to the ongoing nature of this work, rather than implying a definitive answer to a set question.

I’d like to wrap up by inviting you to help me in my iterative learning process. What did you think of my work? What questions come up for you in reading this series? What did I miss, did I misinterpret anything, was my presentation clear, and was there a better way to do things? Whether you’re head of User Experience Research at Google or just a casual reader, I’d love your comments and insights, positive, critical, or inbetween. Feel free to comment on any post (including this one) or drop me a line at nicolibrarian@gmail.com.

Many thanks for reading!

-nicole

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.

How usable is WordPress? (Part IX – Iteration 3)

For my third iteration, I’ll continue to work on the dashboard, the WYSIWYG editor, and add my third overall redesign priority (#7 in the paper prototypes), making changes to the front-end of the blog as seen when the user is logged in.

Main Dashboard

In looking at my second iteration of the main dashboard, I made some changes (further text explanations below images):

Side-by-side comparisons of original and two iterations of main dashboard (opens in new window)

A rationale explaining changes made to the dashboard in iteration 3 (opens in new window)

• The “x” options to close module windows create more problems than they’re worth in finding out how to re-open those module windows – so forget that fix. I decided this upon reading Nielsen, on p. 48:”Given the many differences between groups of users and between individual users, it might be tempting to give up and just allow the users to customize their interfaces to suit their individual preferences. However…it is not a good idea to go too far in that direction either.”
• I removed the “Search WordPress.com Blogs” from the upper right corner. It seemed superfluous to me, and in the process of composing a post, unnecessary. I also colored that top bar navigation a bright, contrasting color, as this is a persistent navigation feature at all times when logged in to WordPress.com, and it’s dark grey goes unnoticed. I also moved the items in this persistent navigation to the right, since it is more common to have things like “My Account” in the upper right.
• I removed the “Howdy, <username>” from the upper right, since “My Account” was now right above it, and the two links did nearly the same thing.
• I highlighted the Upgrades and Promo tabs to make them more visible, though I am unsure if this is really the best place for this information.
• Finally, although this is not visible in the interface (see the rationale), I wanted to make the modules on the dashboard direct links to the deeper content of which they are just a snapshot. In the original, the “Recent Comments” text/module does NOT link to what you would get if you clicked on “Comments” in the left navigation. Similarly, the “Stats” module on the dashboard is not linked to what you’d see if you clicked “Blog Stats” in the Dashboard area of the left menus. So an improvement would be to link the dashboard modules to the deeper content areas present in the left navigation.

WYSIWYG

The last iteration of the WYSIWYG did not focus on some of the deeper functions of the editor, so in this iteration I will look at one area of concern – the toggle to fullscreen feature.

Original of the "Fullscreen" toggle from WYSIWYG (opens in new window)

Changes to the fullscreen toggle to give users an "exit" and indicates their work is saved (opens in new window)

Toggling to Fullscreen

A very handy feature of the WordPress WYSIWYG is the ability to toggle to full screen. Yet while in the full screen mode, there is no way to “save” or “update” or “publish” (idioms used at different places in the WordPress interface. Users who are used to saving their work before altering a display may feel unsure if they can toggle and not lose work, so this simple fix would be to include a button for either saving/updating/publishing (whichever term is in use in the non-fullscreen mode). See the original and fixed image below:

Viewing the Blog While Logged In

As was seen in the user test, users may go out to the blog (by clicking “visit site”, for instance) to try and use this “front end” to help navigate the back-end interface. This can be helpful – in the user test, the user was able to identify a key term, “Pages”, by using this method. My idea for an improvement (as expressed in the three images below) is to enable users to directly navigate from the front end to the correct area of the back end with great ease.

Original view of blog "front end" while logged in (opens in new window)

Proposed redesign of front end while user logged in, aimed at helping users navigate back-end (opens in new window)

Rationale for redesign to blog front end while logged in (opens in new window)

This concludes the iterations of redesign. What does it all mean? See Part X – Conclusions.

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.

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.

Evolving redesign priorities for iteration 2 - in post-it form (opens in new window)

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)

Original Dashboard (opens in new window)

Second Iteration of Dashboard (opens in new window)

Design rationale for changes to dashboard from the original to iteration 2 (opens 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”):

A new posts page - showing the WP WYSIWYG editor (opens in new window)

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:

Blogger's WYSIWYG - very simple! (opens in new window)

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:

Original (top) and modified (bottom) of WP WYSIWYG (opens in new window)

Design rationale for altering WYSIWYG (opens in new window)

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.

How usable is WordPress? (Part VII – Rough Paper Prototypes)

I’ve started to move on from analyzing problems in the WordPress interface into sketches of what, specifically, can be improved. Design of this kind seems to work best in a series of iterations, so this is  iteration one of three. As preface, here is what the back-end of a hosted WordPress.com blog looks like (click the image to see the entire screen width; opens in a new window):

A WordPress.com "back-end" - the Dashboard

Some of my ideas on how to improve the interface can be found in these paper prototypes (a Google Doc PDF).

Recommendations (each are further explained in the PDF):

1. Make the “Visit Site” button more visible.
2. Show the changeable nature of the interface by adding “x” (close window marks) to each module.
3. Re-organize the left navigation based on user goals: to blog! Better “chunk” functions based in order of usage.
4. Remove “turbo” from upper right corner.
5. Remove the WordPress announcement banner.
6. Begin to improve clarity in WYSIWYG by moving “upload/insert” into main tool section.
7. Improve ability to find where things are in the back-end menus by putting “edit” links in front end – like is currently done for each post (when user is logged in).
8. Make module/menu expandability easier – don’t have the drop down arrow disappear.
9. Improve Help menus by adding links from text to function.
10. Link dashboard modules to their corresponding pages in the back-end.

Here’s a quick visual of some of the changes to the dashboard (again, click to see full image); you can see hand-drawn sketches and revisions in the PDF:

A rough mock-up of some proposed changes

Confused? Feel free to drop me a line with any questions.

In the meantime, see the next iteration of my mock redesign in Part VIII – Iteration 2.

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.

How usable is WordPress? (Part VI – The User Test)

WordPress

Blogging has become a very popular online activity. A host of free and low-cost tools have grown to accommodate writers of all kinds – from hobbyists to diarists, from professionals to government officials and beyond. Blogs are attached to social networking software, or can be started for events, such as the project at CaringBridge.org that helps patients and their families set up blogs in medical emergencies. As blogging software tools are increasingly able to integrate with other kinds of Web-based software – such as social networking platforms (like Facebook), photosharing applications (like Flickr), microblogging tools (like Twitter), social bookmarking sites (like Delicious) – some have argued that blogging platforms are becoming more like Content Management Systems (CMS) than simply spaces for chronologically displayed text.

Blogging software has typically been seen as very basic and easy to use. A cognitive walkthrough of three popular platforms  – WordPress, Blogger, and TypePad – found that there are indeed possible areas of improvement for blogging interfaces, and also that of the three, WordPress seemed to be the most flexible, scalable, and extensible for a serious and robust blog that may, over time, need functions more commonly found in a CMS. As online content grows, and individuals continue to blend the traditional static Web site with the interactivity of blogging, time is ripe to reconsider if blogging software is actually as easy to navigate as has been assumed. In the below document, a User Study of WordPress.com’s interface is conducted and analyzed.

Read the full WordPress User Study here (pdf)

Or, you can move on into the first version of a “redesign” (suggested improvements) in Is WordPress Usable part VII: rough paper prototypes.

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.

How usable is WordPress? (Part I – Introduction)

As part of my interest in interaction design and usability, I’m embarking on a project to analyze and design a better interface for an information system. (And believe it or not, that’s the exact title of a multi-part assignment in my class LIS590IIL – Interfaces to Information Systems! Fancy that. This is one of the first classes I’m taking for my Masters of Library and Information Science (MLIS) program in the Graduate School of Library and Information Science (GSLIS) at the University of Illinois. My professor here is the inimitable Michael Twidale.)

I’ve decided to pursue analyzing the usability of WordPress, particularly the free, hosted interface available from http://www.wordpress.com. My goal is not only to analyze the WP interface for usability problems, I am also going to try and come up with design fixes. At the outset, I’ll say that I have been reading a couple great books that are shaping my thinking here: About Face 3: The Essentials of Interaction Design by Alan Cooper, Robert Reimann, and David Cronin, and Usability Engineering by Jakob Nielsen.  I believe this task will entail applying, what Cooper, et al, say is “a repeatable, predictable, and analytical process for transforming an understanding of users into products that both meet their needs and excite their imaginations” (p. 9). I also subscribe to Nielsen’s view that “usability is filled with apparent contradictions” (p. 10), that there will always be need to improve designs to accommodate users, and that “usability is a comparatively cheap way to improve product quality” (p.9, footnote).

I’ve also chosen WordPress because it is an open source project, run by and for a community of users and, depending on my findings, I hope to contribute my analysis in some way. Curious about the difference between WordPress.com and WordPress.org? Learn more here.

So what does this mean and why do you care? It means I’m going to take a systematic and multi-part approach to see how the WordPress blogging interface meets blogger needs; and I hope you’ll care because you’re just as interested in usability as I am, you enjoy being deeply nerdy (see comic here), and because I’m going to try and write this in an accessible and understandable way – something I fear is becoming harder with my return to academia.

Let’s Get To It! Part II: Picking a Method

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.