In my career as a web developer, I’ve helped build many web applications that require the display of tabular data in a clean and simple fashion. Over time, I’ve developed a few techniques for doing so that are effective and easy to implement.
But before I go into that, let me quickly remind my fellow web developers that tables are not, in fact, the enemy. Although the days of using tables for layout are long past, tables are still a perfectly appropriate method for displaying tabular data on the web.
However, I must also acknowledge that there are some disadvantages to working with tables to be aware of, including:
Tables don’t always scale down well and may display poorly when space is limited, like on mobile devices. If your primary audience is viewing your web site on mobile devices, it may be better to use lists or other markup that’s better suited for vertical display.
Tables are not as adaptable as other elements, especially in older versions of Internet Explorer, and that can limit your options when developing a responsive web site.
Display tends to vary slightly across different browsers. This is particularly true with column widths. I’ve encountered many situations where the text in one column wraps to two lines while there is clearly ample space to accommodate for it in another cell. There are ways to get around that of course, but the solution is generally specific to the situation.
So after much preamble, here are four simple examples that I’ve created to demonstrate different ways you can work with tables to display data cleanly:
Talking about site speed today almost seems superfluous, with so many users accessing the web with powerful Internet connections and download capabilities. Most desktop users access the web via cable or fiber optic lines, brandishing download capacities of 15 megabits per second (Mbps) or greater. Although many users will often access those same Internet services via wireless signal, the rapid spread of 4G networks has brought similar download speeds to mobile devices even when they aren’t connected to WiFi.
Despite all that, there are still some desktop users that access the web using DSL or dial-up connections and many mobile users that are restricted to less powerful networks.
But, regardless of all the latest technologies, there will always be some subset of users that hit your web site with poor Internet connections. In addition, many mobile users are limited to how much they can download over their provider’s data network. Personally, I’m limited to 2 gigabytes of data usage per month, excluding any data transferred over WiFi.
That means that when we build and maintain web sites, we need to be cognizant of users’ technology capabilities, as well as their limitations, and plan accordingly.
Understanding Your Users
The first step towards building an optimized web site is simply getting to know your users. Getting a basic idea of user demographics such as age, income, and location will allow you to make some general assessments about how they are accessing your site.
I recommend utilizing Google Analytics to help verify (or nullify) any assessments that you have made about your users. There are several “Audience” reports that will help you gain some insight.
Demographics > Location – Shows where your users are located geographically.
Technology > Browser – Shows what browsers your users are accessing the site with. I like to check this prior to development to help determine what browsers need to be supported for the site.
Technology > Network – Shows what Internet networks are being used to access your web site. This may give you some idea about your users’ download capabilities.
Mobile > Overview – Shows a basic breakdown of your total desktop, mobile, and tablet users.
Google Analytics doesn’t collect enough information to paint a detailed picture, but these reports, combined with your own experiences, should give you a pretty good idea of what to expect.
Once you understand your users, you can then determine which optimization practices are necessary for your site.
Here are some easy techniques that I recommend for all sites, regardless of user technology.
Combine CSS files to reduce HTTP requests. Previously, I would keep my screen, mobile, and print styles in separate files, but I have begun combining them into a single file to reduce the number of requests the browser has to process.
Create image sprites. Likewise, you can reduce requests by creating a single image with all of your design files. High traffic web sites like Amazon.com use this technique frequently, but I find it to be a bit cumbersome and avoid it unless I feel it’s necessary.
Scale down and optimize images for the web. I recently noticed a client site was loading slowly and discovered that three of the photos on the home page totaled over 12 mb. By simply scaling those images down to dimensions that fit their container, I was able to reduce the page weight to well under 1 mb.
Optimize PNGs. Photoshop is notorious for creating bloated PNGs. There are many services that you can use to reduce the bloat and overall file size. I like TinyPNG.
If you are using jQuery or another popular code library, consider referencing Google’s hosted copy. Since many other sites do the same, users may already have the file cached in their browsers, which will save loading time.
Most of these steps are simple and can easily be implemented on any web site without impacting quality or deadlines. Doing these things will reduce page weight, decrease loading time, and ultimately improve user experience.
There are many other things that you can do to help reduce page weight and decrease load time, but you’ll need to decide what techniques are right for you and your site. In many cases, the basics may be fine, but in others, every kilobyte may be important.
To learn more about page weight optimization, I recommend reviewing the Network and Audits features within Google Chrome’s Developer Tools. I also really like the Pingdom Tools website speed test. Both of these will break down how long it takes each resource to load and provide suggestions for optimizing your site.
A few months ago I had the pleasure of writing a piece for .net Magazine about print styles (Make your website printable with CSS). It was posted to .net’s web site last month and received an overwhelming one comment. That comment, however, summed up something I hear all the time:
Would be interesting to see some statistics on how many people actually print websites.
For years I have argued that the best user statistics are those for the site you are building. In the absence of global numbers for how many users print web pages, in this post I’m going to show you how you can measure how many (and which) pages get printed from your site by using Google Analytics. I am also hoping those who know everything about Analytics can answer some of my questions.
I want to be able to call the Google Analytics tracking image (__utm.gif) only when the page is going to be printed, skipping unnecessary HTTP calls and the resulting image download (brief though it is). I rely on the CSS @media print declaration to call the image. I also don’t want to write that image call to the page with yet more client-side script when I can assemble it all right on the server.
I still haven’t figured out what the number 5 maps to, but it works. I also found that I need an asterisk as a separator, though I found no documentation explaining it. In the end, the only way a print event tracked as I wanted was when I constructed it as: 5(Print*/Accessibility). In this example, /Accessibility is the address of the page I am tracking.
The other tricky bit is pulling the cookie value and stuffing it into the string. Conveniently I can get to this within our content management system (QuantumCMS, which you should use) on the server side. Many others (if not most or all) have a similar ability. At the very least you have to include the __utma and __utmz values, passed as encoded parameters for utmcc. Without these, my tracking would not fire.
The Completed Query String
For ease of reading, I will break the string to a new line at each &. This represents what is generated when I visit the careers page on the Algonquin Studios site using Opera.
Now that you have the query string and the Google Analytics tracking image, you just need to call the image when the page is printed. All you need to do is embed a style block at the top of your page with the print media query, and call the image within it:
If you read my post on embedding QR codes, then this code will be familiar — I use header::before in that example. As such, I use header::after here so you can use them both keyed off the same element (header) without conflict.
If you look closely, you may have noticed that my event parameter looks like 5%28Print*/Engage/Careers%29 instead of 5(Print*/Accessibility). I URL encoded the parentheses on the entire string to make certain that they do not conflict with the parentheses in the CSS. If you don’t do that, the browser will get confused and fail to load the image.
Once you have the CSS in place, I recommend going into HTTP Fox or the Chrome Developer Tools to make sure the image is called when you fire a print preview (save paper!), and then to make sure it has the parameters you expect — particularly the utme value:
Checking Your Google Analytics Report
Assuming you’ve verified all is working well, you just need to run a report for events in Google Analytics. Bear in mind that Analytics isn’t up-to-the-minute, so you may need to give it some time to capture all the data.
Log into your Analytics account and make sure you set the report date to the time period where you rolled out these changes. Choose “Content” from the “Standard Reports” on the left side. From there, expand “Events” and then select “Top Events.” You should see “Print” as one of the items in the “Event Category” column (you may need to show more rows).
Click on the word “Print” in that grid and you will see all the pages that were tracked (ostensibly because you or a user printed the page).
From here you can run a secondary dimension to cross-reference this with more information. In my example, I tested different pages in different browsers so I could quickly verify the cross-browser support. You can run screen resolution, landing page, or any other dimension that you think might be handy to compare.
I am just adding this to my own site, so I don’t have any numbers to offer as part of this post. However, if you implement this please feel free to let me (and everyone) know how many users you have who print and for what site. I don’t expect the numbers to be high, but I do expect to see it happen here and there.
If you have any additions, corrections or suggestions, please let me know. I am still unclear how all the Google Analytics query string parameters come together and exactly what they all mean, so there may be some optimizations I can work into it.
A combination of people who are far smarter, far more well connected, and in timezones that allow them to write about this sooner, along with all the Twitter chatter, has already hashed out the major details. As such, I will link to them below. I would be a terrible blogger if I didn’t offer my opinion, however.
Any developer who is complaining that this means there is another browser/engine against which they will need to test has been doing it wrong.
Web developers should always test against different browsers, regardless of their engine. In particular, WebKit has so many nuanced implementations that not independently testing against each browser that uses WebKit belies either a lack of understanding of how WebKit is implemented or laziness.
If you aren’t sure what is different between each WebKit implementation (Chrome, Safari, Android browser, Opera, etc.), I encourage you to read my post “WebKit Will and Won’t Be the New IE,” where I provide a high-level overview of these variances.
At this point it doesn’t mean a whole lot.
Google will argue this is better for users. Apple will argue that Google took its ball and left. Opera won’t be arguing. None of that impacts users because we have mostly done a good job of promoting standards-based development. I again refer you to “WebKit Will and Won’t Be the New IE” for how poor testing can impact users, but that’s not a function of the engines.
That’s just speculation on my part.
For a specification to become a W3C recommendation, there must be two 100% complete and fully interoperable implementations, which basically means two browsers need to support it. When Opera announced the shuttering of Presto, that left Trident (Internet Explorer), Gecko (Mozilla), and WebKit (Safari and Chrome) as the remaining engines (of measurable size). Essentially, two out of the three of them had to agree to implement a feature.
With Blink, provided the W3C recognizes it as a stand-alone engine, there is now one more engine back in the mix, essentially returning the count to where it was in February before Presto’s wind-down (to be fair to Presto, it’s expected to exist in the wild until 2020, but with no new feature development).
I am hoping that this is a good thing for standards.
Blink won’t be using vendor prefixes (even though it will have inherited some), so I consider that a step in the right direction. While I think this matters to developers, I think it matters even more to standards.
From Peter-Paul Koch:
Chrome 28 will be the first stable release to use Blink; earlier versions will use WebKit. Opera and Yandex will start using Blink whenever they start using Chromium 28.
First some bits from The Twitters:
Let’s bring back the Netscape engine and call it Spacer! RT @codepo8: After blink Microsoft might bring out a new engine called marquee
For those of us who put together print styles for our sites, we’ve probably tossed around the idea of embedding QR codes so that users can quickly get back to a page they have printed. In the hardcopy version of my article for .net Magazine, “Make your website printable with CSS,” I show how you can embed QR codes in your page (it’s not included in the online version).
In my example I use the Google Charts API to generate the QR code on the fly. The problem in my example is that the QR code image gets called whether or not you print the page. Not only is this an additional HTTP request, it’s also an additional download that immediately gets hidden. This puts a bandwidth burden on users who aren’t printing, but it’s also the only way to support your users on Internet Explorer 8 and below (who may be the ones trapped at the office who want to bring the document home).
If you truly have no IE8 or below users, then the less bandwidth-hoggy approach is rather simple, if a bit inelegant.
Since each call to the Google Charts API to get the QR code must include the full address of the page, I cannot leave this to my linked CSS file (which is static, not run through any server-side processing), nor would I want to push every URL for every page of my site into that file. Initially I wanted to use a data- attribute to hold the URL and then, using the generated content feature of CSS, have it take that value and feed it into the content: CSS declaration to have it generate the image from there. Except that’s not how CSS works. You cannot use CSS to generate an image from a CSS variable.
The easiest solution is to a put a style block at the top of your page (something I hate doing) and feed the current page’s URL into the Google Chart API query string to dynamically draw the image. The rest of the styles that affect placement, spacing, etc. should all be in your print stylesheet already. The example:
That’s it. Now when (and only when) you call the print styles, the image will load. As proof, here is a screen shot using HTTPFox showing the page before the print styles were called and after, where you can clearly see the QR code is called only when the print styles are fired.
Note: This technique will not work in any version of Internet Explorer that doesn’t support CSS generated content, which includes IE 8 and below. Internet Explorer 9 and above happily include the QR code generated with this method.
Bruce Lawson tweeted out a seemingly random musing today that I have pondered myself — what if, while on a mobile device and surfing a RWD web site, I want the desktop version of a site?
There are many reasons as a user that this might be the case, ranging from poor development practices that hide chunks of content you need to see to just wanting to know what it looks like.
Clearly it’s enough of a use case that mobile browsers such as Opera Mobile, Chrome, Firefox, and so on, have a feature to request the “desktop” version of a site from a menu built into the browser.
Except that feature doesn’t work with a RWD-powered site because media queries, typically based on viewport width, are used to deliver styles for traditional desktop window sizes. The browser feature only sends a different user agent string (bypassing terrible user agent sniffing) but doesn’t do much else. Your 320-pixel-wide device is still 320 pixels wide, and the media queries know it.
Until the mobile browser makers report a false viewport (or, rather, assume one when choosing CSS from a set of media queries), we’re kind of stuck. While I have many ideas on how that might work, that won’t address the issue today.
While I had bandied about an idea to address this on the redesign of my site a couple years ago, it took a client request last year to get my team the time to finally code a solution.
There are some core steps the hammer out in the logic of any solution:
Put a link on the page to view the desktop layout. I prefer to have it in the raw HTML over writing it in with script.
In the more mobile-friendly CSS files allow this link to display. In the more desktop-friendly CSS files hide the link.
Either using a round-trip to the server or client-side script, remove the media query logic and serve up the “desktop” CSS.
Warning for Europeans: cookies. Set a cookie with that preference for the user. Whether it is for the current session, forever, or somewhere in between is worth an internal discussion.
Now display a link to view the “mobile” version of the site. Again, this can be done with or without script.
If the user clicks the link to see the mobile version, re-instate all your media queries, clear the cookie and pretend nothing happened.
This process is a bit oversimplified, but it covers the broad strokes.
There are some hurdles, of course. Your users might not understand what you mean by “desktop” or even “mobile.” You could make the link to get out of one of the views too hard to find. You could bump up against expectations set by the mobile browser feature to request the desktop site. If you serve mobile styles to IE6 users, you could confound them if you don’t clear the link from the page for them. And so on.
You can play around with what we implemented for our client at CHSBuffalo.org. View the source to see the styles and script. There is obviously logic on the server side, but you can make up your own for your own server platform.
These screen shots should give you an idea of what to expect when you visit the site:
When building, redesigning, or maintaining a web site or web application, it’s important to understand the technology visitors will use to access the site to create the best user experience possible.
So what do you need to consider? Although there can be many factors at play, here are the key questions you should answer:
What browsers are used to view the site?
What devices are used to access the site?
What screen resolutions are commonly used by site visitors?
Most of us web developers have a tendency to get pretty excited about using new coding techniques and technologies like CSS3 and HTML5, but it’s important for us to consider what browsers the site visitors will be using so we can determine whether those techniques are appropriate or not.
If you find that your user base primarily views the site in recent browsers, then you may have more flexibility with new technologies. However, if you find that a significant portion of users are accessing the site in older browsers, you’ll need to make sure that they can complete all functions without any major drawbacks.
That doesn’t mean that the site has to look identical in all browsers however. Many web developers commonly employ a technique called progressive enhancement. This coding technique allows for users in recent browsers to see the site design as intended (with enhanced design elements) without negatively impacting the experience of users in older browsers in a significant way. Enhancements might include design elements like rounded corners, gradients, or drop shadows.
There are many desktop browsers that support progressive enhancement techniques including Google Chrome, Firefox, Safari, Internet Explorer 9, and Opera. Internet Explorer 8 and lower usually do not get the benefits of such enhancements.
Most mobile browsers tend to have good support for progressive enhancement techniques as well, including the default Android browser, Safari, Google Chrome, Amazon Silk, Opera Mobile/Mini, and many others.
Understanding what devices your visitors are using will help you engage with them more effectively. There are many devices that allow people to hit the web in addition to computers, including tablets, phones, and gaming consoles. Most computer users access the web in a similar way, with a keyboard and mouse, but don’t forget that there are some users who rely on screen readers to recite the content of the page to them and who navigate by keyboard only.
Tablets and phones are “tap” devices, meaning that users interact with web sites using their fingers. For these devices, it’s typically helpful to create larger tap radii for links and to avoid displaying critical content on mouseover or via right-click.
Because there are many different ways to access a web site, it’s important to design and develop with accessibility in mind. You should always aim to make your site accessible for your target audience and their expected browsing devices, but not at the expense of impaired users.
With users accessing the web on phones, tablets, PCs, laptops, TVs, and a seemingly endless number of devices that come in all shapes and sizes, there is, likewise, a seemingly endless number of screen resolutions that you must consider while developing a site.
PCs and laptops tend to have resolutions equal to or greater than 1024 x 768 pixels, although you may still see a few users running at 800 x 600 pixels. 1024, though possibly the lowest desktop resolution that you’ll need to really consider, is still rather popular and has held a significant portion of the market share for many years. You should, in most cases, consider that to be your base and confirm that your site is usable at those dimensions.
Phones, tablets, and netbooks bear further consideration. If your user base includes a number of mobile users, you may be able to improve usability significantly by applying a different layout or styles optimized for smaller sized screens. CSS3, widely supported by recent mobile browsers, offers an elegant solution of applying different styles at different browser sizes and is often the preferred approach.
Bringing It All Together
Understanding how users experience your site or application will allow you to serve them better and, ultimately, improve overall customer satisfaction. The easiest way to gather data on browsers, devices, and screen resolutions is via Google Analytics, which offers reports for all three. I highly recommend that you review these reports to get a better understanding of your users, especially if you are considering a redesign for your current web site and to close it out, here are some nifty screen shots of those reports:
Testing accessibility on your web projects can be a tricky task if you have no firsthand experience with visual, audible, physical or even cognitive impairment. Having resources in the community is important as is tracking down the same tools in use in that community.
Despite all this it’s nice to have some quick techniques for testing your sites without the need to break from your regular workflow. Conveniently, there are a number of tools already out there. Here is a quick rundown…
WCAG 2.0 parsing error bookmarklet
From Steve Faulkner, this experimental bookmarklet uses string matching to evaluate a page against the WCAG 2.0 success criterion for section 4.1.1 Parsing. It leans on the W3C Nu Markup Validator to do its job.
Excuses for failing to use the W3C Nu Markup Validator fall away when all you have to do to validate a page is click on a bookmarklet. Also from Steve Faulkner, this collection of four bookmarklets allows you to validate the current page (in the current window or a new one) or provide the URL of a page to validate (in a new window or not).
Jim Thatcher has come up with a series of bookmarklets (or as he calls them, favelets) that allow him to make the human review process easier by highlighting details he might otherwise have to wade through code to see. Bookmarklets include image checkers, heading counters, data table notes, ARIA details, and form features.
This particular tool is not a collection of bookmarklets. It is also not built to work for any browser other than Internet Explorer. It does, however, provide far more features than bookmarklets can do on their own. Used in conjunction with a manual test and the bookmarklets listed above it can help our overall accessibility testing process far more than just the bookmarklets alone.
This toolbar is a Firefox add-on from Gez Lemon. Like the toolbar above, it provides a bit more control than a bookmarklet will afford. This will show you ARIA live regions, show you ARIA landmarks and roles, provides a table inspector and a color contrast analyzer.
Since I’ve strayed far afield of bookmarklets I thought I would toss this last one into the mix. NonVisual Desktop Access (NVDA) is a free, open-source screen reader for Windows. While it’s intended for the entire OS, it’s also great for testing web pages. Its support of different accents makes for much fun when it speaks to me as a Scotsman.
Download a copy of NVDA for yourself and make sure to donate when you do — this is how projects like this are able to continue and how you can support the disabled community.
I’ve been wondering – how many people out there would remember to check the batteries in their smoke detectors if it weren’t for daylight savings time?
Every six months, I spend a minute or two on a Saturday night trying to remember if I gain or lose an hour that weekend. Shortly after figuring out if I’m jumping ahead or falling back this time around, I inevitably hear my dad’s voice in the back of my head saying, “Every time you change the clocks, make sure you also remember to change your smoke detector batteries.” Day-to-day family life is pretty crazy for me these days, so I’m not 100% certain I would remember to change those batteries if my dad hadn’t hammered it into my head for years. And I’m glad I remember, because my family and my house are pretty important to me!
While I’m willing to bet most people would agree with the idea that if you run a business of any kind these days, you need a web site. But the time frame for how often you need to update (or outright change) your web site is probably far less agreed upon than say, how often you need to change the batteries in your smoke detectors. Most people might argue you should mix things up every two to three years, but I’ll bet there are some who would say you can go longer.
At the risk of sounding like my mother, technology is hard to keep up with. What’s new and fresh today will be old news in a short period of time. The truth is, if your web site is more than two years old and you are not planning to update it, or the technology it rests on, you’re probably behind the times (and your competition). For example, if your site doesn’t automatically adjust when it’s viewed on a cell phone or tablet, what are you waiting for? Your site won’t develop a mobile-friendly version of itself. How about an even more basic question – are you still sending content changes and updates to your web vendor or “tech guy” instead of using a quality CMS in-house? Well, guess what? You’re essentially hoping the smell of smoke will get you out of bed late at night, because you’ve neglected your smoke detector maintenance.
Regardless of how long you think you can go without paying it some attention, the sales call to see if you are ready to update your web site should be viewed like daylight savings. It’s a subtle reminder, me calling to say “Hey, Busy Person! Don’t forget about this important part of your business.” When you get the call, even if you aren’t ready to deal with it then and there, ask me to call you back on a specific date in the future (sooner, rather than later) and put that call on your schedule now. It will help you make sure that your site update doesn’t get put off longer than it should.
Hmm. Maybe I should change my phone sales pitch. “Hi, this is Tom from Algonquin Studios. Have you changed the batteries in your smoke alarms and when would you like to begin updating your company’s web site?”
The latest article that uses absolutes and broad generalizations to imply an otherwise non-existent struggle between Flash and HTML5 is from UX Booth, “What the Demise of Flash Means for the User Experience.” To be fair to this article, I see regular missives on Flash vs. HTML5 and this particular UX Booth article is just an example of many of them in one easy to cite place.
The opening gives away the false premises for the rest of the piece:
Adobe’s decision to cease development of the mobile Flash platform and increase their investment in HTML5-related efforts created perhaps the final piece of conclusive evidence that HTML5 is the current go-to technology for creating ubiquitous user experiences regardless of device.
Adobe has held that the fragmentation of mobile devices is too hard to keep up with on its own. Flash will still exist for mobile wrapped in AIR applications instead, and Flash is not going away from the desktop. Adobe’s decision to increase investment in HTML5 (via Edge and to a lesser extent Muse) is mostly unrelated since there is a market for an HTML5 authoring tool independent of Flash.
I think it’s fair to challenge the claim that HTML5 creates “ubiquitous user experiences regardless of device” when you consider all the polyfills and shims that need to be implemented to create similar experiences on a few devices. It’s also fair to say that my netbook does not handle some of the related HTML5 specifications the same as my tablet or mobile phone, partly due to various levels of hardware and browser support. Let’s not even get into video and audio codecs or the touch events specification (neither of which are part of the core HTML5 specification).
HTML5 excels at giving users a delightfully inconsistent experience on any device through the concepts of “graceful degradation” and “progressive enhancement.”
Those terms pre-date HTML5 and I can do both with HTML4 and CSS2. The author continues on and cites responsive design as a feature of HTML5, even though my own site is an example of an HTML4 site using responsive design to adapt to assorted displays.
Additionally, more than 90 percent of all smartphones and tablets are HTML5-enabled, which means that all the benefits of HTML5 can be utilized today to provide impressive mobile websites.
Making or upgrading to an HTML5 site can be as minimal as simply using HTML5’s doctype […]
The implication here is that simply changing a doctype gets you all the benefits of HTML5, when in reality you still have the same HTML, CSS and script.
The post never does answer its own question — what does the demise of Flash mean for the user experience? From the article, more HTML5 use. In itself that doesn’t tell me how the user experience is affected, just how developers are affected. If the developer does a good job, the user experience doesn’t need to change. The user shouldn’t need to worry about the underlying technology.
I’d love to see more practical discussions of what HTML5 (and related specs) can do today along with all the nifty experiments that are moving the collection of specifications along.