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.
Related
I have a quick question and It might not be the right place the ask it but I hope someone can help me becuase im curious.
I'm creating a one-page website whit a lot of style (isnt designed webfriendly and uses a lot of images) this isnt a big problem because we believe we're aiming at a more design branche who most likely have kind of good pcs with a pretty ok connection to the internet and the site is sized down a lot of mobile.
But still I wonder what people recommend. my site is currently 2.2mb on loading (is there a website where you can check this btw? I just made a guess by calculating the file sizes of images etc.) I can still optimize a lot but I think going under 1mb is being a hard task. is this good enough or is there anyway who has experienced it isnt?
thanx in advance
You shouldn't worry about the size of your website (especially since you know your target audience) if the user experience doesn't suffer. However, you should optimize everything you can without sacrificing the design. Google's Page Speed might help you a lot. They even have the total size calculator you wanted. There are tons of similar tools available online as well.
Also, read this about last year's website size trends: http://www.theglobeandmail.com/technology/tech-news/bloated-web-pages-costly-for-smartphone-users/article9355125/
According to the website HTTP Archive, which regularly studies the top 10,000 most-visited sites online, the average web page now weighs in at about 1.3 megabytes, up about 35 per cent in the last year.
UPDATE
Inspired by #pwdst's comments, I'd like to add that if you want support for mobiles, tablets, etc... there's no need to sacrifice the look of the main site - you can use media queries and practically serve a different presenation to those users. Of course, you can go even further and make a different website for them (usually a subdomain).
If you use dev tools, for example in Chrome, you can see the number of requests and total transferred data under the "Network" tab. To accurately replicate the experience of your users, you should do this with an empty cache - "Incognito" or "Private" tabs can be a great way to do this in most browsers. It's also worth remembering that the experience when testing locally will be drastically different from that when the effects of latency and upstream bandwidth come into play.
Be extremely careful about assumptions regarding users if you want to maintain usability. "Good enough" is extremely contextual, it may be "good enough" for a user on a desktop, laptop or premium tablet on a solid DSL connection - but anything but on a Edge or 3G connection on a phone. Wherever possible assumptions should be backed up by analysis of user agent strings from server logs, or from analytics software such as Google Analytics. It's also worth remembering that you may have relatively few mobile or tablet requests, not because mobile or tablet users don't want to visit the website - or choose to visit using another device, but because it is difficult, slow or even impossible to use on their device of choice. This case study from an engineer at YouTube illustrates how customers were being completely excluded from the site.
In general the page should be as small as possible, and you may want to look at lazy loading in addition to optimisations, which will help initial rendering time - in fairness though your estimated size is not much larger than the internet archive average page weight of 1681kB as at January 15th this year. Don't forget that other resources can also use a lot of space - JavaScript makes up 274kB of that average - and it's not clear if you have factored that into your estimate. Aggressive use of caching will help return visitors and minimise the data transfer required in these circumstances.
I always try to consider if you can justify the page weight cost against functionality. What is the objective of visitors to your site? Does the added functionality or imagery help this sufficiently to justify the performance cost. Many performance orientated developers are now actively setting a page weight budget but this is harder for single page apps where you cannot be as granular with resources.
I would recommend using Image Pre-loading which can help your page loading times, even when its large.
I'm trying to find out what's the worst case scenario, damage or repercussions of embedding an image from an ambiguous third party website from a security point of view. In specific, what technical access does the 3rd party gain to exploit?
For example, a user posts an image URL and then the image is directly embedded like so on a website:
<img src="http://www.site-thats-not-mine.com/image.jpg">
I understand that the image could be malicious, or even that it's not really an image, but what's the worst that they can do due to this? It's not like it's an uncommon practice either.
Generally, the worst it can do is track the end user. Any headers sent along with the request for the image can be used to keep a database on end users of the image. Another bad thing it can do is change -- it could lead to a broken image on your site if the image is removed or if the server goes down; and if the image is replaced with something else, it could lead to similar problems (even possible legal issues -- for example, if the image is maliciously replaced with the intention of deceiving end users of your site).
There are also browser exploits to consider, but those are not the general problems.
For example image file can be crafted in special way to exploit bugs in browser or image libraries to hack visitor machine.
Other possible things that could go wrong - remote site is down or image is gone. Or instead of lovely flower images your site will one day start displaying bestiality p0rn... It's better to serve own content :)
The worst thing that could happen?
I'd say: the universe could implode. (though I am not sure if that would be such a bad thing...)
No, that is mean in a serious though somewhat exaggerated way: since it is impossible to know all possible exploits that do exist or might be developed it is formally impossible to limit the worst possible outcome of a missuse. Such a question cannot be answered seriously. You might want to re-think your question instead.
I just checked out chromium's source, but I desperately need to learn how to navigate around this monster.
How would I search for parts of the code that implement behavior/features I'm interested in?
Let's say I want to see what happens after a URL is entered into the address bar. How do I find that piece of code?
Or, that I want to see what happens when, while parsing HTML, a certain tag is reached.
I have before me a huge amount of source code, and no skill of navigating around it. How do I learn that skill?
My recommendation for sort of diving in is to take a look at the source for http://code.google.com/p/chromiumembedded/.
It's sort of the condensed version of Chrome and if you look at the files it specifically uses, either ones included in its source tree, or files included therein from the Chromium repo at large. The Chromium code base is a huge amount of stuff, most of which isn't actually in the browser. There's a ton of pulled in code from third party repos which are then boiled down in the build process or Chromium's implementation is located somewhere else in the tree, there's a lot of side projects that (while interesting and an awesome resource for a wide breadth of stuff) will prevent you from achieving your goal of specifically honing in on the browser implementation and how that fits together.
CEF is great because you can see someone who's already done the process of pulling all that stuff together to build a project very specifically scoped at the browser view and nothing else. You can see which parts are primarily derived from webkit easily, you can see where the crossover comes in with Google's implementations, and you can see pretty easily how V8 gets tossed into the mix.
I do say "easily" in relative terms because we're still talking a huge amount of code overall. CEF will put you smack in the center of the requirements, but that stuff is still pulling in the massive amount of various things from the rest of the tree. Compiling it takes me about an hour on a really good computer with 12 gigs of ram and 8 cores, and the generated files take up like 6-10 gigs depending.
At the very least, there's not going to be any sort of quick jump into the shallow end to pick something here or there piecemeal. Browsers are incredibly complex pieces of engineering necessarily, because they have to subsume such a huge amount of individual pieces of functionality and then combine them into a shared context. You may find the one thing you're looking for, but you'll find that it's part of a class library that likely is composed of dozens or hundreds of files, which in turn relies on a hundred more of these libraries to handle each task, so to really take something away you'll have to commit time to taking in a lot more than any given piece of information.
Edit: oh also as your specific example.
src is root http://src.chromium.org/viewvc/chrome/trunk/src
/chrome http://src.chromium.org/viewvc/chrome/trunk/src/chrome
The "chrome" tree largely contains the direct implementations (a lot of stuff isn't in there though, most of it even, but that's the starting point). This has overlap with chromeos (chromeos is kind of chromium browser taken to a crazy extreme)
/chrome/browser http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/
Is getting you to close to where you want to be. You start to see specific references to things that you can match to the browser, like the tabs and whatnot (ignoring the giant elephant of the actual browser implementation itself which is what takes up the majority of the mindspace in all this stuff)
/chrome/browser/ui http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/
Brings you to where most of the ui code is for the browser. It can be confusing when there's crossover or when stuff migrates, like there's a "ui" in the root src directory which has some crossover.
And finally http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/omnibox/
Which has a surprisingly small amount of code in it. But this is what you find a lot. The code here is an implementation of a number of classes that are built up elsewhere. For non-webview gui component you'll find them mostly pointing back to the root "ui" and the native widgets stuff there, which is where the bulk of the actual event handling code is if I remember correctly.
You can try this... it may actually lead somewhere too :-)
http://aaronboodman-com-v1.blogspot.com/2010/10/wherein-i-help-you-get-good-job.html
Reading through the dev forums may help too...
http://groups.google.com/a/chromium.org/group/chromium-dev/topics
Also, this section has a lot of useful documents, such as style guides, etc.
http://dev.chromium.org/developers/contributing-code
Last, but not least, IRC is your friend...
http://dev.chromium.org/developers/irc
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.
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!