Archive for the ‘Programing & Development’ Category

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.

“Anything worth doing is worth doing badly – at first”

Wednesday, December 24th, 2008
Photo by Dan McKay http://www.flickr.com/people/mukluk/

Photo by Dan McKay http://www.flickr.com/people/mukluk/

“Anything worth doing is worth doing badly- at first”

This is a quote from Dick Karpinski that, Jef Raskin, the inventor of the Macintosh computer, quotes in his book “The Humane Interface“.

Last week Dick emailed me to point out that on our home page instead of saying “These actionable metrics will allow you to increase customer conversion rates” I had said conversation rates. One or two other people had also written in with the correction.

The great benefit of this mistake has been it has led to some great conversations.

I have Dyslexia which means spelling is hard. Normally when I write anything it goes through the stages of spell checking, and then getting one or more people to proof read the content. I often procrastinate in putting anything to words because of the frustration of having to go through all these steps, and that my writing is not as good as the rest of my family of writers (my father, mother, great aunt, grandmother, and great great uncle).

But we needed to have our website up to show the worlds that we are here. So, it went up early, imperfect, with areas for improvement. I have left the mistake on the home page, and will apply the Dick’s changes in the new year in the hope that others start a conversation.

The benefit of this mistake has been that I have had the opportunity in getting feedback, that will lead to a far better web site then if had used my previous approach. As Dick Karpinski said to me that was the meaning of his quote, “Anything worth doing is worth doing badly- at first”. The important thing is to confront reality early and often to get past the horrible statistic that half or more of (especially big) IT projects are abject failures.

Dick said that Jef Raskin never tried to settle a User Interface issue by using his authority. He always said, let’s test that. “Quick, cheap, small tests are what let Toyota implement a million suggestions a year. I cannot imagine any Detroit auto maker doing one percent as many.”

This is what we are trying to enable with Webnographer. The idea is a tool to enable developers and designers to confront reality early, and often.