Category Archives: Industry

Rape Crisis Hackathon

Naga IT Services
Filed under: Industry, Projects, Workshops

Some Front-end developers coding

Last Saturday, a handful of people from the Cape Town Front-end Developer meetup group got together to hack on the WordPress-based site for local NGO Rape Crisis Cape Town Trust. We ran into some pretty major stumbling blocks, and we didn’t get nearly as much done as we hoped. We did learn a lot, though, and we’re hoping do another hackathon soon to really get some improvements to the site done.

What went well

We set up a git repository and hosted it on GitHub. This let us take advantage of the team workflow features like Pull Requests that are really helpful when a group of people are working on different feature of the same code base.

A list of the GitHub issues

After some fiddling with sticky notes and felt tip pens, in true developer style, we started using GitHub issues to track the things we wanted to do. This worked well, and let us pick up tasks that fit our mix of skills.

The format of the hackathon felt right: one day, lots of coffee, pizza for lunch, and a mix of developers. We’ll probably repeat that format for the next one.

What didn’t go so well

We didn’t do any preparation work before the hackathon. Our goal, broadly speaking, was to take the site’s existing Theme and make improvements and adjustments to it to bring it more inline with the Mobile First Responsive principles that we strive for in our code. When we started digging into the code of the current WordPress Theme, Headway, it started to become clear that that would be difficult to do, especially in the one day that we had.

Nope packages installing

Headway is designed to be used by people who don’t want to see the code: it offers a drag and drop, visual editor, approach to building the site. Being developers, that was the opposite of what we wanted!

After a lot of discussion, we decided that the best course of action would be to build a new Theme from scratch, including a solid workflow using the JavaScript task runner Grunt, and a Front-end Style Guide. We decided this was out of scope for the day, but that it would make a great project for the next one. We decided to see what we could do to the existing Theme during the rest of the day.

What we’d do differently next time

We spent a fair amount of time figuring out what we wanted to do, and how we were going to do it. Our biggest failure was that we spent a large amount of time poking at the Theme confirming that we couldn’t do what we wanted to.

We could have avoided this time sink by having a few of us doing a bit of prep work in advance. We’ll try and do this for the next one: it would make sense for us to set up an issue list and tasks to be done before the workshop so that we could concentrate on the doing rather than just the planning.

The Emerging Global Web presentation by Yiibu

Naga IT Services
Filed under: Industry, Reading

One of the things that Yiibu are very good at it is making presentations about important things: mobile first, progressive enhancement, and all that good stuff. Their latest, The Emerging Global Web, has some excellent and eye-opening information about Asia in particular.

The bits that I found particularly good had something in common: they’re all useful as refutations of “lower income people (usually on featurephones) don’t spend money using the web.” Yiibu’s presentations shows how people in China and Thailand are using a combination of Instagram, Facebook, WhatsApp, and WeChat to run their business. Not only that, but their business is a combination of an informal physical shop and an online shop. This combination is particularly good for rural businesses who can’t or won’t have a physical, heavy, bricks-and-mortar shop.

The presentation also provides a good reminder that we should be building for the future. A particular example they use is China, and its middle class that is growing very fast. This is already an important market, and will become more so as time goes on.

Last but not least: it looks like all the QR codes in the world have run away to China!

Check out the presentation on SlideShare for the full story and stats.

(Responsive) Web Design

Naga IT Services
Filed under: Industry, Responsive

There’s lots of discussion around the intertubes at the moment around Responsive: what it is and how we define it. Over the past few days, more of the heavyweights of the web development and design industry have chimed in. Here’s a quick round-up of who said what.

One viewpoint is that Responsive Web Design is really just good web design or web design done right. Back in July 2011, Andy Hume wrote about being Responsive by default, and how the principles and ideas are behind it are core to what we do as a web developers. A few months before that, Andy Clarke was saying similar things:

Web design is responsive design, Responsive Web Design is web design, done right.

(Specific) Responsive Web Design

In his post “Evolving Responsive Web Design”, Blue Beanie man Jeffrey Zeldman talks about how, although the Responsive Web Design is good web design (and vice versa), Responsive as a thing in itself is important. He insightfully points out that the reason RWD has caught on is because of the specific definition that Ethan Marcotte set up:

If Ethan hadn’t included three simple executional requirements as part of his definition, the concept might have quickly fallen by the wayside.

