Not so long ago, web makers assumed a lot about web visitors. We figured most people used one browser or another on a computer with a screen of a particular dimension. Web developer and author Jeremy Keith calls this our "consensual hallucination.”

The shift toward the mobile experience forced us to confront these assumptions. Luckily, we've mostly embraced reality: today, we understand the need to build flexible systems that allow people to interact with content regardless of their web browsing choices. In other words, come as you are.

It's a simple goal, but a number of obstacles can get in the way.

Yes, it's possible to use cookies and other tools to generate a lot of data about the people who visit a website. But this post isn't about privacy as much as it is about access to content. After all, the website you’re on right now only knows that you're a person whose browser landed on this article. It doesn't know if you're in the office, at home or on the beach. But that's okay! This website was built with the anonymous user in mind.

Who cares?

A free and open web is based on the notion that websites should be built for the broadest range of people. If our ability to access and interact with a website is determined by our device, browser or network, we lose.

This is of great importance to companies looking to maximize their customer base. For example, Amazon is famous for making the sales process as simple as possible. Their dogged pursuit of a good user experience has paid off. In 2015, Amazon accounted for 60% of online sales growth in the US. A key piece of their success is drawn from making the sales process simple across devices. Indeed, purchases on smaller devices grew by better than 5% between 2014 and 2015. When news of the next Harry Potter book breaks, Amazon wants you to be able to read about it and to place a pre-order all from the comfort of your beach chair.

As web makers, how do we approach this problem? We want to deliver a consistent experience to each user, regardless of their browsing choices. To be clear, web developers and content providers have no reliable way to determine what kind of device is being used to render a site's content. We're not entirely without tools, but it’s important that we choose the correct tool for the job.

A good detective is hard to find

When someone requests a page on the web, a bit of information (the “user agent string”) is exposed about which browser is being used. Developers have tried to use this information in an attempt to tailor the content’s presentation. This is called browser sniffing (sounds disgusting, doesn't it?).

For example, if we go by what the browser’s user agent string tells us, we might guess that the user prefers Opera Mini. Based on that information, we may not attempt to use CSS transitions or animations, because we have to assume the browser won't be able to understand the code.

Unfortunately, a browser’s user agent string frequently provides false positives. Faruk Ateş sums up the problem nicely in this post:

The biggest problem with UA sniffing is the "UA" part, because browsers lie. A lot. They started lying with the release of Microsoft Internet Explorer 2.0, and they continue to lie to this very day. Browsers lie about who they are and what they can do all the time. Sometimes it’s not even the browsers themselves who do the lying, but proxies adjusting UserAgent strings along the way without the browser’s or the user’s knowledge.

Mozilla’s take is even more to the point:

Serving different web pages or services to different browsers is usually a bad idea.

Okay, so we don't know which browser the user has chosen. But even if we could trust the browser’s user agent string, we'd still be in a pickle. What happens if we think the user's device has a relatively wide screen, but the user has chosen to minimize the browser to one side? If we had chosen to deliver a “desktop experience” in this case, the user would probably be forced to scroll horizontally. Bad form, sir.

Similarly, phones and tablets were among the first devices to offer features such as touch and location awareness. If the user agent string had identified the browser as mobile and we had tailored the content for a small screen, we might have been tempted to serve the content using only the most basic feature set, which again seems out of line with the actual user. Screen size does not necessarily correlate with the type of device being used.

Finally, we can’t infer anything about the user’s Internet connection if we attempt to identify the browser and/or device. Developers are probably accustomed to high-speed connectivity. But the open nature of the web demands that we take all users into consideration, regardless of the speed of their connection.

Remember, our goal is to deliver content and functionality in a device-agnostic manner. This allows the broadest range of users to access and use that content.

Progressive enhancement to the rescue

The key here is to recognize that we can deliver a meaningful and functional experience to any browser on any device connected to any network. We need to understand that the core requirements are probably pretty simple.

Happily, we can write code that can test the browser's abilities. We're not reading the browser's user agent string - we're testing for the presence of specific features and the current screen width.

In short, we begin with the most constrained conditions and base the site's presentation and functionality according to those constraints. When core functionality is settled, we can then leverage browser tools (CSS and JavaScript) to test the current environment in order to deliver an expanded experience where possible. For instance, we can use CSS to test the browser width. If the browser is judged to be wider than a certain value, we could restructure the site’s layout (shift a single column into two or three), or display a larger picture.

This is progressive enhancement.

In contrast to reading a browser’s user agent string, which is made available only once, using CSS and JavaScript to test a browser’s abilities is a real-time event. If the user manipulates the browser to make it narrower or wider, the site’s layout can change on the fly.

Summing up

Building websites is hard. Developers have access to a limited number of tools that can provide reliable information on the user’s experience.

But here’s the good news: the tools are getting better. And if we keep in mind that core functionality should be available to everyone, we’re more likely to build sites that are valuable to the user – and that creates value for everyone.