Picle

We launched Picle (currently only for iPhone) at SXSW back in March for this year's South by South West Interactive. Picle adds sound to iPhone photography, allowing you to capture a little audio clip when you take a photo. This photo-plus-sound clip is called a 'Picle', and the app makes it quick and simple to lace individual Picles together into 'Stories'. We are coming to the end of the first version of Picle and we are currently working on version 2.0. 

Will has been blogging about our Lean development of Picle since launch. Part of that development has been user testing, feedback and interviews. Another part of it is observing how users have been using Picle, which has been fascinating for us. 

Watching and listening people's lives through their sights and sounds is quite a powerful experience, it's like stepping into a completely new storytelling ecosystem. One minute you will be watching a family birthday in Israel, the next you will be at an NBA playoff game. To give you an idea of what that is like and to share with you all what we have been experiencing I put together this montage of Picles from around the world. 

It's a great feeling to see people from all over the world use something that you have made.

The App Store has just approved our latest release of Picle - version 1.0.4 - and it is ready for download now. 

Picle is an App (currently only for iPhone) that we launched at year's South by South West Interactive. Picle adds sound to iPhone photography, allowing you to capture a little audio clip when you take a photo. This photo-plus-sound clip is called a 'Picle', and the app makes it quick and simple to lace individual Picles together into 'Stories'.

The latest update is packed with new sharing features - yes, you can share it directly into Tumblr, embed it straight into your Facebook stream (as well as uploading it directly to YouTube or to PicleApp.com - the website we've built for people to publish Picles and Stories to). 

We've made a number of releases since launch - this is the fourth - and each time we get more people using the app in new ways. The way sound adds nostalgia to your pictures is really unexpected, and a quality that makes Picle a powerful storytelling platform. I've chosen some examples (below) from the thousands of Picles people have uploaded and shared to give you a better idea of some of the amazing things that people are doing with Picle. 

Four inspiring examples of great Picles from all over the world 

1 - @siobhanwatts and her 'Instant Morning'. This gives a lovely insight into a morning routine, a brief glimpse into someone else's world. 

2 - @nguyenduong  Story of his time in Kauai, this Story gives me wanderlust.  It feels like watching one of the old photo carousel wheels of someone's holiday, but without their narration. Instead you have the much richer ambient audio of ice clinking, birds squawking and the waves crashing.

3 - Mandarin 940's 'Pigs and Pandas' is a lovely example of storytelling. Seeing and hearing someone from another culture use Picle to create a narrative around these play characters is a real validation of Alex's original thought that sound could enhance imagery.  

4 - And our very own @v_bee making her home made Lemon Curd. There have been quite a few examples of people documenting making meals and other goodies and this is one of the best. This was stuff was ridiculously tasty and I love how we get to see the making process behind it.

As readers of this blog will know (we've written about it here), we are developing Picle in a lean way, so we launched as a Minimal Viable Product and we have been building new features for each release based on user feedback, interviews and testing. For example when we first launched we had no social features built into the app and with this release we have made it possible to post Stories as a video to Facebook & Tumblr as well as Twitter and YouTube (a feature from the previous release). 

We have made some changes to the user interface as well. If you are a first time downloader there is an introductory few slides explaining what Picle is and how to use it. 

  We have also added a swipe feature to stories meaning you don't have to go into the story if you want to delete, rename or share it. The two pictures on the left shows the app in a pre and post swipe state. We have also repositioned the share button so it is more prominent in the story screen. You can see it in the picture on the right in the top right hand corner.  

        To share a Story tap on the share icon and you will be given the sharing options. If you want to share as a video to Facebook, YouTube or Tumblr tap on the 'Share as Video' option. This will bring up those options, you then need to configure and then you can share.  You can then see how the uploading process is going and Picle will let you know once your story has been posted. 

Apologies for the radio silence on how Picle has been developing since the last release. The reason for this is that we have been wrestling internally over what Picle actually is. It sounds rather existential, but by watching how people use Picle and feedback to us, we have had to ask some deeper questions than 'How can we get more people using the app?'.

Here is a panaromic shot of some sketches, printouts and timeline up in the Picle den. 

Firstly  to help inform our decisions we focused on the things we have received the most feedback about. 

    Player - Consumption of content 

Communities - Finding other users and sharing your content. 

  We then explored 3 different scenarios for what Picle could evolve into. 

  1. Optimise mobile so there is an Instagram like stream.

This would be mobile focused only and we would leave the web service.

  2. Focus on Picleapp.com 

A webservice where you can upload and view picles on the web. More like You Tube.

  3. Develop Picle to be a Broadcast Utility 

So the user can capture, upload and share to the world as .mov files

  Whilst weighing these up and debating the pros and cons of each we also have to take into consideration that we are developing in a lean way and we also have to ship our client work. It would be lovely to dedicate all of our resources on getting all of the above optimised, but we must priorities and choose what features are achievable. As Tim mentioned in this post

  Let's be really honest - we're a small product innovation and service design company with clients. Our model is to help clients make their own product and services and we're not set up to launch and operate our own.

     We decided that focusing on just 1 of the above directions isn't the best way to use our resources, it is in fact a mixture of 1 & 2. 

The reasoning for this is that building a stream a la Instagram for the iPhone is quite a large undertaking and not the best use of our limited time and resources. We also know that with the app we have a creeping technical debt as we are adding new features onto what is essentially a prototype base. This means that we will have to do a re-write of the app fairly soon and building something of that size within the app would rack up lot more debt that we will have to deal with later. And if we were just to focus the web service, it would mean that the difficulty of sharing, finding others and the UX of the app would not be resolved.  

  The web service's player is something that we have had a lot of feedback for. As we don't have a stream on the app yet the web service is the platform to consume the content created by other users. In order to make that consumption of content better we will be working on improving the playback for the player. There is work going on in the back to improve the gapless playback and experience that I can't show yet, but here is one of the designs we have sketched up that will improve the experience. 

    To address the feedback we have received about communities we looked at what sharing currently means on the app. At the moment a user can share to Twitter, Youtube and email, but cannot find other users on the web service or app. We created this story to articulate the user's journey   

  'As a user I want to create a log in and connect my account through Facebook + Twitter connect, or through email.'

  Lots of sites and apps are doing this in lots of different (and there is another blogpost in the pipeline about that). The pictures below show a prototype of how we are re-working the user journey on the app so that you can find other people through Twitter and Facebook. 

    These new features will enable people to find out who else is using Picle, as I have mentioned before the ability for people to discover and share is absolutely key to the experience of Picle. 

Toot toot! Picle 1.0.3 is in the app store. It isn't the overhauled socially integrated version that I wrote about previously, but it does include something that we have had a lot of requests for, converting picles into movies. There are also new notification screens for uploading stories and the uploading of individual Picles has had some improvement tweeks made. 

To convert your Picles into MP4, create your Picle or story and then tap edit in the top right hand corner.

Then tap the share button in the bottom left.

This will bring up your options, then tap make into movie. 

Processing...

Then just tap to save it to your camera roll. 

Once tapped you will be notified that the movie is now in your camera roll. 

From the Camera Roll open up the movie and tap on the share options and you can Email, Message or Send to YouTube. 

And here is my first Picle as a YouTube video. 

From all the feedback we received after the first release improved sharing and integration with Camera Roll were the most requested. So we are pleased to say that we have made both of these possible with this release. This release also contains bug fixes, improved error messages and an improved camera with tap focus, which  Julian blogged a couple of weeks ago. 

I will just take a minute to take you through how to use these 2 new features in the app. 

- Improved sharing options that include Twitter and Email.

  To share open the story you want and tap edit in the top right hand.

    This will open up the edit section and the share button will appear in the bottom left corner.

     From there you can select how you want to share. 

    - Integration with your Camera Roll.

  One of the most requested new features from testing was the ability to use existing pictures from Camera Roll and to save pictures taken in Picle to Camera Roll. In this new release all images are saved to your Camera Roll by default.  If you want to change this tap the settings tab and turn 'Save pictures to camera roll' to off.  

    If you want to use a photo from your Camera Roll  tap the Camera Roll icon in the bottom left hand in  the image capture screen. This will then open your Camera Roll and you can simply choose a picture from there. 

      We have some bigger changes for Picle arriving a bit later on, but for now this version will improve your experience and enable more sharing. We are aware that you may get some error 500 messages when trying to upload Picles, we are working on this as much as we can so please do bear with us whilst we try to resolve it. 

Last week we had our first Picle strategy meeting since getting back to blighty from SXSW. We have digested a lot of feedback from tweets, emails, reviews, articles, as well as testing it out ourselves, and it was time to step back and take a look at where we're at.

We started off by evaluating how the launch went and how people have responded to the concept of Picle. Stuart drew this rather rudimentary graph of the potential life span of Picle.

The circle represents our current status.That spike is from the release and the fantastic publicity generated from SXSW. As I wrote in my last post we went to SXSW with 15 users and came back with 30,000. 

  To put this in a bit of perspective FourSquare arrived at SXSW 2009 with 50 users and left with 5,000 users

So now that we have that initial spike of users there will be an inevitable dip, downloads have dropped off a little since we arrived back, but we have broken the 45,000 download mark. According to Stuart's graph the app can go 2 ways. 

  1. We can trundle along steadily making changes in the app improving the user experience and making the whole thing a lot more polished. However, this route is doomed to fail, while the experience may get better the inability to attract new users and expose the app to a new audience will result in Picle fading away into the digital ether. This scenario is represented in the rather upsetting looking line A. 

  Or

  2. We stabilise the app and greatly improve the sharing features so that Picle is introduced to new audiences and users. Represented by line B. 

  Our MVP of Picle has validated the riskiest part of the proposition - that people want to combine pictures and audio and  to string these together to create a story. The level of interest in the app so far and the number of different use cases we've seen prove that. As does the fact that people are bothering to give us feedback. As Eric Ries says, if people care enough to tell you your MVP sucks and how you should make it better, then you're on to something.

  The next step is harder. We have to start making difficult decisions and prioritise what to do next - which of course also means not doing all of the things we'd like to. As Tim wrote in his last post

   Prioritising things is very difficult. Our evolutionary journey has ingrained many instincts that conflict with this Lean approach. We humans all want more than we can eat

  We have an interim release that is awaiting clearance in the app store now. This release has a number of bug fixes, much improved stability, and some quick win new features such as the ability to share via email and Twitter as well as the much faster tap focus camera Julian blogged about.  If all goes to plan this should go live next week.

  But we're already working towards another release with more new functionality. I'd like to share with you what we're planning for that. With Stuart's advice in mind, here's a list of the 3 most important things that we are working on. 

  1. Develop frictionless sharing to multiple social platforms. A lot of the feedback we have received has been that people want to share seamlessly via social networks instead of having to grab the URL of a story/picle and share that manually. We expected that this would be the case when we developed the MVP and this is a validation of that. 

  2. Create an introduction page. At the moment the app is a bit sparse on how to use its features. We have been fielding a lot of questions around the difference between picles and stories as well as the different audio recording settings. 

  3. Create a login/sign up page. To find the signup page at the moment is a bit of a search (it's in the settings tab if you are still looking). People have been getting 500 & 502 errors meaning that they haven't yet signed up to the web service, so user's picles and stories are sitting idle on their phones. We need to develop a login/sign up page so that they can find their friends easily and start sharing their Picles immediately. 

  We have been working on some early prototypes which flesh out the user journey. I have added some preliminary sketches by Tom to give you an idea of the process we are thinking of. 

    The reason that we have only focused on these 3 things for now is because we want to get the next version of Picle into the hands of users quickly so we can see how those features will inform further releases. We've picked out the features we think are the most important to help Picle reach a wider audience and make it clear to new users how to use the app. 

  I want to stress that the release waiting for approval by the app store does not contain all of the above, but it will include a number of bug fixes, much improved stability, Twitter and email sharing, as well as the improved camera functionality. 

  If you look at Tim's iPhone App Icebox from his previous blog you can see that we are working our way through it. The crosses mean completed tasks. The darker circles are the tasks we have bumped up the priority list. 

I’m going to share some of the thinking and code behind the Picle iPhone app starting with the camera functionality. This will involve showing some code snippets and describing classes and frameworks found in the Apple iOS SDK. 

  At the heart of the the Picle app is the ability to use the iPhone camera and microphone in quick succession. The user experience of this functionality is critical to feel of the app so plenty of work has been done both before and after the initial release. Indeed the next release will have this completely reworked.

In iOS there are two distinct ways to handle the camera. One with the UIImagePickerController (iOS 2.0 onwards) and the other using the newer AV Foundation framework (iOS 4.0 onwards). The initial release of Picle uses the older UIImagePickerController whilst the next release will use the AV Foundation framework.

UIImagePickerController

Those familiar with the iPhone camera will have seen that when the camera is opened or a picture is taken an iris shutter animation is played. As we use the UIImagePickerController in the current version of Picle users will be familiar with the view below.

We lay our own graphics over the top to give us our own controls for the camera. The picker initialisation is shown below. We do the usual Objective-C allocation and initialisation. We set the source to the camera as opposed to the camera roll or library and explicitly turn off the standard camera controls.

_imagePicker = [[UIImagePickerController alloc] init]; _imagePicker.sourceType = UIImagePickerControllerSourceTypeCamera; _imagePicker.showsCameraControls = NO;

We can however still control the flash through the cameraFlashMode property. This can be of types auto, on or off. We can also set which camera is to be used through the cameraDevice property, front or rear. We add our own buttons for selecting these options though these don’t apply to the 3GS. These controls sit in custom view on top of the picker view. Displaying the picker is simply a case of calling

[self presentModalViewController:_imagePicker animated:NO];

And is dismissed with

[self dismissModalViewControllerAnimated:NO];

Using the UIImagePickerController is pretty simple and doesn’t require much code to get it to run, however the problem with disabling the camera controls is we lose some functionality like tap to focus and set exposure. We also don’t really want the iris animation so together this became the motivation for rewriting the camera functionality using the AV Foundation framework.

AV Foundation

Using the AV Foundation framework gives us considerably more control over how the camera is configured. We wanted to eliminate the iris, have a faster start and faster capture. The AV Foundation framework enables you get input streams from multiple devices and manipulate video during realtime capture. There is however more code required and one downside is that when taking a still image the video camera is still active. We take a frame grab of the video to place in a view above the video camera while we process the still image. We cannot stop the video until the still image has been captured.

Here comes a snippet of the code to initialise the capture session.

// Init the capture session AVCaptureSession *newCaptureSession = [[AVCaptureSession alloc] init]; newCaptureSession.sessionPreset = AVCaptureSessionPresetPhoto; // Init the device inputs AVCaptureDeviceInput *newVideoInput = [[AVCaptureDeviceInput alloc] initWithDevice:[self backFacingCamera] error:nil]; // Setup the still image output AVCaptureStillImageOutput *newStillImageOutput = [[AVCaptureStillImageOutput alloc] init]; [newStillImageOutput setOutputSettings:[[NSDictionary alloc] initWithObjectsAndKeys:AVVideoCodecJPEG, AVVideoCodecKey,nil]]; // Setup the video grab output AVCaptureVideoDataOutput *captureOutput = [[AVCaptureVideoDataOutputalloc] init]; // Specify the pixel format [captureOutput setVideoSettings:[NSDictionary dictionaryWithObject: [NSNumber numberWithInt:kCVPixelFormatType_32BGRA] forKey:(id)kCVPixelBufferPixelFormatTypeKey]]; [captureOutput setAlwaysDiscardsLateVideoFrames:YES]; // Use GCD to run a thread to capture video frames. dispatch_queue_t queue; queue = dispatch_queue_create("cameraQueue", NULL); [captureOutput setSampleBufferDelegate:self queue:queue]; dispatch_release(queue); // Add inputs and output to the capture session if ([newCaptureSession canAddInput:newVideoInput]) { [newCaptureSession addInput:newVideoInput]; } if ([newCaptureSession canAddOutput:captureOutput]) { [newCaptureSession addOutput:captureOutput]; } if ([newCaptureSession canAddOutput:newStillImageOutput]) { [newCaptureSession addOutput:newStillImageOutput]; }

In essence what the code above does is to create a single capture session that consists of these:

A video input - that’s what the user sees in the view and can interact with.

A video capture out - that’s what we grab frames from.

A still image output - that’s for when the user takes a picture.

We have to add the video preview layer to the layer of the view we wish to run the video in and then call [newCaptureSession startRunning] to start the video.

We make the class containing this capture session a delegate of the capture and still outputs so methods get called when each frame is shown and when a still image is taken. A copy of the last video frame is kept so when we take a still we have an image to cover the video input. We also animate a flash effect over the whole view to visually indicate the taking of a still image.

Key to the new camera was also adding tap to focus. The capture device has the properties whiteBalanceMode, focusMode and exposureMode. If the device supports those properties we set all three when the user taps the camera view. We also render a custom focus box to show visual feedback.

Conclusion

The end result of the using the AV Foundation framework is that the camera starts and takes still images quicker than the UIImagePickerController. We also get the tap to focus functionality we required. Clearly there is a huge amount more code involved in using the camera on iOS but I hope this little taste of what we’ve done can at least show the depth development has to go to complete desired functionality. This is also only a small part of the overall app.

References:

http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UIImagePickerController_Class/UIImagePickerController/UIImagePickerController.html

As with most social online applications, you can think of the data as more like a graph than very simple objects that stand alone. This kind of an application and data is my favourite kind of system to architect and here is why. I warn you, this might get geeky..

One of the fundemental concepts behind Picle is the ability to share your moments and stories with other people, in the same beautiful way that the iPhone app allows you to play them.

We could have acheived this in an Instagram fashion, having just a single page for a story that's viewable around the web. This however, seems like an opportunity missed. Picle is all about sharing, but perhaps even more important is the community behind it. So we decided to create a fully functioning website, where you can follow your friends, like their posts and share them around the web. This means you get your own picleapp.com login to view a dashboard which is effectively a stream of moments and stories created by the friends you are following.

  Part 1: The Data Layer

It's all about relations

As with most social online applications, you can think of the data as more like a graph than very simple objects that stand online. For example, consider the image below, showing users following each other.

    If you were to model this using a traditional relational database using joins or similar (MySQL, PostgreSQL), it wouldn't be too hard, but you would soon encounter problems and difficulties for the kind of calculations and more importantly the scalablity you want to achieve.

  In fact, as I have found before, that sort of database has almost zero features that I would require for architecting the data structure for Picle, which include but are not limited to..

  Scale and redundancy over multiple nodes without losing availability. (i.e be able to take a fifth of your database stack down and still support sufficient reads)

Distrubution of data by adding more nodes, moving and replicating the data around the ring of available nodes.

Advanced queries that can walk many links, perform intersections, etc and reduce the final results to a caluated set which can then be stored (i.e MapReduce).

No global write lock, meaning the system is not affected performance wise by the amount of writes or reads happening concurrently.

  If you look hard at the previous graph you can now perhaps see a theme occuring, with "Nodes" and "Distribution". Our data can behave and be modeled just like our databases. Which even leads me to think, that for this kind of application, traditional web stack databases would be the completely the wrong choice.

  So, how do we store these relations and the values that they need to relate to and what do we store them in.

  We essentially need to be able to store two types of data, the main "values" and the relationships between them. In Picle the main values are in model terms a "User", "Moment" and a "Story". A "User" can have many "stories" and many "moments". A "User" can have many followers ("Users") and be following many "Users". Which then creates a stream of their "moments" and "stories" for the user to view.

  Before we look at the database, let's view this in a pure computer science like way and just create it in data structures. Using the structures you already understand. Arrays and Objects.

  In the following diagram, grey items are Objects and orange objects are Ordered Arrays.

    Storage Engines

What we're looking for then is something that allows us to store the following.. 

  Stored ordered arrays.

Key/Values (perhaps in a hash format, instead of JSON)

Ideally it would also be (mostly) persisted, available and tolerate node failures, this is refered to as the CAP theorem, stading for "Consistency, Availability and Partion Tolerance". A theory first conceived by University of California, Berkeley computer scientist Eric Brewer. The theory was famously first put into practise by Amazon in developing the Dynamo database, which powered much of their site, infrastructure and is most notably the system behind S3. The theory states that not all three of these laws are possible at once and that a tradeoff must be made. So, onto choices..

  Amazon DynamoDB (recently released, very promising, somewhat expensive)

Riak (based on the Dynamo paper, open source and supports multiple storage backends, automatic handling of nodes/partitions and replication of data/hashing)

Redis (semi persistent, extremely fast, cluster not yet here/on the way)

Cassandra (built by Facebook, table like, built in distribution, uses a confusing protocol)

Unfortunately, none of these currently meet all requirements for me personally (which will come in part two), so I have used a mix of two. One of them might suprise you, but which I also plan to change..

  Picle runs using Redis to store all relationships and MySQL as the key/value store. Why MySQL? Well, I planned to build the project entirely on Riak but had a lack of time and didn't have the time to build the model layer that includes validations, error messages and form generation in either Ruby or Javascript. So, for now, MySQL is used as a pretty much pure key value store. This does have some advantages, backups, simple queries without writing map reduce (not really a big gain) and the use of AWS RDS.

  Conclusion

With MySQL in a state that would be easy to replace with any key value store, I'm in a good position. MySQL performs very fast under these conditions (around 50,000 ops), as there isn't a single join and every lookup key I use is on a secondary index. But I will be in trouble when I come to move to two servers, Riak will be in use by then..

  In part two, I'll move on to how you would go about writing an app with this architecture and include sample code. I'd also be extremely interested in what other people think about this type of social scaling and different tools for distributing the data layer.

picle's a bit like a comic. As @malbonster said, it's more dreamlike than video. I think part of that comes from the spaces between the frames into which you have to insert your imagination. That was a theme of Scott McCloud's amazing graphic explanation of the history, meaning and art of the comic, Understanding Comics. Here's his illustration of the design decisions a comic artist makes. It's a remarkably good guide to how to make a great picle, too. 

After a week of BBQs, speeches, panels, margaritas, putting names to faces and more BBQs I’ve landed back at Made by Many HQ and I want to share some of the Picle love.

When we launched as a Minimal Viable Product last week we weren't sure what to expect and how people would react to the app. A week has passed and we’re delighted with how well Picle has been received. 

We went to SXSW with 15 users and we came back with 30,000. 

There has also been a lot written about Picle in articles, reviews and posts. Here’s a select choice of some of them. 

Forbes

Cult of Mac

Fast Co Exist

French Web

The Hairpin

It’s Nice That

Popwuping 

TBWA’s Curiosty Counts blog

BuzzFeed

Youth Leader Stash

The response on Twitter has also been great, with Apple's App Store account promoting the app, adding to the hundreds of mentions, retweets and pieces of feedback. We even managed a few sightings of Picle in the wild at SXSW. 

So, back from another SXSW :(

It's great to be back in a country where the butter doesn't contain sugar by default, where fizzy drinks don't come in buckets and where you can buy meat in units of less than one pound. But... I will miss adding cheese and chipotle oak-smoked maple-flakes and sugar-coated tequila-bacon dust to my deep-fried food. If we hadn't got out when we did I would not have fitted through the doorway of the plane.  

It was another awesome trip for Made by Many for many reasons - not least because of the way people embraced Picle, the iPhone app we launched. 

We promised to make Picle an open experiment in Lean product innovation. To that end, we approached SXSW as a giant customer development exercise. This blog post is about how we prioritised the feature-set that we launched with, and how we might grow and evolve from that Minimum Viable Product.

In particular, I wanted to start by explaining why the features above were prioritised ahead of some of the seemingly-obvious must-haves like social sharing.  

Let's be super-clear, the Picle app and companion web service/website we launched last week were about as minimal as you could possibly get - but that's the point. 

The feature-set above was the absolute least that we could launch something with in order to get useful, actionable feedback about where to go next.

Prioritising things is very difficult. Our evolutionary journey has ingrained many instincts that conflict with this Lean approach. We humans all want more than we can eat - it's not just Texas! 

We've tried very hard over the past decade* to overcome these unhelpful instincts when making new stuff. What we've found useful we've stolen and syncretised - our approach is an ongoing experiment but you could describe it as the bastard love-child of Agile, Lean, Visual Thinking and Service Design. We're like magpies - nicking tools and ideas and rolling them into an emergent set of practices. 

At SXSW we went to an event at Adpative Path's offices where Made by Many's @saulpims talked about this. The high-priest of Lean, Eric Ries, introduced the evening with a suitably inspiring statement that resonated with the way we've approached Picle:

This is a philosophy we've been talking since about 2006. This little excerpt from the still-very-excellent Getting Real book by 37 Signals is packed with gems that neatly encapsulate the approach, for instance:

Skip forward to 2012, and we're using that approach in conjunction with a live feedback loop from real people - in this case, the thousands of comments, ratings and reviews, tweets and conversations we've had with real people about Picle over the last week. 

We deliberately launched Picle without features like social sharing. We deliberately built less, because the leaner you are the easier it is to change.

To quote 37 Signals again:

Less mass lets you change direction quickly. You can react and evolve. You can focus on the good ideas and drop the bad ones. You can listen and respond to your customers. You can integrate new technologies now instead of later. Instead of an aircraft carrier, you steer a cigarette boat. Revel in that fact.

So, here we are - lining up the next releases and weighing up what to add and how the vision has evolved. Instead of  trying to guess, or simply indulging our guts, we've got loads of evidence. We want to do this in the open, and so we're going to share.

Starting with the iPhone app first then (remembering that we also launched a web service and Picle website, for which there is a separate MVP and Icebox) - the diagram below shows the launch release/MVP feature-set, and a bunch of features that we're thinking of buidling in subsequent releases. The future features are labelled 'Icebox' for obvious reasons. But please also bear in mind that we are also applying fixes and optimising functionality that's already live - both of which have been ongoing since before SXSW and will likely make a new release in a couple of weeks . The darker circles are also already in the next release.

It is a law of nature that you will always have more ideas than you have time to make, but the point is that the things on the left - in the MVP - were prioritised because the things on the right probably wouldn't make sense without first having them in place (for example, there's no point in building sharing in before you have something to share).

Of course, it's going to get more tricky, as we're going to have make decisions about which direction to take Picle in first. In this, we shall be led by customer feedback and validation above all.

To quote The Eric again:

So, on to the web service and Picle website.

Have you seen it? You have to register through the iPhone app and then you can log in. At the moment it's still very basic - we rushed to get it out the door in time for SXSW - but it's already starting to look pretty good.

The first thing to say is that we're making daily releases of new stuff to the web service - there's no app store submission process. But we still have an icebox or backlog of candidate features we might like to add. Obviously, some of these would synchronise with new directions in the evolution of the iPhone app.

The diagram below shows the core functionality we bundled into the initial release, and the features we've got on ice as backlog. The same point as above re: fixes and optimisation obviously applies (think error messages for example). And again, the darker circle has already been done but not yet deployed.

And finally, the *really* difficult bit

Let's be really honest - we're a small product innovation and service design company with clients. Our model is to help clients make their own product and services and we're not set up to launch and operate our own. We made Picle in our spare time and launched it for a bit of a laugh at SXSW, and because it felt like it was worth taking a punt. The question of whether agencies can make products, or should act more like start-ups, is a hot one precisely because no-one really knows how this might work: we are in uncharted territory and Picle is a leap in the dark.

Perhaps the most difficult challenge we face in the coming weeks and months is to maintain the momentum and commit the required attention and resource to make Picle as big a success as we believe that it can be. This will be tough.

But this is why we put something out there in time for SXSW.  Alex had a great idea that we wanted to validate, and the feedback is positive: there is something good about being able to create and share little story objects from moments that are captured on a mobile phone with a photo and soundclip.

Picle allows you to make things that are more like dreams than documentaries. For me, the app's power is to challenge the idea that video is always the answer.  I think @conordelahunty may well hurt me for saying this but Picle seems to leave a lot more space (dare I say hackable space?) for your imagination. It's closer to a comic strip than a film, and it's part of an ecosystem of storytelling and processing apps that - for example - power Instagram. 

We have been overwhelmed by the quality and usefulness of feedback we're getting from every direction. Please don't be shy in coming forward with your thoughts. 

-------

Alex Harding is an Interaction Designer  at Made by Many and the inventor of Picle. This is the story of Picle in Alex's own words - a story already blogged on this website, but told through a beautiful video that Alex and Paul Wyatt made last week.