Proposal: Multi-device support

Showing 1-11 of 11 messages
Proposal: Multi-device support Jonas Obrist 2/1/11 4:20 AM
We should add multi-device (aka mobile-) support for the django CMS.

The big question here is: In what form (and to what extend) do we want to support this how?

The problems that need to be solved (either by the cms or 3rd party tools) are:

* Detecting the devices (could be done using django-bloom/deviceatlas).
* Exclude/Include pages for certain devices or device groups.
* Serve different content in plugins or disabling/enabling plugins depending on the device.
* Possibly different templates for different devices.
* Anything I forgot

We currently solve this issue with django-bloom/deviceatlas, a middleware which sets request.device to the current device and request.base_template to a template depending on the device (eg: "base_desktop.html", "base_mobile.html"). We then use a 'proxy base template' ("base.html") for all our templates which then extens request.base_template. Further we do plugin-customization using 'if request.device.is_mobile' and similar. This does however not allow us to use different menu structures for sites or exclude certain pages from the menu.

Please tell us your opinion and suggest ways to solve those issues.

Jonas
Re: Proposal: Multi-device support Kevin Renskers 2/1/11 12:22 PM
The easiest solution is to use CSS 3 media queries using screen resolution detection. No javascript or python code necessary, all done by the client, scales beautifully. As long as plugins get their own css class, you can enable or disable them that way (hiding / showing them).

Of course, if you want to use different templates to send less html over the wire for mobile devices, pure CSS 3 queries are no good. My opinion is *not* to have device detection in the CMS though, but as a completely separated piece of middleware that simply prefixes your template folder with a "mobile/" folder or something like that. All your apps can use that, and it would be useful for sites that don't use Django-CMS too.

This separate piece of detection software / middleware should allow for plugins or hooks or whatever you want to call it, where you can plug in stuff for Django-CMS (for example, boolean field "hide on mobile site" or whatever).

Make it as transparent as possible, release it independent from Django-CMS but allow for easy integration with a plugin structure.
Re: Proposal: Multi-device support Jonas Obrist 2/1/11 12:27 PM
I agree that we shouldn't solve the frontend issues. Those can be solved with CSS easily.

However the Boolean flag on Page will not work. We don't know what devices there will be in a few months. Already now we see that clients want desktops, ipads and phones to be handled separately, so that's already 3 options. The system we come up must be more flexible and be able to handle whatever devices there might be in the future.

Also, the issue of the menu tree is not solved. What if I have several pages which are flash heavy and I cannot (for whatever reason) come up with a iOS compatible solution? I would not want those pages to show up on iOS devices.

Anyway, thank you for your input and I would like to invite everyone to engage in this discussion. This feature will most likely have a big impact on the CMS, so it is in your interest that it is done in a way you find appropriate.

Jonas
Re: Proposal: Multi-device support Kevin Renskers 2/1/11 12:34 PM
The boolean flag was just an example. But whatever solution you guys can come up with, that solution could just as well be made into a plugin for a more generic system, that's all I am saying. Don't weave it all into the core of the CMS. I really really do think that a third party app with a specific Django-CMS plugin is the nicest option. I know I could help out with that too.

Uh, by the way, are non-core-developers even allowed to post in this group? Make feature proposals and comment on stuff? :)
Re: Proposal: Multi-device support Jonas Obrist 2/1/11 12:38 PM
Non-core developers are not only allowed but actually *encouraged* to participate in the discussions here! The point of these proposal discussions is to allow the community to have their voice heard!

This issue especially is something I want as many people as possible to contribute their ideas and opinions on.

So your "whatever solution you guys can come up with" is not the point of this thread, the point is that we come up with a good solution together. Something that not only works for our use cases, but also yours. The more people think about this, the better the solution, at least I hope.

Jonas
Re: Proposal: Multi-device support Kevin Renskers 2/1/11 12:42 PM
Good to hear! And what I meant of course was, that whatever technical solution we as a group can come up with to allow for all the different use cases and future devices and what not, that it's probably to do in a plugin system as proposed by me, as opposed to the entire detection system in Django-CMS core.
Re: Proposal: Multi-device support Jonas Obrist 2/1/11 12:44 PM
I completely agree that we shouldn't do the detection ourselves (or if we do, at least use services such as deviceatlas). There's many solutions out there that already do that very well.
Re: Proposal: Multi-device support ChrisGlass 2/2/11 4:20 AM
Couldn't we create a new dimension to the page space, "profiles" or
whatever we can come up with, that would allow for an extra layer of
grouping of items?

That would mean storing the template on a "page profile", for which we
could make default fallback assumptions (similar to the language
fallbacks for instance), depending on deviceatlas-defined "device
classes" (tablet, phone, desktop,...)?

It would obviously make database queries more costy, and will not help
solve the human ressource problem that front-enders will have to make
several sets of templates instead of only one... but that's another
story.

Also, we now need plenty more menus (we currently cache one menu per
language per site, it will need to be one menu per language per site
per "device class")

Does that make any sense?

- Trib'

Re: Proposal: Multi-device support Angelo Dini 2/4/11 12:42 AM
There is also the problem that you need to reorder plugins as of the device some information has higher priority than others (like a gallery for example). Some plugins shouldn't even display on mobile (or menu's as mentioned)

this logic should be integrated within the cms.

As for frontend, we found an easy way to use different templates if the website should work like a webapp (sencha touch) and or using css media querys id the site should render slightly different. But not all devices support media querys proper (windows phone).

As of today mobile-development is still at it's teenage-steps...
Re: Proposal: Multi-device support waf 5/14/11 10:43 AM
One could exclude menu-items with CSS3 attribute selectors:

For example:
a[href^="/flash-heavy1/"],
a[href$="/flash-heavy2/"],
a[href*="flash"],  {
    display:none;
}

To target specific devices, such as iOS, Android, Symbian and WinMo, I believe should be a problem for a third-party.

To implement browser version-sniffing, rather than detecting browser capabilities, does not sound very 2011 to me. I could make the exact same argument that Django CMS should do this so I could handle IE6 in a better way. :)

To implement a new feature that aims only to fix the wrongs of the past is in the end counter-productive.

My .02$

- Pål
Aw: Re: Proposal: Multi-device support Angelo Dini 6/1/11 1:25 AM
That actually relies on CSS3 which is not yet supported on older devices (we speak here of 6-12 month old devices). The following problems need to be solved within the backend:

- Serve different menus for different devices
- Placeholder placement should alternate depending on the device
- Plugin placement should alternate depending on the device

By "devices" we talk about different distribution channels like phones, tv, handhelds and so on. It shouldn't just narrow on mobile devices. Frontend wise we have different options like media queries, javascript frameworks (serving different templates) or other cutting edge technologies. But within the backend we need to define some mechanisms to let the user define what, how and where the content should be displayed.