How should one develop web projects with Magnolia?
Better put: How should Magnolia support people in developing the public facing website? To answer this question I interviewed 23 people with a stake in the answer – ranging from the CEO, CTO, sales, services, training, & developer teams at Magnolia – to product managers, frontend and backend developers at our development partners. I threw away a detailed list of questions and just asked “What do you think of the STK and frontend development with Magnolia in general?”
tl;dr? You can vote on the Vision statements and tasks. Links at the bottom of the post.
It was encouraging that most responses reinforced one other. It became clear that we need to take a step back and re-evaluate how some of the basic functionality works, and which features are still necessary. This stands to reason, Magnolia has been developed over 10 years under changing circumstances and requirements.
It was a pleasure to meet many of you during the interviews. We appreciate the time and thought that you put into them. But as you can imagine, it was very challenging to distill a recommendation from 50 printed pages (15 meters of A4′s) worth of valuable input!
After I made my first internal presentation of the interviews and analysis (including earlier work such as the STK JAM unconference session from Magnolia 2013 conference, and even an STK evaluation done in 2010) we realized that the input went further then just the STK and frontend development, and spoke eloquently to a broad initiative of lowering the barriers to entry for Magnolia.
In this blog post, I’d like to present the resulting “Vision” for developing with Magnolia – with a focus on frontend development tasks. Please keep in mind that this is a vision statement, subject to revision, and not a roadmap.
What is the point of a “vision”? It is to guide us in deciding which initiatives, efforts and tasks will really help our product and its users.
Consider three types of users with various levels of technical skill:
- Author / Business user – Works in Admincentral, but has limited html or java knowledge.
- Frontend developer – Understands html and templating, but has no java knowledge.
- Java developer – Has a java build environment and can build project.
Expand the range of tasks that the Author and Frontend developer can perform, while flattening the learning curve for everyone by reducing what one has to know and the steps to perform important actions.
No Java required. Possible to develop websites without Java code or infrastructure.
Possible to create apps and custom fields without Java.
Developer needs only a Magnolia bundle, admincentral, and files in a special directory.
Agile deployment. As an author I can easily create & deploy new sites & templates from admincentral with no Jar deployment required.
Speak the language of frontend developers. As a frontend developer I feel comfortable and am quickly productive because magnolia has good integration points for front-end frameworks & templating and supports my frontend build tooling / resource pre-processing pipeline.
1 hour to learn, 1 day to create. Templating system and main processes are straighforward and can be learned in 1 hour. Flatten learning curve and lower the overall amount one must know through simplification of the template set and sensible defaults. The magnolia interface and template set(STK) are so efficient that a frontend developer can create a good looking and functioning prototype in a day.
Rapid prototyping. As a partner I can prototype a project with my client directly in AdminCentral because the page editor performs so well, and the template set and themes are flexible enough to match the most common requirements.
No documentation necessary. As an evaluator or non-technical user, I understand enough to create and manage a website with only the user interface as my guide. Wizards and inline help enable me to create website projects, microsites, templates, dialogs and apps.
Stunning demo. The demo project is an attractive, realistic website that developers and prospects can relate to. Through it they clearly see how magnolia addresses their needs, and understand and appreciate magnolia’s templating technologies. Additionally it demonstrates the usefulness and efficiencies which the default template set brings.
Demo library. As a developer I can more quickly understand what magnolia can do, and solve my use-case problems via the patterns, recipes & examples shared in a consistent format in an online demo library. A demo can contain: description, tutorial, snippets, slides, module download & videos. Demos could come from conferences, knowledge transfers, webinars, meetups, projects.
(Examples: Ajax component. Ajax page.)
Some Concrete Topics
- Resources are hard to work with. They should work equivalently to templates.
- There should be a clean “loading cascade” for templates and resources that includes at least: loading from the classpath, the filesystem, the repository.
- Working with configuration is problematic, mostly because it behaves so differently from code and templates. Two leads that we will investigate are:
Readable bootstrap files – replacing the JCRSystemView xml format with something human readable and editable.
Volatile configuration – Defining configuration in files (either via code, or declaratively with xml or json or …) that get loaded at system start, and are dynamically reloaded when file is changed, that does not necessarily get written to the config workspace in the repository. The goal is to treat config more like code/templates/resources so that config goes into version control at the same time and so that things like module updates and uninstalling become simpler. We call this ConfigByCode and ConfigByFile.
- Templates should become more modular by including (or declaring) their resource dependencies like js libraries, css, images and i18n property files. On the flip-side this makes the theme cleaner by removing the resources that really belong to the component templates.
- A new minimal TemplateSet with a limited set of flexible templates. And a new minimal theme to go with it. The current STK TemplateSet takes the kitchen sink approach including a large number of compatible templates for many common use-cases. This is great for experienced Magnolians, they can prototype sites in two days flat because so much of the functionality is already there. But its overwhelming for new developers. A minimal TemplateSet will help new developers understand Magnolia templating quickly. It will be a better starting point to create their own TemplateSet for the projects they are working on.
- The version 5 adminCentral configuration tree needs improvement: faster in-place editing and the return of the Copy and Paste actions. Looking forwards, the tree should provide more assistance when working on nodes – at least it should provide information about what nodes & properties are required or available. Eventually it could provide wizards for working with config for apps, subapps, dialogs, actions, etc.
Tips: You can vote more then once for each task. Click triangles for more information on each item. http://www.dotvoting.org#vote21238001126vw9t2cctzz