As of tonight, I decided to discontinue pursuing future projects in the area of traditional HTML/CSS design. This is partly based on my mounting frustrations with the CSS standard, that despite being explicitly defined by the W3C, has never been fully and properly implemented by any browser. Every designer instinct tells me that CSS is necessary and not to use table designs, but recently I’ve found it increasingly hard to rationalize this as a benefit against productivity.

As far as I’m concerned, technology should be an aid in my pursuit of the holy grail of Design. If the technology is too old, or just not up to par with my needs and expectations, than I have no other recourse but to pursue other technology that lets me do what I want consistently and with the relative ease I expect. To this end, I have recently put much time into developing with Flex, and in the future plan on working with Silverlight (as much of an Adobe fan as I am, I’d be a fool not to learn more about the competition, for more info, see Blue Ray). I like pushing the edge, and to me, CSS feels like a hack to make HTML, nearly a 30-year old technology, look decent. Ditto on JavaScript in terms of AJAX (that aside, I love what JavaScript is, just not how it is used).
Another factor in this decision is a shift in career focus for me. While I intend on continuing my design skills, I find myself enjoying application programming more and more each day. I find myself more challenged with this, but challenged in a good way.

I find it so much more rewarding not to be fighting the technology, but instead fighting against my own lack of knowledge as I push myself into these areas of programming that are, at least to me, new. I don’t feel like I’m giving up on HTML/CSS. In fact if anything, I consider my journey through HTML/CSS based design complete. It’s been a mix of good and bad, but what I take from it are the lessons and the experience.

So here I am, feeling at a crossroads of sorts. While I find comfort in what I’ve learned, I feel the urge to push forward, and while my past and the present is important, in many ways they both hold me back.

Now all along you’ve probably been wondering about that little picture up there. It’s for the analogy I’m about to give you: Living as a developer/web designer is much like swinging along on monkey bars. You want to keep moving because if you stop too long on one rung, you lose your momentum, you risk losing your grip, and even if you want to start moving again, it’s not that easy.

RIP, HTML/CSS
2002-2008

I have come to the realization that markup languages are the bane of any evolution developers and  (especially) designers want to see in the web in the near future. With some of the new features coming out for Flex 3 I have begun to wonder why we need to still be dealing with markup languages. Markup languages have been around in some form for the better part of 30-40 years. HTML itself is nearing its 20 year old birthday. Of course, there will be all the people screaming that things have changed since the first HTML specification, namely things like JavaScript and CSS which sprouted other methodologies such as Ajax. I am certainly a fan of both JavaScript and CSS but doesn’t the problem lie with the fact that we need these technologies in the first place? Flash has been reported to have reached 99.1% of all desktop Internet users.

Now, I have become a bit of an Adobe fanboy recently, but even if that wasn’t the case I would still have to say that right now programming website with Flex 3 and AS3 is looking far more promising and headache free than anything else I’ve seen. Who else other than Adobe has offered web developers a way to render their sites the same way on many browsers with no additional effort through Flash? Sure, bookmarking and SEO have been issues in the past, but the Flex 3 release will begin to fix much of that.

Next on the list of arguments is those that argue that Flash content can be a costly download to those with slower connections. Well frankly, the people with dial-up should know that in most areas faster ISPs are available, often for less. The fact is most ISPs these days are not dial-up and as a result most dial-ups simply can’t compete in the price wars anymore and still stay in business. The onus is on the individual to be a savvy consumer.

So what’s the roadblock?

• We need browsers to treat Flash files no differently than text files.
• Keep going on making Flash internal bookmarking more effective.
• More Flash SEO.
• More Flash security. Certainly there’s no thing as 100% secure, but that doesn’t mean we can’t aim for 99%.

And the final, big one.

• We need to put the pressure on the consumer to WANT flash sites. We want anyone going to look at any XHTML/CSS site to give it the same sour look any web developer would give a 90’s era Geocities website.

Hopefully, we can begin to see some changes toward a more multimedia based web experience within a few years.

Spry 1.6 has been released!

OK, almost a week late posting about this, but regardless Spry 1.6 has been released by adobe as well as the Spry home page getting a brand new (and much more professional looking) makeover. This version of the framework has some new widgets as well as being a more compressed version of the library.

The Spry team mentioned on their blog that they weren’t able to fix all the bugs and add all the new features that have been requested but are continuing their work on to Spry 1.7.  They also mention a new updater for Dreamweaver CS3 that will allow for this and future Spry updates to be very easy.

Don’t forget that this is still a prerelease version of Spry, although it has still been put to use on a few popular sites and is still worth looking into and using if the functionality that you want works for your target users.

The Spry Team Annouced the Upcoming Release of Spry 1.6

Some interesting news features listed there. By the sounds of it it’s going to be another prerelease. I would be hesitant to use it in commercial projects but have played around with it in the past and found it to be a good framework. Of course, that made me start thinking of working on trying to integrate Spry into ASP.NET as custom server controls. I think it’s possible and I plan to look into it some more this weekend. The only problem I could see is updating it with subsequent versions of Spry, but that primarily depends on whether Adobe decides to make changes in the required markup and JavaScript calls.