Yes, like everyone else in web development, eBay has become immersed in the mystical world of Responsive Web Design. In fact, our top priority for last year was to make key eBay pages ready for multi-screen. Engineers across the organization started brainstorming ideas and coming up with variations on implementing a multi-screen experience. We even organized a “Responsive vs. Adaptive Design” debate meetup to discuss the pros and cons of various techniques. This post summarizes some of the learnings in our multi-screen journey.
There is no one-size-fits-all solution
This is probably one of the most talked-about points in the responsive world, and we want to reiterate it. Every web page is different, and every use case is different. A solution that works for one page might not work for another – in fact, sometimes it even backfires. Considering this, we put together some general guidelines for building a page. For read-only pages or web pages where users only consume information, a purely responsive design (layout controlled by CSS) would suffice. For highly interactive pages or single-page applications, an adaptive design (different views dependent on the device type) might be the right choice. But for most cases, the RESS (Responsive Design + Server Side Components) approach would be the ideal solution. With RESS we get the best of both worlds, along with easier code maintenance and enhancements. Here the server plays a smart role by not switching to a completely new template or wireframe per device; instead, the server helps deliver the best experience by choosing the right modules and providing hints to the client.
User interaction is as important as screen size
Knowing how a user interacts with the device (keyboard, mouse, touch, pointer, TV remote, etc.) is crucial to delivering the optimal experience. Screen size is required for deciding the layout, but is not in itself sufficient. This point resonates with the previous point about RESS: the server plays a role. The first hint that our servers provide to the browser is an interaction type class (touch, no-touch, pointer, etc.) added to the root HTML or module element. This class helps CSS and JavaScript to enhance features accordingly. For instance, the CSS :hover pseudo selector is applied only to elements having a no-touch class as a predecessor; and in JavaScript, certain events are attached only when the touch class is present. In addition to providing hints, the server can include/exclude module and JavaScript plugins (e.g., Fastclick) based on interaction type.
Keeping the importance of user interaction in mind, we created a lightweight jQuery Plugin called tactile just to handle gesture-based events: tap, drag (including dragStart, dragEnd), and swipe. Instead of downloading an entire touch library, we felt that tactile was sufficient for our use cases. By including this plugin for all touch-based devices, we enhance the user interaction to a whole new level, bringing in a native feel. These results would not be possible in a purely responsive design.
Understanding the viewport is essential
At a glance the term ‘viewport’ sounds simple, referring to the section of the page that is in view. But when you dig a little deeper, you will realize that the old idiom ‘The devil is in the detail’ is indeed true. For starters, the viewport itself can have three different perspectives: visual viewport, layout viewport, and ideal viewport. And just adding the default viewport meta tag <meta name="viewport" content="width=device-width, initial-scale=1"/> alone may not always be sufficient (for example, in a mobile-optimized web app like m.ebay.com, the user-scalable=no property should also be used). In order to deliver the right experience, a deeper understanding of the viewport is needed. Hence before implementing a page, our engineers revisit the concept of viewport and make sure they’re taking the right approach.
To get a good understanding of viewports, see the documents introduction, viewport 1, viewport 2, and viewport 3, in that order.
Responsive components vs. responsive pages is a work in progress
Another idea that has been floating around is to build components that are responsive, instead of page layouts that are responsive. However, until element query becomes a reality, there is no clear technical solution for this. So for now, we have settled on two options:
- The first option is to use media queries at a component level, meaning each component will have its own media queries. When included in a page, a component responds to the browser’s width and optimizes itself (based on touch/no-touch) to the current viewport and device. This approach, though, has a caveat: It will fail if the component container has a restricted width, since media queries work only at a page level and not at a container level.
- The second approach was suggested by some engineers in the eBay London office, where they came up with the idea of components always being 100% in width and all their children being sized in percentages. The components are agnostic of the container size; when dropped into a page, they just fit into whatever the container size is. A detailed blog about this technique can be found here.
We try to implement our components using one of the above approaches. But the ultimate goal is to abstract the multi-screen factor from the page to the component itself.
We can at least remove the annoyance
Finally, even if we are not able to provide the best-in-class experience on a device, at minimum we do not want to annoy our users. This means following a set of dos and don’ts.
Dos
- Always include the viewport meta tag
<meta name="viewport" content="width=device-width, initial-scale=1"/> - Add the interaction type class (touch, no-touch, etc.) to the root HTML or module element
- Work closely with design to get an answer on how the page looks across various devices before even starting the project
Don’ts
- Tiny click area, less than 40px
- Hover state functionality on touch devices
- Tightly cluttered design
- Media queries based on orientation due to this issue
This post provides a quick summary of the direction in which eBay is heading to tackle ever-increasing device diversity. There is no silver bullet yet, but we are getting there.
Senthil
Engineer @ eBay