A vision for frontend development

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!

A summary of the interview 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.

Vision

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.

Goal:
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.

Now:
Vision:
Vision Statements:
  • 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.)

A note on Java: Java is a key component of Magnolia and we are not interested in changing that. However, currently for best practice development Java is required for most tasks, while the truth on the ground is that most people are not Java developers and  face hurdles in setting up and maintaining a Java developer environment and proper build. We envision a more flexible Magnolia that allows the non-Java developers to create without barriers by simply working on files in a directory as they are familiar with from working with web MVC frameworks or other CMS systems. They don’t need a Java developer environment, just a Magnolia bundle. That said – everything can still be done as now, and for customizations and integrations Java is used to create new modules, override classes, etc. It is a Java CMS.

Some Concrete Topics

OK, that was all very vision-y and high level. Here’s a few of the tangible topics that emerged:
  • 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.
Getting up to speed sooner:
Looking for more juicy detail? Please have a look at the Frontend vision Management on the wiki:
http://wiki.magnolia-cms.com/display/DEV/Ramp+-+Lower+Entry+Barriers

Your Vision

What is your vision? Can you condense it to three sentances? (I know that’s unfair – I couldn’t.) We appreciate your feedback on the ideas presented here. Or, for more specific feedback, comment on the wiki pages linked to above.
Please help us choose the best path for Magnolia:
Which of the concrete tasks is most important to you?
You get 18 votes which you can allocate as you like to the tasks.
Tips: You can vote more then once for each task. Click triangles for more information on each item. http://www.dotvoting.org#vote21238001126vw9t2cctzz
-
Rating & Voting closes this Friday, the 28th.
-
-

4 thoughts on “A vision for frontend development

  1. I like where this is going – it’s definitely cool to see you are listening to developers.
    As an aside, before starting this change I think magnolia 5 needs work in two important areas:
    - stabilize all the little annoying details (I know you’re working hard on that)
    - provide a sensible, mostly automatized migration path from magnolia 4.4 to 5

    On topic, I have the following thoughts:

    - no java: the tight integration with java is one of magnolia’s most awesome features, and you should be careful not to lose it. That said, the STK is (IMHO) “model-heavy” and a lot more could be done by moving functionality into cmsfn, stkfn, damfn, etc… and handling it from the templates.

    - additional STKs: we’ve always found the way to go is to use the STK models and renderer, but do our own templates. Implementing a design by modifying STKs HTML and CSS always seemed like more work to us. This way of working also means our templates and components are always tailored to the site/design – we’re not abusing existing components for purposes they weren’t designed for.
    So extending magnolia with “additional STKs” seems like a natural idea to me. I very much like the ideas of a “lightweight” template kit, and a “bootstrap” template kit. These could also be used to create easy to follow tutorials on how to create your own template kit.

    - packaging template kits: it would be awesome if an entire “template kit” or design, including template and site defs, templates, theme, dialogs, resources and sample content could be “packaged” and exchanged easily between magnolia instances. Such “template kits” could then be traded on forge and/or the magnolia app store.
    Something like the packager module, but easier to use…

    - rapid prototyping / agile deployment: keep it in the repository! supporting development modes with stuff on the file system is also nice, but having everything in JCR makes development fast and flexible. Don’t lose that!

    Ok, that’s all for now – a bit more than 3 sentences, sorry…

  2. Interesting question.

    One of the things I often struggle with is the idea that the STK offers a “standard” website layout. The idea of predefined areas ( platform, stage, extras, footer and so on ) and navigation ( horizontal and vertical ) seems out of date.

    With a more generic, lean/minimalist approach to components, it would be infinitely easier to give a project your own spin without sludging up the code. I ofter start with a rewired version of the STK with minimalist components and templates. I also add a a few grid components, such as columns.

    This allows editors and designers to build complete layouts without requiring a frontend or backend engineer, freeing up developers to focus on building more interesting things, like snazzy widgets and hip-to-the-groove visualisations. ;)

    Ps. I think a templating kit should leave any developer free to choose his own frameworks and libraries to create a frontend.

    Pps. I’m working on creating a templating kit that’s a rewired version of the STK here: https://github.com/DrOof/phi/tree/master/master/phi-site/phi-templating-kit

    • Thanks for your input Oliver. Your comments/struggle is a welcome validation of the approach that we are currently planning for 5.4 release. We’ll be creating a new slim template set (Minimal templating kit?) along the lines you describe. We dont have a page specifically for that – but you might be interested in this page we started at last years conference to collect input about improvements for the STK: http://wiki.magnolia-cms.com/display/DEV/Concept+-+STK+improvements
      Join the discussion at the bottom if you’d like.

      I look forwards to seeing what you do with the Phi kit!

      Cheers, Topher

Leave a Reply

Your email address will not be published. Required fields are marked *

*


× six = 42

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>