In my previous post, I covered high-level aspects of ReactiveCocoa, the Objective-C framework that allows developers to write apps declaratively. Now I’d like to introduce some patterns in ReactiveCocoa, discuss a few best practices, and outline common gotchas to be on the lookout for. ReactiveCocoa can have a steep learning curve – let’s climb it together.

Splitting is similar to chaining in that it transforms signals into other signals, but different in that it reuses the intermediate signals. Splitting sounds complicated, but it’s as easy as using a signal more than once.

In this example, we’ve created a signal by chaining a few signals together, then stored it in an local variable named dateComponentsSignal. We then use that one signal to create two new signals and bind those individually to two text fields.

The last common pattern is combining. Combining is when you create a new signal from several signals. For example, if we wanted to create a signal to determine the enabled state of a submit button, we could combine the latest values from two text fields’ signals.

Here we’re binding the enabled state of our button to a signal created with combineLatest:reduce:. The second parameter is a block which is itself passed parameters that are the latest values from the signals being combined. Since we are combining two signals that send NSString values, the reduce block takes two NSString parameters. It’s this block’s job to reduce those two down to one value.

self.gestureRecognizerIsRunningSubject = [RACSubject subject];
self.gestureRecognizerValueSubject = [RACSubject subject];

RAC(self.someView.frame) = [self.gestureRecognizerValueSubject map:^id(NSValue *value) {
   CGPoint location = [value CGPointValue];

   CGFloat size = 100.0f;

   return [NSValue valueWithCGRect:CGRectMake(location.x - size/2.0f, location.y - size/2.0f, size, size)];
}];

-(void)gestureRecognizerReceivedTouch:(UIPanGestureRecognizer *)recognizer {
   if (recognizer.state == UIGestureRecognizerStateBegan) {
       [self.gestureRecognizerIsRunningSubject sendNext:@(YES)];
   }

   else if (recognizer.state == UIGestureRecognizerStateChanged) {
       [self.gestureRecognizerValueSubject sendNext:[NSValue valueWithCGPoint:[recognizer locationInView:self.view]]];
   }

   else if (recognizer.state == UIGestureRecognizerStateEnded) {
       [self.gestureRecognizerIsRunningSubject sendNext:@(NO)];
   }
}

[[self.gestureRecognizerIsRunningSubject filter:^BOOL(NSNumber *gestureRecognizerIsRunning) {
   return !(gestureRecognizerIsRunning.boolValue);
}] subscribeNext:^(id x) {
   [self.tableView flashScrollIndicators];
}];

RAC(self.label.text) = RACAble(self.someString);

RAC(self.label.text) = RACAbleWithStart(self.someString);

RAC(self.textField.text) = [[[[RACSignal interval:1] startWith:[NSDate date]] map:^id(NSDate *value) {
   NSDateComponents *dateComponents = [[NSCalendar currentCalendar] components:(NSMinuteCalendarUnit|NSSecondCalendarUnit) fromDate:value];

   return [NSString stringWithFormat:@"%d:%02d", dateComponents.minute, dateComponents.second];
}] deliverOn:[RACScheduler mainThreadScheduler]];

What happens when a developer, a project manager, and a designer are all put into a room together with Arduino software, a USB cable and a Grove kit? We found out, and called it Hack Day.

Prior to Hack Day, some of us had no idea what Arduino or a Grove kit even was at all – let alone how to manipulate it into some new invention or give it the ability to complete a task. That’s what Labs is for. The purpose of Labs is primarily to explore creative uses of technology and frame new possibilities for the agency, clients, and wider community. In short, they make epic shit.

While some of us look on with envy, Hack Day offers everyone a chance to think differently and create something, even if we have no idea what we’re doing. And it isn’t exclusive to just the technologically skilled. It’s about encouraging everyone in the company to dip their hands into this creative pot, work with developers, think in ways we aren’t used to thinking, and ultimately, improve the way we work together to make us better and smarter individuals, and as a company.

