Category: Tips and Tricks

Responsive tables using CSS

As the world of web design has embraced CSS (and, indeed, become more aware of Accessibility) designers have become, in many ways, rather scornful about the humble HTML table—especially as responsive tables are so tricky.

As with every HTML element, there are good, semantic reasons to use tables in certain circumstances. Or, rather, in one circumstance—when you are displaying tabular data.

So far, so good.

The non-responsive solution

However, in our multi-device world, tables do provide some challenges—particularly on small screens. The simplest way to address the issue is, as Twitter Bootstrap does, simply to surround the table with a div that has overflow-x:auto; applied on small screens.

This has always struck me as being rather inelegant: it is a hack, a work-around to enable people to see tables as they would be displayed on the desktop, rather than a truly responsive solution.

So, I thought that I’d share two different solutions that I have used (and continue to use) for responsive tables. I don’t claim to have invented either of them—I have seen similar solutions elsewhere—but I thought that my particular twists might help others.

Hiding columns with the Checkbox Hack

In my day job, we often have to generate pages that display quite large tables—such as a tenant’s rent statement. These will have, say, seven or eight columns, e.g. date of payment, several individual charges, the total charge, and the remaining balance.

The first thing that I did was to talk to the customer, and get them to survey their tenants to find out which were the most important pieces of data. Armed with this information, I used @media queries to hide all but the most important columns on small screens. Thus, when accessing their account through a mobile, the tenant was presented with the date of payment, the total payment, and the remaining balance—the three of which fitted easily without horizontal scrolling.

Crucially, however, if they wished to see other columns, then they could switch columns on and off as desired. And all of this was achieved using only the CSS Checkbox Hack, as demonstrated in the Pen below (this example is not responsive, but you can use the label buttons to switch columns on and off).

See the Pen Table sizing and checkbox toggling by Chris Mounsey (@devilskitchen) on CodePen.

This is a nicer solution than the scrolling div, since it does allow the user to focus on the important information—and, in this type of case, it may even be the best solution.

What do you do when you cannot separate the columns of primary importance? And how do you craft a truly responsive table?

Pivoting the table using data-attributes

The neatest solution that I have adopted is one in which we use data-attributes to replicate our headings, and then simply pivot the table.

In order to achieve this sort of responsive table, we first add the column title to the relevant cells (this does imply a slightly larger HTML foot-print, but you are GZipping your website, right?). So:

Now, we use @media queries to apply the following CSS for small screens (obviously, I use LESS, but I’m showing the CSS for those of you who aren’t familiar with pre-processors).

After that, all you need to do is to use standard CSS to make things look prettier. The Pen below shows one of my more recent efforts: resize the window to see the responsive table pivot (there is a desktop, a tablet and a mobile state).

See the Pen Responsive Table by Chris Mounsey (@devilskitchen) on CodePen.

Conclusion

I think that both of the responsive table examples above work better any others that I have so far used. As outlined, which one of these I use in production rather depends on the purpose of the table.

However, I hope that this quick post gives you some ideas about designing truly responsive tables.

Flexbox

Two years ago, I tried to implement our web software interface using flexbox. Unfortunately, I was a little too eager in this endeavour, and had to hastily reinforce my fallbacks as the specification changed.

The Flexible Box Layout Model—commonly known as flexbox—has the potential to solve a number of perennial problems that front-end devs have been banging their heads against ever since CSS was invented in 1996, including equal height columns, true proportional width flexibility, and DOM ordering over-rides (very useful for Accessibility).

A number of these practical problems—and how flexbox solves them—are illustrated on Philip Walton’s Solved by Flexbox GitHub page.

However, as I discovered back in 2011, flexbox has had rather a chequered history—passing through three distinct specifications. Detailed support is outlined at caniuse.com, but, roughly, browser support is:

  • flexbox-legacy: supported by Safari 5–6 and Chrome 4–20;
  • flexbox-intermediate: Internet Explorer 10;
  • flexbox: Chrome 21+, Safari 6.1+ (allegedly), Firefox 21+ (sort of: there’s no support for flex-wrap and flex-flow).

