Most often when I'm designing a new site, I focus first on its content pages. Then, working from the inside-out, I finally arrive at the home page. This is the approach that I've taken in my work for New Internationalist. That said, a site's home page is often what people want to see first, so who am I to disagree? Today I want to share and invite your feedback on my work on the NNew Internationalist home page. (Comments are open at For A Beautiful Web)
As part of the New Internationalist redesign project, I’m focussing on how the organization presents itself online. To begin that process, I’ve been researching the printed magazine since it started in 1973. (I should stress that I’m not working on the organization’s overall branding, nor the design of the magazine.)
When I was asked by New Internationalist to design for their online magazine, blogs and shops, the challenge seemed pretty daunting. The New Internationalist site has content that reaches back over thirty years, more page templates than you can shake a riot policeman’s truncheon at and a structure that involves some complex interaction design challenges.I also have limited time, budget and resources available.
Initially, what I had in mind to provide this front-end functionality was a “swarm” of micro-applications, where each little application provided one simple, specific, function, e.g., user registration, comments on content, voting and rating, sharing content, etc. There were other people thinking along these lines too, and – eventually – I came across the MicroApps project, which stated its philosophy as:
MicroApps are small REST applications that are designed from the ground up to be integrated with other applications. Usually, they are not directly useful on their own, but must be integrated into other applications (this is what differentiates a MicroApp from a regular REST application).
Unfortunately, the project appeared to be at a standstill, and my experience with Python was pretty limited. Most of my experience is with Perl, so my investigation headed in that direction, and eventually lead to the topic of this post: Perl web frameworks.
Over the past several years, I’ve worked with many organizations and campaigns that have seen their e-mail subscriber lists grow dramatically. As these e-mail lists grow past the thousands of subscribers mark and head into the tens of thousands, or hundreds of thousands, new strategies for list management are often required.
A couple of weeks ago I wrote about Avoiding e-mail list data corruption and – continuing on that theme – I’ll attempt to start documenting some of the approaches that I have explored to keep large lists growing, manageable, and insightful.
This week I’ll focus on making them more manageable.
After a good banter back-and-forth with my colleague here on the New Internationalist Web Team about CSS frameworks, I thought it would be helpful to jot down the key themes of the debate and possible solutions. Hopefully this will benefit other teams that are managing large collections of inter-linked sites that evolve over long periods of time.
Many of the leading minds of the “semantic Web” movement, like Jeffrey Zeldman and Andy Clarke (full disclosure: Andy is leading the upcoming New Internationalist online re-design), have recently compared CSS frameworks like Blueprint CSS to Dreamweaver. For those Web producers that develop skillfully handcrafted sites, tools like Dreamweaver are akin to training wheels on a bike, or a “colouring between the lines.”
That is argument number one against CSS frameworks: they are too prescriptive in their approach, and limit creativity.
The second argument is that they are not purely “semantic,” that is that their markup contains both semantic class names, and names that are purely for presentation or layout purposes.
I think that both of these arguments are mostly (cough) malarkey, and only serve to divert the debate from where it should really be: manageability (And this is an area that really needs some creative, and innovative, thinking).
A few weeks ago, I started a major upgrade to New Internationalist's broadcast e-mail infrastructure. In the process of the upgrade, I noticed that a small number of e-mail subscriber records had been maliciously injected with arbitrary data (in this case, URLs to some other site).
Upon investigating the issue, it occurred to me that many other sites and organizations with larger e-mails list could be susceptible to this type of e-mail data corruption. So here's a quick run-down of the problem and some possible solutions.
The injection is relatively unsophisticated, and is not specific to one e-mail broadcast tool (i.e., I think it would be an issue for almost any e-mail platform on the market).
A convergence where people interested in and/or working in the areas of alternative media, renewable energy, on-line video distribution, free software and any other form of activism that utilises technology.
By default Bricolage sends email notifications with root relative URLs /like/this. Some time ago the NI techs were chatting about how it’d be nice to be able to click the URLs from the emails. This is a partial solution to that.