It took place back in March, a full nine-to-five of internal hardware hacking experimentation for all. What was intended to be a light introduction to physical prototyping and hardware hacking allowed us to open our minds and shift our thinking into a realm that we don’t typically get to play around in. And the best part is, there were no rules, no brief, and no client. We had complete creative freedom. We took lots of photos. And we got it all on video.

]]> http://www.teehanlax.com/blog/shifting-our-thinking-for-a-day/feed/ 0 http://www.teehanlax.com/blog/shifting-our-thinking-for-a-day/ http://feedproxy.google.com/~r/teehanlax/~3/ixg7ISYierg/ http://www.teehanlax.com/blog/reactivecocoa/#comments Wed, 17 Apr 2013 14:08:14 +0000 Ash Furrow http://www.teehanlax.com/?post_type=blog&p=9289

Note: This is going to be a slightly more technical post geared toward our friends in the iOS developer community.

Objective-C is a programming language which often finds itself mired in the antiquated ways of C, the programming language upon which modern Objective-C is built. While improvements in computing power have advanced the state of art in programming language design, Objective-C sometimes seems stuck in the past.

Objective-C and C are imperative programming languages where software developers provide statements that the computer executes in sequence. Behaviour emerges from executing these instructions. If a developer has written the correct instructions in the correct order, then the behaviour that emerges should satisfy the requirements of the program.

However, the instructions often have flaws. We use manual and automated testing to mitigate the risk of these flaws, but it would be better if we could abstract away the individual instructions and focus solely on the desired behaviour. That’s where declarative programming comes in.

The imperative paradigm forces developers to write how a program will solve some task. The declarative paradigm frees developers to describe what the task is.

ReactiveCocoa is an approach to making Objective-C less imperative and more declarative. It abstracts much of the how and focuses on the what.

Let’s take a look at a few examples to see what a declarative program in Objective-C might look like.

At the core of ReactiveCocoa is a signal. A signal represents a stream of events that occur over time. Subscribing to a signal allows developers to access those events. Let’s take a look at a basic example.

A text field in an iOS app can provide a signal which produces events when its text changes. ReactiveCocoa provides a category on UITextField with the function rac_textSignal, which we can subscribe to.

Here, we’ve declared that when the text field’s text changes, its new value is logged. Whenever the text field’s signal emits an event, the block is executed and passed the updated value.

The nice thing about signals is that they can be composed. Let’s filter the signal returned by rac_textSignal to make sure that the length of the string is at least three characters before we log it.

The filter: returns a new signal. When the first signal emits an event, the value of that event is passed to the filter block. If the block returns YES, then the new signal emits an event. The subscription is to the signal returned by filter:.

Let’s do something more complex. Let’s combine two signals from two different text fields and reduce their values into a boolean which we then bind to the enabled property of a button.

The enabled property of the button is always derived from the latest signal values from the two text fields. This represents one of the core components of FRP: deriving state.

In each of these cases, we make declarations once in viewDidLoad and the statements stay true for the duration of the application runtime. There are no delegate methods to implement or state to store. Behaviour is explicitly declared instead of implicitly inferred.

FRP can get much more complex, and learning the nuts-and-bolts of ReactiveCocoa takes time. However, this time is an investment that will yield more stable programs with predictable, well-defined behaviour.

We’ve seen throughout computing history that software development tends toward higher levels of abstraction. We no longer, for instance, deal with punchcards or assemblers. I believe that FRP represents another level of abstraction which programmers should leverage to build better applications, faster.

Based on our experience creating great iOS apps, we’ve come up with a list of 5 things we believe designers should keep in mind while conceptualizing interfaces for iOS. While the focus of this article is only on iOS apps, much of the advice here translates directly to other mobile platforms.

1. Understand Your Medium

This seems obvious, but designing apps instead of websites actually represents a huge shift in mindsets. Apps aren’t websites and shouldn’t be designed like them, either. Let’s talk about specifics.

Apps have a completely different user interaction model from websites: taps vs. clicks, views vs. pages, buttons vs. links, etc. We believe a change in language when discussing app design helps us keep the right frame of mind.

In addition to a different interaction model, apps should have different modalities. Don’t overload the user with too much in one view; separate different functionality into different views. This is even more important on the iPhone than on the iPad, since screen space is even more constrained.

How users get around in apps vs. on websites is another area of contrast to consider. Navigation hierarchies in apps tend to be narrower and deeper than on the web. Users are used to having to tap several times in order to achieve some goal or to access some content; don’t try and prevent this natural drilling-down behaviour by putting too much on the screen at once.

