Wednesday, March 17, 2010

The importance of client interaction

Every analyst knows that communication within a project team is paramount to successful delivery of a product or service. Understanding the client's needs, their business processes and their paradigm are all essential aspects of a project, that can generally only be garnered through thorough communication.

In this age of internet telecommunications, much of our business communication is done over geographically disperse locations via email and telephone. For the more technically savvy there are collaboration and web conferencing tools. But nothing beats a face to face meeting, with all participants present in the same room. And when it comes to reassuring a client that you can and will meet their requirements and deliver a high quality piece of work it is essential.

Face to face meetings bring a real dimension to a team of people who may otherwise be working in a virtual or online environment. As soon as a face can be put to a name and a voice, a relationship is developed. Whereas conference calls specifically focus on the task in hand, a physical meeting allows time for a little small talk, which is, of course, where you get to know the real person, as opposed to the role of that person within a team. Clients are more likely to trust a vendor; consultants are more likely to feel a sense of responsibility towards meeting the client's needs.

In a project I am currently working on a lack of decent communication has resulted in the client's increasing concern and failing confidence in the vendor's ability to deliver a high quality product on time. I can imagine that the vendor has similar concerns as time and again they realise that their understanding of what they are to deliver is quite different to the client's expectations.

Most of the communication has been done via conference call and there have been associated difficulties. Each party uses different terminology, works from different paradigms. Participants even have different accents and ways of speaking that can lead to long pauses and repetition as those on the end of the line try to figure out what was said. A discovery session was conducted at the start of the project but none of the vendor's current team members were participants, no notes were made and no documentation was delivered as a result. A quick email from the vendor confirming what he thought were the issues discussed, the outcomes of the meeting and what the next steps were, would have done wonders for the client's confidence and comfort.

Last year a Forbes study found that 87% of executives prefer face to face meetings citing the following benefits:

  • building stronger, more meaningful relationships;
  • the ability to "read" another person;
  • greater social interaction.
In today's busy world, with tight time scales and even tighter budgets, there is definitely a place for conferencing and collaboration technologies. But these must go hand in hand with the more traditional methods of communication. Where a face to face meeting isn't possible, video conferencing is a great alternative. In the case of my current project, it was less the lack of face to face meetings that was an issue than the lack of good, frequent and thorough communication.

Thankfully, after a few frustrating conference calls a face-to-face meeting was arranged and since then communication has improved considerably. Meetings are now being followed up with notes, although there seem to be two sets of notes: one from the client and one from the vendor, rather than one set of signed off minutes. A sense of trust and working together as a team is in place and most importantly, each party understands where the other is coming from. If only we'd had a week together, rather than a day...


Freelance Switch: 10 reasons why your last collaboration did not work
Forbes: Executives Prefer Face-to-Face Meetings Over Virtual Contact
Forbes: The Case for Face-to-Face
Why Face-to-Face Business Meetings Matter

Tuesday, March 16, 2010

Why you should use a change log in your documentation

There has been a functional specification document going to and fro between us, the clients, and them, the vendor/consultants, for a few weeks now. Version 6 was released this morning. Including the files that have been submitted with annotations by our marketing team that makes 10 versions to review altogether.

The annotated responses are fairly easy to review as the annotations (marked comments) stand out from the document text. So, I just flick forward to a comment, read it and move on to the next one.

However, the official versions which are then submitted in response by the consultants, are not annotated and do not include a change log.

We're talking about a 53 page document. I don't have time to read the same 53 pages six times.

When I produce such documentation I always include a Document or Revision History table at the start. It looks a bit like this:

Lindsey Buckle
Initial Version
Lindsey Buckle 
Draft following technical discussion. 
Updated table p8: added 'File' column

This way, whoever is reviewing the document knows that the only thing that has changed is on page 8 and they're directed to it. They can flick forward to page 8, check the table with its new column and decide whether to approve the document. Much quicker than scanning every page of a 53 page document trying to figure out what has and hasn't changed.

