Goal

This page is to collect and discuss ideas for possible STK improvements. This is a rough, unculled list of wishes, not yet a roadmap.

Motivation

Why does the STK need improvements?

  • Good impression - Developers evaluating magnolia should get a good impression that our offering is up to date.
  • Best practices - Front end best practices are evolving for good reason - we should ensure that our offering incorporates them.
  • In-place dynamic ajax content updating should be supported
  • Not Monolithic - Some people are scared away by the standard templates that we provide, we should make it clear that there are different parts of STK that can be mixed and matched. 

Mission 

STK must support the reality of how frontend engineers build modern websites.
STK should enable and encourage front-end best practices. 

Topics / Wishlist

  • Separate STK foundation from templates
    • Just needs to be clear. Documentation should distinguish them - help people to not be scared away
      • You can use the foundation without using the templates.
      • You can use the components without using the templates.
    • magnolia-empty-webapp should probably already have apps for Templates and Resources, and should support inplace templating.
    • Perhaps the STK app group should be renamed to Templating .

  • Create alternative templatesets
    • Classic templateset (what we use now)
    • Grid layout
      • Bootstrap templateset
      • Foundation?
      • Grid thing that SWM guy presented (advantages to this, if we have one of the above?
    • JQuery Mobile templateset
    • Simple demoproject for each template set.
    • Documentation showing that its easy to create your own templateset.
    • Encourage companies to create their own templateset and add to forge.
      • ie - we could build bootstrap - and someeone else might be motivated and do foundation or jquery UI or extJS

  • 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 
    • Clientside form validation (falling back to server side)
       
  • Improve Javascript handling
    • Revise onload script initialization.
      • so that only used things are initialized
      • customers can easily / intelligently plug into that system.
  • AJAX content loading
    • Standard way to load dynamic content?
    • Bookmarkable URLs
    • SEO of dynamically loaded content
    • Support single page websites
      • Tablets / smart phones / 
      • apps (ie phonegap / firefox OS app / windows app)
      • usatoday.com
    • Content transitions
      • Fade / Slide / Zoom

  • Frontend Templating
    • ie Mustache/Handlebars/Hogan
    • This supports client-side javascript frameworks (backbone / angular)
    • Compiled templates ? Hulk?
    • Rest API to retrieve data for templates.

  • Update components
    • Make sure our components are up to date and working well. 
       
  • Support LESS / SASS out of the box.
    • Experienced front end dev do not want to use freemarker to process css.

  • Documentation
    • A clear demo of the components that are available
      • Pizza topping list.
      • Maybe something like the Vaadin sampler.
         
  • New standard theme
    • pop looks outdated.
    • Hire professional designeers? - or find really nice themes on web to borrow from.
    • Have 3 themes that right away show off how much they can change things.
       
  • New templates for running instance
    •  / that no-one can change.
    • What the SWM guy presented - Philipp seemed interested - is this not already possible?
       
  • Make working with Resources easy and as a developer would expect.

Advantages of STK that we want to honor / not break

  • Fast startup - Cool components ready for you to use.
  • Availablity of components - control which components can go in which areas.
  • Responsiveness - Send less resources to mobile devices
  • Channels
  • Image variations
  • +Personalization
  • Easy upgrade to new versions of magnolia
  • Current STK is very good for HTML compliance and accessibility. (But this should be verified, tests added, and an accessibility showcase page should be added.)
  • ...

Concrete Customer / Partner Input

  • Sebastian had a customer recently asking if we supported Bootstrap framework.
  • Mark from Virgin Holidays
    • Frontend developer wanting to use front end frameworks that he already has experience with.
    • "Its offputting to see bloat or bad front-end design"
    • STK Feels too heavy
    • Scared about having to do lots of configuration in the tree.
    • Dont want to be locked in.
    • Is there a way to encapsulate an HTML "module"? It includes its own CSS and Javascript? (Sounds like Angular thing)

Inspiration / References

 

Minimal Templating Kit

Use Cases

To ensure that what we are designing works - we should have several (3?) use cases in mind. These could be used for thought experiments, or if time permits we could build out actual examples.
Better yet - if we could use these use cases internally at Magnolia then they would be even more realistic and we would understand them better. 

Potential MTK use cases

  • Blog/News site with categories (Magnolia developer blog?) - Blog posts are content from a Blog/News app, not pages.
  • Web application - Angular? Classic MVC TODO list?
  • Shop / Catalog
  • Landing page / Microsite
  • Developer quiz (Magnolia Certification Test?)
  • Intranet: ContentApps for people, interest groups, interests, abilities, places, and times.And modules, departments, cells, and concepts.
  • Twitter Bootstrap site
  • Presentation (ie slide deck)
  • Admin UI components
  • Template Apps
  • Magazine
  • Iphone/android/mobile native app.
  • Game?

 

Potential content-set use cases

Maybe we should rather start with a sets of content as use cases. The templating kit must support easily creating a meaningful content experience with any set of content.
As the CMS cell - we should probably get some inspiring high quality content to work with. (Including high quality design)
This will help us when  we want to create convincing demo projects.

  • Intranet - people, projects, processes, interests, roles
  • Product information - brochureware
  • Branded content experience (redbull)
  • Interest / Content (One of a kind cars & photos/videos/stories)
  • News / Blog
  • TODOList - User application data.
  • Organizational + Forms (City / municipality / School)
  • Shop

I guess this goes in the directions of verticals or "Solutions" based on magnolia.

 

 

  • No labels

23 Comments

  1. Natascha Desmarais

    We should also consider what the SWM guys presented at the conference. Will get in touch with them.

    Another thing to consider is if we even go further and make components classifiable like the categories for pages. So you can say "available components for that area on article pages are content components and link components" instead of listing them like "stkTextImage, stkQuotedText,..." (input from Tobias because he is implementing something like that in Blossom! Very strong selling point imho)

    1. Matteo Pelucco

      Hi Natascha, 

      Just an advice, here: Magnolia power is flexibility.
      You provide a framework, but if this framework put limits, it is not useful.
      And we (Magnolia developers) need to re-invent the wheel any time.

      I would rephrase your sentence replacing the words "instead of" with "OR". Enhance (controlled) freedom, don't put constraints.

       

  2. Gerton ten Ham

    I would like to see a better way off overriding template definitions: Now template definitions are in the "lead" during merge with site configuration. I would like to see something the other way around, so we do not have to touch the template definitions (better support for upgrades) when we would like to change something for example a different freemarker template with custom html.

    1. Adrien Berthou

      Hi Gerton,

      1. What do you mean by "Now template definitions are in the "lead" during merge with site configuration." ?
      2. Regarding this other point: "change something for example a different freemarker template with custom html". Currently you only need to reconfigure the relevant node to point to a different file, which is super quick. Or maybe I am missing something?

      1. Gerton ten Ham

        Hi,

        1. In the site configuration there is something called templates -> prototype (areas) and availability which contain some behavior which is merged with the template definition for pages/components/areas. If i remove a page availability in the site configuration, then it is possible that the page template definition contains the visible="true" property and the page template will still be available to the user. This is mind blowing when you consider Site configuration with... well configuration of your site. It might be my lack off knowledge of the STK and best practices, but i like to do my customization/configuration in one place preferably without having to touch the default implementation.
        2. You are right that it is simply changing the relevant node (property), but what if the STK comes with an update for that same node (property)? Will it simply overwrite your customization? I have read somewhere that the best practices in this case is to duplicate the node and make the change there. But personally i find the amount of pages/components (with all kinds off extends) coming out-off-the-box with the STK already a little overwhelming. But according to the concrete customer/partner input which states that the STK feels to heavy i am not alone in this.

        Hope this clarify my original comment better.

        1. Adrien Berthou

          Hi again,

          1. I think you're hitting the "what the hell is inherited?" problem. I discussed about an idea to fix this issue, that is, like when using your favourite IDE when developing in java, you can easily find out the hierarchy of a class, hence, find out what's inherited (or not). Magnolia configuration inheritence is great but there is feature in Magnolia admin central to actually find out the hierarchy of a config branch, that is, I can't find out if the config branch I'm currently editing is not extended somewhere. I discussed this issue with some Magnolia dev & this is apparently something that could be done in Magnolia 5. Not sure if this is the best solution to this problem but I'm pretty confident that would help greatly. This is probably more of Usability issue than an STK issue I believe though (hence, may not belong to this wiki page).
          2. Yes, best practice when you cutomize a configuration is to always duplicate the branch, then make your modifications. This way, any config change coming during an update will only affect parts of the config that should have not customized. I know what you mean regarding the STK, only using what you need is always the best option (a good way to start is by creating a custom prototype based on the default stk prototype) but many people probably learn this the hard way. I believe that the only way to tackle this issue is to "educate" people about this, as in, provide good tutorials, wiki entries, videos, and so on. It's not that complicated in the end but yes, i totally agree, a little overwhelming.

    2. Christopher Zimmermann

      Thanks a lot for your input Gerton.

  3. Boris Kraft

    Lets make sure we stay focussed with what we want to achieve. It is not our goal to solve everybody's dream list of features, as this would kill us immediately in terms of maintenance. The massive benefit of STK is that config is standardized. This is a huge benefit for large customers that work with many different in-house and/or external teams. Of course there is also a lot of nice functionality there etc. But a grid based system is not semantic! So let the agencies work with whatever they like, but we should stay true to providing what makes sense for our main goal, see above.

    I agree that we need to rework STK, but the goal should be to simplify and lower the entry barrier, not to provide ever more options. For instance, anything that allows people to actually configure STK with a UI would be massive.

    I agree that we have to make sure people understand how to use STK and how to replace anything without losing the major benefits. For instance, using standardized dialogs across an enterprise makes sense, even if the render part (templates) are completely custom.

     

    1. Christopher Zimmermann

      Thanks Boris, you are correct this is basically a big wish list - which will need to be analyzed and culled.

    2. Christian Ringele

      "For instance, anything that allows people to actually configure STK with a UI would be massive."

      -> Concept - Project Creator App

      Probably going bit to far, but steps 2&3 of "Main steps what the app would do" goes into this direction.

  4. Matteo Pelucco

    Just few topics I would like to fìnd in a new STK (between what is missing today): 

    1) Responsive Images techniques

    2) Modern favicon support (virtual uri)

    3) Automatic CSS / Javascript minifier

    4) Automatic CSS / Javascript cat (I mean, if I have dozen CSS files defined for a theme, I would like to have a API shortcut that allow me to serve a "all.css", containing all files (minified), one by other following the node order.

    A framework to consider, maybe with a single-page ad-hoc app: AngularJS

    1. Christopher Zimmermann

      Thanks for your input Matteo, its appreciated.

    2. Zak Greant

      AngularJS is pretty darn cool – and it would increase the number of people able to meaningfully extend Magnolia.

  5. Boris Kraft

    I just want to reiterate/clarify one thought: a big advantage (in my mind at least) of STK are standardized content types and standard dialogs. These should be kept and possibly separated from the rendering part. We could have "Standard Content Types" and "Standard Templates" to show how you can use the content types. A separation of concerns, so to speak.

    1. Matteo Pelucco

      Hi Boris, not only.

      We (3rd part developers) look also into FTL templates and "pattern" to understand which is the "Magnolia way-of-doing".

      E.g.: how can I iterate over a list of content? How can I produce a DAM link? How can I use image variations? How can I access Magnolia API? At time of writing, STK with demo projects and demo site provides the unique way to understand, in official way, how to do common things in Magnolia CMS.

      IMHO, providing modern patterns should be the third key asset for the new STK. Separation of concerns ok, but not only between 2 concernds.. maybe more..

  6. Training Participants - FullStack Developer

    I would like to know what the use case will be for having AngularJS support in a website context (besides it is being new and cool)? 

    1. Gerton ten Ham

      This comment was made by me (Gerton ten Ham) on a laptop which automatically authenticated me as the Magnolia training use apparently (sad)

    2. Matteo Pelucco

      I'm not saying that AngularJS will be the most widely used JS framework for MVC in the future.

      But 'today' it seems to be a very very good option: it is considered a top (top3, I would say) frontend MVC JS framework. 

      If you want to have a sample of a single-page, JS driven App in STK, you can not avoid to include an example made with AngularJS (as well an example based on Backbone / Ember / GWT).
      AngularJS is new, but it is impressive.
      And yes, it is 'cool'. If I would want to sell a templating kit (maybe with some 'cool' demos..) I would have AngularJS with me.

      Another hint: count the CMS supporting AngularJS out there.. 

      1. Boris Kraft

        AngularJS will die like everything else that is hot on the front end right now. The future are web components.

        1. Christopher Zimmermann

          AngularJS is a production ready polyfill for web components. It lets us use the future concepts today. Plus all the 2way binding goodness, scope, dependency injection. And it has massive production adoption. But personally I would also nominate templates that facilitate working with React templating because its so super fast at reacting to changes in the content/data.model. Well, we'll see what we can do for 5.4, it might start quite more basic that that. But if we make the templates truly modular and with high dropin-ability, then maybe some community members could take on some of the fun integrations with these evolving new frameworks. 

          But yes, it seems like web components will be the way to go once they mature. I think angular is even planning to drop some of its own libraries as the various web component standards go final in the browsers.

          1. Magnolia International

            From google perspective, AngularJS is not the future if you look at the amount of sessions in the two last Google IO: 1 session for AngularJS in 2013, none in 2014. 1 session for polymer in 2013 (Google implementation of web components) and 8 in 2014 ...

            In addition, the way we declare a component in Angular is too far from the W3C sepcs: It should be declarative, Angular uses a programmatic API in JS. The gap is too important too make AngularJS a 100% web component framework.

            If AngularJS survives in the next few years, it won't be winning the battle on Web Components, it will have to offer value that native web component frameworks (polymer or xtags) won't bring. the reason why people are choosing AngularJS today won't be the one in the future.

            1. Christopher Zimmermann

              Thanks for the input Nicolas. Yeah - as far as I understand its the intention of Angular to drop its own libraries and adopt web components when they mature. Obviously we dont want to invest energy into something that will be dead in the near future, conversely we want to enable people to be productive on production ready frameworks with high adoption. This conversation may prove academic for 5.4 as we're focussing first on the groundwork - but its still great to get the diverse feedback.

  7. Vivian Steller

    My no.1 missing feature/problem in STK/Magnolia Templating is:

    A proper way of creating compound components built from "facets".

    Let me describe the problem by giving an example: if you are to create a TextImageTeaser component, right now the common way (from a design/maintainance perspective a very bad one) is to have a ModelClass extend TextImageModel and add Teaser related methods to that model class. Or your TextImageTeaserModel extends TeaserModel and you add TextImage related methods by copy/pasting. This is what currently happens when re-using/"extending" STK template model classes.

    However, this often (if not refactored eagerly) leads to lots of code duplications, very similar but different implementations - a low semantical type coherence to speak theoretically.

    This could be solved by introducing "facets". The idea is to create a component by composing facets. For instance, the TextImageTeaser component would be composed of the "text facet", "image facet" and "teaser facet". Each facet might come with its own dialog fields or tabs, with it's own set of templating functions and so on. The point is, that not inheritance but aggregation/composition is used in Model/Definition classes: in the future, this might also work well with configuration by annotations, for instance (pseudo code):

    @Dialog("Text Image Teaser")
class TextImageTeaserModel extends RenderingModel {
	@Tab("Text")
	TextFacet getText() {...}
 
	@Tab("Image")
	ImageFacet getImage() {...}
 
	@Tab("Teaser")
	TeaserFacet getTeaser() {...}
}
 
// image facet for instance might look like
class ImageFacet extends AssetFacet {
	@Field(class = DAMAssetFieldDefinition.class)
	String getAsset();
	...
}

    One could also keep the facets external to the actual models, e.g. provided by a "facet" templating functions library:

    @TemplatingFunctions
class Facets {
	// initializes a stateful facet of the given type for the given childNode of content
	static <T> Facet<T> get(Class<T> facetType, Node content, String childNodeName);
}

    In Freemarker one would access the facet like:

    [#assign image = facets.get(ImageFacet.class, content, "image") /]

    This would greatly improve maintainability and coherence of different "aspects" of a component, and is extensible.

    What do you think?