Navigation is very different on iOS – there is no browser chrome or Back button. Since iOS launched, many navigation conventions have emerged; which one is right for your app depends on your specific needs. Check out Pttrns for a great collection of approaches that apps have taken in regards to navigation.

Finally, remember that iOS apps run on iOS devices. Duh, right? But it’s an important point. Rendering semitransparent content with rounded corners and a drop shadow over top of a image overlaid with an animated gradient is probably going to cause a performance problem. Work with a developer to figure out a way to implement tricky designs without causing user-noticeable lagging in the interface.

Wikipedia has a comprehensive breakdown of all iOS devices, but we thought we’d distill that down to a short list of devices running iOS 6. We’re hoping this will help you make informed decisions about your app’s design and how it can degrade gracefully on less capable hardware.

2. Design Universally

We believe that the best applications are those that work universally. That means they work on Retina screens and non-Retina screens; they work on tall screens and short screens; they work on iPads and iPhones and iPod touches; most importantly, they work well in all these contexts.

This is hard, but we’ve got a few quick tips to get you 80% of the way there.

Avoid odd-sized Retina graphics

Non-Retina assets must have exactly half the size of their Retina counterparts. That means that a non-Retina asset corresponding to a 101 pixel Retina asset would have a dimension of 50.5 pixels, which is impossible. Save yourself and your developer some headaches and always use round dimensions for Retina assets.

Make Tap Targets Big Enough

Remember how users aren’t using your app in a web browser? Well, they also aren’t using a mouse. Instead, all interactions with your app are made with a far less precise instrument: a finger.

In order to make sure that users can easily interact with your app’s interface, make sure that anything they can tap is at least 44 points wide and tall.

3. Design on a Device

iOS devices have a range of pixel densities and vary in their reproduction of colour. When designing iOS apps, you should take that into account.

In order to get an accurate idea of what your app will look like, you need to render it on a range of devices: Retina and non-Retina, tall and short, iPad and iPhone. Use LiveView or Skala to mirror your photoshop files on your device. Lastly, don’t forget to vary the screen brightness to make sure your app looks good in all circumstances.

4. Animate your Interface

Animations are easy on iOS – Apple has gone to a lot of trouble so apps can easily be supplemented with cool animated transitions. It would be a shame not to take full advantage of this opportunity.

Unfortunately, animations are not easily conveyed through PSDs. The best idea for designing awesome animations is to work with a developer to prototype them on an actual device. Together, you can make throwaway apps that explore your idea for an animation. This will let you get a precise feel for exactly how your animations behave.

When designing animations, take advantage of what the user is already familiar with. Users expect that when they tap on an item to see more details, the new view should “push” in from the right; they also expect views for creating new content to slide up from the bottom. Mimic those motions in your own custom animations and don’t associate new actions with the existing animations. You should lean on what the user is familiar with to give them a better sense of familiarity and trust with your app.

5. Involve Developers Early

We believe that the best apps are made when developers are involved early in the design process, and when designers stay involved late in the development process. Collaboration between designers and developers will lead to some great work.

Implementing any reasonably complex design will have implementation challenges – the sooner developers can start thinking about solving those problems, the better the solutions will be.

We developers have ideas about interfaces that we’re not necessarily able to polish into an actual design. We also know iOS like the back of our hands, so we can point out elements of designs that don’t fit well within iOS. When designers and developers work together, awesomeness happens.

So there you go. Apps aren’t websites. Design universally. Design on a device. Animations are awesome. Involve developers early. These points will get you most of the way there – the rest is up to you.

I had to go back and look to be sure, but this is now the 7th iteration of teehanlax.com. It’s by far the biggest departure we’ve taken and quite a bit different from a traditional design agency site.

It’s different for a reason

We don’t list out our services. You won’t find a portfolio section. When we talk about our work, it’s done as long-form story-telling. We call them Stories of Making. They’re quite long, but give them a chance because we didn’t write them to read like case studies. We don’t list cringe-worthy “results”—We talk about what we learned in the hopes you can learn something too. They’re open and honest. They reveal failures, not just successes.

Written for you, our peers

Most agency sites are written for clients or potential clients. It seems inevitable when you write for this audience, you end up looking and sounding like everyone else out there. We’ve decided to focus on a different audience, you, our peers. We’re good at speaking to you and with you. We know what you want because, well, you are us. So going forward everything we will be doing on teehanlax.com is designed for people who like making stuff, just like us.

