How can I convince a client that audio on a website is a bad idea? [closed] - html

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have a client that wants audio to play while the user is browsing the website. Besides the fact that audio is annoying when it starts automatically and plays when you are browsing, I thought of the following technical struggles.
Having to use frames to allow audio to play uninterrupted.
SEO issues with using frames
Having to use ajax to allow audio to play uninterrupted.
SEO issues with all ajax site
Pop-up to allow audio to play in another window
JS pop-up blockers won't allow this
Does anyone else have other technical hurdles that I can use in my defense?

Music on your website is a terrible idea
All who are against music vote for this answer
All who are for music vote for the other answer

It doesn't matter what you or s/he thinks. All that matters is how the customer reacts.
Easy way: see if they'll agree to asking 10 random strangers (who are representative of the visitors you get) and playing music in the background (you can just mock this up) and abiding by their opinion.
Hard way:
If the client won't agree to #1, try the one below (and once they realize #1 costs $30 and #2 costs $300 to do they'll then opt for #1)
How about some objective metrics with an A/B split test: Randomly assign half the visitors to hear music, the other half not to. Then compare conversion rates (or abandonment rates).

Losing customers in the effort to prove a point isn't going to win any brownie points with the client, so I would avoid putting music on without the ability to turn it off. Furthermore, you risk frustrating your user base by defaulting the music to on/loud.
However, in this scenario, you will probably find that most people never turn on the music because they don't realise it's there.
You could ask your users what they prefer the first time they load the page up:
Do you mind if we play music during
your visit to our site?
Sure, go ahead, I love music
Actually, I'd rather you didn't
[X]Never ask me this again
You'll likely find that most of the users say no, and they'll appreciate you not harassing them on every visit to your site. Likewise, those that want to listen to the music can appreciate it without your whole user base being irritated by it.

If the client is unwilling to see how bad of an idea that playing music can be, try to meet in the middle. Maybe add a music player options so users can choose to toggle between on or off. That's the best attempt and what my strategy would be.

Hmm, this is a tough issue because there really is no clear, definitive answer. I like to look at issues like this:
Technical:
If a client wants a feature (in this case sound) perform the due diligence to research if browsers can support that feature, and which ones will not. Come up with numbers to show the client. X feature is only supported in X browser and most people use "this" browser so I would / wouldn't use this feature.
Psychological:
Specifically for sound, study the psychological effects, usability of this feature as it concerns the end user. I will immediacy leave a website if a video or sound starts playing without my permission. I expect a choice, and when that choice is taken away I leave. And at the point where I leave, I'm mad, I hate any user experience where I am left out.
Client is not always right:
So most of us have heard that the client is ALWAYS right. Well to be quite honest, no no they are not ALWAYS right. It does not matter whether your selling websites, or magazines, or working on cars, you have to be there for your client. Obviously if you do good work people will refer you. However sometimes you have to stand your ground with a client. My suggestion is to make sure you do that at the beggining of a project, rather than later. I've turned down projects, or agreed to handle only certain aspects of a site design because I wouldn't be associated with certain features. For example I don't do Flash sites. Not that flash is bad I just don't do it. I give those projects to friends. And they return the favor. If you tell a client upfront that you won't / can't deliver that's a good thing. Don't say yes and then come up with an excusse later in the project, that's where the client will become frustrated with you, and if they complain they are right to do so, and you will loose business.
At the end of the day communication, deciding upfront what you will and will not do will save your lots of headaches.
And as for sound, it has it's time and place. Bands, Flashsites especially those highend national ad campaings for cell phones, or movies can get away with sound. The best option at the beginning of a project is to tell (don't ask) the client that they can have sound, and if it does auto play you will set he volume to low, and have a visable player that the user can control, meaning they can TURN IT OFF, OR LOWER THE VOLUME, these features are not negotiable. If they have a hard time with that, then walk away from the project because they will have a hard time with anything. And don't be afraid to turn down work. For every 3 sites I work on I turn down one.
I recently took on a project that requires sound. I'm kinda in a pickle with my client (he's not mad) but he told me he wanted sound and I offered to use a player, and give control to the end user. He was ok with that. Recently, after checking out the sound player feature he says "No, I wanted a sound to play when you rollover the navigation. The pickle is that he never said that, and I've stood my ground with him about adding that feature. So he's a little upset with me, but we are working it out. He's mostly upset that I want to charge for the extra feature, and I'm not budging. It will all work it. Just an example.
Sorry for the long reply, Good luck!

If someone is viewing your client's web site at work, the music could cause them to click away immediately. That's what happens when audio starts playing on a site I'm browsing at work.

I had this issue with a client. I solved it by doing an Ajax site, but in order to workaround SEO downfalls of Ajax, all the navigation links literally linked to another page. Search engines saw a completely normal site, where navigation links were normal and only the content paragraphs for that one page were loaded in the HTML.
The JavaScript then progressively enhances the page by overriding the link behavior to load the content for the new page. So users with JavaScript got a great Ajax experience, with audio, and only the content div loaded new content.
You can even get around back/forward button issues by marking #pagename in the URL for each page. Upon page load you should check to see if a #pagename is there, and then load the content for that page.
Hope that's clear enough - let me know if you need more details.

See if you can figure out why, from your client's perspective, they want this feature. See if they can give you good reasons. Then you can begin seeing how to meet their goals without necessarily using their methods.
That might help with convincing them, as opposed to resorting to technical concerns. Going technical makes it sound like you don't want to do your job. That's not the case at all -- I'm sure you want their site to be awesome and you will do what it takes to make that happen. It's just that "what it takes" may not be exactly what the client asked for the first time.

There is nothing like a practical demonstration. Find a suitably annoying midi file and loop it endlessly. If the client can stay in the same room for 30 minutes without their head exploding then they have won the right to put music on the site.

