Version 9.16.1 is a tuned version of 9.16.0 which contains a number of improvements that couldn’t be fitted in the regular fixpack format. Fixpacks are for bug fixes and minor enhancements. This release goes beyond that to form a minor release of it’s own. The major improvements in version 9.16.1 revolves around performance of the editorial GUI.

När din polopolyinstans växer och därmed källkodsträdet kan det vara bra att jämna mellanrum se över och ta bort eventuell kod som inte längre används. En del av detta är inputmallar som blir utdaterade med tiden. Jag tänkte därför tipsa om hur man kan ta bort gamla inputmallar som ligger och skräpar i systemet och det är några steg att hålla i huvudet.

Denna beskrivning är baserad på användandet av ramverket Pluris så alla detaljer kanske inte är relevanta för ditt projekt men principen bör framgå i alla fall.

Här följer en steg för steg beskrivning hur man tar bort en gammal inputmall:

1. Börja med att se till att inga instanser finns publicerade i någon contentlista. Det är också bra om man
   kan ta bort alla instanser av de mallar du ska ta bort. (dock ej nödvändigt)
2. Skapa därefter två nya policyklasser, en för artiklar och en för avdelningar som kommer att användas istället för de deprikerade.
   package se.kth.ite.cortina.policy.article;
import com.polopoly.cm.policy.ArticlePolicy;

/**
* This policy is used as policy for deprecated templates.
*/
   public class DeprecatedArticlePolicy extends ArticlePolicy {

   }

3. I template.xml, sätt policyn till DeprecatedArticlePolicy eller DeprecatedDepartmentPolicy
   beroende på om det är en artikel eller avdelning. och ta bort allt som inte längre behövs i mallfilen.
   Det går även att t.ex. skapa en DeprecatedContentPolicy som kan användas istället för båda ovanstående.
   <?xml version="1.0" encoding="ISO-8859-1"?>
<template-definition version="1.0" xmlns="http://www.polopoly.com/polopoly/cm/app/xml">
<input-template name="it.article.coursesearch" label="template.article.coursesearch.label">
<policy>se.kth.ite.cortina.policy.article.DeprecatedArticlePolicy</policy>
<editor>se.kth.ite.cortina.widget.app.OLocalizedContentTopPolicyWidget</editor>
<viewer>se.kth.ite.cortina.widget.app.OLocalizedContentTopPolicyWidget</viewer>
</input-template>
</template-definition>
4. I content.xml sätt <entry mode="remove"> för att ta bort mallen ur avdelningen för mallar, på så sätt försvinner den ur alla mallistningar också.
   
<contentlist>
<!-- REMOVED DUE TO DEPRECATION -->
<entry mode="remove">
<metadata>
<referredContent>
<contentid>
<externalid>it.article.coursesearch</externalid>
</contentid>
</referredContent>
</metadata>
</entry>
</contentlist>
5. Ta bort controllern, init.xml och all annan kod som enbart dessa använder.Policyn ska vara kvar eftersom polopoly verkar fungera så att för att importera en befintlig mall så måste den gamla policyn finns kvar.
   Detsamma gäller förmodligen också eventuella widgets.
   Se också till att ta bort externalid från eventuella andra contentcreators och contentwrappers. Sök efter externalid för att vara säker.
6. Kör en deploy
7. Ta bort template.xml, content.xml, policyn och eventuella widgets samt dess dess katalog och andra spår av mallen

Klar!

REST integration, moderniserat redaktörsgränssnitt & bort med Indexsservern

polopopolyforum.se har träffat Atex Polopoly och fredagspratat med Anders Weijnitz. Vi summerade 2009 och pratade om vad Atex har i sin behovslista för i år. För oss som redan är kunder och har egna installationer som inte bygger på Greenfield Times, vilket jag antar är de flesta av oss i Sverige och Norge, så ser 2010 ut att bli ett bra år där fokuset ligger på kärnprodukten.

2009 var ett bra år för Atex med flera nya marknader och många nya kunder, däribland en del stora drakar som tyska Pro Sieben och norska Edda Media. Utvecklingen av Polopolys CMS präglades mest av förbättringar i Greenfield Times så att den skulle gå från att vara en enkel testsite till att kunna användas som en snabb väg till att få upp en produktionsduglig tidning i skarp drift med mycket ”out of the box”-funktionalitet. I detta ingick också förbättringar för ”Live Layout Management” och communitydelen.

