Read our latest: The year so far & 1.0 update.
Every so often it's worth taking a look back at the events you've been involved in and what the outcome of that involvement was. In April I wrote a post on Open Sourcing Stats. This post continues with that theme of open reflection and process transparency. It's also very important as a way of reporting back to the business that's funding the project. So, here are the details about what we've been doing (workshops, talks, sponsorship), how we've felt they've gone and some stats related to each event. What events have you been involved in and how do you track and measure the success of those events?
FutureJS - as you can probably work out from the name - is a JavaScript-focused event. It's run by the team at :codegram who are based in Spain.
FutureJS was a great experience for Andy, James and myself. The JavaScript community sometimes gets a bad reputation for being highly opinionated and unaccepting of things that doesn't adhere to current trends. FutureJS provided a clear demonstration that JavaScript events can be about variety, sharing ideas and learning. There were talks demonstrating current and future technologies, compile-to-js languages, security and much more.
We ran a workshop with 20 attendees (sold out) that went really well. The point of the workshop is to demonstrate how teams can work productively on a complex web front-end web app. Each team works on individual pieces of functionality and at certain points of the development lifecycle bring those pieces together where things should "just work". And in general they did.
It's also worth pointing out that although we used BladeRunnerJS we try as hard as possible to make the emphasis the workflow, practices and processes. The tooling let's us focus on doing. We also have time set aside to talk about what other tools can be used to achieve similar workflows (Grunt, Gulp, Broccoli, Yeoman, Slurp etc.).
A message to the workshop attendees: you may remember that Andy and I lost our luggage that contained BRJS t-shirts en-route to Barcelona. If you filled out the questionnaire recently about the workshop a t-shirt is now on its way to you. Thanks!
The feedback we got was fantastic and this will be fed into into our next workshop at ForwardJS in San Francisco, which sold out about a week ago. It'll also feed into our product development.
In addition to the workshop we were asked to give a talk after another speaker dropped out. a week or so before the event. We were happy to oblige.
The first set of stats to consider is feedback on the workshop. We were very happy with 4.5/5 star as an overall rating.
I'm particularly please that the approach of "splitting people up into companies and teams, and getting them to work together" got 4.75/5. I'm really excited about this approach and I think it demonstrates the value of having a tool that supports a consistent and productive developer workflow (it's a good one to keep the business happy!).
From a product point of view I actually think 2.63/5 for "would you consider using BladeRunnerJS" is actually really good if you consider all the potential options available when building JavaScript applications and that BRJS as pre-1.0.
The talk covered the concepts we demonstrated during the workshop and seemed to go down really well. The tweet from Pete Hunt of Facebook was a great validator of what we're doing by a representative of a mainstream name.
If you've any thoughts about the talk, please tweet at us via @BladeRunnerJS at me directly using @leggetter or you can drop me an email.
ScotlandJS is a JavaScript event organised by the fine folks at Neo Edinburgh that has been running for a few years now. It's an international event that gets speaker and attendees from all over the globe and, even though it's a JavaScript event, also has talks covering things from mental health to build tools (not in the same talk).
We submitted a talk on Testing Ginormous JavaScript applications through the standard CFP which was fortunate enough to be selected.
Since one of the team was speaking, ScotlandJS is an international event and both Andy and I live in Scotland it also seemed worth getting involved as much as possible. So BladeRunnerJS was also a sponsor and we took up a booth.
In the talk I spoke about some of the problems we came across when trying to "do the right thing" when testing large scale JavaScript applications. I then covered how we solved problems and how we now go about testing "Ginormous JavaScript Apps".
Having a booth at an event gives you a platform; it states that you want to speak to people and that you have something to demo. It's also likely that you've got some swag to give away.
At ScotlandJS we didn't speak to as many people as I would have liked to even though our booth position was prominent. I'm not entirely sure why that was the case. It could be that our demo wasn't interesting enough for the audience; it was Caplin Trader running along side a workbench that shows a single tile running in isolation so it's possible that the financial angle put off the attendees? My talk was on day one and although I didn't speak specifically about BRJS I did mention it. But even then it didn't result in more people coming up and having a chat.
That said, we did speak to people from large consultancies and other well known brands.
Generally, it was very good for "brand visibility", a great conference to be involved in, but I would have liked to have interacted with more people.
Scotch on the Rocks is probably one of the longest running web conferences in Scotland. I attended last year and this year was asked to give a talk - which I happily accepted! It's also a conference with a diverse group of attendees from a number of different types of companies. Traditionally it was a ColdFusion event, but that has very much changed over the past few years and the focus is now Web. This year's talks covered Grunt, the Offline Web (check out PouchDB), NoSQL, Single Page Apps, Realtime (me), Devops and more.
As I mentioned, I was asked to talk about Realtime (Realtime Web Apps in 2014 & Beyond to be precise). Since we know the event is a good one with a diverse range of attendees, and I was going to be at the event anyway it made a lot of sense to also sponsor and take a booth.
In addition to the Realtime talk (video not available yet), as sponsors we were given a 10 minute slot to do a show and tell.
I was also asked to sit on a group panel discussing When is enough enough?:
For SotR we had the same booth setup as ScotlandJS, but we had a lot more people come to speak to us. Being honest, I don't really know why that's the case. Maybe the range of attendees and it being a more general web event meant our product was of more interest?
We really wanted to be part of Devoxx UK because it's traditionally a Java event and BRJS is written in Java. But we also thought that the types of attendees that this event gets are likely to understand what we're trying to achieve with BRJS; we believe that they want to focus on building application and application features and that a toolkit that gets them there faster would make a lot of sense to them.
So, we submitted a talk through the standard CFP which unfortunately wasn't accepted. We then decided to sponsor the event, take a booth and also give a paid talk.
The video isn't available for this talk yet. But it's was a combination of the FutureJS talk with parts of the ScotlandJS talk merged in so if you watch both of those you'll have the majority of the content. As soon as the video is available we'll share it.
This time I managed to drag Ewan along to help out with the BRJS booth. As expected, there was a lot of interest in BRJS. We'll be in touch with the people we met to organise in-house talks, to catch up over coffee and to generally follow up.
One thing that surprised people, and can't have been clear, is that BRJS is Open Source a.k.a FREE. We need to make that more obvious.
We've still a lot more coming up over the next few months.
There are other stats that I really want to eventually capture on a daily basis so we can track them over time. For now, here's the current snapshot:
All-in-all I feel that we've got a lot out of the events we've been to. Some of the main things have been:
We've learned a lot about how best to talk about BRJS. BRJS offers a lot of functionality so it's important to focus on the key problems it solves and features it offers. Once you're in a conversation you can then highlight additional features that are of interest to the person you're speaking to.
I've been working as a Developer Evangelist for over 3 years now and I'm quite often involved in conversations about how to measure success. There isn't a simple answer to this and the ways you can measure really depends on the product or service you're evangelising. BRJS is an open source developer toolkit that is free to download and use. There isn't a sign-up process and we're not capturing usage stats.
Our documentation is reasonably sparse right now, but once we get that fixed (it's in the develop branch and just needs to be merged into gh-pages once v0.10 is released) I think tracking website traffic will be a great measurement of if people are using the toolkit. This will also mean that our own professional services teams, and those of our customers, will start to use BRJS as part of the Caplin Trader developer toolkit.
Downloads of the BRJS toolkit from GitHub is another key measurement that we really need to keep stats of on a daily basis. GitHub's releases API does give us access to a download count per-release, but not a breakdown of downloads over time. So, we need to start capturing that so we can match it up against the events we're involved with.
By "Brand Awareness" I simply mean that people are aware of the BladeRunnerJS name and what it does.
I know that people who work at GitHub, Twitter, Facebook and a number of other large technology companies (social, finance and e-commerce) have heard of BladeRunnerJS. I also know that people like our branding; the name, the logo and the colours. All this is from conversations and from taking time to sit back, watch and listen. You can't really measure this but it's something you can get a feel for.
In the April Blog post covering open sourcing stats I listed that gathering feedback was one of the priorities. FutureJS was a great demonstration of the value of that, but we've had little chance to do any other workshops. ForwardJS is another great opportunity to get feedback from developers in San Francisco so I'm really looking forward to hearing what they think and feeding it into our internal discussions and decisions.
I also want to start reaching out to the people we've met and organise some internal workshops; whether that at the Caplin offices in London or on-site at other company offices. If you'd like to take part in a workshop, or would like us to deliver one at your office, please drop us an email. In addition, I'd really like to get an idea of who has downloaded the BRJS toolkit and what they've done with it.
This is a learning process for myself, for the rest of the team and for the company. The open sourcing process has been a great exercise in the discovery of new tools and processes. This will continue and we're always feeding back ideas into our own processes and into how our toolkit works.
This blog post highlights that measuring success is difficult. So, I'd love to hear how you're tracking success of event involvement and usage of your open source solution.
For the past couple of months the development effort has been focused on ensuring our existing applications are fully supported by the open source BRJS toolkit. Once this work is complete our own teams and those of our customers will be using BRJS.
From there we'll be moving towards a 1.0 release which will mainly focus on improving developer experience by doing things like simplifying the directory structure of BRJS apps, making concepts like bladesets optional and putting some final tweaks to static file deployment. The driving force behind this is to help adoption and use in development environments other than our own.
I'm very hopeful that a v1.0 BRJS will represent a highly usable toolkit that offers a significant amount of value to teams that want to efficiently develop complex single page web apps that scale.