9.16.1 General Release Notes

Jun 01

General Release Notes

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.

GUI performance improvements

One of the major features in 9.16.1 is a collection of performance enhancements which will make the Polopoly GUI run a lot quicker for most customers. This has been achieved mainly by consolidating and slimming down static resources in the GUI and minimizing the number of reloads of such resources.

Examples include:

  • All GUI related product stylesheets have been merged into a single file named polopoly.css
  • Lazy initialization of tabs where possible
  • Removal of MochiKit dependency, minification and consolidation of the remaining JavaScrips into four files (down from 32)
  • The bundled FCKEditor has been slimmed down
  • All static resources under /polopoly now have correct cache headers. (For development it is possible to disable this feature by commenting out the StaticFileServlet in web.xml)

Performance has also been improved by optimizing the way lock information is checked and by tuning the default cache time for lock information. Many default content lists have also been modified to only show the top 30 entries instead of all entries in the list. To show the remaining entries a ”show all” button has been added. This behavior is configurable. See change note: #11782.

In-context editing, site specific categorization, widget profiling, browser compatibility and more

Apart from the performance improvements there are a number of other useful fixes in version 9.16.1.

The in-context editing has been updated. When saving content, the save will now also propagate down to any in-context content being edited within the same template. Furthermore, editing an in-context content and then pressing edit on the content it is visible in will result in the context content keeping its state.

Sounds complex? Try it out by editing the Alt-text of any image in the Standard article in Greenfield Times.

The categorization capabilities in version 9.16.1 has been extended to include site specific categorization. A new categorization tab has been added to the site template where you can configure the category dimensions to use. Every category dimension has been extended to support a custom Atex Text Mining plan. See upgrade notes for more information.

In 9.16.0, profiling support for Elements was introduced. This capability has been extended to GUI widgets in version 9.16.1. It is now possible to profile Orchid Widget lifecycle operations such as init(), render() and update() with the Metrics Reporting tool. See the Developer’s Guide under ”Profiling Polopoly web applications” for details.

The constant battle for browser compatibility continues in version 9.16.1. Issues with popup menus in combination with frames on Internet Explorer 7 and 8 have been addressed. The Velocity code in flash.vm now also generates Internet Explorer-friendly markup.

These are the major enhancements in version 9.16.1. See the detailed change list in the forum

Taggar: , , , ,

Vårstädning – ta bort gamla inputmallar ur ditt källkodsträd

Mar 31

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
  8. Klar!

Taggar: , , , , ,

Så blir ditt polopolyår – det ser lovande ut

Feb 16

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.

Taggar: , , , , , , ,

Polopoly developers’ responsibility

Nov 18

kvinna_med_manga_hander-smaller

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

Taggar: , , , , , , , , , ,