Fun with Tables

For those who have maybe read one or two of my posts, you may have noticed that I draw inspiration from current events at my day job. It’s been awhile, but I’ve recently been asked to create a user experience for a table with the following display and functionality requirements:

  1. There is a default set of data that needs to be displayed, but no one seems to know who to ask to find out what the data is exactly
  2. The table can potentially display up to 17 columns (17 data segments)
  3. Users can customize the table view by hiding or revealing columns (data segments)
  4. Users can customize their table view by reordering the columns (data segments)
  5. Users need to be able to filter table data (rows)
  6. The table needs to be responsive, because the site is responsive
  7. We’d already designed a card view (previous iteration of a table scenario with less requirements), so our “new” table scenario needs to have continuity with the card

By now we (as an industry) have more or less figured out how tables on modern web sites (RWD) can render depending on the size of the screen. Such as:

  1. Tables (containing only numeric data) that switch to a pie chart when viewed on a small screen.
  2. Tables (with numeric and text data) that transition to a card or “cell” view when viewed on a small screen. See example.
  3. Tables that hide less important columns for smaller screens (not my favorite approach). See example.
  4. Similar to above, but a drop down menu is available to re-enable hidden columns that can be accessed with horizontal scrolling. See example
  5. Tables that flip x and y axis for smaller screens so the column headers are always visible while the data cells scroll left and right (on a small screen). See example. 
  6. Tables where the left-most column is “locked” in position on smaller screens and the remaining columns scroll, allowing for row-to-row comparison. See example.

Obviously, this isn’t the end-all-be-all list, but you get the idea. There are a lot of solutions out there, and luckily for me, I was able to adapt aspects of them for this particular ask. (With a little e-commerce conventions sprinkled in.)

Small Screen, Card View:
I decided that since a card view already existed (though with only 8 data points displayed), we would take a retail approach and treat this view as an “e-commerce” product card. Most e-commerce sites’ product cards (or tiles) contain an image, title, price, rating stars and number of reviews. In order for the customer to see more information about the product she needs to click through to the corresponding product detail page (PDP). Easy-peasy mental model.

Since each row in our table represented an individual item, and each item just happened to have a corresponding detail page, it seemed a logical solution. Why overcomplicate?

Also, it was decided that there was no point in offering the user the option to customize the information (requirements 3 & 4) while in the card view. The card data was predetermined and order locked, meaning trying to hide/reveal or rearrange the order would be a pointless exercise in futility. If the user wanted to see more item details and info, she could click or tap on the card detail to go to the corresponding detail page.

Medium Screen and up, Table View:
Adding a menu to hide/reveal columns was no biggie, especially for larger screens that had the real estate. Also, a filtering mechanic wasn’t an issue either, since the card view had to be filterable as well. Because we had solved for the question, “WTH what happens on a small screen?” it was just a matter of WTH happens when the medium/large screen gets smaller, but not small screen size.

The biggest issue of course, was the fact that the table didn’t have a set number of columns.  At any point in time a user would be able to hide/reveal/reset columns and rearrange the order of columns to suite their browsing preference. Regretfully, there was no user data to help inform any user scenarios, so we winged it.

It came down to two relatively obvious options: 1) the entire table is scrollable left-to-right (once the screen was reduced for overflow to kick in), advancing one column at a time, or 2) the left-most column would be “locked” and the remaining columns would scroll horizontally.  We went with option 2.

I really like Option 2 because it’s a brilliant solve for a table that has rearrangeable columns. Users can decide what information is most-to-least important that needs to be visible. As the screen sizes reduces, the most important information will remain visible, and secondary information accessible via horizontal scrolling.

We also decided to implement the ability to export the whole kit-and-kaboodle to Excel, just in case a user had hundreds of entries.

Fun with Excel.

UX Mag: Modals on Mobile: How to use them wisely

Chris Wigley of UXMagazine gives succinct review of the current use of modal windows use in small screen design. He rightly reminds of us of when and how modals should be used. If the content was planned for, then make it right, instead of a modal hack job.

Modals are becoming the dumping ground for content that doesn’t fit anywhere else, often because of issues with content planning. Modal windows should be applied only to meet the following objectives:

  1. Interruption: force the user to make a decision or complete a task within an important workflow
  2. Feedback or Correction: Confirming decisions: “Confirm you are happy with your decision” moment.
  3. Deep Dive: Focusing on a single piece of content, such as an image, article or video.

Read the complete article here.

Modern web design is responsive (with a lower case r)