To make things more complicated, Modernizr only has feature-detection for the oldest and newest syntax, which are output as flexbox-legacy and flexbox respectively.

And finally, once you delve into all of the possible variables, the syntax is not at all simple.

Luckily for us, a number of very smart people have been keeping up to date with all of the progress and built some useful web tools to generate code for us.

  • Flexyboxes provides a neat WYSIWYG interface for building flexible layouts, and it will generate code for all three syntaxes if you need to. Do be careful, however, as the older versions are not as capable as the up-to-date flexbox.
  • You can only use Flexplorer if your browser supports the latest syntax (which Safari 6.0.2 does not!), but it does also give a useful rundown of browser support for vendor prefix requirements.

With everything settling down—and a UI refresh of our software on the cards—I have been considering writing a set of LESS mixins for deploying flexbox in the wild. Inevitably, of course, putting “flexbox less mixins” swiftly shows that yet more smart people have got there first.

With so many to choose from, David de Coninck’s version jumped out at me most immediately—his use of guard expressions is really elegant.


See the Pen Flexbox 2013 LESS mixins by David De Coninck (@davidgenetic) on CodePen

Do you have a favourite LESS mixin that supports all of the syntaxes out of the box? Let me know in the comments…

 

Reciprocity: give to get

Living in the world that we do—with its smartphones, transatlantic travel, ultra-high-def TVs and One Direction—it’s sometimes easy to forget that we are, at the most basic level, animals.

We have, over the course of human evolution (modern humans it’s generally agreed upon have been around for at least 200,000 years), carried with us various traits that helped our long gone ancestors to navigate and survive on this planet we call “home”.

In the modern world of communications these traits may seem of no real concern to us but the truth of the matter is that we still act and make decisions based on them.

The use of reciprocity, for example, can be a powerful tool to help create a reaction and a connection with your clients and customers. It can help build a deeper relationship, creating trust and loyalty.

At the most basic level, reciprocity is the exchange of something of value between two or more people. This doesn’t have to be as obvious as giving a present or receiving a birthday card: assistance, advice and contacts can equally be a form of reciprocity.

By and large we try to repay in kind what another person has given us; if we don’t, we usually have an overwhelming feeling of guilt—and there aren’t many people who enjoy that feeling. I know I don’t.

There are many theories as to where reciprocity comes from and why it’s a major influence over our lives and decision making. It has been theorised that it relies on a universally held belief of future obligation: if we give something of value away it won’t be lost forever but will be repaid to us in the future with something of equally valuable (or even more so). Humans for the most part will almost always strive to repay this “debt” even when the expectation of repayment is a vague one.

We can see reciprocity happening all the time in the online arena—take LinkedIn, for example. When we receive endorsements or recommendations from our clients or associates, most of us will respond in kind without being asked—we somehow feel compelled to do so.

When someone comments on one of our photos on Facebook, we will often comment back on one of theirs. Even if we don’t feel obligated, we would rather do this than not as it’s fundamental to our social success.

We can make use of this ancestral practice in a variety of ways.

  • Write free articles—not only will you be giving your readers knowledge for free but you’ll also be enhancing your position and credibility as an expert in the field in which you operate. The same can be said for coding. There are many developers who use reciprocity by giving away bits of code they have created: those who download the code feel obliged to either spread the word about the developer’s site, leave comments of thanks (usually praising the developer’s skills) or offering solutions or “bug fixes” for free.
  • Offer a free consultation—by giving away a bit of your knowledge and helping your potential clients/customers just a little it will instil the feeling that you’ve gone out of your way to help. It will enhance your reputation and increase the prospect of a more meaningful and prosperous relationship.
  • Compromise—by showing that you have the ability to compromise, your client will more than likely wish to reciprocate in kind, leading to a mutually beneficial outcome. This doesn’t mean that you have to become weak and go against your fundamental principles. Be strong, but always make room for compromise too.

