Perth Hackfest October 2012/Responsive design and Theming

Note: These session notes are now read-only to enable them to be shared with everyone. If anyone would like to add further notes, please contact Helen about editing rights.

Responsive design / Theming

• 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
  • reflows the page properly
  • https://moodle.org/plugins/view.php?plugin=theme_standard_fluid
• 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

Summary

• 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)