A great article by Nate Voss of VML about how we need to start thinking about modern web design. Nate makes a fantastic point that as users of the modern web we have come to expect web experiences to just work, no matter the device or platform.
This expectation of connectivity and accessibility anytime and anywhere leads to the necessity that modern web design needs to be responsive (lower case “r” is intentional). “Responsive” (with a capital “R”)  is a viable technique among many, such as Adaptive, Progressive Enhancement, RESS–aspects of which enable us to achieve the best, most accessible experience for the end user.

Read on at:

User Experience Mobile Immersion Conference 2015 – Recap

I recently attended the 3-day UX Mobile Immersion Conference (UXIM15) in Salt Lake City, Utah, hosted by UIE (User Interface Engineering). If you’ve ever had the opportunity to attend any previous UXIM Conferences, then you know how highly rated the conference is for the quality of the speakers and topics they cover. Each speaker is literally household name in the UX/UI realm and their workshops and talks are of the highest caliber.

Never been to the UXIM Conference? I’ve missed a few years, and it’s a bummer to feel left out.  Hopefully the recap below can give you a glimpse of wisdom and smarts from this year.

Kill your assumptions
Throw away all your working assumptions about input types, devices, screen sizes and user tasks because the lines are becoming more and more blurred. Technology, once iterating every 10 years is on course to iterate every 2-3. Instead of trying to keep up (and losing your mind in the process) in an industry of unpredictability, a more strategic, sane course of action is to approach web design with simplicity, accessibility and performance in mind by using tested, reusable components and patterns.

Input does not equal device does not equal input
We may no longer assume that a certain screen size, input type, or hardware equates to a particular experience. “Desktop” no longer equals a keyboard and mouse any more than a “Tablet” does touch. Moreover, how will web pages change with voice or gesture controls that sync with your devices? Input is not detectable in a reliable way – it is transitory and dynamic.

Device does not equal task does not equal device
“Mobile users will do anything and everything desktop users do, provided it’s presented in a usable way.” — Brad Frost (@brad_frost)

Assuming that a user will or won’t do something on a particular device, specifically a small screen, will get you into serious crap. It wasn’t too long ago we believed users wanted less content or only specific content on their mobile phones because mobile meant the user was on the go. We know now mobile users kill time on their devices while standing in a line or on the couch in front of the TV. Take note: 30% of global ecommerce sales come from mobile.

Device classes aren’t definitive anymore
“These days, trying to draw a line around device classes (mobile, tablet, desktop) is as fleeting as drawing a line in the sand.” — Jason Grigsby (@grigs)

Defining device classes these days is like trying to definitively classify a Labradoodle as either a Labrador or a Poodle. Desktop to tablet to mobile dimensions now either overlap or are separated by just a few pixels. Besides, what class does a watch fall into, or a refrigerator? The windshield of your car?  It’s best to think about devices by size (XS, S, M, L, XL) instead of by class.

Performance is a Design Requirement
“Being Responsive from a layout perspective should not preclude us from being responsive from a performance and interaction perspective.” –Scott Jehl

Performance may appear to be “invisible,” but it can have a direct correlation to whether or not your user decides experience your site. Performance needs to be an essential design principle, not just a technical responsibility. Good performance is good design.

Some sobering thoughts:

  • 1.97mb – that’s the average page size of today’s web.
  • 74% of mobile visitors will abandon a site if it takes longer than 5 seconds to load.
  • 85% of mobile users expect mobile sites to load as fast if not faster than desktop sites.
  • The top e-commerce sites are 22% slower than last year; user data confirms that slow sites result in lost revenue. A slow loading site is one of the primary reasons for site abandonment.

Don’t add the unnecessary in the first place.
If the quickest way between A and B is a straight line, Stephen Hay succinctly states that a lot of experiences out there have (consciously) put a lot of crap between A and B, making for some ridiculously complicated experiences.

The Zero Interface Approach
To help achieve the universal of goal of getting from A to B as quickly as possible, Stephan Hay uses “The Zero Interface” approach: UX/design starts with zero-base. You begin with nothing, what you need is added, stress tested, and refined. Concurrently, you ignore client/designer/developer baggage such as competitor patterns, sunk costs, design trends, pattern libraries because baggage focuses on existing solutions.

The goal of Zero Interface is to focus on solving the problem, versus applying existing solutions blindly without understanding the root of the issue. It forces you, at every step (UX, Design, Dev) to examine each component you add and implement to ensure that it is part of the solution, not adding complication. Train yourself to think, with each addition, is this one thing to many?

Responsive Web Design and Progressive Enhancement
“We in the web world Rube Goldberg everything.”  – Stephan Hay (@stephen_hay)

Responsive web design isn’t just about making web pages fluid and displayable across multiple screen sizes; not “one size fits all.”  Modern web design is about ensuring that design and technology aren’t keeping users from accessing the content they want or need. This means considering and solving for a vast array of scenarios, like devices that may just be a few months or a few years old, disabled script, unsupported touch, older browser compatibility, while simultaneously creating experiences for current technology and devices yet to exist.

Keep in mind: 68% Americans access the web from a mobile device, and ⅓ of mobile web capable Americans access the web solely through a mobile phone. This means if a user can’t access your content, your information, your products or services on mobile, then you don’t exist for those users.

“We have a moral obligation to make sure content and information is accessible across devices and inputs.” — Jason Grigsby (@grigs)

To achieve broader accessibility web design experts Jason Grigsby, Brad Frost, Stephen Hay (to name a few) recommend Progressive Enhancement: begin designing for the most baseline experience–a small screen, slow data plan, no touch capabilities. Once the baseline experience is determined, layer on enhancements such as visual aesthetics, interactivity, gestures–stuff more modern browsers, technologies, and devices will detect and render. The “fallbacks” created by the baseline considerations have two advantages: 1) content and information is accessible 2) the site potentially won’t fall apart with when the next greatest thing comes along. With proper planning and implementation, the site will be useful and usable in an industry of unpredictability, diversity, and disruption.

Atomic Design
Along the lines of RWD, Brad Frost uses an approach coined, “Atomic Design.” Atomic Design is a set of 5 principle stages that more or less occur concurrently: atoms, molecules, organisms, templates, pages. The goal of an Atomic Design approach is to bring together individual elements (atoms) to form a component (molecule) that when combined with other components creates a larger organism. These organisms, or patterns, are placed into content frameworks (templates) to test the pattern across multiple scenarios. As more and more patterns are added to the template, the page takes shape.

The benefit to Atomic Design is that it allows the team to focus on individual design patterns instead of trying to solve for a page of patterns all at once. The content framework infers where solutions will eventually be implemented (placeholders) with finished patterns introduced as they are designed and tested.

Key to the success of this approach is to get into the final environment (the web) as soon as possible; to stop thinking of websites as set of individual pages, but as a system of components combined together. With the near limitless number of devices, breakpoints, resolutions and technology, it is nearly impossible to create a mockup for every breakpoint in photoshop (not to mention, what happens when there’s an edit that needs to made across all the pages). Additionally, the static page is not an accurate representation of the final experience, which is why it is crucial to move out of static comps to code once the design aesthetic has more or less been established.

Is Design Metrically Opposed?
“Bounce rate is the most cited metric for pushing a content agenda.” — Jared M. Spool (@jmspool)

Measure: Something we count
Metric: A measure we track
Analytic: A measure software tracks
Missing: Are these useful?

All too often metrics and analytics result in inferences that are then translated into solutions without further examination. Google Analytics can’t tell you why;  what content is the most useful? What you should do to improve content?  Why people are spending money? Why did someone click?

Qualitative finds should drive our quantitative research; quantitative research should be focused on user frustration. By simultaneously overlapping a journey map of observed user frustration (and delight) of corresponding metrics, we are more likely to pinpoint and solve for the actual cause of user frustration, as opposed to a design decision based in inference. In short, user experience needs to own behavioral science.

See you at UXIM16!

The retailer customer challenge: mdot, responsive or dynamic serving?

According to a recent post by Pure Oxygen Labs, 2014 saw retailers shifting away from Mdots to Responsive and Dynamic Serving. Here’s a look at the numbers:

  • 59% used dedicated mdot sites – down (significantly) from 2013
  • 15% used dynamic serving – up slightly from 2013
  • 9% used responsive design – up (significantly) from 2013
  • 14% had no mobile web presence at the time (OMG)

Pure Oxygen Labs points out that while mdot usage is sliding, the biggest obstacle and conundrum for retailers adopting responsive design is page speed and it’s potential effect on conversion. Despite this “Achilles’ Heel”, POL expects responsive to surpass 15% retail adoption in 2015.

Read on for Pure Oxygen Labs interpretations, predictions and technical insights.

Image use, design patterns and style guides

A great podcast on current trends and challenges when it comes to responsive design, courtesy of Jason Grigsby (Cloud Four) and Jared Spool (UIE).

The lines between designers and developers continues to blur, and what is old is new again in terms of challenges of designing for the web. As responsive design moves forward, coming to terms with image use, design patterns and components instead full page comps, and maintaining style guides are the new challenges and headaches we get to tackle.