Archive for the ‘Programing & Development’ Category

A Pragmatic Approach

Thursday, December 13th, 2012

Two weeks ago we held the first Geekdom Friday. It’s a once a month, open event where we talk about a technology related subject from which everyone – not just geeks – can learn and chat about.

My talk was about what I’ve learned from the book “The Pragmatic Programmer”, by Andrew Hunt and David Thomas. Although it is targeted at programmers, it contains lots of useful tips on problem solving that everyone can use.

On “Take Responsibility” the book covered why everyone that touches a project (regardless of at what point, or for how long) should make sure that they see it through, and not sit idly waiting for things to go wrong. Because they often do, and when it happens, one should “provide options, not make lame excuses”.

On “Fighting Entropy”, is about how to avoid chaos from taking over your project, covering the “Broken Window Theory”: all it takes is that one small part of the system gets messy or broken, to settle a sense of abandonment and more “windows” get broken without repair, just like in dark parts of big cities. It’s all about cleaning up the mess as soon as you notice it.

The book explains how quality should always be the main requirement of a project, while trying to settle for what’s called the “Good Enough” product: focus on it’s core before thinking about adding extra functionality.

In the talk I covered briefly the “Evils of Duplication” , where I mention the golden DRY rule (Don’t Repeat Yourself) which teaches us to never duplicate ‘pieces’ of knowledge, we talked about Prototypes and Tracer Bullets. While the first are disposable, often paper-based representations of the product (or parts of) used to test specific areas or ideas, the latter are build to keep, to test how the system holds together, to see if it ‘hits the target’ – you’ll have a trivial implementation that you can test to see how it behaves in practice. Once that’s verified, they act as the basic system ‘skeleton’ on which we can build on.

Often Prototypes and Tracer Bullets are mistaken for each other, although they serve a different (yet useful) purpose: think of “prototyping as the reconnaissance and intelligence gathering that takes place before a single tracer bullet is fired.” (quote, p. 52)

In the end, having a pragmatic approach to problem solving is all about constantly reminding ourselves of the big picture. Think about who will use what you are building, take responsibility for it, learn from mistakes and be prepared for them.

More to come next month!

Photo of David Thomas was taken by James Duncan Davidson

A designer’s perspective on a Groovy and Grails meetup

Wednesday, April 1st, 2009

Last Tuesday I went to the first Groovy and Grails meet up in Brighton. Graeme Rocher, the founder of Grails lives in Brighton, so it was very exciting for the Brighton geek crowd to have their first very own meet up down at the coast and outside London. The most exciting thing was that Graeme was going to re-create Twitter in 40 minutes of live programming.

FeraLabs helped to organize the event, so I went along, even though I am not a programmer at all. My background is in design and HCI.  The thought of a geek programmer meeting was slightly disheartening, as I was worried that I was going to be sitting there with blank eyes, not understanding a word.

But to my surprise, my preconceptions were found to be wrong. I really enjoyed the talk.

Graeme started his presentation with a short introduction about Groovy and Grails, including the Grails philosophy, which did sound a little bit like a usability recipe for programming:

  • build on the shoulders of giants
  • embrace convention over configuration
  • use sensible defaults
  • achieve simplicity without sacrificing flexibility

Graeme also highlighted a few geek facts about Grails:

  • Grails is 3-5 times faster then Ruby on Rails
  • in March 2008 Grails had 7000 downloads a month, in March 2009 it had increased immensely to 70.000 downloads a month
Black window of horror

Black window of horror

Then the programming action began. Graeme opened the black window of horror and created a new app. He explained the different folders that were created, and what the different items in them are. For a programmer this may have been a bit basic, but I got excited, as it was something that I recognized.

FeraLabs is building Webnographer in Grails. This means that I see these folders everyday. I work with them and around the code, working on html myself and trying not to break the Grails code.

Graeme Rocher

Graeme Rocher

Graeme whizzed through the different steps of creating Twitter. He achieved this mostly through plug-ins, so it looked really easy. There was of course some manual programming, and Graeme explained the different steps and what the lines of codes were meant to do. 40 minutes later he had recreated the functionality of Twitter. It was ugly, but it did work.

A personal note about Grails: I liked that it seems to be using mainly natural language for its commands. This certainly helped me following the presentation, and will also be useful in my future work in getting a vague notion of what the different lines of code do and refer to.

In conclusion, for me as a designer, it was great to find out what all the bits and pieces of code do. I work with/around it every day and I am definitely curios. This does not mean that I will convert to being a programmer. Yet, this little insight that I got at the talk can definitely be beneficial to my future work, as well as other designers. It can help the communication between programmers and designers, encourage mutual understanding, and result in a better working relationship between both.

So I my question to the programmers is, are you willing to try seeing things from the design and user’s perspective too? And what do other designers think about hanging out with programmers a bit more? Do you think that cross mingling at different events can encourage better working relationships between designers and programmers?

Please leave your comments below. I’m keen to find out what you think.

Where the world’s first transatlantic email was sent from

Monday, March 30th, 2009

Millions of emails get sent internationally everyday, they connect people, enable love across the borders, keep families in touch, and help billions of dollars of trade. So, isn’t it strange that nobody seems to know where the world’s first transatlantic email was sent from?

