Mobile browser templates and detection - Newscoop Development Discussions on Sourcefabric Forum

Micz Flor

hi developers and community,

i want to start a discussion that might be very easily answered and implemented: how to develop campsite templates for mobile devices. campsite has a powerful templating engine and logic. so this could actually be a really easy task. here my start of the discussion.

my suggestion would be:

create an almost empty template with zero HTML and just a little php (see next point)
detect browser in php inside the templating engine (smarty) and set smarty variable(s)
depending on the detected browser, the template will then include different templates (which create HTML)

this means that e.g. the index.tpl then could either include index-html.tpl or index-webkit.tpl depending on what browser would be detected.

advantages: all done in campsite templating. disadvantage: the caching might get confused by this (would it?).

if this is comparably "easy" to do, it might even make it into the source code (not the templating set) and become a variable that can be detected in the campsite lingo. i would suggest to push this to the top of the feature list for the upcoming release. IMHO this will make more of a difference than some on in JIRA Smile

some scripts and infos related to this issue:

http://chrisschuld.com/projects/browser-php-detecting-a-user s-browser-from-php/

http://psoug.org/snippet/Detect-MobileWAP-browser_50.htm

http://www.useragentstring.com/

Mugur Rus

See also this link posted by Andrey some time ago:
http://www.slideshare.net/bryanrieger/rethinking-the-mobile- web-by-yiibu

"depending on the detected browser, the template will then include different templates (which create HTML)"
There's no need to have different templates for different browsers. As seen from the presentation above the HTML is 99% the same for all browsers. Links to CSS files change and there is Javascript in the HTML that adapts the HTML based on the client browser. This solution would also confuse the new cache engine and we could not use it. The minor changes in HTML between the outputs can be isolates in some small templates that deal only with formatting. Write once use everywhere, not write multiple times for different outputs.

"disadvantage: the caching might get confused by this (would it?)."
The new cache certainly would get confused because it's caching pages - the final output - per URL. And now you'll have a few different outputs per URL depending on the client browser.

Micz Flor

Mugur Rus wrote on Wed, 01 December 2010 10:27

"depending on the detected browser, the template will then include different templates (which create HTML)"
There's no need to have different templates for different browsers. As seen from the presentation above the HTML is 99% the same for all browsers.

i have to look at that presentation. the main issue is loading time. especially jQuery is a heavy load and if you work with mobile devices, you don't want to load 300k of code which are not needed.
Quote:

The minor changes in HTML between the outputs can be isolates in some small templates that deal only with formatting. Write once use everywhere, not write multiple times for different outputs.

the usability of mobile are very different. this is partly because of the behaviour states (e.g. mouseover does not exist, i.e. a lot of functionality like pulldowns working with this state fail).

it is true that you can develop a site from scratch for both. possibly you can even refuse to load stuff on mobile that's not needed - and therefore the client does not pay for the data traffic.

however, many sites use the vhost m to give access to their content for mobile devices. like www.spiegel.de and m.spiegel.de. the experience is a totally different one:
http://emulator.mtld.mobi/emulator.php?webaddress=m.spiegel. de&emulator=sonyK750&Submit=Submit

also, the content is totally different, the drama, the narration is totally different.

migrating an existing site to mobile use would benefit massively from this branching into different template sets. it would allow them to do business as usual and not touch everything.

in an ideal world (sorry, in my ideal world) the Sourcefabric CMS would allow to set templates (as it does) for index, section and article. and there could be a second set of pulldowns, doing the same for mobile index, mobile section and mobile article.

this becomes even more of an issue when you deliver e.g. slideshows. in the link i posted above, scroll down in the emulator to the bottom of the page and go to "fotostrecken". there are slideshows done especially for the mobile devices.

no lightbox jquery / javascript used, but static pages.

the possibility to branch mobiles into specific templates has many huge advantages.

the fact that you can develop all pages "also" mobile compatible creates a lot of work for publications. they need to touch all their templates. it creates "zero" work for our CMS development. so this is not a solution we provide, but work we put back to clients. if we can make life easier for clients, we should do it.

so, idea: new set of pulldowns in our publication configuration to allow setting templates for mobile devices - and then we have a mobile detection before the templates are rendered? that might also avoid the caching problems.

comments?

Andrey Podshivalov

Mugur Rus wrote on Wed, 01 December 2010 11:27

"disadvantage: the caching might get confused by this (would it?)."
The new cache certainly would get confused because it's caching pages - the final output - per URL. And now you'll have a few different outputs per URL depending on the client browser.

as you can see on slide show that mobile and desktop versions has no any differences. Client browser decides which css should be applied but not template. So template caching will work fine.

Sava Tatić

On Wednesday, December 01, 2010 11:10:52 you wrote:
> so, idea: new set of pulldowns in our publication configuration to allow
> setting templates for mobile devices - and then we have a mobile detection
> before the templates are rendered? that might also avoid the caching
> problems.

Perhaps it's time for Andrey to weigh in re: caching.

Otherwise, am looking forward to further discussion on this topic.

Sava

--
Sava Tatić
Managing Director, Sourcefabric o.p.s.
sava.tatic@sourcefabric.org

Salvátorská 10
110 00 Praha 1, Czech Republic
+420222362540
+420602653104 (mobile)
Skype: tictactatic

Subscribe to our Newsletter:
www.sourcefabric.org/newsletter/

http://www.sourcefabric.org
http://www.twitter.com/Sourcefabric

Mugur Rus

"as you can see on slide show that mobile and desktop versions has no any
differences. Client browser decides which css should be applied but not
template. So template caching will work fine."
Sorry, I saw it some time ago and my memory may not be so good. Anyway, this
is a very good reason to have a single set of templates for all types of
browsers. Micz, please watch the presentation.

Mugur Rus
Senior Software Developer, Sourcefabric
mugur.rus@sourcefabric.org

Cluj-Napoca, Romania
+40 (0)720 528408
Skype: mugur_rus

Subscribe to our Newsletter:
www.sourcefabric.org/newsletter/

http://www.sourcefabric.org
http://www.twitter.com/Sourcefabric

On Wed, Dec 1, 2010 at 12:23 PM, Andrey Podshivalov <
campsite-dev@lists.sourcefabric.org> wrote:

> Mugur Rus wrote on Wed, 01 December 2010 11:27
>
>
> "disadvantage: the caching might get confused by this (would it?)."
> The new cache certainly would get confused because it's caching pages - the
> final output - per URL. And now you'll have a few different outputs per URL
> depending on the client browser.
>
>
>
> as you can see on slide show that mobile and desktop versions has no any
> differences. Client browser decides which css should be applied but not
> template. So template caching will work fine.
>

Micz Flor

Mugur Rus wrote on Wed, 01 December 2010 11:26

"as you can see on slide show that mobile and desktop versions has no any
differences. Client browser decides which css should be applied but not
template. So template caching will work fine."
Micz, please watch the presentation.

http://www.slideshare.net/bryanrieger/rethinking-the-mobile- web-by-yiibu

sorry, my mistake, i did watch this a few weeks back when it was posted.

being a bit biczy: this presentation is for web designers and that means to CMS developers: good, great presentation, i don't need to do anything Smile

and another fact: mobile browsing is not like browsing with different image sizes. it is a different kind of browsing altogether. the cinema is not like television either Smile

i will turn this around now:

a) ok, point taken: dear CMS developers, so off you go and redo the admin interface to work with mobile devices by only using one template and coolio CSS stuff

b) what about the user? they might want to decide! do they want to watch the entire page with safari or the mobile slim version

c) we are providing location based content with the new release: this is much more interesting to mobile devices - and that will mean that a publication will possibly have their geolocation traffic content right up top on the mobile site - and nowhere to be seen on the "normal" site.

d) rich content: there might even need to be a transcoding to server flash videos to mobile devices. this could even mean: mobile on HTML5 and the "normal" site is not.

e) if it is all an issue of CSS only, other CMSes seem to be wasting their time. Theme Switching is a big issue!!!

f) there is a presentation for everything. possibly CMS developers should look at this one, rather than the one for webdesign:
http://www.slideshare.net/twom/mobile-cms-presentation-cmsex po-2010

Sava Tatić

So how about making a blueprint for this new functionality? Doesn't sound complicated, but let's see it in writing in the wiki (here: http://wiki.sourcefabric.org/display/CS/Blueprints).

All the best,

Sava

Howdy, Stranger!

Categories

Poll

Top Posters