web design

There are 2 posts filed in web design (this is page 1 of 1).

strong coupling and web development

We are all well aware of the dangers of strong coupling: for me, the most dangerous being the increased maintenance costs in such a system. Much has been discussed about coupling and measures such as dependency injection are used to help control it.

However, as far as a Google search leads me to believe, but I didn’t search too hard, not much has been said about the strong coupling that can exist between HTML, CSS, and JavaScript files. Maybe I’m doing something wrong, or at least something different, from others but many times in recent weeks I have found that the dependencies between these files can be rather tight and restrictive.

To understand what I’m talking about, let’s take a look at an example. Consider the following snippets of an HTML, CSS, and JavaScript files respectively:

1
2
3
4

<div id="main_wrapper">
    <h2>Header</h2>
    <div id="content"></div>
</div>
1
2
3

#main_wrapper {
    color: #FFFFFF
}
1

$('#main_wrapper').attr('color', '#000000');

As you can see the id is referenced in at least three different places. Well so what?

The problem, as I see it, comes from the fact that it is more than likely these files will be maintained by different people. For example, a designer is likely to maintain the HTML and CSS files and a developer the JavaScript file. In the days before JavaScript proliferation, this maybe wasn’t such a problem. However, with the rise of jQuery and its awesomeness the landscape has changed a little.

In fact, jQuery actually compounds the problem, as we have all become accustomed to seeing JavaScript code littered with things like $('#main_wrapper'), i.e. CSS selectors are referenced throughout the code base. What this means is that when the designer changes the structure of the HTML file, or the class names and ids, it can have unexpected side effects.

The easy (part) solution to all this is that when you create ids and classes you never change/remove them or their container – or at least you never change them without searching globally rather than just locally. I’m not sure how restrictive this is though, maybe those with far more experience of this than I do can offer up some more constructive thoughts? Are designers are just not used to such constraints? I dunno?

To me it just seems like a hassle having to keep track of selectors, ids, and classes in so many different places. It seems to go against the spirit of good programmer where we try to localised any side effects when changes are made. With the above way of working this doesn’t seem possible – and combined with the divided level of responsibility between designers and developers, I imagine this causes an increase in the number of bugs and also in the cost of maintenance.

Maybe others don’t see this as an issue at all? Maybe I’m doing designers around the world a disservice? You decide.

At the moment I can’t offer up any better solutions, as I have not really thought about it too much yet. When I do though, I’ll be sure to report back 😀

the curious case of the graphical interface

Until recently I had a rather nescient attitude to the needs of users who have barely seen a computer never mind used one. It’s easy for developers to forget about these people. However they exist, and with the rise of the internet as the dominant carrier of information, I would presume that now more than ever the new computer user is finding their way online.

Most developers have had the “keep it simple” mantra for UI development drilled into them over the years, both in an academic and commercial setting. However, having spent some time educating a few older family members (who fall into the computer newbie category described above) on the ways of the internet, I’m of the impression that it’s not just simplicity that is required but moreover consistency.

For example. A simple hyperlink like this one which seems innocuous to the average user, can cause trouble. Why? Well, when “teaching” people to use the internet it’s helpful if you can define some simple rules. One of these rules might be “Things you can click on will be underlined”. Rules like this give a surprising amount of comfort to an inexperienced computer user. However, until actually watching a family member struggle when links are not underlined I would not have known/believed the problem existed. To them the link above just looks like a piece of coloured text, which they don’t associate with the simple rule. A similar situation occurs when links are in the form of an image, where unless it looks like a button then they are unlikely to click it.

However, many sites don’t underline hyperlinks, so an alternative rule may be “When you move your mouse over a piece of text and it turns into a little hand, then you can click it”. That is as long as someone has not change the default cursor – thank you for this feature Internet Explorer! This rule is not ideal though as means you have to trawl the entire page to find links.

If you plan to really confuse a new user then you can always do the following: fail to underline the text, have it the same colour as the rest of the text, and instead of using an anchor tag, use any tag you like and just assign an onclick handler to the element in javascript. That way you get no cursor that changes to the familar hand as well. Awesome.

The above problem really does exist and I have seen it on many websites even those undertaken by well known web agencies.

This is not the only area of inconsistency, there are many others. In fact, another problem that seemed to cause increased stress levels is time/date input – for example a flight search engine. Most sites that require this functionality tend to provide some sort of calendar widget. Therefore, you can show someone how to input a date by asking them to first click on the calendar image, now click the appropriate button to navigate to the required month, then click on the required day to select. However, every calendar widget is slightly different which is just the start of the confusion. The real problem is reserved for those sites that do not have a calendar widget to select the date. The user then looks everywhere trying to find this calendar button to click, and finally is left pondering the date format to enter manually – if they even get this far. Surely it must be to the benefit of everyone if we agree on a standard calendar widget that can be skinned in some way? Just a thought.

I’m sure there are many other areas where this sort of confusion can occur – I can only begin to imagine the problems with Flash sites! Hence the next time you are designing a webpage that is intended for public consumption it’s probably worth bearing this in mind.