I live in Adams Morgan, a multi-ethnic part of Washington, D.C. not far from the famed Dupont Circle and on the same street as the White House. Nearby is Meridian Park, a semi-green oasis in the middle of the city. At one end is an imposing statue of Joan d'Arc gifted to "the Women of America by the Women of France." On summer weekends, Joan is witness to a most amazing spectacle.

Many people, most male, and mostly from Jamaica, West Africa and Spain, congregate here with all manner of percussion instruments. The gathering is not formally organized and everyone is welcome. Each person just joins in with his/her instrument and makes some amazing music. It is quite a spectacle to see 20-30 people playing all manner of drums and the crowd enjoying/dancing to the most infectious beats.

As I sat and listened to the beats today, I found myself thinking about software. Weird, yes, but that is my passion and I inevitably draw parallels. In the drummer group, there is no leader and people join and drop out at random. As new people join, there is a clear dissonance, but gradually, they sync up, beat for beat until it is so perfect that you cannot help but look for the conductor.

I think about the similarities this has with designing a user interface. I am not very good at software engineering, but I do put quite a bit of effort into the user interface of my software. Creating the U.I. almost always starts off with dissonance. Even with planning and preparation, the initial result is seldom pleasing. It takes several iterations and many days, sometimes weeks, before everything starts feeling harmonious. It's like the drummers...you can't instantly sync up...it takes time.

Although I have no scientific data to back this up, I think that successful software has an underlying rhythm. Elements work together in harmony so they become invisible and actions have a natural flow. This is the signature of intuitive software.

When Microsoft unleashed ASP.Net on the world, it helped us take a giant step forward, but in the U.I. area, I think it was two steps back. ASP.Net has single-handedly resulted in the propagation of some of the most dissonant and horrible web user interfaces the web had witnessed. And this is not the first time Microsoft has done it. When Microsoft gave us VB, the same thing happened. By making it easy to create a U.I. by dragging controls around on a page, Microsoft unfortunately created the U.I. equivalent of a cancer. I cringe every time I see controls grouped willy nilly and adorned with superfluous fonts, lines, colors, bevels...you name it. This stuff eats away at app usabililty.

With ASP.Net, my pet peeve is the "auto-postback." Whoever put that into ASP.Net should be drawn and quartered. And developers who use it deserve the same. For instance, few things are more horrible in a U.I. than to have a page postback when the user makes a selection of a dropdown item to populate or reveal additional form items. Extreme dissonance! This should be done client-side, and not server-side. If there is a lot of data, use XMLHttp. There is no excuse for postbacks that occur without a user click action on an actionable user interface element (i.e. button, icon, hyperlink etc.).

When I evaluate web software, I look at the usability first and the capability second. My rationale is that if it is not usable, who cares what it can do. If I see that the app is an ASP.Net app, I have a litmus test. If I go make a dropdown, radio button or check-box selection and the page posts back, I am done evaluating. As far as I am concerned, the app is unusable. That said, my favorite portal DotNetNuke abounds with instances of this. So although by my definition it is unusable, I continue to use it for two reasons: (1) it has a lot of other positives, and more importantly (2) being on the core team, I am empowered to change this, but haven't, so I consider this my own fault.

Anyway, I work around it by never using any of the built-in DNN modules other than the registration (which I hope to change some day, because the postbacks on it drive me nuts). With version 3.x, my worst fears were realized. Now, DNN settings pages sport collapsible sections that -- you got it -- post back, to expose more fields. Arrrrgggghhhhhhh!!!!! I would like to fix it but my biggest fear about fixing some very obvious problems with the DNN U.I. is that I am afraid to break some functionality in the process. DNN has so many moving, interdependent parts that this is actually quite easy to do. I know I should get over this unjustified fear and fix things. Someday soon I will work up the courage to do it, until then I will present mini-fixes through my blog as I have been doing and live with the dissonance.

I find social networking technology quite exciting. FOAF (Friend of a Friend) is an interesting specification. It is designed to allow computers to understand the relationships between people using RDF/XML.

