References:

Note - this document refers to a set of templates that will be created, for the concept of reworking some of the STK code features, see: Concept - Integrate STK features into Magnolia

Purpose

Problems

  • The overall design of the page templates are too restrictive to specific use cases, making it difficult to build a website that does not match the specified use cases.

  • The master page template (main.ftl) has an outdated html structure. Also the idea of having one html page structure for every project is flawed. Implementers have different needs and different in-house approaches to web projects. CMS's that do not respect that alienates front-end developers. It would be fine to provide a main.ftl which can be thrown away - but many of the components depend on the html structure in this file.

  • There are so many templates that it is hard for someone to learn.

  • The example theme (pop) is entangled with the templates. If you remove the theme, then the components do not work. But it is difficult (and not best practice) for a front end developer to attempt to use the theme, and simply override some classes.

  • The design and components are outdated, rather discouraging than encouraging prospects.

Goals

  • Good impression - Developers evaluating magnolia should get a good impression that our offering is up to date.
  • Enable and encourage best practices - Front end best practices are evolving for good reason - we should ensure that our offering incorporates them.
  • Support the reality of how front-end developers build modern websites.
  • Easy to learn.

Proposal

The Template Kit

Principles

  • Template set is so reduced that its easy to learn. Just demonstrates key templating features.
  • Flexible enough that it could be used with most front-end frameworks. (flexible template kit?)

  • Fewer, more generic components - ie one teaser.

  • Open areas by default - every area accepts all components. If you add component availability node, then it restricts it.

Front end best practices

  • Be light-weight
  • Start minimal - let people add things. Rather then starting monolithic and cluttered and people have to rip things out.
  • Only include needed css & javascript
  • Only initialize needed javascript - Revise onload script initialization. (components can easily / intelligently plug into that system.)

  • Best Practice HTML5.  Accessible, Valid, Shims, Up-to-date libraries, HTMLBoilerplate.

  • More wrapping elements. & classes to assist with responsive styling (debatable)

Templates

  • Pages
    • Generic Page
    • Dynamic List Page (Aggregation Page)(Category and/or contenttype as fragment/querystring)
    • Dynamic Detail Page (contenttype and/or ItemID as fragment/querystring)
  • Components
    • Dynamic Navigation
    • Responsive Column
    • TextImage
    • Teaser
    • Teaser Collection
    • Content example?
    • Dynamic Content List (Category based / or specific items / or date)
    • Contact Form (Direct to ContentApp)
    • Youtube (at least one web/service integration should be included)
    • Social Sharing
  • Move content components to content apps
    • The use case components such as news, events, faq, glossary, commenting should move to their own modules.

Content Pool Components. Teasers & lists that filter based on categorization & sorting mechanisms (For example sort on “date” for News / Events / Blog).

New Demo Themes

  • pop is outdated.
  • Hire professional designeers? - or find really nice themes on web to borrow from.
  • Use BEP or equivalent CSS patterns.
  • Have 3 themes that right away show off how much they can change things.

    • Wireframe. Absolutely minimal. No style to get in the way of understanding what the templates are. Can be used to build out information architecture of sites.

    • Clean. Light modern style.

  • Support Bootstrap or other theme tech so we can have a huge ecosystem out of the box.

Implementation

TBD.

Thoughts:

The MTK should use the Javafree module approach and store all of the configuration and templates as simple files in a directory.

Question: But then what about the template models - Could the main model heavy lifting be in main somehow, so that the models for the templates could be simple Groovy classes? 

 

Use Cases

To help us design the template set - we should have 3 diverse use cases that we keep in mind, even if we do not actually build finished demo-sites. Possibly:

  • Content Pool. A news site - which demonstrates a content pool of news articles & categories with a home page, dynamic category-based "list" pages, and "detail" pages for each article.
  • Web Application. (SPA: Single page application) An content-managed instance of the classic "TODO MVC" using the angular.js framework. Find here: http://todomvc.com
  • Landing page. A one-page marketing-focused scroller with a call to action at the bottom - signup form or contact form. Probably with fancy scroll-effects and perhaps a full browser video background.

Etcetera

Naming

Possibly called Minimal Template Set. "Template Set" is more accurate than Kit. As this should simply be a set of templates. Consider that we should have several of these things - so should they all be called Template Kits? Template Sets? or simply Themes? But we have a tradition of Template Kits - and companies have developed their own - so maybe best just to stick with it.

Things we should really look into if we have the opportunity:

TemplateSet: Twitter Bootstrap.

Twitter Bootstrap is so popular and useful that we should provide it as an extension of the MTK out of the box.

This would have the added benefit of demonstrating how we see a multitude of specialized template-sets can be created for Magnolia.

It should contain pages and key components for the responsive grid like rows and columns. It could also support a very limited subset of the special components such as the navigation.

Natural Templating / Frontend Templating

Ideally we should really look into Mustache / Thymeleaf - new AEM (Adobe) templating before we start to make sure we're not missing the boat here. Can we use a templating language that front-end developers are already used to?

Template Model Mixins

Consider Vivian's comment at the bottom here: Concept - STK improvements

(A proper way of creating compound components built from "facets".)
Maybe not with "facets" but could there be a simple way of building up models via composition / mixins. 

 

  • No labels