There are lots of web browsers out there now, which makes browser support a daunting task for any web developer or designer.  It doesn’t help the fact that even though there are standards, each browser has its own quirks as to how it interprets those standards.  Add to this the recent surge in mobile web use, and things get even more complicated, as you have mobile browsers that can support most web conventions (i.e. the iPhone) and older or smaller phones which cannot.  It may be permissible, for now, to say you cannot support all mobile browsing situations, but rarely is there a good excuse for not taking the time to assure quality in a variety of desktop browsers.

By adhering to the standards, you can get a website that is compatible for most situations.  There will likely be a few places where it is not, and more than likely the offending browser will be Internet Explorer.  There have been situations where I have spent hours just trying to work out a small kink in a design because of IE’s lack of full support for established standards.  Nevertheless, with some time and testing, all of this can be worked out if the design is good and the designer is familiar with browser quirks.  Not taking the time to test multiple browsers and versions is a sign of one or more of the following things: laziness, rushed to delivery, or poor quality assurance testing.

Laziness, or perhaps more appropriately, apathy about whether or not a site or application is cross-browser compatible, is probably the worst excuse for lack of cross-browser compatibility.  This is when the designer or developer of the application only tested it in, say, Internet Explorer, and didn’t care whether or not it worked in any other browser.  When people ask for support and are asked what browser they are using, if the answer is not Internet Explorer, they are met with the response “Oh, I’m sorry, we only support Internet Explorer.”  I don’t really find that to be acceptable today.  It is not difficult to install Mozilla Firefox or Google Chrome, at least the latest versions of them, and test the site.  At least know where the issues are!  And do not even get me started on the IT guys who will not let you install Firefox on a network computer because it is “insecure” (yes, I have actually encountered one).

There are some products that are rushed to delivery without the attention to testing that needs to happen.  Really, with these types of products and/or sites, the UI being cross-browser friendly is probably the least of their concerns, because there’s probably a lot more going wrong.  Tied together with this is the constant rush to get new features out the door and paying little attention to what’s happening with the UI.  As things are added, manipulated, or taken away, the chances of every little thing on the page working across different browsers decrease dramatically, especially if they were rushed, not tested, and thrown out into the world.  If the product is actually going so far as to throw errors in certain browsers, then you really have issues.  I have come across components from a certain vendor that would blow up when you viewed them in Google Chrome or Safari.  While this component vendor should have tested their product for cross-browser compatibility a bit better, so should the company using the component for their own product which produces the same error when viewed in those browsers.

Poor, or complete lack of, quality assurance testing means that any cross-browser issues that would have been caught will not be.  Even if there is not a QA “team” in place, some testing can be done by the designers and/or developers working on the project.  UI issues are generally pretty obvious, and testers with keen eyes can identify differences as small as one pixel.  In some respects, this is very similar to my explanation for laziness above, when it comes to the person designing or developing the project of checking their work in different browsers.  Having a team in place for testing means that additional eyes are looking over stuff that the designer or developer has been staring at for hours on end, which can be very beneficial.  Alas, not all companies can afford this luxury.

Cross-browser compatibility testing has become an important part of user experience testing, and it is not one that should be taken lightly.  The more popular the site or web application is, the more types of traffic it should be designed to accommodate.  One area I see this growing even more is in mobile web browsing, especially since mobile web browsers tend to have tighter restrictions as to what content they can actually display, and display correctly.  Many sites already have separate mobile versions, and it may be that this is the best way to address that particular issue.  All in all, the number of browsers that we need to support is not getting any smaller, so our workload is only growing.

A few weeks ago, I made this post about some of the difficulties I’ve had with working on my personal software projects.  In short, the difficulties stem from the fact that I’m trying to take on too much at once, trying to make everything perfect, and not doing enough project planning ahead of time.  I’ve made the decision to do something about this, and will start a new adventure in learning: project planning and management.

I would like to emphasize that the only management experience I’ve had is two years at a fast-food place when I was in college, therefore, I’m pretty much starting from scratch on this.  I’ve done a lot of self-learning over the past five years, learning new programming languages, patterns, practices, etc., but I neglected project management.  I see this as a mistake for a variety of reasons, the most important being that if I don’t plan my project out, how am I going to know what direction to take it or what features to implement?  I’m sure some people can do a “fly-by-the-seat-of-my-pants” style of development, but I prefer to outline what has been done and what’s yet to come, even if it takes a few revisions along the way.

Where to begin?

I have a strong interest in Agile software development processes, such as XP or Scrum.  Since I’m looking for a solo development process, and thus having to take on multiple roles at different points in the project lifecycle, taking one of these approaches to its full extent is probably not a good idea, since they are more team-oriented.  Finding the right subset of practices that would fit nicely with my individual development style, while allowing me to better manage my personal projects, is part of the challenge here.

I will probably start my search by looking for some blogs or online articles on the subject, then branch out into books.  If anyone has any suggestions to make, please do so.

Am I over thinking this?

I’ve asked myself this question a few times before I made this post.  I would think that any project, team or solo, would need some kind of feature list at the very least, and some kind of system to keep things running smoothly.  The difference is that in a team environment, there is usually a person designated as a project manager who does a lot of what I’m missing.  Am I overcomplicating the issue?

Thanks in advance for any input I may get from this.  I’m always encouraged when I find something new to learn about, and this is no different.  I see lots of potential improvements for myself as a developer through this adventure, regardless of the environment, and that makes it worthwhile.

When doing event binding in jQuery on a page that has a lot going on, it might be best to make sure you unbind and rebind the events, just to make sure you only get one event per element. I recently ran into an issue where the number of events triggered grew exponentially, and it was linked to this. Luckily, jQuery has a nice convention for working with rebinding. For instance, if we were binding to a button’s click event, and wanted to make sure this method was only ever called once when this button was clicked, we could do the following:

This way, we explicitly remove and reset the function that will be called when that button is clicked. Inside the function body, you can still use $(this), just as you would do had you written the function inline. There are a couple of variations to the unbind method: without any arguments, it can unbind ALL bound events, and with only the event type, it will unbind all events of that type.

You can read more about bind and unbind with jQuery in the official jQuery documentation at http://docs.jquery.com.