Hello Plone.

In February, I started working at Four Digits as an intern to help out with the new Plone UI. I was to use my usability "expertise" to represent the end users of Plone. A couple of months later, I can present you my research on these end users and their view on the CMS. It contains summaries of the interviews taken, an usability guidelines check on Plone, my research conclusions and a summary of the subjects mentioned in these conclusions. There must be something of interest to you.

All comments or feedback are welcome and appreciated. Help me get a high grade and say it’s the best you’ve ever read.

Get the PDF file at: http://researching-plone-ui.googlegroups.com/web/researching-plone-ui.pdf

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.

Introduction

Hi, my name is Laurens and I work at Four Digits as an intern to complete my study, Communication and Multimedia Design at the HAN in Arnhem. The next couple of months I will be researching Plone and will try to find weak points in the UI that can be improved in Plone 4.

To find these weak points I will contact some users of Plone from the Four Digits clientele and examine Plone with them. In this post you will find a summary of my first interview with a Plone user. You might consider this interesting if you want to know how an average Plone user uses the system and how he feels about it. Combined, you will find some personal statements from my experience with Plone these last couple of weeks. Enjoy.

The guinea pig, Jorrit.

Starting my focus group research, I wanted to meet the users of Plone and observe their ways with the system. I had a try out interview with Jorrit of youth centre Willemeen to work out the best way for these interviews. I am a volunteer at Willemeen and work in Jorrits publicity team. We know each other well and are the only two to work with the Willemeen Plone website. The risk of asking Jorrit for this try out was that we would drift off from the interview and would not be focused on looking at Plone 3. Still starting with a familiar person for my interviews would allow me to make errors and work out some methods for this research, with still having a representative Plone user.

The startup was kind of difficult. Willemeen only has two rooms which have computers and both were packed with people. There was nothing else to do then sit at Jorrits usual desk and don’t mind the rumor. On the other side, Jorrit always works in these conditions, so I joined him in his regular working environment.

The Willemeen site only lets you do a couple of things, add concerts and events to the agenda, upload pictures to the “backstage” and add news items. Still Jorrits biggest complaint with the system is that it has too many buttons he doesn’t know what to do with. His main task with the system is uploading events to the agenda, news items are rarely posted and he hasn’t started with the use of the backstage yet. So even with only adding pages in folders, Jorrit has trouble working the system.

First let’s find out who Jorrit is before we conclude what creates this struggle. Jorrit works in youth centre Willemeen as head of publicity. This contains being in charge of distributing poster, flyers and press texts, screen-printing and digital publicity. He’s in charge of the website and fully responsible for it. When using his computer he mostly works on gmail, filling in online concert agenda’s and some Photoshop. He spends about two hours a week on Plone, logging in for each minor update. He has no clue what all the buttons of Plone do except the ones he has to use. Even the use of the actions and display drop-downs are unclear to him. Because he has got so accustomed to following his path to adding a page, the system doesn’t slack down his efficiency on the computer. When you ask him to do something else than his regular tasks he has to look thrice at everything, so in unfamiliar territory the system slows him down massively.

What makes Plone so hard to use for Jorrit? Well, Jorrit never had a training in Plone. His predecessor ordered the site long before Jorrit came to Willemeen and never put it online. Jorrit decided to use the site whether he knew how to use it or not, the old one just couldn’t do anymore. So Jorrit got a Plone site without knowing a bit of Plone, the functionality of the site or finances to take a training. No wonder he doesn’t know what most of the buttons do. But is this what we want? That somebody HAS to be trained before he can use Plone? Or do we want to make a system that’s so natural in its use, everyone can use it without effort.

Plone 3

Jorrit really made it clear that Plone didn’t gave him the freedom he wants from a CMS. It has to much functionality he doesn’t use, the system is slow in use (not only is loading a page slow, but you have to load so many pages) and he really feels he is doing what the system desires from him, while the system should do what he wants it to. Jorrit showed me what he did like as an usable system and took out his iPhone. He said that even a guy like him, who doesn’t know much about computers, can still use this. He opened a photo, pressed options, clicked send via e-mail and the picture moved down and up came an editor for e-mail, all seamless and quick. This is what he would want, a focused website which can be used seamlessly and quick. And who can disagree? Focused and seamless were the two most important guidelines when I studied Rich Internet Applications.

To make things even worse he explained why he didn’t like the editor. He said it required him to know HTML and he doesn’t know any. A couple of wrong pastes and enters let you type outside an paragraph and ruin the styling of the site. showing him that he can set styles on the top doesn’t help, he doesn’t want to set styles and headers, he just wants to fill in information about a concert, post a link and an image and be gone with it, he doesn’t want to worry about styles. What can I say, he is right, the editor (kupu or tinyMCE, doesn’t matter) is built for styled page editing, not typing flat text. Even thou Word, Hotmail and a lot of other text editors have a difference in pressing Enter or Shift+Enter, Jorrit didn’t know that and just thinks it’s annoying his texts aren’t aligned similarly. I think this can never be resolved in one editor. Text editor always need some learning curve, otherwise the editor probably cut functionality to make it simple. Making a n00b editor and a l33t one and preferably seamlessly switchable in page editing, could be a solution.

I actually agree with him when he says there are way too many buttons in Plone. The tabs give you the choices Content, View, Edit, Rules, Sharing, History and with a bit of luck the developer installed some products that add extra tabs. And if that wasn’t enough, just beneath all these options you can drop down (!) Actions, Display, Add new and Status. Just opening a page gives me so many things I can do, I don’t know where to start. A thing I personally don’t like in Plone 3 is the Mac-like tabs above the page editor, with the absolutely misplaced ‘default’ naming. Half to my surprise Jorrit had never noticed them before. Is it not that for him the extra metadata fields are not that important, he simply never noticed them. And he confirmed another problem I had with these tabs, he didn’t want to click them because he was afraid of losing his data. These tabs are the only (!) clicks in entire Plone that don’t trigger a refresh. Not refreshing is way good to go, but it’s only these buttons. The user expects leaving the page with a click, because all the other clicks do! When your editing your data your very alert for not losing it, thus no leaving without a save. Consistency is a good way to bring down the learning curve of a system, so this needs to be fixed (making the whole system seamless would be a nice fix).

Future

Although Jorrit has little knowledge about computers and internet applications, he sure knows what he wants them to become in the future. I very much agree with him that a CMS should be workable for people of all sorts and that it should do exactly what you think it would do, so it makes it easy for everyone to use it, even if it’s your first time. A CMS should follow a natural flow, adjust based on the user actions (bending towards the user) and give feed forward whenever possible. In general a CMS should do what it’s intended for, making life easier.

We agreed that internet applications of the future should act and work just like “analog” systems. Sorting your file structure should be as easy as opening a file cabinet (the good examples, in any case) or messing around a stack of paper on your desk. Endlessly clicking and waiting will hopefully be bygones. Current day’s Drag and Drop systems are nice, but will be perfect once we crop the Drop out of it. In the future a CMS would just use Drag. Complete freedom to mess about your content to whatever ways you like. But then, we might want to add an undo button.