Blog

Sidekick Studios Hackathon #3: Collectist

Posted on 23rd April 2013 by Patrick Sinclair -

Collectist was an inspired last minute pitch by Jonny that blasted it’s way through the thorough selection process at the Sidekick Studios Hackathon.

Originally called “Collectr”, the idea was to create a mobile application that lets users share collections of their favourite things in innate detail with the rest of the world.

Johnny’s Pearson

For example, Jonny is an avid bicycle enthusiast who has spent a huge amount of time building his custom-made bike and wants to show it off.

He uses Collectist to photograph his lovely single speed Pearson bike.

The bike is made of individual components, including the wheels, brakes, handle bars, saddle, stem, pannier rack, pedals, chainset and so on.

In turn, the wheels themselves are made of BLB track hubs. And at each point, Jonny is invited to add another part to each component - he can describe his bicycle in as much detail as he desires.

Comparing and contrasting your stuff

Now that he’s shared his bike with the world, he can compare his beloved Pearson with other bicycles that have been uploaded to Collectist.

This is done by assigning a Freebase topic identifier to each item. Freebase is a community-curated database of well-known people, places and things - similar to Wikipedia but the information is formally structured instead of free text articles.

As everything in Collectist has a Freebase topic (e.g. bicycle or bicycle brake), we can search for all items of a particular type:

Collections of all sorts of things

There are Freebase topics on pretty much anything, so users are able to upload all kinds of things onto Collectist.

So let users organise their things, we added a collections feature so that stuff could be grouped together. Here are some examples of the collections created so far:

• Jonny’s medals and badges - mostly purchased in Berlin 
• Mark’s lunchtime faves - a list of cafes and market stalls around Old Street where Mark likes to go for lunch
• Kirsten’s Costumes and hats - some of the costumes and hats made by Kirsten, a costume designer
• Patrick’s Portuguese delicacies - tasty things to eat from Portugal including the infamous francesinha sandwich (contains bread, ham, 2 types of sausage, steak and is covered by cheese and tomato & beer sauce)
• Tony's collection of awesome GIFs - some great animated GIFs including a cat driving a car

Let's talk some tech

While hacking on Collectist, we soon realised we would need a generic data model capable of handling relationships between different objects. It felt like a good match for a graph database such as Neo4j, and given the hack day environment we decided we should give it a go.

Over the two days we were able to develop the Collectist prototype as a Ruby on Rails application running on JRuby using the neo4j gem. We found that Neo4j made some of the complex hierarchical queries easy, although we didn't have enough time to master the query language.

However, when it came to deploying the app onto Heroku we discovered that the neo4j gem didn’t support the Neo4j REST API - we’d have to rewrite our app’s domain model with another library. By this point it was too late to do anything about this so although we had a working prototype by the end of the hack day we weren’t able to deploy it.

In the end, I went back and replaced the Neo4j backend for something that is more established and familiar - MongoDB. 

So now we’re ready to share Collectist with the world.

What's next?

Good question!

We took Jonny’s idea and built a proof of concept that allows users to describe collections of their stuff.

There are a number of directions Collectist could take: it could become a marketplace for custom made goods, a place to share and compare your things with other peoples or we could focus on a particular domain such as food or cocktail recipes.

What I like the most about Collectist is how generic it is - it could be used for anything!

What will you add to it?

Sidekick Studios Hackathon #2: Greenterest

Posted on 18th April 2013 by Katie Marcus -

Pitch & Pivot

Asi's initial pitch for the hackathon, as voted to be made by the team, was called ConnectedGardens. The premise was still fuzzy, but the gist was creating a tool to connect amateur gardeners, helping them plan their garden spaces and offer year-round advice on growing and maintenance.

After getting into our team we starting plotting grand plans for a complex 3d drag-and-drop garden designer, laden with expert advice and a database of plants matched to your soil type, conditions and sun levels. But after a few hours of research and head-scratching we realised that this wasn't feasible for several reasons. Primarily, it was way too big for a hack, and also relied on knowledge that we just don’t have. We saw that lots of sites and apps already try to do the virtual garden design thing and none really succeed: probably because the variables are far too wide to be solved by an online tool.

Greenterest: We're Digging It

So instead we embraced our lack of know-how and focused on making Greenterest: a web app that connects amateur but enthusiastic urban gardeners with others, to learn and share in a specially-designed social network. We were all quite surprised to find that a gardening-based social network doesn’t exist already, given the general popularity of gardening. Our research showed that all the current sites seemed to either cater to people who already know their loam from their mulch, or are terribly old-fashioned looking forums with few social/exploratory tools. We made Greenterest with a customer in mind who already Instagrams their growing efforts but isn’t sure where to turn to when they get stuck. It’s for anyone who grows things - whether it’s a few herbs on a windowsill or five acres of rolling landscaped gardens - to show off their progress and trade advice.

The hack

Once we had the idea for Greenterest, the ideas for potential features kept flowing. We had to bear in mind the tight hack timescale and just focus on building a minimal viable product that got across the gist with a target customer in mind. We focused on just creating a user registration/profile creation/photo upload flow for the hack, and sketched up wireframes of the key pages on paper.

The visual design had to come together fairly quickly, so I spent one morning doing a bit of branding exploration before choosing a route to go with. It's almost a given to use green for a gardening site, but I went for a turquoise shade teamed with purple and orange for a bit of an offbeat play on the norm. Some quick illustrations added a bit of charm and served as a site footer that explains the proposition. With no front-end developer on our team, it was a chance for me to dip my toe into code-y waters on some of the finer details of the layout and help Ian out where I could. 

Over to Ian for the tech bit: It's built as a fairly simple Sinatra app with MongoDB. We chose both of these for maximum flexibility over the 2 days of the hack as we didn't really know exactly what we were building. We also started off with the Twitter Bootstrap framework to try and get started quickly but this probably caused more problems than it solved once the design was nailed. The login stuff was a bit of a pain as Sinatra doesn't have that built in. With hindsight we should perhaps have used Facebook or Twitter for this.

On the Greenterest alpha site you can create your Plot: a virtual space where you tell people about your garden, upload photos and tag your plants to find people growing similar things. We made it all about organic discovery: each profile will show similar Plots, popular tags and meta information about the garden, so you can find similar content with no effort. We didn't quite get all of this coded up the hack, but a bit of UI fakery made it look padded out to get the idea across.

If a user doesn't have a garden yet or doesn’t want to upload photos, they can still surf the site and ‘Dig’ (what we did there, you see it) other people’s photos, saving them to their Trug – a curated inspiration scrapbook of others' snapshots.

The name is obviously a play off Pinterest and inspired the tile-based user interface I chose for displaying photos. But actually the app isn't very much like Pinterest: we want users to create their own content rather than regurgitate from others, and ramp up the peer-to-peer learning angle. We'd definitely rename the app and revisit the design if/when we continue to develop it further.

Release and reveal

Because we had a working - albeit basic - prototype by Friday afternoon, we could release it and get some real content in before we presented the hack back to the other Sidekickers. I had gathered some interest on Instagram by posting snaps of my works-in-progress, so we had a small selection of people to email the link to, asking them to try registering and adding a few photos to their Plot. The feedback from this (admittedly small and self-volunteering) focus group was very positive, with most people saying they would love to see the app continue development. (A subsequent post on my own blog also gathered not-insignificant interest, including our first press!)

Sadly however the app did not succeed with the popular vote within Sidekick, placing last out of the three hacks. Perhaps because it was quite straightforward technically and we might have overused the Sidekick Twitter to attract our alpha testers. Who knows?! However, I am still proud that after 2.5 days we had a working prototype app that solves a customer need and has lots of potential for further development.

What next?