Mark Boulton brings that around to the business side of things, reminding us that it matters what clients think, and they’re beginning to know about the term responsive, and ask for it:

You see, responsive design is a useful term and one that will stick around for a while whilst we’re going through this change. How else do we describe it, otherwise? Web design? I don’t think so. No board member is going to get behind that; it’s not new enough.

(Device-agnostic) Responsive Web Design

Trent Walton’s article, Device Agnostic, rounds the discussion off nicely, and is well worth a read. He talks about the number of variables and unknowns that we have to take into account (screen resolution, input method, browser capability, connection speed):

With such a wide range of possibilities, the sensible thing to do is to zero in on the harshest conditions (or toughest things to deliver) and build from there.

He talks about Hostile Browsers: how a user’s choice of browser can sometimes be acting against design and modern web technologies. He also talks about flux. See Frank Chimero’s beautiful essay What Screens Want for more about that.

Trent also offers a timely reminder that it’s not all about the new and shiny:

As web designers, it is our role to consider (and plan for) maximum reach and access, even when final results might seem underwhelming or less immersive.

Building things for the One Web

Naga IT Services
Filed under: Industry, Reading, Responsive

There were a few articles doing the rounds recently that touch on some deep, fundamental, aspects of modern day web development. They had some common themes: the importance of being flexible and that this stuff is hard (developing for the multi-device world). We’re still finding our feet, and one area that’s seeing lots of change is deliverables.

Given the fluid nature of the web, what are the right deliverables for designing and building a web site? How can we show work in progress on a web site without showing the whole, fluid, web site? Whose job is it to decide what we show, how many deliverables there are, and to explain why they’re different from “traditional” deliverables?


Jeremy Keith’s Continuum and Ethan Marcotte’s response: Platformed both discuss the squishiness and universality of the web. Jeremy pointed out that despite the fact that there are differences in browsers and operating systems we can still support every browser that can connect to the internet by using a strategy of Progressive Enhancement.

the unevenly-distributed nature of browser capabilities is not a bug, it’s a feature.

you can provide universal access to content and tasks without providing exactly the same experience for every single browser or device. That’s not a failing of the web—that’s its killer app.

He points out that it’s our responsibility to explain this diversity of consumption of the web, to educate clients who don’t understand.

Explaining your design work is part of your design work. It’s the same with web development.

Mike Monteiro often talks about this, too: What Clients Don’t Know (and Why It’s Your Fault). Ethan added to this, saying that because of the fluid, chaotic, nature of the web as a design medium:

we play the long game in this business.

The web is One Web, and it does (and will) go everywhere that it can. Designing and developing something that’s pixel-perfect across a small range of today’s browsers and devices already puts you behind the times. We need to play the long game and build for the unknown: well-formed and structured HTML with Progressively Enhanced CSS and JavaScript that lets our sites go anywhere.


The next day I picked up Laura Kalbag’s excellent article: Delivery Logistics, on A List Apart.

In web design, the deliverables we create are rarely the final product; they’re rarely the thing we’re going to “put live” to any users.

We need to stop acting as though deliverables are the be-all and end-all of web design, and treat them as the communication tool that they are.

This is really important. Style Tiles are an excellent example of this. They provide provide a catalyst for discussions: interface elements without layout, so that we can focus on pieces that make up the design and the layout. The deliverables along the way are essential to the process: we’d never make it to the end, or build the right thing, without things like Personas, Customer Journey Maps, Style Tiles, and so on. We should be treating them more like signposts to the end product than the end products in and of themselves, though.

Even the web site (the “real” deliverable), once it’s gone live, is in a state of flux: content gets updated and moves or breaks things; styles get updated for new branding elements.

Closing thoughts

It’s an ongoing process of discovery and learning. One thing I do know is that, as an industry, our tools need to keep changing to keep up.

Building a mobile and a desktop prototype and testing them extensively is great (and very practical), but it’s important to remember that these are just two very thin slices of how the site will be experienced: browsers accessing the web have a lot of dimensions to consider. More on that soon.

Of course there’s a balance to be had. It’s impossible to test across every configuration, and impractical to test across large numbers. It’s also true that many of the lessons learned at these two points on the spectrum can be applied widely. I think that it demonstrates the importance of getting into testing with browsers earlier rather than later, though.