2.2 Deciding What Level of Support You Should Offer
At the moment, it’s impossible to take advantage of all available web technologies and simultaneously provide support for every possible user setup. Learn what to evaluate when deciding how far and wide your support should go, for your own sites, your client sites and your customers’ sites.
1.Introduction2 lessons, 07:49
2.What Will You Support?6 lessons, 58:46
3.Creating Compatibility7 lessons, 1:15:06
4.Testing Tools1 lesson, 10:33
5.Conclusion1 lesson, 02:11
2.2 Deciding What Level of Support You Should Offer
Hi. Welcome to Bombproof Web Design. In this lesson, you're gonna learn about how to decide what types of support you're going to offer for all the different kinds of setups that your users might have. There are two things that are true in the world of web design at any given point in time. The first is that there's gonna be some kind of new technology or new code that's just been released that is so cool you wanna incorporate it into all of your projects right away. And the second is that there will be a percentage of your site visitors who can't support that new technology. So how do you figure out which of the new and latest, greatest technologies you incorporate into your projects and how far and wide your support should go for the various aspects of your users setup. Well, you can start by having a look at the three different types of project that essentially any web design project falls into. So what type of project your web design project is, depends on who it's for. Your design will either be for customers, so you're producing themes for a platform like WordPress, or your producing templates where you don't actually know who the end user of that product will be. It could be anybody. The second is when you are producing a project for a client, for example, a small business website. And the third is when you're producing something for yourself so a design portfolio or a blog. Or even something for our own business. So how you should approach figuring out what to support and what not to support depends on which of these three categories your project falls into. But first, there are some things that are universal to all projects, regardless of what type of project it is. The big one is that you should always support accessibility. It doesn't matter who the project is for. It doesn't matter what the project is meant to achieve. Always, always, always support accessibility for people with vision impairment, hearing impairment or mobility impairment. Don't be that guy that runs the shopping center and refuses to put in disabled bathrooms or disabled parking lots. That's just not cool, don't be that guy. Always plan for your sites to be responsive. We're well beyond the days where you can just build a 960 pixel-wide website and just have that be the only size that your site is designed to function with. So, make sure you've got a fully flexible layout. And I'll be showing you some techniques that you can use to make that happen later because if you have a really good approach to responsiveness, you design will work really well by default on almost all devices, operating systems, and displays. There will be a few exceptions and a few tweaks you will have to make, but just having a good responsive strategy will get you 90% of the way. And, never ever depend on a mouse. Never assume that the user will have the ability to hover over things like a drop down menu, for example. You have to assume that your user might only have touch interaction. Or, they might only have keyboard interaction. Or, they might even be using something like a television remote control. Or, a game controller. So, for everything else other than these universal support areas that we've already discussed, you have three options. The first, is you can make a blanket rule that you won't use any technology that doesn't have full support for every aspect of all of your user setups. However, that is not recommended because your sites will miss out on a lot. If you were not to use any technology that didn't have complete 100% support you would have reduced responsive functionality. You would have a lot less prettiness in your site and you would also effectively be penalizing the majority of your users. So even though you want to make sure you support all of your users In some way, you also shouldn't be penalizing the majority of the users just because there are some users that won't be able to use every single aspect of the technology that's used in your sites. So the second option is that you can detect unsupported setups and you can provide fallbacks or polyfills. So if there some CSS or HTML or some type of technology that you want to use in your project but you know it's not fully globally supported, yet you know that there is a really good quality fallback or polyfill that will mean nobody even realizes that they don't support that technology. Then you can go ahead and use it, as long as you have a good plan in place for how you're going to deal with it. The third option is if there is some technology that you really want to use that is really, really going to add to your project but there is no polyfill and there is no fallback. Then, the third thing you should look at is detecting unsupported setups and showing some information on the screen to the visitor to let them know that for whatever reason they're not going to be able to experience the site as it's intended to be. Looking at the three different types of project again. The first one that we mentioned is if you're creating a project that's going to be sold to customers. This is the most unpredictable form of web design because you have no idea where your design might be used. You don't know who will purchase your theme or template. You don't know where they'll deploy it and you don't know what type of traffic they will be interacting with. So, if you're producing box products for customers, you have to have the absolute widest level of support that you can possibly provide. So that means you are not going to be able to use newer technologies unless there is a solid fallback or a polyfill is available. For example, web components are for the time being, they're out, you're not going to be able to use those because there's no solid polyfill that will let you support back far enough. However, on the other hand, it's perfectly fine for you to use HTML5 semantic elements like header, article, footer because there are solid polyfills available. And that's something that we'll have a bit of a closer look at later. So, even though if you're working with projects that are designed for customers you're going to work with the base assumption that newer technology that doesn't have a good polyfill is out. Even with that approach there's still going to be some edge use cases that you should cater for, such as users of IE6. Microsoft themselves don't support IE6 anymore. It would be fairly reasonable to have an approach whereby you say I don't code my sites to work in IE6, but that doesn't mean that you can't still detect an IE6 user and give them some advice to let them know that they won't be able to experience your site. So what about if you're doing a project for a client. This is a different situation because you can get some quality information to help you make decisions. You're not flying blind in the way that you are when you're dealing with projects for customer use. The best place that you can start is by examining the client's statistics. Earlier on I showed you what you can gather from looking at Google Analytics and what you can get off from looking at Orstats. So if you can start by having a look at the current traffic that a client is interacting with, then that will give you a really really good idea what type of support you're going to need to able to provide. Once you've done that, the most important thing with a client's site is to understand that it is objective-based. Every site that you do for a client is created because it has a very specific purpose. So that purpose might be to gather leads, or it might be to generate sales. Or it might be to communicate the selling points of a product. So you have to start your planning for a client site with an understanding of the objectives of that site. Once you understand those objectives, it becomes fairly clear what mechanism you should use to decide whether newer or older technology should be used in the project. You simply have to ask yourself which of the two choices will best help achieve those objectives. If newer technology such as, again using the web components example, if that's going to allow you to create an experience for the client's visitors that will create more conversions, create more sales, pull in more leads, then that client is going to love you. However, if using the newer technology is going to block out too high a percentage of their visitors and you end up having lower conversions, then you're gonna have problems. Examine all of these pieces of information in unison to figure what is best going to help the client achieve their objectives. Then once you've established your assessment discuss the pros and cons of the various options with the client. Make sure that they understand what direction you're going to be taking their project before you commence production. And whatever you do decide to use still provide fallbacks and polyfills and advice to unsupported visitors wherever it's appropriate just like you would if you were creating a project for customer consumption. And thirdly, you have projects that are for yourself. In this scenario, you are your own client. So you can apply all of the same rules that you did were looking at a client project. However, this time, you just have to understand, you just have to write down, analyze your own objective for your project. So, if this is something that you are doing professionally, then perhaps your objectives are going to be to get contacts from potential clients or perhaps you are just doing something experimental. Perhaps you are doing a site that is deliberately designed to explore newer technologies, in which case, obviously you're going to best achieve your objectives by going ahead and using all the newest, shiniest stuff you can get your hands on. When you're doing things for yourself, you can be a bit more loose with how you approach what you're going to support, and what you're not going to support. However, just to show courtesy to all the users of your site, again, still follow those same processes where you always consider accessibility. You always shoot for responsiveness. You always try to make sure that your UI is going to work for the visitor. And for any area where people may encounter unsupported technologies, you go with fallbacks, polyfills, or advice to the user. In the next lesson, you'll learn about specific web technologies and which ones you can and can't use in your projects.