Dylan Jay: p.a.toolbar: the UI revamp Plone didn't know it needed

I was recently doing a kind of show and tell with another CMS developer. I was showing off Plone and they showed me their (PHP based) CMS. Even though this other CMS made you have to jump back and forward between the backend editing and viewing the site, I had to admit it looked slicker. Their CMS has less features, wasn't as easy to use yet it made you feel more excited. Think looks don't matter? We had some feedback recently from a potential customer that their bosses went with Wordpress because "it looked nicer". But let's skip that people shouldn't buy things on looks alone and talk about why Plone doesn't look as sexy as it could. 

Other CMS' often look slicker because they were using more up to date widgets and a theme in their editing environment that conveyed up to date practices. Plone on the other hand, out of the box looks ok but not modern nor does it convey the sophistication that Plone's features deserve. It feels... basic. This is how it looks out of the box but the reality is that many people who see Plone for the first time aren't developers and aren't seeing sunburst at all. They are seeing a themed version of the editing UI. Unfortunately it costs money every time a developer wants include Plone's editing UI directly into a custom theme.  At PretaWeb we've decided it's worth it to give users the easiest possible editing experience, however since CSS is fiddly and we don't always design the HTML ourselves, the final look of the merged editing UI can often look very underwhelming. I know many other companies save themselves time and remove the editing UI and give the users a different un-themed url for editing. Doing so loses one of the key differentiators of Plone, in-page editing. 

Plone's UI is basic for a very good reason. It has to be integrated into potentially thousands of themes. It can't use complex CSS, heavy JS or a sophisticated design otherwise it makes more work when creating a new theme. In addition any time a core developer might want to improve the UI they are faced with this big wall of backwards incompatibility making any UI change conservative and plain (not that I'm arguing we shouldn't still be conservative). This is also the reason there exists a lot of plugins that patch in updated widgets to different parts of the Plone UI instead of these going into the core.

Luckily there is a solution and it's called plone.app.toolbar, but lets just call in toolbar. Toolbar works by including a small javascript in your theme that when a user is logged in it creates an iframe at the top of the page. The iframe then loads in the whole Plone editing and management UI including all the remaining css and js. The iframe means that the CSS and JS from the themed site and the editing are isolated from each other. All the configuration screens including editing, site setup etc open in an overlay over the whole screen but still pull their CSS and JS from inside the iframe. 

Isolation means you don't need to consider of Plone CSS when building your theme. If you are using diazo, which already reduces the time to theme dramatically, I estimate this will further cut our time to convert an existing theme by half or to a single day instead of two. The icing on the cake with toolbar is that it manages to do this isolation while preserving Plone's in-page editing experience and backwards compatibility with existing plugins that added menu items to the old green bar. Move around the site and the toolbar quickly reloads into the new context. Nice, but the big change toolbar enables, and this is what I hadn't considered till now, is we are now free to iterate and improve Plone's UI without any fear of causing issues to themers. 

PretaWeb, of which I'm co-founder, recently sponsored Rok Garbas $2000 USD to progress the work he had been doing on toolbar. Even though it didn't complete the work we felt it was still worth it. Rok made a lot of progress. The good news is that much of the work on toolbar is happening in p.a.widgets, the aim of which is to create modern replacements to many of the widgets used in plone. The reason p.a.widgets is now a dependency for toolbar is that many of our existing widgets relied on javascript using "onload" events to initialise them. On-load doesn't work when your widget/configlet is loaded in an overlay. This has now been solved by Rok in a backwards compatible way. 

So far p.a.widgets improves the default widgets for dates and tags only. One widget yet to be done is the reference browser (used in related items and in collections portlet). Roche and others (with UI feedback from the Plone UI team and Limi) have been working on a reference browser replacement, based on work started at the 2012 conference. Once completed this will go into p.a.widgets and therefore toolbar. 

Some might be wondering, but what about CMSUI? For those that don't know CMSUI was a prototype created at the Plone UI sprint in Bristol in 2011. There exists a demo of what CMSUI looked like. It was the same concept but it went even further, changing many of the menu's that are in the current "green bar". There were some great ideas but unfortunately it broke backwards compatibility with plugins that added items to the "green bar" and the approach it used didn't work in practice. Toolbar is the more conservative stepping stone. Once toolbar is complete we are free to start improving the toolbar bit by bit to bring in ideas from CMSUI and any other productivity ideas the community has. I want to thank all the work done by many developers of all the iterations and ideas that has gone into toolbar over the past couple of years.