The future eZ Publish Platform backend UI is "here"!

Today, we are happy to open the PlatformUIBundle git repository on Github. To be honest, it’s also a great personal achievement for me since it’s the result of exactly one year of work!

As its name suggests, this bundle provides the user interfaces which will replace the good old legacy admin interface. It actually provides the Platform UI Application which is divided into two different parts

1. the editorial part where you’ll be able to manage your content (browse, create, edit, remove, move, copy, ...)
2. the admin part where you’ll be able to achieve technical related tasks (manage users, languages, sections, content types, ...)

Key concepts

The Platform UI is build around some key concepts and goals:

• An application: it is build as an application not as the website. Of course, it still relies on web technologies (HTML5, JavaScript, CSS) and it will still be available through your web browser.
• Strong focus on User Experience: we want to reinvent the User Experience for all our users (editors, business users, developers, ...) and provide a really good UI.
• Touch friendly: this goes without saying in 2014, the User Interface will be touch friendly
• Extensiblity: we want the PlatformUIBundle to be extensible. We know it is mandatory for integrators but this is also required for us as we want to provide several products on top of it.

Architecture

The Platform UI Application is based on the  YUI Library and especially on the  YUI App framework. We chose YUI because it provides a full set of consistent and high quality components.

As written before, the PlatformUIBundle provides an application which is executed by the browser and is divided into two different parts with two different strategies in the way they build the pages:

• the editorial part uses  our JavaScript REST Client to issue REST calls in order to interact with the eZ Publish Platform installation. From those REST calls, it extracts the data it needs and basically executes some templates to generate the resulting HTML code
• in the admin part, the pages are the result of one regular AJAX request which response is of course generated by a regular Symfony controller and where you can use for instance a Twig template.

You probably wonder why we are implementing two different ways of building pages. On the admin part, we wanted to reuse some code that was produced in a very early prototype that was build in a more traditional way. In addition, as a great side effect, having the base components to include an AJAX response transparently in the application will allow any developer to extend it without a deep knowledge of the complete JavaScript stack. In other terms, in some use cases, extending the Platform UI application might be as simple as writing a Symfony controller and a very small amount of JavaScript code!

Where are we?

You can login in the application, browse the content through the content tree, display and edit content (depending on its field types), and, in the admin interface, access a system info page, the list of sections and their details. Most of those features are presented in the following screencast:

As you can see a lots of features are missing, like displaying sub-items, a complete version management UI, almost everything in the admin part, and some blanks need to be filled there and there ;-) At a lower level, we need to think and to implement a proper l10n/i18n system, the handling of the user’s policy, the extensibility points, ...

Contribution ?

So this public opening is a great milestone but it’s only a small steps in a long journey. As usual, your feedback is more than highly welcome, be it as a comment here, issues in JIRA or as code through a pull request!