This is the last post (first and second post) about my experiences from my thesis and this time I will focus on how you as a developer can improve the user experience for your editors in the Polopoly Admin GUI. This is not only an initial problem when first implementing a web site in Polopoly, but also when developing and changing the implementation over time.

In my thesis several editorial staffs participated from different types of organizations and using different web content management systems (WCMS). Some of them had worked really hard to make the user experience as good as possible for the editors. Some had not done as well and they had often forgotten the most important aspect of software development: the users and, maybe more important, the tasks and activities of the users. This means all users and not only the boss or the people speaking out the loudest.

As mentioned in the last post, the initial user experience is based on the choice of web content management system as well as the provided guidelines of developing the editor’s user interface. After that, it is up to the implementers to implement the web content management system and make the user interface usable, efficient and effective. This is more important in a web content management system like Polopoly, than, for example, EpiServer or Sitecore.

Content is king and, therefore, the users producing the content must be gods. You have to know your users and how they work both outside and inside the web content management system. With very little effort, you can learn a lot. Ask them if you can observe what they are doing during an hour or two, or even better, a whole day. Do not focus on their opinions, but rather on their tasks and activities and how your knowledge about the features of the web content management system can support them.

When I observed different editorial staffs I found some general aspects that might help you to better understand your editors. First, editors are busy people with a lot to think about. Second, they are creative and they want the software system to support them to be creative. Third, they are organizers and, therefore, the software systems they use should support them to stay organized. Last, and maybe most important, they want to get things done. To summarize, the editors want web content management systems to make them more effective and efficient. That means supporting their activities as good as possible.

Besides understanding the users, knowledge about usability and interaction design is a self-evident tool in every developer’s toolbox. Usability and interaction design is not only important for the frontend user interface, but also for the backend user interface. If you feel that interaction design and user-centered design is not part of your toolbox yet, order Designing the obvious or Don’t make me think from your favorite bookstore. These are short books that you read in an evening or two and, most important, they are really funny and easy to read.

Last, two tips to think about when designing the Polopoly Admin GUI. When I observed editors using different implementations of Polopoly, they usually searched or browsed to find content in the left frame. Editors of different organizations had different information seeking behaviors. After you have identified the editors’ preferred method to find content, make it as efficient as possible to use it. Even if it might be hard to think, it is possible to improve the interaction design of that left frame more than you think.

Tabs are essential in the Polopoly Admin GUI on many levels. As mentioned before, you have to found out how your editors work with content to divide the content right. For example, if you observe that editors switch between two tabs in a content several times in a minute, it might be better to have all that information in one tab. In this case, scrolling with the mouse wheel is often faster. I you have ridiculous much scrolling, it might be better to divide the content into two or more tabs. Especially if you observe that some forms are not used as much. You have to observe and understand the users to make the right design decisions.

To conclude, try to design the Polopoly GUI for the 90% that will really be using the system and get out into the wild to learn more about them. If you try to adopt a 1-click mentality, you might be able to cut down on all those tabs and make the editors more pleased with the web content management system.

This is really just touching the surface of how to understand and designing the Polopoly Admin GUI as this had nothing really to do with my thesis. If you have other observations, please leave a comment below and share your insights of how you and your organization design your Polopoly Admin GUI.

If you want to learn more about how I conducted my thesis and more examples and solutions, read my thesis.

Max Walter is a soon- to-graduate computer science student at the Royal Institute of Technology that did his master thesis at Atex Polopoly. He is also working as a usability consultant at Metamatrix. During his studies he has written computer books for beginners and articles in Sweden’s largest computer magazine for advanced users, Datormagazin. Read more about him at LinkedIn, follow him on Twitter or read his online business card at http://2mw.se.

Image © iStockphoto

Som vi på polopolyforum skrev i september, så har Atex Polopoly ett projekt där de ska lansera en ny supportwebb för oss kunder efter nyår. Vi satte oss ner med Mattias Köhlmark som berättade om vad de tänker och hur systemet ser ut nu när ett par kunder har fått testa och säga sitt.

Polopolysupportens nya startsida (bild 1)

Så vad är det nya?

Lösningen som Atex tänker sig ta i drift för alla kunder efter nyår består av ärendehanteringsverktyget Jira kopplat till WIKI:en Confluence. Atex har använt Jira internt ett tag som ersättare till Bugzilla och känner sig nöjda med det. ”Många av våra kunder använder Jira, och det bidrog till valet, man känner igen sig” Säger Magnus Kölhmark.

Screenshot från Jira i nya Polopolysupporten (bild 2)

Grundläggande i en kunds konto i nya supportwebben är att man som kund har en grupp där alla ens användare är knutna till så att alla inom en organisation kan se alla ärenden som rapporteras från organisationen, oberoende vem som gjorde det.

Jira implementationen är ganska standard så som den ser ut i skrivande stund, med det man är van med så som personliga Dashboards och möjligheten att följa vad som händer via mail och RSS . Värt att notera är två viktiga val kan man göra när man lämnar sin buggrapport, och det är priority, vilket är en prioritet på ärendet från 1 till 3 där, 3 är högst, prioriteten är vårat sätt som kund att säga om vi tycker att en fråga är viktig relativt andra frågor som vi själva har skickat in till supporten. Med andra ord är det dumt att alltid sätta den till högsta prio.

Den andra viktiga inställningen på en rapport är Security Level, som beroende på kund kan sättas til publik eller privat fråga. Väljer man att rapportera med säkerhetsnivå publik, innebär det att andra kunder kan se och följa frågan.

Atex har också tänkt sig lite andra delar i nya supportwebbben, så som den utvecklare till utvecklare (Dev-2-dev) del där man kan ställa frågor till andra utvecklare, liknande polopolyforums forumdel.

Supporten ska också fylla sajten med sina omkringliggande kunskaper som inte direkt berör själva produkten. Magnus tar som exempel hur man bäst använder HTTP-cachning i sin driftmiljö. Informationen förmedlas under rubriken Tips and Tricks i form av Knowledge Base artiklar

Jira/Confluence lösningen ger också en snygg lösning på sökning som kommer ske i alla redaktionella  källor samtidigt, det vill säga DevGuide, JavaDoc och supportsidor (KB-sidor).

På frågan om vi som kunder kommer att kunna följa Polopolys behovslista (eng: Backlog) så var svaret från Atex svävande, men om jag får gissa så är svaret att det inte kommer att ske, inte heller på en högre, abstraktare nivå. Däremot verkar det som om kunder kommer kunna följa alla de buggar som fixas innan de hamnar i en releasead versions change list.

polopolyforums tanker och synpunkter

Ska man hårddra det så kommer Atex nya supportwebb att vara en konkurrent till polopolyforum.se, men jag skulle vilja börja med att säga att vi tycker att det är ett jättebra steg som man tar i och med Jira och Confluence. För om det är något som det finns för lite av så är det bra källor till Polopolykunskap på nätet, så ju mer snurr det blir på Atex supporten dessto mer kommer hända även här på polopolyforum. Det kommer dessutom vara en stor skillnad i att supporten alltid kommer att finnas bakom inloggning och inte lika lätttillgänglig.

Så vad gav vi för återkoppling till Magnus Kölhmark på mötet?

• Vi ser det som nödvändigt att man kan kommentera KB-artiklar och DevGuiden, inte bara för att rätta fel i själva texten, utan även för att kunna ge mer information om t ex konfigurationer som inte står i DevGuiden.
• Vi vill också att Atex importerar alla ärenden som i dag ligger i det gamla supportsystemet så de finns tillgängliga för oss kunder direkt när vi börjar använda systemet.
• För att förenkla borde startsidan inte vara bara text utan lyfta fram de saker som supporten gör, publika buggar som rapporterats in, och framförallt lista kundens alla öppna ärenden.
• Vi önskar också att man för in en möjlighet att lämna ”feature requests” vilket inte är möjligt i dag då det bara finns två val, bugg eller support ärende. Många gånger är det inte en bugg utan en ändring eller tillägg man vill göra på en funktion.
• Någon typ av meta-data driven ”Se även” listning på ärenden vore också bra, datamängden i Jira växer snabbt och man kan ha många ärenden liggande. Så en funktion för att se om andra har rapporterat liknande fel eller synpunkter vore bra. Det är svårt att hitta bara genom sökning. Kanske ett tagg moln?

