University of Portsmouth Library: A practical approach to Responsive Design
1 like1,086 views
The document outlines the development of a responsive website for the University of Portsmouth Library, detailing the planning and implementation process amidst budget constraints and existing site redesigns. The approach included moving to a fluid grid layout, utilizing CSS techniques, and ensuring compatibility across various devices, ultimately achieving a site that improves accessibility and user experience. Key lessons emphasize the challenges of retrofitting existing sites and the importance of considering content design versus strict device formats.
University of Portsmouth Library: A practical approach to Responsive Design
- 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/