From Accessibility to Zope

Django has had multi-table inheritance for three months now, but I haven’t used it because I can’t picture many use cases for inheritance which don’t rely on dynamic polymorphism.

In my current project, however, I’ve found a fairly convincing use case. I can do all of the basic listing and manipulation with the base class, and I only need the superclass for one particular operation.

Rather than writing this in a different way, which would be less intuitive, I pushed ahead with the conceptually simple approach and fought with Django to make the inheritance polymorphic. The way I did this was brute force it: check all of the relations for one that exists.

from django.db import models
cls = inst.__class__ #inst is an instance of the base model
for r in cls._meta.get_all_related_objects():
    if not issubclass(r.model, cls) or \
        not isinstance(r.field, models.OneToOneField):
        continue
    try:
        return getattr(inst, r.get_accessor_name())
    except models.ObjectDoesNotExist:
        continue

There are faster ways of doing this if you do it at the database level (left joining all tables in the inheritance hierarchy and sorting out the mess into the correct subclasses), but this is simple and self-contained and forces me to think about when I need this. And looking at the query cache, the overhead is not too bad anyway.

The current generation of social networks are based on an assumption that giving you reams of data about what other people are doing and have done really puts you in touch with other people. As a user, I do get the impression that I am in touch with people, even though I may not actually be communicating with them. So we don’t always bother to make stuff happens.

There are social networks that tell you where friends have been, some that tell you where they are, some that tell you what they are doing right now and some that tell you where they will be. But very few, it seems, that tell you where to be.

Taking Facebook as an example (as it’s the only social network I’m using heavily at the moment), it does not make it easy to set up things to do. Creating events is a very laboured process. It takes perhaps 15 minutes to set up an event. It’s an individual rather than a collaborative task. Invitations to events get ignored because of the way they are delivered. People get blanketed with invitations that they don’t want. And I can’t even set up an event until I’ve set up a group to arrange the event.

Social calendaring is not a new concept as the promise of electronic calendars has always included ease of scheduling, via e-mail invitations of some sort. Google Calendar and 30 Boxes represent the state of the art in this regard, which is simply calendar sharing and event invitations.

The thing social calendars really should address is scheduling of events, because I’m lazy and also busy and I always say things like “we really should …” but it never happens.

My ideal social calendar could fulfil these user stories:

• Find me something to join in with on any given day.
• Schedule things with the knowledge of when I’m most likely to be free or busy, even when nothing is scheduled.
• Arrange online games with my brother in Australia (7 hours ahead in summer or 9 hours in the winter).
• Pick a date and time to do a thing I want to do, with friends who want to and who may have to travel to do it.
• Remind me to book the venue for an event.
• Book out an event I’m hosting.
• Nail down the fuzziness inherent in saying something like “Let’s have dinner on Thursday evening” so that we can say “Dinner at 8pm, and Alice will be joining us at around 10pm for drinks”.
• Suggest when to actually go to bed so that I can get up next morning.
• Pin-point exactly where an event is so that I can work out how to get there.
• Don’t keep trying to schedule things my skint friends can’t afford to do.
• Suggest things I might like to do.
• Mildly favour a schedule where I can watch my favourite TV programmes.
• Create entirely new groups of local people with similar tastes (say Buffy, or Linux) in such a way as to be actually kind of fun and neither awkward or annoying.

As is perhaps evident, I’m a strong believer in heuristic tools that do really innovative stuff. What are the chances that all of the above are possible in a calendar application that doesn’t automatically book me to go pole-dancing in Alaska moments before it has me watching Mork and Mindy with total strangers in my home on a Friday night? Hmm.

The WCAG Samurai Errata to WCAG 1.0 is an independently-produced set of amendments (”errata” is not really the right word) that fairly accurately nail how WCAG is and isn’t working for pragmatic but standards-compliant developers like me.

I stumbled across this while browsing Google for references while writing a proposal for a client. I was writing my usual set of caveats about the Web Content Accessbility Guidelines (WCAG), in which I lament how rubbish they are in practice. My usual spiel goes along the lines of “WCAG 1.0 informs all of our work at Mauve Internet. However, because the WCAG is subject to intepretation, and is now somewhat dated, we do not warrant conformance.” I would like to make a clearer statement of how and why but a specification isn’t really the place to challenge sections of the WCAG.

Happily, I can now get rid of this kind of non-committal note when writing specifications, and offer a firm commitment to WCAG+Samurai.

I will also be revising my company website - indeed, my company policy - to recommend conformance to the WCAG guidelines as amended by the WCAG Samurai Errata where possible.

What with the summer weather finally here and some good light, it’s a good time to be taking photos.

While I do encourage people to take nice, artistic photographs, and include them on a website perhaps in a frame, this is ultimately limiting. If you would like to end up with photos you can use within the design of a website, you need to take a different approach to setting up your shots. The composition will be done using graphics software at a later date, so you need to avoid doing the composition when you’re in the field.

The following guidelines are based on the main reasons I have to rule out a particular photograph as suitable for a piece of graphic design.

Don’t crop the subject

It may look artistic if the subject extends out of the frame, because it places the subject better in frame and leads the eye in the opposite direction. But it’s the number one reason for ruling out photographs from a layout. With no cropping of the subject, the designer can place a photo anywhere and composite the subject into the layout. With one edge running through the subject, the designer is constrained to place that edge along a natural edge in the layout, or failing that, hide it behind something else. With each additional edge that runs through the subject, the designer is more and more constrained with what can go where.

Don’t take black and white shots

It’s easy to convert colour photos to black and white on a computer; the opposite is not possible. Take colour photos just in case you need them.

Use a mixture of different shots

Most photographers will take multiple shots of a subject, but often this will just be a process of refinement - to try and capture one excellent photograph. You should aim for a much more varied mixture, of portrait and landscape, wide-angle and close-up, different angles and so on.

Try and take the same shot of different subjects

Designers will often be creating a suite of graphics to work together, so take similar shots of different but related subjects.

Include acres of background in your shots

In artistic photography you’re told to put the subject off-centre in the picture, roughly a third into the frame.

In web design we often have very long or tall regions to fill, quite different dimensions that you might encounter in print design. The aspect ratio of the photos that we might be putting on a website is rarely 16:9 let alone the traditional 4:3. We’re more likely to deal with aspect ratios of 10:1.

To successfully frame photos that can be cropped to a very wide or tall aspect ratio, your subject should be much smaller and nearer the edge.

Don’t use depth of field effects

A short depth of field can really 3D effect to a photograph. But it is difficult to cut out something that’s blurry, and sometimes that’s what designers want to do. A blurry background isn’t a problem, as part or all of the background may be removed, but when parts of the subject extend out of focus it’s impossible to separate the subject from the background.

A designer can fake a depth of field effect if the subject is in focus.

Don’t strive for contrast

As a rule of thumb, artistic photos look best with dark darks and bright highlights. Nearly all B2B and the majority of B2C websites are dark text on a pale background, and the dark darks contrast too much with the light and airy environment of the average website. That’s something that you can’t actually fix with colour curves as you can only produce murky greys. A subject that is mostly well lit but fades to black is as hard to work with on a pale website as one that is blurry or cropped: there’s no good way to blend the dark bit into the site.

If your website is on black or dark grey, you’re in luck. These are ideal for publishing artistic photography and really good contrast will look stunning.