Category Archives: XHTML/CSS

Photoshop guidelines for web designers

We often work with external design agencies. Sometimes they work with wireframes we produce, and sometimes not. These are my standard guidelines (or wishlist, if you will) that I try to send to designers before they start. I don’t think I’ve ever received any that meets all these criteria, but it’s always good to aim for. Perhaps it’ll be a useful checklist for other designers out there.

  1. Final deliverables are layered Photoshop files (.psd), with flat file snapshots of each.
  2. When providing flat files (incl. work-in-progress snapshots), use 24-bit PNG format (not JPG).
  3. Use separate files for each distinct layout template.
  4. Photoshop Layers should be given meaningful names. Multiple identically-named layers are unnacceptable. As far as possible, remove obsolete layers. Use layer groups to organise layers
  5. Photoshop Guides should be used, matching the page layout grid. Remove obsolete guides. Guides should be snapped to pixel edges Photoshop lets you position guides at sub-pixel level, which causes confusion when working with pixel-level artwork for screen-based media. To snap guides to pixel edges, first create a marquee selection in the right place, and then snap the guide against the marquee edge..
  6. Consistency between Photoshop files is required, regarding measurements, fonts and colours.
  7. Use a meaningful and consistent file naming policy. Related files should be named in such a way that they are alphabetically adjacent (e.g. content-normal.psd, content-wide.psd
  8. Versioning: for updated versions of files, use a consistent and sensible versioning system in the file names. E.g. homepage-v01.psd. Files with version numbers should stay in order when sorted A-Z. Avoid file name suffixes like -final.psd, -updated.psd, -new.psd etc.
  9. Bear in mind CSS capabilities and work with them wherever possible. For example, horizontal and vertical lines should follow pixel edges exactly (not anti-aliased) in order to be implemented as CSS borders.
  10. When drawing vector shapes, remember to check the “Snap to Pixels” box in the shape options.
  11. Remember to specify hover (mouseover) and active (on click) states for links and buttons.
  12. Accessibility: Minimum font size is 11px. Body text should ideally be 12px or 13px.
  13. Accessibility: Test for adequate colour contrast and colour blindness
  14. Text in Photoshop should be sized in px units (not pt), and in integer sizes (not fractions)
  15. Specify the actual leading in the Character palette, and, for multi-paragraph text areas, spaces above and below paragraphs in the Paragraph palette, that should be implemented using CSS. Do not use double linebreaks or font sizing to set paragraph spacing
  16. Use web fonts as far as possible (core web fonts or from a commercial web font service). Only use non-web fonts (e.g. corporate fonts) where absolutely necessary (they’ll be implemented using images). This is extra important for text that will be content-managed or translated.
  17. Embedded images such as logos should be production quality, as the Photoshop file will be used to cut out final images. (Tip: embed logos as ‘smart objects’, or avoid resizing them multiple times.)
  18. If working from wireframes, try to avoid a “wireframe aesthetic” (monochrome, everything in boxes). If a wireframe puts something in a box, it just means that information should visually stick together. Use gestalt principles to group information visually.
    Edit 3 Mar 2014: Good series on gestalt by Andy Rutledge: 1, 2, 3, 4, and 5.

Edit Feb 2014: Here are 2 excellent resources for designers producing website mockups in Photoshop:

About us: Isotoma is a bespoke software development company based in York and London specialising in web apps, mobile apps and product design. If you’d like to know more you can review our work or get in touch.

Jonathan Stark – “Building mobile apps with HTML, CSS and JavaScript” workshop

Jonathan began with an overview of the current mobile landscape. In a nutshell it’s a minefield of platform fragmentation and device fragmentation.

“‘It’s brutal to develop natively across platforms”

Jonathan Stark
So what to do? Well, we then looked at three approaches; native, web and hybrid. All have their advantages but hybrid looked the way to go for most mobile use cases. In Jonathan’s words the advantages are:
  • Web files bundled in native executable
  • Access to device APIs
  • Sell in native app stores
  • Not perfect, but pretty damn good

Next we looked at some useful guidelines for the mobile use case. A nice summation would be “Do one thing and do it well”.


We looked at various CSS3 features; advanced styling, transforms, transitions, animations etc. There’s a wealth of information out there on these so I won’t go into too much detail. Here are some interesting pointers:
  • android requires text-shadow to have a blur value.
  • box-shadow has performance issues, particularly on Blackberry (consider using media-query to turn off for Blackberry).
  • border-image is particularly interesting, as it does away with sliding doors css.
  • animations are hardware accelerated on iOS.
  • be careful of z-index on transforms. By default on it stacks above static positioned elements.
  • box-reflect works with form elements.
  • box-shadow takes up space like borders.
  • box-reflect works on <VIDEO> tag.
  • Talk of hardware acceleration for animation in the next version of Android  (Ice Cream Sandwich).
  • using lots of CSS3 gradients, animations, box-shadow will cause performance issues, tread careful and test often.
I liked the look of CSS animations. I have some reservations of how manageable they will become on medium to large projects. Having written code based animation sequences in Flash I know from experience it can get pretty complicated managing dependances and interactions. Using LESS, or SASS looks like an absolute must for using CSS animation on anything but the smallest projects.


Next up was looking at some of the useful offline features of HTML5. Namely; web storage, web SQL database and application cache. My personal favourite was web storage – it looked easy to use and very useful for state maintenance. Application cache also looked great but I can see huge problems debugging, even Jonathan struggled to demo it properly.

Phonegap, jQTouch and Sencha Touch

Here we looked at the various frameworks for building hybrid apps. Again there is a ton of info out there. Jonathan was obviously keen on jQTouch but I actually think Phonegap looked the more promising platform for development. It seemed to have a good balance between ease of use, learning curve and features. Sencha Touch looked really powerful, whilst  jQTouch looked lightweight and quick to build with.


In the final part of the day Jonathan showed some great debugging tools. If you’ve ever had to debug mobile CSS you know what a pain it is to debug on the device itself.  The stand out star for me was weinre, a really fantastic tool for debugging mobile apps.  The basic premise is it gives you access to the webkit inspector on your laptop which in turn is linked to the phone browser. It allows you to see exactly what is happening on the phone and allows live editing as well. Pretty amazing really.


Jonathan’s workshop has re-enforced my opinion that writing mobile apps for all formats is best done using HTML5 / CSS and JS.  The key benefits are:
  • write once*
  • The skills are already available and less costly than hiring native specific developers
  • one central code base
* They’ll always be some platform specific code needed.
All the slides and downloads from Jonathan’s talk are available here:

CSS3 Flexbox

CSS3 brings us a host of new features. Whilst most people will be familiar with gradients, text-shadow etc. I’d like to draw your attention to one of the lesser known modules in CSS3: flexbox. What’s interesting about Flexbox is that you can use it now if you use a Gecko or Webkit based browser (no IE sadly and Opera’s support isn’t there yet).

What does Flexbox bring us that we didn’t have before? Well it gives us a whole raft of new ways of controlling layout and flow. What we now achieve with floats we can do far more successfully and with more control with Flexbox.

I’ve never liked floats, they always seemed a hacky way of structuring HTML. Unfortunately with the meager positional CSS available, floats ended up being the best way of creating flexible fluid layouts. Let’s look at some examples.

display: box

To define an element as a flexbox we set the display to box.

.flexbox {
display: -moz-box;
display: -webkit-box;
display: box;

Example 1


Notice that by default flexbox elements are aligned horizontally. If we want to change that to vertical:

.rule {
-moz-box-orient: vertical;
-webkit-box-orient: vertical;
box-orient: vertical;

Example 2

Box-orient is inherited i.e. child elements will also be aligned horizontally.

Example 3

Observant viewer will have noticed that Firefox (3.6.8) ignores the width and height setting on the child boxes, whilst Webkit respects it but overflows the content.

So if you want child elements to be aligned vertically, you’ll need to set the containing element to box-orient:vertical.


We can reorder elements as we like, using box-ordinal-group.

#box-2 {
-moz-box-ordinal-group: 1;
-webkit-box-ordinal-group: 1;
box-ordinal-group: 1;

Example 4

The immediate application of this should be obvious, for the first time we have way of defining display order without reverting to all the hacks we’ve had to use up to now (floats, relative positioning, negative margins etc). Powerful stuff.


Box-flex allow the content to expand to fill the available space.

.rule {
-moz-box-flex: 1;
-webkit-box-flex: 1;
box-flex: 1;

example 5

Notice once again the difference between Webkit and Gecko; whilst Webkit expands the main block to the browser window, Gecko expands to fit the content.

Box-flex fills space in proportion to the value given. Quoting the specs:

“All flex is relative. For example, a child with a box-flex of 2 is twice as flexible as a child with a box-flex of 1.”

To explain this better lets look at an example:

#box-1 {
box-flex: 1;
#box-2 {
box-flex: 2;
#box-3 {
box-flex: 7;

Example 6

For ease of calculation I’ve given the H1 child element a width of 50px, and the containing element a width of 600px. So the available space is:
600px – 150px = 450px

Working out the ratio is:
1 + 2 + 7 = 10

450px / 10 = 45px

this produces:

box 1 width: 50px + (45px * 1) = 95px
box 2 width: 50px + (45px * 2) = 120px
box 3 width: 50px + (45px * 7 ) = 365px

Further more you can set relative spacing whilst having fixed width paddings and margins. If you tried that with floats you’d either have to use percentage margins or have boxes bouncing all over the place.


Box-align works in the opposite direction to the orient setting. i.e. if the element is set to horizontal, box-align controls alignment in the vertical and vica versa.

#main {
-moz-box-align: stretch;
-webkit-box-align: stretch;
box-align: stretch;
#box-1 {
-moz-box-align: start;
-webkit-box-align: start;
box-align: start;
#box-2 {
-moz-box-align: center;
-webkit-box-align: center;
box-align: center;
#box-3 {
-moz-box-align: end;
-webkit-box-align: end;
box-align: end;

example 7


This reverses the order of elements.

#main {
-moz-box-direction: reverse;
-webkit-box-direction: reverse;
box-direction: reverse;

Example 8

Notice the inconsistency between Gecko and Webkit again. Gecko aligns the right hand column, whilst Webkit aligns to left but reorders the elements.


Box-pack controls alignment in the direction set by orient.

#main {
-moz-box-pack: justify;
-webkit-box-pack: justify;
box-pack: justify;
#box-1 {
-moz-box-pack: center;
-webkit-box-pack: center;
box-pack: center;
#box-2 {
-moz-box-pack: start;
-webkit-box-pack: start;
box-pack: start;
#box-3 {
-moz-box-pack: end;
-webkit-box-pack: end;
box-pack: end;

example 9

Justify is a nice attribute, equally spacing elements within the parent container.

Final Example

example 10

The classic 3 column layout. Notice the navigation appearing first, also note that the background colour extends to the full height of all boxes.

Sadly flexbox is not supported by IE and looks unlikely to be supported by IE9. So it will be a while before these techniques become mainstream.

About us: Isotoma is a bespoke software development company based in York and London specialising in web apps, mobile apps and product design. If you’d like to know more you can review our work or get in touch.

Just Enough Documentation: an ideal web design process

A recent project reminded me how much I like the “just enough documentation” approach, and how inefficiently web design is often done.

Tasked with redesigning an Agile project management web application (to improve usability but not re-brand), I used the following process:

1. Paper sketching for a day or so to get my ideas straight about page and widget layout. This is the best time to explore wildly different alternatives, and make most of the big decisions.

2. Wireframes in Omnigraffle of the key pages. Since the visual style wasn’t changing, I could do high-fidelity wireframes closely resembling the final design. I work on a large format, so there’s ample space to overlay notes and state changes, as well as alternative ideas. The wireframes were shared with the client on a continuous basis for feedback.

Lots of things weren’t wireframed, including less critical pages, and many dynamic states.

3. I did only two pages in Photoshop, in which I did just enough to give me my final measurements, and the few image elements that needed cutting out. I refined designs a little from the wireframes, but most of this I left to the next stage. The wireframes and this stage together took about 5 days.

4. HTML and CSS. Because in my design I was switching from a fixed-width layout to a liquid layout, you can only really appraise the design once you implement it, so it was imperative to get to this stage as quickly as possible. It is also far, far more efficient to fine-tune margins, typography and colours in CSS than in Photoshop. Furthermore, I could quickly mock up most dynamic interactions – of which this app has plenty – in jQuery (which I had not used before but was ridiculously easy to pick up.) How much more effective than doing so in wireframes, where you (and the client) have to imagine how it will “feel” to the user and you can never be sure whether it will work?

By far the bulk of my time – about 2 weeks – was spent working in HTML and CSS. Pages or elements that weren’t wireframed were much quicker to design directly as HTML and CSS, without the duplication of effort. New ideas inevitably arise during this stage, and are immediately incorporated. I occasionally went back to paper or Photoshop or Omnigraffle to work out small details, but there was no need to keep those design documents “up to date” – they had served their purpose. The client was able to appraise the designs exactly as it renders in the browser, and the resulting artifact was also ready to be integrated into their back-end.

Not only could the client and I be confident about how the design will actually look once implemented, I could also ensure that accessibility measures were built in, as well as the ability for it to be easily re-skinned. (As the app is sometimes white-labelled.)


If I reflect on the design process on many past projects, most seem ridiculously inefficient. Where UX designers had to exhaustively wireframe every single page and every possible interaction, with complex state diagrams for all the dynamic elements. And to keep the wireframes up to date throughout the course of the project. Where designers had to mock up dozens of pages in Photoshop, with everything finalised to the last pixel (but usually omitting hover effects and never considering liquid layout or browser differences). All the foregoing needing to be done before a client will sign it off and a single line of markup can be written. The front-end developer reduced to an automaton incapable of taste or decisions, who just had to implement the Photoshop mockups to the pixel, and all interactions exactly as specified in the wireframes. It was usually impossible to refine aspects of design or interaction at this stage (everything having been signed off), let alone adding new ideas, despite it being the most fluid.

Obviously this won’t suit all projects or clients. For example, I had the advantage of not starting from scratch, and a client who was prepared to work in this way. It was a relatively small project with few stakeholders. On some projects there may be good reasons for an exhaustively documented waterfall process. But very often in my experience it was simply because it was the only way the agency knew how to work, due to the excessive compartmentalisation of skills, and an inadequate understanding of the meaning of web design. And my, what a lot of time and money it wastes.

Plone Theming or: How I Learned to Stop Worrying and Love collective.xdv

Recently I’ve been tasked with looking at how we can improve our Plone theming process.

One of the problems that most teams come across on any web project is how to spend less time doing the basics and more time solving the unique problems that each project throws up. This seems to be especially true when it comes to skinning / implementing user interfaces. No matter what framework / CMS I’ve used (and I’ve used plenty) it’s often hard to square the circle between what we want as output and what is actually produced.

Another aspect that can eat up time is having to implement user interface changes during development. Even with the best sign-off procedures, designs, and by extension HTML templates are often subject to change. With that in mind the key objectives we are looking for in a theming method are:

  • easily portable between projects.
  • full control over CSS/HTML and JS output.
  • working in parallel with the development team.

So lets look at the various theming options for Plone.

“Plone theming is getting a bit complicated”

You’re not wrong. From what I can see you have 2 options:

  1. Write a custom stylesheet. It’s amazing what you can do with CSS, but that alone won’t cut it. We need to able to specify the HTML output to meet our high standards of accessibility and design.
  2. Create a ‘vanilla’ theme product. Creating a Plone theme is not for the faint hearted and to be honest it had me stumped. You really need to have a solid understanding of Plone and Zope to create anything worthwhile and while that is not necessarily a problem it’s certainly not my area of expertise.

I could probably grab some developer time here at Isotoma to help me put together this ‘vanillla’ product, but even that doesn’t answer our needs in the level of flexibility we require. There must be an easier way….

Deliverance / Collective.xdv

The future of Plone theming lies in Deliverance / Collective.xdv and will be at the core of Plone 4 theming (so I’m told). You can start using it now though. (see this excellent tutorial to get started )

It took a little effort to get a working buildout, mainly because I couldn’t get lxml working on my mac (necessary for collective.xdv). So I installed it on an Ubuntu VM which worked just fine.

Once I’d got it working it didn’t take me long to realise the potential of this new way of theming. In a nutshell, it allows you to have whatever output you want. Not only that but it allows template development to happen separately and in tandem with the main development effort.

Let’s have a quick look at how it works. At it’s simplest level you have 2 files: theme.html and rules.xml. The theme.html file is a standard html template and you can write this however you want. It is the rules file where it gets interesting. I won’t go in to the full details (see here for a full description) but here are some examples of what you can do.

Replace content:

<replace content='//*[@id=”content”]' theme='//*[@id=”content-area”]' />

this replaces the element in the theme.html with whatever content Plone produces within #content element.

Append / prepend content:

<append content='/html/head/style' theme='/html/head' />

this adds all the styles from Plone.

Discard content:

<drop theme='/html/head/comment()' />

This removes comments form the theme.html appearing in the site.

It uses Xpath, something that I’m familiar with and very easy to learn. With deliverance it gets even easier because you can use CSS 3 selectors. All-in-all you have a very powerful way of theming Plone whilst having a fantastic level of separation and flexibility.

I’m very hopeful that collective.xdv / Deliverance will be the solution we are looking for and I’m really looking forward to using it on forth coming projects.

Nasty IE6 CSS bug

Probably not new, but I can’t find mention of it anywhere so I’ll post it here:,
#foo.baz {
 background: blue;

In the CSS above, #foo.baz effectively neutralises in Internet Explorer 6. It will never be applied. The same happens even if you separate the grouped selector into two statements like this: {
 background: blue;
#foo.baz {
 background: blue;

Anyone seen this before? It’s hard to think of a short description, or something to Google for. “IE6 grouped selector with combined id and class selector bug”.

I worked around it by removing the classes from the selector (which was fortunately possible in this case.)

And before you ask, one of our largest clients is a multinational corporation whose internal IT policy has standardised on IE6.

[Update: As usual, spelling out the problem helped me find other mentions of it here and here.]

CSS Systems

Natalie Downe of Clearleft has written a very useful presentation entitled CSS Systems, or, “Writing Maintainable CSS”. These are principles and patterns for writing HTML and CSS that makes it easier to hand over to other people to maintain, and generally more robust. It’s very relevant for agencies like us, and I was pleased to find that the system we developed internally (documented on the company wiki) correspond with hers about 99%. This blog post consists of comments, additions, qualifications, agreements and occasional disagreements with her presentation.

Continue reading

Best practices for speeding up your site

Best Practices for Speeding Up Your Web Site — part of an excellent series of articles on the Yahoo Developer Network.

They mainly focus on the front end, as that is where you’ll get most bang for your buck. They make frequent reference to YSlow, a Firebug extension that looks extremely useful.

The presentation here is also strongly recommended, as it makes succinct arguments for all the techniques. (View on Slideshare to see it full-screen.)

Some things were familiar to me (and most are already standard practice for my colleagues), many weren’t (e.g. avoid @import for CSS), and some I know of but haven’t been convinced of before (e.g. CSS sprites). I was quite intrigued by this example of CSS sprites in use on Google. (When using CSS sprites, remember to consider their accessibility to screen readers, and don’t use if you want them to print.)

IE8: steps in the right direction

After the furious controversy and rationalisation unleashed by Microsoft’s embrace of version targeting from IE8 onwards, we were thrilled by their u-turn on the decision yesterday. Instead of acting like IE7 unless instructed otherwise, “IE8 will, by default, interpret web content in the most standards compliant way it can.” Big sigh of relief.

And today Microsoft released the first IE8 Beta. Thanks to John Resig for his excellent review, pointing out all the significant improvements as well as omissions. As Resig points out, it’s primarily my JavaScript-coding colleagues who’ll see the greatest leaps forward, but I’m amazed and happy to see support for ARIA, meaning we can finally improve the accessibility of Ajax-based web applications. And I love the Firebug-like integrated debugger — you can even use it when in IE7 mode!

In the review, Resig makes one comment that resonated with me: “I simultaneously feel both joy and anger in seeing these fixed. Happy that they’re being released and anger for the fact that I had to struggle through them and that they now consume some portion of my brain.” Joy and anger. That’s exactly what IE8 makes me feel. We’re made to feel grateful for the fixing of years-old bugs that on any normal software product wouldn’t have been tolerated for longer than a few months.