Product Development

Page tree
Skip to end of metadata
  • Created on 2011-05-17, last edited by Magnolia International on 2012-05-04
Go to start of metadata
Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 91 rates

GREY Progress tracked in SCRUM@jiraGREY

Current Status

A prototype is available in our Forge http://svn.magnolia-cms.com/svn/forge/mobile-concept/trunk.

This project comes with:

  • a module containing the templating and the main configuration.
  • a theme providing css and js for the mobile website, and also a new configuration of the imaging module
  • a EE webapp

This project could be a good example if you want to implement the 1to1 approach.
We really recommend to read these 2 articles if you want to have a better understanding of what we did during this POC:

Once the webapp is running, you can simply change the user agent of your browser to render the mobile version.

Objective

The goal of this page is to collect thoughts in order to develop templates allowing a mobile version of a website.
These templates should be integrated within STK.

Customer profiles

Let's have a look of who is asking for mobile sites

  • smaller customers with no immediate intentions to maintain a separate mobile site. They just want to ensure that their website also works on a smart phone. They have limited resources in the web team. Any magic we can provide will delight them. In other words, the mobile experience should be transparent. Ommit additional site definitions, microsites or the like if possible. A typical customer would be Magnolia itself, where we stand to gain little in terms of visitor attraction if we have a specialized microsite for smart phones, but would like to provide a nice mobile experience nonetheless.
  • larger customers with significant web team resources. These may already maintain many websites, so adding mobile sites would be ok for them, but they probably want to reuse content and/or minimize the effort it takes. They will possibly want to create a different navigation structure, prune unnecessary content, possibly provide direct access to "top articles" and generally ensure that a mobile visitor has access to the same information than on the non-mobile version. E.g. Texas State University has 300 sites to maintain. Creating 300 additional mobile sites would probably be too much effort, but a system that is smart enough to generate a mobile version would be fantastic (note: this would actually be the same as for the small customer). Other types of customers in this group would be fine in creating derived sites for smart phones.
  • "Ecommerce customers" will understand that their mobile site (or app) must be maintained pretty much independently from their main site. It really is a special case. These customers typically have their own in-house development team and understand that they can build such a site with existing Magnolia. The would not gain much from mobile templates we provide.

Depending on the customer profile, we can define the following use cases:

Use cases

  • 1 to 1 mobile website:
    Usually for small websites, the same pages are available from a mobile device.
    Exactly the same content is served on a mobile but rendered differently.
    Pages are designed for mobile devices.
  • mobile microsite:
    Compared to the main website, the mobile microsite has a complete other structure, usually this structure is flatted and reduced.
    This is typically the case for huge websites, they sacrifice some of the content / features to ensure that the user find what he really needs.
    Some pages could have content in common with the main website, these contents could be fetched from the original.
    Possibility to create new pages, only available for a mobile (e.g Mobile Landing page, specific form pages).
    Pages are designed for mobile devices.

Mobile Web Best Practices

In both cases the pages have to be designed for mobile devices.

Few articles about this topic:

In summary:

  • popular screen resolution is 320x480
  • weight of the page reduced (less images, smaller images)
  • prioritizing content (less areas, reduced footer, ect...)
  • simplify navigation / reduced structure
  • navigation mechanism: jump entire section of a content, back button, back to the top
  • larger button, more space (touch device)
  • give users the option of visiting the standard site

and more...

Navigation
In many mobiles the omnipresent menu can´t be applied in many cases because of the screen size. The menu probably should be in a vertical way and it could be very uncomfortable if for every single page people would need to scroll down all the menu to see the content. So, only use omnipresent menu if your site has only three links or less on its top navigation and, because of that, it can be horizontal. The solution is to put the navigation on the first page and on the others pages use a link at the top to come back to the first page or use breadcrumbs.

Technical approach

Site configuration
  • Approach 1: 1to1 mobile website
    Similar configuration than for a multisite config.
    Site A representing the main website.
    Site B representing the mobile website.
    The site B extends the site A but has a different domain, provides new templates (layout), provides new CSS / JS, manages the images differently, disables some areas.
    This different behavior is managed by the configuration of the site definition.
    The redirection to the site A or B could be managed by the MultiSiteFilter.
  • Approach 2: microsite
    Site A representing the main website.
    Site B is the mobile website.
    A mechanism allows the site B to inherit a part of the structure of the site A, pages are fetched from the original content.
    These fetched contents could be overwitten.
    Site B can add new page to his structure.
URL

Google recommends a single URL without redirect for serving smart phone content:

If you have "smartphone" content (which we see as normal web-content, as it's generally a normal HTML page, just tweaked in layout for smaller displays) you can use the rel=canonical to point to your desktop version. This helps us to focus on the desktop version for web-search. When users visit that desktop version with a smartphone, you can redirect them to the mobile version. This works regardless of the URL structure, so you don't need to use subdomains / subdirectories for smartphone-mobile sites. Even better however is to use the same URLs and to show the appropriate version of the content without a redirect.

Templating

All the templates / features / paragraphs provide by the STK should be redesigned for mobile devices.
Redesign means functional redesign and graphical redesign:

  • what would be the behavior of each component on a mobile and
  • what would be the rendering of each element

but before
What kind of templates / paragraphs we need?
Maybe not all the elements provided by STK are needed for a mobile website.
For example, Flash Template, HTML template, teasers paragraph, ect...

Maybe we need new elements: localization features, ect...

Functionnalities

  • describe the functionalities of each templates / paragraphs

Layout - style - usability
This is a important part, the rendering of each elements, the usability, the navigation mechanism.
It has to work for almost all the smartphone.
Techno: HTML5, CSS3 ?
Framework !!

Bookmarks
  File Modified
PDF File Sitecore_Mobile_whitepaper.pdf SiteCore mobile whitepaper 2011-06-07 by Antti Hietala
PDF File Developers_Guide_8th.pdf 2011-06-14 by Samuel Schmitt
  • No labels

16 Comments

  1. Magnolia International

    For the record: http://www.openmindlab.com/lab/products/mgnlmobile.html

  2. Magnolia International

    Let's not forget that STK, by means of its default "pop" theme, already provides an "alternate" view of a regular site; the content - and amount of transferred data - is exactly the same, but the "small.css" alternate stylesheet (kicking in on devices with a screen width than 900px) rearranges and hides certain element. This simple approach could be pushed further.

    1. Antti Hietala

      I tried Gregory's suggestion. I copied small.css and created iphone.css, then started to prune out page elements that don't work well on a 320x480 screen. It's tedious work unless you know the CSS styles well but can indeed be pushed further. Disabling elements such as extras and promos via site definition and resizing the main area in CSS is quite feasible.

      How would you do the navigation? I think Guardian does a successful transition from desktop to mobile. They strip the menu into a flyout. Works nicely on the phone. Compare:

      1. Samuel Schmitt

        Yes the Guardian is a good example.
        The mobile website is simplified:

        • navigation bar reduced + flyout
        • footer reduced + access to the desktop site
        • less content displayed
        • for each section, only the first article has an image, no abstract
        • extra areas removed
          ect... They followed the best practices (smile)

        For Greg's suggestions, of course it works. But the problem by managing everything on the client side is that the size / weight of your page stay the same, the size of the images are same, content is only hidden and still on the page.
        If you want to change the behavior of a list of news (first with image + title, other only title), you could achieve that with JS and CSS, but I'm not sure that's the best way...

        1. Boris Kraft

          I don't think this manages everything on the client side. STK Image variations kick in on the server side.

  3. Boris Kraft

    What I want to add is that we are not concerned about non-smartphones here. For that, a template that exports XML and a service that translates that into device specific code (incl. WAP) could easily be written. This is out of scope (see customer profiles section)

  4. Boris Kraft

    I don't think we will need to work much on the STK templates themselves. These are semantic HTML state of the art templates which cleanly separate html structure from functionality, design, business logic and content. The main issues to start with for me are

    • different navigation as already pointed out. I like the Guardian approach.
    • ability to turn off areas, possibly per site and page configuration
    • we need to redefine imaging rules to ensure images are lighter in weight
    • some mechanism to switch between mobile & desktop version
    • a close look at teasers and what to do with them, especially the fancy teasers (carousel, tabbed teaser etc)
    • video: a big topic anyways, as we should move to HTML5 or at least switch dynamically. No Flash support.
    • forms: possibly use the jquery stuff to ensure forms work well on smart phones

    1. Antti Hietala

      Regarding fancy teasers, how about enabling swipe gestures for paging teasers. Apps commonly let you swipe through the images of an article using horizontal swipes and continue reading the article vertically. I have not seen this done on mobile websites but our paging teaser already rotates images with clicks. Reacting to swipes with jQTouch should be possible. Benefit: saves screen real estate by displaying one image at a time and no need to reload the page.

      1. Samuel Schmitt

        Take a look at http://jquerymobile.com/

  5. Boris Kraft

    Here is another idea - the way STK structures sites is by using article type pages as main content holders, and section pages as overview pages to the main content. On a mobile, section pages could simply list the teasers, much like http://bazonline.ch/mobile/ does. Or we could skip them altogether and only display a list of most important articles (however calculated) and provide all other articles via search, intra-site navigation and tags ("related content").

  6. Samuel Schmitt

    in our discussion , I see two main topics:
    1. User interface
    2. How to enable a website for mobiles

    For the point 1 we have to think about components that render the content correctly on mobile.
    It's about templates, paragraphs, what is design and layout of the pages, usability, navigation mechanism.
    Technical perspective: review the template scripts, css, and maybe model class (if for some reason the behavior of a component has to change for mobiles).
    And we could think about new elements (geolocalization)

    Second point, what is the mechanism in order to provide a mobile website, several cases:

    • from an existing site, content is here, customer wants that his website will work also on mobile with minimum effort.
      Technical tracks: multisite, subtemplates reacting on the user agent
      How to disable areas, part of the original website?
      The rendering of each page will be manage by the template mobiles.
    • microsite: a standard website, using mobile templates

    Are you agree with this separation of the tasks?

  7. Boris Kraft

    I have added a white paper that discusses both the one-site method and the separate mobile site way as well as some best practice.

    1. Samuel Schmitt

      Interesting document.
      They point out that the main disadvantages for the Two Site Method is to maintain several versions of the content.
      We could prevent that by fetching content from the main site to the mobile.

  8. Sean McMains

    We put a lot of thought and effort into this on the Texas State sites. You can't see it on the home page, since it has a custom template, but the standard template we use elsewhere renders very differently for mobile devices. Take a look at http://gato.its.txstate.edu on an iOS or Android device for example. (You can use the iOS simulator in Apple's dev tools or set your user-agent string to the iPhone's if you don't have an actual iOS device handy.)

    We did take approach #1, since many of our content editors aren't technical, and we wanted them to have a nice mobile version of their site without them having to do anything special (or even be aware that they were making a mobile version of their site too).

    To that end, a few of the features we focused on:

    • Navigation: We modeled ours after Amazon's, and provided a link up the hierarchy at the top of the page, and drill-down links to go deeper into the hierarchy at the bottom of the page. I do like the Guardian's approach too, though – it seems like a nice way to make the most of the available space.
    • Formatting the content for a small screen: we decided that not all of the content on the normal page needed to be displayed on the mobile version. We stripped out the sidebar content and reformatted each of the paragraph types in the main content section to display nicely without zooming so that visitors can read and navigate the main content easily. Another approach might be to put the hidden information into a collapsible DIV to make it available on demand, though this does require cramming data down the pipe that has a good chance of never being displayed.
    • High-resolution images for Retina and other high-density displays: Our image gallery paragraph was where we paid most attention to this. Javascript exposes the density of the screen through window.devicePixelRatio, so we were able to wait for the dom:loaded event and then, if the visitor is using a high-pixel-density device, swap out the SRC for the images to load the higher-resolution ones instead of the standard ones. See http://www.theatreanddance.txstate.edu/ for an example of our image gallery in action. (It also uses swiping gestures to scroll through images, though I was never quite happy with how smooth we were able to make them.) We also did the same resizing trick for site banners.
    • Speedy display: we tried to make sure that all of the common assets were as cacheable as possible, that our various CSS and Javascript files were rolled together into a single http connection each, and that all of the textual content was GZIPped in transit to get over the wire as quickly as possible. YSlow and Google Page Speed were both valuable for figuring out ways to speed up page load times.

    Our users were generally quite happy with this approach, though I think you have a valid case that there may be higher-end shops that want to publish a tailored version of their content for mobile platforms. Additionally, as more mobile devices become available, support can become a challenge. For example, when the iPad came out, it received our mobile template, which looked rather silly on a screen of that size. We eventually decided to simply serve the normal content to the iPad, as its larger screen was better suited to dealing with that than was the iPhone's.

    In any case, I'm excited to see thought and effort going into Magnolia's mobile story, and would be glad to help in any way that I can.

    1. Samuel Schmitt

      Thanks Sean for your inputs.

      I started last week an implementation of the case #1, my goal is to provide a mobile version of the demo project without changing the original content.
      You can follow my progress on this page http://wiki.magnolia-cms.com/display/DEV/Mobile+Website+-+1to1+implementation.
      Dont hesitate to add more technical things and feel free to create a sub page, for example about how you managed images. I think it's an important point!

      And also I would like to know how you managed the redirection to the mobile website.
      It's the same url, so no redirection, you managed everything with css media queries?

      All inputs are welcome (wink)

      1. Sean McMains

        Thanks for the pointer, Samuel. The new page hadn't shown up in my RSS feeds for the wiki (or I just missed it), so I was glad to get to catch up on what you've been doing.

        The way we managed displaying content differently for mobile browsers was to look at the user-agent string, and then to return content that was appropriate for mobile or desktop. Because we were using a custom caching system, we had to update it to cache the mobile content separately from the desktop content.

        On the template side, we had a check early on in the rendering cycle that would look at the user-agent string and set an "isMobile" flag in the request scope. The various templates would then check that flag and change their rendering logic accordingly.

        The advantage to this was that it gave us the ability to do completely different renderings for the desktop and mobile version of a given piece of content when needed. The downside was that there was no way for the site visitor to change from the mobile version to the desktop version or vice versa. (It would be possible to add that with a little cookie logic, though we would have had to update our cache again to keep an eye on that cookie.)