I think we can all agree though that old IEs need to die and that the newer browser releases (like Firefox 4.0 and IE 9) can’t get here fast enough.

Feel free to stand by your second statement… I don’t think I took as much issue with your second tweet as I did the first… the second simply exacerbated. Knowing how many difficulties so many people had in this contest, having your first and second, (and so far, only) tweets sound so negative struck me as off-putting.

People did some amazing stuff. I guess where we differ the most considers your Telnet example: if the team whose project didn’t work in Firefox listed in their description that it only worked in Chrome… would you have docked points? I guess that answer is “yes”, because a browser is a browser is a browser. I simply disagree with you as to its importance in the grand scheme of things.

All things being equal, sure, those whose projects are ready for prime time deserve great credit. I’m simply putting more stock in the “great, bold attempt.” And I still don’t think anyone should be disappointed by the intense amount of pure effort that people put into these projects and then had the guts to have their work judged en masse.

In short, to apply a crude analogy, someone who builds a car that runs on plain water but unfortunately isn’t certified for highway travel deserves more credit, I think, than a hybrid that just gets better gas mileage?

There are two separate metrics upon which this strategy fails: Utility and Completeness.

Since I use Firefox as my day-to-day browser (not an unreasonable assumption, considering that it has about 23% market share and is a standards-compatible browser) I find it hard to be able to rate an application highly for Utility that simply won’t work for me. I make exceptions for applications for which the demo is so compelling that I would consider opening or downloading a separate browser just to use that application (such is the case for Serrano, for example). In the end though I will have to dock an application at least 1 star for simply not allowing me to be able to use it. At this point I’m not even considering Internet Explorer 6-8 – I think we can at least assume that developers should just be shooting for standards compatible browsers in the limited amount of time given to them. Of course any team that goes above-and-beyond to make sure that their project works in older browsers (like Simulchart) should absolutely receive additional points.

Now, for Completeness it can also be argued that any application that simply breaks in my browser is not complete – and is buggy, as per the guidelines: ‘How “fully baked” is the site? Are there bugs or dead ends?’ I docked at least one point for Completeness for projects that didn’t support Firefox (thus making it unusable for me).

You argue that developers that do good work and have a good project but that don’t have cross-browser support (and, thus, are not useful to the general public) shouldn’t be docked points. If that’s the case then surely you would agree that developers that do good work and have good projects AND have cross-browser support should be given additional points. Their projects are ready for prime-time – which means that they went above and beyond and deserve to win the competition. Sites that I want to use today (like Simulchart) and games that I can play today (like Scrabb.ly) — and share with my friends and family without repercussion deserve every star they get.

Another way to think about it: The browser is a critical aspect of any of the entries — it is the medium through which they are meant to be viewed. Ignoring that medium would be foolhardy as it is absolutely critical that it work properly. If the contest was all about Node then there would be no Design rating. So far I’ve only come across one entry that used a non-browser as an access medium and that was the Discworld MUD (you could also access from Telnet). I connected via the OS X Telnet client and confirmed that it worked and was playable. If I was unable to connect using that client then I would’ve docked the entry another point — for the same exact reason that my inability to view the entry using Firefox causes me to view the entry in a particularly negative light.

I completely stand by what I said: “Teams that made working, fully-functional, cross-browser applications in 48 hours deserve to win – and get my vote.”

I miss being able to do cool shit.

For example – “Espresso”, “Cappuccino”, and “Coffee Latte” – each brand has different taste and price as well as respectively. In my country, almost everyone (who love coffee) has taste those kind of coffee in everyday – perhaps, with different terms – because the same quality coffee at Starbucks, can be get anywhere in here from the lowest prices (also the chocolate and milk). I drink coffee when I visiting my friends, I drink coffee while in my lunch time, and I also drink coffee while I’m typing this comment.

If I understand on how to sell many kind of coffee at higher / highest prices in the market, perhaps I’ll become selling coffee right now. But coffee is not my language, I just drink it

“One day, I mix my coffee with peanut butter…. it was really taste heavenly!!!”

Cheers, Jeroen

However, I feel I must explain my initial design decisions, at least partially.

First off, yes. I did justify my decision to hide the labels behind a “know your target audience” excuse, but – as your facebook friend mentioned – I knew my site visitors would be individuals looking for a web developer/designer, and expect to see graphic heavy content (it is a portfolio site). It was a decision I made only due to the fact that many other fairly prominent designers and developers had decided to use similar graphical text replacement techniques despite this short coming.

That said, I used the screen media type so that mobile browsers (other than iPhone) got straight up html, with text labels intact, and the labels were hidden in a manner that made them accessible to screen readers. Also, while the page linked to by Smashing didn’t have any other contact info, the form was originally for my contact page. That page does also list several other ways of contacting me – email, phone, snail mail, twitter – so that even if someone couldn’t use the form for what ever reason, they would still have other options available to them. You see, accessibility isn’t always about limiting yourself (or jumping through crazy hoops) so that everyone has the exact same access to an interface. Sometimes it’s about offering a reasonable (if somewhat clunkier) alternative when non-accessible techniques are utilized.

However, I admit that the image is large and slow to load. I’m still trying to find a way of compressing it that keeps its fidelity and alpha channel intact. I also think that I could have added title attributes to the form elements to allow someone a method of deducing the use of each field without the graphic available.

Again,
Thanks. I like the solution you came up with.