Obligatory XKCD.
Myspace

The business stakeholders do not care about your technical worries. So I advice you not to waste time telling them or seek more input.
The business stakeholders do care about money- and that is the major reason why you were hired and a "currency" you can use to "talk" to them. Explain to them things like:
How adding audio can reduce an ability for customers to stumble upon their site via a Google or bing search (SEO)
How audio can be disruptive and make them more likely to go to the competition (which is only a click or two away) (this is your pop-up issues)
The current state of technology and users' expectation will not make this site pretty and give a poor return of investments (Ajax problem you mentioned)
Notice each of these focus on the button-line (profit-$$$) and does not bore the business stakeholders with technical details which is not their problem (but yours.) Speak to them in their language, be frank and realistic and these guys can be wonderful. A demo of an extremely bad site can help if you feel that it helps your cause (but be careful because this can also hurt you.)

Nothing you've listed is a reason to avoid playing audio on their website.
To you and I (and many others I suppose), auto audio is really annoying.
My suggestion is that you explain your feeling to your client.
If your client still insists on having audio, then do what they want. The client is your customer, and the customer is always right.
As an aside, many photographers I know have audio, and while many poo-poo this, they all swear that their clients love it. So I guess to each their own.

Put it on the website and wait for complaints to come in.

Store designs, notes, and specs for client's approval on your own web site. Add music to these pages. Make sure it's music he doesn't like.

This comes down to one of the primary rules of usability: do what the user expects.
The only way I'd consider putting auto-playing music on a website is if it's for a band website with an integrated Flash music player. The reason is simply that the user will expect it. Any other time it's just annoying.

Another point - many users open many tabs/windows at once, so if music starts playing, you don't actually know which site is doing it, which is intensely annoying!

I might cite a precedent to make my case. Identify their space or niche on the internet. Look at other site owners who are very successful in the customer's space. Do they play music? Is it working for them?

Suggest against it, because most internet users actively dislike it. Make a comparison to the blink tags of ten years ago, which also made sites seem less professional to the larger audience.
And if they still want it, do it, because it'll make them happy, and happy customers with terrible work beats unhappy customers with the Best Site Ever. Just leave the site out of any portfolio of your work you put together.
Or, as the genius above already added, add a toggle for music on/off.

Every time you call the client, blare music in the background and say you just opened some website that started playing it automatically.

Related

Should I preload a large image that's above the fold?

