This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Ethical Dilemma: Should I still cater for IE6 as a web-developer.
5% of IE users last month use IE6. So I am curious if people think I should support it....because I haven't been.
http://www.w3schools.com/browsers/browsers_explorer.asp
I wouldn't..Its not worth your time and effort for 5%.
What is your product or service?
What percentage of conversions come
from that 5% of ie users?
What percentage would come from
those users if your site had
better support for their
browser?
If you answer those questions, you won't have to ask anybody else whether you should support IE6 for your site or not.
No. But someone is going to say you will lose customers if you don't.
It's time for IE6 to die, already. Those of you who are still using tube monitors and abacuses, please give us a break and come into the 21st century.
As Bobince points out in his comment above, it's unrealistic to put a coat of wax on a VW Beetle, and expect it to look more like a Porsche.
Businesses tend to keep IE6 on as legacy applications might only support IE6 so you tend to find they are in no hurry to roll out newer versions of IE as they would have to update in-house applications.
Probably not, but if your consumers consist of people that use old browsers, it might be a good idea.
It's not that they're 5% of your user base, they're 5% of your IE user base. In otherwords, IE6 accounts for 5% of 30% of your traffic.
I would say no, because you'd be sacrificing too much time and features for too few people. That and big websites like youtube and firefox have dropped support already.
IE6 users are almost exclusively corporate users whose update schedule is mandated by the corp. If your userbase is the general public then that 5% figure will be much lower and as such I dont think supporting IE6 is worthwhile.
Related
Is it really worth chasing a 100% score on Google PageSpeed Insights at the sacrifice of the best User Experience?
Some of the opportunities suggested create a poorer experience, so is it really worth it?
Is it really worth chasing a 100% score on Google PageSpeed Insights at the sacrifice of the best User Experience?
NEVER sacrifice user experience in the pursuit of speed and performance.
Speed is important but how people interact with your site is far more important, especially if you are spending money driving people to your site.
With that being said your second point is completely false....
Some of the opportunities suggested create a poorer experience, so is it really worth it?
There is not one suggestion in PSI that will negatively affect user experience.
This shows that either you didn't understand a point or that you have implemented a fix incorrectly. (they are not that well explained to be fair)
If there are particular points you are struggling with then please post a separate question, I will happily guide you.
Speed has been proven again and again to improve conversions, with every second being worth around 10% in conversion rate improvement (or every 0.1 second being worth a 1% increase in conversions).
When to not chase 100% score on PSI
The actually reason to not chase perfection is time and resources, coupled with diminishing returns.
To get a site to 80 / 100 is normally an easy process.
To get from 80 to 90 takes a reasonable amount of work.
To get from 90 to 100 normally means designing the site from the ground up to be lightweight and involves all sorts of tricks such as inlining critical CSS.
Let time and effort guide you, there is no real benefit of trying to push for 100% unless you are turning over a significant amount of money (£1 million+) as the conversion rate increase is not proportional to time spent and cost.
On my site (https://klu.io) I had already designed it to be lightweight from the start and it still took me nearly a day to optimise all the SVGs, set up automatic CSS inlining for critical content etc. etc.
I will be the first to say that extra day effort was not worth it, other than to 'show off' to clients that I can get sites to 100, I never take a client site to that extreme as it does not provide any financial benefit and I would recommend the same to you, aim for 85 and above and you will have a high performance website fit for 99% of needs.
Have we finally got to the point where we assume CSS2, and hope for CSS3?
(Not looking for discussion, if the answer is "yes, you idiot", go for it...)
You should always take into consideration users who
A. use screen readers and text-only browsers
B. are on mobile devices
C. are not human (i.e. search engine spiders)
By having a good separation of content and style, you should be able to address each of these with ease. As far as users who have CSS disabled, in this day and age, I don't think a designer should concern themselves over it too much. It's certainly not worth spending a significant amount of time and resources on.
What is your target audience and what is your cost for supporting (or not supporting) certain clients?
In addition to the fine points made by pst and ttreat31, I'll add that using semantic markup will generally let your document be readable with CSS disabled (i.e. using the browser's default CSS).
There may be a few quirks (forms come to mind), but generally I find with my own pages, they are plenty readable.
You, and your business, will probably survive if you require CSS. But you'll probably do better if you DON'T require it.
By catering for non-CSS cases, you'll write better markup, with better-structured content. You'll mitigate cross-browser problems, and develop a more robust API. Search engines will be able to parse and 'understand' your content that much better.
Allowing for 'no CSS' is much more about the philosophies relating to web standards and good coding practises than it is actually about the common final rendering.
I don't take any effort to help users who disable CSS or javascript. If I worked on a site which counted on attracting new customers and had lots of first time hits, then I would probably try and give non-javascript users a scaled down set of features. But I would never bother with users who disable CSS. I think that is probably a very small minority.
I often surf in the terminal using links or lynx when my computer is overloaded and I just can't have Firefox, Java, and some Flash applications taking half of my RAM. Text-only browsers don't have advanced CSS or Javascript support.
Many server administrators might do similar thing as most servers are headless, and some administrator might be too lazy to open their other laptop just for a quick browse. People using screenreaders usually have similar view as text-only browser, except it's now read aurally instead of text-only.
When using text browsers, I wouldn't expect any fancies colors or tables, usually I just need to have some quick information. So, IMO, you should at least make all the page's essential information available as plain HTML.
I'm working on a web development project usng PNG transparency, CSS3 and all the other goodies you would come to expect in a "new" web design. IE8 and Firefox look great, IE7 is passable and IE6 looks like the dog coughed it up.
With Windows 7 out in the wild (If you have to dual boot... do it in style :P) and Internet Explorer 6 down to a pitiful 11% market share, has anyone made the decision to ignore it?
Granted, I've still made the effort to make IE6 usable - but how far should I take it (how far have you)? Is anyone else working on a project where they've given the finger to this ancient design massacring nightmare?
browser stats: http://www.w3schools.com/browsers/browsers_stats.asp
I still try to make my interfaces usable in IE6, but I don't spend the time to make them look perfect, or even decent. For my projects, it's just not worth the effort. People and companies with IE6 need to upgrade, period.
Edit: Semi-random addition: I just saw this graph of web usage mentioned on Slashdot, which puts IE6 at 14% of all users. At least it's going down!
I personally tend to try to make my stuff usable even in Lynx. In general, if you start with that in mind, it's pretty easy at least to have it degrade gracefully.
This can only be answered by determining the audience for your web site. If you already have a version of your site running, look at the logs to determine how many people use IE6 and visit your site. Then you can make the decision on whether you're going to support those users anymore, and whether you're going to make the site work well or just well enough to be usable by those users.
11% is still one in ten users.
Much depends on what you're creating. If you're creating an intranet site where you know that most users should have made it beyond IE6, then go right ahead.
Me, I'd stick with IE6 for the time being for public sites, at least until the percentage drops below 2% or so. But this is really a question for the site owner: are you willing to look ugly for one in ten of your users?
Note, for web design questions of this kind, try doctype.com. For browser compatibility, try Litmus.
IMHO it's not just a matter of how many people are using IE6, it's a matter of why they're using it. If 11% of people were using IE6 because they really liked IE6 and Ie6 had a chance of gaining popularity as time went on, I'd say they should be considered. However, given that probably 99% of people using IE6 are using it purely because of inertia and it's getting less popular every day, I don't think it matters too much. If anything, the fact that your website looks like crap in IE6 will encourage them to upgrade.
That said, I think your page should probably explain to the relatively computer illiterate why it looks like crap and that IE6 his a browser from the caveman era and they should upgrade.
What does the PNG transparency and CSS3 give you, that can't be done with older technologies?
It might be fun to try the most recent technologies, but you shouldn't throw out one in ten of your customers.
I'm still dealing with IE6.
jQuery has helped.
As has graceful degredation. I use CSS3 now and don't care too much if some things just won't appear in IE6.
For PNGs, Twinhelix has a nice script that does quite a bit for PNG transparency support in IE6:
http://www.twinhelix.com/css/iepngfix/
Or, alternatively, I use PNG-8s. Not ideal, but really easy.
The only major beef I still have is IE6's lack of double class selectors:
.class1.class2
I could de-bloat my CSS quite a bit of IE6 supported that.
I've been saying this for 3 years now - if you're trying to make things look nice for somebody using IE6, you're wasting your time. People using IE6 are not savvy enough (and depending on what you're doing, are they even your target audience?) to notice or care about the PNG transparency or anything. If they are savvy and they are stuck on IE6 b/c they are at work or something... really, who cares? They probably don't, it's probably just another reason for them to curse their stupid IT department. Not your problem.
Sure, make sure your site WORKS in IE6, but it doesn't have to look nice.
yes, I do, as does Google and Yahoo!.
yes, it sucks, but the numbers are still there (with us it's about 30 - 40% of users still using IE6)
I say join the cause to get IE6 out by choosing not to support it! ^^
But as some others have pointed out, it depends on the target audience, and if you can afford to cut the IE6 users out.
If you have a lot of corporate clients, like my company, absolutely yes. Big companies standardize on a browser and they don't move off it easily. And often there are enterprise-level systems that depend on a certain browser version, like IE6.
If you design in flash, you'll get cross browser compliance.
I personally loathe background music on a website. My client has opposite feelings on the subject. I added music because the customer is always right, though I'd like to revisit the subject with them.
Almost everyone would agree that it is annoying and wastes precious bandwidth but are there any usability studies or a recommendation for someone esteemed in the profession that can provide a valid argument against background music?
Usability is not the only concern. Consider the following scenarios:
1 - Someone browses to the site while at work in a shared office, and now all of their co-workers think "Gee, he's wasting time".
2 - Someone browses to the site while in a room with a sleeping baby, and now they have to spend an hour getting him/her back to sleep.
3 - Someone browses to the site while they are listening to their own music, and now they hear a cacaphony of shrieks until one source is muted.
Also, consider that any benefit gained from the music on your website will be totally lost on anyone who has their speakers muted. So your audience can be divided between:
A - People who cannot hear the music
B - People who can hear it, but do not like it
C - People who can hear it, and do like it
I would not care to estimate the percentages associated with each of these groups, but keep in mind that category "B" is actively offended by your website. To take a line from the hippocratic oath, one rule of web design should be "do no harm".
Metrics. You'll never be able to convince a business person with an emotional answer.
If you investigate the situation empirically you'll be able to give them something irrefutable.
I would would try an experiment: (get google analytics)
have one site with the music as-is, measure the bounce rate,etc
have an identical site without music, measure the bounce rate,etc
Have the server randomly serve up the different pages for a couple weeks (until you get a significant data) and see what happens.
Maybe we're wrong (I hate music too). I hope your customer is wrong, but who knows.
You could also add a survey link and try to get people to answer that as well (but without an incentive that might not work)
Stats can be your friend here :)
I would also:
(calculate the size of the audio file(s)*the number of hits*months)/cost of GB per month
Then tell them how much money they are wasting.
Basically, it boils down to this:
Audio on websites is a bad idea. No one likes it.
Try to educate your client that it is a bad idea. (It's annoying, different levels of sound can cause problems, yadda yadda) Mention that most users don't take sites seriously if they use sound. It's a very '99 thing to do.
If you client does not budge, (politely) remind him/her that they are paying you for your expertise as an internet professional. You are the expert on the web, and they have hired you to give your expertise.
If they still won't budge, keep the sound and make sure they are happy. The bottom line is keeping the client happy.
Music also interferes with screen reader users. I'm a blind computer user and nothing annoys me more then having music start playing and drowned out my speech program that's trying to read the site. Nothing will make me close a website quicker then unwanted audio.
It took a bit but I found a site that talks about usability on web sites.
They have a video on the right hand side of this page:
http://www.ciaromano.com/evaluating/testing.php
It shows why audio ads are not a good idea on websites.
Hope this helps.
G-Man
Just make sure that there is a way to turn it off. It really depends on the type of Website, because multimedia-heavy sites (i.e. sites for Movies or Games) can benefit from it, but if I'm listening to some of my own music, I definitely want a way to turn it off.
Oh and please, no crappy MIDI-Files that people already hated in 1993 when they were novel.
This is a tough one -- and what's amazing is that at the moment, I have a client who's demanding the exact same thing.
Personally I don't know of any usability studies addressing this topic specifically, but there's plenty of anecdotal evidence out there from users complaining about the intrusiveness or outright corniness of unrequested background music. * That said, clients still ask for it. Best you can do is try to explain the situation to them, try to gather a few good examples of people complaining about it from the Web at large, build a case, and hope the client goes for it.
In my case, she completely agrees that it's potentially annoying, understands it cuts against the grain of user expectations and politeness, but wants it anyway. So I'm building it. Whaddyagonnado.
* Indeed, you could probably use this thread as evidence! Good luck.
Consider taking a different path with the client.
Ask them what the purpose for the music is...
If it is to install a particular feeling or mood with the visitor of the site, consider taking them through all the points mentioned in answers here and discuss how that may violate the intended for the music.
Then you will be able to talk to the client about different ways to instill the same "ambience" to the website without resorting to music. This is really a design issue and not usability.
If the background music/sound was to convey some information, then it is a usability issue as people who for technological or biological reasons cannot hear the sound at the correct volume will miss out on that. Therefore the site is not as usable as it should be.
Unfortunately, as a service provider of sorts, all we can do is cringe and give the customer what they want - after documenting your disapproval both commented in the code and in writing to the client, of course.
Pardon me, but i have a different opinion about loading music in the website. With all due respect I have for the answer posters of this thread.
I see visits to e-commerce websites like going to a shopping complex. Where you have a cart, varieties of products, checkout counters and background music to make your stay as comfortable and interesting as possible.
There's a whole psychological reason as to what certain slow paced music can do to certain parts of the brain. Some studies even suggested that certain music play a role in motivating customers to purchase more items. Check this site
This can definitely be a plus point in a website. Of course it depends on what kind of website it is. However, a slow and non-vocal music shouldn't necessarily disrupt one's attention; rather it might have the opposite effect.
My justification is that when a potential customer visits a site, he is only using one of his senses while browsing through the pages. His eyes! I'm saying why not allow him (if he wants) to use his sense of hearing that would encourage him (not only through the means of displaying fancy texts, design and animations that looks nice to the eyes) but also to capture his attention through music (allowing him to be more in touch with the site).
Its obviously not possible to trigger his sense of smell and taste. But why limit it to only the eyes. Why not use the ears too!
Whether you choose to put music into your site or not, MichaelStum's post about having an option to turn off the music is highly essential.
Of course in the end its all about the amount of traffic that comes to your website. For this matter, #Cbrulak's idea of using Google Analytics would be a realistic approach for different individuals.
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 5 years ago.
Improve this question
I'm not a great fan of duplicating effort. I do find, however, that there are benefits to tracking agile iteration progress on both a physical card wall and an online "calculator" (Excel, some scrum tools) or an online card wall (e.g. Mingle).
I find that a physical card wall in the team space provides a visceral kind of connection to the status of the cards... and that moving a card physically when you finish something provides a level of satisfaction that can't be duplicated online. I can feel the card... and people can see me walk up to the wall to move something.
Online tools provide great capabilities to share remotely and to calculate progress (e.g. in Mingle, you can use the built-in tools to automatically calculate burn-ups or burn-downs from the real data, saving lots of administrative time in doing those things manually).
I'm curious if agile practitioners maintain two tracking media like I do, and how do you present the benefits of the physical wall to those who say "I can do it online... why would I want to do it on a card wall instead?".
I feel the same. There is something very psychologically satisfying in moving a physical card around on a wall. Thinking managerially, we like stats and we like them to be automated as much as possible.
Perhaps you can keep both? Use the physical wall as the main daily source of information your team work from. Then, assign one person (e.g. the scrum master) to take down the live status and put it into Mingle/Excel at the end of each day.
As long as there is good benefit for the users to have both, then you should find both keep happening alongside each other nicely. Find out what the motivators are for each tool. For example:
Physical wall:
Instant reaction
Quick visual
Physical satisfaction
Online records:
Really really useful statistics
People can be rewarded against the stats in there (e.g. points completed)
Hope this helps.
My team has struggled with this as well. Electronic data makes analysis and reporting very easy and enables associations of checkins with a backlog item, but its a lot easier to manage cards during the standup. Plus, it's a lot easier to get a "5000 foot view" of the project from looking at a large wall than a small monitor.
No matter what you do you're either either going to have some duplicate effort, or you're going to have a process with some pain points. The goal is to find that balance between the amount of duplicate effort and the value that it affords.
We're still working on finding that balance :) Here's what we do:
During planning, we throw everything into OneNote. Formatting is a bit of a pain, but we're getting better.
After planning, our ScrumMaster enters the data from OneNote into an Excel document for generating our burndown. He then exports this data into TFS, for associating checkins, and does a mail-merge to print each task on a label which is then affixed to a post-it and added to the wall.
During the standup we move the post-its around on the wall.
After the standup, the ScrumMaster updates the Excel doc, generates the burndown update, and sends it around to the team.
As a team member this is pretty low-friction, but it's pretty wasteful of the ScrumMaster's time.
I greatly prefer Cards on the wall for a few simple reasons:
Everyone know how to use them. No software training required.
Not subject to problems with network, someone's computer needing maintenance etc., even in a blackout, people can still update their cards. This may sound like a joke, but can be nice to have something to do when for whatever reason yu can not use your PC
Programmers can freely update the cards while they are booting up/compiling
Easy to see them all at a glance
Ideal for meeting if your in a scrum environment and having amini meeting aroudn a desk.
I like jotting a note on the card when it's moved with time and mover... for trakcing bugs/features.
Cross link your online and card wall.
Set up two way replication. Method is left as an exercise for the student.
Also handy to catch whiteboard content from discussions.
We use both, and I can't imagine doing it any other way. Part of it may be that we find our "online card wall" a little too clunky to easily maneuver, but we use the physical cards for getting a quick idea of what developers are working on, letting QA know which cards are ready for testing, and for QA to post what is ready for our weekly demos. The dev area, QA area, and ready to demo areas are three physically distinct places, with the ready to demo being most easily accessed. We also use the physical cards for final scoring.
Could we do all of this online? Yes, would it be quicker, and easier? No way!
We've abandoned using cards after the sprint planning session (they get added to Rally) because it doesn't make sense for us to track in multiple places. Our scrum master is accountable for making sure people enter their tasks appropriately and move them (that's what the daily standup is for). The 5000 foot view is much better in an online tool than a bunch of cards on a wall that can only be categorized two-dimensionally (or maybe three if you stack enough on top of each other).
We use both a card wall and ProjectCards. It's painful for me because I sync the two of them, but it's worth it to have the feedback for the team that is local.
We've bandied about the idea of getting a large touch screen, but I still would rather have physical cards. The other idea I've been toying around with is having a printer which will automatically print out an index card whenever a story is added to ProjectCards.
I was just wondering. How about a giant projector based touch wall. ;)
Best of both worlds. This might give some pointers.
http://johnnylee.net/projects/wii/
Theres something very good about a big wall everyone can always see. I think we need a way to print onto regular thick index cards but I've had no luck so it is duplicated effort at the moment.
Electronic Card Wall Using RFID, this allows you to use a physical wall, with data mastered in software of your choice. As you move cards around, software updates accordingly.
If you use JIRA. http://wallsync.net will keep your cards in sync for you...