Wow! It's taken me a day to get over the exhaustion of Podcamp Atlanta 2007. Kudos to Amber, Rusty, and Penny and everyone else involved for pulling off such a great event.

So I sit down and sort through all the new business cards I collected, and it occurs to me that I can't remember half the people I spoke to by business card (the good news is I did remember the other half!) Which is when it hit me; why don't people start putting a photo URL on their business card? For example, here's mine (notice the Well Designed URL :-), but of course it's not yet on my business card:

Photo: http://www.mikeschinkel.com/photo/

Of course, that begs the question of a Personal URL on a business card. A person's personal URL is a URL that points to their personal "About" page, and I think everyone should get one. Of course that URL should also have a photo:

About: http://www.mikeschinkel.com/about/

Note My "about" page points to the "About Me" category on my blog, but I plan to write a good concise "about" page in the near future. And my next business cards will have my photo and my about URLs listed.

technorati tags: business cards, photo url, personal url, about pages, podcampatlanta2007, podcampatlanta, podcamp, atlanta

Well, yes as I've already said, I'm not a super-timely blogger. I should have blogged this long ago, but ah well.

Anyway, Amber Rhea of The Georgia Podcast Network organized a Podcamp here in Atlanta for this weekend March 16-18 2007 at Emory University. An as of yesterday when I asked, Amber said that she had 185 people registered!  Wow.  Another event like SoCon07; I can't wait!

But this one is going to be special for me as I get to hold my first discussion on Saturday about User-Centered URL Design. What's that got to do with Podcasting, you ask?  I'm not sure either, but Amber assurred me that attendees would be interested. :-)

But seriously, podcasters has many of the same issues to address that everyone publishing on the web should consider including usable URLs for their audio files as well as the website that hosts them. I look forward to some likely discussions!

technorati tags: podcamp, atlanta, url design

Back in July of 2006 someone asked on the forum for ASPnix, the web host that specializes in CommunityServer, to add ISAPI Rewrite to their servers so that customers can clean up their URLs. Seven people including myself chimed in asked for it. Over the past eight months, little was said by ASPnix except by a former staffer who implied it was harm the stablity of their servers and who really gave no indication that any real consideration was being made to offer a solution for URL Rewriting.

Well finally, on Feb 22nd, Roma confirmed that ASPnix has will finally be offering ISAPI Rewrite on ASPnix's web servers. That's yet another IIS-centric web host who has finally freed its customers from the shackles of poorly designed URL Hell! Hooray!

Now let's just hope that Scott Watermasysk can be convinced to add URL Rewriting support in CommunityServer using ISAPI Rewrite to eliminate .ASPX extensions and more on CommunityServer, sooner than later.

Technorati Tags: ASPnix | ISAPI Rewrite | URL Rewriting | IIS | Web Hosts| Teligent | Scott Watermasysk | CommunityServer

When it comes to programming on the modern-day GUI (post-DOS) platform, the vast majority of my coding has been, in order of experience, using T-SQL, VBScript in ASP, and about equal parts classic VB (v3.0 to v6.0) and VB.NET. As you can see from my order of experience, I'm really a database guy, and since the beginning of the web I've always viewed the web as somewhat of a database publishing environment (anyone remember the DOS product dbPublisher Pro from Digital Composition Systems?)

What's more the web allows a potentially infinite number of people to use a developer's database publishing apps without any extra effort to distribute them. Finally, the web provides ability to capture evidence the apps were run, how often, and by how many people. Is it any wonder I have more of inclination to develop for the web as opposed to desktop applications?

Back during the period from 1994 to 2006 when I ran VBxtras/Xtras.Net where we where a reseller of ActiveX controls and then later .NET components, I never really thought about the cost of add-on components. Almost anything I wanted to play with I can get an NFR (not-for-resale) copy just by sending an email or picking up the phone. Although I still have many of those relationships from a decade+  in the business, I hesitate to ask for NFRs these days except from my really close friends simply because this business I'm in today has nothing to do with benefiting those people.

So numerous facts have me giving up on my prior five year assumption that I would someday learn VB.NET at an advanced level and have me instead actively considering alternatives:

1. As I just stated, the fact I now have to pay for third party components and tools means I'm paying more attention to cost of acquisition,
2. My recent favorable impressions of open-source developer tools and components, on par with some of the best tools ever sold by Xtras.Net,
3. My increasing frustration with the Microsoft developer division's process and release cycle,
4. All best web applications seem to target L.A.M.P. such as Mediawiki, WordPress, vBulletin, Subversion, Trac,  Ruby On Rails, Django, etc. and all but one of them are free to use
5. Completely preconfigured stacks (including O/S) that are becoming available for download as a VMware appliance,
6. Recognizing that Ubuntu's has an approach strategic enough to result in Microsoft being profiled in a revised edition of Clayton Christensen's Innovator's Dilemma as yet another example of why great companies loose their leadership position,
7. And lastly my rising disgust for ASP.NET (and I promise I will blog about those specific soon...)

By the way, even though I dislike ASP.NET, I do still really like the .NET Framework and programming model.

Oh and a note about the first point; whereas there is good open-source tools available for .NET, the operative word is "tools" not components. When you compare what's available to freely use for .NET compared to what's available for any of the "P"s (Perl, Python, and PHP), .NET just can't compare, at least not in depth or breadth.