I'm excited about the rel="preload" property, because it looks like it can help speed up page render times.
The use case is a web page with a large image above the fold. Right now, Chrome doesn't start downloading the image until after fetching jQuery (a fairly heavy file). With preloading enabled, they download in parallel.
But I'm reading conflicting reports about whether I should use preload for things that are in visible HTML elements elsewhere (as opposed to things made visible by user interaction, like a dropdown menu).
This post seems to recommend not preloading:
When not to use preloading:
When the asset is referred to somewhere else on the same page.
When you're not sure the user will actually require that asset. Like on a page visitors only go to 3% of the time.
While this one seems to indicate it was really helpful for a similar situation on the Financial Times website:
When the Financial Times introduced a Link preload header to their site, they shaved 1 second off the time it took to display the masthead image...
So which is it? Should I provide an early "hint" to display the always-shown, above-the-fold image? Or should I just let the browser get to it in the usual order?
I think that in cases involving performance optimization, you really want to create an A/B test to determine which one you should do. There really is no cookie cutter answer for image preloading that applies to everybody as a best practice.
One of the biggest tenets of a favorite book of mine, Lean Enterprise, is use to A/B tests to prove or disprove a HIPPO (highly paid person's opinion). Certain opinions carry a lot of weight, both in your organization and on the internet. Because of their importance and reputation, their opinions veer towards the realm of fact, even though it may not be.
The practice of measuring performance empirically is also touted by another book I love which deals with performance tuning - Code Complete 2nd Ed. In that book, McConnell gives several code examples where you would expect one piece of code to be optimal, but in fact, it performed poorly (see chapters 25 and 26). One of his key points is that you should always test a performance optimization. If it isn't worth testing, it isn't worth writing the "highly performant" code in the first place. McConnell's premise doesn't just apply to his low level coding examples, but to high level decisions such as preloading images above the fold as well.
I can also attest to the importance of A/B testing at a professional level. I used to work on Amazon's SEO team and we A/B tested everything. The fact of the matter is that you never really know how customers will respond to something. Nobody can predict customer behavior - not even Jeff Bezos - and you really need to back up your hypothesis with real data to prove or disprove the validity of what you're doing.
Even though you can find multiple blog articles and online sources discussing whether preloading is better or not, you don't really know whether that will work for you until you've done it. Different people have different servers with different performance characteristics and different network topologies, etc. You just don't know which way is better for you until you have the data. If you launch your A/B test and find that find that your repel rate goes up when preloading, then you know that you have to dial back your treatment and return to your control. If however, you find that customers don't get bored waiting and click through at a higher rate than before, then you have a winner and you dial up the treatment - deleting the control code entirely after a period.
I hope that helps.
The article is wrong about those statements. Preloading is used by the developer because he already knows those assets are needed on a page. Preloading is not a "hint". Prefetching is more in line with what he states, that you are telling a browser that it's possible the asset may be needed.
If an image is above the fold, then you know it will be needed, and that is exactly what prefetching is for.
Addy Osmani of Google
preload is a declarative fetch, allowing you to force the browser to
make a request for a resource without blocking the document’s onload
event.
I would use rel="preload" for images only if they are to be found in css, javascript that will led to a bottleneck in the render of the page at a later time, if user driven events will request the image and it will have detrimental impact in user experience or if you are experiencing any flows due to this large image in the rendering of the page.
I understand your image is above the fold, and if it's to be found in the source code from the beginning I would let browser prioritize what to download first.
On the other hand you could always A/B this change and see if it works for you.

Can the site built entirely in Flash be still SEO-friendly and visible in search engines? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
My website will be basically selling services; will my SEO ranking still be affected if I embed the Flash site in a blank html page? I am at that critical point where I am ready to upload the site but I am just having second thoughts about the ease of doing business with Flash.
Ignoring the SEO implications of an all-Flash site, unless you're building games, or I have an extremely strong desire to buy what you're selling, I will turn back immediately if I find a website built entirely out of Flash.
Nothing against your programming skill; I just have rarely seen such a site give me what I want. The name is often apropos.
Search engine crawlers can't crawl flash sites, so your SEO rankings will be based off the non-flash part (the blank html page). Personally, I also don't really like the user experience of a flash-only site.
Google and Yahoo! have added flash crawling functionality to their engines recently.
http://www.adobe.com/devnet/flashplayer/articles/swf_searchability.html
From a SEO perspective you're fine on that front. Still..your page will need a DOC TYPE, Page Title, etc to remain SEO compliant.
IF your target market is users browsing your site from a laptop or desktop you should be fine. You may want to include a flash-free option for users accessing your site on a mobile phone or with javascript/flash disabled.
For example, You can run a browser sniffer to redirect any user agents accessing the page on Safari via an iPhone OS.
Other than that Flash does offer some nice flair to a site. If you can give alternatives to users that don't like the application then I say do it.
It can certainly be done well. I've seen some pretty cool Flash-powered stuff being run by some pretty big-name companies, do a search for HP's Photosmart page for instance.
Look: there's a lot of information out there about Flash and SEO, and much of it is out of date. Google rolled out "official" flash support about a year ago, and they've been refining it ever since. Google will index your Flash site, but exactly what gets indexed is a bit of a black box so it always helps to have HTML alt-copy.
Never, ever build a full-flash website without using SWFObject for embeds and always try to use SWFAddress to enable Flash Deep-linking. There are ways to make this work and work well - a lot of people don't know that and have a deep-seated hatred of all things Flash because they were irritated by Splash pages in 2002. There's nothing to be done about them.
But if you want to use Flash, go for it - just do a lot of homework and test your work.
Whether or not it's business suicide depends on how much of your revenue is dependent on getting referrals from search engines. Your search engine ranking will certainly be affected if you have an HTML page in which you simply embed some flash.
Could you implement an alternative more static site, by scraping the main content from your flash?
all web applications should be made from the point of view of accessibility, no matter what the scripting language used at the time. If you use a nice script like SWFObject then you can populate your page with "alternative content" to the flash page which the search engines will crawl. this will also allow any browser that doesnt have flash to have a look at the website, even if you dont make the whole thing as "pretty" in HTML.
two birds as they say.
I don't know whether you've considered this or not, or whether it applies to your circumstances, but you might lose out on business from the visually impaired. Unless I'm mistaken, I don't think there are any screen readers that operate on Flash.
I think it depends on what kind of business we are talking about.
For most, I would say don't do it!
But there are ome kinds of sites where I think it is appropriate, if done very well. For example if you are in the business of art or design, or are showcasing a product/service where art or design is key.
As an example:
Volkswagon's GTI Project (a large part of what cars are about is design)
Flash has fallen out of favour the last few years with a lot of people. Initially it was because search engines didn't crawl it but these days it's mainly because 'flashy' effects can be done with javascript engines like jquery, scriptaculous or mootools.
Having said that I can tell you that nearly every business customer I go to still wants flash on their site and most casual web users don't give two hoots what a site is built like as long as it works, is fast (something kinda tricky to do with flash) and is what they want to look at.
I say go for it and see how the site does! I'm sure if you use analytics for a few weeks you will know whether your site is doing well or not.
Best of luck with it :)
For some reason Motorola made their new Droid site all in Flash.
This is a good article about how dreadful it is, and the drawbacks:
newmedia article
There are a ton of good reasons to use Flash sparingly. It's good for what it does well and dreadful for entire sites.
Ok so first of all, perspective, my primary domain is Flash and system architecture, I and the company that I work for at present are all about creating online 'digital experiences', engaging online content.
This is NOT applicable to selling services, e-commerce, and general information based sites, as much as it pains me to say that. There is current a massive backlash against flash due to the arrival of javascript effects and the canvas tag, I'm going to be bold here and say that anyone who thinks they can replace x years of plugin development and and media experience by giving html/javascript devs a div they can draw into are simply misguided (and you can show me all the chrome experiments you want but its still not going to be pixel bender or native 3D support).
So with that said, in this climate you've got to play to each formats strengths, you want slick, stylised SEO'd content that is accessible and concise, html with progressively enhanced javascript is a no brainer. You want a web app that people can use easily, search and build a micro-community around then googles GWT (other js frameworks are available) is the way to go. For everything in-between and beyond theres Flash.
I'm not giving Flash a kicking (it's my lively-hood after all), far from it, in fact I'm actively encouraging people to use Flash only for the kind a digital master-pieces it was made for, if you can do it in HTML, why would you do it in Flash? Sure in most cases it actually works out lighter than JS, and it's cross-browser compatible, but these are small issues that will only be ironed out in time, HTML was designed for the web, Flash was designed as a plugin.
In coming years we will see Flash on a multitude of devices with the open-screen project and the iphone-flash cross compiling, it is becoming a platform for multimedia development in general, where-as the web is becoming more service orientated platform, web apps running off searchable indexed content in the cloud. If your website is intended for the web, then make it for the web.
(Just realised that this was a bit of a rant, apologies)
If you created a web site with Flash, user will not be able to use basic browser functions and extensions such as searching, spell checking, sharing a particular page via Twitter, etc.... (And cannot access from iPhone.)
Depends on the site in question. If its just displaying marketing collateral or case-studies then a "flashy display" would be fine. Have seen couple of such websites in the past and the better ones have impressed me.
You should also consider how frequently content would change and how it impacts your design in Flash vs say design in html. The search engine ranking aspect also will matter.
You won't get any business from me.
Nothing says 'amateur' on the web like pointless Flash.

How do you determine if doing something the right way will handicap you?

I have a horrible habit, actually something I'm wrestling with right this moment, when I think of a better way to do something - either a refactor, or something that would just be SO MUCH COOLER LOOKING, or such a better UX, I just HAVE to do it. Even when it would cost me time and I'm in a time crunch. I never know when to say, "no, there isn't time for this I can do it later."
Is there a line you draw?
Like right now I need a way to display magazine articles that are in the database. The easy way would be to create a new .aspx page and just pass the article id. the AWESOME way would be a jquery fade in modal that would display the article. At least that's what I think. Not being a guru it would take me longer to write. We are launching next week no time for extra crap. However, I just can't bring myself to do it the easy way.
Does anyone else run into this problem? Wondering if more experienced programmers have some wisdom to share.
I'd go the quick route first.
Write an ASPX page that is showing an article based on ID, or even cooler and more SEO-friendly, a slug. You'll be able to meet your deadline. Then, I'd start on the awesome jQuery way.
The bonus to this is that you'll have a fallback option, in case that a user has JavaScript disabled.
You're talking about "gold plating". It's a very common and well-known issue for software developers.
From the glorious founder of StackOverflow himself:
30: Developer gold-plating. Developers are fascinated by new
technology and are sometimes anxious
to try out new features of their
language or environment or to create
their own implementation of a slick
feature they saw in another
product--whether or not it's required
in their product. The effort required
to design, implement, test, document,
and support features that are not
required lengthens the schedule.
The proper way to cure this problem is to volunteer for so much work that you don't have time to do it right, let alone add on extra bells and whistles. :)
Edit: Other "classic mistakes" link here.
I think it's just a matter of setting priorities. Also, if your client, or boss doesn't want you to do things the flashy way, and you don't really have time to do it the flashy way, just do it the simple way, and come back and upgrade to flashy if you have time later. Clients and bosses are usually happier when you finish the work they gave you before moving on to making things better.
I look at how much time I have left, and if I feel I am pressed, I don't venture outside of my area of expertise. I am all for doing it correctly and elegantly, but the reality is that the majority of the time the deadline takes precedence, and I know if I stay within my comfortzone when pressed, I will most likely make fewer errors which means I save the QA people time in testing things.
That all being said, I have been known on more than one occasion to push the limits of how much can be done. If you aren't working an immense amount of overtime already, you can always make extra the time necessary for going the harder route. Yeah doing this can cause a little more work for extra people but sometimes that's the difference between having the best application or having the first loser.
My other advice is don't try and do both options. If you create a basic version stick with it and move on. If you try and do both, you're really wasting time in the end.
The right way is to have it functioning so that users can get to the information they seek. The designer way is to have it kind of working but also have javascript light things up and move around.
The best way is to get it working correctly then revise it. There shouldn't be much refactoring involved if you know where to place things. Obviously retrieving the article is going to be business/app logic and the actual fancy design (like fades/animation) will be part of the design/view aspect of the setup. These portions should be able to sit and be somewhat ignorant of what the other is doing - they shouldn't be tightly coupled.
Sounds like typical feature creep. Convince yourself that tabling a feature idea now to meet a deadline is quite different from simply dropping the feature altogether. You can come back to it months after release and put in new features.
I think you've pretty much answered your own question there. You said that adding this feature would take too much time, and you're in a time crunch and are launching next week. I think it's fairly obvious you need to go the "easy" route.
You're basically describing feature creep. http://en.wikipedia.org/wiki/Featuritis
You need to discipline yourself, what I would do in your position is document the new feature I want to add, and implement it after your out of crunch mode when you have time to work on it. You're obviously aware that adding this feature is going to cost you time and may very well set back the launch of this product, you just need to have the discipline to prioritize and stick with it.
I think every developer has this problem if he is interested in programming and isn't coding just as a way to make money in a 9 to 5 office job.
Here is my advice:
Make a list of every cool thing you think of as you're writing the code. After you have a working basic version, commit it to your source repository.
Now if you have time left go back and do as many cool things as you have time for. Use branch tags if you're going to have to seriously rework the code.
Once you run out of time, if you're doing Agile, write the leftovers up as stories and give them to your project manager or client.
I think when you say you are doing something the "right way" that implies a balance of quality with the speed you can write it in.
If you make something as high quality as possible, but never release it, it's not the "right way". On the other hand, if you write crap but get it out super fast, that's also not the "right way." To do something the "right way", you must balance these two.
An economic phrase that comes to mind is "Quality, Price, or Production Speed, pick two."
Things like this used to absolutely kill me!
Here's my advice:
Do it the easy way (the aspx with the
id parameter)
Write a small proof of
concept to show the client
Show the client the working page and the proof of concept later along with an estimate on how long it will take. The experience of designing the prototype will give you a better idea of what is involved, how to do it, and how long it will really take. The proof of concept can also inform maintainence developers what's what (fading vs logic), and allow them to issolate if the fading mechanism or logic is broken.
Personally, I would stay away from the fading thing. In my experience the client will see no added value in the fading functionality and IMHO seperating it to another page will be easier to maintain. I believe it will be less prone to bugs later since code for the 2 pages will not be intermixed onto one page (if I understood you correctly).
In test driven development approach, when you implement a feature by writing a test for it and implementing it the easiest possible way, you will be able to go back and do it "right" only when you find really need to do so. Knowing this allows you to avoid overdesign. And often, you find you won't need to after all.