Our peers are our clients

While this may seem counterintuitive to focus our site at other creative professionals, we think potential clients will understand who we are, what we do and how we work far better through this site, than any site we’ve put out before.

Over the past 2 years we’ve found that more and more of the people we partner with are our peers. Our peers are responsible for hiring companies like us, not just CMOs and IT departments.

We have a ton more to share about the new site, but it’ll be far better experienced in a forthcoming making of story than it will be in this blog post. In addition to new stories we’ll be posting up new tools that help you do your job. We also have some old sections (like this blog) that will be getting an overhaul.

We hope you like it.

I’m very pleased to formally announce two new additions to our crew today. The first is Ash Furrow, an outstanding iOS developer. Also joining us (again) is Kate Bowen, who did a good stint here a couple years back.

Seeing as Kate is a copywriter, I asked her to write a little something about Ash and herself to put here on our blog:

– – –

We are excited to welcome Ash Furrow, a new member to the Teehan+Lax family, and considerably more excited to welcome returning member, Kate Bowen.

Ash moved to Toronto from New Brunswick to work as an iOS developer and lead the iOS team at 500 Pixels for a year and a half, shipping their iPhone and iPad apps. After working closely with (but mostly just watching) the designers, Ash became more involved in design and photography. He also began a podcast on software design with two others… It was alright.

Kate grew up in our hometown of Toronto—we love that about her. She first joined Teehan+Lax back in 2007, where she called it a home for just shy of four years. These years are often referred to as the golden era of T+L. After flying the coop two years ago to explore working with different mediums like print and radio, many tears were shed (by us). Kate pretty much helped us to grow into the company we are today, so it’s nice to have her back.

Ash co-authored a book on Objective-C development (whatever that is) and has just finished another on collection views, a new technology in iOS. Kate single-authored enough short-stories to make up a beautiful, emotionally moving and intricate book that someone will probably adapt into a screenplay one day.

– – –

We’re looking forward to great things from them–even Kate.
;)

Getting to this goal required a change to our workflow. The traditional approach of separating tasks by disciplines into progressive phases would not work for this type of project; we had to adopt a more agile approach.

Traditional vs. Agile

In a traditional workflow, tasks are based on disciplines and are scheduled one after another. First the analysis and planning is completed, followed by design, development and QA. The finished product is then presented and delivered to the client. Although there are rounds of feedback, revisions and collaboration within this workflow, for the most part each discipline is tackled separately until completion before the next task can start. Progress is measured by which activity has been completed.

In an agile workflow, instead of planning around one complete deliverable, this process breaks down the requirements into key features. Workflow is managed by the priority of features, which are iterated and built on rather than creating one final product. Each iteration is shared with the client to review. Progress is measured by how many features have been completed. Tasks may still be separated by disciplines but can be worked on concurrently.

Technology used

There are many, many tools to choose from but after some research and testing, we settled on angular.js, a JavaScript MVC, to create a dynamic web application. We also used Twitter Bootstrap and LESS for fast prototyping and more efficient CSS as well as Git for version control.

Lessons Learned

Wins

• Being able to use dynamic content makes it easier to identify functionality issues and see how the designs work in context.
• Different activities can run concurrently, tasks can overlap. There still needs to be some lead time between tasks but not as much as required in the traditional flow.
• Code is not used to fake the functionality of features just to be tossed out and replaced in production. Instead, the code is written to be production ready and can be delivered and used as-is.
• If cost or time becomes an issue, thoughful decisions can be made about which features can be left out.
• If there are changes to the project timeline, the prototype may not have all of the planned features but will still be functional.

All of these things let us make decisions by actually using the product. Usage is oxygen for product design.

Challenges

• Getting used to tearing down code and designs, rebuilding and redesigning over and over again is a hard adjustment. You have to learn how to be flexible and expect the inevitable.
• Deciding where to draw the line between creating a pixel perfect prototype versus a functional prototype when time becomes a factor can be tough and often happens on a case by case basis.
• The project team and client have to have the resources to create and maintain the technology used.

Managing many concurrent activities and making informed tradeoffs takes a lot of executional discipline.

As with any process, tool or technology, one solution may not work for all situations. There needs to be some experimentation to find the right fit. Despite some of the challenges using a different approach, the project was a success because the final deliverable had more value than what would have been accomplished using the traditional approach.

We’re excited to continue in this direction because we strongly believe it will help us get better at making digital products and services that people love and want to use.

Reference: http://www.agile-process.org/

It’s called Veta La Palma, an aquaculture farm located in Spain. Wikipedia tells me that it produces 1,200 tons of sea bass, bream, red mullet and shrimp each year. Unlike most of the world’s fish farms, it does so not by interfering with nature, but by supporting it.

When Barber asked Miguel Medialdea, the lead biologist at Veta La Palma, how he measured success, he pointed to thousands of pink flamingoes blanketing the water and said, “That’s success. Look at their bellies, they’re feasting!” He explains that the flamingoes travel 150 miles every day to feed on his fish “because the food’s better.” His fish farm is also one of the largest and most important private bird sanctuaries in Europe.

Barber asked him, “Isn’t a thriving bird population the last thing you want on a fish farm?” He explains that the flamingoes, by eating mostly shrimp, create an abundance of nutritious algae left for his prized fish. “We farm extensively, not intensively,” says Medialdea.

Barber describes Veta La Palma as:

1. A farm that doesn’t feed its animals.
2. A farm that measures its success by the health of its predators.
3. A farm that’s literally a water purification plant.

As interested as I am in sustainable aquaculture, I find the model compelling as a blueprint for healthy ecosystems of all kinds. Imagine digital environments that could be described that way: places that require little maintenance, that provide value to everyone (not just the ‘farmer’) and contribute to improving the overall health of the wider digital environment.

It seems like everyone is talking about the importance of ecosystems these days, especially in the context of ‘brand ecosystems’. And although I think this is an interesting topic, I am using the ecological metaphor to talk about something a little different.

The Problem: Digital Landfill

Many award-winning digital campaigns are really very empty experiences. You are led along an arduous (though often very pretty) path for a “chance to win” something great. Which is fine – it is what it is – but I don’t think these represent excellence in digital experiences; marketing or otherwise.

Two well-received campaigns that spring to mind are Volkswagen’s “Hitchhike with a Like” and the Shoppers Drug Mart “Spin to Win” contest. Both are brands that I really like, but after going through the motions of their game mechanics (spinning wheels, clicking to ‘hitch’ a ride), I left both experiences feeling a bit used. I didn’t get anything out of them except for that chance to win and the likelihood of winning anything is slim. Both of them present themselves as games, so even if I don’t win, I should be having fun, right? Instead, I left both experiences with a tangible film of regret, my life energy being converted into a “time spent” stat for someone’s impending measurement exercise.

What is the goal of these programs? That I spend half an hour on their Facebook promotion? I know it’s a game, but it’s slow and unfulfilling. It’s pretty, but I expect more from my game experiences these days.

And what happens to these sites when the quarter is over? Some will be recycled but most will drift off toward the garbage heap. Which makes sense because they weren’t built to last.

Made by Many coined the concept of ‘landfill marketing’ or ‘digital landfill’, which is a great way to describe disposable digital marketing efforts. They don’t provide much value to anyone and are a threat to the health of our digital environment. Good digital experiences, on the other hand, are designed to be durable and to provide to long-lasting benefit to everyone involved.

An Alternative Model: Sustainable Digital Environments

How do we create digital experiences that are sustainable and that function in a way that benefits both customers and brands … and even our competition?

I was inspired by Big Spaceship’s case study on creating the Crayola website:

“Unlike many websites, the purpose of Crayola.com is not to keep visitors on the site for as long as possible. The site is a tool for driving product usage so we made it very simple for users to get inspired and start creating.”

Healthy digital environments should leave you feeling refreshed and energized or empowered in some way. But in order for them to do that, brands need to think of them as something that can exist long-term and have that sort of effect from the outset.

How do we do this? Using Barber’s description of the Veta La Palma as a guide, let’s look at digital experience through three lenses we can use to question our efforts. If we aren’t providing value to someone, somewhere, then maybe we should rethink our approach or our motivation.

1. Support natural behaviour (Don’t feed the animals.)
The first lens is probably the most straightforward. Healthy digital environments aren’t about carrots and sticks. When people are self-motivated to participate in something, they are fed by the environment in a more substantial way. They are not taken out of their natural state and asked to do something unnatural. People behave in a certain way already, so it’s important to support them in that rather than distract them from their goals. And let’s not mistake conditioned reflexes for engagement. Think Nike+.

