Should designers test for the MAC?

Here's a controversial question - and something I heard recently from a so called 'industry expert'.
Should designers bother testing their designs on the MAC platform given that they only make up around 3% of the global market?
Is the time and effort needed to test worth the ROI of those 3%?

 

And worse, that 3% is split between a number of different web browsers -- each with their own quirks.

 

I don't think it's necessary, as long as you got the PC bases covered (IE6, IE7, FF, and Opera). If it looks right on all four of those, odds are the Mac browsers (Safari, Konq, and FF) will display them correctly as well.

 

Thing to remember: Unless you're redesigning google.com, global market statistics are essentially meaningless.

Design a site for the audience. Browser usage statistics vary immensely from site to site. You can't make a blanket statement like "only 3% of the entire world is Mac, so only about 3% of my visitors will be Mac".

Even so, 3% is actually quite a bit.

Just break down and buy a mac mini on eBay. Anyone serious about development should have a mac in their possession.

 

Not really—Mac users are less reluctant to download any third party software, which is part of the reason they bought the Mac in the first place. The vast majority of Mac users are using Safari, and those that aren't using Safari are using FireFox, which I hope you are testing for.

And IE mac is as dead as NS4.

 

I recently realized that I had a bug with just Safari. They didn't like how I centered an html table, so I had to use css to accomplish the goal, which was a little tricky with phpBB.

It's a never ending cycle of finding bugs with different setups.

 

I'm going to say yes and no, and here's why. When I code a site, I don't give a damn what operating system the person who's visiting the site is using. I care about the BROWSER.

You see, there are four major rendering engines: Trident (IE), Gecko (Firefox, Netscape, K-Meleon, Galeon, Epiphany, Flock, etc...), Presto (Opera) and KHTML/WebKit (Konqueror, Safari).

Now, as a Windows XP Pro user, I don't have access to KHTML, but I do have access to the other three. So I test on them as I go along. I don't fall into the trap of "coding for Firefox, then hacking for IE" since I check in each one after I make any changes to my code. Usually (if you really know what you're doing and can back it up with quantifiable results, including not having to go back and fix your code when a new version of a major modern browser comes out - Firefox fanboys and IE hackers I'm looking primarily at you) if your site works properly in IE 6, IE 7, Firefox 1.5, Firefox 2.0, Opera 8.5 and Opera 9, it should work in Konqueror and Safari.

HOWEVER, while Konqueror and Safari share the same core engine, Safari tweaked it just enough to make it "different" from KHTML (which is why they call it "WebKit"). Bear in mind that Konqueror and Safari have trouble with styles applied to form elements (though I have found a way around it in most cases, which also takes care of bugs in IE and Firefox - yes I said that Firefox has bugs, so deal with it).

There are also times when a layout will break, or a feature (like a dropdown menu) won't work in Safari or Konqueror because of a conflict in the code that IE and Opera among other browsers will not have a problem with. This is because KHTML/WebKit is still a maturing codebase, with quirks that other rendering engines do not have (save for IE, but those are just attributed to sloppiness on the developers' part way back when).

 

You're authoritarian words towards other people's different methods of development suggests to me, you believe you're at the top of the game - But that's when you start to stagnate. For example, you still use the universal selector to reset your styles, which indicates to me you haven't done a lot of real world commercial development.

If I know that by not defining a line-height here firefox 1.0.7 will add an extra pixel or two. Opera might get a bit annoyed at some overflowed elements or equally when not applying a width to a floated element. Safari and Konquerer will go silly with background-image repeats when the image is bigger than the container. Icab will need a little help with alignment in tables and sometimes with float clearing. IE will apply the double margin bug, refuse the work when using a comment tag between an adjacent selector and I'll also need to apply an extraneous div in certain situations to position an element absolute after a floated element.

If I know all that, then what makes my working methods wrong when I chose to use Firefox primarily and sort the problems out in a non-obtrusive way after, that won't affect other browsers in the long run?

The mac market share is over 6%[1]. Unless you're site is a non-commercial, there's no reason you should be ignoring such a huge market share, with trends indictive of continuing growth.

Unfortunately just because it works in all PC browsers, doesn't mean it will work in Safari. Take one of the sites I developed 4 months ago; http://www.bensherman.com/client/index.aspx. There's a problem inside the sidebar with the 'newsletter' heading. In safari the form beneath will get pulled up to, leaving no space. It's not the way I've coded it being the problem, rather a bug of Safari not respecting the headings margin. It's solved in the next iteration of the site, but taught me a valuable lesson that I needed to have access to the MacOS.

 

This is an excellent and oft-forgotten point.

 

It depends, can you afford to potentially having a significant proportion of your users not being able to use your site?

The percentage will depend on your markets, we spend a lot of time working for graphic designers adding coding to their sites for their clients and so have a much higher than average rate of mac users using our site.

There are companies out there that allow you to lease a VPN onto a mac with all the common browsers installed and their highest charges are $3 for 2 days use. Isnt perfect but is sufficient for testing. Alternatively you can buy a second hand mac for very little.

 