The other night, after the Connecting Innovation event I got into a conversation with Professor John Carroll from the University of Sussex about the contribution of Sussex to advancing the internet.

I had read somewhere that the first transatlantic email had been sent from the University of Sussex campus. But nobody knew about this important event. Using Danny Hope‘s iPhone in the pub afterwards, finding the information took ages, because of a total lack of any web pages mentioning it. But luckily I found a reference to it in a obituary in the The Daily Telegraph.

According to the article, in September 1973 Professor Dick Grimsdale and a group of American academics sent the world’s first transatlantic email message from the University of Sussex campus. This press release locates the event to a computer in a lecture room in the Engg 2 building. The computer was linked with a network of inter-connecting mainframe computers in the USA.

At the same conference, Vint Cerf and Bob Kahn presented a paper called “A Protocol for Packet Network Interconnection” (pdf). This paper laid the foundation for TCP/IP which is bedrock for how the internet works. TCP/IP is the language that computers on the Internet talk to each other.

In the UK, we have a tradition of placing a blue plaque, on buildings where somebody famous lived, or an important event happened. This post is to gather support for a blue plaque to be erected on the Engg 2 building on University of Sussex campus to commemorate the sending of the world’s first transatlantic email. If you agree, or disagree please put your name into the comments at the end of this post, stating your support, or non support, and we will start the ball rolling.

Post Updated with a photo of Engg II building by Graham McAllister.

Update II spoke with English Heritage and found out that they only do plaques inside London, outside it is done by the local council.

Groovy and Grails meet up in Brighton

Monday, March 2nd, 2009

We are helping to organise a Groovy and Grails meet up in Brighton on the 24 March at 7pm.

Grails is one of the fastest growing web frameworks, and as Brighton has many meet ups for other frameworks and programming languages including Rails and Python, so we thought that it was time that there would be one for Grails and Groovy.  Another important reason is the creator of Grails, Graeme Rocher, has just moved down to Brighton.

Grails and Groovy

The reason that Wired magazine, Pepsi Cola, Sky TV use Grails, and why we at FeraLabs chose to develop Webnographer in Grails, is that it allows one to build an application quickly.

Grails uses the Groovy programming language, which is another creation from the United Kingdom. Groovy runs on the Java platform (which means it will run on most computers), and has a unique syntax that means it easy for both somebody from a Java background to start programming in it, and somebody more used to other dynamic languages like Python, Ruby, and Smalltalk.

The Book

Graeme has just written a book on Grails. He will bring a couple along to sell to the event, but you can order the book The Definitive Guide to Grails 2nd Edition (Expert’s Voice in Web Development) on Amazon as well.

The meet up in Brighton

At the meet up, Graeme will demonstrate the speed of developing in the framework by building a Twitter clone in less than 40 minutes. In my personal opinion not only is Grails fast to develop a web application in, it also has a very low learning curve for both the experienced programmer and the novice.

When and Where?

Danny Hope of #UXBRI (the meetup for User Experiance in Brighton) has kindly arranged for us to use the historic Regency TownHouse.

24 March @ 7pm
Regency Town House
13 Brunswick Square
Hove, East Sussex
BN3 1EH

Sign up for the event on Upcoming to secure your place.

Webnographer – Where we are at!

Tuesday, February 17th, 2009

This is an update of where we are with Webnographer.

We are developing Webnographer using Agile Project Management Techniques. Agile builds the project in very small iterations of between 1 and 4 weeks. At the end of each iteration the software should be working. To give an example with Webnographer in our first iteration the whole system was usable from start to end. I.e. we could build a test, get participants to test a website, and analyse the results.

Not only did we want to just build a tool that could give summative results, for example how long a user takes on a task. But we wanted to build a remote testing tool that could be used for formative testing as well. Webnographer enables this by capturing users interactions on the page, as well as qualitative and quantitative questionnaire data. This means that Webnographer does not just report the state of a system (as in summative evaluations), but also provides insight into where, how and why user errors occur (as in formative evaluations).

So how could we build complex usability testing software in a week? We didn’t. When we started, the building of the test and the analysis of the results had to be done by hand. Over a number of iterations what had to be done by hand got automated.

The Agile technique is a revolt against the traditional waterfall approach. Under the old fashioned waterfall approach the business specifies exactly the software that will be built, the developers build it, and then it gets tested, and hopefully released. The challenge with the waterfall approach is that it often led to software projects running over time and budget.

With Agile each iteration can either add features or rework what has been built before. This has the advantage for developing Webnographer, that as we get feedback from each of the tests that we run with clients, the results feed back into each iteration and add to an improvement of the tool.

Up until now, we have mainly focused on the design of the test set up. The test set up was the most time consuming part and easiest to automate for Webnographer. Before it had its simple interface, to create a test each one had to be hand crafted, taking half a day. Modification of a test was hard, time consuming, and error prone. So we have focused on developing an easy to use interface for the test design. This is now complete.

The next iterations will focus on the analysis part of the product. The driving force is that we want to show people actionable results in an easy to understand way. Sample reports are to follow soon.