What do you do? Do you include a change log? If so, what details do you add? Let me know in the comments.

Friday, March 12, 2010

CSS: How to fix IE6 bugs

Praj sent me this link to an excellent tutorial, which I'm hoping will relieve some of my IE6 headaches.

I am so busy at work that I'm yet to find out. But if not now, maybe in future, when another client insists that I don't discriminate against curazy IE6 users.

[I notice he hasn't blogged this. Perhaps because he isn't insane enough to try to mess with IE6.]

Tuesday, March 9, 2010

Design: Colour scheme definitions

I found the following definitions of different colour schemes, adapted from this tutorial, really useful and wanted to note it here for future use.

Monochromatic - uses multiple shades of one colour. Shades of gray are considered achromatic as they don't actually contain colour. It's pretty much the same thing though.

Analogous - uses colours adjacent to one another on the colour wheel. Apparently this can be tricky: choosing colours further apart than 1/3 of the wheel can result in less appealing combinations.

Complementary - uses colours on opposite sides of the colour wheel. Something to watch for here is simultaneous contrast, where the colours enhance one another to the extent that they become difficult to look at and possibly even illegible.

Split Complementary - uses two colours adjacent to the complimentary colour of your base colour. Or something.

Triadic  - uses three colours 1/3 of the colour wheel apart from one another.

Tetradic - uses four colours made up of two complimentary pairs.

To see some of these schemes in action, check out the Color Scheme Designer.

Design: Colour profiles in GIMP

I am not a designer. Although I did do pretty well in GCSE Design and Communications; an A if I remember correctly, because I was a right girly swot, and this was before the days of A++ or A* or whatever nonsense you can get now.

I have decided to teach myself a few key techniques to extend my web development skill set. This means going right back to basics. I'm not made of money so I'm working with GIMP.

This week I learnt about colour profiles. A colour profile is a set of data that characterizes a colour input or output device. Different devices and browsers have different colour profiles, which basically means they display colours in different ways. A profile is a look-up table which maps the properties of a colour space to a device-independent working space.

Therefore, you need to use colour management policies in your editing software to ensure that what you see whilst editing an image is how it will look when rendered. Colour management policies add a description of the colour characteristic to the image, i.e. they add a colour profile.

Most devices (cameras and scanners) will embed a colour profile on creation of the image. When opening such images, GIMP will offer to convert the file to the RGB working space (sRGB), which is recommended and is fine for web-based images. However, it is possible to add other ICC profiles to your image in GIMP, if required.

For the best results you can add a colour profile for your monitor. However, this is way beyond my beginner capabilities, and probably beyond my needs for now. You can also add a colour profile for your printer in order to view on screen how your image may look when printed.

See this tutorial for how to set up colour management in Photoshop.

Tuesday, March 2, 2010

Why we should stop developing for IE6

This is not the first time I have said this but I really truly hope it's the last: developing for IE6 sucks.

Since Google announced its decision in January to stop supporting IE6 (as of yesterday), there has been much online discussion as to whether or not sites should continue to be developed for IE6. In developer communities this has been a hot topic for some time now.

Web developers hate IE6. Aside from the much-publicised security issues, IE6 is notoriously non-compliant when it comes to W3 web standards and has shocking CSS support. Developers spend a significant proportion of their time getting a site to work in IE6. Just to test the current website redesign entailed installing VMWare Player and running an old, tediously slow virtual machine. And woe betide the developer who starts off with IE6 and then tests in other browsers. In short it's a complete pain in the short and curlies.

So what's the big deal? Why not just stop developing for IE6? The problem lies in the fact that a significant proportion of website visitors still use it. Statistics range from 10% to 20% of the global browser market share, although, as the graph below (from StatCounter) shows, this is falling. These figures are not evenly dispersed. Only 6% of Australian web users browse with IE6, whereas 25% of Asian and African users do. In these regions it is the number one browser, presumably due to the higher concentration of developing nations and subsequent lack of infrastructure.

