'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.

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Typical page on non-responsive site

12. ‘Default’ layout on responsive site

13. images
Potential issues
Fixed width tables

14. images
Issues addressed with <div>s & CSS styling

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. 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

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

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

20. Menu navigation
replaced by menu
widget
New footer layout
Breadcrumb trail added

21. 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

22. 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

23. 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

24. 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.

25. 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

26. 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?

27. 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

28. Library

29. Library

30. 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/