Monthly Archives: November 2011

Santa’s Slave Parade

Last Sunday it was Amsterdam’s annual Sinterklaas parade, when the Saint and his ‘helpers’ arrive on the boat from Spain and parade through the streets of Amsterdam distributing sweets and biscuits to the children lining the route.

As Nicholas is the patron saint of the city (as well as children and sailors) there is an amazing turn-out along the roads leading from the harbour through to Leidseplein, where he delivers a benediction from the balcony. Hundreds of blacked-up men, women and children also march along the route, representing Zwarte Piet (Black Pete) – variously described as a defeated devil, Ethiopian slave-boy, or a chimney-sweeping servant. Whatever the genesis of the Sint’s companion, it’s definitely one of the oddest things an ex-pat in Amsterdam is likely to see…

Facebook to stop RSS blog import to Notes from November 22

Well, that sucks. Facebook are currently displaying a notification at the top of my News page informing me that they will no longer support blog RSS imports as of November 22.

I can’t really see what the benefit of this decision is to Facebook. They will be losing a huge amount of content, all of which can be consumed within their application. Forcing bloggers, and other businesses that are automatically piping their RSS content through to their Facebook page, to manually recreate outgoing links can only lose them traffic and eyeballs for the ads that accompany content they display themselves.

There are a few applications and services that can recreate the Notes-import process, luckily (although I haven’t actually used any of these):

  • is “a simple and FREE service that makes updating your social networks a snap,” apparently, and looks pretty simple to set up;
  • Within Facebook itself there are a few apps such as My Blog Posts which provide similar functionality.
Curiously there is nothing on the FB blog announcing this change (as of this writing, at any rate). Any Facebook insiders want to explain what has motivated this decision?

Do web designers need a portfolio to apply for a new job?

I was recently asked whether an online portfolio is a must-have for web designers and front-end developers applying for work. I thought it was an interesting question, and deserving of further examination.

One of my responsibilities at is hiring new design talent, and inevitably part of that involves reviewing applicant CVs. The job description for our currently open Web Designer position states, among various other requirements, that applicants must provide a portfolio of work. But with so many experienced designers working in-house for corporations that may be unwilling to allow their internal workings to be exposed in public, is it fair to expect every applicant to be able to display their previous work?

As a hiring manager, I am looking for a designer or developer with relevant experience, and the right mixture and level of skills for the job; that means HTML and CSS at what I judge to be a decent quality, and (for designers) evidence of a basic grasp of the fundamentals of good web design. Of course, once they pass the initial CV review stage then other factors come into play: personality, communication style, and how they react to questions relating to the unique environment in which we work. But in the beginning, that 1-3 page summary of their professional life is all I have to go on. And that means that a good portfolio can really influence any decision.

Naturally this situation unfairly benefits those coming from an agency background, churning out designs and templates for hundreds of clients in an environment where publicising your previous work is actively encouraged. You can see this kind of designer represented every day on design galleries and “50 of the best designer portfolios” list sites; if your own site has a 60pt welcome message stating the obvious (“I design websites”) you’re probably one of them too.

And those applicants are easy to assess. I can flick through their portfolio and quickly form a picture of their design chops; are they comfortable working in different styles, do they have a decent grasp of layout, typography, colour theory, UX? For non-designers, I can View Source and rate their code quality; bonus points for using modern techniques, black marks if I see an MM_swapImage() function in there.

So what are in-house designers/developers to do? They might have 10+ years of solid experience – but if it’s all working on the same website, which in any case they’re not allowed to publicise, how do they prove they have the right skills for the job?

Some might say this is where personal projects separate the men (and women) from the boys (and girls). It’s certainly true that a well-written technical blog and some interesting GitHub projects can help to build a picture of a front-end developer’s area(s) of expertise, but it’s rare to find someone from the more graphical design end of the spectrum with much more than a simple Twitter account. Speculative work is a possibility, of course – but lorem ipsum filled homepages, no matter how beautiful, don’t give potential employers any idea of your ability to interpret business requirements or balance real-life client priorities.

In the end, I think much of the opportunity for these in-housers is tied up in their CV. A well-written summary of their skills and how they have been applied, their major achievements and projects, and evidence of increasing levels of responsibility or upward movement in their role should be enough to at least secure a first interview. Setting technical challenges or spec design tasks as part of the interview process would be another option, although personally I’m not in favour of that approach; I tend to feel that it doesn’t accurately reflect the work environment the applicant will need to work within, and also places an undue demand on their (unpaid) time.

So, is it an unfair situation or not? If you’re hiring designers, or you’re an in-house designer struggling to apply for jobs that require a portfolio of work, I’d love to know what you think.