For people outside of computing, or even who aren’t directly involved in some way with web development, it can be very difficult to understand the different levels and roles of various members within a team and who become responsible for creating their website. Of course there isn’t any set-in-stone roles, many developers transcend and have skill sets expansive enough to cover more than role, but it’s usually the case that if you want the very best, you don’t necessarily want one person who claims they can design and develop your website for you. You might find you end up with a technically perfect website with a nice, but not a visually amazing design. Equally back-end developers don’t generally like the front-end stuff, or don’t have the same level of skills that a front-end developer (should) have. So the problem is conveying this to non-developers (and most commonly: clients and potential clients). I’ve found myself trying to explain the concept of three different roles (design, front-end, back-end) in a variety of ways but over time I’ve developed my “Highstreet Store Analogy” and I’m not saying it’s perfect, but I’ve helped a lot of people grasp the concept of different development roles using it: Read more

Possibly one of the most frustrating parts of my migration away from the lumbering old PC (which has served me well, albeit on occasion frustratingly unreliably) over to my new Apple MacBook Pro (a set up and operating system I have been using smittenly at work for a couple of years) has been the peripherals: the AirPort Extreme is an innovative and amazing piece of technology that allows me to access my external harddrives over my home wireless connection, but it’s bloody difficult to then use it to share with the other (Windows) computers in the house as well. Possible, but difficult.

The double-margin bug in IE6 is one of those inexplicable behaviours of the aged browser that nobody quite understands: the developers claimed to be following the W3C’s CSS standards with IE6’s rendering, but sometimes this can almost be forgiven: the rules and guidelines are written down in such a verbose and brain-shattering verse that it’s very easy to see where people would perceive different outcomes when reading the same thing.
Not even a year ago, I spent a couple of days wrestling with Mark Davidson’s sIFR in an attempt to find a cross-browser compatible method of embedding custom fonts into a website I was developing, which the designer absolutely insisted could not use a normal web-safe font. Of course I very quickly gave up and reverted back to a PHP dynamic text replacement module - for all the great things that sIFR has done for the web developing community (and especially in reducing arguments between designers and front-end developers), it’s an absolute pig to get to work reliably across browsers and can really reduce the usability and loading of your site. Not good.

One of the biggest problems with larger application developments is the maintenance. If you’ve ever worked for a company, or somebody (or have been that somebody yourself), who decides on a whim that the dark blue colour used extensively across your website should really be a light shade of green (yuck!), then you can appreciate how time consuming and troublesome this sort of “simple” change can be.


