A less obvious example comes from Yancey Strickler, one of the founders of Kickstarter. He talks about how the classic formats for Kickstarter videos have evolved since they launched. He says, “We never told people how to structure the rewards or how to make their videos or anything … there’s sort of a collective intelligence that emerged over time on how to do this thing.” Letting go of some of the control can yield interesting and ultimately more authentic results. If you can commit to supporting the experience, other things will sort themselves out organically.

2. Be generous (Measure success by the health of your predators.)
This quality points to the importance of what Tim O’Reilly refers to “creating more value than you capture”. How this manifests will depend on the goals of the brand. But if we agree that the best experiences are those that provide people with something they need or want, it would indicate some level of success if people want to use, share or outright steal what you’ve got on offer.

A good example of this is how ProPublica uses Creative Commons on their stories to encourage other publishers to distribute their articles. The terms of their license are laid out on a page titled: Steal Our Stories. The result is a substantially wider reach, which supports their mission to have an impact and spur reform.

3. Improve the world around you (Be a water-purification plant.)
The fact is, most of us don’t get to work on world-changing projects all of the time. But there is something inspirational about creating digital experiences for the people of Planet Earth that actually serve their needs. By holding ourselves to some of these standards, we can improve the cultural environment around digital making and marketing.

If you support the environment you rely on and don’t take more than you need, you can improve the lives of your customers (and neighbouring communities) in tangible, and often intangible, ways.

An admirable example is the MAKE phenomenon. It’s a magazine, it’s a festival, it’s a community. Sure, they sell things, but it’s so much more. They describe their audience as: “a growing culture and community that believes in bettering ourselves, our environment, our educational system—our entire world. This is much more than an audience, it’s a worldwide movement that Make is leading—we call it the Maker Movement.” Importantly, this movement is not an accident, it’s by design.

What’s In It for You?
Sustainable Relationships.

Understanding the real relationships that exist between your customers and your brand helps support the development of brand utility. Instead of force-fitting your brand’s product into customer’s lives, the sustainable ecosystem model helps us to ask: What is your brand really doing for its customers? Or, as Ingmar Delange asks in his presentation on brand utility, “What can we do for you?”

It is not possible to create and maintain healthy digital environments for customers without understanding what motivates and supports behaviour in context. A healthy digital ecosystem simultaneously provides sustenance and room to breathe – that is, meeting customer needs while also getting out of the way.

Thinking about digital experience design in this way helps us keep customers in focus – instead of trying to create faux experiences around marketing objectives, we can strengthen the mutually-beneficial relationships that exist in these ecosystems.

(This post originally appeared on Medium)

On December 20, 2012 the New York Times released Snow Fall, The Avalanche at Tunnel Creek, a 5 part story of skiers and snowboarders trapped by an avalanche in Washington State’s Cascade mountain range.

It is an amazing story reminiscent of Jon Krakauer’s, now famous 1996 Outside Magazine piece, Into Thin Air. As a piece of journalism, John Branch’s Snow Fall is an extraordinary piece of writing. It is a form of writing not often seen on the Web; long, well researched, impeccably edited, Pulitzer bound. But most of the conversation around the piece surrounds its layout and presentment.

In between the words are incredible motion graphics, videos and photos that bring life to the story. In fact, most people commenting on the story really only viewed it as a picture book. Due to its length and depth I had to carve out a solid hour to read it and haven’t viewed every element.

Snow Fall is everything that Craig Mod outlines in his article “Subcompact Publishing: Simple Tools and Systems For Digital Publishing” isn’t. Snowfall is Epic.

Craig outlines several characteristics of Subcompact Publishing, which arguably Snow Fall follows… it has clear navigation, HTMLish, Open Web etc. But Craig’s overall theme in Subcompact publishing is that it is lightweight, lesser than by design. Subcompact publishing is really something that should be easy to do.

In contrast, Snow Fall was not easy to do. It took 11 people 6 months to create. It is greater than in every way to Subcompact pieces (like this one). Snow Fall isn’t the first of these pieces. ESPN’s Doc Ellis story, The Verge and the work that Pitchfork are doing lately with their features are all coming from the same place.

