andrewingram full-entry feed

Gridmaker For Photoshop CS4

2009-02-22T22:19:02+00:00

Abstract

After a suggestion from John Nack I had a go at porting GridMaker 2 to the new Flash Panel framework in CS4

Body

A while ago John Nack contacted me to ask if I was interested in porting my GridMaker plugin to make use of the new Flash Panel capabilities of CS4. It’s taken me some time to get around to doing it (despite it not actually taking that long) but I have it working now. I haven’t implemented all the functionality i’d have liked (like loading/saving settings) and I had wanted to customise the Flex theme to make it look native to CS4 (I hate non-native UI, as a result I am very wary of any Flash-based user interfaces) but I kept putting it off. I figured I may as well release what I’ve got or risk forgetting about it completely.

Installation

Download GridMaker.jsx and GridMaker.swf and put them in ‘Plug-ins/Panels’ in the Adobe Photoshop CS4 folder. Load Photoshop and the panel should appear under ‘Window/Extensions/GridMaker’. Once activate the panel will appear in your command panels on the right.

I’ve set the defaults to be equivalent (though not identical) to the 12 column layout found in 960.gs, the only real differences are that the gutter isn’t split in half and the outer margins are 20px rather than 10px.

It’s also missing the unit-selection functionality from the second version of GridMaker.

GridMaker.jsx

GridMaker.swf

Quiet around here

2008-08-23T14:15:00+00:00

Abstract

A short blurb on why I’ve not said much recently

Body

It may or may not have gone unnoticed that nothing much is going on around here lately, there are two reasons for this. Firstly, a supreme amount of laziness – can’t be helped. Secondly, I’ve been thinking long and hard about how to redevelop this site. I’m not happy with the way content is represented on the site which makes me extremely reluctant to add anything new until I’ve reworked some things.

I’ve had ideas for things to talk about but it would be impossible to display them how I feel they need to be displayed within the current framework of the site. I’ve come up with an appearance I like for the blog/articles pages, so now I just have to sort out the other areas of the site; ideally this will happen before I get bored of the new design and start over…

Do what you like to my CSS, but stay out of my HTML

2008-01-25T20:50:00+00:00

Abstract

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.

Time to play with new things

2007-12-20T23:56:00+00:00

Abstract

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).

Readable URL Slugs

2007-10-16T22:35:00+00:00

Abstract

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:

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.
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.
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.
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

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.

Readability, Uniqueness, Hackability and Meaning in URL Design

2007-10-07T00:48:00+00:00

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.