Go ahead. Read that again.
Yes, we really do believe Magnolia 5’s GUI will be better than any other web based CMS on the market. That is a strong aspiration, agreed, but then again it’s been Magnolia’s core aim from day one: “Simplicity on an Enterprise Scale” for us means a CMS that is intuitive to use and works well for enterprise use cases. We have shown Magnolia CMS can cover enterprise use cases. Now its time to deliver on the usability part.
Setting a goal means adjusting focus. Magnolia 5’s focus is on user experience.
Magnolia 5’s usability shall amaze content authors with a high-usability interface not just when using a desktop browser, but also on an iPad and other mobile devices with a touch screen. With such high goals, you better choose a very good toolkit for building Magnolia’s new Graphical User Interface (GUI).
At Magnolia Conference 2010, Philipp and Daniel talked about Magnolia 5.0, and specifically about how we were evaluating Vaadin as our framework for the next-gen AdminCentral (our administration interface) in Magnolia 5.0. After a lot of debate (both internally and with the community) and some proof of concept development, we finally decided to stop tinkering and take the decision to go with Vaadin as our toolkit of choice for the Magnolia 5.0 GUI.
Show Me the Veggies!
If you'd like to see the Vaadin/Magnolia synergy in action, take a look at above video. This is a proof of concept. Things will look completely different with the final Magnolia 5.0, but it shows that Vaadin is able to work for the things we have in mind. It also shows a nice idea about building a graphical dialog editor.
Consistent User Experience Across All Input DevicesMagnolia's tagline is "simple open source content management" and we take this to heart. We want content authors (and developers) to be delighted with every aspect of Magnolia. Very simply, Vaadin helps us meet this goal because the people that build Vaadin share our philosophy. They really care about the user interface.
Out of the box, Vaadin comes with some great-looking UI components, which certainly helps for first impressions. And not only that, but it lets you put them together into a slick and intuitive interface without leaving behind a trail of messy code. However, shiny widgets alone don’t make a good user interface. With Andreas, Magnolia has a dedicated and experienced user interaction designer on its team who completely shares our vision of how things should work. Andreas has worked for months defining basic interaction patterns and hammering out how an interface must work to support not only mouse but also keyboard and touch as input devices for common Magnolia operations. So the next time you hit the down arrow on your keyboard to navigate down through the AdminCentral tree, it will actually work!
Touch support means Magnolia’s administration interface will work on an iPad and other mobile devices requiring touch support. It also means that Magnolia 5’s AdminCentral will likely be completely accessible, a feature often requested by governments but hardly found in any existing CMS.
One benefit of how we will utilize Vaadin, using shared components and pure Java packaging, is that the overall user interface will be much more consistent, regardless of whether a module comes from Magnolia's core developers or from an external contributor. This means shorter learning curves and more shiny, happy users.
Standardization is a good thing and Magnolia has used existing code and supported standards wherever there was a match with our needs. The GUI library really is the last major part of Magnolia that was non-standard, simply because what we need did not yet exist.
Besides using a standard GUI library, one of our original technical goals for Magnolia 5.0 were to decouple AdminCentral from the server. Alas, our research made it clear that still no GUI framework exists today that fulfills all requirements at once. Vaadin comes with built-in listeners and data binding for its UI components, and it's already tested to work on major browsers, so it covers a lot of what we need. The framework is server-side, which brings a lot of benefits for every developer working with it, but it also means the coupling between client and server is not quite as loose as we originally envisioned it. Still, there is a lot to like about it:
- Rich widget framework
- Out-of-the-box theming
- Java developer friendly
- Close to Swing
- Can integrate any GWT-components
- Rare GWT-compiles (compared to plain GWT)
- Testing with pure JUnit
- Apache License
- Well documented
As Philipp discussed some time ago, Vaadin uses server-side events, which could impact performance, an issue that is particularly critical if you wish to provide a snappy user interface on the web. While we've seen that a server-side framework in itself doesn’t imply worse performance than a pure GWT approach (an alternative we considered), we will need to invest more effort on that end to achieve what we want. On the positive side, running an entirely server-side architecture makes the system more secure, and Vaadin's JSON-based UIDL allows for future extensibility. Vaadin is helping us kill multiple birds with one stone here: we're reducing server load, increasing security, future-proofing our work and creating a better user experience at the same time.
For those of us who like to be home at least occasionally, Java is a fantastic choice to build applications, and Magnolia 5 with Vaadin will make it easier than ever to build extensions for Magnolia and help the Magnolia community grow, because now, you can also go wild on the front-end.