# Friday, October 12, 2007
« 500GB MyBook Drive Copy Speed on Vista | Main | Continuous Integration and Version.txt »

Its no wonder many programmers shy away from web programming, specifically HTML and CSS.  Most senior developers consider HTML programming, and UI programming in general, beneath their station.  I think they're hiding from the truth. 

Making an easy to use and pleasant looking user interface is much harder than consuming a web service or writing some highly concurrent middle tier layer, especially when that environment is the Internet where you have any number of browsers and operating systems to interact with.  Sure you think MAC, Windows, Linux, IE, Firefox, and mobile devices, but lets throw in another element most people don't think about - web browsing from a TV. 

Sure HDTVs have enough resolution from 2 feet away, but the issue is, people use their TVs from 10feet away or more, which effectively reduces your resolution because all of your fonts and images need to be double what they are on the PC.  Additionally the input device has changed from a mouse, to a remote control which also means you need to tab between buttons and hyperlinks, not mouseover - your fancy CSS rollover buttons don't work anymore.

Now try to get a page to look consistent across all these platforms and browsers!?  Good luck, its hard enough to get things to look consistent between FireFox 2.0 and IE7 on Windows.  What works in one browser for positioning and alignment falls flat on its face in another.  This leads to a lot of trial and error when coding up some HTML and CSS. 

I think this is why so many ASP.NET programmers hide behind ASP.NET server controls.  To touch the HTML and CSS is like assembly programming for a non-specific platform.  It hurts.  Building a nice UI for a TV doesn't fall into the realm of pre-built user controls, so I find I spend a lot of my time in "web assembly language."

At least when you're dealing with a complicated middle tier things are consistent, they either work or they don't.  Add in concurrency, threading, and scalability to your middle tier and you might have an argument that its as hard as UI programming.

Yeah, UI development is that kind of hard, especially when you throw in the subjective aspect of it.  Maybe that's why Mr. Coding Horror has so many blog posts about UI development.

Thursday, October 11, 2007 11:32:51 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [2]  | 
Friday, October 12, 2007 4:57:08 AM (GMT Standard Time, UTC+00:00)
I admit that I do prefer working in the middle tier versus working on the UI for those reasons you mention. It's not easy and it can be much more subjective...closer to art than science and far less predictable.

Check out this interesting and informative (and lengthy) article from Joel Spolsky on UI design:

http://www.joelonsoftware.com/uibook/fog0000000249.html

(My favorite is when he criticizes for its poor design the "the most moronic "wizard" dialog in the history of the Windows operating system" used when finding something in Help. I laughed because I remember back in the day that dialog box also confused me tremendously by the options it "provided".)
Vega
Friday, October 12, 2007 6:35:00 AM (GMT Standard Time, UTC+00:00)
After reading, and reading, and reading, I noticed that the URL contained the word "book". You weren't kidding when you said lengthy. I'll definitely have to finish this later, but so far its been really enjoyable. I really like the following paragraph as it really reminds me of our codebase at work. Principle of least surprise anyone?

"So the programmers spent a really remarkable amount of time writing some amazingly complicated dialog box handling code to work around the default behavior of Windows. (Being inconsistent is almost always more work than just acting like your platform expects you to act). This code was a big maintenance nightmare; it didn't port so well when we moved from 16-bit to 32-bit Windows. It didn't do what people expected. And as new programmers joined the team, they didn't understand why there was this strange subclass for dialogs."
Comments are closed.