Till sist …

Atex jobbar fortfarande med att utforma systemet, vad man ska få göra/inte göra, vad som ska finnas/inte finnas och det är nu som du ska göra din röst hörd om du har synpunkter!

In the last post I shortly explained what my thesis was about and in this post I will write more about my observations at different editorial staffs. Most users of web content management systems understand why the system imposes limitations on how to produce the content and publish it. Still, they hate it.

First, it is important to separate professional and non-professional web content management users. In this case, professionals are users that work with the web content management every day. They are experts of the system and what they are doing. For example, first page editors of larger newspapers’ websites or web editors of larger government agencies.

In this case, non-professionals are users that work with the web content management occasionally; for instance, once or twice per week or even month. They often have to accomplish different types of tasks each time. For example, part-time working editors at government agencies, but also journalists that only occasionally write content directly into the web content management system.

Professional and non-professional users have different requirements and require different web content management systems or, at least, different implementations. Compare it to the difference between using Photoshop and Photoshop Elements. Journalists prefer to use Photoshop, but your aunt would probably prefer use the simpler version, Photoshop Elements. Journalists would maybe feel a lack of freedom if using Photoshop Elements and your aunt would feel that she had too many choices if she used Photoshop. In my thesis I observed and talked to both types of users that were using both web content management systems that were like Photoshop and Photoshop Elements.

Many web content management systems and the implementation of them were developed to meet the requirements of professional users (and the opposite). Even so, the professional users often felt that the web content management systems limited them in their practice. In some cases, where the implementers really had thought of how the editors worked, the editors often overall liked the user experience. In most cases the editors felt inefficient and ineffective. I am not an expert, but lack of efficiency must mean that these organizations could save money by making the user interfaces more efficient.

The difference between implementations of the same content management system was larger than I thought when it came to the user experience of the user interface for the editors. A good example, from a media provider, was when the layout of teasers was graphically displayed in the interface. This supported the memory by removing the need to remember different titles for different layouts of teasers. That made it easier and more efficient to decide and change the layout of teasers.

Another, not so good example, was when the implementers had chosen to not use the standard WYSIWYG widget for management of text. To make a long story short, to move a paragraph from the beginning of a text to the middle of it, the editors had to move the paragraph one step at a time. For each move the page was reloaded. This was time-consuming and made the editors stressed out. One editor said that it could take an hour to accomplish a task that in Word would have taken five minutes.

The knowledge and skills of the implementers are essential to create a good user experience for the editors using a web content management system. Additionally, to provide the implementers with this knowledge, the web content management software companies have to provide the design guidelines of how to implement the user interface for editors. Software companies as Microsoft, Apple and Google Android provide design guidelines to implement their user interfaces.

Furthermore, the implementers have to have knowledge about interaction design, usability and other user experience issues when designing the backend user interface. None would argue that these aspects are not essential for the frontend of websites. If the backend user interface is not optimized for the real users, the editors, they will be inefficient and ineffective and that cost money. Web content management systems that are less implementation depended seems to be more appreciated by non-professional editors. Probably because these systems are not as complex and the software companies can make the usability and user experience really good, with less risk that the developers ruin it.

In the next post I will write about how you as a developer of Polopoly can improve your implementations by learning some basic interaction design. If you want to learn more about how I conducted my thesis and more examples and solutions, read my thesis.

Max Walter is a soon- to-graduate computer science student at the Royal Institute of Technology that did his master thesis at Atex Polopoly. He is also working as a usability consultant at Metamatrix. During his studies he has written computer books for beginners and articles in Sweden’s largest computer magazine for advanced users, Datormagazin. Read more about him at LinkedIn, follow him on Twitter or read his online business card at http://2mw.se.

Image © iStockphoto