I'm not at the top of the game - no one is. Not even Eric Meyer, Jeffrey Zeldman, Dave Shea, Tommy Ollsen, Paul O'Brien, Molly Holzschlag or (yes, I'm going to say it) even you. Every time someone thinks they know everything there is to know, someone comes along and does something totally new, whether it is a new take on an existing technique, or something so new it's never been done before. We all learn. Anyone who thinks they know everything there is to know and refuses to accept the fact that there are other ways of doing things, much less is willing to try them out during their free time, are the ones who stagnating.

Which is why you test in each browser you can get your hands on as you go along. It's called "debugging as you go" and is something that should be done during development, rather than after, so you can catch errors early on (before they become mistakes - I believe that an error does not become a mistake until after one refuse to correct it).

Knowing about browser bugs and the workarounds for them only come with experience, experience that must be acquired either through following in the footsteps of others (by learning from them) or by making the mistakes yourself and then having to go back and clean up the mess. As for me (and browser bugs), while I don't have a Mac (or Linux box), I do know people who do - and they check my work regularly for me. Once in a blue moon a problem will rear its ugly head, and when it does, it gets squashed like a bug. And my testers abuse my work as much as I do (which is why they're my testers). I don't ask them "how it looks" I ask them to do whatever it takes to BREAK my work. (By the way, I hardly ever use absolute positioning - and almost never inside a floated element; I prefer negative margins.)

I never said it was wrong (though I did come dangerously close). What happens when you choose one browser as your development platform is that you 1.) ignore the others and code primariliy for that browser (and often that browser version) then run a cursory check afterwords in the others, making "fixes" to make the other browsers appear to work and look identically to the one you are using, and 2.) when the next browser version comes out (regardless of the browser), you stand a very good chance of having to go back and fix your code (I'm just using the words "you" and "your" in the general sense - I'm not talking to you or anyone else specifically) to make it work with the next "flavor of the month" browser and/or browser version. This was readilly apparent when Firefox 2 and Internet Explorer 7 came out (in fact, media outlets were literally warning Web designers to check their sites to ensure that they worked in those browser versions). Look at how many people had to waste their time fixing mistakes that they had covered up with duct tape just so they could go back to doing what they were already doing. I didn't have that problem. At most, I had to give IE 7 "hasLayout" in a few instances.

Great advice, Adam. But like I said, I don't have a Mac, but I do know people who do, and they check in their Mac browsers for me - so I'm still checking to see that the sites I code work just as well as those on a PC or Linux box.

Yeah, this fact bit me in the posterior a few years back, when I started taking Web design/development seriously. It was a personal site for a friend, but I wanted to check on the Mac and Linux operating systems just to be safe. It turned out that a "trick" that had been advocated in a leading HTML/CSS book (by O'Reilly Publishing of all sources) was responsible. After that, I stopped reading the books and started teaching myself through experimentation.

 

Here are a few thousand other visitors to one of my web sites this month, none of whom are on platforms I test from -- even though I own and use Solaris and BSD boxes.

• Sun Solaris: 2498
• BSD: 1829
• Symbian OS: 906
• Sony PlayStation Portable: 793
• CPM: 111

Why should Mac users be special? Do they have little wheelchairs on the backs of their monitors?

 

Because it is their choice to use a Macintosh rather than Windows, Solaris, FreeBSD, or my dog Larry (that last one's a joke).K At the end of the day, we should respect the user's choice and make our sites work as reasonably well as possible on their setup of choice.

That's why it's called "user-centric" Web design in the first place.

 

3% of the global market is still millions of people you'd be shunning.

 

And it's my choice to encourage them to buy real computers.

Do you test your web sites on the BlackBerry web browser?

 

Want to buy me one? Besides, which browser in particular? Blazer (I think that's what they call it) or Opera Mini?

 

Yes, we do test sites on blackberry's/ smartphones when our client has specified a desire for them to be used through either emulators or our own technology.

 

This one has been on my 'to reply to' list for a bit...

There's one thing you're forgetting. You know your stuff, people who are learning don't. If they start looking in other browsers while they're producing the sites initially and try to fix it while it's being developed, all ends of shit code starts to appear - it especially encourages the use of position: absolute. Then it becomes hack after hack after hack and eventually the site ends up being held together by the most tempremental of means.

But really it doesn't matter, it's not too important how you want to build a site - it's just preferred practices. The more important point is that it should be styled with two major layers; The main CSS and a seperate hack/filter file to sort out browser bugs. The user goes about building and when testing, the hacks are seperated from the rest of the code.

I've been very fortunate to work with some of the top web agencies in the UK on some great sites, through my company's Code Press service. Learning new things everytime I go onsite and especially with the Code Press template side of the business when others do the building. It's brilliant to see new approachs to ideas you'd left set in stone a long time back. Ideas that won't make it to books for years to come. It's an exciting and rewarding time to be in this profession.