Slide 1: Good Morning and welcome to this session on Responsive Web Design at Contec Frankfurt. I am Michael Cairns from Publishing Technology and I am joined by Michael Kowalski from web consulting firm Contentment. We are going to speak to you today about Responsive Web design (RWD) – what it is, how it works and why you should consider RWD as your method of dealing with an ever changing and growing set of screen sizes and devices. Essentially, as a content owner and distributor you will want to provide your customers and clients with a consistent and optimized view of the material you put in front of them. You don’t want to make compromises and we will show you how having a RWD strategy can help you meet your client expectations and enhance the user experience.(Click on the cover to see the entire presentation on slideshare)
By way of introduction, I am COO of the Online division of Publishing Technology. PT is a software and services provider for publishing and information businesses around the world. We are a public company and we work with a who’s who of publishing and content owners all of whom I am sure you would recognize. The Online division, which I run, comprises two main products: IngentaConnect which is a content hosting provider for small and medium sized journal publishers (although not exclusively) and pub2web which is a content platform that enables publishers to manage their content and manage all interaction with their clients. For example, if you subscribe to content from the American Institute of Physics you would be using the pub2web platform to access your subscription. We provide a very powerful platform that enables publishers to manage their content, access, membership (in some cases) and even their publishing schedules. Our clients are in the scholarly and academic publishing sector although PT’s client base in more broad than that.
Slide 2: These are contact details for each of us and Michael K will introduce himself in a few minutes.
Michael Cairns, Chief Operating Officer – Online, Publishing Technology
michael.cairns@publishingtechnology.com
Michael Kowalski (Contentment) - Founder at Contentment
michael@getcontentment.com
I am going to provide an overview of RWD and Michael K will then give some real life and practical suggestions that come from his experience in working with a variety of clients on a consultative basis
Slide 3: Over the past five years (and possibly longer) there has been a constant flow of articles and blog posts about RWD but, it is really only in the past two years or so that RWD has come into the mainstream where, for example, we are seeing panel discussions at scholarly publishing conferences discussing RWD. Incidentally, most of this presentation was given at the SSP winter conference in San Francisco back in May by my colleague Toby Plewak who deserves credit.
For anyone in the audience who wants more information about RWD simply Google the term and you will find yards of material. It is quite likely that the first item returned will be something by Ethan Marcotte and his stuff on RWD is really worth reading. I read this article he wrote in 2010 again last night as a refresher and his article covers much of what we are discussing today.
For those who have some idea what RWD is all about, you will also know that the concept isn’t really a new idea, but it has gained steam recently due to the proliferation of these newer technologies and solutions such as HTML 5, CSS 3 and media queries. Michael K will speak to these in a few minutes.
Slide 4: As I noted, the proliferation of devices is probably driving your design staff crazy since they fight every day to make your content look perfect on every conceivable new device. There is a diminishing return to this effort; moreover it is unlikely to be sustainable. So here is a quote from Jeffrey Veen at Adobe who believes that RWD is the way of the future – at least for the next ten years.
“Day by day, the number of devices, platforms, and browsers that need to work with your site grows.
Responsive web design represents a fundamental shift in how we’ll build websites for the decade to come.”
- Jeffrey VeenVice President, Products at Adobe
Slide 5: So what are we comparing when we speak of content delivered using the concepts of RWD versus the older traditional, fixed-width websites. These sites are rigid, inflexible and render legibly only when viewed at full-size on a desktop browser. They are designed to work in a single context and once we begin to interact with them outside of the context they were built for – namely sitting at a PC or full-screen laptop, they start to give us trouble.
We suggest that they represent old thinking: That the desk-top was going to be the primary – perhaps the only – way we would be consuming content. This assumption is obviously not the case.
Traditional websites will satisfy a designer’s impulse for control, predictability and order in a design however, from a usability perspective they fail on many levels for today’s typical content consumer.
Slide 6: Content access issues abound and we’ve all been there. Perhaps we find ourselves using a mobile device to access content we normally interact with on the desk top. This is a changing use pattern we are seeing more and more frequently. Your experience will instantly become confusing, annoying and frustrating when you find you can’t access the content as you would expect. You will be left to wonder why that should be the case. Why should my device or point of access matter?
Once we squish a website like this it into a small-screen device finding content becomes a needle-in-a-haystack sort of exercise: we are forced to zoom, pinch, scroll up, down, left and right to find or view what we are looking for. Navigation is nearly impossible and a finger sometimes needs to be as pointy as a sewing needle to tap a link or a button. The best/worst examples of this can be wifi access points where you are left to find the “Get on Line” button on your iPhone when it is so small it looks like a single solid line.
In short, a fixed-width website becomes virtually unusable as screens get smaller and our content becomes harder to access, navigate and interact with.
We could even end up having a Hugh Grant moment if we become too stressed out about this inconvenient experience. For those who remember his frequent refrain during that movie will know what I am talking about.
We will talk a little today about “context” and your user because it is important to understand where and how your target users interact most with your content. A nurse on station will have an entirely different requirement for access and use than perhaps a paramedic. The content they require may be the same but the ‘context’ the user finds themselves could be vastly different. A paramedic under stress is not going to want to zoom and pinch to determine what type of diagnosis to make.
Understanding how your customers access and use your content is an important first step in defining your RWD strategy.
Knowing whether they are at a funeral a wedding or some other event could prevent a melt down.
Slide 7: So this is where RWD comes in.
The Web is by nature a dynamic, flexible medium, and many people have suggested that RWD is the next natural phase of its evolution. In the past, designers and their clients spent huge amounts of effort trying to attain print-like pixel-perfection in their designs, like print projects, they attempted to make their websites look the same across the then-limited amount of available devices, resolutions, browsers and screen-sizes. But those days are over and that type of activity will begin to look anachronistic. Responsive design is a digression from this type of thinking. It forces us to think bigger, to put our USERS, our CONTENT and the Way(s) users access that content – that is CONTEXT at the CENTER of the design process.
RWD forces us to design SYSTEMS rather than just static INTERFACES - systems that can maintain the best possible access to, and presentation of, our content regardless of the device or screen-size.
Even the screen you are viewing this presentation on could legitimately be considered a ‘device’ screen and that is certainly true of television screens not just computers and mobile devices.
Slide 8: By now you should have a sense of what RWD is, but here is a specific example. The Boston Globe has been one of the pioneers in RWD and we can see how this works by viewing the Globe site using a traditional web browser. If you slowly reduce the browser window by pulling it slowly from the right edge to the center you can see at a certain point the content and design moves and changes. Content is stacked, menus are consolidated and made compact, images are resized, etc.
This process uses media queries to ‘sniff’ your browser and render the Globe content to match the device you are using. Media Queries are little bits of code that measure the width of the given screen and tell the browser how to adjust the size, placement and hierarchy of a given page’s elements. Using the principals of RWD, content is optimized based on the device you are using. RWD is a flexible, grid-based layout that expands and contracts based on the size of a given device’s screen and it uses flexible images, scalable typography and media that changes size when a different screen size is used. For example, going from an iPad to an iPhone.
Slide 9: Other examples of RWD sites are these here but I am sure you will find more on your own.
· www.ft.com
· Bostonglobe.com
· Qz.com
· Mashable.com
Slide 10: If providing a consistent optimized experience for our content users isn’t sufficient reason then consider that Google favors this approach. Google likes to access one url for site content rather than multiple urls that can exist when publishers create mobile specific versions of their content. Google doesn’t like that approach because they believe it doesn’t create a useful experience for their search customers.
On the Google web site you can also find this definition of RWD:
“Responsive web design is a setup where the server always sends the same HTML code to all devices and CSS is used to alter the rendering of the page on the device using media queries.”
One other aspect of RWD is cost and typically (in the absence of doing nothing) the alternative to RWD is often to build apps for the predominant operating systems such as iOS, Andoid, etc. Yet with as many device types as we are currently beginning to see – and we at IngentaConnect see a similar number of devices hitting our site - the ability to keep ahead of this from a development stand point has the potential to become very expensive. RWD may cost more upfront in development but over the long term it will be cheaper than the App approach as the number of device types and the need to tune your apps for every device continues to explode.
Slide 11: I almost omitted this slide, because in 2013 I don’t think I need to convince anyone here at Contac that mobile is important. It just emphasizes our point.
So why is RDW important?
Because more of our users are either going mobile or accessing our content from a variety of devices and they expect the same experience from one device to the other. All of us are consumers of content and we expect the same thing so why would we think our customers are different?
Here are some other stats:
· 2015 – 7.4 Billion wireless devices sold
· 1.2Billion smart phones devices enter the market over the next 5 years
· Enterprise table adoption grows by 50% year
Just this morning I saw this stat from Forrester - 35% of US mobile phone owners have used their device while shopping in a store in the past 6 months – which stat suggests whoever is delivering content to users in retail stores need to increasingly think about “context” as I mentioned earlier.
In this area, you don’t have to look far for some good stats.
Slide 12: So it won’t come as a surprise to anyone that mobile access is on track to outpace desktop access. This chart is reflecting internet usage in general, but we’re all seeing similar trends on our websites at PT. We’ve all known this, and for several years now we’ve all been working frantically to make our content accessible to mobile users.
Slide 13: As an indicator of how complex the delivery of content on mobile devices is becoming this page from the Cornell library website spends and inordinate amount of time and space explaining how to access the myriad offerings from a wide variety of content providers. This section reads like a rogues gallery of mobile publishers’ experiments in mobile strategy – apps for iPhone, apps for tablets, apps for Android, mobile optimized websites. Different hoops to jump through for access – paid apps, free apps that require subscriptions, mobile device pairing, etc. I don’t mean to call anyone out – there are some great apps listed on these pages: But looking at these pages got me thinking about the various problems and limitations in the mobile solutions we’ve tried so far.
Slide 14: Creating an optimized experience for your users could leave you feeling a little confused but for our users the experience is even more disorienting. We’re asking our users to access the same content in very different ways depending on what device they are using to access the internet. This can’t be a sustainable environment for content producers or users.
We suggest that without a RWD solution the typical mobile development process will not support your long term objectives as users change the way they interact with your content but naturally expect a consistent experience.
Slide 15: Without a RWD strategy our only option is to make assumptions and decisions about how to reach (and market to) our readers based on what device they have in their pocket. And as a result we are investing in mobile solutions one platform at a time. This is especially true when we are talking about native apps, but it also applies to many of the mobile sites we’ve built, optimized for one device over another. As I mentioned it becomes an expensive proposition to support all of these different solutions, especially if you’re only doing it to serve your existing subscriber base which means new costs but no new revenue
Slide 16: What typically happens is someone says we need a mobile web site or presence.
So we try mobile websites, and we strip them down and optimize them for the “mobile use case”.
But guess what this is all in vain as a recent survey from IBM suggests. Users want mobile to be *AT LEAST* as good as the desktop website. What a surprise! This is supported by the “View Full Site” button, a recommended best practice for those stripped down mobile websites. We’ve all seen that button, and importantly, most of us have had occasion to click it. At the very least that is a cop out and we can do better.
Think about that paramedic under intense circumstances having to click on that button.
Que the Hugh Grant explosion.
Slide 17: So when you begin to think about how you are going to start a RWD project these are some of the things you should consider versus the app approach.
App Approach:
· Do I want or need to be in the App store?
· Do I rely on or make use of device specific functionality like the camera?
· Do I have a specific functional focus?
RWD:
· Do I have a content focused approach?
· So I need broad device support
· I may have frequent content changes
· I need better discoverability via a 3rd party like Google
Slide 18: It is generally better to be able to start from the smallest access point outwards however most content producers already have a web presence where content access has been thought about in terms of the desktop browser. That said each of these five considerations should be thought about by your team as they think about rolling out a RWD program.
Audience
· Assumptions about your audience: what they do, how they work, what content they use and why, etc.
· The audience “contexts”: where are they using the content, are there constraints?
· Always consider the typical devices, the environmental, user, psychology.
Content & Functionality
· Do you have a content strategy in place?
· Determine whether your internal processes need to change?
· Do your users need interactive content? Multimedia or other content formats?
Capabilities
· How will you support HTML5.0/CSS3/JS expertise
· UI/User design expertise will be required
· Don’t short change testing and user acceptance
Cost – potential to lower cost over time if one code base
· RWD expenses can be up front due to increased complexity and scope but less over time versus
App development
Process
· A mobile first or the smallest screen upwards produces the best overall results: work from smallest out
Slide 19: As I mentioned earlier ‘context’ is really important and you will need to understand how your primary users interact with your content. Some things you will consider:
· How important are specific devices?
· Where are they likely to be using the devices – or do locations define the device.
· What are they doing when the use your content – that is what are their circumstances at the time? For example, are they typically under stress when using your content and is ‘time’ a serious consideration? In some cases potentially a life of death occurrence for a medical information provider.
It is important to understand how your users are using your content in a variety of situations and circumstances. That understanding can help you define your RWD approach.
Slide 20: Which brings us to the other big challenge we’re facing - the pace of change in the device space. It seems to be ever accelerating. There was even word recently that Apple may bring out a larger format iPad next year.
Slide 21 HTC has more than 20 screen sizes. Giving 30% to Apple
Slide 22: We can’t forget Samsung.
Slide 23: It is also important to understand that the lines between devices are blurring. The largest Samsung smartphone is not much smaller than the new iPad Mini. iPad + a keyboard is no smaller than my laptop. This Microsoft Surface tablet ships with a keyboard. This new Asus laptop has a touchscreen interface on the lid.
Slide 24: Publishers don’t need a “mobile” strategy. We need to completely rethink our ONLINE strategy.
Slide 25: A successful RWD project entails many if not most of the same considerations as a more traditional design implementation, and then some.
· Since we are designing for any number of devices, screens and contexts, we need to invest more time and effort up-front, gain a better understanding of our users, the way they access and use our content: what is important to them, and what is less so and use this as our foundation for planning.
· We need to prioritize how accessible our online offerings are based upon this understanding. We need to build flexible navigation structures, accommodating grid patterns, and a user experience that enables the largest amount of people on the broadest possible range of devices to find, explore and consume our content.
· We need to design for fat thumbs, for people standing on a crowded train or lying in bed, for a researcher trying to look up the name of an influential colleague whose name he forgot, who he’s about to meet with in 15 minutes.
· Lastly, we need to test our designs across devices, browsers and screen sizes. Get your site or prototypes into the hands of users and learn from them. Revise, test, repeat. It is an ongoing process.
It is a way to get your content out there, to take it beyond the bounds of the office or university walls.
Slide 26: So what is RDW in summary. It enables content owners to,
· Maintain one website that serves all devices and screen sizes
· Provide complete support for (almost) all website pages and features, regardless of device or screen size.
· Implement changes across all device
Slide 27: Lastly no presentation is complete without a quote from Bruce Lee and this one perfectly describes the RWD concept:
“When you pour water in a cup, it becomes the cup. When you pour water in a bottle, it becomes the bottle.”
Think about that.
0 comments:
Post a Comment