Which browsers do you support?

I came across this older blog post today and it got me to thinking about which browsers you, as a web developer at the university level, support. The author had some nice graphs in there which listed which browsers he supports and to what extent he does.

I’m writing mostly to get my own thoughts down at this moment in time. I’ve recently been hunched over my own college’s analytics to make some determinations on how our website redesign is going to commence. So, I’ll just list off some general categories and what I’m doing within those categories.

Internet Explorer

Luckily, we are dropping IE6 this time around because its usage has dropped below 1% of all total traffic. That is not the ONLY reason for dropping it because IE6 also needs some annoying hacks to get things to work, encourages me not to use modern web technologies without providing an alternative, and would increase development time. IE7 is still there, rearing its ugly head for the time being, but its share is dropping as well and I can only hope that it will disappear within the next couple of years so that we can drop that too.

IE7, IE8 and IE9 will all be supported and I’ll be testing all three. IE8 is currently the default browser on campus but I am hoping to push IE9 through as soon as it is released. I would love to drop all of the older versions, but they are going to be around for a LONG time because Windows XP will only be able to be updated to IE8. I would encourage anyone who is stuck on XP to use either Firefox or Chrome to make things much faster.

IE7/8 will not, however, receive all of the graphical “candy” that some other browsers will. This mainly is due to the lack of CSS3 support on those browsers, but everything will still be accessible and looks good.

IE9 is going to be targeted to be as compatible with all of the candy as possible just to see how far I can push things. It should be fun.

Firefox

I will be trying to aim for Firefox as one of the standards for browsers (along with Chrome). Firefox is available on Linux, Mac and Windows so that way I can provide a comparable experience on all three platforms (same with Chrome). Firefox 4 is going to be an interesting beast, if they ever launch it, and I’ll do my best to support that browser as well. Not too much to say here other than Firefox 3.5+ will work.

Chrome/Safari/Webkit

I’m lumping the three of these together even though they are not the same browser, but the first two share the same rendering engine (Webkit). Chrome is available on Linux, Mac and Windows and is the second of my standard testbeds. I actually do all of my coding with Webkit browsers in mind first and then make tweaks from there to accommodate any oddities that arise. It has worked well in the past.

I’ll also be making sure that Safari 4+ on the Mac works as needed, even thought Safari 5+ will be officially supported. Anything newer and I will probably end up pushing you to another browser (more than likely Firefox for the older machines).

Mobile

One of my goals is to provide some kind of mobile experience for iOS and Android devices. Sadly, Windows Phone 7 will probably not make the cut nor will the newer Blackberry phones. I’m not sure what I am going to do about the older Blackberry devices because there are a great many of them still in use on campus by faculty/staff/administration, but they provide such a minuscule amount of traffic to the current site.

I need to look at either providing a m.mlc-wels.edu or looking into media queries to handle different devices. This is a longer-term project, but one I am excited about.

Conclusion

Main thing is that I’m shipping with IE7+, Firefox 3.5+, Chome 5+ and Safari 4+ support for the website when it will originally ship. The pairing down of needed versions is something I will continually try and do to cut back on code needed to support different browser versions.

With the upcoming rolling-release development cycle for Firefox (which Chrome already does), I’m hoping that it will push web standards farther ahead by incorporating them when they are finished instead of waiting for the next big release so that you can have more bullet points in a press release.

Categories
Technology

Firefox Moving to Chrome’s Dev Model

Firefox is moving to Chrome’s development model of rolling releases, getting away from the large, cumbersome release schedules that have been the norm for the project for a very long time.

Of course, the first thing they need to do is release Firefox 4, finally, and then ramp up the new production model to try and release new features as they are ready instead of setting milestones and rolling them into large releases.

I welcome the change and hope it will push Firefox ahead as fast as Chrome has been moving.

On Wording for Webpages

I frequent the University Web Developers social network and try to keep up with what is being talked about there. Mainly this has to do with my current work as a webmaster/web developer/web person at Martin Luther College, but it doesn’t take much to take some of the discussions going on there and expanding them to the web as a whole.

One recent discussion has focused around the wording for a particular part of the website that has to do with student housing. The question boils down to this: do you use the name of the department or something that more generically points to the purpose of the area of the site.

The two phrases being tossed about were “Residence Life” or “Housing.” A third term was brought in by someone else, “Dorms” later on, but my thoughts are the same regardless: go with what a person would actually be thinking of when they come to your site. I don’t know of anyone who is going to come to the site and think “I really need to find out more about residence life.” However, I can imagine (because I did this myself) that people would come thinking about “student housing” or “dorm life” and both of those would fall under the simpler terms.

When presented with options on how to word things, try and go with what is the more clear and will speak the clearest to your intended audience. Sometimes trying to be consistent (with department names) can cause more confusion and ultimately lead to more problems than was intended.

Clarity for the user should trump almost everything else.