Of course, these long intensive pieces are the stuff magazine journalism is based on. These publishers are just following in the footsteps of their predecessors.

Gay Talese, Frank Sinatra Has a Cold. (Esquire, April 1966)
Hunter S. Thompson, The Kentucky Derby is Decadent and Depraved. (Scanlan’s Monthly, June 1970)
Neal Stephenson, Mother Earth, Mother Board: Wiring the Planet. (Wired, December 1996)
David Foster Wallace, Consider the Lobster. (Gourmet Magazine, August 2004).

We stand on the shoulders of giants.

There seem to be 2 separate but related currents running in publishing right now, minimlaists and maximalists. Subcompact Publishing meet Epic Storytelling.

Epic Storytelling is a designed experience.

Epic Storytelling is about bringing significant resources to bear to tell a story. It requires specialists bringing their craft to it for it to happen.

Epic Storytelling is bespoke.

It is not (at least right now) system driven. As NY Times Design Director Andrew Kueneman: said in the Atlantic Wire

“This story was not produced in our normal CMS, which is probably pretty obvious.”

There are attempts to create publishing systems that can create Epic Stories systematically, (The Atavist) but these are in their infancy.

Epic Storytelling requires the reader to focus.

It is not lightweight for the creator or the reader. Epic Storytelling wants your attention in a way that is different than Subcompact. Both require focus but Subcompact enables focus by removing cruft, making reading easier. Epic Storytelling rewards those readers who give it focus.

Epic Storytelling is an art, not a science.

Buzzfeed and HuffPo turned writing into a science, the science of optimizing clicks and headline writing. A/B the piece into existence. Epic Storytelling creates a splendid artifact. One, that is what it is, not optimized for page views but optimized for experience.

Epic Storytelling is considered.

Given the resources required to make these pieces, they need to follow a considered process. One that is well suited for large editorial organizations. The exact qualities that impede them in the Subcompact world, help them in the Epic world.

I see these two worlds not as opposite ends of a spectrum but rather a Venn diagram overlapping. They share as many qualities as they don’t. I believe that they can co-exist in the world quite nicely. At times each will be envious of the other, for one’s strengths are often the other’s weakness.

Maybe the best publications are equally adept at both and that is where the future lies.

History

In September of 2008, one of our designers, Greg Washington, began discussing a frustration he had. When starting any design project he would assemble a collection of images. These images are the foundational design research he would do before opening Photoshop or sketching. Over years of projects he collected dozens of folders of loose images on his hard drive.

Most designers maintain private collections of visual inspiration and research to fuel their creative process. Their typical workflow involved going out on the Web and downloading images to a local folder. There these images would sit with a bunch of other badly named files like img4065.jpg and fre566ba01.tif. If highly motivated, designers might bring those images into another program like Illustrator, InDesign, Photoshop or Keynote to create a “moodboard”. These files—both the individual files and the moodboards—might get printed once, or thrown into the depths of a server only to be lost.

Greg was looking for an easier way to find, organize and store images that would serve as creative inspiration. He wanted to be able to easily share these images and see what other designers were using as inspiration. He wanted to be able to network those folders that he knew were sitting on everyone’s computers.

We loved the idea and decided to put some effort behind building a site that could do this. Through October, November and December of 2008 about 4 people worked on a site that we called Image Spark. It launched in January of 2009.

As of December 2012 Image Spark has over 1,152,487 images, 21,996 moodboards and 48,947 user accounts. It had 155,339 visits last month, 89,816 of which were unique. Those users generated some 968,057 page views.

In 2012, it had over 1.1 million unique visitors viewing almost 9 million pages.

So why are we considering shutting it down?

How 37Signals made us all believe

In 2008, when we were building Image Spark, we discussed, how we could commercialize it. We discussed different business models, including display advertising, premium features and membership. We thought we had an idea that could be commercially viable. But how would we know what to invest in it? Should we pull people off client work? Should we take some of the cash we had saved as a business and hire additional people?

We convinced ourselves that we would know very quickly whether it was successful or not. People would either love it or they wouldn’t. The “people” would tell us. Usage would give us evidence about whether to put more resources into it. In retrospect, this seems insanse. The “Field of Dreams” approach to product development… build it and they will come. Why did we believe 6 weeks after launch we would know whether to sacrifice part of our services business for Image Spark? Because 37Signals made us believe it was possible.