How to convince a customer that what he wants is a bad thing to do? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
For instance, customers that we're creating web sites for, request things like:
all links should open in a new window
put custom 'Back' button on every
page while there is a working
browser's equivalent
make some part of the text blinking etc.
Of course I tell them it's wrong, but is there some nice list of bad things to have from a respected source that I can point them to?
Become that respected source. Seriously: if your clients are showing reluctance to take your advice directly, compose documents that illustrate good and bad user interface design and publish it on your website. You gain three things from this:
You become more knowledgeable about the why of bad and good design. Having to think through something to compose it into a document is more helpful than many give it credit for.
If this is publicly published, you probably will get feedback about your ideas. Throw away the bad suggestions and integrate the good, and you become better at your craft.
You have the source for these discussions in a presentable format, yet you retain all your personal branding. If you include examples and demos of the good and bad, most people can see why you advocate for your ideas.
EDIT: epotter is dead on as far as the "buck stops here" aspect of interacting with a client. If your documents can show why irritating a user is a loss of revenue in the long run, it is unlikely you will have much push-back. On the other hand, if your personal preferences includes UI designs that don't help with retention... stop doing that. (I recall the days of "CSS Only, No Tables" designers before CSS had matured: they insisted on forcing their designs on clients, even though in some browsers they didn't render well. While a cause is admirable, you work for the client not a cause.)
Always try and show them how it will cost them money. For example, if they are going to do something that annoys the user, they will have less traffic which will lead to less revenue.
For better or worse, dollars always speak the loudest.
First, don't tell them it's wrong.
They may take it personally.
Instead, understand the need they are trying to fill, then suggest alternatives that don't include the bad behavior. Mock all the alternatives up and point out the good and bad of each one. Let them choose. As long as you have a good alternative, and sufficiently pointed out the faults of the bad implementation, then they generally come around to your point of view.
In other words, act like a designer. When a customer says, "I want green text on a red background," you don't immediately tell them that 10% of the world's males cannot read that, you first need to understand why. "Well, it's Christmas," then you can suggest alternate themes to give the site a festive feel without the design error. As long as the mockups you suggest are better than theirs then they will generally acquiesce.
Not because they made an error, but because you saw their real need and improved on their idea.
If they're adamant after that, though, do the work - don't spend your time trying to convince them the error of their design sense, it's a waste of resources.
Educate them over the long term, but if it takes you an hour to convince them not to make a change, that's one hour you could have spent improving your relationship with customers who treat you as designers rather than web-monkeys.
-Adam
I've had to play a semi-sales role at time with web projects and I have to stress how important it is to keep the customer happy.
Nevertheless, I completely agree with you that you are obligated to say something in the name of giving them what they want. I always found that the best approach is to start by agreeing with them (in principal at least). You could say,
"I completely agree with you that this
text is very important to your users.
Many testers that I've worked with
have strongly preferred using this
font/graphic/color to call out
critical text. Unfortunately, some
users associate flashing text with ads
and avoid it"
I find that this approach lets them know that you
Understand what they want
Appreciate their motivations and suggestions
Only want to help
One last word of advice, if after the gentle nudging, they don't get the point, consider doing two quick mock-ups. (their idea and yours). If that doesn't work, then just give them what they want. In the end, they pays the bills and if they really want an ugly site (assuming you can't afford to turn away business on aesthetic grounds) just give them the site.
Good luck and take deep breaths!
Jakob Nielsen's Alertbox has been an invaluable source of common-sense usability advice for me for many years. Here's something he wrote way back in 1996 that still applies today:
The BACK feature is an absolutely
essential safety net that gives users
the confidence to navigate freely in
the knowledge that they can always get
back to firm ground. We have known
from some of the earliest studies of
user navigation behaviorthat BACK is
the second-most used navigation
feature in Web browsers (after the
simple "click on a link to follow it"
action). Thus, breaking the BACK
button is no less than a usability
catastrophe.
And here are the first two of his Top Ten Web Design Mistakes of 1999:
Breaking or Slowing Down the Back Button
The Back button is the lifeline
of the Web user and the second-most
used navigation feature (after
following hypertext links). Users
happily know that they can try
anything on the Web and always be
saved by a click or two on Back to
return them to familiar territory.
Except, of course, for those sites
that break Back by committing one of
these design sins:
opening a new browser window (see mistake #2)
using an immediate redirect: every time the user clicks Back, the
browser returns to a page that bounces the user forward to the undesired location
prevents caching such that the Back navigation requires a fresh trip
to the server; all hypertext navigation should be sub-second and
this goes double for backtracking
Opening New Browser Windows
Opening up new browser windows is like a
vacuum cleaner sales person who starts
a visit by emptying an ash tray on the
customer's carpet. Don't pollute my
screen with any more windows, thanks
(particularly since current operating
systems have miserable window
management). If I want a new window, I
will open it myself!
Designers open new browser windows on
the theory that it keeps users on
their site. But even disregarding the
user-hostile message implied in taking
over the user's machine, the strategy
is self-defeating since it disables
the Back button which is the normal
way users return to previous sites.
Users often don't notice that a new
window has opened, especially if they
are using a small monitor where the
windows are maximized to fill up the
screen. So a user who tries to return
to the origin will be confused by a
grayed out Back button.
These aren't crazy newfangled ideas, they're decade-old guidelines based on hard research. You'd need a really, really, really good excuse to repeat a decade-old mistake.
Find examples of actual pages that do this and show them. Here's a good place to find some.
If you show them the examples, and instead of being awed by the suckyness and changing their minds, the clients say, "Yeah! That's exactly what I want!", then make them sign a nondisclosure contract saying they'll never tell anyone who designed their web site. :)
You have to explain "why". It's not enough to tell them something is "wrong" (and in these cases, it's not so much "wrong" as it is a "bad idea")
Most people respond well to logic and reason. If you can make a reasoned argument for why doing something a certain way is a bad idea, they'll usually bow down to your experience and knowledge.
useit.com is an excellent resource for usability arguments
but you're probably wasting your time. Either do it their way ("the customer is always right") or walk away - arguing is unlikely to improve the situation unless you can demonstrate a significant monetary gain from not doing it their way, which you probably cannot do given the issues you listed.
if your name will be on the site, i'd politely walk away
Show them some articles on sites like http://useit.com which has some empirical studies on how adherence to web standard practices increases usability and so therefore user satisfaction and so therefore profit.
Ask them what results they're after. "Have all links open in a new window" is a statement of solution. Solutions are your job, the client's job is to state objectives.
Start with this: "Oh, you'd like links to open in a new window. Tell me more about why you want that - I'd like to explore with you whether there are alternate ways of getting the same results."
Perhaps continue with this: "Also, I might point your attention to other consequences of opening all links in a new window - consequences you might not have considered, and which perhaps you wouldn't like."
Suggested reading: Dale Emery's articles on resistance.
At the simplest, try to explain them each of it in a user understandable manner.
e.g. Blinking text is an old style thing not supported by all browsers
Not sure why "back" can be a problem. But put your viewpoint.
It's always convincing if you demonstrate to the user that his design is unconventional or wrong by showing a list of very well known websites that he would "respect" and pointing out how they don't do X. Your customer will probably want his site to be like the big players' web sites.
If he still insists that his weird design makes sense you could say: "yes, I agree that sounds like a good idea in theory, but the fact is that users are simply unaccustomed to X and would walk away from your website if it diverges too widely from the standard way of doing things".
IOW, when all else fails, use fear.
You can lead a horse to water, but you can't make it drink.
With customers (of any type), the best you can do is inform them of their choices, and why they are not the best ones and then leave it. If it's really bad, require sign-off stating that they find that design acceptable. Do you want to be 'right' or do you want to get something into the customer's hands that works?
If it completely impedes a working solution, then (and only then) should you stand on principle, but beware you have very few (if any) of these 'stands', so use them wisely. Be prepared to walk away.
Paul.
Unless there is a compelling business case NOT to do it (and I'm not sure this is the case with any of your examples) then if the customer is adamant DO IT! They are paying for it after all. They can always find someone else who will do it if you won't!

What is so evil about a Flash based website?

I have the feeling that Flash-based ( or Silverlight-based) websites are generally frowned upon, except when you are creating games or multimedia-content rich applications. Why this is so?
Flash is infamous for its poor accessibility.
Keyboard navigation does not usually work, and Flash (up until recently) did not have search engine support.
Flash applications does not work in mobile phones and other portable devices.
Flash is not there in the iPhone!!!
Flash is controlled by a single company (Adobe) and so it is not following any well defined standards for the Internet.
The beauty of Internet lies in the fact that you can always view the source code of any website you are in. This way you can use the same programming/design techniques in your website or you can find security flaws in the web application. This is not possible in Flash. In Flash, source code is closed.
The big question is, why should you use Flash "except when you are creating games or multimedia-content rich applications"?
jtyost2 says,
"I would also add that you can't directly link to any content inside of a Flash site, thus breaking one of the major factors that makes the Internet, the Internet, links."
content weight
usability
crawlability of search engine bots
accessibility
ease of use (disputable)
technology encumbrance (added software required to access the site)
security issues (needing to add software comes with issues involved with installing or running that software/player of the content)
[Edit] Why I place usability and ease of use separate is best explained in this link
Usability:
a result – software that is usable;
a process, also called user-centered design, for creating usable software;
a set of techniques, such as contextual observation and usability
testing, used to achieve that result;
or
a philosophy of designing to meet user needs?
Ease of use:
Effective
Efficient
Engaging
Error Tolerant
Easy to Learn
I agree with the comments on that site, but this is all debatable...could be a good stackoverflow question: is usability and ease of use the same? IMO part of usability is ease of use and vice versa, but they are not necessarily the same.
I hope I don't enfuriate the more semantical sensitive with this edit :-)
Interestingly everyone here blasts Flash/Silverlight and you would do well to recognise that this is only one side of the coin.
Flash (and Flex) allow web site designers significantly more flexibility and richer content for their site and this works in a variety of situations - e.g. sites relating to movies, or bands, sites for kids, sites for games etc.
Certainly, there are many reasons to not choose Flash/Flex/Silverlight, but one can do sites just as inaccessible in JavaScript these days. I have previously worked with JavaScript products that have no reasonable usability by blind people, or web crawlers.
Flash penetration (from a biased source to be sure) is 99%+ (http://www.adobe.com/products/player_census/flashplayer/version_penetration.html), which means that those that say "would never visit a Flash site" are in the 1% of the population that do no install Flash, do not watch YouTube or movie trailers online.
So, you need to be mindful of your audience. Certain audiences and situations would definitely be better off with plain HTML pages and a minimum of JavaScript (government websites, programming websites are two areas that spring to mind). Other times it is because the audience are office workers that are not allowed to install Flash in the browsers.
Rich Internet Applications (RIA) is one area where there is a distinct clash/struggle between the Flex/Silverlight and JavaScript/CSS/HTML sides. I've worked with both, and I'm now of the opinion that requiring Flex/Silverlight plug-ins is fairly reasonable, though you can still lose some visitors if the application is public.
In summary - you're best to identify your audience, identify what they're willing/able to use and then based on such limitations decide on your technology.
Flash and Silverlight based sites typically go against basic Internet conventions with their closed models.
For example, most Flash & Silverlight based sites:
Ignore the back/fwd button.
Don't allow you to send anyone a URL to a specific place on the site, or bookmark a specific spot for later via your browser
Place the internet in a fixed size box. No dynamic sizing for wider monitors or higher resolutions.
"I was about to click checkout but I wanted to change something so I hit the back button"
In this next rant s/Flash/Flash or Silverlight/g
The Flash application/plugin is a closed source pot of serious undisclosed security holes that expose private data, allow modification of arbitrary files on your hard disk, etc.
Flash files are enormous for basic content. There are more efficient ways of doing things
Flash is slow. The plugin on my Windows PC can hog 100% of the CPU time to play some shitty websites.
Flash is non-standard. There isn't a supported flash plugin installed everywhere. Linux users can't run it without jumping through package management hoops. Firefox users on Windows don't get it by default (well didn't last I checked).
Flash is annoying; your users don't want to be bombarded by animations and jingles and junk just to get some basic information.
No back/forward functions unless the Flash designer wanted to implement them in
Can't view a single page without waiting for all the content/scripts that make up that "page" to load. That's really quite painful if all your user wants is a slice of text and you force the multimedia down their throat.
Most Flash-only sites are really bad; the designers seem more concerned with using all of the features of the flash engine rather than presenting something that's concise and useful to the user.
I am a Flash developer. The firm I work for has no difficulty finding clients who want us to build Flash-based products for them. There is a certain set of applications which it is much easier to develop in Flash than in other environments I have used.
But Flash has its problems. Some above have complained that Flash apps do not include keyboard support. Others say it is because the developers are too lazy to implement it. The truth is that many of the components that come standard with Flash are buggy. At my firm we have had to write our own replacements. One feature that is problematic is keyboard support. I implemented my own support for keyboard interaction. It works well, but required effort. If I were writing a Windows VB app, the keyboard navigation would be provided and would work well out of the box.
The same is true for deep-linking, back-button support, etc. A clever developer will be able to make a Flash app behave well. Some open source libraries are indispensable here.
As for flowing layouts, I just completed a proof-of-concept for this (in AS3) as well. It is possible, but requires much effort. Why do I make the effort? Because of the other things that Flash does well.
My biggest gripe with Flash is that it takes you "out of the browser" into its own totally separate application. This breaks "browser standards" - i.e. the functions I can do in my browser:
Right click
Middle click (for opening links in other tabs)
Selecting text
Copy & paste
Printing
Keyboard shortcuts (since Flash steals keyboard focus)
Back/Forward buttons and the whole "page" concept
Javascript interaction with other elements on the page (I don't think this is possible).
"Inspect element" in Firebug or Chrome, if I wanted to see the source of a particular part of the Flash file, or find the image being used.
Flash has its uses. It's good for content, not webpages.
Printing is often poorly supported and the backbutton does not work.
I think it's a matter of selecting the lowest cost medium to reach your target audience,
be it Flash or Silverlight or JavaScript or plain text.
You can have text-only, JavaScript-only, etc. versions of your site if you have the
money, and your target audience come with different prioritizes.
So my question to you would be: does your website has people who frown on Flash as its target audience? If yes, you need to stay away from it. If not, use anything to give your
visitors a good experience.
SEO is the prime issue. Still Flash is not crawlable. But Adobe is working on it.http://www.adobe.com/devnet/flashplayer/articles/swf_searchability.html for better swf indexing.
Does anybody know a site called YouTube? It wouldn't exist without flash. Flash has great video/multimedia capabilities that simply cannot be ignored.
Flash is amazing when used in the proper way, in appropriate circumstances and when the designer/coder has taken care to embed basic accessibility features.
The thing is, like all good things, there's a lot of abusive use (flashturbation). Especially in the beginning, when people just want to slap Flash wherever they can just to show off.
But I strongly disagree that Flash sites are bad: When made properly, and with good UI design and accessibility, they bring a whole new dimension to the web.
See Steve Jobs' Thoughts on Flash: http://www.apple.com/hotnews/thoughts-on-flash/
Let us not forget that Flash allows web sites to display video, animation, user interaction, etc., and it allows this to be a simple process or a geeky techie one, depending on what you want to do. Many bad Flash sites are down to the author.
If YOU don't like Flash then the answer is simple, don't use it. Don't install the Flash plug-in, or install a browser plug-in such as Flashblock on Firefox. This replaces any Flash movie with a play button, preventing and download until it is clicked.
Better than that though, if you don't like the solution that Adobe or Microsoft are giving you, then come up with a better one, or at least let them know what you don't like, they do take feedback seriously. Support some of the people who campaign for accessibility improvements in Flash, for example visit http://niquimerret.com.
Accessibility is an ongoing issue and not one that will go away, Flash accessibility is improving for people with physical disabilities. In in some cases the use of Flash enhances the experience for people with cognitive and learning disabilities, when an concept or idea is better explained when presented as an animation rather than a page of words and static images.
Flash adds another heavyweight component that's required to properly view a web page. The flash plugins are often buggy and can crash a browser. Flash pages often are used to make cutesy animations and other things that make it harder to quickly navigate a site.
All of the above is true for the wild wild web.
However, for internal business applications, Flash and Silverlight allow the user to have something close to a fully-fledged application in their browser. Accessibility, SEO, and closed source are not very important in an internal application. All that matters is making the user's life easier.
I dislike Flash based websites because what happens if your browser crash or your connection dies for a bit? You have to load it again and go back to the menu, and select the item you wanted to read about, and so on and so forth.
Just don't do it. :S
I don't install Flash on my browsers, mainly to escape the nuisance of animated ads, but also for all the security and privacy reasons mentioned by others.
So sites done completely in Flash are nonexistent as far as I'm concerned. (W.r.t. Youtube, I download videos directly into Miro.)
Probably for the same reason C programmers shied away from Win32 API, Win32 programmers from MFC and MFC programmers from Windows Forms. It's tricky to use and understand - I have tried programming in Flex and am getting along pretty well but it is not inherently designed for typical web application design e.g. there is no native (at least until Flex 3) support for databases or cookies or sessions - you need to put all 3 in PHP or another server-side page and call that from ActionScript.
Try making a simple register/login page with PHP and then again with Flex/Flash and you will see that all the server side crunching is done by someone else - again, this is probably by design since we have HTML/JavaScript for the front-end mixed with ColdFusion or PHP etc. for back-end in "traditional" web applications.
Like started by other people, Flash is bad with the keyboard - try pressing Ctrl-T in Firefox when a Flash object embedded in an HTML page has focus (mouse-over) - so that can be frustrating for the user...
Having said all that, I would still rather make a web application front-end in Flash/Flex than HTML/JavaScript/CSS since the latter needs a sharp learning curve that gets quite bewildering after a while since you have to account for the "good" design aspects of CSS and JavaScript and the bad ones too - and also the peccadilloes that JavaScript/CSS inherently have and those which are introduced by the JavaScript library vendor (Yahoo's YUI, Google's Ajax API, script.aculo.us, etc.
If you are already a web programmer who knows CSS/HTML/JavaScript very well and have a good development environment set up on your PC with all required code inspectors and runtime debuggers etc. etc. then it's easy to keep on working in that (not taking into account end-user preferences) but if you are like me and want to make a web application ready and available for use quickly and want to add features to it quickly while making it pretty all the time, then Flash/Flex is a better option, IMHO.
I am a Flash developer.. and I have found that although Flash requires more effort in coding, the potential is enormous. You can create very simple sites with simple transitions, so subtle it would seem to be a normal HTML page, while still being just as light.
At the same time, you can use OOP with ActionScript to create a website that is as complex and as inclusive, as well as feels and acts like a desktop application. WHILE ALSO REMAINING VERY LIGHT! (only the content required is loaded on demand, as apposed to 4 column HTML sites with far too much information.)
Nowadays, and this is still without migrating to ActionScript 3, but still using ActionScript 2, MY flash files contain simply 2 or 3 lines of ActionScript, only one frame, and an empty stage. Everything else is dynamically created or added at runtime.
Flash's problems are not about Flash, but about lazy development.
In its defence, most of the issues raised here about how people have implemented Flash in their websites, not about Flash itself. Flash does support accessibility it's just that most people don't consider it when building their sites. Flash does work on mobile phones - it's Flash Lite, although the ActionScript is limited in earlier versions.
Why should anyone have an automatic right to view the source code of a website?
A web author has spent time and effort dreaming up their code to share their ideas through the medium of the web. If you want to know how something works, why not put a bit of effort in yourself, and work it out? The beauty of the web is the message, not the medium.
So what if Flash is owned by a single company - Adobe bought it for a reason, and that's because it's a fantastic bit of kit. The problem comes from web authors not using it properly, trying to make it do things it was never intended to, or simply not applying standards to their sites when developing using Flash.
What is so evil about a Flash based website? Absolutely nothing.
It's like asking what is so evil about a gun. Nothing. It's the idiot wielding it that has the problem.
Flash sucks and I refuse to visit Flash-based web sites. Why? Because I can't. Why? Because Adobe is too ignorant to write a plugin for a 64-bit browser.
Look at any major car maker's website, they are ALL in Flash. It depends on what you are doing. If your goal is to provide a rich, sexy website Flash/Silverlight will give you a huge advantage in terms of development time. IF you are providing content/data HTML and JavaScript (jQuery for example) can give you a lot of whizbang without requiring additional software plug-ins (Flash/Silverlight).
Flash Player is the culprit behind more Mac OS X crashes than anything else. It's not exactly well-known for its stability.
All the above answers are focusing on Flash, Silverlight is just as bad or worse. If you are running Firefox with NoScript (you should be) then you have to click on every script that you wish to allow to run.
So build your websites with scripts, Flash and Silverlight. Just make sure that they still work with them disabled. Many of us will simply move on when we open a site and see nothing.
Many of us have had bad experiences with Flash based websites which has propagated the idea that flash is "evil". I don't really think it's fair to apply the label of evil to any technology or framework, they are each designed to cater to specific scenarios and many of them do well in those scenarios, for example, I have no problem with websites that use flash video.
A few other responses have touched on the fact that the use of flash contradicts many of the standard metaphors we use on the internet (e.g. links and navigation buttons), I hate this as much as the next web user but this doesn't really make flash evil either.
While it has been said that there are mechanisms within Flash/Flex to add support for these things, in my experience these are rarely implemented, which is not directly the fault of Flash per se, but is very annoying for the user.
Perhaps the evil is not Flash/Flex but Adobe for not making many of these things easier or more visible to developers.
For the record I have never developed in Flash
Flash isn't evil, it's what people do with it that's evil.
For goofy vector animations and maybe even for example a 360 product view or interactive diagram, yes. Flash can do beautiful Full HD animation on my ancient box # 60 fps using ~15 % cpu.
For web video, if you have no other choice, I suppose.
But for entire websites and these things called 'RIA's, no.
So shockingly a technology works better for the thing that it was designed to do.
Flash is one more stuff to learn in web development. No thanks!
There are just too many already. If I can do my job without it, I don't need it.
Programming is being paid less every day.