There's not much buy-on to this right now because it is squarely in geek territory. I suspect that as soon as Friendster and Orkut figure out how to monetize their networks and publish an API, this might die off. On the other hand, it is conceivable that FOAF becomes the API to expose social networks to outside developers.

Give the Foaf Explorer a whirl.

I am working on implementing a WebDAV server for ASP.Net. Yes, I know this capability is built-into IIS6, but unfortunately, it requires that you enable WebDAV on the server, creating a big security hole. Additionally, the built-in implementation is unable to authenticate against a custom membership provider. In any event, my solution is a drop-in component that instantly enables WebDAV capabilities for any ASP.Net app.

One of the challenges when developing any app that relies on headers for passing commands back and forth (as WebDAV does), is that debugging is quite challenging. I explored several tools to sniff HTTP traffic, including a few that were implemented as ISAPI filters. I found all to be cumbersome and requiring sever-side installation. There are many IE add-ons that do this also, but since I am working with WebDAV, there is no browser in the equation. It's purely traffic between Windows and a WebDAV server. 

I had resorted to logging to a file from within my app, until I chanced upon HTTPLook. Wow! This app is awesome. It not only does exactly what I want, but it also has a simple and elegant U.I. (important to me) and has excellent features such as filtered capture etc.

My WebDAV development has become several orders of magnitude easier, thanks to this tool. And as a bonus, the app comes with a CHM help file containing the entire HTTP spec. Too cool.

Many customers of my File Manager Pro module have asked for the ability to edit documents directly (i.e. click on an edit icon in the file listing in their browser, then edit and save the document). This is easily done for text-based files, and indeed that capability is already implemented. However, for files that require a client-side application, this is not at all simple.

Let's use Microsoft Word as an example. If you click on a Word doc link in your browser, by way of the mime type (or extension as a fall back), the browser is able to determine which application should be launched. It downloads the file to temp storage and then passes on the location to the app after launching it. Any changes made to this document are made to the copy in temp storage and have no bearing on the original file on the web server.

To facilitate the editing of documents on web servers, both server and client must support WebDAV (Web Distributed Authoring and Versioning), a protocol that extends HTTP by defining standards for web document authoring, versioning and publishing. IIS5 and IIS6 natively support WebDAV (although the capability is not on by default.). Windows XP and Mac OS X natively support the ability to map/mount a WebDAV collection as a virtual drive. All Office apps, most Adobe apps, and many other popular applications support the ability to transparently work with documents using the WebDAV protocol. So what's the problem?

For servers on an Intranet, it is easy to enable WebDAV and create an easy to use shared document area. But then again, on an Intranet, why bother when you could have a shared drive. In a hosted scenario, WebDAV is much more difficult to implement due to the security concerns it poses. Currently, IIS does not provide a way to enable/disable WebDAV on a per web basis. So if a hosting provider were to enable WebDAV it would potentially compromise all websites on the server that were not properly secured. For this reason, WebDAV support in hosted scenarios is almost non-existent.

Also non-existent (as far as my Googling indicates), is a "server" API for a custom WebDAV implementation using ASP.Net. There are many client implementations, but if you want to be able to have WebDAV clients access a database-driven document repository, for example, you are on your own. This brings us back to File Manager Pro.

I was quite intrigued by everything WebDAV had to offer and so started doing some testing. I was pleased to find after a few hours of coding that it is possible to write a custom WebDAV server that works on ASP.Net. And so that is precisely what I am going to do. I am going to implement this as a generic API first and then use the API to add document authoring and versioning capabilities to File Manager Pro.

So far, I have tested getting a directory listing and editing a document. I have not implemented saving it, but I know it will work because my IIS logs show the request coming in with the right content.

This is quite exciting because it opens up File Manager Pro, and indeed DNN, to a whole new level of document collaboration. I am quite interested to see how this API may be used in different DNN modules in the future.

Order of events in the lifecycle of an ASP.Net page: