Themes

Excellent proposal!

Switcher itself is not a major problem -  I have tested the same code from detectmobilebrowser.com with theme layout files - and if mobile devices get also different default css without holy grail layout from base theme (different mobile base theme?) most activities can be used with mobile devices.

To this middle part (Mobile Theme):

For a start mobile base theme should eliminate floats and frames, columns (one column with the content first is the best option), scripted effects (menus, docks, popups etc), nested tables and layout tables (most of tables have already gone in moodle 2.0 ). Mobile base theme css should set proper widths and heights for small-screen elements, reduce margins, paddings and borders ( to 0), switch to ems or percentages rather than pixels, switch to smaller font sizes for headings and paragraph text and so on.

With current moodle 2 css most of these things can be done with overriding theme css of base theme but ideally mobiles should not need most of base theme css at all

These proposals seem like really good simple ideas to me, so I hope other people like them.

(Of course, as a colleague of Anthony's I am probably biased.)

Sounds great. A huge +1 from me. I have another idea to add to the mix. Once we have browser detection could we enable/diable certain filters based on this.

Specifically what I have in mind is that once we know they are mobile based I would disable the multimedia filters as these probably wont operate, and I would also like to add a new one that replaces a .flv file with a .mp4 extension tat would auto link to to the mp4 file if they are on a mobile device. (this would require however that both an mp4 and flv variant of the files were uploaded beforehand however).

Thoughts? Or am I just dreaming?

Julian

Hello,

This is an excellent proposal. I have been looking at mobile apps recently (for Mahara) and as pretty and functional as they can be, they create a never ending update and support cycle for many mobile platforms.
A small screen browser css theme is much easier to control, update, and customise centrally - there is only one to fix.

One thing not mentioned are the 'mid-sized' screen devices such as iPad, Galaxy Tab and so on running 5-10 inch screens. Some could support a full theme and others may better run a mobile theme.
Would there be place for a locally defined (in 'local' directory) config file so new broswer versions/device types/functionality could be added as they are released in various local markets under different branding/versions? Admins would then be able to easily set or override the defaults as required.

On a related note, see what UCLA are doing with their mobile framework:

http://m.ucla.edu/about/

Following community feedback, our proposal has broadened.  Here's  v2 -

Moodle Device Detection Specification

Introduction
This document proposes some additions to Moodle 2.1 to enable detection of different types of device so that additional or alternative functionality can be provided.  This would, for example, allow blocks, modules, etc to take advantage of mobile functionality (cameras, geo-location, etc); make customisations for tablets or to develop modules or blocks that are only for use for particular types.

It also specifies a means for different themes to be used for different types.  This provides an alternative to using @media rules within a theme with the associated issues this may bring for users with larger displays (loss of features or unfamiliar layout if resizing a browser window).

Browser Detection
A site setting enabledevicedetection will be added and set to yes by default.

The following functions would be added to lib/moodlelib.php –

get_device_type() –  uses  regular expressions to detect whether a device is mobile, legacy, tablet or default.  If enabledevicedetection is set to no then will return default.  Further, users can use a new administration setting to add additional name/regular expression pair (if the regular expression is found then the function will return the name).  User defined expressions will have precedence, allowing the four basic types to be overridden.

For more granular detection of browser operating systems and browsers, it is intended that the existing check_browser_operating_system and check_browser_version functions should be used and extended if required.

Theme Selection
The theme selector user interface for sites, courses and users will be changed so that, if enabledevicedetection is set to yes, it will be device type led.

The first screen will show a list of device types, including user specified types, with a thumbnail of the currently selected theme and a ‘return to default site settings’ button if changes have been made.  Users will then be able to select a device and see, by default, a list of supporting themes (the user will also be able to opt to see a list of all themes, whether they provide support or not).  The current theme will appear at the top of the list followed by a list of themes that can be chosen with thumbnails and a select button.

If enabledevicedetection is set to ‘no’ then a default device type is always assumed, so in accessing the theme selector the user will be taken directly to the selector for default devices.

Moodle Themes will have an additional optional setting supporteddevicetypes that will include a comma delimited list of supported types.  If a theme does not have this, it will be assumed to support the default type only (remembering that this is only indicative as administrators can ultimately use any theme for any device type).

Storing Theme Settings
The theme fields of the site, course and user globals will include a comma delimited list of device categories and themes intersected by an ‘:’ (e.g. mobile:standardtheme).  If these are empty, default themes will be used.

Switching Themes
Themes being used for particular device types will provide the user with the ability to switch from the theme for their type of device to the default type theme.  This selection should persist for either the duration of the session or permanently according to the user’s selection, made via two links in the page footer.  This will be stored in a user or session variable in comma delimited form according to the current context (site, course, user, etc) and device e.g. $USER->switchtheme = ‘site:mobile:standardtheme, course:tablet:anothertheme’.

A new file, switch.php, will be added to the theme folder.  According to the switch link selected, this will either set the switchtheme field of the session or user variable (and save the user setting).  The user will be redirected to the screen on which the link was selected.

Themes being used for particular device types will show a link to switch back to the default theme.  When a switch from the device type theme is undertaken, an additional variable, originatingtheme, will be added to the $THEME global.  If this variable exists, the theme in current use should show a link back to the standard theme for the device in use.

An additional public function will be added to the core_render class in   lib\outputrenderers.php, theme_switch_links().  Calling this will add the two switch links to a mobile theme or the single link to a ‘modern browser’ theme if the aforementioned conditions are met.

Template designers can specify where these links should appear.   An additional protected variable will be added to the class, switchlinkdisplayed, that will be false by default.  Calling the theme_switch_links() will cause it to be set to true.  standard_html_footer() will be amended to add a call to theme_switch_links() if switchlinkdisplayed is not set to true.

Resolving Themes
In lib/pagelib.php, resolve_theme() will be amended to check the value returned by get_device_type() and compare it to the relevant theme field to find the correct theme to use.  Any switchtheme settings in the session or user globals will have precedence, then theme field settings.  The existing theme order (course, category, session, user, site) will continue to be respected.

If no theme can be found, then the default Moodle theme will be used.

Existing legacy browser support code will be removed.

Upgrade from Moodle 2.0
An upgrade script will be written to maintain pre-existing theme settings. A modern theme will become a default type theme in Moodle 2.1 and a legacy theme will be associated with the new legacy type.

Attached is the version of the spec I will be working from.  Only very minor changes from the above.

I've finished the code for this.  It's now available for review at https://github.com/anthonyforth/moodle/compare/master...WIP-25394

The Moodle bug for this (http://tracker.moodle.org/browse/MDL-25394?focusedCommentId=103657#comment-103657) has also been updated.