The approach that I eventually settled on works well. It’s powerful, easy to understand and quick to roll out.

If you don’t use Tridion, you might be wondering what all the fuss is about. Surely it’s just a case of giving different user groups permission to read, write or delete different types of content? Well, that’s true, but because the Tridion content management system is more complex than most, the list of things that require access control is fairly long:

1. Publications as a whole (think “websites”)
2. Schemas (the definitions of different kinds of content)
3. Categories (the way that content can be classified)
4. Folders (where content is stored)
5. Structure Groups (the structure of your websites)
6. Targets (where content can be published to)
7. Publishing Statuses (the steps along the content creation production line)

Another difficulty is the fact that the GUI doesn’t make the permissions very visible. You can’t glance at a list of folders, for example, and see what the permissions are. You have to open each one to check what permissions are applied and this simply isn’t practical when you’re dealing with large numbers of them.

However, if it’s possible to create a permissions model that’s predictable and logical, there’s less of a need for it to be constantly visible.

My system divides permissions up into three types:

1. Ability (eg Intranet Component Editor, Website Page Editor) – specific to Publication
2. Content type (eg Job vacancies) – across all Publications
3. Team (eg Marketing) – across all Publications

None of these are enough to manage user permissions on their own – a user is given all three of these types (in actual fact they are Tridion User Groups) in combination.

Here’s an example.

Jane needs access to publish the corporate employee handbook as downloads to the Intranet. The groups she’ll need to be a member of are:

• Ability: Master Component Editor
• Content Type: Downloads
• Team: Human Resources

Ability: Master Component Editor

This group gives read access to the Building Blocks Management folder in the Master publication – granting access to the root folder where all content is stored.

Content Type: Downloads

This group does several things – it gives:

1. Read access to the folder where Download Components are stored
2. Read access to the folder containing the Downloads Schema
3. Read access to the folder containing the Downloads Component Templates
4. Read access to the Categories used in the Downloads Schema

Team: Human Resources

This group gives write and delete permissions to the Human Resources folder inside the Downloads folder.

Assigning these three groups in combination gives the user the detailed permissions they need but keeps the groups re-usable and modular. The system can be expanded with more Ability groups such as:

• Ability: Intranet Publisher (gives access to the Intranet Publication Target)
• Ability: Website Page Editor (gives read access to the Website Publication’s Root Structure Group)

We’re using this system to help us manage almost 200 devolved authors over four Publications. I hope it helps you too.

But one of the issues with using flexible images is the need to load a large image which is then scaled down using CSS:

img {max-width: 100%;}

I’ve written a jQuery plugin called Doubletake that dynamically resizes images as necessary. It is based on the width of the containing element rather than the screen size so it doesn’t employ cookies to store the viewport width. It’s also different from Filament Group’s approach from last year in that it’s entirely client side and isn’t limited to just two image sizes.

It can be configured to watch the window resize event but it’s intended mainly for use on the initial page load.

It’s not perfect by any means. Because it’s client side, it makes two image requests – loading the mobile-sized image initially and then scaling it up if necessary which is hardly ideal. I’m sure the JavaScript could be improved a great deal too.

It’s little more than food for thought really – an alternative take on the solutions for responsive images that have been proposed so far – but when combined with dynamic resizing tools like SLIR and src.sencha.io I think it’s quite an effective approach.

Below is a comparison of the screens from the old and new iPhones (from Engadget’s review).

Now, to cater for the iPhone 4′s higher resolution screen, we have a couple of options:

1. serve a higher resolution image
2. use something that doesn’t pixellate

While it’s possible to use CSS media queries, JavaScript or a server-side technology to detect the iPhone 4 and serve up higher resolution files, this is only going to make things worse for your Retina-enabled visitors.

The reason is simple – a higher resolution image means a larger file size – something that should be avoided at all costs, especially on a mobile platform. Plus, although your image will look good to start off with, if your user decides to show off their “pinch to zoom” multi-touch trickery, you’re right back to square one. Pixels, gah!

SVG to the rescue

