

Your Rating: |
![]() ![]() ![]() ![]() ![]() |
Results: |
![]() ![]() ![]() ![]() ![]() |
92 | 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:
- http://www.w3.org/TR/mobile-bp/
- http://www.uxmatters.com/mt/archives/2011/01/designing-for-the-mobile-web-special-considerations.php
- http://www.noupe.com/how-tos/mobile-web-design-tips-and-best-practices.html
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
- http://www.phonegap.com/
- http://jquerymobile.com/
- http://mobiforge.com/designing/story/effective-design-multiple-screen-sizes
- http://validator.w3.org/mobile/
- http://www.w3.org/TR/mobile-bp/
16 Comments
Magnolia International
For the record: http://www.openmindlab.com/lab/products/mgnlmobile.html
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.
Antti Hietala
I tried Gregory's suggestion. I copied
small.css
and creatediphone.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:
Samuel Schmitt
Yes the Guardian is a good example.
The mobile website is simplified:
ect... They followed the best practices
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...
Boris Kraft
I don't think this manages everything on the client side. STK Image variations kick in on the server side.
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)
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
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.
Samuel Schmitt
Take a look at http://jquerymobile.com/
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").
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:
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.
Are you agree with this separation of the tasks?
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.
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.
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:
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.
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
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.)