37Signals was the worst thing to happen to services businesses trying to make products. They fucked it up for all of us, because they made it. For those of us old enough to remember, 37Signals was a services company like Teehan+Lax. They had clients and did work for hire. Of course, 37signals isn’t a services company anymore. They make amazing digital products and their success is enviable.

What’s more enviable is how they made the transition from services to products. They seemingly did it with very little disruption. One day they had clients, the next day they were running Basecamp. Cash started rolling in.

The great lie, agencies tell themselves is that it can be done. You can make the transition. Look, 37Signals did it. So can we. Image Spark might have been our Basecamp. Several years later, a startup called Pinterest proved there was a business in image sharing. Why wasn’t that us?

Let me explain why, I think, 37Signals were able to do it and why we failed with Image Spark.

Clayton Christensen, the father of disruptive innovation, says, “you can’t start a disruptive business from inside an incumbent one.” The incumbent business will always take the resources from the disruptive one. He argues that if you want to create a disruptive business you need to isolate it from the incumbent business. The disruptive business needs its own values, processes and resources to be successful.

In our example, the incumbent business, Teehan+Lax, which gets its revenue from charging clients, was too powerful for Image Spark. As soon as Image Spark launched, the people who worked on it (the resources) went right back on to the work that paid the bills. In the spring, Greg (a driving force behind Image Spark) left for an opportunity on the west coast. Image Spark became the Christmas toy that sat neglected in the corner.

So how did 37Signals do it? Basecamp was a project management tool that 37Signals was using to manage their clients.

“We built Basecamp because we needed it. I’m a big believer in investing in what you know and what you need. We invested our time, energy, and focus into building a product that we knew we needed to run our own business. When you build what you know, and when you use what you build, you’ve got a head start on delivering a breakout product.” [source]

Basecamp got the resources (capital and human) it needed because it fueled the incumbent services business of 37Signals. It was able to take root because it wasn’t disruptive but highly complimentary.

This allowed them to mature a product and then realize, “hey others might like this”. This is why, I believe, 37Signals succeeded in their transition, and most agencies will fail.

Image Spark had some complimentary aspects but it wasn’t like its existence was crucial to Teehan+Lax’s services business. After we launched we got positive response from the design community, but not enough to gather the evidence we would need to invest heavily in it.

This is actually what happens with most products. They are rarely complete failures nor are they complete successes. They limp into the world on launch and then the real work starts. The real work of maturing and scaling.

Image Spark dies a horrible death and becomes a zombie

We did the worst thing you can do for a product: we left it alone. Over the past 3 years we’ve made only a few incremental updates to Image Spark, all on the backend. We moved it over to AWS from a dedicated server and then later re-engineered the database to improve performance.

There was never enough evidence that we should invest in it and so we just left it out there. It cost relatively little to keep open (about $2500 in server costs) and some people use it. But the product has become, what Joe Olsen at Phenomblue calls, “a ‘zombie idea’ not dead, yet not alive either.”

Image Spark is our zombie and now we need to decide whether to kill it.

In December, MongoHQ informed us that our database requirements have grown to such a size that we need to upgrade to a Large server. Our AWS bill, while not huge, is getting larger not smaller. Next year, we estimate Image Spark will cost us about $9,000.

We aren’t sure it’s worth it.

What do we do now?

We are faced with a decision about the future of Image Spark. It has become this zombie walking through our business. A small asset is growing into a increasing liability.

Stock investors use a simple model for making investment decisions… buy, sell or hold.

We adapted that model to make investment decisions in our business.

Improve – Invest the required resources to improve the product so that it is valuable to users.
Maintain – Do nothing more than is required to keep it alive
Kill – Shut’er down
Sell – Can someone else find value in what’s been built?

Right now, Image Spark is on the kill list. We aren’t interested in maintaining it, finding a buyer and negotiating a sale feels like a distraction. Improving it, means diverting resources from money making activities to Image Spark which in a post-Pinterest world seems foolish.

We’d be interested to know from you, what do you think we should we do with Image Spark?

Zombie Photo Credit: e_monk

UPDATE: If we decide to close Image Spark, we will provide an export function and time for people to get their images. We wouldn’t leave you hanging.