We don’t know which browser, which version of that browser, or what kind of computer a user visiting our website is using.
That’s why we have web standards we follow which give us the ability to code one website that can work everywhere. We use normalized templates (e.g. HTML5 Boilerplate) to give our projects a consistent and healthy starting point. We use JavaScript libraries (e.g. jQuery) to make things easier for us an alleviate cross browser issues.
We don’t know the capabilities of the browser the user is visiting our website with.
So we feature test and polyfill where we can. That way we can build the fantastic experience we want to and deliver perfectly acceptable experiences to all browsers.
We don’t know what the size of browser window is of a user viewing our website.
So we should design our sites to be fluid and utilize media queries to optimize the site for any screen size (responsive web design).
We don’t know what the internet connection speed is of a user viewing our website.
So we try and load as few resources as possible. We make those resources as small and compressed as we can. We serve those resources through servers optimized just for that and geographically closer to our users (e.g. NetDNA). That way our website loads as fast as possible.
We don’t know the mindset of a user viewing our website.
So we conduct user research (e.g. Silverback) and try to find out. We try and accommodate different ones. We use our experience (and sometimes gut instinct as users ourselves) to make the right decisions. We design for humans.
We don’t know the physical location of a user viewing our website.
So if our site needs it or could be better by knowing it, we can ask for it. Either literally or through HTML5.
We don’t know what languages a visitor to our site understands.
So if we have the resources to do it, we use translation services (e.g. Smartling) to offer our website in a user’s native tongue. If we are trying to be as professional as we can, we also probably try and be sensitive to culture differences worldwide.
We don’t know how “computer savvy” a user is visiting our site.
So we try and make it very obvious how to use our site and not make too many assumptions. We use common design patterns to accommodate “affordances“. We sweat the details in our design, copy, and overall “user experience”.
We don’t know what disabilities a user visiting our site might have.
So we try and craft our sites with accessibility in mind.
We know very little about a visitor to our website. We actually know less and less every day, as the demographics of internet users widens (younger and older, no longer a nerd thing, more areas geographically, etc.) So as we march forward toward the next 6 billion people using the web, let’s embrace the unknown by accommodating for it.
Google analytics?
Google analytics doesn’t answer all those questions though.
Google Analytics (and other analytic software) is very useful for giving us data on visitor *in aggregate*. I guess my thinking while writing this article was for individual visitors as they hit our websites.
Google Analystics is giving us data only after the website is launch and all the decisions were made.
Woopra for more real-time stats is kinda nice, but it obviously won’t give us all the answers to the list above, nothing will. The obvious inevitability is that we’ll need to actually ask people stuff. Feature Feedback, Service Surveys, Review Requests, etc…
We thoroughly enjoy using Woopra.
The real time analytics are a great way to see real time the path users are going. Provides IP, lets you watch the path they use, location, web browser, OS version and many other features including a chat instantly feature if they are on your site.
We also like the video capture services. Feedback forms are a good feature if people will take them.
very intersting article, we do know CSSTricks :D..which is one of my favourites.
Can I get this as a poster? :)
Seriously… This could make a really cool infographic.
Absolutely agreed! Do it! It’d be great.
So…
–
Sorry, can’t help noticing all but the first answers starting with “So, “. I find myself doing that a lot as well when I look back at some old blog posts.
I’m sensitive to that too, seems like an unnecessary word a lot of times. In this case I like the rhythm of it.
This. So this.
This. So this.
Being able to accurately translate a website into multiple languages would be very nice. Of course, that’s something that’s easier said than done.
This is a neat summary of thing we do know, that we don’t know
Sorry Chris but I don’t think that smartling.com would be an appropriate translation service. I’ve read what they say on their website (nice website by the way!) and they get it all wrong (machine translation, a crowd of volunteers, etc.).
As they say, if good content is worth more than advertising, translation has to be carried out by professionals specialized in the products/services of the company requiring translation services. Just like web design, translation is a fully-fledged job and you need education, training and experience. It’s not necessarily cheap.
Chris Coyier, thanks for the shout-out.
“Commenter Chris”, I’m afraid you may have a misunderstanding about what we do at Smartling. We enable multilingual sites and mobile apps with a super-easy, drop-in software service that’s SEO compatible and with the quality of human translation. We are agnostic as to *how* the content gets translated — by professionals, by your own community, or by machine (in limited cases) — that’s up to you, the customer. The reality is that half our customers are using certified, professional translators (pro translator plus pro editing/reviewer workflow). The other half are using some form of “crowdsourced translation” — using their internal bilingual personnel and/or their bilingual power users. In *all* cases the translators have access to world-class contextual translation interfaces, a comprehensive translation glossary (which ensures accuracy and consistency), and a translation style guide.
I would argue that the engaged, bilingual power-user member of your community — who loves your service, knows it intimately, and wants to participate, and has access to the proper translation tools — will probably do a better job of translating your site than the “most professional translator in the world” who’s never used your service!
The reality is that just about all our “professional translation” clients actually use a hybrid approach, where they invite their multilingual folks to participate in the translation process, collaborating with the pro translators — this produces great results.
Smartling’s message is that the localization process shouldn’t be so painful, and shouldn’t be a mysterious black box. Different customers have different translation needs (and budgets, etc) and a one-size fits all approach (i.e.: “you must use professionals”) doesn’t work for everyone. We’re not picking winners — customers can translate using Pros, their own Crowd, or Machine — depending on their needs.
The fact is that 98% of all content on the web goes untranslated, and it’s simply not possible for professional translators to do it all. Smartling is trying to remove some of the FUD that pervades the translation industry, and ultimately make the entire web truly multilingual.
(And thanks, commenter Chris, for the compliment on the site design!)
Woopra which i think is relatively new is much better for for instant results I’ve found!
Most of those can be figured out with Javascript alone.
Some users disable the javascript from browser. I do it too, most of the time.
But, as you said, javascript can do that. And yes, i know, most users never disable javascript, so it’s something to be taken in consideration.
> We don’t know what the size of browser window is of a user viewing our website.
No, but we can easily find out the width of the screen and determine the max-width:
alert(screen.width);
I disable JavaScript by default. What are you going to do now?
Take the seats, suspension, windscreen, radio, heater out of my car and store them in a garage until I think I need them.
If the opportunity cost for removing car components were as low as toggling flash or javascript in a browser, this would be a popular feature. The use case is closer to powering off the radio because of an obnoxious add, or not inviting strangers into your car to conduct behavioral observations in an unfamiliar part of town.
I disagree. Most of that things we can take from stats, and the rest we might guess based on company profile.
Yes, we cannot get it from a site which isn’t out there yet. But things like browsers, resolutions are something common to most of pages. Other things like targeted user profile really depends on what we sell.
If somebody tries to build site for everybody then probably he doesn’t have proper business plan.
We also don’t know what type of device user can use to access, Mouse or Keyboard or both or Touch based, So we keep the clickable area bigger. and use Meta viewport tag to give readable zoom size.
—————————
We also don’t know whether user’s browser has support for CSS and JS or not , So we use semantic mark-up and Unobtrusive JavaScript.
hi chrys, i’ve translate this article in italian language, mention your original post: http://mademietoile.com/cio-che-non-sappiamo
Chris, this should be a “sticky” post so that we DO know what issues Web designers have to resolve before launching. Thanks!
Chris,
For some strange reason any page on CSS Tricks “Ohh Snaps” and makes other tabs in Google Chrome Canary on Mac “Ohh Snap” as well. It is really weird and I’m not sure why. Just thought I’d give you a heads up.
Also on Chrome dev build on both Mac & Windows.
Chris, this is a mouthful of delicious links. Great post. Thanks.
This is such a great post!! Thanks a lot for all the information you share with us.
Great thing to write about!
There’s now 7 billion of us.
Chris…This would be great as a poster! I could hang it up in my office.
Thanks for a stunning website!!
A thing in my mind to ask though, is that why are you linking in a “not-so-semantic” way? Take for example the link pair ” web standards” and “we follow” in the beginning of post.
Now what I’ve learned the appropriate way is to use anchor tag content, which do actually reveal content or the title of the target page (for search engines and for people). Now, I’m afraid “we follow” won’t do that, does it :)
BR,
J.
Very useful Post.
There are lot of things we can actually find out from the list you mentioned.
I think bigger focus should be about Who our user is (as in what information he’s looking for, in which context is he – is he at home or on the road, is he in a hurry or he has time, is he more visual type or kognitive, etc.), not what technology our user uses to access our website.
Great article. Very succinctly put and chimes with quite a lot I’ve been thinking about.
We’ve all developed sites which have looked great and have caused pain later when clients feed-back issues raised by their individual clients. I recently stopped taking on new clients while my colleagues and I spent some time re-thinking some of our workflows to prevent some of the situations you highlight biting us on the ass later. And that includes initial client discussions where much more discussion takes place, especially around device reach. The term we use a lot now is ‘fail gracefully’ particularly if we can’t get jQuery to load, or we still have a large number of IE6 users.
It’s always worth thinking of this stuff – thanks for the reminder.
Thanks for all of the great links.
I’d argue that you can’t possibly know any of these, no matter what you do, so you’re better off by not being interested in them in the first place.
How accurate is the physical location of a user viewing our website? When it’s most likely you’re only seeing the ISP’s.
Or how much do you help and how much do you stay in the way when you try to predict what disabilities a user visiting our site might have? Since the majority of sites dictate the rules by which the user is accustom to navigate.
Great article – now I do know ;-)
Excellent article, I’ll also have to concur with the ”I’d like to see that on a poster” calls.
I think the most important point from the whole article is that you must rigorously test and provide polyfill and fallback for legacy browsers, H5BP is definitely a good starting point as the development community has put countless hours into testing cross-browser compatibility and very much try and keep with the times.
I would love to see a comprehensive list of known browser bugs and CSS defaults. Any takers?
Thanks for this great post Chris. A pleasure to met at FOWA London :-)
I didn’t know Smartling, and it’s a great solution for translating websites. Jack, do you also translate specialized content, like medical one.
Nice round-up :)
of course you know some of these things… when an HTTP request is sent a server it sends more than what page it wants. All of the important things about the type and state of the browser can be accounted for. If the user is using firefox, IE, or on a mobile phone, then display the page accordingly. Things can be dynamic, so it doesn’t matter what size the browser is. You can also very easily get a user’s IP. so yes, you know where they are too. This whole article is wrong. Change the title to What We DO Know
Hi Chris,
I like this round-up; very useful.
I know some commentators (above) have picked at the details, but for my part, I especially like the clarity of the language used. I think this does a good job of demystifying a lot of the WHAT and WHY of what we designers get up to, and it is presented in a clear Problem : Solution format.
I mean, I’d be happy to share this with a non-designer colleague, to help them understand where I am coming from, and I think that shared understanding and communication, especially between people with different areas of expertise, is very valuable indeed.
Nice one.
I have install a widget on my website to monitor the visitors. But it can’t provide accurate information. I just wonder if there is a better to do so.
This is a good list to have in mind. Thank you.