To be honest I’m sick of hearing “I hate IE6″, “Death to Adobe”, “All hail HTML5″, and whilst I agree in-part with the enthusiasm of those in the industry embracing standards and forging ahead there is of course a reason we are in the mess we are in, and that reason isn’t going away.

As mentioned at Techchunks, IE6 did come out prior to 9/11, but that doesn’t make it any less relevant now than it was back then.

The sad and ultimately excusable (you would love it to be unexcusable but you don’t have that much money) fact for why IE6 is around is money. Thousands upon thousands of loyal Microsoft-engrained organisations poured umpteen millions of dollars into building proprietary intranet and software platforms on top of ActiveX.

Unfortunately, or perhaps fortunately, ActiveX was removed from IE7 forward and this has left all of those corporates in a position where they must move their internal software systems to something else. Yes, Muicrosoft has been providing migration paths and support for moving away from ActiveX/IE6 for a long time, but it still represents a large expense in IT budgets that managers have been successfully avoiding for a long time.

While ever IE6 happens to be in the top 5 used browsers on your site, are you willing to write off potential sales from those users?

Before you even bother starting with “but they have firefox on their desktops too!” – sorry you are wrong. What they have on their desktops is of no consequence, I have 5 or 6 browsers installed, but you will only see 1 of them in your stats if I visit your site.

Is IE6 a pain in the ass? Yes.
Is IE6 costly to develop for? Yes.
Is IE6 really necessary for my webapp? That’s your choice.

Is IE6 going away in 2010? No. Not a chance. Short of someone writing a virus to remove it from the face of the earth that little browser is here for the long haul.

Unfortunately IE6 is here until managers are willing to cough up the money to move their own apps away from ActiveX. And for anyone who builds websites to make money from visitors, will continue to support IE6 until such a time as it dies out sometime before 2020.

I have been working on a project recently that includes header and footer bars much similar to Facebook style sites, but due to client requirements the site must remain accessible, which rules out using javascript for including the components.

On larger projects ESI has been great for doing remote includes, but due to no ESI support in Apache and no use of proxy/cdn servers in this project ESI was just not going to be possible. SSI of course was the next logical step, something Apache supports, but unfortunately doesn’t allow remote includes.

I thought about including a local proxy file such as a CGI or PHP file which could then issue the remote request and feed the data back, but this seemed hackish. There had to be a better way. It turns out there is.

If you have mod_proxy compiled into Apache then you are all set. Using ProxyPass we can make remote directories pretend to be local directories in Apache, and we can SSI include remote resources over a ProxyPass.

For example, should I wish to include resources from http://foo.com/includes/ I start by creating a proxy pass to my remote resources in my Apache virtualhost.

ProxyPass /remote http://foo.com/includes

I can then use local SSI includes:

 <-- #include virtual="/remote/myfile.html" -->

This is interpreted by Apache and then run through the ProxyPass resulting in an include of the remote file http://foo.com/includes/myfile.html into your local site.

This has certainly made SSI a more usable option for cross-site resource sharing. Best of all – you can do those normal SSI includes inside eZ Publish templates and it gives you even greater flexibility in your projects.

Daniel Dilger wrote a brilliant post on why Flash for the iPad and iPhone are simply not viable, ignoring hardware, battery and other constraints – it simply isn’t possible from a gesture perspective.

Hooray, finally someone is talking sense.

Read the post here

As the title indicates this post is specifically targeted at the ongoing discussions that swept twitter yesterday regarding whether or not designers should have a hand in coding their designs.

Initially this was started by Elliot Jay Stocks who tweeted:

Honestly, I’m shocked that in 2010 I’m still coming across ‘web designers’ who can’t code their own designs. No execuse.

Since I spend a lot of time working closely with designers I thought it would be interesting to weigh in on some of the points which have been floating around.

Should designers be able to code their own designs? Yes, no, maybe… I mean actually it has less to do with code and more to do with understanding the medium. In all the time I have worked with designers, the one thing I have found refreshing is to work with designers who actually understand the medium in which they are working. Unlike print, which is a very controlled medium, moving into the web is very much a different experience for designers. Without properly understanding the medium in which they work you are destined for hard to implement designs which do not make use of benefits of the web.

