On Friday last week (that is the 4th of May 2012 just in case you are reading this in 2013) we spent an excellent day up in the BBC’s plush new MediaCity, Salford offices with a bunch of BBC folk, other start-ups and generally bright, vibrant people. The cause was the first instalment of the BBC’s Connected Studio. First, a little about what the Connected Studio is and then I’ll tell you some more about the day.
BBC R&D are looking at innovation all the time with the real possibility that some of the very cool new tech they are currently working on not surfacing for another 10 to 20 years.The Connected Studio is an initiative to look at how the BBC can innovate just a little beyond the existing roadmap for digital. The intention is to do this in a collaborative manner with BBC staff working with invited external digital agencies, technology start-ups, designers and developers to participate in generating new ideas, concepts, features and functions . Find out more here.
The main focus areas each having their own creative studio days are 1) Homepage, Search and Navigation 2) Weather and Travel 3) BBC Children’s and 4) The Olympics. There is a reasonably detailed engagement charter detailing the steps to achieve the goal of generating ideas and moving them rapidly through concept to proof-of-concept to pilot. Each focus area will start with a Creative Studio day. This is a one day event (the first being 4th May. More on that later…) to facilitate ideas and concepts. Out of the ideas pitched at the end of the day, a number of the companies or individuals will be invited back to the Build Studio. The build studio is a 2 day innovation workshop to develop ideas and proof-of concepts much like a Launch 48 (although you already have the concept by this point). The objective is to have a working PoC at the end of the 2 days. Of these PoCs, up to five will be invited to work on a 6-8 week Pilot Build for which there will be up to a £50K budget. The BBC then has an exclusive option for a 6-12 month period to take forward any successful pilot it chooses for full product development.
There is a total fund of £1m to develop concepts throughout the year, with an additional £1m of BBC staff time.
That was a quick overview of the overall concept of The Connected Studio I’ll take you through the experience of participating in the first Creative Studio.
The Creative Studio
We were limited to 2 attendees, as I believe was every other company. So I attended along with one of the UX Consultant’s in our network Alex Ng. The Creative Studio on 4th May was all about Homepage, Search and Navigation. Prior to the day we had been provided with a creative brief so knew that the focus was to explore the potential uses of customisation and personalisation.
You have the option of booking in advance, a 15 minute closed pitch with the BBC and a third party. This is for those that already have a developed idea and want to protect their IP. Everyone else presents in an open session, the time you have to present largely depending on the number of people presenting.
Arriving at MediaCity between 9-10 for registration (I left my house at just after 5am) you get a good breakfast before getting started at 10.
The new BBC Office has lots of space that has been built to foster collaboration and creativity. We were situated in an events space that had been segregated into a number of areas for the main presentations, break out areas for collaboration and another presentation area for some presentations by some key BBC experts that were open to all if they chose to attend.
Adrian Woolard (Project Lead R&D North Lab) got the day started, introducing us (probably about 60-70 people half of which were the BBC) to what the Connected Studio is, the vision unveiled by Raph Rivera and what was expected of us. James Thornett and Clare Hudson then introduced us to the current homepage and it’s journey to now, their strategic objectives and the challenges they face. At 10:40 we were ready to go and had a 4pm deadline to be ready for the presentations.
We had developed a few ideas into one concept on the train up to Manchester so requested a closed pitch on the day but they were full. So, it turned out soon after that we had a 2 minute slot to present in the open session in front of the audience and the camera. Not nerve racking at all! As we already had an idea we went off into our own little space to develop it further, prepare wireframes and a presentation to fit into the 2 minute time slot. Other people gathered around the “ideas wall” to collaborate with others who up to now, had only half an idea and wanted to create a team to work up some ideas on the day. Others went to speakers corner where various BBC experts were waiting to answer any questions.
Supporting the open spaces were a number of 15 minute “expert” presentations in the morning. The agenda was as follows:
I didn’t attend all of the morning sessions as I was deep into developing our idea but both the Homepage Tech session and the Personalisation session were very useful. Both gave an insight into the current state of their topics plus a view of the roadmap ahead. Especially interesting was Tom Broughton discussing their ambitions to implement a Triplestore to allow semantic search features – something that was prevalent in the idea we were presenting.
A very nice free lunch was available from Midday and then the afternoon session was focussed around developing the presentations whilst those that had closed pitch sessions were presenting in a private meeting room. Linda Cockburn, a creativity consultant that led the BBC’s Creative Network for 5 years, did a presentation on how to present and then there was an opportunity to present your pitch back to her and real members of the Homepage audience to get personalised feedback prior to the 4pm deadline.
At 4pm we were all ushered to the presentation area where a number of plasmas, a microphone and a cameraman awaited. There were twenty-three 2 minute presentations. The whole day (as expected from the BBC) was run to strict timelines, the excellent event production team running a tight ship for everyone involved including the 15 minute morning expert sessions. So, the pressure was on to fit our presentations into the 2 minutes, some of which were cut off because they ran out of time. All-in-all there was a high quality calibre of presentations with some excellent and varied ideas produced. Some were digital but to my surprise most were hand drawn presentations on flip-board paper and there was one presentation told in the form of a story.
At the end of the presentations at 6pm, beer and wine were provided (until 11 if you wanted to stick around for that long) for all of the attendees to mingle. Some very interesting people and all in all an excellent day of fun and innovation. The next step is to wait to see if we get through to the build studio (we should hear by the end of this week). The concepts presented will be judged on, Distinctiveness, Relevance to brief, Innovation, Value, BBC public purposes and Connected Strategy (One Service, Ten Products, Four Screens – http://tinyurl.com/connected-storytelling)
Our Concept
Without doing too much of a reveal, our concept was based around turning the home page into a living thing that is more dynamic and more real-time rather than a navigation step that users spend very little time on. Less than 10% of people used the personalisation features in the previous version of the homepage and lots of people will continue to ignore it. With this is mind we introduced various levels of personalisation and testing the idea of machine learning to automate personalisation as much as possible. Once a semantic Triplestore is introduced, this could be taken a lot further.
Our key points were the following:
Here’s one our mock-ups that we presented to give you a taste of what we were thinking:
Summary
I doubt we will pitch for Weather and Travel or BB Children’s creative studios due to this being less relevant to the work we do but you never know. If they interest you though, I would highly recommend getting involved in The Connected Studio whether you are a digital agency, tech firm or and individual designer or developer. It really is an excellent day.
Here’s a few links of interest:
Unsurprisingly, there were several talks about the web and JavaScript at QCon. There is no doubt about the meteoric rise of JavaScript in the recent years, and it's hard to imagine that this will not continue. Web browsers have been powered by JavaScript for years and more and more desktop applications are moving to the web. Node.js proved that JavaScript is as good as any other language for building a framework for web applications. Mobile web seems to be the next frontier and where progress seems to be among the fastest.
Download Slides
Allen is a Mozilla Research Fellow and was the project editor for the ECMAScript 5/5.1 standard.
Allen started off his talk by illustrating the two major eras in computing, the corporate computing era and the personal computing era. A major shift in computing happened in the late 70s and early 80s, where the shift to personal computers radically changed the nature of computing. Currently, we are undergoing another significant shift to what could be called the "ambient computing" era. Ambient computing has the characteristics of being device based rather than computers and being ubiquitous.
Every computing era had a dominant application platform. The dominant platform emerged as the winner through a combination of market demand, good enough technical foundation and superior business execution. The dominant platform for the corporate computing era was IBM mainframes. In the personal computing era, the dominant platform was the combination of Microsoft Windows and Intel PC (much lovingly called Wintel). In the emerging ambient computing era, it is becoming clear that the new application platform will be the web.
Each computing era also had a canonical programming language - COBOL/Fortran for mainframes and C/C++ for personal computing. The canonical language for the web and thus the ambient computing era appears to be JavaScript. Allen brought up the interesting question about what could replace JavaScript and how that could happen. JavaScript, even with it's quirks is "good enough" and there doesn't seem to be any apparent way that it would be replaced by anything else. As such, his claim that "JavaScript will be the next canonical language for the next 20 years" seems spot on.
After the ECMAScript 4 fiasco, TC-39, the committee responsible for deciding the future of JavaScript, is moving a lot faster and is more driven and organized to improve the language. There are a lot of improvements to the JavaScript language coming with ECMAScript Harmony, which represents ECMAScript post version 5. Some might be considered controversial, such as the inclusion of classes, and are ongoing current discussion. Considering the slow browser adoption rate, even ES5 is not yet mainstream and will not be for a couple of years more. This unfortunately seems to be one of the biggest bottlenecks in moving the new ambient computing platform forward.
Tobie is currently the chair of the Core Mobile Web Platform Community Group which is dedicated to accelerating the adoption of the Mobile Web as a platform for developing mobile applications. Tobie and his team at Facebook put a lot of effort into analysing the most popular native applications and finding out what capabilities were missing in web applications to make them on par with native applications in terms of user experience.
Facebook recently launched ringmark, a test suite aimed to accelerate the adoption of HTML5 across mobile devices and provide a common bar for implementations of the mobile web standards. Ringmark provides a series of concentric rings, where each ring is a suite of tests for testing mobile web app capabilities. There are currently three rings, however the intention is to continue the project by adding more rings as the capabilities of mobile devices increase.
Ring 0 is designed as the intersection of the current state of iOS and Android and 30% of the top 100 native mobile applications can be implemented using ring 0 capabilities.
Ring 1 includes features such as image capture, indexDB and AppCache. Browsers implementing ring 1 should be able to cater to 90% of the most popular native applications, most of which actually don't or need utilize advanced device capabilities such as 3D. Tobie highlighted that getting ubiquitous ring 1 support should be the short term goal for mobile browser vendors and developers to drive mobile web adoption.
Ring 2 will fill the gap with the final 10% of applications, with things like WebGL, Web Intents and permissions. Ring 2 is aimed to be a longer term goal.
Mobile Web should also be able to achieve beyond 100% of the native apps, with capabilities such as hyperlocal applications (e.g. an application tailored to a certain local event) and deep linking.
Lack of standards for mobile web applications when it comes discoverability or manifest files was also mentioned as one of the hurdles that mobile web needs to overcome. It will be exciting to see how fast we will be able to reach there.
Slides (Built with HTML5!)
Alex is a TC-39 representative for Google and is also a member of the Chrome team. One of Alex's missions has been to drive the web platform forward. He is as frustrated as the rest of us developers with the current state of fragmented support and slow progress.
WebIDL and JavaScript have a cognitive dissonance problem. DOM was specified as an API for the browser programmers rather than the actual consumers of the API who are the JavaScript/web developers. It was also devised at a time where there were expectations that other languages than JavaScript would be consuming it, and artifacts of such an ideal still persist in the API. Moreover, DOM does not conform to normal JavaScript rules. The DOM types cannot be extended or constructured. It is not possible to do a new HTMLElement() whereas it would be very useful for many scenarios.
new HTMLElement()
As web applications have increased in complexity, the disconnect between application data and the browser model has grown making web development painful. The developers have been trying to solve this using frameworks such as Backbone.js, however they are not perfect. Alex outlined two proposals to W3C that seek to make web development easier.
Shadow DOM is a way to create web components by a browser provided API. Modern browsers include native controls, such as the standard HTML form components. These built in controls are isolated from the rest of the page and are only accessible through whatever API they expose. There is currently no API to create third party components with the same strong encapsulation enjoyed by the native components.
The other proposal is Model-driven Views which reminded me a lot of how Knockout.js works. MDV provides a way to build data driven, dynamic web pages through data binding and templating via native browser support.
Also interesting, but didn't get the chance to attend:
The various efforts around HTML 5, JavaScript and the mobile web all point to an improved developer experience. The question is how soon will this future will arrive? Combined with browser vendors pushing updates aggressively and consumers changing mobile phones every 1-2 years, it might not be as far as it seems. Listening to the talks also confirmed my opinion that native mobile apps are only a stopgap solution and the future lies in HTML 5+ and JavaScript as the platform that will power applications in the future.
Last week most of my time was spent at QCon London. QCon is an annual international software development conference in London that covers a broad range of topics within the software development world. After looking through the schedule for this year, I ended up spending a good chunk of my Red Badger Training Budget on the conference, and it was totally worth it. The conference was 3 days with a massive amount of interesting content. I will try to do a series of blogs to cover the topics which I thought were highly interesting.
One of the most prominent programming languages at the conference was Erlang. As Damien Katz said in his talk, Erlang is a language from the future, built perfectly to scale reliably to multiple processors and cores at a time such needs did not exist. I attended several sessions relating to Erlang, driven by my curiosity for the language.
Joe Armstrong is the creator of the Erlang language. He gave an excellent introduction to what highly available systems are, and how such a system can be built. Highly Available systems have six rules that they need to follow.These are:
Erlang is a programming language designed to satisfy all these six rules. It is not a coincidence that some of the world's most reliable systems have been written in Erlang.
Erlang programs consist of many small processes, which correspond to something between an object and a thread in terms of size. An empty process is around 300 bytes, and the Erlang VM is capable of hosting millions of such processes. Each process is completely isolated and communicate with each other through only messages. A failing process does not effect the rest of the system, and can easily be restarted by a supervisor process. The lack of shared memory and mutable state ensures that it is easy to produce very reliable code.
One of the highlights of the talk was this quote from Alan Kay:
"Folks -- Just a gentle reminder that I took some pains at the last OOPSLA to try to remind everyone that Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging" -- that is what the kernel of Smalltalk/ Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase)...."
"Folks -- Just a gentle reminder that I took some pains at the last OOPSLA to try to remind everyone that Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea.
The big idea is "messaging" -- that is what the kernel of Smalltalk/ Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase)...."
The key idea in OOP has always been messaging and encapsulation rather than classes or methods, which, unfortunately has been how OOP is being taught generally.
An interesting footnote from the session was when asked about his opinion about Node.js, Joe mentioned that he is not really fond of event based programming and the style of such programming is difficult.
Jesper works for Wooga, a German social gaming developer. While their cute Facebook games might not be terribly interesting for software developers, a backend for a single game deals with more than 20 million requests in a day and more than 100,000 DB ops in a second, which makes things a little more interesting.
Jesper outlined the journey Wooga took in terms of evolving architecture, where each new game gave them an opportunity to try something new and evolve their technology.
Starting with a traditional technology stack (MySQL/PHP/Ruby on Rails), the engineers at Wooga eliminated their database bottleneck first by using Redis and ultimately by switching from a stateless server to a stateful one.
To build a robust stateful server, they used Erlang, which brought in other problems such as code readability, testability and maintanability. Their ultimate solution to this was to use Erlang for the core parts of their backend and handoff data to small workers in Ruby using a message queue, which gave them the best of two worlds.
Jesper emphasized how the Wooga's focus on small teams, collaboration, generalists, effort reduction and innovation paid off in spades in their journey to become the 2nd biggest social media games development company.
Riak is a distributed database which is roughly based on Amazon's Dynamo paper. It is similar to NoSQL databases such as Cassandra, CouchDB and Voldemort. Riak Core is a seperate component from Riak DB, and deals with the distributed systems aspect of Riak DB.
The session was a deep dive into how Riak Core implements availability, eventual consistency and partition tolerance, which are the three key aspects of any distributed system. Possibly one of the most technical sessions that I've attended at QCon, it was an inside look into how a distributed system works and how Riak Core solves many of the problems such systems encounter.
Not surprsingly, Riak Core is written in Erlang, which makes messaging across distributed system easy since Erlang processes communicate the same with each other the same regardless of if they are residing on the same machine or not.
Lot of the times we as software developers take for granted that the systems we use should just "work". This abstracts the underlying complexity away from us and makes easier to think in our problem domain. However, having a little insight into how a complex distributed system works under the hood is always interesting and good to know.
Damien is the original creator of CouchDB, a document oriented database written in Erlang. Having worked with Erlang for a real application, he shared several of his observations.
However, it has a caveat: Erlang performance is slow. The Erlang VM, while beautiful in design is not as fast as other VMs like the JVM. Damien linked the reason for this all the way to the strange syntax Erlang has. A language needs mass adoption and investment to be fast, and for this to happen it needs to be familiar to programmers. Erlang's unfamiliar and "weird" syntax is preventing it from getting mass adoption.
Erlang is not a perfect fit for every problem, string processing being an example -- but it is perfect for distributed systems that need to be reliabile.
A lot of the benefits of Erlang can be achieved in C/C++ by following certain practices, however will take as much as 5-10 times the coding effort, but 5-10 times the performance as well.
Damien's new venture, Couchbase, uses a hybrid of Erlang and C/C++ because they simply cannot compete on pure performance with Erlang. However, an interesting point he made was that if you are running your own application, it might be cheaper to solve performance bottlenecks by simply spending more money on CPUs rather than on engineering time.
Erlang, even with its quirks seems to be growing and in Damien's session somebody mentioned that there is a new $5 million investment into the language to improve performance. Patterns found in Erlang can certainly be applied to other languages and help a software engineer approach problems differently. The programming language itself will no doubt continue to grow and be a major player in the concurrent future.
We’re hiring again and looking for a new senior developer. Checkout the job listing on Stack overflow Careers and get in touch: http://careers.stackoverflow.com/jobs/14387/senior-developer-permanent-red-badger
We go to quite a lot of effort at Red Badger to find the right people to employ, people who will invest themselves in our company and what we’re trying to achieve; all very noble. But as with all good relationships, it’s not just about the take but also the give – you get back what you put in.
Part of that giving back often comes in the form of training, be it a book, a conference or even a traditional course. The question is; how much do you spend on each employee and who get’s to say when it get’s spent?
One of the great things you get to do when you start your own company is to put in place the policies you always wanted when you were an employee working for someone else. I’m sure many people ultimately decide to start their own company because they think they can make a better fist of it than their current or past employers. Whilst that all sounds fantastic in practice, one of the other things you have to do when you start your own company, or indeed just run any company responsibly, is to make decisions that are in the interest of company long term security.
We strongly believe in ensuring that we hire the best people and then help them stay the best. We also believe in hiring managers of one so figured we’d delegate the training budget management to each employee; with some ground rules of course!
Here’s the email we sent to our team:
We’d like to set out and agree an open and fair approach to training, such that each employee can self-manage any training courses or conferences they are interested in attending. To enable this we have decided to set a nominal budget allocation for each employee so that they can judge when and what they would like to attend in regards to training. We propose to set this at around £2,000 per calendar year, per permanent employee. Our thinking is that this could fund attendance at a lot of smaller events and courses or the ability to attend one large conference per year. Some things to note: In the case of attending a conference, the price of your ticket and travel will count towards your training spend. This amount is not a hard fixed amount and can be increased to cover more expensive conferences if circumstances allow. This is not a prompt to figure out how to spend £2,000, but intended to illustrate what you can expect Red Badger to contribute to your training each year so everyone knows where they stand and all are treated fairly. You still need to discuss conference/training attendance with us before booking. The ability to attend events will depend on project resourcing. If you attend a conference/course we would expect you to share your experience and learning with the Red Badger team (e.g. lunchtime brown bag sessions) and with the wider community via the Red Badger blog.
We’d like to set out and agree an open and fair approach to training, such that each employee can self-manage any training courses or conferences they are interested in attending. To enable this we have decided to set a nominal budget allocation for each employee so that they can judge when and what they would like to attend in regards to training.
We propose to set this at around £2,000 per calendar year, per permanent employee. Our thinking is that this could fund attendance at a lot of smaller events and courses or the ability to attend one large conference per year.
Some things to note:
As with all things, this is an iterative process which we will tweak and improve over time with experience. I’d love to hear what other companies do and any feedback on whether this deal sounds great/ok/crap.
@dwynne
I always had a problem with the term 'User Experience (UX)' being used to describe a particular discipline - not that I don't agree with the fact that's what they are predominantly concerned with. I just don't like that it seems to imply that other disciplines are NOT about user experience.
I am a graphic designer, and it is definitely (should be) about user experience. But that's probably very obvious - so I didn't complain.
And there are developers.
I recently read an excellent blog about the UX developer by Leisa. She makes a point that some front end developers are so in tune with the idea of user experience, they can be called UX developers for their contributions.
I cannot agree more. But I also agree with one of the comments the article has - "UX dev is just a good front end dev". Because of front end development's closeness to users, in the same way as the visual design and site architecture, it has to take user experience into consideration to do a great job.
What about the back end devs?
You might think, well, it's not important that they understand UX - after all they are not creating direct touch points to user journeys.
I am lucky enough to have worked with some back end devs (i.e. Stuart and David) with strong UX understanding, and oh my, it REALLY makes a difference.
There would be no 'you can't do that because it's not built / structured / stored in the right way', because they understand the importance and WHY you're asking certain things to happen. They would be coming up with alternatives to achieve your goal, or find the way around it. They could suggest you a new way of doing things which you thought technically not possible (or plainly not thought of), because they understand the user journey and user experience principle. It's the same in any disciplines - you can solve problems so much better / quicker when you know WHY something needs to happen rather than just WHAT needs to happen.
So my conclusion is - UX devs definitely exist and it includes ALL devs. If in doubt, try working with one. It's so good, you don't want to work without them ever again. :-)
Location: Clerkenwell
Salary: Excellent plus Share Options
Red Badger is a creative software consultancy – we are working on some really innovative projects with some excellent calibre clients. Our integrated teams (PMs, BAs, UX, Designers, Devs, UI Devs, Testers) collaborate using agile project methodologies (Scrum and Kanban). We are a startup, having been in existence for 18 months and are growing rapidly. We are in need of a charismatic, talented Agile Project Manager to integrate into our talented team. You will be working on some very exciting projects ranging from Rapid Prototyping/Concept Lab type environments to longer term engagements.
You will need:
Desirable:
This is a great opportunity to work with in a really sociable, fun environment. Red Badger is still young but growing so you’ll be involved at an early stage in our history and to have influence in shaping our future.
For more information or to apply please contact us here: hello@red-badger.com
As we now roll full steam ahead into 2012 I thought I’d take the time to do a blog on Red Badger’s year in 2011.
The Beginnings
Red Badger was formed in May 2010 with Stuart Harris, David Wynne and I investing some of our savings into building a company based on specific ideals with a specific long term strategy in mind (this has evolved over the last 18 months). We wanted to be in full control of Red Badger’s destiny and as such decided not to seek investment of any kind. We also made an executive decision that we wanted to dedicate ourselves full-time to Red Badger so decided that we wouldn’t contract ourselves out to clients as individuals to fund the building of the company. This of course had it’s implications. We all quit our jobs and for the next year we would be working in each others homes, building up the company with no income whatsoever.
Into 2011
As we entered 2011, the company was nearly 7 months old and we were still just 3 guys working from each others homes. 2010 had largely been about creating a presence. We formed some key partnerships, pitched to potential clients and generally got ourselves out there. In October, we also started to design our twitter app, Birdsong for Windows Phone 7. By January 2011 we had two main channels of work - we had been working on a couple of large pitches (amongst others) for 2 very big clients and developing Birdsong. By 25th January v1.0 of Birdsong was available in Microsoft’s Marketplace.
Birdsong
At this time, Windows Phone 7 was in it’s infancy having only been released in November 2010 – having been involved in developing on the platform in its beta stages, we had every confidence in a bright WP7 future. However, we knew that Birdsong wasn’t going to contribute to building the foundations of Red Badger in monetary terms and in fact didn’t plan for Birdsong to be making large contributions to Red Badger revenue in the long term as only a small percentage of apps actually make companies a lot of money. Birdsong for us was all about building a Red Badger presence.
The first half of 2011 was an incredibly enjoyable time for Stuart and David being able to focus on developing Birdsong, shipping features in response to customer demand – part of this involved creating a good customer service platform through Zendesk. We also started to do the promotional work around it, engaging with Microsoft at an early stage. The Microsoft activity is on-going but you can read the Microsoft Case Study on-line.
We knew that Stu and Dave’s time on Birdsong was going to be short lived once client projects came through so we had to ensure it was architected really well (This is a given anyway) to allow for someone else to come in, learn the code-base and take over where Stu and Dave left off. By May and over 1,000 BDD specs later, Birdsong was doing pretty well – it was on v1.4, was the leading premium social app on the WP7 platform and had gained some notoriety among the WP7 consumer base and internally at Microsoft. It was achieving what we had set out for it.
We have ambitious plans for Birdsong, were aware that it still had a long way to go and was by no means perfect but were preparing ourselves to have to leave it for a while.
The Madness Begins
In parallel to developing Birdsong we had been working hard on a couple of pitches (amongst others) for 2 really big clients for quite some time (At time of writing neither project is live so we can’t talk about them yet which gives you an indication of their size). In April, we finally won both projects with both of them due to start just a few weeks apart in May and June.
All of a sudden, we needed to build two project teams of ample size and find an office to run them out of. We started plugging into our network of people we have worked with before. We knew they were very high quality but availability was an issue. Everything we do is Agile and built on a UCD approach so we needed integrated teams consisting of a PM, UX Consultants, Designers, Developers, UI Developers and Testers.
With a lot of hard work we somehow managed to assemble two teams with the right people to work on our projects - 90% of which we had worked with before (Which eases the worry of whether you’re getting quality or not).
At the same time, another startup - Fluxx was formed in April. They are a digital strategy company setup up by a number of our friends and former colleagues at Conchango. They had just found a lovely new office in St. Paul’s that would cater for their growth expectations over the next 2 years but at the time they had ample space spare. We were in discussions to partner with Fluxx as a development partner so it made sense for both companies that we would sublet a floor in their building for 6 months.
So, with project wins in place, a new office and a staff rota of the highest quality we secured a bank loan to get us off the ground with rent, buying furniture and equipment. We moved into our new office in May, raring to go.
The Projects
Both projects were very different but both incredibly challenging and innovative. One is an interactive 3D HTML5 website for a large automobile company with no dependency on Flash for modern browsers. The other is a large Government project that I can’t say anything more about. Both are mutli-platform with Web, Mobile and Cloud elements.
The first thing to do was to get the processes and systems in place through which we would run our projects – we now had clients in Germany so a cloud based infrastructure fitted perfectly (See: How The Cloud Underpins Red Badger’s Business) to allow for a remote but collaborative working environment. We also had to educate our clients in the way we approach and deliver projects.
In May, we kicked off our first project, meeting in Hamburg for 2 weeks for project planning and requirements development (Sprint 0). Once that project was underway we started the kick-off for the 2nd project.
It was a very interesting time, integrating two new teams from scratch, getting used to the new office and spending a lot of time flying between Munich, Cologne, Hamburg and London. Over the next few months we iteratively improved the processes of the projects and solidified our working relationships with both the clients and the Red Badger team internally.
Both of the projects have gone incredibly well and are both still on-going 7 months later.
The Intern Programme
With all of the above going on, it is easy to understand how difficult it had now become for us to focus any time on Birdsong development. This presented us with an issue as we have long term ambitions for Birdsong but it is very difficult to dedicate a resource to it that can be earning us up to £1,000 per day when Birdsong has only made us about £3,000 in a whole year. We decided to align Birdsong development with our plans for developing talented youth by using Birdsong as a training platform for our interns.
So, in June (Earlier than initially planned) we launched our intern programme. We advertised for a few months through our blog and a number of University job board sites. In all, we had 65 applicants for 1 position (admittedly some of these were students that seemed to be applying for everything regardless of position and relevancy of their skillset) so there was quite a lot of work to narrow these down to a final 8. We then set the final 8 a coding challenge, reviewed the code that they sent us and ended up interviewing 3. We finally offered Joe (an incredibly talented and self motivated student at Kings College) a part-time position due to start in November. (Joe’s Blog).
We have given Joe the responsibility of owning Birdsong development and support. We are investing in his long term future at Red Badger (we are investing our hopes on him joining us after graduation) so take a senior developer off of projects to pair programme with him when he is with us. This is costing us over £1,000 a week in developing both Joe and Birdsong but we think both are worth it. If we didn’t have Joe we simply couldn’t justify doing this just for Birdsong development.
Joe has now been with us for a month, has two weeks off to sit exams in the first two weeks of 2012 but is making fantastic progress. There is an incredible amount of code to familiarise himself with but he has almost completed the Trends functionality (a good feature to ease him into the dev) and will soon be able to start moving on to more pressing bits of functionality such as updating the Push Service (which we know is in need of some desperate attention). So hopefully, Birdsong users won’t have to wait too long for an update. Watch this space...
Growth, a new office and new project wins
As well as running our two main projects (delivering quality is our primary focus), the second half of 2011 has been about solidifying partnerships, trying to secure new business, and growth (which is dependent on an improving cash flow).
At the beginning of December we moved into a new office as we were growing out of the Fluxx space (at the same time Fluxx were getting big enough to grow into the space we vacated). With so much going on it is taking us some time to get the office in ship-shape but the interior designers have been in, we’ve got water supply/drainage fitted and now need to get the kitchen fitted and let the interior designer do his work. Hopefully it will be done within the next 6 weeks and working in a messy office will be no more.
An important part of our growth is to hire permanent staff so we have started converting some of our contractors to permanents and bringing in other new permanents into the team. Rachel has also joined as Client Services Director (blog) who is responsible for business development and marketing so this should give us the extra focus on new business that we need. We need more people across a varied skillset but finding the right quality (which is absolutely paramount to us) is difficult so that is one of the challenges we face. A nice problem to have.
As well as growing and moving into the new office we have also won new projects, most significantly with a major media corporation doing some innovative rapid prototyping using Node.js (See Steve’s Blog here). We are well shaped for 2012, with 3 large parallel projects and some smaller ones to fit in also. There’s lots of hard but fun work ahead of us.
Moving on to 2012
2011 was a year of transition. 2012 will very much be focussed on securing the future of Red Badger. We have had a great 2011 but it would be naive of us to think we are out of the woods entirely. We are still very young so our focus must be to grow steadily and sensibly and to win new innovative projects with both new clients and existing ones. The first 6 months of 2012 will be very interesting. In the 2nd half of 2012, if all goes to plan, we have some interesting product development plans to kick-off.
We of course will continue to develop Birdsong, hope to take Joe on for a year long full-time placement in June and may potentially bring in new interns/grads in the summer to bolster the Birdsong development team.
We also will be doing a re-branding exercise and overhauling our desperately out of date website. We just haven’t had the time to do it up to now so hoping to get something moving on that this month.
Exciting but challenging times.
Ravensbourne
I realise in this (now rather long) blog that I haven’t mentioned Ravensbourne College. Ravensbourne is an innovative, creative University on the Greenwich Peninsula in South East London. They offer great support services to their post-grads and an incubation programme (with the help of a European Development Fund grant) for startups in London. This acts as a stimulus for new entrepreneurship in London. In Jan 2011 we were accepted into the incubation programme which provided us with free facilities and meeting rooms as well as an opportunity to work with other incubatees that were based there. This very much provided us with a platform from which we could launch ourselves. Our first meetings with our clients were held there and our first projects were won there. So, our gratitude goes out to all at Ravensbourne, especially Chris Thompson (Who heads up the Ravensbourne Programme) and Carrie Wootten (Head of Enterprise and Innovation).
Finally
Happy New Year to you all. I hope 2012 is as good for you as I’m hoping it is for us. I have a good feeling about it.
Over the past couple of months, a small team at Red Badger has been working on a number of HTML5 prototypes for an interesting client. Speed of development and easy iteration have been essential so we've taken the opportunity to try out a new technology stack which has given what we were looking for and is exciting the whole business.
Maybe a demanding prototype schedule isn't the ideal place to chuck away everything you're used to and start afresh, but actually a lot of the front-end development has built on tools and themes we've worked with throughout 2011 and we've found that the speed and ease of using Node has more than compensated for the learning curve. So, what have we been using?
Server
Node - Underpinning everything we've been doing in our prototyping project; Node is fast, event-driven and built on Javascript. Its been fascinating for myself, as a primarily front end developer, and Stuart with an ASP.net background to see how our respective specialisms are converging on a single set of tooling. The module loading system, NPM, which is similar to Ruby's Gem ecosystem, also makes it incredibly easy to pick up and play with the many extensions that are out there - and to create your own too.
Express - A development framework for Node, giving RESTful routing and content negotiation. After working with Open Rasta in .net MVC on a previous project, the ease of setting up applications using Express has been a delight.
Jade - With Express providing the application routing and view rendering, we next add Jade for templating. A HAML-style syntax, offering us simplicity and brevity but compiling to really well-formed HTML and easy to use with HTML5 data-* attributes for Knockout (which we'll come to later). In fact having used Jade for a while now I'm not sure I want to go back to writing "proper" HTML.
Step / Async - Node's asychronicity takes some getting used to after having worked with linear control flows for such a long time. Imagine AJAX callbacks as the fundamental way a language works - you can't rely on other parts of your application providing data at the moment you need them, so you need to be able to create queues for parallel and serial execution. Step and Async are two modules we've tried out for this, both have their benefits but Async seems to be slightly in the lead for what we're doing.
Now - The other great benefit of Node is its ability to serve real-time applications, and the Now module takes this to almost magical levels. Existing as a namespace on both the client and server simultaneously, you can call client methods from the server (and vice-versa) to push data instantly as a general or targetted broadcast. Seeing this in action has really convinced us that Node is something to get excited about, and has wowed the client too!
Client
Knockout - We used Knockout on other projects throughout 2011, but with Node's inherent ability to supply real-time data its really coming to its own. It's a Javascript library implementing the MVVM (Model-View-View Model) pattern, which should be familiar to Silverlight developers, and makes rich UIs a breeze to update. The new 2.0 version, released during the Christmas break, removes the reliance on jQuery for its default templating which really opens up its flexibility.
Underscore - Described a 'utility-belt library' for Javascript, Underscore is another tool that is compimentary to the likes of jQuery and adds a whole raft of functional programming methods to objects and arrays (among other things). It also runs as a Node module so we can make use of it on both client and server, great for code consistency.
Ender - In fact with Knockout and Underscore at work, it was beginning to feel like jQuery had been relegated to just a "ready" utility, DOM selection and effects. That's a lot of weight for something we weren't using very much so as an alternative we're trying out Ender, which allows you to compile your own library from smaller modules - such as the lightweight DOM selector Qwery. And it all installs and builds in a similar approach to NPM.
LESS - A CSS pre-compiler, and another tool we used during 2011, but as a native Node module its integration is now much easier. If you're developing in a Node environment you can use it to watch for LESS file changes and compile locally (we also use LESS.app on OS X), and then deploy the LESS and have the server startup create a complled and minifed version in production. Alongside Jade and Coffeescript its beginning to feel like compilation from more efficient syntaxes down to browser-readable files is becoming a key element to web development.
The whole picture
As well as this Javascript-oriented development we've also been trying out MongoDB and Redis for data storage as part of the stack, with equally encouraging results. And to make project compatibilty and pair programming between our Windows, Mac and Ubuntu users easier we've given JetBrains' Webstorm (and PHPStorm) IDE a thorough test drive - given it has all that familiar Reshaper goodness from their Visual Studio tools its looking like a great combination so far.
It might seem that, with all these Javascript-heavy technologies in HTML5 documents, older browers won't get a look in. As we're prototyping on this project perhaps its not important, but actually support is pretty good. Every view Node creates is sent as rendered HTML, just like any other web server, and in fact due to its speed we're finding that we can make sites less "AJAX-y" than we might otherwise - which of course is better overall for accessibility and discoverabilty. On the client side, Knockout is compatible back down to IE6 and even the 'magic' of Now is mobile compatible, with beta support for older IE versions. Of course we want to move away from those legacy browsers as much as any other developer, but if it's a client requirement this stack can still provide it.
So as a result of these experiences we're investigating using Node and its related technologies more widely at Red Badger during 2012, its already looking like its going to be an exciting year!
Salary: £excellent plus share options
Red Badger is rapidly expanding and we are looking for amazing UX design consultants to join the team at our new offices in Clerkenwell. We are passionate about innovation, agile development, and integrated teams, so you’ll be working closely with some of the best UX consultants and developers around, crafting engaging and immersive experiences which look beautiful and flow effortlessly.
Nice to haves:
This is an exciting opportunity to join a small team at the start of its development when you can help to shape the organisation and the culture as we grow. We are winning new clients very quickly, so we expect the team will expand substantially in 2012.
0845 544 0186