Of course, what is really important is that you understand the statistics for your target audience. My organisation's stats are similar to those above from StatCounter and we have very little traffic from Asia and Africa. In discussions with the Web Coordinator (who is also Project Manager for our web redesign) I have tried to persuade him to forget about IE6. My argument is that our target audience is largely young (generation Y school-leavers) and tech-savvy. As such, they are more likely to adopt modern browsers. Only 5% of our traffic comes from IE6 browsers: not a large proportion and one that will only decline.

However, he has made the call to at least attempt to support IE6, arguing that other universities still support it. This seems like a lame argument until you consider that a potential student using IE6 might end up at another university because they couldn't find the information they needed on our site.

I had a ponder about who on earth these people still using this outdated browser could possibly be. Due to Australia's vast size there are a few remote properties and townships that don't have good broadband connectivity. Downloading the later versions of IE would not be an option for this demographic (although they could ask Microsoft to send them a free CD if they thought of it and had the patience to find and load the web page).

Additionally, there are still workplaces which continue to use IE6 due to the reliance of internal applications. Not updating is often cheaper and easier than rewriting those old systems. And then there are those people, perhaps the older generation and those infrequent surfers, who simply don't know or care that they should update. However, I do wonder how many people in this category intentionally visit our site.

We try to develop a site that is accessible to all, including those with disabilities. We currently have no statistics on what percentage of our visitors are in this category. As such it seems fair that we shouldn't discriminate against IE6 users. (Although, it could be argued that they have a choice as to which browser to use.)

My personal feeling is that the difficulties surrounding the development of a website for IE6 far outweigh any perceived benefits. It is time-consuming, does not comply with web standards, is old and outdated, and its user-base is low and falling. I think developers should ensure that users of IE6 (who, it is worth noting, probably don't know how to turn off CSS in their browser) can get to all the information that any other user can access without a major visual assault on their eyes. That is, that information should be readable, accessible and navigable. Develop for IE7, IE8, and the latest versions of Firefox, Safari and Chrome and then create a separate stylesheet for IE6, stripping all but the most necessary styles. If you can get your valid, standards-compliant website to look cool and groovy in IE6 then fantastic. But if it doesn't, don't redesign your website. It's simply not worth it.

My current challenge is to get our site looking worthwhile (and as close to the original design as possible as per my colleague's request) without changing the HTML, which has already been sent off to the CMS consultants. I think ripping out my own hair strand-by-strand would be easier, quicker and less painful. I am considering the addition of a disclaimer stating that the site is optimised for IE7 and above. Although I have to do some work persuading the project manager to let me yet.

Google drops IE6:

Discussions and articles on supporting IE6:

IE6 security issues:

Web statistics:

CSS: > notation doesn't work in IE6

I can't believe I'm actually writing CSS tips for IE6. (More on this in a subsequent post). I wonder if anyone will ever actually want to read this? And I hope that I won't ever have to refer to this again. But here I am.

So, against my better judgement I am prettifying some HTML for IE6 and I have just discovered that it doesn't like the following notation:

#name > ul

To be fair to IE6, I didn't know what this did until I few days ago. For anyone reading this who doesn't know, it means that you apply the following attributes to a unordered list sitting directly within an element with an id of "name". That means that the ul in question can't be inside any other element. To apply attributes to any and all uls within name use the following notation:

#name ul

I spent days trying to fix up some tabbed menus in IE6 and all I had to do was delete the > selector.

For more on CSS selectors and what they do see selectoracle, an awesome website that takes CSS notation as input and outputs the meaning (along with any potential problems). I'll be adding this to my list of Very Useful Tools.

UPDATE: I have found a website which lists CSS selectors and the browsers that support them. I feel quite sick at the thought of the task ahead after seeing the long list of red "NO"s under IE6.