Page tree
Skip to end of metadata
Go to start of metadata
Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 89 rates


A 1to1 implementation means that from an existing website we have to provide a mobile version.
Exactly the same pages are displayed on a mobile but rendered differently.
Pages have to be designed for mobile devices respecting the mobile web best practices.

According to this definition of a 1to1 implementation of a mobile website,
we can enumerate few goals to reach:

  • Exactly the same content has to be used, no new pages created
  • Some areas have to be disabled on the mobile version
  • The web pages and all the elements has to be optimized for a mobile experience
  • Images have to be smaller
  • The size of the page has to be reduced (less loading time)
  • When the user access the url of the website from a mobile he has to be redirected to the mobile website, switch mechanism

What I did

The main idea is to use the multisite definition mechanism.

I started from the Demo Project and tried to provide a mobile version of it.
Only the home page is done (the other pages are working but not redesigned for a correct mobile experience).
The development of the mobile website is based on STK.
You can checkout the project here

First I created a new site def,
Mobile site definition:

  • extends Demo Project site def
  • has its own domain (eg. m.localhost vs localhost)
  • provides its own prototype definition in order to
    • turn off some elements (vertical nav, promo, extra, meta are disabled)
    • and also to provide new template scripts (main.ftl, branding.ftl)
  • has its own theme

Mobile Theme:

  • stylesheet:
    • style.css (STK style)
    • mobile.css, this stylesheet modify the style of several elements for a better mobile experience
  • defines new image variations in order to provide smaller versions of the images

I modified some templates scripts.

  • main.ftl of the desktop website, I add a JS managing the redirect to the mobile version
  • main.ftl of the mobile website, new meta tag
  • branding.ftl, removed some elements
  • I also modified some paragraphs scripts

Here the result of the home page rendered on a Iphone.

Another version of the home page


Here I list all the drawbacks I found

About the configuration:
  • even when I disable areas in the prototype definition of the mobile site def, it could be enabled by a template definition.
    For example, if in the prototype of the mobile site def I disable the promos Area, then if a Template (e.g Section) enable this area explicitly, all the Section will display the promos Areas on my mobile website.
    Same thing with the template scripts, for my mobile website I want a specific main.ftl, if a template definition defines a main.ftl, this one will be used.
    And in a project it's often the case that we have to override site definition.
  • with the paragraphs, I have the same problems. I wanted to modify the teaser layout, I removed the abstract text and I also inverted the position of the image and of the header. When I did that, these changes were applied to the 2 sites, and this is normal because a paragraph has the same definition for both site, but for me it's a drawback. The layout of some elements on the desktop site and on the mobile site could be different, and some layout modifications cannot be done only with CSS (when I want to remove the abstract of the teaser, I really want to remove it from the page, and not only to hide it, one of my goal is also to reduce the size of the page).

Templates and paragraphs have the same behavior and provide the same information / layout irrespective of the website displaying them. In this case it's really difficult to provide an enhanced mobile website.

What I need (suggestion):
I need that the templates and paragraphs behave differently on each site, in other words: I need that a template/paragraph has a definition per site def.
For example, the template stkHome could have a template def for the desktop site and another template def (sub definition) for the mobile site. In this sub def, I would like to define only the properties I want to override (like the template path), I also want to define for which site it should be used (by indicating the site def name).

About the content:

I provided a smaller logo for the mobile version and I also hide the Home page from the navigation. The problem is that these changes are visible on both websites.

What I need (suggestion):
Dialog could provide specific properties only for the mobile website.

About the HTML structure:

When I did my slight redesign, I started from the HTML prototype of STK and I modified the CSS. This is the best practice when we start a new project based on STK, but this HTML prototype is not really designed for a mobile, it's too complicated. There are too many HTML elements we dont need.
The style.css is huge and there are a lot of JS script loaded (and maybe we dont need all of them).

What I need (suggestion):
We should think about a new HTML structure, more simple (1 column, and maybe the possibility to have 2 columns for the main content).
For example

I also need new layout for each STK elements (paragraphs). What should be the rendering of a teaser, teaser group, article, event, ect...?

Mechanism to switch between the mobile website and the desktop website

I did this switch with JS but if for some reason the javascript is disabled on the mobile, the user won't be correctly redirect to the correct website.

What I need (suggestion):
A server side switch.


After this first iteration, I was able to display the home page of the demo website on my Iphone.
In this part, we will review the goals and see if they are completed.

Good result, need small modifications
Acceptable result, possibility to find a work around
Bad result, need more time to find a better solution

Exactly the same content has to be used, no new pages created:
No content is created except that I replaced the logo with a smaller one, and for the version 2 of the home page, I removed the home tab from the navigation.
The dialog should be improved in order to provide specific information for the mobile version.

Some areas have to be disabled on the mobile version:
I disabled some areas from the prototype definition, but as I explained in the drawbacks, any templates definition can override these settings.

The web pages and all the elements has to be optimized for a mobile experience:
The home page is displayed correctly on my iPhone, but for an optimized mobile experience the whole web page structure (html,css,js) has to be review, and all the elements (navigation, teaser, article, ect..) have to be redesigned.
It involves that we need a new prototype and also that the elements can be render differently according to the site (and this is not so trivial with the current definition mechanism).

Images have to be smaller
With new variation rules for the imaging module the images are smaller.

The size of the page has to be reduced (less loading time)
I reduced the size of the pages because the images are a bit smaller, but without an optimized theme it's not possible to reduce more.

When the user access the url of the website from a mobile he has to be redirected to the mobile website, switch mechanism
As explained in the drawbacks, the switch is working but it's not the best solution to do it in javascript.

Of course we could discuss the red points: why should the pages of the mobile version be different, with less content. For example in this implementation I decided to remove the abstract of the teasers, we could discuss that point and say lets provide exactly the same structure for both website. But I think that for many reasons (usability, loading times, ...) the structure has to be different if we really want to provide a good mobile experience to the users.

What's next?

According to the results, we see that there are still a lot of things to improve

  • Improvement of site def / template def mechanism
  • Mobile Web design
  • Server side switch

If we want to integrate this mobile feature in the product, we should really work on the improvements.
The version 5.0 will come with new STK mechanisms, maybe it will solve the problems I found, to clarify!!

On an other side, we could anyway work on a mobile HTML prototype and then integrate it in STK. The benefits are multiples, these new templates could be used for a 1to1 implementation, and they also could be used for a microsite implementation ( mobile website from scratch).

For a customer specific project, we now have a good overview of what we could suggest for a mobile version of a website.
According to their requirements and to the complexity of their main website, the mobile website could be feasible with more or less workaround.
We could think about best practices, what are our recommendation...
Sprint 2


The different problems can be solved with workaround, according the specification of the project some of them could be applied.

Templates enabling the display of an area
If we dont need an area in any pages of the mobile website, the easiest way is to remove it from the script

Cannot change a paragraph
Use CSS to hide elements and to modify the layout. This workaround around won't reduce the size of the page, but at least we could provide a better usability of the mobile website.

If the result with these two workarounds is still bad, the last workaround is to modify the Renderers and RenderingEngine of your site.
By modifying these objects you will be able to change the behavior of the merge between the prototype definition and the template definition, and more...

  • No labels


  1. Thanks Samuel, these are excellent findings. Please ensure that this topic is on the agenda for the next STK release.

  2. There's another mobile js framework called Sencha Touch ( ), which might be worth looking at as well. There's a GPLv3 version for OS projects and a commercial version (not sure how much it costs).

    And this one is using a different approach to responsive websites overall: