Library
Stop the talk, make it happen
A practical approach to responsive design - a work in progress

Colin Work
Web & Com...
Library
Context
• Resources – 1 person, effectively no budget
• Hosted on corporate T4 service, but independent to main Un...
Library
Business Case
•From the top “We need a mobile app!” (Late Spring 2012)
• student recruitment led, impact of fees

...
Library
Planning
Constraints:
• no additional resources/budget available
• major site revision already nearly complete, fo...
Library
Plan A:
Launch website on schedule and follow with a separate site for mobile, using shared T4 content
(through co...
Library
... but conferences, workshops summer/autumn 2012 led to ...

Plan B: the responsive website.
Pros
• single versio...
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 b...
Library
“Nested” Grids
• allowed max re-use of existing layouts & types
• minimise impact on users and content providers
•...
Library
Step 3 – create a CSS file to replicate the current site using new page layouts and content types.
• within CSS, (...
Typical page on non-responsive site
‘Default’ layout on responsive site
images
Potential issues
Fixed width tables
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 si...
Library
CSS Snippet
@media only screen and (min-width:731px) and (max-width: 805px) {
#right_panel, #mob-foot-address, #mo...
Right side bar now hidden, but content still
available from the top bar navigation
Header reduced in size

Search widget replaced
with link to a page
Content rearranged & image size
reduced in CSS

Footer ...
Menu navigation
replaced by menu
widget

New footer layout

Breadcrumb trail added
Library
Step 6 – create a 2nd CSS file to handle “media-queries”
• a 2nd file is not a necessity, but it allowed for a tra...
Library
Limitations & Issues
• less flexibility for creating content
• images position determined by content type
• a “raw...
Library
Font size issues
... on mobile:
<meta name="viewport" content="width=device-width" />

Prevents “smart phone shrin...
Library
In practice ...
Benefits of the responsive site
• site works as well, or better, than non-responsive version (code...
Library
New problems encountered
• stricter control required with content contributors. Some heavily graphical content sim...
Library
• training/support issues – as site’s appearance can vary, demonstrations &
screenshots have been problematic.

• ...
Library
Lessons Learned:
• “retrofitting” an existing site is more difficult than starting with a clean sheet. If you can,...
Library
Library
Library
Conclusions:
• “Responsive design” is not really anything special, apart from use of ‘media queries’
• if you have...
University of Portsmouth Library: A practical approach to Responsive Design
Upcoming SlideShare
Loading in …5
×

University of Portsmouth Library: A practical approach to Responsive Design

0 views

Published on

'A practical approach to responsive design by the University of Portsmouth Library':Colin Work from the University of Portsmouth outlines how they used TERMINALFOUR Site Manager to make the Portsmouth Library sites responsive. The approach, the challenges, lessons learned and more.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
0
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

University of Portsmouth Library: A practical approach to Responsive Design

  1. 1. 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
  2. 2. 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
  3. 3. 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 AY 2011/12 cf 2010/11 -4.16% +62.13% AY 2012/13 cf 2011/12 +34.39% +152.15% Tablet n.a. +486.65%
  4. 4. 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”
  5. 5. 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?
  6. 6. 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!!
  7. 7. 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.
  8. 8. 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.
  9. 9. 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)
  10. 10. 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.
  11. 11. Typical page on non-responsive site
  12. 12. ‘Default’ layout on responsive site
  13. 13. images Potential issues Fixed width tables
  14. 14. images Issues addressed with <div>s & CSS styling
  15. 15. 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
  16. 16. 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
  17. 17. Right side bar now hidden, but content still available from the top bar navigation
  18. 18. Header reduced in size Search widget replaced with link to a page Content rearranged & image size reduced in CSS Footer rearranged
  19. 19. Menu navigation replaced by menu widget New footer layout Breadcrumb trail added
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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.
  24. 24. 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
  25. 25. 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?
  26. 26. 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
  27. 27. Library
  28. 28. Library
  29. 29. 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/

×