During the hack and after, we had loads of ideas for other features that would make Greenterest a genuinely delightful, useful site for amateur gardeners. Eventually users would be able to follow others and see their updates on the homepage, and to tag and follow certain plants or types of plant (veg, herbs, flowers). I'd love to create a snapshot timeline on each user's profile, so they could chart their garden throughout the year and see how it grows and changes. We could have forums for questions and advice, and perhaps even a marketplace to trade seeds and cuttings. There are even obvious monetisation streams such as charging for premium features like a marketplace, affiliate links for related products (or even integrated ecommerce), display advertising and sponsored plots.  The possibilities are huge and exciting. We're just deciding now how best to organise and regroup to take it further.

If your interest has been piqued, head over to greenterest.net and have a play. We'd love to hear what you think.

Sidekick Studios Hackathon #1: Sidetracked

Posted on 9th April 2013 by Johanna Kollmann -

We spent Wednesday evening to Friday afternoon not doing client work, but hacking away during the first Sidekick Balaganathon. 

After a round of pitching, three ideas survived the dot-voting, and the Sidekicks broke into three teams (aiming for a balance of skills). We'd like to share with you what we made; this first post is about the winner, Sidetracked. 

The design problem

You are taking the train from Scotland down to London, and you have some time. You’d like to get off the train somewhere along the way, to walk around a historic town centre, discover interesting architecture, check out a local museum, or savour a pint in a cosy pub. But how do you find out where is good?

The usual way is to find your route on a website like nationalrail.co.uk or Wikipedia, then do multiple web searches for each station along the way to find something interesting.

Mark pitched the idea of a tool that would accomplish this in one step, focussed on a small number of types of attractions. The Sidekicks voted for it, and Johanna and Alex joined his team to help build it. We called it Sidetracked. 

Sidetracked - Discover historic sites, museums and pubs along your train route

Sidetracked shows you what route has the most interesting gems to discover, and makes it easier to plan your trip. Enter where you are leaving from and travelling to, and we’ll show you the top historic sites, museums and pubs along the way. 

We love Sidetracked for discovering places to visit, and for finding some hilarious Foursquare places and tips. Very happy to have built something fun and useful for ourselves!

How we built it: the data

We started out by researching data about all the train stations in the UK to allow us to show the routes, and we explored APIs and databases we could use for the recommendations. We decided to focus on historic sites, museums and pubs (ideally those with good beers and real ales), and ended up using the Foursquare and Untappd APIs. 

While there is a lot of information available about heritage sites and listed buildings, we couldn’t find any APIs and only a few accessible databases. The most promising one we found was Kasabi’s English Heritage dataset (backed up on archive.org after Kasabi shut down). Unfortunately it’s in RDF format, which none of us had experience with. Converting this large set to CSV with Ruby was an option, but would have taken too long. 

For the train times, we are using Realtime Train Info’s API. We had to map the train stations in order to generate a route, and discovered that NaPTAN, the dataset we found via data.gov.uk, had each station, but in Ordnance Survey Grid Reference format. Foursquare requires latitude and longitude. Luckily Alex found this reference for how to convert the data, and did some manual wrangling to make it all work.

The learning: there is less accessible open data out there than we were hoping for. Don’t underestimate the effort it takes to get data into shape.

How we built it: a focused approach

Mark had a very clear vision for Sidetracked. We decided that it had to work for our parents: tourists who are keen to explore Britain’s history and pubs, who will plan ahead, who will use the information on the go, who might not have data on their phones, and who are probably not Foursquare users. This helped us prioritise our efforts during the hackathon, and it also gave us a clear idea of what we still have to build to make it useful for them. 

You can see our backlog and an overview of what we’ve built over on Sidetracked.

The learning: making something useful for yourself works. Having a very clear idea of your ideal user allows you to focus your efforts. A leader with a clear vision can settle debates quickly. 

Take a look, try it, and let us know what you think. Sidetracked is live at getsidetracked.net, and you can tweet us @sidetrackedapp.

