Perth Hackfest October 2012/Responsive design and Theming

Jump to: navigation, search
  • What are the current problems?
    • Multiple clients/devices support
      • duplicate work/development
    • Accessibility issues (make ui work for different people and different situations)
    • Navigation consistency
      • Reports in nav, not settings
      • Location of links to assignment, etc
    • Editing icons all over the page
    • Need to test your theme for all pages
      • Need more consistent css selectors
      • Policy for naming layout and CSS selectors should go into the coding guidelines as the consistency there is crucial.
    • When editing content, need to do several page loads (e.g. edit, confirm action, redirect, display)
    • Developing content for mobile devices
      • user generate content is out of our control
    • Responsive design power
      • Putting divs and others blocks just below each other is not enough. Input widgets need to be changed (e.g. from the list of links to a drop-down menu).
      • change layout, change nav into dropdown button, compact blocks/elements
      • Uses css media queries
      • Moodle theme has layouts, but no guide/consistency
  • Moodle fluid theme
  • Standard Moodle theme layouts
    • Should provide a good base theme with responsive design so that other themes can inherit from it
    • Need to solve it in core, so that it works for everyone
      • Not just adding more hooks for css
  • Mobile app
    • still a need for it, can do offline activities
  • Hard for developers to create UIs
    • What other projects do is provide UI templates
    • Totara has developed standard UI widgets, guidelines/style guide
      • Element library
        • easier to use an existing set of elements than making your own
      • If programmer wants to add new element, they add it to the library for designers to theme later
      • One place to see how all outputted elements will look like for designers
      • Elements are renderers
        • Can improve accessibility, by having standard way of developing output
      • Tim Hunt: We try not to have developer documentation in the core code, but the element library is very useful and should be included as part of core.
  • Developers vs theme designers
    • Inconsistency across activities
      • Page body tags are good, but next step would be to have same element selectors across modules
      • Developers need guidance on selector consistency
      • Action item: Form a small subgroup to create documentation
  • Supporting “non modern” devices
    • Text only browsers, should they be supported?
      • Yes, because of accessibility/screen readers
    • How long do we need to support non-javascript fallbacks?
      • screen readers are being improved to work with newer js interfaces
    • If new feature doesn’t work for touch, should it be rejected from core?
      • e.g. drag and drop interface


  • New theme in core with comprehensive layouts that are responsive
  • Detailed list of “widgets” for the interface, with test page showing all of them (in core)

Responsive design breakout session notes

Technical notes from Petr:

  • We need to be backwards compatible with existing themes for at least 3 versions
  • We can look at a new base theme - possibly for each version
  • Lots of renders may (will) need re-writing (again version-specific)

Problems at moment:

  • lack of similarity between components - e.g. h2 with different classes for the same context
  • overuse of components in different contexts - e.g. generalbox

Need certain key widgets - at least all those in the bootstrap:

  • boxes
  • headings
  • lists
  • tables
  • form elements
  • tabs
  • notifications
  • images
  • forum thread/post
  • user with photo

Look at twitter bootstrap for examples - - list of components

Can we use HTML5 attributes too? To specify the role of an HTML element?

  • backwards compatibility with non-HTML5 browsers?
    • possibly not granular enough.
  • primarily for accessibility
    • shouldn’t really use them for another purpose

Concepts for resizing mobile devices:

The new Moodle Mobile app:

The future idea is to have the moodle site change via css and javascript to look similar. the quicklinks at the top change for example when resizing

It’s be good to get rid of the mymobile theme and no longer need it

What about blocks? Do blocks work on a tablet device? - no not really

What to do instead:

Convert to menus which, when clicked, show just that block (lightbox/popup/fullscreen)

Can we do a mockup to do this - just mobile, or desktop too? Why not do both (and drop the dock)

Docking not required.

Swipe to the side to see blocks. Swipe back to hide.

Need to maintain a way to change back to the original display.

Responsive design leading site:


Responsive tables

How do screen readers cope with the change in layout? Shouldn’t be an issue as CSS is changed, not DOM layout.

IE 6 - 8 Respond

Three-level CSS-only dropdown menu:

Action items

  • Patch of the element library to be sent to Moodle (Simon Coggins)
  • Go through the totara element library - go through the specification - find and remove duplicates. (HQ and all?)
  • Add code examples to the element library, possibly via code call to renderer (?)
  • Standardize classnames and layout to facilitate theming - collect examples of issues from themers. (Amy)
  • Upgrade the renderers to support versioning (Petr).
  • Add missing renderers, based on element library
  • Fix custom menu to be CSS only (must be equally accessible)
  • Develop a mockup of Moodle theme on mobile (based on mobile app) (HQ)
    • Blocks in the side menu, click title to show block in main content
    • Custom menu displayed at top or side menu
    • Link to switch the control to/from normal desktop mode
    • Show to community for feedback