Library

Stop the talk, make it happen

A practical approach to responsive design - a work in progress

Colin Work

Web & Communications Developer University of Portsmouth Library

Colin.work@port.ac.uk

Library

Context

• Resources – 1 person, effectively no budget

• Hosted on corporate T4 service, but independent to main University site

• Integration with other in-house & 3rd party services critical

• Web site is primarily an information resource, teaching tool and research aid.

• “Captive audience”, well defined.

• major redesign begun Autumn 2011

Library

Business Case

•From the top “We need a mobile app!” (Late Spring 2012)

• student recruitment led, impact of fees

• enhancements to Wi-Fi coverage on campus

• Proliferation of smart phones and tablets amongst students

Accesses by device over previous 12 months

Desktop Mobile Tablet

AY 2011/12 cf 2010/11 -4.16% +62.13% n.a.

AY 2012/13 cf 2011/12 +34.39% +152.15% +486.65%

Library

Planning

Constraints:

• no additional resources/budget available

• major site revision already nearly complete, for launch in September 2012

• no time to re-visit current site and meet September deadline

• staff/students very sensitive to disruptions during term time

• could not diverge from prepared teaching/support materials

“you wouldn’t want to be starting from here”

Library

Plan A: Launch website on schedule and follow with a separate site for mobile, using shared T4 content (through content mirroring and/or browser device detection). Pros

• (relatively) easy to do in T4, using examples & documentation

• minimal if any impact on newly launched website

• could be initiated quickly, and developed in stages

Cons

• how would we support pages/services held outside T4? • proliferation of devices, esp. range of tablets with characteristics somewhere between smart phone and desktop

• would the mobile site end up as a “poor relation”?

• support overheads

• future proof?

Library

... but conferences, workshops summer/autumn 2012 led to ...

Plan B: the responsive website. Pros

• single version of site (consistent content)

• very low maintenance overhead

• could be applied to non-T4 sites

• device agnostic ... hence future proof?

Cons • potential disruption to newly launched site (not another redesign!!)

• relatively few relevant real world examples

• hard to phase in – site change would be all or nothing

• it looked difficult!!

Library

How it was Done Step 1 – get rid of old mind set. A web page does not have to look the same in every browser.

Library

How it was Done Step 2 – using a test site, rationalise the existing T4 site.

• all elements of the site need to be contained within a “fluid grid” – replace fixed width elements with <div> s which can be sized and positioned from a style sheet.

Note: in an ideal world, you would start by creating a grid, and adding elements to the grid. We adapted our existing layout to a grid-like layout.

• headers and footers fully contained within T4 page layouts, including any JS or other code • T4 content types handle all content page structure (insets, images etc.) • image requests eliminated or embedded in CSS where practical

Note: we opted to stick with HTML 4 throughout due to the fact that old browsers were still widely used on campus at the time. We do use CSS3 (eg. for media queries) but the core style sheet is CSS2.

Library

“Nested” Grids • allowed max re-use of existing layouts & types • minimise impact on users and content providers • outer grid easily adapted to non-T4 and 3rd party services

Outer grid (managed by page layouts) Inner grid (managed by content types)

Library

Step 3 – create a CSS file to replicate the current site using new page layouts and content types.

• within CSS, (almost) all measurements set as em values or percentages • this CSS file provides a decent fallback ‘default’ presentation if media queries are not supported

Step 4 – replace old CSS, content types and page layouts with new versions

• site is now “responsive ready” • no disruption to existing site, no significant change to the user experience.

Typical page on non-responsive site

‘Default’ layout on responsive site

images

Fixed width tables

Potential issues

images

Issues addressed with <div>s & CSS styling

Library

Step 5 – determine “break points” (how will the site flow as screen size changes)

• could involve:

• changes to sizes of elements: target ÷ context = result Eg. Required font size of 12px ÷ base font size of 16px = font-size: 0.75 em 300px sidebar ÷ 1200px page width = width:25% beware of CSS inheritance! • changes to positioning of divs • hiding/revealing divs (CSS & JavaScript)

• need a decent default without CSS or JS trickery • Google analytics can be useful in identifying breakpoints • lots of trial and error! • most useful tool ... a pixel ruler

Library

CSS Snippet @media only screen and (min-width:731px) and (max-width: 805px) { #right_panel, #mob-foot-address, #mob-foot-links {display:none;} html {font-size:12px;} #outer {margin-bottom:-5em;} #logo {background-image:url(<t4 type="media" id="173166" formatter="media/*" />);} #library a {font-size:1.8em} #library a {float:left; margin-left:1em;} } Note: using rem as an alternative to em will help with dependency, but may not work with older browsers

Right side bar now hidden, but content still available from the top bar navigation

Search widget replaced with link to a page

Content rearranged & image size reduced in CSS

Header reduced in size

Footer rearranged

Menu navigation replaced by menu widget

Breadcrumb trail added

New footer layout

Library

Step 6 – create a 2nd CSS file to handle “media-queries”

• a 2nd file is not a necessity, but it allowed for a transparent transition on our site • all our conditional execution is based on viewport width (plus a print definition) – but this is not quite good enough. A more subtle approach would incorporate device resolution.

Step 7 – link to the media queries CSS file added to page layouts

• site is now fully responsive, with no disruption to service

Step 8 – apply design to non-T4 elements of our web presence

• simply used a variation of a T4 page layout to create a template

Library

Limitations & Issues • less flexibility for creating content

• images position determined by content type • a “raw code” content type used for hand crafting special cases • could be argued that resulting page consistency is a plus

• Reliance on using hidden divs.

• added overhead for page download • mitigated by removal of graphics from the design

• Some link areas too cluttered (eg footer)

• makes touch selection difficult on mobile

• “Purity” of the design compromised by needing to fit it on to an existing site • process of “continuous improvement” as sections are updated

Library

Font size issues

... on mobile: <meta name="viewport" content="width=device-width" /> Prevents “smart phone shrinking” and hence 1em = 1em

... tablets & desktops :

need to take into account • screen resolution (eg. 1024x768px) • pixel density - 72 ppi (PC), 96 ppi(Mac), 226ppi (Retina) • viewport size

to provide optimum reading in all cases

Our viewport based solution works but less than optimum for reduced windows on large screens

Library

In practice ... Benefits of the responsive site

• site works as well, or better, than non-responsive version (code needs to be good) • improved accessibility support • transparent to users (most are unaware that site presentation varies) • essentially device/software independent • improvements resulting from consideration of every element in detail (do we need it? What is the purpose? Relative importance?) • maintenance, updating simplified. A new look would be easy to deploy.

Library

New problems encountered

• stricter control required with content contributors. Some heavily graphical content simply won’t work well on mobile. More thought on content design required.

Non responsive content

Library

• training/support issues – as site’s appearance can vary, demonstrations & screenshots have been problematic.

• need to change mind set of teachers/trainers

• cannot provide a “full site” view on mobile devices (not without some additional JavaScript) • does responsive design impact on the nature of the web?

• are practical constraints on what you can/should do with the web acceptable?

Library

Lessons Learned: • “retrofitting” an existing site is more difficult than starting with a clean sheet. If you can, throw the old site away. • don’t think in terms of devices. Think in terms of “viewports”. • Minimize the use of graphic files for cosmetic effect • let the browser do it’s job. Don’t try to force an effect or presentation if that’s not how the browser wants to do it. • CSS is the key to everything – think of your HTML code as no more than markers for the CSS to work with. Minimise presentation/layout in your HTML content • T4 content types may be needed to enforce your “fluid grid” structure

Library

Library

Library

Conclusions: • “Responsive design” is not really anything special, apart from use of ‘media queries’ • if you have followed “good practice” you will need minimal changes (if any) to your code • significant ‘incidental’ benefits from applying responsive design

Responsive Design = Good Design • But there may be penalties

http://www.port.ac.uk/library/