Dealing with Unsupportive Clients or Bosses - CSS3

Sometimes the obstacle to using CSS3 successfully isn’t so much the lack of support in browsers, but rather from your client or boss.If you’re concerned about getting pushback from the people paying the bills, here are a few strategies that we hope will help you get CSS3
accepted at your workplace.

Don’t Tell Them Everything
Let’s start off with what might be the easiest “buy-in” strategy of all— call it the anti-strategy, if you will. We’ll say it bluntly: maybe your client or boss need not know at all that you’re even using CSS3. Think of it this way: if you hire someone to build you a house, you don’t need or want to know the names of every tool, material, and technique the contractor is going to use along the way. You care about some of the technical details, but for the most part you’re more concerned with the bigger picture and making sure your goals are met—in whatever way that contractor thinks is best.

Sometimes web design is a bit like this. While there are plenty of technical details you do need to run by your client or boss before implementing them, there comes a point where you just need to decide what the best tool for the job is, and use it. For instance, it’s probably best to discuss whether you’ll be using CSS3 animations or Flash for a particular animation on the site, but you don’t necessarily need to ask your client whether he wants to use HSLA or an alpha-transparent PNG for a semitransparent background. Nor do you need to ask if it’s OK if you add a subtle text-shadow to a heading to make it stand out a bit more. If you’re going to be using CSS3 in limited amounts for small visual details, you can probably quietly decide that on your own, and then just implement it.

Educate Them About Progressive Enhancement Up Front
When you’re still in the sales-pitch phase of a new project, be sure to always include some discussion of progressive enhancement. Before starting work, make sure your client understands the basic idea behind progressive enhancement and how it will affect her own site. You’ll probably need to show visual examples in multiple devices and browsers, preferably from real sites, to make the point clear. Discuss which browsers you will enhance and which browsers will get the more bare-bones version. Find out which browsers matter most to your particular client based on usage statistics for her current site or the planned audience of a new site.

When discussing progressive enhancement with your client or boss, you don’t need to go into technical details, but talk about how designs looking different in different browsers is inevitable and even good. To convince them it’s good, you’ll probably need to play to one or all of these three angles: saved money, happier users, and better search engine placement.

Tell them how designing using progressive enhancement, and CSS3 in particular, can reduce initial development time as well as maintenance time over the entire life of the project, costing them less. Also tell them how they can save money on bandwidth costs because CSS3 reduces the need for so many external resources like images, and often reduces file sizes. Remind your client that performing complicated workarounds for IE is billable time, and question what the ROI of that choice will be.

Talk about the ways that CSS3 can improve usability and how this can translate into happier users who stay on the site longer, which in turn can translate into more sales, signups, or whatever goal the site is aiming for.

Impress them with your knowledge of Google’s search algorithm by explaining that Google now rewards fast sites, and go on to explain how CSS3 can make their sites faster.

In short, emphasize to your client or boss that progressive enhancement is in his or her best interest—because it truly is. It may not get accepted overnight, but keep working on helping your clients understand the reasoning behind web design and development best practices like progressive enhancement. Some day—pretty soon, we hope—these practices will be mainstream, and assumed, and then you’ll already be ahead of the pack in providing better benefit to all users.

Manage Expectations from Design Mockups
One of the ways designers most frequently get into trouble is by showing their clients something in a design comp, otherwise known as a mockup, and then having the client expect the final product to look exactly like that in all browsers at all times. Even if you intended for the appearance shown in the mockup to display only in up-todate, advanced browsers, you’ll often end up forced to add in workarounds and hacks to try to make it look the same everywhere. There are a few ways you can avoid getting stuck in this trap.

The best way to avoid setting unrealistic expectations based on your design comps is to never create any comps at all—or at least never show them to your client.Instead of using Photoshop or Fireworks to mock up your design as a static image, go straight to HTML and CSS to create the design mockup in its real, final medium. Show the client a working page that he can play with. As long as you make sure to show it to him in his own browser, he’ll be able to see only what his browser is capable of, and no more.

Although this method of going straight to the CSS may seem like it would be a lot more work, given the fact that if the client doesn’t like the site you might have to rebuild it entirely, it shouldn’t be more work if done wisely. In fact, working in HTML and CSS should save you time.

You’ll need to make sure that you get a lot of information up front from the client about what he expects from the design and what his tastes are. Don’t settle for “I’ll know it when I see it.” Push him to give you detailed answers.

Also, work out the overall page structure and layout, using simple wireframes, before delving into any CSS work. That way, even if the client doesn’t like the images, colors, or fonts you used, at least everything will be in the right place, or close to it, making changes to the design at this point much less time-consuming.

In fact, being able to change the appearance by editing CSS in a single file is often much faster than editing graphic comps. In the time it takes you to get the anti-aliasing and line-height and text wrapping just the way you want them in a graphics program, you could have
probably done the same thing twice in CSS, and had a more accurate representation of how it would really look in the browser to boot. Also, being able to play with the design in a browser allows you to spot problems in the design that would only occur in a live page. You can fix these problems as soon as you spot them, instead of placing problematic design elements into a comp that your client might then fall in love with, forcing you to spend hours agonizing over how to actually implement them in a real page.

You can still use a graphics program for generating your wn ideas in the early stages of creating a design, and for laying out small areas of the page that do need complex graphics that CSS alone can’t handle. But overall, using the real tool that web pages are styled with—CSS— to build your designs will lead to fewer headaches down the road.

Despite these benefits, we know that designing in the browser is a huge shift from how most web designers work and what most clients expect. we admit that we have not been able to do it myself very often. Plus, you may have no control over the comps—they may be created by separate designers and simply handed over to you with instructions to build exactly what is shown. If it’s not possible to design in the browser in your situation, read on for other ways you can avoid setting your clients up for disappointment.

If you’re going to present your clients with traditional design comps, showing only one view of each page, be sure to explain to them that they’re just mockups, not true representations of what everyone will see. Before ever showing them a comp, make sure they understand that static images can never be completely accurate because it’s impossible to show all the variations in browsers, screen sizes, available fonts, and more. Explain that not every visual detail they see in the mockup will be available to every viewer—including possibly themselves—in the browser. Some people will see slightly less attractive variations based on what their browsers can and can’t handle, but you’ll use the best features of each browser to give a good experience to everyone.

If you have the time, it’s well worth it to create variations of each comp, to show some of the possible variations that users in different scenarios will see. For instance, you might create a comp of the home page at three different widths: 480 pixels for mobile phones, 750 pixels for small monitors, 1200 pixels for wide monitors. You might also create a comp to emulate IE 8’s expected appearance, showing, perhaps, that this browser won’t see the rounded corners and translucent backgrounds shown in the main comp.

Yes, this is more work up front. But if it keeps you from having to jump through hoops to try to make the page look just as gorgeous in IE as it does elsewhere, and if it allows you to use CSS3 and enjoy all of its time-saving benefits, then in the long run it will probably be less work. And you’ll have a better finished web site to show for it.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

CSS3 Topics