Comments on: Smart practitioners have harmless URLs

By: J. Boye » Blog Archive » Percussion releases new vision, new website and new product

Sat, 07 Mar 2009 19:10:17 +0000

[...] am always curious how vendors eat their own dog food, sometimes with mixed success. Percussion uses harmless URL’s on their website, but evidently it still requires work to make all old links [...]

By: J. Boye » Blog Archive » When the economy goes down implementation costs go up

Fri, 23 Jan 2009 00:06:19 +0000

[...] management radar, is postponed to a distant future, so customers still have to fix accessibility, harmless URLs, and the buggy rich text editor on their [...]

By: Lisa Garcia

Lisa Garcia — Mon, 19 Jan 2009 13:02:53 +0000

Hi all,
First of all, let me state that I am not in any way technical, but I do am responsible for overseeing the Government of the Azores Portal, and we do have an ugly URL problem… I’ve come accross your postings as I did some research on the subject. As such, I would really very much like to hear from all of you: what can I do to make it better? Clues, hints, tips anyone? Our portal is built over CMS 2002 with Sharepoint 2003. The portal is organized by channels, in which each government service has its own channel and is responsible for editing it. Hope this description helps.

By: J. Boye » Blog Archive » Are you still using Microsoft CMS 2002?

J. Boye » Blog Archive » Are you still using Microsoft CMS 2002? — Sun, 18 Jan 2009 22:56:56 +0000

[...] new projects, make sure you implement harmless URL’s, hereby preventing problems later [...]

By: Sigurd Magnusson

Sigurd Magnusson — Wed, 14 Jan 2009 21:08:19 +0000

We made a conscious decision to enforce friendly URLs in the SilverStripe CMS, meaning the product will note install unless the (IIS or Apache) web-server is configured to permit it.

This is generally very good, although we get criticism on our forum from time to time, that it makes it harder to install. We think it is worth it — if we didn’t mandate it, then all too many installs would have poor URLs, like you state.

Another point to your post, is; (a) automatically generating nice URLS from the page titles, and (b) making it easy for content authors to alter those URLs, e.g. to shorten “Employment Opportunitities” to a URL like ‘site.com/jobs’. (You can see these at http://www.silverstripe.org/assets/video/cms.html )

By: J. Boye » Blog Archive » Use EPiServer for your website and keep SharePoint behind your firewall

Sun, 21 Dec 2008 00:17:12 +0000

[...] for knowledge sharing and collaboration. If you take a closer look at the site, please note the harmless URLs. Also, Urchin Software by Google is used for website [...]

By: Janus Boye

Janus Boye — Fri, 19 Dec 2008 00:05:12 +0000

Thank you for the very helpful reply. A few points:
- Yes, editors and system integrators are often also to blame, but the problem starts with the vendor. If the system created harmless URLs out-of-the-box, there would be no configuration to sell to customers.
- Sitecore does not create vendor-specific URLs by default (unlike FatWire), but they do create technology-specific URLs, which is just as harmful.

If vendors does not understand this problem, can we really expect customers to pay a consultancy money to fix it on each and every project?

By: Eldblom

Eldblom — Thu, 18 Dec 2008 09:21:45 +0000

Just to clear up your misunderstanding:

Firstly, nice URL’s are mostly an editor driven feature, see e.g.:
* http://cbs.dk/nyheder_presse/hoejreboks_forside/arrangementer/2009_01_19_09_45_00_faglig_dag_paa_cbs_for_samfundsfagslaerere
* http://www.drk.dk/nyheder/081105+militaermanual+efterlyses
Which gives a good indication that even the best intended website structure can be ruined by a bad editor (Hats of to dsb.dk which actually maintains a good and stringent URL structure). The feature is also driven by the specific implementation of the Website CMS, not the vendor itself see e.g. the following EPiServer driven websites which I hope we can agree are not nice:
* http://www1.idrottonline.se/templates/NewsPage.aspx?id=268077
* http://www.skandiabanken.se/hem/templates/pages/SectionPage____1580.aspx

Secondly, the .aspx extension is applied primarily because of the nature of older versions of the Microsoft IIS webserver and .NET framework. The extension can be removed but requires configuration (which I guess is the same as .php on Apache). My experience is that this configuration is not easily sold to the customers and is therefore often skipped.
The problem is not applicable to the new IIS 7 webserver (on Windows Server 2008), so my guess is that future websites running .NET Platform CMS’s will no longer have this problem.

Last but not least; in the case of Sitecore, the URL’s are absolutely not vendor specific, and has not been for the last many releases of the product. See e.g. http://www.stenaline.dk, which runs Sitecore and has nice URL’s. In your example from the Sitecore website (www.sitecore.net/Products/Sitecore%20CMS.aspx?nav=t) the .aspx can be removed – and we agree that it should have been from Sitecore’s side. The %20 indicates that the editor has put a space in the page URL, which is a bad habit. Lastly I would guess that the ?nav=t parameter underlines a third party vendor-specific shortcoming, which is that analytics tools (like Google Analytics) cannot determine whether you have navigated the page from the topmenu or elsewhere and therefore must have a parameter which specifies this.

I hope this rather long reply helps you understand that your criticism is somewhat misdirected. We totally agree that the URL problem should go away, but try to primarily face the editors, customers and implementers (like me) not the vendors.