Summary of interview results

Introduction

For those of you who don't know, my name is Laurens and I am an intern at Four Digits to research Plone's usability. It has been a month since my first interview with Jorrit and I have come to some conclusions. I spoke to a bunch of more webmasters like Jorrit, non-technical people who were appointed as “the one who will do the website”. Even an intranet with 6000 users had a single webmaster who just “liked working with computers”. Apparently this is a bigger group of users than I expected.

For your reading pleasures I summed up some of the points about Plone 3 UI that stood out the most. Problems your average non-technical users encounter while using Plone.

The list

In random order:

• Learning curve. Do we want webmasters to need training before being able to use Plone?
• Page loads. Plone opens a new page on every click, combined with the fact that Plone can be slow to load new pages, it brings down the users workflow.  Most users have the feeling that their doing what the system wants, not that the system is doing what they want.
• Be seamless. Seamlessness gives users the idea they are in control, they see what happens when they do something. A good example: open a picture on an iPhone en send with e-mail.
• HTML knowledge. Even thou Plone is built so you don’t have to know HTML, the editor can do such strange things, you still need to edit HTML. We need a way that’s ultimate HTML proof.
• n00b & l33t editors. Editors with great functionality are commonly to hard for the average user, but leaving out options for the advanced user so the average user can use it is not an solution. Toggle simple and advanced menu’s?
• Metadata. There has to come a new way of entering metadata. The current tabs are overlooked by all the webmasters and the inconsistency of the seamlessness is confusing.
• Natural flow. Plone has to bend towards the user, not the other way around. Adjust to user preferences by spotting their actions and give feed forward.
• Search results. If you name a folder the same twice, you won’t know which is which if you search it. Adding location at search results would make it easier to find folders like ‘archive’.
• Content tree. The current content page looks just like your average browsing tree, except it doesn’t interact. Every click need a page reload. This breaks down your navigating flow and isn’t consistent with conventions of content tree browsing.
• Tables? Developers stopped using tables for designing pages years ago. In current Plone editors there is only one way to design your pages, drum roll using tables. If people who used tables for a living found a better way, why do we expect non technical people to use this method once again?
• Resize images. You can set the size when choosing an image and drag point for resizing in the editing area. This is confusing. Use one way or the other, for both rendering and showing.
• Dashboard / profile. It’s a potential social networking system. Use it that way! We live in social networking days, if the opportunity is so close, why not use it.
• Exclude from navigation. Place it under status. The status menu gives you the control if your visitors can see a page, excluding it from navigation is an edit in visibility and could therefore be placed in status. It also creates the opportunity to edit the navigation status of multiple files via the status button in contents.
• Sharing roles. What are the privileges of a member? And can a reviewer edit webmasters pages? The naming of the roles don’t make much sense and there is no explanation of the roles available. If a role was named ‘private viewer’ it would make more sense, but you still need to sum up all its privileges.
• Name the error. When pasting in a collection, you will get a ‘not allowed’ error. Why not let the user know he can’t paste in a collection, not that he doesn’t have the right to. Feedback is knowledge.
• Let users report bugs or improvement proposals. If we make a system for webmasters to report bugs or suggest improvements directly to plone.org, there is a bigger chance to get user level points of view into Plone or a product. Free usability testing results! Let non-developers join in the Open Source community.
• Documentation. The current documentation is aimed at developers. For webmasters / users it’s hard to find background information or manuals on products they use. Plone.org is a very technical place while most users are not technical and did not create the site themselves , but ordered it. Let’s make it easier to find user side information about Plone and its products, so our clients won’t call us that much.
• Category. The horror within Plone. Kill it now it’s in sight. Shoot! Shoot!! It needs a complete different UI and should simply be called Tags. The word 'tags' explains what it does more than Category and the term has become the standard since the web2.0 hype. It's okay to use by now.
• History. A very useful function and one of the big fortunes of Plone. Too bad it looks very technical. It’s built for developers and imported directly into the UI for webmasters to use. Cut out the HTML history, just show text edits and show who did it when in one view.
• POV. Many features in Plone are designed from a developers point of view, while most webmasters look at the system from a visitors point of view. Are we creating a CMS for people on developers level or non technical people on visitor level? Don’t think that if you know how to use it, it’s a usable product. If your mother can use it, then it’s a usable product.
• Ordering. Please let’s make 'contents' viewable by name, etc. Just make order clickable and only then editable. If we do this we can make the whole row draggable, not only the unexplainable 4 dotted icon.
• Send this page. The buttons on the bottom of a page, sending the page via e-mail and printing, should be available as a individual page option in the metadata settings.
• Visual noise. One of the main features of Plone is that you are editing your content within your site. Everyone considers this a big plus, but it makes the work harder. Backend editors focus on creating the page, when you see your site around it, it turns into distracting visual noise. Your site plus all the webmaster buttons create a lot of options, a rainforest of options. Drawing the attention from the surrounding site and focusing on the webmasters options reduce visual noise.
• Visual feed forward. The current borders within the edit field are green, we can color it different for different functions as a way of visual feed forward. For instance, If your viewing a page the borders are green, if your editing the borders turn blue and if your deleting something all will turn red. Without reading or even scanning the text, users will know what they are doing.
• Edit button. Bring in the big fat edit button and leave out the rest. When you’re not editing you don’t need that a lot of options.
• Actions tab. Kick it out. Nobody uses it and it’s confusing. If you want to copy/paste you can go to contents.
• Word. To end with the Plone developers nightmare. We can’t deny that number one task of a webmaster in Plone is creating pages and with that we can’t deny that everyone uses text from Word documents. The editors are focused to create pages within Plone, while everyone already has their text and just wants to publish them via the editor. We can’t deny this method and just have to bend towards it. We have to make Plone more Microsoft Word compatible.

The end

Hoping no one will send me death wishes because of my last statement, I will come back to you within the next couple of weeks to post a  full report. I will go deeper into these attention points added with the summaries of all the interviews, reasons behind most of the struggles with the current Plone UI, usability checks and my personal point of view about Plone 3, current directions, Plone 4 and the future of CMS.