Man började också med det första steget för att byta ut indexservern mot Solr så att sökindex ska kunna distribueras ut och bli mer rubusta. Hittills har man byggt in metadatasökning. Atex Textmining kom också som ett tillägg som innebär att man kan få förslag på taggning av artiklar utifrån det innehåll man har skapat.

Kort så har plattformen byggts om en del för att kuna skala bättre, man har lagt krut på bildgenerering där derivaten av bilderna skapas ”on demand” och ligger ute på frontarna och man har även börjat utveckla möjligheten att skapa plug-ins.

Vad ser vi i kikaren för 2010?

I år har Atex Polopoly tre områden de i första hand kommer fokusera på. Det är integration med api:er, en ansiktslyftning av det interna gui:t (redaktörsgränssnittet) samt att fortsätta utveckla Solr.

Integration med REST

En utbyggnad av REST-api:et kommer att göras där man skapar ett nytt semantiskt dokumentformat som inte är lika kopplat till datastrukturen. Detta medför att man enklare kommer kunna importera och exportera data mellan Polopoly och andra tjänster. Det kommer också via Atom Publishing-protokollet gå att prenumerera på ändringar där länken i atom är en länk till xml-dokumentet som nytt innehåll.

Polopoly ska bli en del av ett större metadatalager av repositories, där de ska bli mer oberoende för en publicist var han eller hon redigerar eller får information ifrån. Protokollet för att läsa och redigera innehåll kommer vara utbyggbart och ska också skiljas mer från hur polopolycontent-xml:en idag
ser ut. Semantik mellan format, title, ingress etc kommer Polopoly stödja via ett par fält redan från början.

Idag är det problem med xml-en. Om man ändrar sin indatamall så ändrar man xml-formatet för import och export också. I Greenfield Times kommer det finnas exempel på hur man bygger ”klistret” mellan det nya xml-formatet och policyn.

Ansiktslyftning för insidan, äntligen!

Äntligen tar man tag i redaktörsgränssnittet som alla redaktörer lever med i sitt dagliga jobb. Det har länge känts gammalt och utdaterat. Tanken här är att i första hand förenkla de vanligaste handgreppen och minska antalet klick för redaktören. Man kommer också att förbättra ajax-stödet, skapa nya teman samt göra det lättare att utveckla egna teman.

Anders pratade också om att insidan nödvändigtvis inte måste vara en mappning mot indatamallen som den är idag men mer information om detta kommer senare.

Slänga ut indexservern och Lucene och göra plats för Solr

Arbetet med att fasa ut indexservern fortsätter. Målet är att slänga ut den helt under året. Anders brottas dock fortfarande med hur man ska lösa det på det tekniska planet. Det är nog många av oss som har skrivt kod som är direkt kopplat mot indexserverns underliggande Lucenedokument, så det kan nog bli så att vi får refaktorisera lite i våra respektive kodträd. Men jag är nog inte ensam om att känna  glädje över att få göra just det, och kanske för sista gången behöva oroa mig för indexserverns single point of failure.

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

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.

Delade images i Amazons moln

Du har säkert suttit och tänkt att du skulle vilja installera den senaste versionen av Polopoly med tillhörande Greenfield Times, men som vanligt inte haft tid, på sin höjd hinner du läsa igenom versionens change list. Då har vi glädjande besked! Atex Polopoly kör i dag sina nattliga byggen i Amazons cloud, och vi har lyckats få dem att dela ut dessa till oss så vi kan installera deras images och därmed alltid ha det senaste funktionerna tillgängliga för utvärdering

Detta byte kommer troligen också innebära att den inbäddade HSQLDB byts ut mot annan databas. Atex Polopoly har också nu bestämt hur deras nya releasehantering ska se ut och det blev lite annorlunda än vad vi skrev om i  maj. Ojämna versionsnummer kommer inte att släppas som produktionrelease utan bara finnas för att ladda ner som Developer release från supportwebben. En developer release är tänkt att vara till för utvärdering och testning av ny funktionalitet som ska komma i nästa produktionsrelease.