This is the first part of a three post series (part 2 and part 3) that will be posted here in November about the thesis I did at Atex Polopoly. I did the thesis in the fields of human-computer interaction (HCI) and computer supported collaborative work (CSCW). In this post and two more posts I will shortly present my thesis, my experiences from in the wild and what to think about when designing the Polopoly Admin GUI. This post is about how I conducted my thesis and my conclusions.

The thesis was about content collaboration, which is when editors collaborate about producing and editing content, for instance, a teaser or an article. The purpose was to investigate how this type of collaboration was supported in web content management systems. The overall question was if the user experience of web content management systems would be better if it was more like a community where users worked together to produce and publish content.

A field study was conducted at seven web editorial staffs. Three different types of editorial staffs were participating in the study: distributed editorial staffs (a university and two municipalities), time-oriented editorial staffs (two larger media providers) and news-oriented editorial staffs (two newspapers). At all editorial staffs, collaboration was central in the process of producing content. These staffs did not only use Polopoly, but also Escenic, EpiServer and SharePoint.

People collaborated by talking to each other, sending e-mails and instant messages and, sometimes, even using other types of collaborative software. But they rarely used the web content management system directly to collaborate. One example of collaboration was that one editorial staff used workflows to manage content, which in this case was an approval process to where at least two users worked together.

Another example was that one web content management system had support for sending content to a “first page inbox”. Even if some journalists sent completed teasers to the first page editor, he or she did never check the inbox. The primary source, and the only they had time to follow continuously, was the first page editors e-mail inbox. Therefore, all journalists sent an e-mail to tell the first page editor to check the “first page inbox”. In the next three paragraphs, three examples are presented to support the three main conclusions of the thesis.

The first conclusion was that web content management systems would improve content collaboration by better integrating support of external collaborative software. Many editorial staffs had found alternative usages of features in the web content management to collaborate about content. For example, many editors used the ID of a content to share the content with other editors. That was accomplished by sending the ID in an e-mail or an instant message.

The ID is a string of numbers that the editors had to copy from, for example, an e-mail and paste into the web content management system. One editor said that it was like “sharing phone-numbers with each other”. By using URLs it would be possible to minimize the number of steps necessary to share a content to another user. For example, it would be possible to easily create an e-mail directly from the editor’s interface with the content URL in the body of the e-mail. When the URL is clicked, the content is opened in the editor’s user interface. It is much better to support the mental model of internet in the web content management system, then the mental model of phone numbers.

The second conclusion was to better support awareness of content activity and, that is, to make editors more aware of what other editors and content producers are doing. Even if all web content management systems had support to follow recent changes, they lacked efficient support to filter them. For example, editors waiting for content to be delivered wanted to observe if another editor had started working with the content, for example a teaser. It was not possible to follow only one user or to observe the activity of a group of users. Compare it to how you follow friends on different social networks.

Last, but not least, the editorial staffs had different requirements about content collaboration. They worked with different types of content and, therefore, had different requirements. Additionally, the organizations had different structures. Subsequently, collaborative features had to be customizable. For example, to improve the awareness of content activity different dashboards designs were tested. Each editorial staffs, or even editor, had their own favorite features in the dashboard. The dashboards designs were only very simple prototypes and it does not prove how the editors would use the dashboards in the reality.

Better collaboration support in web content management systems is likely to facilitate the management of articles and other content. The conclusion was threefold. Better integration with external collaborative systems, better support for awareness of content activity and making collaborative features customizable to support different types of editorial staffs are the most important guidelines.

To finally conclude, some organizations may benefit from using a web content management system where the user experience is more like a community. If you want to learn more about how I conducted my thesis and more examples and solutions, read my thesis. In my next post that will be published in one week I will write about my experiences from the wild.

Max Walter is a soon- to-graduate computer science student at the Royal Institute of Technology that did his master thesis at Atex Polopoly. He is also working as a usability consultant at Metamatrix. During his studies he has written computer books for beginners and articles in Sweden’s largest computer magazine for advanced users, Datormagazin. Read more about him at LinkedIn, follow him on Twitter or read his online business card at http://2mw.se.

The photo was taken by bwalsh.