In a lean environment, design matters more than ever

Posted on 11th March 2013 by Mark Mitchell -

A few months ago, I wrote of the challenge in maintaining a standard of quality in design using a lean, build – measure – learn methodology. Normally, we approach design as a series of milestones often tied to client deliverables. Each stage has time set against it with a clear deadline. This predictability affords a designer a good bit of focus and occasion for refinement. Iteration and experimentation come at the start of the process; then iteration as a deadline looms — the client's requested changes.

Design's changing role

The team at Sidekick are working with Inaura, an inclusion charity. Our modest goal is to transform the alternative education sector. The product, Narrative, puts the student and their needs at the heart of the system and allows everyone around them to collaborate and share important information. Our task was to create a so-called Minimum Viable Product (MVP) with the charity. We built the MVP in a lean way: feedback provided by our test customers validated each new feature. Everything was subject to debate and rigorous prioritization. One might expect such a process to minimize the role of design, particularly as the product finds its feet. The design process was, indeed, changed. Or better said, refashioned. Design provided guidance and a crucial, ongoing partner to technology in shaping a long-term vision.

During research and customer development, we still collated information, conducted interviews and distilled the information into meaningful patterns. As the team discovered the roots of the simplest, most useful notion of what to build we sketched out potential solutions. Whether marker lines on paper, wireframes, or a basic prototype, the visualizations acted as a tangible proposal. Tinder for discussion, internally and in the field. The product started with one core feature: a journal. In customer development interviews, simply having a visualization of how the journal might work was tremendously useful in getting early adopters on board.

Iterations, many and often

As our ideas took hold, development began. The build followed an agile methodology; lightweight and disposable if necessary. The journal needed a basic user interface, so we quickly designed one. As build continued, we asked more questions and prompted further discussion. Each time we made a small improvement, we made an iteration on the interface — either directly in the code or first as a swift mockup.

The product identity slowly grew more distinctive. With each new feature, a new iteration on the interface. New visual treatments and patterns of interaction influenced those that preceded them. We kept much of the layout simple and straight-forward, flexible enough to adapt to new features. "Just enough design", our mantra.

In practical terms, this meant less refined, visually rich interface design up front. The cumulative effect, however, was comparable in craftsmanship. Each design iteration was closely forged with increased product value, meaning less waste (time spent visualizing components that will never be built) and more fundamentally usable aesthetics in the user interface.

Feedback loops

That said, we did find a need for a more traditional set of deliverables, in parallel to the MVP. Inaura, in their effort to find future customers, needed a tangible display of the product's broad vision. It didn't need to be accurate, only to spur discussion. We invested time to design three key pages for the sales pitch.

Interestingly, this in turn influenced the design of our MVP. We agreed to implement document sharing as the next key feature. It was likely the ongoing, iterated design would have been adequate. However, we saw a chance to take cues from the pitch documents, which were much broader in scope, in refreshing the MVP.

Reflections

Our design work on this project is unique in many ways. Still, I am curious which work patterns will repeat themselves next time. It is fair to assume that we will keep to small, frequent iteration instead of blocked schedules of time. By contrast, I look forward to what the quirks and nuisances teach us, and how they will continue to inform our process. Documenting our learning is not only helpful for us at Sidekick, but an essential piece of work we instill in our projects with clients and partners. The data goes some way towards a project's long-term goals and future investment.

Using visual markers for easier responsive design

Posted on 8th March 2013 by Alex Heeton -

Here's brief tip to speed up your responsive site development: 

This month saw a lot of prototyping for one of our clients. Combined with mobile-first responsive design, this quickly led to a scary number of test devices piling up on my desk.

To stop myself confusing different media-queries and editing the wrong styles, I created these visual markers:

They sit in the bottom right of the screen, and update whenever you resize your screen or rotate a device. 

You only need a placeholder element and a few lines of CSS, all the code is in this demo.