SVG (Scalable Vector Graphics) has been around for donkey’s years but until recently was consigned to the web equivalent of the garden shed. Aside from some sterling work in technologies like Cufon it had pretty much fallen off the web design radar. Because it required an Adobe plugin (last updated in 2001 for the Mac – 2001!) which no one except SVG enthusiasts even knew about (let alone installed on their computers) this brilliant technology never caught on.

Well, those days are over, bud.

Reason 1: It’s supported (at last)

Today all of the main desktop and mobile browsers support SVG:

• Internet Explorer
• WebKit (Safari, Mobile Safari, Chrome, Android – and BlackBerry)
• Gecko
• Opera

Plus, with tools like Modernizr at our disposal, serving bitmap content to older browsers is just an .svg class away.

Reason 2: It’s responsive

Yes, that’s right. SVG makes your responsive design even more responsive. There’s no need for downscaled large images or multiple sizes. It just scales! Automagically!

Reason 3: It’s future proof

As I’m sure you’ve realised by now, the beauty of SVG is that it’s vector, baby – it scales up or down to any size or any resolution without becoming pixellated. If someone (Apple, I’m looking at you here) decides to release a three bajillion dpi screen the day after you’ve gone live, there’s no need to break a sweat. You don’t have to redraw your icons. You can sleep easy.

Creating SVG files

So, now that you’re all fired up about SVG files, what’s the best tool for creating them. In my opinion, the best (and most expensive) is Adobe Illustrator. Fireworks comes a close second with Aaron Beall’s fantastic Export extensions. I’ve also tried Inkscape, Sketch and Lineform but for me they can’t compete with Adobe just yet.

Here’s something I prepared earlier

I used Aaron Beall’s Fireworks extension to create an SVG version of the Twitter bird. It’s 1.6Kb, transparent and can be used at any size. This is exactly the kind of thing SVG was made for.

You will need:

1 x CSS media query that targets iPhone 4 only
1 x double size background image

@media only screen and (-webkit-min-device-pixel-ratio: 2) {
#targetelement {
background-image: url(doublesize.jpg); /* image is 200x200 */
-webkit-background-size: 100px 100px; /* display at 100x100 */
}
}

The media query targets iPhone 4 only at the moment, but be aware that if other devices with the same device-pixel-ratio become available (and use WebKit) then this media query will affect them too.

During development, the following jQuery code worked absolutely fine.

$('head').append('<style type="text/css">...</style>');

The new styles were added to the head tag and the browser updated the animation as expected.

However, I have since updated to Mac OS X Lion (10.7) and although the styles are still added to the head of the HTML document, they have no effect. Only unticking and reticking a style checkbox in the Web Inspector caused the browser to “notice” the updated styles and repaint the screen with the new properties.

I don’t think this is a bug introduced by the Lion update because it has been reported by others. That’s not why I’m mentioning it here. I wanted to document the workaround because it took several hours to find an answer. Hopefully, this will help others who are as perplexed as I was.

A way of adding styles at runtime that definitely does work is:

var css = "body {colour: red;}";
var styletag = document.createElement("style");
styletag.setAttribute("type", "text/css");	
document.getElementsByTagName("head")[0].appendChild(styletag);
styletag.appendChild(document.createTextNode(css));

This has been tested in Safari 5.1 and Chrome 13.

Hope it helps!

Downloadable documents are maintained here to ensure availability only. No claim is made of ownership or publication.

Website design guidelines

• Edinburgh University
• Central Office of Information guidelines
• BBC’s Global Experience Language 2010
• BBC’s Global Visual Language 2008
• BBC Glasswall
• Yahoo Web Design Guidelines for Advertisers 2008
• Apple Web Design Guidelines 1996
• New School Web Style Guide
• Yale Web Style Guide 3
• Cambridge University 2008
• Apple guidelines for iTunes U 2007
• Columbia University 2006
• Barbican

Collections

• IdentityWorks list of manuals

Advice

• Building a better style guide
• SilkTide
• General principles from BBC Online

They have a JSON API which makes usage a breeze and you can purchase as little as 100 credits (for just £5 at the time of writing).

I used their service to send texts from an iPhone web app I made just before Christmas – it worked an absolute treat.

Hope this saves someone some head scratching.

Inspiring stuff.