I did an overhaul on the look of my blog because I had an actual visitor from the outside world.  I feel like Sally Field winning the Oscar: "you like me, right now, you really like me!"  If figured I'd give it an extra touch of CSS geekiness.  I hope you like it.

Apparently, Internet Explorer doesn't like it very well.  If you scroll down the page, the size of the DIV elements changes for some entries when you use either the scroll bar or the mouse wheel.  This is just plain bad.  I know that MSIE 6.0 had this problem, but they still haven't fixed it yet?  What's up with that?

Here is what it is supposed to look like:

And when MSIE 7.0 messes up it looks like this:

Notice how the space is too wide and the subject title is stuck in the margin.  Scroll one more notch and it's OK again.  Send this one back!

BTW, the blog looks just fine in Firefox.

I just came across an article from Jakob Nielson's UseIt.com web site concerning Weblog Usability.  I figure I should go ahead and take the test and see how my own blog stacks against the ideals of the guru.

Top Ten Design Mistakes in Weblogs:

1. No Author Biographies - Not guilty

I have my real name and some real info about myself in the "What's this?" box to the right.  If you visit my home page, you can even download my resume.

2. No Author Photo - Not guilty(anymore)

Yes, I have posted an unflattering, but honest picture of myself.  I do have a nice picture of myself that was taken at my wedding by a professional photographer almost 17 years ago.  I don't think I can really use that, though.

3. Nondescript Posting Titles - Not guilty

I just barely squeaked by on this.  I try to title each blurb accurately, and when I'm in a playful mood I may throw in a double entrendre, such as "Nutty Warnings".  Some titles are lame, I admit it.  I throw myself on the mercy of the court on this count.

4. Links Don't Say Where They Go - Not guilty

This is classic Web 101 fare.  Search engines look for this; SEO depends on it.

5. Classic Hits are Buried - Guilty

The dasBlog software doesn't lend itself to breadcrumb navigation, and I have been too busy/lazy/apathetic to do anything to about it.  I don't have any real "hits" because I have so few readers that it probably doesn't matter.  I'll get off with probation on this.

6. The Calendar is the Only Navigation - Not guilty

I do add categories to each blog entry, honest, officer!  Once again, I'm at the mercy of dasBlog on this one because it show categories in a linear fashion instead of a hit-based or frequency-based heuristic.

7. Irregular Publishing Frequency - Guilty

I have not made a serious attempt to publish regularly, even though I can write quickly.  As they say in the Holy Grail, "I'm getting better".

8. Mixing Topics - Guilty, Guilty, Guilty

The fertile crevices of my brain are aching to explode with information to tell the world.  While I do try to keep the topics programming-related, I suffer from ADD of the fingers.  What was I writing about, now?

9. Forgetting That You Write for Your Future Boss - Hung Jury

I have deliberately refrained from including profanity and NSFW content from my blog.  So I get a silver arrow point for that.  Some people might be offended by my cheeky humor and unabashed assessments.  If that's the case, then they have a problem with my personality.  One of my criteria for accepting a new position is that I can get at least a chuckle during the job interview.  If my boss has no sense of humor, chances are he will melt down or blow up during a difficult situation, which will make my own life miserable.  So I guess in a way you can say that I am writing proactively in self-defense.  Yeah, that's it.

10. Having a Domain Name Owned by a Weblog Service - Not guilty

Oh, c'mon!  You can't spring the $7 a year it costs to have your own domain name?  Personally, I'm helping fund Bob Parsons' kids' college education.  But let's not go there.

The Verdict

Cleared on six counts, found guilty of burying the evidence, negligent publishing, and crossing the center line of my weblog.  I am hereby put on probation and required to attend a defensive blogging class as well as blogger sensitivity training.

Now, how well will YOUR blog stand up?

You've seen Google spreadsheets and online word processing.  But how about Visio diagramming?  Introducing Gliffy, a free service for drawing diagrams reminiscent of Visio and sharing them online.

Here's one I tried.  It's not quite up to Visio standards, but not far behind either.

At CodingHorror.com, Jeff shows how to make your website look good on a mobile device.  It's pretty easy.

<link rel="stylesheet" href="http://www.yourdomain.com/css/styles-site-mobile.css" type="text/css" media="handheld" />

Unfortunately, you still have to download all the HTML as before, but at least it will look nicer.  And CodingHorror does look swell on a cell.

http://www.codinghorror.com/blog/archives/000782.html

I recently tuned into the podcast on IT Conversations, hosted by Phil Windley, and featuring David Platt, .NET programmer and author of the new book "Why Software Sucks".  In the podcast, Platt adds some new light to problems of user-facing software (as opposed to programmer-facing software).  Much of what he has to say has already been covered in Alan Cooper's unforgettable book, "About Face".

So what makes some software suck?  Software is supposed to make our lives and jobs easier to accomplish.  When software makes it difficult for a user to do things, or forces the user to remember things, or demands that the user do a complex dance with her keyboard and mouse, then that software sucks unequivocally.

But if you visit the computer lab and ask the programmers what makes software suck, they will have a totally different perspective.  Code that's hard to read, lack of unit test coverage, tight coupling of objects, redundancy: these are the problems that make software suck.

My opinion is that you can have the most highly refactored code, in all of its object-oriented goodness, and the software can still suck.  My fear is that there are many devotees of Martin Fowler and Uncle Bob, who in their own minds believe they are writing great software, but realize only after it has been foisted on the end user that it actually sucks.

When I tried to de-suckify a feature in the web application we recently released, I was often met with fierce resistance from programmers, whereas the business analysts were very open to new ideas on how to make the software more user-friendly.  One example was when we were required to build an interface whereby a loan representative could transfer the responsibility for a loan application to another loan rep.  In our lingo, this is called "pushing a loan".  The original specification required that the end user would enter the name of the receiving loan rep or their office then run a search against the database.  I believed that this method would be error-prone and that there ought to be any easier way.  I sat down with the business analyst in charge of this new feature and asked her "What do people use this for 90% of the time?"  She stated that most often, people would push the loan to someone else within their own loan office.  So I asked how she would like it if, when the user first selects the feature, he is presented immediately with a list of the loan reps from his own office, and that this list would precede the search function on the page.  The business analyst thought this was an excellent alternative, and she went to draw up the new plans.  Back in the development lab, things ran afoul because "everyone knows" that the search function "has" to be the first thing on the page.  This was going to "break the convention" of the look and feel of the rest of the web application, and this self-imposed directive should take priority over giving the user what they truly want.  Also, this alternative was going to require extra programming that we had not originally planned.  I stood my ground on the customer's behalf, and ultimately we all did agree on this alternative presentation of the UI.  But this incident illustrates that sometimes even software developers who are in good communication with the end user will fail to have the end-user's best interest as their top priority.

In our development shop, we developers would often lapse into the flawed mentality of "the customer's always right", and I have been just as guilty as others on this.  The customer would dictate the requirements and the developers' task was to merely implement whatever they came up with.  Occasionally, the customer would ask for something so goofy that we developers would have to put our foot down and everyone would go back to the drawing board.  Such are the risks of assigning the responsibility of software design to the customer, in this case the business analysts.  The business indeed knows best what the business needs, but is typically not the best choice in deciding how to get there.  The developer has the knowledge to create whatever a specification calls for, but his knowledge of the business need is often very shallow.  This leaves a disconnect between the customer and the developer.  This disconnect was partially alleviated by the agile process we used, during the breakout sessions.  These sessions are great at defining the business need at a high level that could be understood by both business analysts and developers.  These session are not so good at defining the user interface.  And user acceptance is all about the interface.

In Cooper's book, "The Inmates are Running the Asylum", he introduces the concept of the "interaction designer", a person who's job is to define the user interface and overall orchestration for a software project.  In software development circles, the "architect" is more like the lead programmer who has view of the entire system as a whole, including database structures, development frameworks, and the code base.  Cooper's interaction designer is more like an architect in the real world, and they are not so concerned about the mechanics of making it happen as they are with getting it absolutely right with the customer.  Programmers don't necessarily make good interaction designers, because of their intense focus on the "how" of creating software, they lose sight of the "what".  The interaction designer is not so concerned that the chosen framework doesn't directly support a certain feature, they are focused on the end product, and have the artistic license to devise the product so that it works intuitively and flawlessly for the end user.

In Platt's interview, he does not acknowledge many of his observations that have already been articulated at length by Cooper.  He does offer a few helpful tips for both end users and developers.  His tips for developers include:

1) Make sure the project includes a "virgin" - that is, someone who is knowledgeable in software development but comes to the table with a clean slate, unaware of the software currently under development.  This fresh perspective will cause new ideas to bloom outside of the box of groupthink that evolves within a development team.

2) Be willing to break with convention. Doing things the way they've always been done is no longer good enough.  If you can't find the right GUI widget from your class library, get a better class library or build it yourself.

3) Don't let edge cases complicate the mainstream.  Programmers tend to write software that is mathematically correct, when they should be focused on making the actions and decisions most often taken by the end-user the top priority. Platt says that it should be easy for the user to do things that are "good, smart and safe" and difficult for users to do things that are "bad, stupid and dangerous".  Platt also demonstrates that it's faster and easier to track a UPS delivery by searching the UPS tracking number in Google than it is in UPS' own web site.  In Cooper's "About Face", he makes the absurd analogy of putting the eject button right next to the radio switch in the pilot's cockpit.

4) Instrument the user experience.  Today's software allows you to be able to report on the user's experience, so you should monitor how the user uses the software and then use that information to improve the software for the user's actual needs instead of their stated needs.  If your software is a web application, the simplest thing you can do is monitor the web server logs, but you can even do more than that.

One of the problems I see with judging software usability is that it relies on subjective experience.  There is no one good metric to determine how much a piece of software sucks or doesn't suck.  Aesthetic appeal is the first thing that hits the eye, but the lasting impression is the ease of interaction.  For instance, my T-Mobile service lets me pay my bill over the phone, and I don't even have to push a single button; its voice commands are intuitive, succinct and accurate, and I have even paid the bill while driving.

I'll have more to say about these issues on future blogs.

I found an interesting alternative data access layer (DAL) to NHibernate called SubSonic.  It was formerly called "ActionPack", but I guess there must be enough confusion with Microsoft's "Action Pack" that they changed the name.  SubSonic is open-source (MPL)

SubSonic has been hailed as "Ruby on Rails" for .NET developers.  There is a screencast of it here, prepare to be amazed.  It works kind of like this:

1) Add a reference to the SubSonic DLL
2) Modify your web.config with connection string info and SubSonic build provider info
3) Build the project
4) ...
Copyright (C) Sidney Harris.

5) Amazing!  Domain objects and data access layer have been automagically created!

I foresee this as a great way to quickly get a data-driven site up with a minimum of development effort.  Realizing this is not the end-all and be-all of data access, you are still free to use "traditional" ADO.NET techniques.  A recent benefit is that CodePlex has come out with an XmlProvider, so that if you would rather persist to XML instead of a database, it can handle that data access layer, too.  This thing keeps getting better and better.

Recently, I bought my wife and myself his-and-hers Windows Mobile 5.0 gadget phones.  Now I'll admit freely that I'm not a huge cell phone user, and I've always considered maintaining a cell phone as a necessary evil in the consulting world.  Since I have been experimenting with the .NET Compact Framework SDK, I figured this could have potential in software development projects I'm working on.

What is truly amazing is the amount of power that can be packed into one of these little devices.  This device, the T-Mobile MDA (link) has built-in WiFi, bluetooth and infrared beaming, it synchs with Outlook, et al, using ActiveSync, it comes with a mini MSIE (approximately IE 5.5), Pocket Word and Excel, a PDF viewer, some games, and other stuff.  There is a plethora of free and commercial software for the phone, and I downloaded a Command Prompt program and a Registry Editor.  Using Visual Studio 2005, you can easily develop and deploy your own .NET software to this device, including SQL CE 5.0, which comes with a cute little Query Analyzer for ad hoc querying and debugging.  Equipping this device with a 1 GB MiniSD memory card gives you ample room for about 100 MP3s that you can play with the mini version of Media Player.

Oh, and did I mention that you can make and receive phone calls with this device?

It is amazing that this thing runs on about 500 MHz processor and delivers this kind of punch.  When I think back to my first PC, that I bought 13 years ago, this little gadget blows it away.

I love almost everything about this device except for one thing: most web sites look downright awful on the web browser.  Nearly all web sites are designed for 1024x768 screen size, with the assumption that the user will be using it at a desktop or laptop.  Most web sites use a boatload of graphics, with the assumption that bandwidth is not a problem.  When my device is connected via WiFi, this really isn't a problem, but more often I connect to the Internet using GPRS, which is much slower a typical broadband connection and more latent than even a dial-up modem connection.

As a developer, I see the conundrum. Today, most people do not use mobile devices to browse the Internet.  But I bought this device for $249 last year, and I am sure that it will be half that price by the end of the year.  Why would I want to develop a web site for such a niche market?  Until Firefox started gaining popularity, I only designed for MSIE since that was biggest target.  But thinking forward, the mobile web market is poised to boom in the next two years.

So what choices do we have as developers?  We could work by redesigning one site at a time to comply with the new miniature standards.  This is a large development effort and will cost businesses a lot of money to implement.  Do I think this will actually happen?  Only the largest companies or the ones most directly involved in web businesses will do it.  For instance, GoDaddy has a mobile web interface that I used to register a domain using my gadget phone.  But most vendors are not doing this yet.

So what about medium to small-business web sites?  I think there needs to be a handly plug-in the can convert a web site to mobile formatting when a mobile web browser makes a request.  My idea is that I could create an HTML proxy that makes the actual HTTP request from the web server, but then reformats the HTML and imagery that is sent back as a response.  Current mobile web browsers make the full request and drop formatting on the client.  An HTML proxy that can be installed on the web site would provide an alternative where the crash diet occurs on the server, resulting in faster loading web pages on the mobile web browser.

My thought is that there would need to be certain flavors that are available immediately.  Most dynamic pages are written using PHP, ASP and ASP.NET these days.  These would be the immediate target systems.  I have yet to flesh out the details of this server HTML proxy, but I'm going to be investigating this this year.  If you are interested in enabling people to use the Internet more effectively please e-mail me.  I think this is a pretty good idea, but I'm willing to listen to better ones!