With all the noise over the revelations from Microsoft this week concerning standards rendering in IE8 I’ve found it hard to collect my thoughts on the subject, but I’ll give it a try anyway.

Body

This week Microsoft revealed that to trigger standards rendering in IE8, web authors will need to use a new meta tag to specify which version of the IE rendering engine to use. Alternatively (and this wasn’t immediately apparant) authors can just use an unknown doctype such as the HTML5 one which would automatically trigger standards mode. I’ll say it outright that I’m not a fan of the idea but I can see why it’s been done, I find it arrogant of Microsoft to demand special treatment when we’ve already had to put up with quite a lot of IE’s rubbish over the years. This is coming from someone who is normally an apologist for Microsoft, normally I take the viewpoint that whilst making things work in IE is a pain it’s usually relatively straightforward once you reach a certain level of experience and become aware of the problem areas.

But there is something that is bothering me alongside this, why the hell do we keep making changes to our structural/context layer (HTML) in order to control how the presentation layer (CSS) behaves? Why should my use of a valid doctype mean that my CSS magically works properly? A doctype is used to validate the structure of an xml document, it has nothing to do with how it’s displayed, and why are we still using doctypes anyway? XML Schema Definitions are much easier to develop, from what I gather they give you a lot more flexibility and they’re really easy to understand. This isn’t a rant about doctypes though, this is a rant about me having to change one area of my code to affect how a completely different part of my code performs.

So we have to use proper doctypes to get IE6 and IE7 to use CSS more correctly than IE5, but that’s not enough – we also have to add conditional comments into our HTML so that we can deliver special CSS to them to clean up the things that IE still can’t do right. Now we have IE8 to look forward to, but now we have to add even more to the head of our documents to trigger the probably-still-not-right-but-getting-closer rendering mode in this new version.

Why the hell aren’t we shoving all this information in our CSS instead? If this information is controlling how the CSS works surely it would make sense to configure it there? In a proper deployment environment it’s a piece of cake to update CSS because it’s generally served from a different web server to the web application, we can easily tweak the CSS for new browsers without so much as having to reload/redeploy anything. Quite frankly, whilst I prefer clean CSS due to being a bit of a perfectionist, if I have to stick all this nonsense somewhere it’d rather it be in the CSS than the HTML. I consider it much more important to have valid and streamlined HTML than CSS.

Just a thought.

A quick experiment to try out new features in Safari.

Body

The latest builds of WebKit have added some pretty nice new CSS properties – namely rotations and embedded fonts, so I decided to have a quick play with them. I didn’t spend very long on this (rushing to get things done before Christmas) but I hope it inspires other people to start exploring these features. I know we can’t use this stuff in production sites yet, but I have a feeling that if we can come up with some truly kick-ass demonstrations we might be able to convince the other browser manufacturers that these properties are worth implementing.

I would love for someone to come up with a really good graphic novel style design, I had a go but I had no reference materials and didn’t really put in the time it deserved.

Here’s my example (Obviously it requires the latest build of WebKit to run).

Just a quick few words about producing readable URL slugs

Body

When I read around for methods of converting a piece of text (such as a blog entry title) to a URL-friendly slug, I generally just find one-line regular expression replace functions without any real explanation of what’s going on. So here’s a basic overview of what such an algorithm should be doing:

1. You need to be aware of what characters are generally allowed in URL segments (here’s a good guide), basically any letters or numbers are allowed. You can probably also allow a single quote (no double quotes) as the only piece of punctuation available to you, most other punctuation is reserved or considered dangerous to use.
2. Choose a character for spaces, normal spaces aren’t allowed (they are actually but they have to be encoded so they end up being quite ugly). Realistically you can use underscores and hyphens. The preference is hyphens because they don’t get disguised if written as hyperlinks.
3. Convert your text to lower-case. Your URLs should be consistently cased for usability and lower-case is the easiest and most attractive option. If an upper-case version of a URL (or part of a URL) is accessed it should redirect the user to the canonical lower-case version.
4. Make sure you only don’t have two spacing characters in a row, this shouldn’t be an issue if you’re careful about the order of each step