Of course being commercial products the .NET third party components are more polished and of course have commercial support available. However, unless you are big company that needs to CYA and have a throat to choke, those are often dubious benefits especially when you consider the benefits of open-source (i.e. source code, and the ability to fix something and contribute it back so you'll know it stays fixed!)

Anyway, I could write for hours on the pros and cons for open source vs. commercial developer components and tools but that's not the subject of this post. The subject is about which language I will focus the majority of my future attentions on learning and using, and I'd love to get your input before I decide. Here are the current contenders:

PHP

All the major web apps I mentioned above seem to be built using PHP and I'm currently running many of those apps, PHP is pretty similar to the ASP that I know so well, it's web-specific, there is a huge support community, it runs on both Windows and Linux, and every Linux web host known to man seems to offer it preinstalled. However, there seems to be lots more crap PHP code examples littering websites than good PHP code examples making it harder to learn so it might be hard to seperate the wheat from the chafe, it is not easy to configure on Windows Servers (especially at a shared web host), and no one individual framework seems to have gotten the lion's share of the market attention so picking one would be a crap shoot. Oh, and it uses those infernal semi-colons just like C#.

Ruby on Rails

Ruby and it's framework Rails have gotten tons of attention and it seems all the cool kids are doing it, especially lots of the Web 2.0 startups, it is very database-centric, has very elegant URL mapping functionality, and it seems you can get web apps built really fast using it. And Ruby.NET is also on the horizon meaning I might be able keep my toe in .NET. However, the community comes across as just a little bit too religious and I'm generally alergic to that, AFAIK it doesn't run on Windows, or at least not for shared hosting. Plus I've had people I respect tell me that Ruby doesn't have nearly as many users as the "P" languages, that Rails it not nearly as mature as its purported to be, and that Rails makes simple thing simple but complex things extremely difficult. And the number of available web hosts that offer it is quite limited.

Python

Unlike PHP, it seems Python is well suited for both web and desktop apps, which might come in handy from time to time, and a shipping IronPython means that I definitely can keep my toe in .NET. The Django framework seems to be a little more mature and have a little less religion than RoR, and Django also has nice URL mapping functionality, albeit slightly less elegant than RoR. And it seems to run equally well on Linux and Windows. However, Django seems more document publishing-centric and less database-centric, there are very few web hosts that support DJango, and I've heard it is a real bitch to get working on a web host.

VB.NET+Castle/MonoRail(+Mono)

But then again, maybe I will stick with VB.NET. The Castle/Monorail project is supposed to be a lot like RoR, and I'd even have the option to use Mono on Linux. However, the third party tools are definitely wanting, most web hosts haven't a clue what Mono is, and they coded Castle/MonRail in C#, so I'd always be dealing with semi-colons...

ASP+IIS+JScript

I could stick with ASP, which I still like, and learn JScript to replace VBScript, the latter of which just has too many limitations when compared with the other current options. This clearly also runs on Windows and any Windows web host will support it, and I already know Windows backwards and forwards. On the other hand, I'll need to use ISAPI Rewrite for clean URLs, JScript on ASP it has no future and few code examples on the web, and what third party components and tools (to speak of...)?!?

ASP+IIS+VB.NET

I could also use develop VB.NET objects and call them from ASP; that's what we last did at Xtras.Net (and I think that is what they are still doing, last I checked...) Of course, calling .NET objects as ActiveX controls just doesn't feel right, and again there's that third party component and tools problem...

PowerShell+IIS+???:

Of all the teams working on tools for developers over at Microsoft, the PowerShell team run by Jeffrey Snover is the only one that gets me excited anymore. And in an email from him (or was it a comment on my blog, I don't remember exactly) he said that PowerShell can do web, and will be able to do it more easily in the future. On the other hand, it's not here today, and what if webified PowerShell is just another way to do rubbish ASP.NET instead of what it should be, a url-based object-selector-and-invoker like Django or Rudy on Rails.  And what's the chance it will ever run on Mono...?

Other:

Is there anything else do consider...?

At this point I should probably explain what I'm not considering, and why:

Java on Anything:

Although I was really impressed at a Sun Tech Days recently here in Atlanta , even the Sun people were all over dynamic languages with praise, like Jython and JRuby. And though I was impressed with NetBeans 5.5, all the other "enterprise" baggage like J2EE and Servlets and JSP Custom Tags gives me the feeling I'd be jumping out of the frying pan and into the fire.  Oh, and Java uses those infernal semi-colons too.

C# on Anything:

One word: semi-colons!  Sorry but if I'm going to go .NET, it's going to be VB.NET (or IronPython). VB.NET is so much more natural to me than C#, and there are things you just can't do in C# that you can do in VB.NET related to using "implements" on a method in an inherited class (I ran into that limitation of C# compared to VB.NET on a project several years ago where I was managing a pair of interns coding in C# and they hit a wall because of that limitation. I can dig it up if anyone cares, or better yet, can someone who knows the specifics explain it in comments?)

Perl on Apache:

Although my partner on Toolicious Ben Coffey who is a devoted disciple of Perl will cringe to hear this (yet again), I can't quite get my head around Perl, and they tide, at least today, is away from Perl. Of course Ben claims that will all change with Perl 5.0, but to me that remains to be seen and I'd rather go with a bird in the hand (i.e. one with a lot more active current user base) than a bird in the bush.  But who knows, they say you should learn a new language every year; at any rate if he's right maybe I'll try and pick up Perl 5.0 in around 2012. :)

So there you have it: my potential choices and non-choices. Any thoughts I which I should choose?  Any and all input will be appreciated and considered seriously.

Back in January 2006, I blogged about how much I wanted an IIS 7.0 that handles extensionless URL rewriting. Well this week I just got my March 2007 copy of Microsoft's MSDN Magazine in which they ran a detailed technical preview of the features and functionality of Internet Information Server 7.0. Reading through it, I found myself salivating over it's capabilities that I've needed for literally a decade. Those who follow some of my other escapades know that the #1 feature I want it to provide over IIS 6.0 and prior is the ability to fully control the URL with our without an extension.

Yet, something is different now. Five years ago I would metaphorically have killed for that functionality. Even a few years ago, I wanted it badly. But reading about all the great things in IIS 7.0 today for future availability on server hosting platforms next God-knows-when (i.e. after Longhorn ships *and* most Windows-offering web hosts upgrade) sadly comes across to me as just too little, too late.

Too Little

Too little because Microsoft won't deliver IIS 7.0 to run on Windows 2003 Server necessitating a costly and in some cases problematic operating system upgrade. This will drastically limit the number of situations in which people can choose to switch to develop for the new features of IIS 7.0. For example, when the funds for operating system upgrades are not in the budget or simply because the developer doesn't have the corporate clout to convince management of the need to upgrade. 

And the only people who will even be able to experiment with IIS 7.0 will be those with Windows Vista. And since upgrading to Vista also requires funds and often new hardware, it is not a foregone conclusion. Consequently there will only be a small percentage of Microsoft-centric developers writing web apps that uses the functionality of IIS 7.0 over the next several years. Given the limitations of IIS 6.0, I just find this scenario to be unacceptable.

Too Late

Too late because Microsoft's outdated process and slow release cycle, which I blogged about last month, has given rise to compelling alternatives on the Linux platform.  And Apache has has many of the key features that IIS 7.0 provides, most importantly via it's mod_rewrite functionality, that by the time IIS 7.0 is ready for prime time, there's a good chance only a tiny percentage of web developers will care. I for one need to develop web apps I can run on web hosts today, not wait around and dream for some yet-to-be-determined future brighter day.

Microsoft, the rules have changed and you are not immune. You can no longer schedule product updates years out and expect people to wait to pay you for them years from now when free-to-use open-source alternatives addressing the same need exist today. I can no longer bring myself to design or run a web app on IIS 6.0[1] when the URL management functionality I crave is already available on Apache. And by the time IIS 7.0 is released I doubt I'll even consider running an IIS server.

Unless...

However Microsoft, there is a solution if you will only listen, which I highly doubt. Microsoft You should know more than any other tech company that your key to success is getting developers to write programs for your platforms. Yet on the web developers are voting with their feet and most new web applications not sponsored by a "You don't get fired for buying Microsoft" large company IT organization are choosing to build on Linux and Apache.  IIS was once the leading server on the web, but today it can barely eek out more than 1/3rd market share. If you don't stem this time, things will only get worse. Much worse.

Here's what to do: Release IIS 7.0 as an update for Windows 2003 Server and Windows XP that gets installed automatically via Windows update. Offer it in parallel to IIS 6.0 so it must first be configured by an admin and IIS 6.0 disabled, if necessary. Feel free to restrict it in whatever ways you must given 2003/XP's lack of Longhorn/Vista infrastructure, but don't use that as an excuse to eliminate key features such as URL management and HTTP response filtering. Doing this won't change the minds of those who have already given up on Windows, but it will certainly minimize the profuse bleeding.

Footnotes

1. Given how much I dislike ASP.NET and how frustrated I am with IIS 6.0, I can't wait till I find the time to move my blog to another program besides dasBlog.

Over on the Well Designed URLs Initiative blog, which is my baby, I've started a call-to-action to get people to use delicious to tag:

URLs that Suck!

Check it out, and then be sure to tag any especially bad URLs with the tag "urls-that-suck" on delicious.

So I'm excited that I just got my express delivery of Wrox's Professional Web 2.0 Programming by Eric van der Vlist, Danny Ayers, Erik Bruchez, Joe Fawcett, and Alessandro Vernet.  I'm anxious to read it to learn their take on programming for Web 2.0.

I first learned of the book when I noticed in my logs that their website http://web2.0thebook.org/ was linking to my Well Designed Urls are Beautiful blog post from last year. I then noticed they had a link to an excerpt from their book with the excerpt being titled: Future-Proofing Your URIs[1]; clearly a topic that I am interested in.

What's more, cracking the book I find they additionally have an entire chapter on HTTP and URIs; excellent! I look forward to reading this and letting you know my impressions.

----

[1] I finally learned a clear distinction between URIs (indentifiers) and URLs (locators). Whereas a URI  uniquely identifies a "resource", a URL not only identifies it but also lets you "de-reference" it (i.e. access it and/or download it.)

I came across an interesting piece of software called InstallPad via SDTimes "News on Monday" email newsletter. InstallPad is designed to download and automatically install applications on Windows machines. Relatedly, ever since I first installed FireFox I was very impressed with what a great design they had implemented in their add-on updater. I believer that InstallPad works in a similar fashion.

InstallPad might become really big...

InstallPad was developed by a recent University of Maryland graduate Phil Crosby who evidently interned for both Microsoft and IBM.

Although InstallPad is actually a pretty-simple idea I could see InstallPad become very popular very quickly. It has a viral quality to is that makes me wish I had developed it. As InstallPad can solve a problem for software developers by distributing software updates to their customers, I could see software developers motivated to distribute InstallPad for Phil. All that software developers would need to do is either include InstallPad with their software and/or point their customers to the InstallPad download page. Finding a motivated group of people who can help you succeed is the mark of a true viral strategy.

InstallPad has got all the right attributes. Phil even opened his source code on a subversion server and is asking people to contribute.

And I think he's got that potential...

...Except!

Except for one problem. For some unknown reason (I haven't contacted him to ask, I decided to blog it instead), Phil decided to license InstallPad for Personal Use Only! Instead of using an existing open-source license approved by the Open Source Initiative Phil decided to roll his own and disallow business use. Even though he was quite excited to be frontpaged by Digg his choice of license is going to all but neuter any chance of InstallPad becoming significant. 

Phil probably wants to reserve the right to sell InstallPad to companies as he claims he is working to form a startup. But that is exactly the wrong strategy. In order for InstallPad to be really successful it will need to have a significant percentage of the Windows user base in a given market segment, and I'd estimate that "significant" would need to be at least 30% if not more like 60% or 70% (with a caveat, in a moment.)

Why is having a large percentage of user in a segment so important? Phil needs vendors and software developers to see InstallPad as worthy of support. Because InstallPad could solve a problem for software vendors without them requiring to do much work, it could be a win-win. But only if it gains a significant user base first OR if the software vendors can distribute it for free. (that's the caveat.) But requiring InstallPad to be purchased for commerical use eliminates the second option and creates friction that minimizes growth of the user base. Alternately, if software vendors are free to distribute Installpad, they could start making their updates available in a InstallPad-friendly format, at an InstallPad-friendly URL, and with InstallPad-friendly configuration files. That would drive InstallPad adoption and increase the number of software applications with which InstallPad would work seamlessly.

Now you could counter with "Phil doesn't have to do anything special as it can work with existing software as-is," but the reality is there are hundreds of little gremlins that will cause InstallPad to fail and/or require an end-user of InstallPad to have to fiddle to get his app to upgrade. And each time a users has to figure out why InstallPad is not working is one more chance for them to decide InstallPad's is not worth the trouble.

Or you could say "People can just use it to download open-source apps from SourceForge which already has a compatible Url structure." But don't you think it's rather ironic to have a product downloading and installing open-source that itself is not open source?  I think users will view it the same and shy away from it.  And it's not the type of software that is likely to get a lot of contributers if it is not truly open-source.

The other issue Phil has to concern himself with is that the idea is not very hard to duplicate, especially since Phil offers the source code for public viewing. How long would it take an unethical person to building his own from scratch after viewing the source?  On the other hand, nobody needs to be unethical; they could just reverse engineer it. From what I saw it wouldn't take long for a pair of professional programmers to duplicate it.  And as soon as someone creates an alternative and licenses it via an approved open-source license their new software gain a large user base much more rapidly. And Phil will be left with having had the great idea first but ultimately InstallPad will become insignificant.

So InstallPad's greatest potential hedge against competitoon is an installed user base, and Phil should do everything possible to minimize friction to growing that installed user base.  Which means licensing freely for commercial use.

Show me the money!

But you are probably now thinking "How will Phil make money if he gives away his software for commercial use?"  Several ways:

1. Consulting - Offer himself and/or his team up to work for corporations that want to use InstallPad but that have needs the software doesn't currently address. Have his software and website proactively solicit for that business. If he doesn't like the idea of doing consulting he should think about it like this: he is going to be adding features anyway, why not get someone to pay for it upfront? Most companies will be glad to pay a nice consulting fee if you solve a problem for them, especially if what they pay for gets contributed to an open-source project that they won't have to maintain moving forward and that hopefully others will be paying to improve too.
   
2. Dual-License - Just like MySQL, Phil could offer a dual license that offers "Enterprise" features for a fee. His consulting engagements in larger companies to help implement InstallPad would allow his to see the need for features that the general population does not need but that enterprises will pay handsomely to license. And by handsomely, offering at a price that would save large companies a lot on software licensing fees when compared to the offerings of companies like Altiris yet still make his company highly profitable if he keeps his costs under control. Basically he would become the classic upstart as described by The Innovator's Dilemma.
   
3. Other - Thirdly, there are the opportunities Phil won't even know exist until after he has the asset of a large user base to leverage. It really is true; build it and they will come.

But three things above will not happen until he generates significant growth in his user base and also significant buzz. And I'm here to tell you based on my experience in dealing with thousands of software vendors over the 12 years I ran Xtras, chances of his software growing a significant user base with the current licensing model are slim to none. So he's absolutely got to open-source it. IMHO anyway. :-)

So Phil; here's the strategy I think you should use:

Give InstallPad a real open-source license like BSD (but ideally not GPL as it's requirement for code contribution can cause other problems) and then focus on getting as many people to use InstallPad as possible. Further, create a set of guidelines and/or best practices that a software vendor would use to make their software optimized for InstallPad. You could even create a little graphic they can use, like the "Optimized for Windows XP" logo.

Then start with some mid-size software vendors and call on them to ask them to support InstallPad. You can find these vendors by asking everyone you know which software products are a pain to get updated. I say mid-size because you won't get the time of day at a large computer, at least not until you have a sizable user base. And a small company's user base is too small to really give you any leverage in exchange for your effort.  What you want to do is get companies with, say, 10,000 users or more sending out their software with InstallPad and/or sending out emails to their customers with links to download InstallPad.

You need to make it easy for software vendors to contribute "InstallPad Profiles" for their software (you may not have the concept of a InstallPad software profile yet, but you will.) You could use InstallPad to download these profiles from the vendor's website at a location they give you and then maintain. You can then incorporate all vendor's profiles into one configuration file which InstallPad users can download from your website or a mirror every time InstallPad runs.

And add a feature that asks your users to let you know about software they want InstallPad to upgrade but that doesn't work, for whatever reason (i.e. files not available online, crashes during install, no hands-free install, etc.) You could even suggest they ask their vendors to support InstallPad on your behalf. There's nothing like having a bunch of users begging for something to motivate a software vendors to do something!

If you do all this and you are diligent about "selling" the InstallPad concept to software vendors, you will soon have more users than you can handle and it will be time to find some angel funding!

Concerns about your use of Urls

Regarding the technical side of InstallPad, there are two things you should be aware of. One is a potential concern about how you are groking version numbers from Urls, and the second is an opportunity given your use of Urls:

• The principle of URI Opacity
• URI Templates

Contact me if you'd like to know more about these issues. As an aside, I believe Url design is critically important for an optimized Web 2.0 strategy, hence my reason for launching the Well Designed Urls Initiative.

About these Strategies...

One of my specialties as a consultant is software and partner marketing strategies. I learned by studying and doing over the last twelve years founding and running Xtras which I have since moved on from. And I'm sorry to toot my own horn but the best evidence that I'm good was the five year period from 1994 to 1998 when I grew Xtras by over 1700% and was recognized by Inc Magazine on their Inc 500 list of fastest growing private companies in 1999 as #123 on the list. In addition, as I have immersed myself in recent trends, I've come to believe that some of these most effective strategies, at least within the foreseeable future, will be to leverage open-source (as if you couldn't tell), the effects brought on by "Web 2.0," and of course, as always, partnering. Leveraging them, if done correctly, can provide hugh benefits to both customers and the companies that employ them; truly a win-win scenario.

If you are currently unsure how best to leverage open-source, Web 2.0 effects, and partnering strategies for your software and/or website, I can help you devise your marketing strategy on a short-term consulting basis. Alternately, if there is a strong enough fit for my interests, I might even consider helping on a longer term basis is there is equity involved. So if you want to create or improve your strategy, let's talk.

For those of you interested in Salesforce.com and their URL structure, useful for making bookmarklets, I documented Saleforce.com's URL structure over at another blog I maintain entitled Thoughts on Salesforce.com.  I also copied that documentation over to my WellDesignedUrls.org wiki with plans to maintain in on an ongoing basis.

Those of you who read my blog know that I strongly believe in the importance of URL design. For years it bothered me that we've see so many URLs on the web that look like the following example of poor URL design from Jeffrey Veen's 2001 book The Art & Science of Web Design:

http://www.site.com/computers.dll?1345,1,,22,567,009a.html


Back in Aug of 2005 I finally got my thoughts together and wrote the post Well Designed Urls are Beautiful. Well, from anecdotal evidence (I don't track stats on my blog stats very closely) it appears that post has become my blogs my popular post!

The popularity of that post combine with the several others facts inspired me to go ahead and launch a website with the following mission:

"Providing best practices for URL design, and to raise awareness of the importance of URL design especially among providers of server software and web application development tools."

The "facts" I referenced above are:

• I continue to feel strongly about URL design yet many are still oblivious to the benefits,
• I still have a lot more to say on the topic, and
• It appears that good URL design is one of the many tenants of Web 2.0 partly because of AJAX, Mashups, and REST-based APIs meaning that it won't be such an uphill battle!
  

The name of the website/wiki is WellDesignedUrls.org and for it I have the following goals:

• To create a list of "Principles" as best practices for good URL design,
• To cultivate how-to articles about implementing good URL designs on the various platforms like ASP.NET, LAMP and Ruby on Rails, servers like IIS and Apache, and web development tools like Visual Web Developer and Dreamweaver,
• To cultivate general how-to articles and resources for tools such as mod_rewrite and ISAPI Rewrite and others,
• To cultivate "solutions sets" for mod_rewrite and ISAPI Rewrite and others that can clean up the URLs on well known open-source and commericial web applications,
  
• To grade web applications, websites, and web development tools by giving them a "report card" on how well or how poorly they follow best URL design practices,
  
• To document URL structure of major web applications and major websites,
• To recognize people who are "Champions for the URL Design cause" (those who've written articles and essays promoting good URL design), and
  
• To providing resources for further reading about good URL design.
  

The wiki is clearly new and thus a work in progress, so it will probably be a while before it realizes all these things I mention. However, as I have time and am able to recruite others to help, I think it will become an important advocate for good url design and a great central resource for best practices.  And if you've read this far, I'm hoping that you'll consider either contributing when you feel you have something relevent, or at least use start considering the value of URL design in your own web application development and also point people in the wiki's direction when applicable.

Thanks in advance for the help!

P.S. I also plan to launch a WellDesignedUrl blog in the near future. Subscribe to my RSS feed it you want to be notified of when the blog goes live.

Today Joris Evers on CNET posted an article about the security developers for the four main web browsers discussing how to make surfing the Web safer. One of the tactics mentioned was Microsoft plans for IIS7 to show the URL in the address bar on all Internet windows to help users identify fraudulent sites. Whereas the trend has somewhat been for many websites to eliminate the address bar on their seconday windows to make their websites look slicker -- see what happens when the bad marketing wonks get involved, and when techies become over-enamored by techniques like AJAX -- this move will shine the light more brightly on the lowly URL.

In the past have blogged about Good URL design for websites and the related topics of wanting Mod_rewrite functionality for IIS and the tool ISAPI Rewrite that gives mod_rewrite functionality to IIS so it is clear I'm passionate about virtue of incorporating URL design into the overall design of a website. More specifically, my personal opinion is that URL design is one of the more important aspects of web design. This even though one person in this world disagrees with me, but Mark Kamoski is wrong. :)

What's cool about IIS7 requiring the URL to be seen at all times besides the obvious anti-phishing benefits is it will hopefully cause more website stakeholders (marketers, developers, etc.) to think more about the design of their website's URLs.

And that would be a good thing.

---

P.S. Actually, I'd love to see all Windows applications do what Windows Explorer does and support a URL of sorts (maybe call it an "LRL" as in Local Resource Locator?) Wouldn't it be great to see apps like Word, Excel, QuickBooks, and even Visual Studio be written as a series of state changes where the URL/LRL could represent in a user readable format each uniquely-representable state (with some obvious caveats)? Just imagine how that would empower the creation of solutions by composing applications... but I digress as that is the topic for a future day's blog post.

P.P.S. I almost don't want to say this next thing as it could obviate the need for exposing URLs to guard against phishing, but I'm too intellectually honest not to. I see a huge market opportunity for Verisign, with the support of browser and server vendors, to enhance their SSL certificates to include a "Phishing-Safe" seal of approval. Today website owners only need pay for a certificate if they are collecting sensitive information, but in the future I could see it becoming a defacto requirement for any website with a login to need a "phishing-safe" certificate, raising the bar on lots of hobby forums sites, etc. But I once again digress... Oops, I should have read the whole article before pontificating here; looks like they are discussing just such a concept.

I just found a blog post by Shirley E. Kaiser at her blog entitled Brainstorms & Raves containing an awesome collection of links and related discussion about Apache’s .htaccess.

While admittedly I write mostly for an audience of developers that use Microsoft-technologies, many of the items discussed apply to Microsoft's IIS if you use a 3rd party tool named ISAPI Rewrite. This tools provides many of the same features of Apache's .htaccess on IIS via the httpd.ini config file and implements most of its functionality in a manner identical to mod_rewrite on Apache.  I absolutely love this tool and I've previously blogged about ISAPI Rewrite as well as The Importance of Well-Designed URLs, the latter of which is IMO the most important reason you absolutely need ISAPI Rewrite if you are hosting a website on IIS.

Anyway, the blog post covers topics and links to articles that:

• Explain how and why to rewrite and/or redirect URLs,
• Discuss techniques for reducing hotlinking and bandwidth theft,
• Talk about blocking bad bots and comment spammers,
• Covers regular expressions needed to match the URLs to rewrite or redirect,
• Explains Robots.txt files,
• Lists which bots are good and which are bad, and
• Covers HTTP error code.

A great resource!

After seeing Eric Pascarello's thread at ASP.NET forums entitled "AJAX - Is it Hype? Is it for you?" I decided to post a thread at ASP.NET forums with a reference to my post from July entitled "AJAX: A Panacea, or a Pending Train Wreck?" UkBtlog responded so I'm blogging my reply below:

UkBtlog states:
I think there needs to be a big distinction between web applications (gmail, google maps, online banking) and web sites (msdn, wired, www.asp.net. AJAX is primarily useful for web applications. AJAX has limited use for web sites.

I'll agree there is a big distinction in some ways, but that's part of the point. Most web developers will be drawn to AJAX because it's the "next cool thing" and you'll see AJAX on practically every site, and in most cases very badly done. This is no different from when people went crazy with desktop publishing software using tons of fonts and colors in a document! But bad AJAX on the web will have a much more profound negative impact than ugly flyers posted on a light pole.

I'm not arguing that web developers can't use AJAX well, I'm arguing that AJAX opens a pandora's box where most web developers will use AJAX and few will do it well.

UkBtlog states:
I don't believe that AJAX is actually useful for things that search engines are best at searching. To use the example of MapQuest and Google Maps, I have never searched for London Bridge and had MapQuest come up as a result in a search engine. This although it uses query string parameters to be deterministic it isn't something that is searchable. I can also use the robots.txt to stop search engines and google even tells me how.

Again, we mostly agreed, but UkBtlog again missed my one of my points; web developers will use AJAX badly on web sites that should be searchable.

UkBtlog states:
This is the same as restarting an application and isn't really a suprise to developers. Sure this may not be the expected user experience, but perhaps the dom standards should give web application developers a way to stop the use of refresh if web apps are to mature.

It's not a surprise for web developers, but it's a huge surprise for web users! And a bad one at that!!! One of the reason for the success of usability on the web has been the consistent and constrained UI. Web usability guru Jakob Nielsen quotes in The Top Ten New Mistakes of Web Design (May 30, 1999):

Jakob Nielsen states:

1. Breaking or Slowing Down the Back Button

The Back button is the lifeline of the Web user and the second-most used navigation feature (after following hypertext links). Users happily know that they can try anything on the Web and always be saved by a click or two on Back to return them to familiar territory. Except, of course, for those sites that break Back by committing one of these design sins:

• opening a new browser window (see mistake #2)
• using an immediate redirect: every time the user clicks Back, the browser returns to a page that
• bounces the user forward to the undesired location
• prevents caching such that the Back navigation requires a fresh trip to the server; all hypertext
• navigation should be sub-second and this goes double for backtracking

Further, from Why Frames Suck (Most of the Time) (Dec 1996):

Jakob Nielsen states:
13% of users are still using Netscape 2 which had one of the worst usability problems to be seen on the Web so far: the BACK button in the browser simply didn't work with framed sites. The BACK feature is an absolutely essential safety net that gives users the confidence to navigate freely in the knowledge that they can always get back to firm ground. We have known from some of the earliest studies of user navigation behavior that BACK is the second-most used navigation feature in Web browsers (after the simple "click on a link to follow it" action). Thus, breaking the BACK button is no less than a usability catastrophe.

And I wouldn't attack the sources for being old; usability is based on the way humans process information and that doesn't change rapidly just because someone coined a new term and all the bleeding edge web developers have jumped on it!

Also, Jakob hasn't written about AJAX, yet, probably because he writes about his usability research results, not just his opinions (like you and me :), but I'm sure he will as soon as he has solid data to back him up.

UkBtlog states:
Developers of web application spend a lot of effort and tears trying to remove the problems of back buttons and refresh behaviour. The web browser shouldn't be trying to hold state, although it happens to cache the previous page, as HTML is supposed to be stateless. So if I want to buy into implementing state into a website such as using cookies or hidden fields or fancy frameworks like ASP.NET I don't want the browser interferring with my application state. If I am writing a web site for a company that informs the world on what they do, then I am not keeping any state and the back, forward and refresh buttons hold no fear. Your view is a little simplistic for the variance in reasons for developing for the web.

The criteria for expanding web functionality shouldn't be about how to make it easier for the developer!!! The web should be about making it easier for the user, and about empowering solutions that were previously unavailable. The stateless web addressable via URL with a well defined content set (HTML, GIF, JPG, and now PNG and PDF, DOC, XLS, etc.) is the technology that has empowered so much economic expansion and functionality on the web. Making it easier for the developer while ignoring other goals will just drag us down into the new dark ages; the dark ages of the web.

UkBtlog states:
AJAX maybe abused as it is the new cool feature, but using framesets or domain rewriting can lead to similar problems. I can also use pointers without correctly releasing the memory, but I don't.

And you'll note most web developers have finally stopped using framesets (thank god!) I had some of the same issues with them. (I don't know specifically what UkBtlog meant about domain rewriting.)

UkBtlog states:
Any of the technologies developers are presented with can be used in a way that is not best practice. If you do this with an information website such as Wired.Com or MSDN the information will not be found and your business will suffer. I only see this "misuse" of AJAX existing in proof of concept and misinformed developers.

This isn't about what one developer such as UkBtlog does. It is about the health of the web. Many cities have ordinances that say you can't have a grill on the balcony of an apartment or condo for the same reason. I can make sure I don't burn down the building with *my* grill, but what about my neighbor? If he doesn't use his grill safely, he'll affect *me*. Albeit an extreme analogy, the same is true for AJAX and web developers for the web.

UkBtlog states:
Perhaps we should encourage article writers to discuss best practice use of AJAX to help remove your fears.

Now with *that* I complete agree! So why do you think I am writing these blogs? :-)

But not only writers. We should also encourage tool vendors like Microsoft with their Atlas, and anyone making AJAX toolkits to really think through the issues and make sure their tools encourage best practices.

But what are those best practices? Thus far, I've only complained about AJAX. When I have time, hopefully soon, I'll make some recommendations as I see it for minimizing the threat and maximizing the benefit of AJAX.

UPDATE: If you are interested in URL design, check out my new project to promote the importance of URL design:

www.WellDesignedUrls.org

---

With all the talk of AJAX these days and with my concerns about poorly implemented AJAX-based sites and what they may mean for the web, I'm once again reminded of an opinion I've had for a long time: Well designed URL is one of the most valuable aspects of the web.

Put more succinctly:

Well Designed URLs are Beautiful!

The following are my (current) set of rules for how to ensure beautiful URLs:

Well Designed URLs Point to Content that Does Not Change

Theoretically, each URL points to a unique view of specific content, or a specific "state" if you will. And I content that should include URLs that point to dynamically generated web pages.

Of course many URLs point to content that changes that with each view (such as advertisements) and/or that is modified based on the current login state of the person viewing the content. Both of these cases corrupt the purity of the ideal stateless URL, but in my pragmatic opinion they are okay as long as the core content for a given URL is static.

URLs that point to home pages and section home pages often change their content, but to me that is okay too. Web users generally don't expect portal pages to have static content, but all other URL should point to content that doesn't change.

Well Designed URLs Don't Change

This should go without saying, but then again how often have you found exactly what you were wanting on a search engine or in a website's "links" section only to get a 404 after you click the link? Sometimes this happens because the website owner went out of business, but usually its because of a careless website owner/developer who simply reorganized the website without considering all the dead links they are creating, and all the opportunities for traffic they lost for themselves.

Of course most application servers and most content management systems make it almost impossible to "do this right." For example, what's with Microsoft's IIS, now in version 6.0, that you can't serve virtual URLs unless they have an extension (most commonly .aspx?!?) Sheesh!

Well Designed URLs Can Be Stored

When you see a web page you like, you should be able to bookmark its URL and return to view the same thing later. When you see a web page you want a friend to see, you should be able to cut & paste into an email where they can see in their browser exactly what you saw (this is especially helpful if what the see is a bug in your server-side scripting!) And when someone who is blogging or building out a website finds your related web page, they should be able to include your URL as a link in their web page, and it should work as a link for anyone that views their site. Plus, if a URL can be stored, it can be indexed by a Search Engine.

Well Designed URLs Only Use Parameters with Forms-Driven Queries

Many websites use parameters to data drive their website. In most cases, those URLs are just ugly. If I'm looking for Sweaters at Sears, I should click a link that points to www.sears.com/sweaters/, not www.sears.com/products?type=23.

Instead, URL parameters should only best used on pages that allow users to submit a query based entered into form fields. All other URLs should be composed and readable.

Well Designed URLs are Readable and Hierarchical

URLs can and should be part of a website's user interface. Well designed URLs that are readable and Hierarchical provide wonderfully rich information to a website user about the structure and content of a website. Websites with non-readable and non-Hierarchical URLs don't.

Well Designed URLs Mean Something

Besides being readable, a web page's URL should mean something to the website viewer. Having "/honda/" in a URL helps the website user understand the site; having "/tabid23/" in a URL does not.

Of course who violates this rule the worst? Content management systems. And it seems the most more expensive the CMS, the worse it violates this rule (can you say "Vignette?")

Well Designed URLs are Readable in Print

When you see a web page you'd like to reference in print, you'd want it to be readable, not a collection of what appears to be random letters and numbers (i.e. not like a "GUID.") Imagine a reader trying to type in 38 apparently random letter and numbers; that's simply a painful thought.

Well Designed Websites Have Atomic Leaf Nodes

How many sites have a URL to display a collection of items but no unique URLs for each specific item? Just as an atom is indivisible, so should be leaf-node web pages, each with its own specific and understandable URL.

Well Designed URLs Are Hackable

A website that has a web page for the relative URL "/cars/toyota/4runner" should also have a web page for "/cars/toyota/" and for "/cars/."

Well Designed URLs Can Be Guessed

Let's say that a website user is on a really slow link. If you URLs are well designed, chances are they can guess at the URL for the page they want. Of if you, godforbid, have a broken link, maybe they can correct it.

Well Designed URLs Are Only As Long and As Short As Necessary

URLs should be short. Short URLs can more easily be posted into emails and not wrap, and short emails can be printed in advertisements, for example. However, URLs should be long enough to make them readable, not obscure their meaning, and retain the website's heirarchy.

If you can't make URLs short enough to be readable, retain meaning, and retain heirarchy, create alternate URLs for print, advertisement, etc.

Well Designed Links Do Not Trigger JavaScript

How often do I find web pages with links that use JavaScript? Grrrrr!!!! (Can you say "__doPostBack()" Yes, I feared you could.) What's wrong with JavaScript? Users often use browser's status bar to view the URL give them a clue to where the link will take them. Not with JavaScript. Plus, many users hold down the shift key to launch a new window. NOT WITH JAVASCRIPT!!! (Can you feel my anger? Well Designed Links do NOT trigger JavaScript.)

If this is so bad, why is this done? For the application server developer's convenience, and not for the user's convenience; that's for sure.

Well Designed Search Forms Always Use GET

Search engines result pages provide content too, and their URLs need to point to content that doesn't change. Well of course they do change over time as they display what is current, but that's appropriate for a search engine result page. If a search form using POST, its search engine result page URL is only useful when an action of a search form, and worthless in every other case.

For a perfect example of a search page that violates this rule, check out CycleTrader's Search Page.

Well Designed URLs Have More Friends than Just Me

Of course I'm not the first to make the case for URLs, and I probably won't be the last. Here are some of the better essays about quality URLs:

• Tim Benners-Lee's Cool URIs don't change.
• Jakob Nielsen's URL as UI.
• Jakob Nielsen's Pages Must Live Forever.
• Jesse James Garrett's User-Centered URL Design.
• Pete Hopkin's Good URLs Are Important.
• Adam DuVander's Only good URLs.
• Thomas Powell's and Joe Lima's Towards Next Generation URLs.
• Simon Willison's Quality news site URLs.
• Simon Willison's URLs matter.
• Simon Willison's Top web design mistakes.
• Nathan Ashby-Kuhlman's Article URLs week: Principles.
• Mathew Thomas' How to recognize a Weblog tool by its permalinks .
• Már Örlygsson's Howto: Future-proof URLs in Movable Type.
• Peter Seebach's Making URLs accessible.
• Anne van Kesteren's URI (IRI) design.
• Brent Simmons’ Law of CMS URLs.
• Adam Moran's Human Readable Web Addresses.
• Jennifer Kyrnin's "Link Rot" Are You a Culprit? (Don't Change Your URIs).
• Mark Pilgrim's Cruft-free URLs in Moveable Type.
• Shirley Kaiser's More on Friendly URLs.
• Paul Hoffman's The User Interface of URLs.
• Olivier Thereaux's Choose URIs wisely.

There are also a few tools that can help:

• For IIS: ISAPI_Rewrite
• For Apache: mod_Rewrite

Well Designed URLs are an Asset

Some people rail against the URL and say it is an overly technical anachronism to which non-technical people should not be exposed. I completely disagree.

Just like so many other technical things that have become such a part of common culture over the years to have become all but invisible, such as radio station's frequencies, checking account numbers, ATM passcodes, and highway speed limits, so too will URLs become so straightforward that they'll soon not even be recognized as technical. Instead, they'll be viewed as obvious and valuable because they fundamentally are.

So, in a nutshell:

Well Designed URLs are Beautiful!

As a former MapQuest user, I find Google Map's interactive interface built with AJAX (a combination of Asynchronous JavaScript and XML) really cool and lots of fun to use. And Google's GMail, also built with AJAX, has a nice snappy UI that's much better than Hotmail. And the more websites that adopt AJAX techniques the less stodgy and more fun the web will be.

But even so, I still think this Next Big Thing called AJAX could well turn out to be a disaster for the web (disaster with a lower case "d," that is.)

Why? The simple answer is "state", or lack there-of.

In the early days for the web, a Uniform Resource Locator pointed to a page on the web that stayed the same, at least until updated. Later, many URLs pointed to dynamic content, but most returned deterministic content; i.e. they returned the same HTML even if accessed multiple times. However web pages with AJAX content have an infinite potential number of states, many for which no URL will ever exist.

Why is this bad? Let me use examples. Have you ever tried to email a friend a Google Map at the precise zoom level you are viewing? Fortunately Google makes it possible with the "Email" link, but how many other web developers will go to that level of effort?

As another example, try using GMail. Click around a bit. Now click the refresh button. Shazam! The page view you had disappears and you return to the Inbox. Now click the [Back] button. Do you go to the state where you were previously? No! You go back to the prior web page, whatever that was. You cannot go "back" to the prior page in an AJAX site because the browser doesn't manage the state for you. Instead the AJAX developer has to manage state and provide a "Back" link or you won't be able to go back. So what's the likelihood when he's behind schedule to release a new website he'll go to that extra effort, or even that he'll know how?

Okay, these are just nits from someone resistant to change, right? Well, not exactly. The biggest problem with lack of state is that programs, such search engines, can't process AJAX web pages programmatically; Google, for example. Anything hidden behind AJAX's interactivity is also hidden from search engine view.

In the July 4th, 2005 issue of Information Week, Google's own Bret Taylor claims clicking on a blue URL and loading a page is "the old Web User interface." Ironic that the company that spawned interest in AJAX is the one that depends most on the programmatically indexed web pages that AJAX will minimize.