Presenters:

Aaron Ganci, User Experience Designer, OCLC
Bob Robertson-Boyd, Senior Product Analyst, OCLC
Hany Elemary, Senior Software Engineer, OCLC

Presentation Description:

OCLC has developed a new Web interface for the FirstSearch product using responsive design techniques. We have previewed this new interface with 19 institutions and in early 2013 we will go into open beta with the thousands of libraries currently subscribing to FirstSearch. We will describe the project from its beginning to the present and share what we have learned throughout the process. The majority of our presentation will focus on the technical aspects of implementing a mission-critical Web interface for desktop, tablet, and mobile devices using HTML5 and CSS3, including how we leveraged this emerging technology to meet the core principles of our business: performance and accessibility.

Discussion points:

• The importance of understanding your content in order to build the semantic structure of pages and use microformats to extend your reach across the Web.

• WCAG and ARIA accessibility guidelines within our application.

• The use of progressive enhancement and CSS3 media queries to design interfaces that fit various device capabilities and viewports.

• How to support a rich user experience by using CSS3 hardware accelerations, as opposed to JavaScript, to improve transitions and animations.

• How to off-load data requests to improve performance.

Related Resources:

• Slide Deck
• An Event Apart: Responsive and Responsible

How has AGILE impacted the way you think about work?

Simplicity–the art of maximizing the amount of work not done–is essential — The Agile Manifesto.

Agile encourages you to think really small and break tasks down to the smallest level of detail. Complexity comes naturally to any software project so it’s best not to force it upfront. Agile is essentially about shipping the minimal viable product (MVP) and delivering incremental improvements along the way.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage – The Agile Manifesto.

By welcoming requirements’ changes, Agile encourages quick adaptation. Generally speaking, change is the only thing you can bank on these days, and this is especially true in the software world. The way we do it is that we plan for the release (3 months), but not in great detail as things may change or shift around a little bit. Then, we plan and design in great detail for the upcoming sprint (which happens to be one week in our case) as requirements are much less likely to change in the span of a week than 3 months.

How has AGILE impacted the way you think about people and teams?

Agile attempts to eliminate what I like to call the “superstar” problem. Within the organization, your team may have a superstar or two. What happens when the super star leaves on vacation or gets sick? The business basically stops until they come back. Agile encourages working cross-team/cross-role so that you’re not dead in the water without your superstars.

So, to summarize, we don’t just have a UI developer or a service/API developer. We have software engineers who can pretty much work in any area. Obviously, some of them are more passionate, and hence talented, than others in their areas of interest/expertise. But the point is that we all can do each others jobs to a high degree.

How has AGILE impacted the way you think about leadership?

I feel empowered and heard. When I was first hired, I was contributing to technological decision making within the first two weeks.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done — The Agile Manifesto

Conclusion:

To me, Agile is about two things: 1. Practice and 2. Flexibility. If you haven’t had much luck with it, you’re likely to have been denied either or both.

I’ve been fortunate enough to land in a place where Agile practices are carried properly. But after all, Agile is not the work. It’s a process and it’s a means to an end (shipping software). So if you’ve given it an honest chance/try, and for whatever reason, it didn’t work for you, don’t let it become your religion.

Goodbye 2012, and hello 2013. 2012, you’ve been quite harsh at times and rather kind at others. There is no reason to expect otherwise from the years to come, but I’m hopeful that they’re better.

Gotta keep the tradition of posting my new year’s resolutions.

13 Resolutions for 2013:

1. Finish the 50 pull-up challenge
2. Listen to your body and stay healthy
3. Eat more vegetables and less red meat
4. Speak at a developer’s conference
5. Redo your blog with Ruby on Rails and MongoDB and make it responsive
6. Contribute to an open source project
7. Write at least 1 article/month on your blog
8. Share more code and techniques
9. Write your own music (1 song) on the guitar
10. Start master’s degree
11. Learn Spanish
12. Travel to at least 2 new places
13. Take note of conditions that lead to moments of creativity and recreate

12 Resolutions for 2012:

1. Finish the 100 push-up challenge
2. Finish the 50 pull-up challenge (carried over to 2013)
3. Finish The Tough Mudder Event
4. Become a 4.5 tennis player
5. Read “Strength Finder 2.0″ and work towards capitalizing on your strength
6. Read “Roger Federer’s” biography
7. Learn Spanish (carried over to 2013)
8. Write at least 1 article/month on your blog (carried over to 2013)
9. Learn 4 songs on your acoustic guitar
10. Start a fun project with many different technologies as part of ongoing learning
11. Prioritize effectively and work efficiently
12. Say “No” more often when time is tight

What are your resolutions for 2013?

“Pity gives way to respect when much more value is delivered than originally expected.” - John Maeda, The Laws of Simplicity.

What a great quote! That’s exactly how I felt a few weeks ago when I helped a friend install Nest in his house. Nest is a classic case of simple design. It is also a great example of a Natural User Interface (NUI). These interfaces encourage users to interact through their simple, seemingly familiar design. For instance, in Nest, there is only one/two input controls; the ring and the clickable screen itself. There is nothing else that gets in the way. The user is not overwhelmed with a bunch of options and, therefore, decisions become more obvious. Watch this 4-minute video on the setup process then read on…

The most interesting part to me was the use of the same input device (the ring) with inherently different UI components.

List Menu:

The ring is used with different list options (Wifi Networks in the video). By rotating the ring, the user is able to step through (highlight) each option in the list.

Input Field:

Another use case for the ring is typing in a text box (password in the video) by selecting letters, numbers and special characters from the screen.

Spinner/Range Fields:

Yet a third use case is applying the ring as a spinner field to loop through a list of numbers to set the zip code. And lastly, the main use case, adjusting the thermostat, is also controlled with the ring. Rotate right for heating and left for cooling, as the interface provides feedback through the temperature in degrees and color codes (orange=heating, blue=cooling).

Design Decision:

The interface highly demonstrates good design decisions. Notice, for instance, how confirming actions are made a bit more explicit by clicking on the screen or the ring. This way, users don’t get frustrated confirming an action they didn’t explicitly make. All other options are made more forgiving by using the ring/wheel.

Conclusion:

When users have a limited set of options, they have no choice but to zero in on those available options and start interacting with them.

“Proportionately more attention shall be paid to that which is made less available.” - John Maeda, The Laws of Simplicity.

By the time users work their way through the first UI control, they’re experts at using the thermostat. Learning one use case means learning a whole set of familiar interactions in this UI.

As designers, we have to remember that each time a user gets introduced to a new option, there is some level of uncertainty. It takes a special designer to cut down on those uncertainties by reducing the options in a way that’s still fully functional and appealing. Now compare Nest my friend’s more familiar-looking, older thermostat.

Overwhelmed? I’d like to hear your thoughts.

We can’t ignore our users if we never allow them to introduce features in the first place.

This weekend, a random, strong thought popped in my head. I couldn’t fit it in a twitter post, so I’m starting a new short series of posts called “As I see it.” What triggered this thought is a presentation at “No Fluff Just Stuff” conference in Columbus, Ohio, about UI/UX design and user feedback. The presenter, who shall remain nameless, said “Once you have a stable product, ignore feedback from users as it will only cloud your vision.” Something to that effect anyway … I’m slightly paraphrasing.

While I sort of agree with his statement, to me, it felt like it stood against being empathetic to the user. It also got me thinking that if we change our mental model, we never have to deal with muddy feedback. So here it is: we can’t ignore our users, if we never allow them to introduce features in the first place. Instead, we need to move up the abstraction ladder and ask them what problems they’re trying to solve. Then we (product owners/designers/developers) analyze these problems and introduce solutions in terms of features.

I realize this is easier said than done and that it takes a “master of craft” kind of person to actually train users not to provide feedback in terms of UI changes or features (something that’s engraved in every user of software these days). But the question is: is it possible? Would like to hear your feedback.

Although native apps (along with their design details) are discussed in the book, the book’s main focus is on the mobile web experience. On that topic, Luke focuses on three main ideas in the book and discusses the design details around them. The ideas are as follows:

• The inevitable growth of mobile, which leads to new opportunities
• The constraints of mobile, which lets you focus on content & organization
• New innovative features that lets you think differently about design

One of my favorite parts in the book is a great analogy made by Rachel Hinman at Nokia that desktop is like “diving” while mobile is “snorkling.” Luke takes this analogy and adds further wisdom to it by saying that in both “diving” and “snorkling” you’re looking at fish underwater. Meaning that the core value of your website stays the same regardless of how it’s accessed. “So, don’t deny people access just because they’re on a mobile device.”

There are plenty of good quotes and takeaways from the book. I only included the ones that were really interesting to me. 

Content:

- “There simply isn’t room in a 320×480 pixel screen for elements of questionable value.”

- “Reduction is the best layout approach available to you on mobile.”

- “When interacting with mobile devices, people are in one eyeball one thumb mode.”

- “When it comes to mobile forms, be brutally efficient and trim, trim, trim.”

Design Gotchas:

- When designing for the mobile web experience, it’s very common to include controls/actions at the bottom of the screen. While that’s common due to the fact that people use their thumbs for touch, you have to be careful as to not interfere with the phone’s hardware buttons (back button, search button, home button, menu button, etc).

- Destructive actions such as “cancel” or “delete” should be placed uncomfortably out of reach as to not be mistakenly clicked when using other controls. Also, this makes people think hard about the destructive action they’re about to take.

- Set the user expectation. If you present the user with something that looks swipe-able, it better swipes or else the user will be frustrated.

Closing remarks:

- “The mobile web experience is getting better. Device APIs are being worked on as we speak. This will result in tighter integration between your phone’s hardware and the web browser.”

- “Welcome to mobile where the only thing you can count on is change.” My takeaway here is that we need to design our layout responsively, and adapt accordingly. Also, as Luke suggests, we need to accept that this area will be in constant change (at least for some time) so “prototype, prototype, prototype” to see what’s working and what’s not.

All in all, there is lots of great design details that make up this awesome, easy and engaging read (only 120 pages). It is a “must read” if you’re considering mobile in your company.

- When choosing a technology – Ted Neward

• Resist the familiar.
• Reject the goal of reuse until you have a pattern.
• “Best Practices” are our attempts to avoid thinking. So, it is helpful to think outside the box.

- Regarding processes — Barry Hawkins

• Don’t make a process your religion.
• Processes change quite often. So, be flexible.
• A process is not the goal, but a means to an end.

- Dealing with information overload — Scott Hanselman

• Psychic weight happens when your brain is literally going through a ToDo list for the week. Stop that and archive important reminders/info in a trusted source. A trusted source can be as simple as a piece of paper in this case.
• Effectiveness is running in a specific direction. Efficiency is being able to run well and fast in that direction.
• Stop trying to convince people of your position on twitter. Nothing important can ever be stated in 140 characters or less.

- On Responsive Web Design — Ben Callahan

• The web is not fixed-width. It’s never been. We (as developers) made it fixed width.
• Start with the smallest screen first when designing your web applications. If you approach the desktop first, things may get out of hand quickly.
• A mobile-first approach gives you insight into your most important content.
• Avoid using non-semantic CSS grid systems that force a specific naming convention for css class names. The class name “column-3″ may span 3 columns on the desktop view but spans only one in your mobile view, so “column-3″ becomes meaningless at the mobile view.

- On UI/UX Design — Jen Myers

• Design is not and should never be an after-thought. It’s not about making things look pretty. Instead, it’s about solving a problem.
• Designers are no longer just designers. Likewise, front-end developers are no longer just front-end developers. Both job descriptions are closely related and should cross-pollinate.

These quotes/takeaways are directly related to sessions I have attended. If you’d like to add other quotes/takeaways from the conference, feel free to leave them the comments below.

I can only hope that 2012 is just as good, if not better than 2011. But, hope isn’t a strategy so here are 12 resolutions for 2012 and an evaluation of my 11 resolutions for 2011.

12 Resolutions for 2012:

• Finish the 100 push-up challenge
• Finish the 50 pull-up challenge
• Finish The Tough Mudder Event
• Become a 4.5 tennis player
• Read “Strength Finder 2.0″ and work towards capitalizing on your strength
• Read “Roger Federer’s” biography
• Learn Spanish
• Write at least 1 article/month on your blog
• Learn 4 songs on your acoustic guitar
• Start a fun project with many different technologies as part of ongoing learning
• Prioritize effectively and work efficiently
• Say “No” more often when time is tight

11 Resolutions for 2011:

• Start a blog
• Become a 4.5 tennis player. (carried over to 2012)
• Start MBA degree
• Read “Open – Andre Agassi Autobiography”
• Help someone with great need
• Learn 4 songs on the acoustic guitar (carried over to 2012)
• Learn NoSQL databases and use them in a project
• Travel Internationally.
  • Toronto, Canada
  • Paris, France
  • London, UK

• Learn Spanish (carried over to 2012)
• Cook and eat at home more
• Find Balance

What are your resolutions for 2012?

To get a bit more technical, the idea is to have one HTML structure or code base that can be controlled and optimized by the CSS for different devices. It does so very elegantly by only detecting the resolution of the device/viewport. It doesn’t care about the device type or web browser running. So, if a specific resolution is detected, it applies certain presentation rules to optimize the experience for that resolution. In fact, this technique is gaining more ground that it has become an obvious alternative to creating native mobile apps. Ok … enough babbling. If you need more information on responsive web design, I highly suggest reading Ethan Marcotte’s article. Need more information still? Then also read Ethan’s book on the topic. It is simply remarkable.

But just like many other development strategies/approaches, nothing comes without a little bit of pain, mistakes and lessons learned. So, let me summarize some of the early lessons learned from using Responsive Web Design at work while catering for multiple viewports.

Lesson 1: Scale Up … Not Down

Ok, story time … After I finished optimizing a prototype web app for tablets and smartphones at work, it was time to demo progress to the product manager, Bob Robertson. Bob is not just a typical product manager. He has enough technical knowledge to call good developers out on their bullshit. He has very good understanding of usability and UX. Bottom line, he knows enough to be dangerous. But anyway, I digress. As I was showing Bob the web application, I said: “Notice as I resize my browser window how the modules scale down and optimize for the lower resolution so that …” And that’s when Bob interrupted me and said: “We don’t want it to scale down … We want it to scale up.” I liked the way Bob put a twist on this. However, I didn’t know exactly why I liked it.

Later during the week when we decided to display things in a slightly different order for mobile, I found myself going back to restructure the HTML. I didn’t like that very much. It was a simple change that affected the maintainability of the code. So, I thought: what would happen if it’s a bigger change? That’s when I really understood why Bob wanted me to take the progressive enhancement approach rather than graceful degradation. It is certainly easier to add components to your current design as you move up. It is the best way to code with change in mind. Additionally, designing at the smallest screen real estate forces you to think about your content. It forces you to assign priority to your content/structure. For instance, the content of most importance to the mobile user will most likely be the main content for tablets/desktops. Consequently, this content get higher priorities.

Now, let’s pause and think for a second … The truth is, if you’re writing a simple blog, either approach, progressive enhancement or graceful degradation, will work for you. However, if you’re writing a web application that’s complex in terms of interactions, themes, workflows, authentication and personalization, then progressive enhancement is a “must-take approach.” This will prevent you from spending lots of time refactoring your HTML. Why is this so important? Well … it’s not important at all if you’re the sole developer. It is extremely important, however, if you work within a large team with lots of shared HTML snippets, where changing one line of code can affect other workflows and developers.

Lesson 2: Avoid HTML duplication, when possible

Since we’re dealing with only one HTML structure for multiple viewports, sometimes unnecessary markup is rendered while not viewed. And even though the HTML rendered may not account for much, the less HTML rendered, the better the overall performance of the application. As a developer, it’s easy to have temptations to add more HTML to account for differences between viewports. And even though this is acceptable in some cases, it should be looked at as a last resort. To give a quick example, imagine a submit button that has the caption “Submit” on the desktop view. If the requirement is to have a button with an icon for the mobile view, developers might be tempted to add another html component (image), hide it at the desktop view, then show it at the mobile view.

Search page for desktop

Same search page for mobile (at a lower resolution)

Search Demo

Well, you can certainly accomplish the same effect without duplicating the HTML by just adjusting the CSS. In this case, you would include the submit button as usual. Then for the mobile view, you assign a background image to the button while moving the text off the screen. The “text-indent” CSS property is your friend here.

Obviously, that was a very simple example but it demonstrates using the same HTML structure while catering for aesthetic differences through the CSS.

Lesson 3: Handle responsive images with care

Most modern browsers handle image re-sizing quite well. Unfortunately, older versions of Internet Explorer don’t do the same and the quality of the images can suffer significantly when shrunk down. Especially if the image you’re dealing with has lots of text on it. Most likely, you will end up with an ugly, pixelated image. The good news is that there are some scripts out there that can handle this issue quite well in older versions of IE. I’m not going to get into the technical details of what these scripts do exactly. Instead, I have some references at the bottom of this article to some solutions Ethan Marcotte has come up with.

Another point is that it doesn’t always make sense to re-size images down to the mobile view. When shrunk down, images might be a bit too small to be meaningful. In some cases, it may make more sense if the image itself is a “crop-out” of the original image … Yes, another version of the image. But before you get all angry about the multiple HTTP request for both images, Ethan has been collaborating with the Filament group to experiment with mobile-first images that scale up responsively, all while not requesting multiple images. See further readings at the bottom of this article.

Lesson 4: Accept that there is no silver bullet

Remember at the beginning of the article when I said RWD works by only detecting the screen resolution? Well, I lied … Sort of lied anyway. To be clear though, RWD should work by only detecting screen resolutions. But due to the presence of un-elegant browsers such as older versions of IE, you will have to do more than just detecting screen resolutions. Yep … You got it. You will have to check for browser versions in your code. The question is, we’re targeting mobile, so why is IE so important? Simple answer … Windows Mobile browsers are detected as IE7. Yuck! So, if you need to cater for Windows mobile phones, you need to check the browser version.

And the funny thing is that Microsoft already knows that their browser is yucky and not standards-compliant so they support conditional comments in the HTML. These comments are ignored by all other browsers but get picked up by IE.

<!--[if lt IE 9]>
  <link href="ie8.css" rel="stylesheet" type="text/css">
<![endif]-->
<!--[if IEMobile]>
  <link href="winmobile.css" rel="stylesheet" type="text/css">
<![endif]-->

IEMobile is also detected as IE7. In this case, winmobile.css will be loaded if IE7 or IE mobile is detected, which causes problems. To get around this problem, you have to fall back on another conditional stylesheet that applies to any version less than IE9 (as shown above).

I sort of lied about something else as well … Sorry, but in some cases, you will not only be using CSS. But JavaScript can also come to the rescue when used with CSS. For instance, you may need some fancy interactions at the desktop level but not at the mobile view. These types of interactions typically require a JavaScript library. So you may choose not to load these JavaScript libraries conditionally. But this time, not using conditional comments. You will be using just regular JavaScript conditional logic.

Lesson 5: Team communication

If you’re a one man shop, then you’re the project/product manager, designer, developer and quite possibly, the sole user But, unfortunately (or may be fortunately), we don’t all work in this environment. For large scale applications, you often find different teams working together on the same project. Thus, cross-team communication is absolutely necessary. But it doesn’t stop there. You also need to communicate cross-job descriptions. From Product folks to UI/UX designers to developers … all have to be on the same page. Design meetings have to occur cross teams with developers and designers working together. That means being just a web developer is not desirable. You need to be a developer who understands how designers work. Likewise, being just a designer without understanding the basics of the web in general and responsive web design in specific is also dangerous.

Closing thoughts

Browsers have been getting better over the last couple of years. And HTML5/CSS3 are gaining more traction day after day. We’re constantly hearing about big companies ditching native mobile apps for HTML5 alternatives. Some of which are utilizing Responsive Web Design in their implementations. With that in mind, I strongly think that RWD is the way forward. When faced with limited time and resources, RWD just makes a lot more sense than developing a separate mobile site or native mobile app. It is also a great way for developing/desigining for change. For instance, I hate it when I have a widescreen monitor viewing a website that occupies only a small fraction of that, with small text that requires me to zoom in to read comfortably. Developers should adapt to that just as well as they adapt for mobile.

So … Design Responsively.

Further Readings

• Fluid Images – By Ethan Marcotte
• Mobile-first Responsive Images – Filament Group/Ethan Marcotte

CodeProject

After 5-10 minutes of poking around in the plugins section of WordPress, I came across one that did exactly what I needed; optimize my blog to run on mobile devices (iPhone, iPod Touch, Android phones, BlackBerry Storm & Torch and Palm Pre among other touch-based devices). The plugin is called WPTouch. I highly recommend it. If you’re looking at my blog on your mobile device, you’ll notice the difference. It is also highly customizable.

Enjoy!