One of the things you can't get away from when working for a browser vendor, unless you live in an unwired cave (which would make it difficult to work), and even if we occasionally do wonder about the accuracy, is usage statistics for your product.
I have an impression that some allow these statistics to guide their web site development, but I believe that relying overly much on such statistics when developing a web site can turn out to cause problems for the web site, not just for the web site's public image, but it could also be economically costly.
This article present what I think the problems are and why, and in general terms how to avoid them. …
On desktop, for which most of the statistics is gathered and presented (the situation is probably different on other platforms), we have over the past 10 years seen one dominant product being replaced by another even more dominant product; as well as a number of small players such as Opera, fighting to get a share.
Of course, for small vendors like Opera, usage statistics can become a handicap due to many Webmaster's tendency to code for the most frequently used browser first; then modify the code to fit the second and never getting around to the third. They think it will "cost too much", some even going to the extreme of blocking the ones they do not "support" (read: do not test).
I suspect that this method of development is based on two primary, but unquestioned assumptions:
- The assumption that designing for selected browsers will cost less than designing for all browsers
- That the alleged extra cost of designing for all browsers cannot be recouped by increased sales to the users of the alternate browsers.
Are these assumptions really based on fact? I don't know, but my belief is that they aren't. However, I am not aware if anyone's proven them one way or another based on actual data.
What do I think a full investigation of these unquestioned assumptions, for example by economy and marketing researchers and presented at a conference like WWW 2008, would turn up?
Firstly, I believe that it would be less expensive designing for the established standards first, then adding work-arounds for things that do not work in specific and frequently used (old) browser versions, and submit bug reports to the vendor when necesary.
The reason it is probably more expensive designing for one browser first is that the you start development at the wrong end. You have to break the code repeatedly. Then when an updated version of your preferred design target comes along and fixes the problems you worked around, your site will look broken in it, and you have to fix it, which increases the cost of developing the site.
The reason why I think this is the case is that most of the modern browsers have a reasonable support for current Web standards, so that much of your site will work out of the box. The ones it's not working for will most likely be the older browsers, which you may have to customize the
code for; for newer browsers you should submit a bug report. There are differences in some areas, like Javascript DOM, but there are ways to accommodate these differences in a non-browser specific way, and in a way that will accomodate newer browsers almost automatically.
Designing for standards first also have additional benefits, like being able to learn the fundamentals faster, as the specification is publicly available, and the documentation of the quirks in each browser may not be easily available anywhere, and I also think ability to design for a standard tend make time to market shorter as more tools are available to ensure that your code is correct.
Another benefit is that by designing for standards first you have a better chance at making your site better accessible to users that require assistive technology, for example people using voice screen readers.
I have also seen articles (here is one example) indicating that a standards compliant site has a better chance at being correctly indexed by search engine spiders, meaning that you would be more visible in the search engine results, thus attracting more customers.
Lastly, not taking the users of alternative browsers seriously may well cost you dearly.
These users will tend to be advanced users and also early adopters, just the kind of users you want to entice to your site when developing. Early adopters understand all about finding and reporting bugs, in addition most of them are also willing to live with the problems as long as they are eventually ironed out. In fact, the advanced users is a resource you should strive to keep on the good side of, because they are very likely to not just tell you there is a problem, but a number of them are able to tell you in large part how to fix it; IOW they are "free" tech support, and they can accelerate your development cycle.
Then there is the built-in presumption in both the above assumptions: That all kinds of customers are equally valuable to your company. It may well be that the advanced users would spend more money on your Web site than the ordinary users, in particular if they like the experience provided by the site.
The advanced users are also likely to be the tech-support hub of their network and quite likely the source of many recommendations, not only about new and good services but also the ones that are *not* recommended. A "good" way to get off the first list is when you don't make sure your
site work properly for them, and a very "good" way to get listed on the second list is to really anger them by not taking them and their requests and suggestions seriously, for example by suggesting they should use another browser (replace "browser" with "car", and think about it).
It is IMO quite possible that every advanced user you get as a customer will bring more customers to your site than an the more ordinary users will, and as such they may be vitally important to the economy of company behind the site.
Two examples:
In my previous apartment I had a Zanussi dishwasher. At one time I needed to get hold of a replacement part, and tried to visit the Norwegian Zanussi page, and was blocked by an "Invalid browser" webpage. I tried repeatedly to get them to fix the site, but essentially I just got back replies about either using another browser or accessing the necesary information throught their Electrolux page (There was no infomation about that shared agency at the web page displayed to Opera users). The end result was that this company lost at least NOK 20000 (USD 4000) in end-user sales revenue when I outfitted my new apartment last year, and several of my preferred items were actually imported and sold by this company.
The second example is just a few weeks old. I was contacted by a Norwegian shopping site as they were having problems in Opera with their new EV certificate. I explained the problem (a simple configuration error) and generally how to solve it, and also passed on the information to the CA. The interesting part was that they were keen on solving the problem because 10% of their customers are using Opera. Digi.no, a Norwegian online news site has previously reported 5% Opera usage at their parent company's network of sites, but 10% at their technology heavy site, all of which is in the same ballpark as has been reported in many other European countries.
Before site designers makes the choice to not accomodate a browser, the designers should carefully consider the economic consequences of their actions (and the CEO and CFO of the company should pay attention). If they make the wrong ones, their choices may be detrimental to the health of the company.
So, what should a web site developer look at when considering this area?
- What is the distribution of user agents used by first-time visitiors?
- What parts of the site do the various groups of visitiors visit? And which aren't being visited by some groups, and why not?
- How often do the first time visitor that arrive with one browser come back with another shortly after the first visit? The ones that doesn't come back, or just do testing, are the lost customers that will spend their money at your competitor's site instead (and will quite likely tell your support people why, and if they even mention your site to their friends you won't like what's said).
- Are there places on the site, in particular during selection of items to purchase, or during checkout that users frequently do not complete their actions? What are the specific problems at these locations?
- Among those that purchase something at your site, how much does each group of browser users spend? Which groups doesn't spend anything or significantly less, and why don't they spend as much?
- By not accomodating some groups of users, how much revenue would you directly loose? What is the indirect loss based on estimates of how many new customers those users could have brought to the site?
- When reading statistics, keep in mind that the market segment and countries you are targeting may have a significantly different distribution of browsers than what the global statistics indicate, in particular for the mobile market.
There are many ways to turn potential customers away from a site, some can be even more costly economically than what I have discussed above, but I think that combined with a less expensive development method designing for standards compliant browsers first, the side effects will turn out to be so beneficial that designing for all browsers is a very good move economically and image-wise for a web site.
Just my NOK 0,50.
Even though I definitely refuse to buy anything from a site that doesn’t allow me to enter with my preferred browser, I had never thought about the two “unquestioned assumptions” you mention. I figured that creating a website based on standards would increase maintainability and accessibility, but the economical side of the story never occurred to me. Last month, a newspaper in Holland showed that Postbank (one of the largest banks here) has reduced the interest it gives on savings accounts to nearly 0%. I could’ve figured out myself, but I wasn’t paying attention. :p So now I’m looking for another bank. One of the criteria for selecting another bank is whether I can do my online banking with the browser of my choice. If that’s not the case, I will simply continue looking.
Online banking is an extreme example, I wouldn’t use such a site if Opera didn’t show it’s secure.But for anything else, I indeed make a note to self not to recommend the website. Then use “mask as…” if I need the service.
I find your article a bit disturbing.First point:”The assumption that designing for selected browsers will cost less than designing for all browsers”It is a fact. It is a fact NOW. I know, that in hypotethical future, there is going to be a set of respected standards. And yes, then it would be easier to develop cross browser compatible sites. Problem is, that it isn’t the case now. Judging todays assumptions by tomorrow standards is pointless IMHO. Today, in 2007, there is no well written, well supported, non-misleading set of rules, aka. ‘standard’. Due to vague nature of W3C guidelines, both Opera and Firefox can differ in implementation, and be in line with specification. And I repeat, it is cheaper NOW to develop for IE/FF only, than to do it for Opera, Safari, Konqueror etc.. It is cheaper to use only IE/FF because of: – these are well-known in webdev comunity, ie. more web developers are skilled, and can perform good enough. Opera/Safari’ quirks are less documented, there are no tools (for Opera), that makes developing for them much more expensive, due to higher cost of staff that knows how to handle Opera/Safari – there are well-know dev-tools for both IE/FF. Im talking specyficaly about Firebug and Visual Studio. The second one, in both 2005 and 2007 (orcas) version has excelent JS debugging capability. It is ESSENTIAL for developing webApplications. These are too big to be ‘alert development driven’. – Time. Polishing bugs for 4 browsers takes longer than for 2 browsers. It is exponential in many cases, because fixing one bug can cause bug for other browser. – I ommit here things like personal emotions, but don’t forget, that people that make decisions often are emotion driven. I personaly was offended by one of Opera employees, and in a situation, when it is anybodys guess, I’ll always go in an Opera-unfriendly way. And I’m absolutely sure that I’m not alone. Company’ image is something more than official PR announcements, it is company employees attitude towards their customers on forums or blogs. Second point:”That the alleged extra cost of designing for all browsers cannot be recouped by increased sales to the users of the alternate browsers.”It is rather simple mathematic. Things like ROI are easily measureable, you can easily tell that (it is pure speculation, I don’t know any data) ie. Firefox users leave 5% more than average user, and there are 15% of them, while Opera users leave 20% more money than average, but there are only 1% of them. Given that developing for Opera is 30% more expensive you can calculate if it is viable to continiue support for Opera or not. It is really, pure mathematics. Mathematics, along with statistics can create prognostics about future consumer behaviour. You can easily tell if developing a site for few other browsers is proffitable in 1 year span, 5 years span, or at all. I repeat, it IS measureable. Sites that I had privilege to maintain it was quite easy math – due to 7% market share of Opera in Poland we supported it on tech sites, but ignored in on ‘casual consumer’ sites, where Opera had like 2% or less.Because all sites are made to make money, you just need simple math to tell if it will make enough money to pay for itself (it = adding support for non IE/FF browsers)As for the banking or consumer electronics example – it is just that, they don’t find it economicaly viable to support product A. It costs them some, but less than supporting it. They’ll loss you as a consumer, maybe your family or friends, but they’ll earn (not spend) much more on ignoring Opera/Safari existence.Remember – it is the money that counts in the first place, and people rarely do things that are not economicaly viable.
yngve: can i copy and translate your article here for Opera Indonesia? http://my.opera.com/id
opera95beta, how well will the sites you work on stand up in case there is an influx on many new users using ‘x’Phones or Opera Mini? Are the sites going to be usable for those potential customers, or are they going to go down the “street” to the website that is usable?My point is that by first coding for the standards, which are fixed targets, you will be better prepared when a market change occurs (and they usually show up when you least expect them). It is a more sustainable approach because in most cases you do not need to do any major work to accomodate the new conditions.In other words, I think a standards first approach will be less expensive up front, and during the lifetime of a site, because there is less need to accomodate sudden shifts in the market, and therefore reduced need for heavy maintainance.In my opinion, writing compliant sites will give an independent designer a reputation for designing sites with lower TCO, meaning higher quality, which should again the designer more challenging (and rewarding) work, and as a result higher income.Lost business opportunities can be another problem for a business, and they are not just the potential customers that get to your website and leave without buying. They are also all the potential customers that never get to your site because the searchengines did not list your site because it was unindexable, or because nobody was word-of-mouth marketing your site since they did not like it.Lost business opportunities do not show up on the managment’s bugdet spreadsheets, but they do tend to show in the competitions’s bottom line.BTW: Almost five years ago ESPN redesigned their site to be standards compliant. According to an interview just by redesigning their front page they halfed its size, and saved 2 terabytes of bandwidth, each day!
well, I’ll try my best to address all your arguments (thing unfortunatelly you didnt with mine, but anyway)With mobiles, IF the influx start to be visible (it certainly isn’t now in Poland), and for pages that are tech oriented/tend to be accessed with mobiles (traffic news, general news, but not article-driven portals) – we will make sure that both OperaMini and nokia/general browsers (iPhone got rather bad reviews in Poland and wont make any impact) are supported just as good as our customer wants (and pays for it). We never ever block anyone who uses agent that wasnt tested for. Truth is, that market isn’t a charity organisation and tends to support best the group that is the largest (brings most profit), and after that look for the minorities. Never in reverse order! Market isn’t saturated yet.Remember that lifespan of a page iteration is around one-two years. You REALLY don’t need to prepare now for stuff that is going to happen in 3 years. 1+ new versions of your site will be produced up to that date.”coding for the standards, which are fixed targets,”They are not. Simple as that, anyone who spent more than few weeks boxing with ‘standards’ like Javascript or HTML knows that both specyfications are full of holes, uncertainities etc. That is one of the problems that Opera faces. Opera does certain things in a different way than Mozilla browsers. Both are OK with the standards, but the Mozilla as the bigger player can say which one is ‘more’ standard. As long as there are no real, well written standards, your whole line of thinking is broken, because it is based on unrealistic/utopian theorms. It wasn’t a problem in the past, it is now, because webApplications really stretch the abilities of JS to the limits.Second thing. IE6. No sane person can ask anyone to ommit IE6. Coding standard first you ask yourself for LOTS of troubles. It certainly is possible, but in many cases (esp. when you work with content that is suplied by 3rd party) it simply is impossible. “In my opinion, writing compliant sites will give an independent designer a reputation for designing sites with lower TCO, meaning higher quality, which should again the designer more challenging (and rewarding) work, and as a result higher income.”Unfortunatelly, market seeks for the lowest denominator. Not the highest standards. It doesn’t matter what companies say about their mission and BS like that, it is the price to quality ratio that is important. As a freelance webDesinger you earn the most doing lots of simple, medicore quality sites. It certainly isn’t the most exciting job available, but paying mortages isn’t exciting either. I don’t claim that I like it, but it is the way world works now. WebDesigner market was spoild by lots and lots of students that start their careers as ‘HTML programmers’. They take very low salaries, and there is almost no gap for higly skilled proffesionals, because they wont agree on salaries of that level. So they go elsewhere, and like me go into Interactiv Designer bussiness or Architect or stuff like that. Create ideas, but leave the coding to the underpaid. That simply can’t achieve high quality, but market knows that and agrees on that. There is another reason, why coding standards first isn’t cheaper. Most available webDesigners, or HTML programmers CAN’T do it properly. They know tools like MS Expression (?) or DreamWaver (? I’m not good with this stuff anymore) that manage quite OK, but if they had to write something without InteliSense.. God forbid. You want standard first? You need good webDesigners, these aren’t cheap. So, giving that we want page that works in IE/FF (and this is the standard now) it is cheaper to do it in a way the cheapest available webdesigner can do it, as long as the final result is OK. I really feel a little strange taching basic market mecanics. You might see it differently, because you work with (probably, I know only Hallvors) one of the best webDesigners in the world, but that spoils your judgement a little I think.”Lost business opportunities do not show up on the managment’s bugdet spreadsheets, but they do tend to show in the competitions’s bottom line.”They do indeed. Marketing people, no matter how I don’t like their jobs are quite good at estimating these figures. Statstics help, comparative analysis helps (seeing how well competition that did certain thing fares), surveys help etc. You can determine it (with some error ofc, but the risk is the factor that helps you get profit) and calculate – if one thing is economicaly viable or not.And about mouth-to-mouth marketing, Opera has one of the worst possible. I searched for some Opera related stuff recently and what I found was ‘opera censorship on their forums and blogs’. I don’t know what it is about, but disscussion was hot. If it had to be my first impression in search engine.. And another one (this time I agree) – it doesnt work with (and here rather long list of sites like Google Groups/Reader/GMail, Yahoo, MS Live, CNN etc etc). I hoped that 9.50 will change it, or at least the true facts part, but it didn’t, but it is another story.”BTW: Almost five years ago ESPN redesigned their site to be standards compliant. According to an interview just by redesigning their front page they halfed its size, and saved 2 terabytes of bandwidth, each day!”I think you think that sites that I had under my control vere table-driven font-tag soup. No, they weren’t. you can code perfectly valid x/html site that breaks in Opera. It simply wasn’t worth it (opinion from merketing guys) to test it and make it work with Opera. Certain 3rd party .NET library wasn’t working OK with Opera, and we had nobody that could fix it if I recall correclty. It is quite common with .NET 3rd party libraries that they fail (mostly due to quirks in JS or lack of overflow-x/y. I know that 9.5 supports it, but it is two years too late, popular belief is that Opera doesn’t understand it, period). If it isn’t in the budget nobody wll do it. Again, it isn’t a charity organisation. And my own point of view now. Yes, IF there were standards (without holes) AND there were no IE-hell, THEN it would be chaper to code standard’ first. Id prefer it, becuase without all that hell of compatibility (you know, how many mobiles we had to buy to test one of our latest services?!?) designers would have a) time to get better b) products would be of better quality.But it is utopia, now is now, and in late 2007 coding standards first is only for very wealthy or very bored companies. Other can’t afford it.
Originally posted by opera950beta2:I’ll try my best to address all your arguments (thing unfortunatelly you didnt with mine, but anyway)Seems to me that you failed to address his as well. Maybe you should make sure you are perfect before criticizing others, don’t you think? ;)Why did you create a new account, by the way?”opera95beta” vs. “opera950beta2”
Hi all,I think I understand the point of opera95beta.The principle should be “code for the spec, not for a browser”. Ok. But the authors don’t follow that rule, and it leads to incompatibilities.Many say “It’s the implementors’ fault (mainly IE, but imperfect Opera’s and FF’s implementations too)”.Others say “it’s the end users fault (IE monoculture)”.This article seem to say “It’s the authors fault”. Well it’s certainly a bit of everyone’s fault. But what is the primary cause for this problem. Isn’t it the spec itself ? Though it’s not a question of “holes” in spec, I think.I’ll take two examples : WebForms2 and CSS.I don’t know anyone who can predict what a page layout will look like with reading the CSS. Multiple columns is painful to code. Anyone who ever tried to develop tableless CSS knows what I mean: you HAVE to test your stylesheet every two seconds to see what it looks like in the different browsers (f**ck to the IE implementation of CSS2.1), and figure out why it doesn’t work like you want at all, and add hacks and tuning and… it’s tedious. (If you have a trick to code CSS in a cross browser way, tell me, please!). What’s the problem ? Implementations ? My lack of intelligence or laziness ? the W3C spec wording ? I think it’s all that. The spec itself is too complicated. Complicated for me to code. And evidently, complicated to implement too ! (maybe the major vendor has reasons to deliberately ignore standards, but others don’t. And no one has a 100% CSS implementation yet). No matter how many times you’ll tell me CSS is simple. It is not, when you use it for layout (instead of style). The best you can do is probably to use something like YUI : which is just another imperfect, full of temporary hacks (and proprietary?) spec on top of CSS.Now, let’s see WebForms2. This spec is a real pleasure. It makes the authors’s life a lot easier. It is easily and already implemented (native in Opera, which is great! and transparently emulated in others with a little script, while they align). This is a success. You can use it today. Not many do, because it’s still young and not many knows it.What is the difference between these two specs ? Is that simlicity ? I don’t think CSS 2.1 has “holes”. It is simply not very elegant (or at least, I don’t get it). It can’t (?) be emulated. CSS3 is supposed to address these issues. I hope CSS3 column and advanced layout will not come too late : it seems great. But it also seems even more complicated to implement, which is a very bad sign.You can teach authors to use standards everywhere. The point is there will always be some who will develop for one browser. You can blame bad implementors, the point is you can’t make sure they’ll implement standards correctly.So the only things you can influence are the specs. I think it’s the basic idea behind HTML5. Imagining a spec that make these two categories of people (bad developers, bad implementors) not a problem.How ? Against bad authors : precise errors handling in the spec.Against bad implementors : good fallback mechanism.David