Produktionsreleaserna som kommer få jämna nummer (9.16, 9.18 etc.) kommer att släppas med ca 8 månaders mellanrum, vilket är väsentligt längre än i dag. Developer release:en borde bli ett bra komplement till Amazon, eftersom du där inte kan testa utveckling, skriptning o.s.v. Ändringen till 8 månader mellan produktionsreleaser borde innebära att många av buggarna i Poloploly hittas innan produkten skeppas.

Värt att tillägga är att enbart produktionsreleaserna kommer att buggfixas, hittar man en bugg i en developer release får man vänta på nästa produktionsrelease för att få den fixad från Atex Polopoly.

Vad tycker ni om den nya releasehanteringen? Diskutera det i forumet under Vad tycker du om Polopolys nya releasehantering?

Precis som Mats påpekade via vår feedback-funktion så har det saknats kategorier i forumet för att ställa allmänna frågor och dela med sig av tips. Forumet har tidigare varit lite för smalt vilket vi nu delvis hoppas råda bot på. Nu finns det två nya kategorier, ”Frågor om Polopoly” och ”Tips & Tricks” som vi tror ska fånga upp fler tankar och funderingar som alla kan ta del av.

Kom ihåg:

• Inga frågor är för dumma!
• Inget tips är för litet!

Var med och bidra i sveriges enda oberoende polopolycommunity och kom gärna med fler förslag via ”Tyck till”-knappen till höger.

Nu när sommaren börjar lida mot sitt slut och hösten knackar på så tar vi nya tag här på Polopolyforum.se.
Genom ett inledande möte med Anders Weinitz (produktansvarig på Atex Polopoly) i fredags så  fick vi se en demo av nyheterna i version 9.13 och vi passade samtidigt på att fråga om en del oklarheter som har dykt upp inför en eventuell uppgradering. 

Version 9.13, steg 1 i att skapa en robust metadatasökning

Version 9.13 är det första steget i att skapa en stabil metadatasökning och på plats finns nu:

• Taggmotorn Solr som hanterar indexeringen.
• Nya dimensioner i kategoriseringen (person, företag, taggar, plats)
• Atex Textmining som används för att generera förslag till de nya kategoriseringsdimensionerna baserat på inmatad titel och text i artikeln (Atex Textmining kommer dock ha en separat prislapp)
• Ny publiceringskö som baseras på valda kategorier från den nya kategoriseringswidgeten.

Man har även ändrat de taggar/kategorier som följer med som default och dessa taggar har de baserat på IPTC (International Press Telecommunications Council) i förhoppningen att de ska vara mer användbara än de som tidigare som följde med produkten.

Frågor och svar

När 9.13 släpptes och arbetet med uppgradering/migrering startade så kom en del frågor upp som behövde besvaras , här är några av de frågor som vi fick svar på

Fråga: Kommer vi behöva ha både Solr och indexservern nu eller kommer indexservern  att tas bort framöver?
Svar: Vårt mål är att få bort indexservern under hösten, den kan dock komma att finnas kvar som en fasad för vissa speciella ändamål.

Fråga: Kan man bygga egna dimensioner liknande de inbyggda?
Svar: Ja, men de kan inte kommunicera med Solr i nuläget.

Fråga: Kan man uppgradera till 9.13 utan att använda sig av Solr?
Svar: Ja, det kan man stänga av.

Fråga: Polopolys förslag på topologi som man hittar i dokumentationen ser ut att vara väldigt komplex och dyr om man jämför med många befintliga system, är det något som man måste följa för att detta ska fungera eller går den att simplifiera med lokala Solr slavar på befintliga fronmaskiner o.s.v.?

Svar: Ja, det går att simplifiera. Detta var bara en rekommendation och vi ska se över om vi ska uppdatera dokumentationen eller om vi kan länka in bra information till Solr:s egen dokumentation.

Vad kan vi se fram emot i verion 9.14?

Det är fortfarande ganska tidigt för att prata om detaljer i version 9.14 men i stora drag så kommer det handla om två saker. Det ena är att skapa stöd för att kunna hantera plugins på källkodsnivå, detta så att man enklare ska kunna dela fälttyper mellan projekt. Det andra man kommer lägga krut på är att förbättra prestandan och skalbarheten på frontarmaskinerna.

Mer om detta i kommande inlägg senare i höst.

Polopoly släppte igår version 9.13.1 och bland många små fixar så finns förbättringar inom sökning, dokumentation och XML-export.

Alla ändringar listas nedan precis som på Polopolys supportsida.