In order to make things pretty on the web designers need to first understand principally what is possible, how their design will work, that what they are designing can actually be implemented without too many browser limitations and that it will look as good on the web as it did in Illustrator when they were making it.

I am not advocating that designers should go out and learn HTML, CSS and Javascript and do it all themselves, unless of course you are a sole-trader, but in understand the medium you will in turn work quicker, smarter and produce designs that are easy to implement, manage and maintain over longer periods.

For those who have come from print backgrounds, this is what you already know, it’s what you have done in print for years. You first learnt the medium, its constraints and how to deal with them. Now you need to learn the new medium you find yourself working in.

Something that every technology person comes across is budget and time overruns. Something like 80+% of technical projects run over time.

Really? Are you surprised? I’m not. No matter how much pre-planning and thought you put into a project, no matter the resources, staffing and waterfall diagrams to back it up, technical projects are at best a guess.

There is no finite timeline on which you can measure how long it will take to implement payment gateway ‘x’. And of course during such an implementation you will uncover problems ‘y’ and ‘z’, which are not in your waterfall diagram.

As technologists we need to communicate to our clients better that timeframes are mere goals – not guarantees.

Auto updates in Wordpress are great. They make it so easy it’s actually enjoyable to update, well for some people it is. For those of us who want to override one specific thing in the Wordpress core with an enhancement, such as my archive listing, we have our changes overriden with each update. In my case my archives page is broken until I go and reapply my patches again.

Thank god eZ Publish made some great design decisions and made overriding internal functionality easy… now we just have to simplify the upgrade process a little and we can have the best of both worlds.

After considering Tumblr and other services I realised that I spend quite a lot of time reading and collecting resources across the internet for personal development or out of interest and quite often intend on sharing or commenting on such content within my blog. This of course doesn’t happen simply due to time constraints, enter asides.

Asides, linklogs, tumblelogs and any other associated name you want to throw in allow you to post short form comments/posts, in my specific case related to other content I have found around the web.

I have set this up on my blog quickly and will expand on it over time when I can focus on the display and functionality issues surrounding it. For the mean time they will be the short ones (obviously) with a grey(ish) background.

Over the past 24 hours I have refreshed the layout/look of my blog and it has given me a chance to simplify my layout and a chance to test out something new, Cufon.

Cufon is a text replacement system much like sIFR but much quicker and easier to configure and without the need for flash. Instead of flash, Cufon uses canvas and VML for cross-browser support and converts fonts into VML paths for use by javascript.

It sounds ugly, but it is actually quite elegant in both design and usage. It is quick and well supported and whilst there are still known bugs I think that in comparison to sIFR it is infinitely quicker and easier to setup. It is in use on this blog now and it is definitely something I will be considering for future projects and recommendation to others.

Safari 4 Beta, the latest release of my favourite browser, has fixed a “bug” that has become a common practice among web professionals.

Text-shadow has been around in the CSS2 spec since 1998, but has had poor support from browser vendors. It’s rise to fame however has been as a workaround for sub-pixel rendering of fonts within Safari.

Safari uses sub-pixel rendering instead of normal anti-aliasing as a part of the Core Graphics framework, which in most cases makes text look sexy, unless you have light text on dark backgrounds.

A workaround was discovered using text-shadow in Safari, which invokes anti-aliasing. This workaround provided a text-shadow offset of 0 and forced anti-aliasing, ensuring text remained legible.

Unfortunately these days are numbered… Safari 4 Beta has removed this option and text again looks bloated and ugly. Luckily Garrett Murray has come to the rescue with a solution for this “bug fix”.

text-shadow: #000 0 -1px 1px;

Obviously substituting #000 for a background colour suitable for that your text is displayed on, alternatively you can use rgba(255,255,255,0.1) as your colour specification for the definition to work on any background colour (I haven’t tested this across all browsers).

A lot of people have been blogging about the recently released Safari 4 Beta. There seems to be plenty of camps on whether new features are of any benefit, if they break usability and if Apple really knows what they are doing.

Throwing all of that garbage aside, Safari 4 is a nice update. The tabs work, they actually make more sense at the top than under the address bar and it seems that the browser is overall a much faster, sleeker implementation.

My only issue at this point in time is it’s CPU usage. Some bloggers seem to be saying CPU usage on Safari 4 is lower than 3, but I am experiencing quite the opposite, with my poor MBP stuck with Safari chewing up 80%+ CPU and driving up the temperature.

If anyone has any suggestions as to what may cause such CPU usage please let me know.

I have been a member of the WSG mailing lists for some time and I have watched with amusement the discussion regarding the release of the Safari 4 Beta and whether or not it was Safari or Opera which passed the Acid 3 test first.

My response to this is simple.. who cares?

In the web industry there are only two important positions on this issue, those browsers that do pass Acid 3, and those which do not. Stop worrying about who gets there first, and focus your worry on those who still don’t pass.

While the the two most popular browsers worldwide continue to sit in the wrong camp I am not impressed.

I don’t know how many people follow the work from the The Barbarian Group, but they produce some pretty amazing things, including Magnetosphere, a visualizer for iTunes which has been rebuild and shipped as one of the new visualizers in the latest versions of iTunes. 

Not surprisingly these extremely cool people have built some other extremely cool things, including a little OS X app called Plainview. 

Plainview fills a very specific need allowing web based developers and designers to showcase, present and demo their work within the medium it is designed to be used. The best description comes from the Barbarian site:

We Barbarians give a lot of presentations. A lot of speeches. A lot of Dog and Pony shows. People want to see our work. And the work we do is on the Internet. And, until now, we really had two options for showing our Internet work: we could capture it all to Quicktime, and throw it into Powerpoint or Keynote, so we could present in a nice full-screen mode that looked professional, or we could try to show it in the browser, and have all that ugly chrome distracting people from our beautiful sites. Both of these options had their pros and cons – full-screen looks sweet, but you lose the interactivity of the site, everything has to be canned. And showing things in a browser lets you show the site’s interactivity, but, again, that ugly chrome.

So now we have a third option. Fire up your full-screen browser and let your audience focus on the work.

You can find more information and download a copy from here. 

So if you happen to be on a Mac go and grab a copy of Plainview and give it a go, it might just make that next client meeting a lot easier.

I totally agree with whoever posted this over at reddit: 

If you’re a web designer working alongside print designers with little to no web design/dev knowledge, how is your experience?

and in response:

Teeth-grindingly annoying.

Print-turned-web designers:

• Learn the medium you’re working in. A five minute video of even the best print advert makes for a lousy TV advert. Likewise, techniques and habits refined by years of print design are often sub-optimal or flatly counter-productive when applied to the web.
• For the love of god, give up on pixel-perfect positioning and learn to appreciate flow layout. Sure, it makes design harder… but if you think designing flow layouts is hard, think about us poor schmucks who have toimplement the damn things. And if you think flow layouts are ugly, let’s see how good your precious pixel-perfect design works when I do something freakishly unusual like resize my browser window.
• Print pages are Things To Look At. Web sites are Things To Use. Prioritising aesthetics over usability or functionality is like putting a car steering wheel in the middle of the dashboard “because it looks nicer there”. You think it’s pretty and a real design coup, but everyone else is laughing at your idiocy (… or swearing at it if the design ever gets into production). Incidentally, I swear if I get one more design through with a “button” image but no pressed button image (or “link” style but no “active/hover/visited” link style) I will personally bite off your head and defecate into your body-cavity. You have been warned.
• Conventions are not boring – conventions are your friend. Putting light-switches near doors is a convention. Sure, putting them square in the middle of the ceiling is innovative, but then so is cheesegrating your knees (hey – do you know anyone who’s done it?). Innovative means “nobody else is doing it”. Accept the possibility that nobody else is doing it because it’s a fucking stupid idea.
• I don’t want to “explore the interface”. I want to get in, do my shit and get out again. If you think forcing users to explore the interface is such a good idea, try ripping the labels off all the cans of food in your cupboard. A couple of meals of cat-food, chilli and peaches should demonstrate exactly how “fun” this is.

Pant, pant, pant, pant… pant… ahem.

Amusing to say the least and I am sure the print designers will have plenty to say in return. 

Thanks to Thomas Koch from whom I found this little gem.

I read today that Jamis at 37signals has fallen into the same trap their “Getting Real” philosophy tries to avoid. 

I kept chasing my tail. I’d look at the existing reporting UI that we have for our other products, and then I’d start thinking what needed to change to adapt it for the Jobs/Gigs reports. That would then lead me to think about potential refactorings in the code needed to support the (hypothetical) UI changes. Thinking about the code refactorings would lead me back to the UI, where I would think some more about the visual impact of the code refactorings, and so I would go, loop after loop, ad nauseam.

It is good to see the staff at 37signals still fall into the same traps everyone else does, even after evangelising their “Getting Real” philosophy. 

I certainly agree that it is a hard habit to kick, and in some cases I don’t have a desire to. There are a number of projects and clients, especially so in the enterprise space where these approaches just aren’t desirable or suitable. But that is a topic for another day, what really caught my attention was the last line..

So, if you ever catch yourself playing mind games with your code, just stop and make something. Pretending is poison. Stop drinking it!

This is great advice. This is something every web developer, user interaction designer, graphic designer or similar should seriously consider and take note of. Rather than spend countless hours thinking about how it might work, build it quickly, visualise it, tweak it, delete it and move on if it’s not suitable. This in many ways follows on from the previous blog post at ZURB regarding failing fast. 

Designers seem to be able to do this well inside of their fancy Adobe toolkits (ok, you caught me, I have CS3 as well) but handing a PSD to a programmer isn’t very useful, it happens often, but prototyping inside graphic programs is usually done without too much consideration for the real content to fill those spaces. 

Increasingly the best solution seems to be rapid prototyping in html/css/jscript. If you can free yourself from the mindset that html/css are left only for the actual development then you can start to rapidly prototype and see if things work. Mark Boulton Design is certainly a great inspiration for this approach as they continue to work through the redesign of the Drupal website. In the past 8 revisions it’s been possible to see the site come together through quick prototyping, with user feedback. The great thing about this approach is you can click it, interact with it. Rather than just seeing the navigation looks pretty, you can determine if it’s usable, if your content overflows your containers and if users feel comfortable with the interface. 

So next time you get caught “pretending”, as the 37signals guys would say, then whip out your favourite editor and just prototype that interface in 5 minutes, see if it works, if it does great, if it doesn’t then change it, or delete it and go make another coffee (my preference).

I seem to find myself saying this all too often this year, to both new staff and other friends in the wider community so I thought it best to post briefly. I know a lot of others have covered this topic in the past and continue to do so, but it doesn’t always seem to get through to people.

Do not use <table> for layouts

<table> and its related tags are provided in HTML 4.01 to provide a means for which to define tabular data. Their purpose is neither one or layout or display and should not be used to achieve any visualisation of any type. They exist solely to provide a definition for tabular data. 

Well yeah..

It was a popular message, here comes CSS and it answers a bunch of questions about how we style content. But somewhere along the way the message seemed to be misinterpreted or lost in some way… and turned into

“don’t use tables, they are evil” – which it seems a large proportion of entry level web developers still believe to be true. So now we find hordes of people looking at css layout techniques for floating cells to replicate the same functionality a table provides…

Stop it.. oh my god

The original message was “Do not use <table> for layouts” and that is still true, don’t set them at 100% width and start putting your menu and content areas inside tables, it is bad form. But this doesn’t mean stop using tables. If you are displaying tabular data then use a table, its why they exist. Tables are not evil, just the way people chose to use them a few years ago was. 

Oh, and you can make them sexy using CSS.