1. Depending on preference and URL length you might want to remove certain words such as prepositions to keep the slug as concise as possible whilst still being relatively meaningful

   In Java, the following method call is probably a good starting point:

   replaceAll("[^a-z0-9']+", "-")

   The Ruby equivalent would be

   gsub(/[^a-z0-9']+/, "-")

   You’ll need to do some other things before and after the above methods but they represent the key part of the algorithm.

   Note: I’m uncertain on the best practice for using the vertical single quote in slugs. I couldn’t see anything that said they’re a bad idea, but I imagine most people would prefer to just remove them. This raises the issue of whether to collapse the single quotes or to replace them with hyphens.

   ]]> Java, Programming, Ruby, URL, Usability 2007-10-16T22:35:03+00:00 http://www.andrewingram.net/articles/readability_uniqueness_hackability_and_meaning_in_url_design/ http://www.andrewingram.net/articles/readability_uniqueness_hackability_and_meaning_in_url_design/#When:00:48:01Z Abstract

   In this article I discuss the development of usable URLs and outline some guidelines that will aid developing them. I also briefly touch on the importance of choosing development frameworks that enable decent URLs.

   Body

   Update on 13th October 2007: Mike Schinkel made me aware of some misused terminology, so I’ve updated the article to amend this.
   Update on 19th October 2007: A user at Reddit highlighted how bad my first sentence was, I’ve rewritten it a bit.

   Introduction

   URL design is arguably one of the most important areas of website developement. Not only do URLs generally have huge visual priority in web browsers but they’re also shown on search result listings and get used for matching search terms. Let’s not forget the usability factors, what does a bunch of seemingly meaningless query strings and numerical database keys tell your users about where they are in the site? This is just the tip of the iceberg when it comes to reasons for investing resources in developing decent URL schemas, yet it’s only in the last couple of years that we’ve seen the emergence of web development frameworks that truly put an emphasis on them. In the slower-to-upgrade enterprise world most sites are still running on frameworks that produce some truly ugly URLs.

   The next problem is the URLs people choose once they decide to switch away from query parameter infested schemas to ones that use readable URL segments to identify pages. Simply put, just converting your parameters to friendly pieces of text isn’t enough; you may get improved search rankings from your new found keywords but all you’ve really done is disguise the problem and search rankings should never be your primary aim in URL design.

   4 Principles of URL design

   Having read a number of articles on the subject as well as exploring my own views on the matter I’ve come up with what I believe to be the 4 most important aspects of URL design:

   URLs must be Readable

   Just by reading a URL a user should be able to make a fairly good guess as to what they will find if they visit it. Titles (converted to a readable slug format so that those nasty %20 things aren’t visible everywhere) should be used instead of numerical ids and the URL should make it clear whereabouts in the overall site structure the resource is.

   Pages with unique content must have Unique URLs

   A lot of factors come into play here, the first is that the same content shouldn’t have more than one URL, you should choose your preferred URL for each page on your site and if a second is required it should simply be done as a permanent redirect. A search engine will follow the redirect and only index the canonical URL. This applies to the www sub- domain which the majority of websites have set up as optional. Use Apache’s mod_rewrite (or equivalent) to add a permanent redirect that forwards the request to the non-www URL (or the other way round if you really want the www part). Localisation should also include the locale somewhere in the URL so that the preferred localised version can be bookmarked (not everybody has their browser configured to use their preferred locale). If a page has unique content it must not rely on sessions or cookies to load this information otherwise it will be invisible to search engines, Brad Fults discusses multilingual URL design in “Designing URLs for Multilingual Web Sites”, his conclusions may not match your own but the article does an excellent job explaining some of your options.

   URLs must be Hackable

   This follows on from readability and the idea that a URL is not only a location but also a map – much akin to breadcrumb navigation (“Breadcrumb Pattern at Yahoo”). One of the main features of successful breadcrumb navigation is that it doesn’t represent the route you took to get to the page but rather the route home or to other pages. Every URL is constructed from a number of segments separated by forward slashes, for a URL to be hackable the user must be able to repeatedly remove the last segment and also arrive at a valid page that makes sense within the context of the URL. The user must also be able to swap in alternative segment that make sense, like changing “2007” to “2006” or changing “reviews” to “news”. This sounds straightforward enough, but the biggest stumbling block is introducing new URL segments to resolve namespace conflicts (what if someone gives an article a title that causes conflict with an existing URL?), this is a bad thing because it means you now have a URL (everything up to and including your new segment) that doesn’t have a page behind it. The solutions range from refactoring your URL schema to simply preventing new content from using existing URLs programmatically.

   URLs must be meaningful

   Put simply, every single part of your URL should not only mean something to the user but also to your system. Let’s say that instead of just using your article title you’re using the numerical id as well, your system may not actually care what the text is as long as the id is right. This violates the idea of unique URLs because now every single article effectively has unlimited URL possibilities. Similarly, keywords shouldn’t be stuffed into the URL if they have no actual effect on what page is returned by the system. If a user gets any part of a URL wrong they should be served a 404 page which ideally would list the possible URLs the user may have been looking. By removing useless parts you also ensure that your URL is only as long as it needs to be, long URLs almost always become unclickable if put in emails because readers break the line before the running the algorithm that converts the URLs to clickable links.

   Conclusion

   The 4 principles outlined above represent my condensed findings on how ideal URL schemas should be constructed, in reality it’s not quite as simple as following 4 relatively straightforward guidelines (and there are probably a number of factors I’ve overlooked that may not fit within the 4 areas) but my opinion is that URL design is easily important to justify the work that may go into programming a system that allows good design. In my experience some web development frameworks make it unreasonably difficult to develop decent URLs whilst others can even make it enjoyable, this ease of URL development should be considered an important factor in framework choice.

   I have deliberately refrained from mentioning SEO directly until now, I have no objections to SEO but I feel that if any design decision is made purely for SEO purposes you risk adversely affecting the user experience. However, applied correctly these principles also go hand-in-hand with optimising your URLs for search engines. In fact, you can find the majority of what I’ve said in various SEO articles just with different motivations behind the decisions. My point was to emphasise the importance of proper URL design and highlight that even if your site is so successful that you don’t need to worry about SEO you still need to worry about the user experience and therefore URLs.

   Thanks to Nathan Smith for helping me out with some thoughts regarding this article. Andrew Ingram is aware that his site doesn’t remotely follow his guidelines but promises to try harder in the future.

   ]]> Accessibility, Programming, URL, Usability 2007-10-07T00:48:01+00:00 http://www.andrewingram.net/articles/question_concerning_django_and_templates/ http://www.andrewingram.net/articles/question_concerning_django_and_templates/#When:23:19:00Z Abstract

   This is a request for help from all the Django users out there, it’s about using different templates for different types of article in a blog or CMS system

   Body

   There’s a project I’m working on that I think could really benefit from switching to Django primarily due to its powerful admin system, but there are some requirements that i’m not sure can easily be solved. I can think of ways to solve it using a hand-coded admin system but that removes the main benefit of making an immediate switch.

   The Problem

   The system requires that different types of content be deployed regularly using a number of significantly different templates. They are different to the extent that an admin panel for adding content would have different form fields for each template, i.e. some templates might just use one textarea whilst others might use a number of text areas and some text fields and image selection fields. Can this kind of thing be done easily (or with an acceptable level of difficulty) using Django and ideally within the auto-admin itself?

   If I were to try and solve this problem in another programming language or without using the Django admin I would do it as follows:

   • A folder would contain all the templates as html files
   • Editable regions for each template would be defined using some kind of commenting syntax that would allow preview content to be shown if the template was loaded in a browser
   • The system would parse the template when it’s requested and generate a form based on the properties of each editable region
   • When the content is saved the form content would be converted to a map of labels to content and stored to a single field in a database table
   • When the page is rendered that data would be retrieved, parsed and inserted into the page, replacing all the comments with real content.

     The reason editable regions have to be defined is that the templates are quite complex and we don’t want people accidentally breaking stuff by forcing them to work with the template html.

     I’m open for suggestions on better ways to approach this problem, both for non-Django and Django usage (since even if we solve it for Django we’d need a way to do basically the same thing in non-Django apps)

     ]]> Django, Programming, Usability 2007-09-30T23:19:00+00:00 http://www.andrewingram.net/articles/undo_form_reset_script_for_kids_who_cant_reset_good/ http://www.andrewingram.net/articles/undo_form_reset_script_for_kids_who_cant_reset_good/#When:01:10:02Z Abstract

     It doesn’t happen often, but occasionally we all accidentally hit the reset button on a web form and lose all of what we just spent time typing out. I’ve written a little bit of javascript that makes it possible to recover from these disasters.

     Body

     I’m a big believer that if the user manages to screw something up whilst using some software it’s the fault of the software developers rather than the user. In his recent article “Never Use a Warning When you Mean Undo” Aza Raskin highlighted the need for an undo buffer rather than a warning prior to making a mistake, the reasoning being that users become accustomed to ignoring warnings – especially if it’s regarding a task they perform often, and that recoverability is a key area of software usability. Web applications have long suffered from a general lack of undo functionality and it’s something I’m keen to take a look at addressing in future projects, but that’s for another day.

     HTML forms often have a reset button, this is a native html control that allows a user to reset the contents of a web form to its starting state. I’m not too concerned with the use case for such reset buttons – I can’t imagine getting so much wrong in entering a form that it’s easiest just reset everything, but let’s assume you have a valid reason to include a reset button and so there it is in your form. First issue is that these buttons are usually right next to the submit buttons and have the same appearance (Luke Wroblewski looks at the effect of these types of buttons in “Primary & Secondary Actions in Web Forms”), second problem is that if you accidentally hit this button the majority of web browsers (if not all) won’t let you undo this action (you can select a text field and undo changes to that, but as far as I can tell you’re pretty much stuck with other kinds of inputs).

     With this problem in mind I had a go at writing a simple bit of javascript (enabled by jQuery) that looks at all the forms in a page with the class of “undo-reset” and captures events on any reset buttons it finds. It’s fairly straightforward so I won’t go into too much detail but basically it adds a short bit of text at the end of the form alerting the user that the form has been reset and provides the option to reverse the change. It makes use of the jQuery forms and deserialize plugins to store and restore the contents of the form.

     You can try it out on the example page

     Please let me know of any issues you find or any improvements you can suggest. I imagine it could easily be made into a greasemonkey script that you can apply to any forms you like.

     ]]> Javascript, jQuery, Usability 2007-09-30T01:10:02+00:00 http://www.andrewingram.net/articles/be_careful_with_jquery/ http://www.andrewingram.net/articles/be_careful_with_jquery/#When:22:14:00Z Abstract

     jQuery is a fantastic Javascript library but it also has the tendency to make it a little bit too easy to write inefficient code.

     Body

     Let’s get this out of the way first; I love jQuery, it makes DOM manipulation straightforward and has just the right level of involvement for a Javascript framework. Basically if you’re doing nothing particularly fancy, you need nothing more than the jQuery Core and you could reasonably find yourself using most parts of the core functionality without being guilty of going a bit too crazy with Javascript functionality.

     The jQuery selectors are fast, and they seem to keep getting faster. It’s got to the point where using a jQuery selector is only marginally slower than using the native DOM functions.

     The problem is with chaining. As one of jQuery’s most praised features chaining is a mixed blessing, you can do a lot of powerful things in just one line using it but chances are you’ve solved the problem in a way that’s far from efficient. Each time you add another link to the chain you are effectively adding another loop that must be iterated over; in just a few short steps you will probably have added a lot of algorithmic complexity and unnecessary repetition to your code.

     There are a few tricks you can use to optimise your code (this applies to any coding, but I’ve found jQuery makes it a little bit too easy to be lazy):

     • Cache repeated selections, if there’s a selector that you always find yourself using, save the result to a variable – this means the actual selection only gets run once.
     • If you know the actual DOM functions and they’re safe to use in all browsers you should probably use them, they’ll be faster. This is especially important if the function is inside a loop.
     • In general it’s good to minimize your result set as soon as possible so that you are working on less data, but in jQuery this might mean that you are running an extra chained function when you don’t really need to. Say you are doing .filter(“span”).each(fn), you can combine this into a single .filter(fn), and just modify your inner function to ignore span element.
     • Don’t forget other coding tricks. There are thousands of ways to improve algorithms and eliminate unnecessary loops but it’s easy to forget about them when enjoying the simplicity and elegance that jQuery provides. You may end up with code that’s a bit more verbose (okay, often it will be a lot more verbose) but users that are on machines slower than the ones you test on will thank you.

       Feel free to contribute any other tricks you’ve come across that improve the performance of jQuery-based algorithms

       ]]> Javascript, jQuery 2007-09-25T22:14:00+00:00 http://www.andrewingram.net/articles/generating_sprite_navigation_from_fireworks/ http://www.andrewingram.net/articles/generating_sprite_navigation_from_fireworks/#When:22:04:00Z Abstract

       Using a single background image and change the positioning has long been the favourite way of developing accessible navigation menus. It gives you pre-loading of hover states for free as well as an overall reduced server overhead. The main problem with the technique is that it’s rather fiddly writing all the HTML and CSS for it. SpriteNavi is a command panel for Fireworks that can generate this code directly from an image.

       Body

       The technique of using a single image and shifting its position depending on the menu item and state has been my favourite method of creating graphical navigation menus ever since I first heard about it. Overall file sizes tend to be smaller and in general the approach is more accessible. The main drawback is that writing the HTML and CSS can be quite time-consuming since it requires calculating the offsets and dimensions of every state of the menu.

       SpriteNavi is a Fireworks command panel I’ve developed to help automate this process. I’ve chosen Fireworks for the initial development because it’s much easier to develop for than Photoshop and much more of the application is accessible to scripting. As it stands SpriteNavi can only develop horizontal navigation bars, the main issue with adding vertical menu support is how to do the user interface rather than any coding problems so hopefully this will be coming soon.

       It works by using guides in your document to work out the dimensions of the menu items. So if you don’t already use guides you’ll have to add them to use SpriteNavi, guides at 0 and the image dimensions are optional.

       Simply download the .swf file and place it in your “Fireworks\Configuration\Command Panels” folder, load Fireworks and SpriteNavi will be selectable from the Window menu. You can then choose to float it or have it docked in the toolbar

       Press “Fetch Guide Data” to populate the datagrid. you can then change the name of the menu and the menu items as well a prefix to be added to the name of each menu item to avoid conflicts with any other ids in your HTML. Use the spinners to select which row should represent each of the 5 states of the menu items (I personally tend to group link and visited on the first row, focus and hover on the second and active on the third). Then press “Generate Code” to output the HTML and CSS in the textarea below. You can then copy this code into your own HTML and CSS files. You can change the numerical values if you like but it’s not recommended if your document guides are correct.

       

       Download SpriteNavi for Fireworks (right-click and save link as, otherwise the swf will just load in your browser)

       ]]> Design, Fireworks 2007-08-19T22:04:00+00:00 http://www.andrewingram.net/articles/gridmaker_reboot/ http://www.andrewingram.net/articles/gridmaker_reboot/#When:22:11:00Z Abstract

       The first versions of GridMaker were well-received but several issues were highlighted, this article introduces the next version which includes a number of changes.

       Body

       A few months ago I wrote GridMaker to aid in producing grid-based web design mock-ups in Photoshop (and later Fireworks). Whilst very primitive it was well-received and many have informed me how useful they’ve found it. At the same time it was clear that there were a number of issues so I went back to GridMaker and made a number of changes.

       What features have we lost?

       As the new version stands, a number of old features are missing. The obvious thing that’s missing is the notion of a grid configuration input, this allowed people to potentially make quite complex grids but ultimately the idea would have needed to be much more complicated (think regular expressions for defining grids) in order for it to be sufficiently flexible. Instead I’ve limited the configuration to one size of column and one size of gutter.

       In addition, the maximum dimensions inputs have gone. These allowed users to generate documents and guides up to and including their maximum desired image size. This was a useful feature because it allowed you to produce grids specifically for certain screen sizes. This feature will be back and there will be some very useful improvements, I just need to figure out how the user interface will work since ExtendScript is very limited with regards to UI widgets.

       Finally, there is no longer the option to configure rows. However, this will also be looked at more in the future, particularly with regards to things like baseline font size

       What new features are there?

       Right now you can specify four properties for columns; column width, gutter width, number of columns and column divisions. These are fairly self-explanatory, the approach is similar to Matthew Pennell’s Grid Calculator script, the only addition is the idea of column divisions which allow you to divide each column up into a number of smaller columns without separating gutters.

       The row heights are currently calculated using the column width and golden ratio, this hopefully provides an adequate compromise until I get the row settings done properly.

       Last but not least, you can finally specify which units to use (pixels, cm, mm and inches) in the document (this does actually change your Photoshop preferences though so just be aware). One word of warning, if you use the default settings with inches nothing will happen because you’re trying to generate a bigger document than Photoshop can handle.

       

       To install, just put GridMaker2.jsx in your Photoshop\Presets\Scripts directory and load the program, the script will be available in the File/Scripts menu.

       Download GridMaker2.jsx

       ]]> Design, Grid, Photoshop 2007-05-09T22:11:00+00:00 http://www.andrewingram.net/articles/gridmaker_for_fireworks/ http://www.andrewingram.net/articles/gridmaker_for_fireworks/#When:23:54:01Z Abstract

       GridMaker ended up being quite popular so I decided to take a look at porting it over to Fireworks.

       Body

       When I was initially showing GridMaker to people, one of the first questions asked was whether it would work in Fireworks. Unfortunately Photoshop and Fireworks don’t have completely compatible APIs (as far as I’m aware, things may have changed with CS3 but I couldn’t find any suitable documentation) so a different approach was required. Fireworks doesn’t seem to have a nice set of GUI functions like Photoshop’s ExtendScript but it does allow embedding of Flash applications into the program itself as Command Panels.

       I’ve never really used Flash before but ActionScript is pretty intuitive if you know JavaScript and ExtendScript (they’re all based on the same language) so converting the code was pretty straightforward and seems to work nicely. I particularly like how well GridMaker looks embedded into Fireworks. I won’t go into how to use it since it’s exactly the same as the Photoshop version and it doesn’t include any additional functionality yet (this is a serious possibility since Flash has far more flexibility for building user interfaces than ExtendScript).

       Simply download the .swf file and place it in your “Fireworks\Configuration\Command Panels” folder, load Fireworks and GridMaker will be selectable from the Window menu. You can then choose to float it or have it docked in the toolbar

       

       Download GridMaker for Fireworks (right-click and save link as, otherwise the swf will just load in your browser)

       ]]> Design, Fireworks, Grid 2007-04-30T23:54:01+00:00