It seems that even though we are moving full steam ahead into the future, there are certain traits that are ingrained in the collective human psyche. Don’t forget to use those traits—they’re effective, they work and they have done for at least the past 200,000 years.

Applications that I use

Having mentioned Sketch in my previous post, I thought that I would expand on the applications that I use in my workflows. And to start with, I need to expand on what those workflows actually are.

Which is tricky—because I do quite a number of varied jobs.

First, I do a considerable amount of management, both in my team and in the wider business. This is why my job title is the, slightly unwieldy, Creative and User Experience Manager (usually shortened to CrUX Manager).

Essentially, I lead the team that designs and builds our customers’ websites and intranets on our company’s content management platform (CMS). However, I also design the user interface (UI) and user experience (UX) for the CMS—plus I also design a lot of the new functionality too.

Occasionally, I give talks at events—both internal and external—about the web, CSS, Accessibility, and other related issues.

Because I know a lot about the web, our product and our customers, I have also spent a lot of time in customer pitches, Information Architecture (IA) workshops, and in discovery meetings for new software. In other words, I am heavily involved in a customer’s entire journeys with our company—and, in many cases, for determining the steps along that journey.

And, since I run the CrUX team, I am also responsible for recruitment to that team and, with the operations team, for managing resources on a day-to-day basis. And, of course, when we have a new starter, I am responsible for sorting out software and hardware—which means that I know how much we invest in our applications!

Which brings us back to where we began—the applications that I use to achieve all of this.

Graphic Design

For the moment, I find myself continually coming back to Photoshop—like a dog to its sick. I don’t really like Photoshop for design (and I loathe Illustrator) but it is familiar and thus relatively easy to dip into.

However, I am gradually weaning myself off Adobe’s products in favour of smaller, cheaper applications that are, in many ways, better for the job than Adobe’s bloated behemoth’s.

I have been playing about with Sketch (about £30) a lot, and I think it’s a wonderful application. It is very capable and, with every update (usually monthly), it becomes more capable and more stable. I am aiming to make it my primary design tool.

For non-vector based work, I have been getting into using Pixelmator (about £20) which is also an excellent (and cheap) photo-editing and design application.

Browsers

My browser of preference is Safari. Its Web Inspector tools are almost as capable as Chrome’s, and I find the browser faster and more reliable than Google’s offering.

However, I do test in all major browsers—including Internet Explorer 7, 8, 9 and 10. To achieve this on my Mac, I use VirtualBox (free) and the wonderful IEVMS script to automate the conversion of Microsoft’s supplied disk images to a format that VirtualBox can read.

Coding

A few years ago, I found myself, with a colleague, in a café with free Wi-Fi; up until that point, I had used Dreamweaver to code my work. However, my laptop was not equipped with my meatier applications and so—needing to do some coding and having read a good review of it—I downloaded Panic’s Coda.

And I have never seriously used another coding environment since (although I have also dabbled with MacRabbit’s Espresso—before they merged it with CSS Edit). I certainly never launched Dreamweaver ever again.

Coda was, essentially, my first foray into the sunlit uplands of indie Mac Developers. Up until that time, I had basically used Adobe applications and little else; for someone with this experience, the speed with which Coda launched and operated, as well as its feeling of lightness, were a revelation.

That independent developers are challenging Adobe in its core areas of photo-editing and vector design (this latter being an area that Adobe basically stole when it killed my beloved Freehand) is one of the very best things about the Mac platform right now.

I write in LESS and use the excellent CodeKit to process it, as well as for compressing images, and other useful things. Be sure to read CodeKit’s amusing release notes, by the way…

Finally, I started using CodePen a lot for experiments, reduced test cases, reference files, etc. I particularly like the fact that it compiles LESS on the fly. I haven’t had much time to continue playing with it recently, but that should change in the next few days.

Software Design

My role in this area is, essentially, to gather customer needs, to productise them, and write requirements specifications.

For this I use Apple’s Pages (£14) for the text and, for the workflows, Celestial Teapot’s very nice little diagramming application called, simply, Shapes (roughly £3!).

This latter app is—like most Mac indie apps—under active development and Celestial Teapot seem very good at taking feedback and incorporating it into releases.

Administration

For most other administrative tasks, I use Pages, Numbers and—for presentations and speaking engagements—Keynote.

When presenting, I use Apple’s Keynote Remote—running on my iPhone—to control the slides and display presenter notes (where necessary). In the absence of Wi-Fi (a rare thing these days) I carry a standard, hardware Apple Remote.

Miscellaneous

I do dabble with a few other apps, and I like to try out new applications quite often.

Wireframes

Where necessary, I use MockingBird for building up wireframes; it is simple, elegant and easy-to-use. The lack of development on it over the last couple of years has been disappointing, but it is still an excellent online application.

Animation

One app which has a great deal of potential is Tumult’s Hype. Using this application, you can build up complex animations using a timeline model, and Hype will then generate a file containing CSS3 animations (including complex matrices): even better, it will also generate the Javascript required to cater for older browsers.

Combine this with Modernizr and the built-in YepNopeJS, and you have a modern, compliant solution for creating complex animations.

Project Planning

Since I have taken over my current job role I don’t use OmniPlan as much, but I still find it useful for internal scheduling: it’s a fully-fledged project management application, with proper concepts of utilisation and efficiency.

Font Management

For font management, I still use the free version of Linotype FontExplorer X (which, whilst difficult to find now, has lasted me for years and years!), but I am starting to switch over to Bohemian Coding’s Font Case.

For web fonts, I use TypeKit (although, since Adobe has taken over, I am finding some issues with reliability. What a surprise) and, occasionally, Google Web Fonts.

And that’s about it. There are one or two applications that I play with, but the major ones are those listed above.

Do you have any favourite applications? Feel free to leave your preferences in the comments…

How browsers build pages

There are any number of guidelines and theories about how best to write sustainable CSS, and smacss (pronounced “smacks” apparently) is another of those. I was reading through the introductory chapters, and was interested to learn how browsers build pages.

The browser starts at the top and sees a body element. At this point, it thinks it is empty. It hasn’t evaluated anything else. The browser will determine what the computed styles are and apply them to the element. What is the font, the color, the line height? After it figures this out, it paints it to the screen.

Next, it sees a div element with an ID of content. Again, at this point, it thinks it is empty. It hasn’t evaluated anything else. The browser figures out the styles and then the div gets painted. The browser will determine if it needs to repaint the body—did the element get wider or taller? (I suspect there are other considerations but width and height changes are the most common effects child elements have on their parents.)

This process continues on until it reaches the end of the document.

This seems, to me, to be a very inefficient way of building a page since multiple “repaints” are necessary, but it is easy to forget just how fast and efficient modern browsers have become.

Below, you can view a vastly slowed down video of a Mozilla browser rendering a page using this method.

Pretty impressive, I think. But it still seems conceptually inefficient…

Using local colour variables in Less

One of the most time-consuming aspects of website design is when the customer wants multi-coloured menus—and for those colours to cascade through the other attributes on those site areas. This can involve lots of different selectors, and having to change them all to different colours can be a pain—and this is where using local colour variables in Less can save lots of time.

Standard colour variables

Consider the following set of declarations:

Now, imagine that these all had to be altered depending on the .site-area-x, and that we have huge number of selectors to restyle.

Obviously, we could simply declare our @color2, but then we have to go through and change the colour in all of the other declarations too.

And this needs to be done for each one of the eight different menu areas—it’s going to be pretty time-consuming.

Local colour variables to the rescue

There is a better way in which to do this—by using local colour variables. Consider the following set of declarations:

We now only have to change two attributes—the .site-area-x class, and the @site-area-colour.

OK, it’s not entirely automated, but it will take considerably less time than the first method.