something in the way

Today, we note the availability on Android of Control, a WebKit-based touch interface also on iOS.

For visualists and interactive designers, it’s worth paying attention to one feature in particular: dynamic interface creation. Perhaps biased by the musicians who have tended to embrace them, touch interfaces have tended to rely on the static layouts favored by physical knobs and faders. That’s arguably the worst of both worlds: you lose the tactile feedback of physical controls, but you don’t add any of the flexibility of a display.

Control is an open-source application rendered in HTML5, powered by JavaScript and JSON, so it’s capable of anything you can imagine. But Charlie Roberts has already demonstrated how a dynamic interface could work. Using OSC, you can make control layouts on the fly. That could lead to more sophisticated software integration for visual and musical performance, new chances for collaboration and live rigs, and the ability to make an interface on someone’s device in an interactive situation.

We saw the last of these scenarios in the case of the iOS app mrmr, developed by Eric Redlinger. As proof of concept, I and others put together a gallery show using mrmr, at which interactive pieces were able to build interfaces on-the-fly on user’s iPhones and iPads. With Control, those horizons expand, no longer constrained to individual proprietary UI widgets on one platform (like iOS), but cross-platform, Web-based, and dynamic.

The video above I think does a good job of scratching the surface of what’s possible. More on that here:
Control 1.3: Dynamic Interfaces, jQuery integration & more

But dynamic layouts could go in many, many directions. Since this is especially relevant to visual performance, perhaps in modes of interaction not really possible in music, I’d love to hear what readers imagine. And do try Charlie’s app, whether on iOS, Android, or both:
Control

– and if you’re really ambitious, have a look at the source!

Already making the rounds on the Web (as well it must, if it is to accomplish its author’s aims), a YouTube video immortalizes roll of film found against all odds in a snow bank. Upright Citizens Brigade video producer Todd Bieber, who found the roll, has turned them into a charming narrative as he looks for the film’s owner.

It’s a reminder of the importance of physical artifact in a digital age. Film by necessity has clear physical form in a single object; digital media has to exist physically somewhere, encoded in storage media, but it hardly has the same sense of definition.

I wish I had something intelligent to say, but I can only smile, especially as lately I’ve been rediscovering film myself. (If only motion/movie film were as easy to work with as still.)

But the question remains compelling: how do you bring physical objects into digital work? Should you? Do you turn to media like film, or do you find a way to make your digital work physical? (Prints, handmade wooden flash drives… even the beam of light that projects your work onto a wall, all can take on new meaning.)

Via NPR: Lost Photos Of NYC Blizzard: Found! [the picture show]

‘UX Professional’ is a bullshit job title. It’s just a way to over-charge naive clients. All web designers should be UX prosless than a minute ago via

Ryan Carson
ryancarson

A web site or web app should not be the result of a production line of people.

A web site or app should be the product of a Web Designer and a Web Developer (who occasionally are the same person, as demonstrated by Shaun Inman). Anyone else who is added into this equation is a waste of money and time.

[Update] A lot of folks in the comments and around the web are attacking the above sentence, so let me clarify. At its core a website should be the product of a web designer and a developer. Obviously on larger projects you will need to add various people because the workload would be two much for just two people. However, these people are added for logistical reasons, not strategic. I still strongly believe that if the lead web designer on a project needs someone who specializes in UX because they don’t have a good understanding of solid UX principles, then they shouldn’t call themselves a web designer. Web Design and UX are not two separate disciplines, and UX is not something you add to a project because you have a large budget. [END UPDATE]

I’ve worked in the web industry for 10 years at three different web design agencies and now run my own company who produces websites and apps.

Wikipedia defines User Experience Design as ..

A subset of the field of experience design that pertains to the creation of the architecture and interaction models that impact user experience of a device or system.

I define it as

Advanced knowledge of …

1. HTML (including HTML5)
2. CSS (including CSS3)
3. Responsive Design principles
4. Accessibility
5. Usability
6. User testing

A basic knowledge of …

1. Copy writing
2. JavaScript
3. Marketing
4. A/B and multivariate testing

You cannot be a ‘UX Professional’ if you are not an experienced Web Designer and involved in the day-to-day process of designing, building, testing, marketing and updating a web project.

Editorial

Misdirection is an art practiced by magicians by which an audience’s attention is diverted from one place to another. What’s brilliant about it is that it’s not a lie. Indeed, the audience has to participate for it to work. We, the audience, watch the right hand instead of the left, because what the right hand is doing seems more interesting. The left hand is still there, in plain sight; if anyone bothered to look, they’d see the trick.

After months of obsessive campaigning, Apple scored the final blow with Jobs’ “Thoughts on Flash”. The firm has reduced important debates over open development, censorship on devices, and the future of Web standards into a simplistic dunking booth contest with Flash as the target. Adobe’s CEO called the debate a smokescreen. Adobe has their own biases; they want to direct attention away from the possibility that their flagship product stands to lose market share in the shakeup over the future of the Web. But that’s Adobe and Apple. What matters more is that the rest of the technological sphere has gotten dragged into a pro-Flash, anti-Flash debate. Watching that devolve over the course of yesterday was painful, and it’s time to say something.

It’s a false debate, because it’s clear that Flash’s role in the future isn’t exactly what it was in the past. Flash has traditionally done two things: it’s been a common-denominator solution for video, and a cross-platform development framework for interactivity, animation, gaming, and other “rich” application experiences. It’s recently done those two things in the absence of any solid alternative. In the browser, the bottom line is that open Web standards are finally able to accomplish many if not most of those goals, not only for video but for interactive animation and drawing. That doesn’t mean the end of Flash development: Flash is used for everything from rich client apps outside the browser to animated television on the Cartoon Network. But it does mean a different landscape.

Focusing entirely on that issue, however – as Apple apparently dearly hopes you will do – misses other, more fundamental issues.

The irony here is, I agree with most of what Jobs said — about Flash. (I expect a lot of you are with me.) But this isn’t just about Flash. It’s not just about the iPhone and the iPad (least of which once you start using “the future of the Web” as the catchphrase.) And it’s what Jobs and Apple aren’t saying that bothers me most. Whether the misdirection is intentional or not, whether Jobs’ thoughts are heartfelt (I believe they are), that doesn’t matter. There’s a danger here of losing the plot by allowing Apple to control the whole debate.

There are serious concerns about whether Apple’s path, limiting the tools developers use and what applications can say, is the right course for digital expression. And there are real concerns about the future of video standards, and whether those will give the Internet the freedom with video that it’s had with text, images, and sound. Each of those issues is far deeper than whether or not Flash sucks.

Talking about Flash, but slamming all cross-platform development

Scoring points against Flash and its issues with reliability and performance is an easy matter. But Apple isn’t just suggesting Flash is a poor alternative. They’re blocking development with other tools, restricting developers from using other tools on their single-vendor store. Apple knows better, developers, what you should do. And Jobs goes further, to argue all cross-platform development libraries, in effect, are bad:

We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

This becomes even worse if the third party is supplying a cross platform development tool.

What does that mean, exactly? When is a “layer” of software “between the platform and the developer”? Jobs’ “Thoughts” still don’t offer an explanation of an issue that has confused and troubled even some of Apple’s most loyal developers. The nearest translation I can work out is that Apple doesn’t like anyone using tools other than their own.

It’s a big deal, too. Complaining about such tools is one thing. But Apple has promised – and delivered on that promise – to weed out even high-quality apps just for the sin of using such tools.

In case there’s any doubt about how sweeping this generalization on cross-platform tools, and how divergent Jobs’ thinking is from actual developer realities, read on:

Adobe has been painfully slow to adopt enhancements to Apple’s platforms. For example, although Mac OS X has been shipping for almost 10 years now, Adobe just adopted it fully (Cocoa) two weeks ago when they shipped CS5. Adobe was the last major third party developer to fully adopt Mac OS X.

The problem is, even Apple themselves don’t necessarily live up to the same standard. It took Snow Leopard for Apple to fully “adopt” Cocoa technology in the OS, and Apple’s pro apps have only just become fully Cocoa-based and 64-bit. Aside from illustrating that Jobs is sometimes unencumbered by reality in his arguments, this raises questions about the underlying thesis, that supporting cross-platform development means that you support a lowest common denominator and nothing else.

Incidentally, while its developers have assured me they’re safe, the logic itself flies in the face of even simple tools for artists like OpenFrameworks, which because of how it’s architected as a cross-platform development tool that could target the iPhone alongside a Linux desktop, or any number of other combinations. That’s just the sort of compatibility and portability I would think you’d want for creative expression and development, but the gist of Jobs’ entire rant in “Thoughts on Flash” is the opposite: proprietary, platform-specific development is always better. Apple wants apps on their platform, and not elsewhere. I can’t blame Apple, but I do have to question whether the rest of us need to accept the logic. Jobs is really clear on this point:

Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform.

Of course, “everyone” wins only if they spend their cash at the Apple ecosystem. And there are casualties: while Apple makes a great case against Flash, they have less of a case against tools like the Scratch viewer, a teaching tool that allows kids to develop on desktops using kid-friendly programming schools and run their creations on the device.

Now, if this only applied to tools, it wouldn’t be so bad. Unfortunately, a topic Jobs doesn’t mention at all is why Apple is blocking certain ideas from its store, too.

Talking about Flash, but not talking about censorship

Can you say “slippery slope”? Apple’s “Thoughts on Flash” do nothing to explain how the single-vendor control of the iTunes store has apparently made Apple feel responsible for anything delivered on their device. Yes, it’s true, game systems suffer from the same (often worse) restrictions, though I’m not arguing that’s a good idea, either. The issue is drawn into sharp relief because of the number of apps and number of developers on Apple’s mobile platforms – more so as it appears this could be the future of development. (It’s telling to me that Apple is awarding only iPhone and iPad developers its coveted Apple Design Awards this year at the WWDC developer conference.)

Apple already eroded free speech on their platform by blocking pictures of people in bikinis and other PG-rated, suggestive content. As with any censorship, what makes this a dangerously slippery slope is that it mandates double standards. One bikini app is blocked, while another (Sports Illustrated) is fine. [PC World]

Banning bikinis seems overly Puritanical enough. But we were reminded that free speech is at issue this month with the case of Pulitzer Prize-winning political cartoonist Mark Fiore. The very definition of a “slippery slope” is this: once you begin blocking some things, what’s to stop you from seriously impeding free communication. The fact that the browser remains open to any content you like, including hard-core (or potentially even illegal) porn, only illustrates how pointless this whole exercise is.

If application development is important, and not just what’s in the browser, then free expression in applications ought to be important. And as for the one argument Jobs has made on the subject, that “if you want porn, buy an Android,” here’s an experiment for you. Try searching for “porn” or “naked” on the Android Market. I did, to see if in fact Jobs was right and my Droid had become a smutty wasteland. You’ll find almost nothing there. What is there has, most often, one or two stars and a lot of negative reviews. In other words, democracy wins.

So, Jobs didn’t address the fundamental issues of how development works on his company’s devices. But he did score some points against Flash in the “open” battle over the Web and video, right?

The problem is, he didn’t really address the ongoing concerns about H.264, and the reason everyone hasn’t already adopted the video tag with that codec as a standard.

Talking about Flash, but not talking about H.264’s patent problems or real open standards

Web tags aren’t really open unless there’s a standard underneath for them to serve. Early standards advocates learned this the hard way with GIF, the Graphics Interchange Format. The story goes like this: for years, GIF was adopted as a graphics encoding standard online. Sure, it was patent-encumbered and could potentially result in massive license fees – but it was free at the moment, so why should anyone worry? (Is this sounding familiar yet?) In the late 80s and early 90s, GIF was a free ride, so no one bothered to adopt an open alternative. Then, just as GIF began to peak in popularity, the folks who owned the patented technology, UNISYS, decided to change the rules. It was their right to do that, because they still owned the patent.

Ironically, GIF’s patent was far less dangerous than the patent that covers H.264, because it applied only to the LZW compression algorithm used in writing the files, not decoding them. That meant only the GIF creation tools were really at risk, from 1994 when the additional fees were announced to 2004 when the patent expired. (If you want to brush up, there’s a 2004 reprint of a 1995 story on the topic.

First, it’s important to understand that MPEG LA, the body that licenses H.264/AVC (among other things), represents not one patent owner but a pool of patent owners. Those owners set the license fees and terms. That makes licensing patented technologies easier, but as far as making H.264 the new video standard for the Web, the whole situation is more complex, not less – because any member of that pool could decide to cause trouble before the patents expire, in roughly 2025.

But I digress. There’s a bottom-line question here.

Is it possible browsers, streamers/broadcasters, and users might incur license fees for using H.264? If they did, it could threaten the freedom of video on the Web in generally, which depends on a level playing field for publishers and viewers. It could also be devastating to free and open source video production tools: not only would those tools violate the patents, but it’s possible users of those tools could be liable for fees.

The answer is relatively clear, but only through New Years’ Eve at the end of 2015. From Betanews:

As part of its response late yesterday, MPEG LA delivered a statement to multiple sources, including Betanews, announcing that the rights management firm will extend the period for which it will refrain from collecting royalties for use of H.264 in free streaming video, until the last day of 2015. The term of that royalty-free agreement was due to expire at the end of this year.
“Products and services other than Internet Broadcast AVC Video,” reads MPEG LA’s statement to Betanews, “continue to be royalty-bearing, and royalties to apply during the next term will be announced before the end of 2010.” Internet Broadcast AVC Video is the name of the patent portfolio to which H.264 belongs, when used in the context of streaming.

H.264 licensing body won’t charge royalties for HTML5, other Web streams [Betanews, February 2, 2010]

That’s an incomplete answer, though. We still haven’t seen the 2016-2025 terms, and just as importantly, the MPEG LA is very clear that users could be liable for the use of the codec. From the same article:

But in a direct, personal response to the LWN.net reader that was shared with other members, MPEG LA global licensing director Allen Harkness explained that the fact it doesn’t charge end users (viewers) royalties for downloading H.264 streams, doesn’t mean they should not be licensed to do so. Effectively, someone has to be licensed to produce the videos, and that license does incur a fee. But that license is then effectively passed downstream to the end user.
“While our Licenses are not concluded by End Users, anyone in the product chain has liability if an end product is unlicensed,” wrote Harkness. “Therefore, a royalty paid for an end product by the end product supplier would render the product licensed in the hands of the End User, but where a royalty has not been paid, such a product remains unlicensed and any downstream users/distributors would have liability. Therefore, we suggest that all End Users deal with products only from licensed suppliers.”

By the way, before you get your conspiracy theorist hats on, one of the companies that could wind up paying steep fees is Apple. Apple is just one member in the MPEG LA pool, and its liability (the number of patents for which it would have to pay) could well be greater than its equity (the patents Apple themselves own, which are far fewer in number and smaller in importance). It’s more likely that Apple’s support for H.264 is motivated by practicality, not some desire to cash in on H.264 patents. They’re already paying to be a licensee, and they’re aware of the legal ramifications of using H.264. It’s “the devil you know,” in other words.

Is there an alternative to H.264?

There are many things to like (or even love) about H.264 as a codec, but it’s a stretch to argue that H.264 is the best codec for all Web video.

On this, we can ask Adobe and get a more fair and balanced answer. Adobe added H.264 support in Flash Player 9 and Adobe AIR. If it was the solution to everything, you’d expect it would have been the solution in Flash. So why wasn’t it? David Hassoun of RealEyes Media explained in a Flash 9 tutorial on the Adobe Developer Connection:

So does this new Flash Player support for MPEG-4 and H.264 mean that it will replace the On2 VP6 codec? Absolutely not. The addition of H.264 gives developers greater choice to select the technology that best meets their needs. The current implementation of H.264 does have some limitations, such as lack of support for alpha channel and the inability to embed video into a SWF file. On2 VP6 is a solid, high-quality choice for Flash-based video projects. The On2 VP6 codec is also clear of any licensing issues that may arise with MPEG-LA. (Licensing information can be found on the MPEG LA and Via Licensing sites.) The On2 VP6 codec will remain a consistent and viable option for media delivery—see the On2 VP6 technology white paper (PDF, 140K) for more information. The added support for H.264 simply means that there are now more options and wider spread compatibility for high quality and HD video.

Apologies for my geeky Empire Strikes Back metaphor, but here’s where we’re at: OGG Theora is blasting into space, headed for a losing battle with Darth Vader. “That boy is our last hope,” says the open video movement. “No,” says Yoda, or, erm… maybe Google. Or me. Or Frank Oz. Or something. “There is another.”

If Google were to open up the video codecs it got from On2, the whole debate could change, as I wrote last week. On2’s video codecs may actually, ironically, be better suited to the job than H.264, for some of the reasons above. But most importantly, it would mean that On2 video could become a format that’d satisfy the major browsers and open and proprietary video production tools alike, without everyone risking incurring lots of fees. (One variable to explore would be this codec’s performance on mobile, though I know various parties have considered On2’s stuff as a mechanism for targeting mobile devices.)

But let me be clear: this is not just me wishing I’d gotten a job with ZDNet or going off on some personal vendetta. There are major reasons for the visualist community to care. Both this site and its sister site have long been about online freedom of expression, and about the democratic power of our connected world and its open standards. If we’re going to have the freedom to edit, produce, distribute, and consume video, having proprietary “taxes” along the way is a very bad thing. And this debate isn’t over yet. It also has far, far less to do with Flash than a lot of people currently seem to think.

Right now, though, the news isn’t good. The biggest news this week was largely ignored:

The other shoe: Microsoft and H.264

I’m not optimistic. If I had to bet right now, I’d bet on a patent-encumbered future for video. When I spoke to parties from organizations like the Mozilla Foundation at the Open Video Conference, their biggest concern was time. While the world has focused on Apple and the iPad, the simple truth of the matter is that everyone in the tech world has reached a consensus that the time for video directly in the browser, as part of HTML5, is now. So what everyone has been waiting for is support from the world’s leading desktop OS vendor and #1 browser maker: Microsoft.

I think the battle is over. Dean Hachamovitch, General Manager, Internet Explorer says that Microsoft has chosen H.264:

H.264 is an industry standard, with broad and strong hardware support. Because of this standardization, you can easily take what you record on a typical consumer video camera, put it on the web, and have it play in a web browser on any operating system or device with H.264 support (e.g. a PC with Windows 7). Recently, we publicly showed IE9 playing H.264-encoded video from YouTube. You can read about the benefits of hardware acceleration here, or see an example of the benefits at the 26:35 mark here. For all these reasons, we’re focusing our HTML5 video support on H.264.

So why isn’t Microsoft concerned about the litany of potential license issues above? That’s easy: Microsoft doesn’t need open standards. You’ll need to pay for that license somehow. So why not get locked into their proprietary operating system in the process?

Other codecs often come up in these discussions. The distinction between the availability of source code and the ownership of the intellectual property in that available source code is critical. Today, intellectual property rights for H.264 are broadly available through a well-defined program managed by MPEG LA. The rights to other codecs are often less clear, as has been described in the press. Of course, developers can rely on the H.264 codec and hardware acceleration support of the underlying operating system, like Windows 7, without paying any additional royalty.

In fact, Microsoft is better off if alternative operating systems like Linux and Android incur license fees. It means those operating systems are just a little less free, which erases some of their advantage over Windows.

Is there any hope at all? As near as I can figure, Google is now the only company with the leverage to navigate us out of this mess, thanks to the enormous popularity of YouTube and the growing popularity of Android and the Chrome Browser, plus the fact that Chrome OS is on the horizon. Time is running out, but if (this is a huge if) Google were to open up an On2 codec, then adopt it across YouTube and its mobile and browser lines, then nail implementation so well that it convinced others (particularly Microsoft) to follow. The other likelihood is that even the likes of Microsoft may privately adopt a “wait and see” approach with those MPEG LA terms. If later this year, MPEG LA either plans to hike its rates in 2016, or it doesn’t cover terms all the way to 2025, it might raise the appeal of an alternative like Google’s.

Alternatively, we can hope that the MPEG LA decide to be generous and extend free terms through 2025. If that happened, then even this patent-encumbered video format could become a major tool in the open Web. We’d effectively get the dreamworld Apple has been hinting at: an open video tag with a free video format that looks great and has wide hardware and software support. So the “happy ending”
doesn’t have to exclude H.264.

Mozilla is, in the meantime, in a tough position. Having promised not to support H.264, we could wind up in the weird situation of having to use Flash in Firefox while Chrome, Safari, and Internet Explorer all use HTML5 and H.264. It seems that could change, though, depending on how things play out. The fact that Mozilla has taken the hard line ought to suggest that there is at least some cause for concern.

Phew. There’s absolutely no way to cover this issue in a small number of words. Well, or you could gloss over the issues and pretend they don’t exist, if you’re a tech CEO.

There are other issues left out of Jobs’ “thoughts,” though.

What we can do: think different

Don’t get me wrong. As I said, Jobs’ “Thoughts on Flash” likely mirror a lot of our own. What I’m saying is that we don’t have to limit our thoughts to that debate.

Cross-platform development, freedom of speech in software, video codecs, patents, intellectual-property, Web standards: these are all complex issues. They merit more than simply scoring quick political points against one platform or another. (And yes, that includes even being too quick to dismiss Apple’s platforms and what they do right.)

This isn’t just about the iPad or the iPhone. It isn’t just about Apple. It’s about which debates we have, who frames them, and how we address them.

The point is, what we all see in our Web browsers could depend on the these issues. What the tech community thinks and decides about how development should work, about which freedoms are important for developers and which aren’t, all depend on these issues.

Mesmerizing magic tricks are a good time. But in this case, the responsibility falls on us – not Apple, on us. Fool me once…

wee see – collection one from Rolyn Barthelman on Vimeo.

When working with drawing code – or perhaps even computer media in general – starting out with simple shapes can feel oddly uncomfortable. Perhaps as adults, we’re accustomed to dressing up our work and our identities. Using something as basic as a regular triangle can feel naked and dry.

As kids, we don’t think this way. We love bright colors and simple shapes, maybe because we’re seeing everything for the first time. And maybe it’s simply that we have more imagination. (How many young kids have you seen in utter states of bliss with empty boxes and wrapping paper?) Of course, imagination and playfulness is just the state a lot of us want out of our art.

That’s why it’s so encouraging to me to see the work of Rolyn Barthelman and Wee See. This is serious play: if you really master form, pattern, and motion, you can make beautiful work using nothing but elemental shapes. And it’s also playfully serious: it’s crisp, it’s minimal, but it also feels like playing around with blocks. And, okay, sure, mostly during the brilliant animations in Sesame Street as a kid I was waiting for the Muppets to reappear. Maybe I’d even appreciate that more now.

Not surprisingly, Wee See’s current favorite toy is Colorforms, the stick-on vinyl shapes. Check out their ode to the glory of Colorforms. (This actually makes me want to make my own Colorforms geometries – perhaps get a library in Processing that can also be transferred to physical objects! Anyone tried making your own vinyl stickies? I won’t sell them / risk violating the Colorforms patent.)

Wee See found via that evergreen source of inspiration, Motionographer.

Yet another wonderful animation from this group; I can’t wait to see more:

wee see – collection two from Rolyn Barthelman on Vimeo.

Side note on the essential nature of simple shapes: while peeking around the Creative Commons search on Flickr, I happened across this very vital use of colorform-like shapes, as photographed by scary toy clown/spezz. Someone with Naval experience may be able to tell me exactly what’s going on here, but I find it interesting that – as with the toy – in a military application, economy and efficiency matters. That says a lot about design.

I think we have a serious problem in our industry.

I believe it generally started when Basecamp became quite successful and 37signals started to talk about their theories on the subject. Their basic mantra was “Don’t quit your day job to build a web app. Build it in your free time and use your day job to pay the bills until your new app brings in enough money to quit your day job.”

I used to agree with this, but now I think I’ve come full circle.

I’ve seen a lot of web apps launched recently which haven’t succeeded. They’re not failing miserably, and they’re not wild successes. They’re just kind of puttering along, sapping just enough resources to be a problem, but not succeeding enough to really take off.

The majority of these apps were built by small web design firms or freelancers who bought into the dream without really understanding how much time it takes to make an app succeed. I speak from experience as this is exactly what happened with Amigo (which we sold in a firesale a few months ago).

Who Died, Who Survived?

There’s a really interesting post over at Meish.org with a great graphical example of the various web apps that have gone under. Here’s the graphic Meg put together:

It’s a sobering reminder of how tough it is to launch a successful app.

So what’s going on here?

I believe there’s a general misconception that goes like this:

1. Identifity a niche need that you have that’s currently under-served
2. Bang out somewireframes (or better yet, just start HTML’ing)
3. Ask a designer or developer to help out, in return for a bit of equity
4. Tweet about an invite-only beta
5. Listen to beta feedback and make tweaks
6. Launch
7. Get TechCrunched
8. Build recurring revenue till you can quit your day job
9. Live the good life

The major problem occurs between step #7 and #8. Most apps will fail here, not because there’s a problem with the idea, but because they don’t know how to market it. The reason for this is that it takes significant passion and time to properly market an idea. Sure, you may get lucky and the app magically spreads itself, but the cold hard truth is that most apps need serious time and effort in order to make them a success.

We need to consider that 37signals and the success of their apps are probably outliers - anomolies that aren’t easily repeatable.

So now what?

Don’t get me wrong, I’m a big fan of 37signals, but I think that unfortunately a lot of folks are getting the false impression that it’s easy to build a successful web app.

It takes time, passion and more time in order to make something succeed.

With that in mind, here are my suggestions for avoiding the web app Deathly Hallows:

Make time for marketing

Plan for the fact that marketing the app is going to take at least two days a week. I’m talking about about 16 solid hours of work, at a minimum.

How will you do this if you’ve got clients banging down your doors for changes or updates every day of the week? I’d highly recommend saving up enough cash so that you can take at least two months off from normal client work in order to make your app a success. This is two months after you launch. Keep in mind you might not be making a single $0.01 during this time, so you’ll need plenty of reserve cash.

If it’s impossible to make time for marketing, you’ll have to get investment in order to hire someone who can do it for you. This is pretty dangerous though, as this new recruit isn’t going to have your passion or understanding of the app.

Create a resource that helps your customers kick ass

One of the reasons why 37signals has been so successful is because they have built a large blog that’s aimed at their potential customers. Signal vs Noise has around 90,000 RSS subscribers and it does one thing really well: offers great advice, opinion and tips for people who might subscribe to their products.

If you read one thing about building a community around your products, read this comment by Kathy Sierra. It sums up this idea in a couple paragraphs.

Spend money on advertising

I think a lot of us are lulled into believing that if you tweet enough about your new app then it’ll surely succeed. Wrong. It’s very likely that the only way you’ll be able to get the word out to the masses about your new idea is by spending cold-hard-advertising-dollars.

Now, if you’re going to go down this route, it’s vital that you can track the effectiveness of your ads. You need to know:

1. Conversion rates on clickthroughs
2. Percentage of clickthroughs
3. What keywords are converting well for you
4. Where people are dropping out of the conversion process
5. Which ads are working (always test different copy and designs)

A/B Testing from the Start

One of the keys to increasing conversion rates on your site is to test the hell out of it. Plan on doing A/B testing from Day One, and never stop. If it’s a bit overwhelming, just tackle one page at a time, starting with your home page. Google Website Opimizer is the way to go on this.

To wrap it up

The most important piece of advice I’m trying to communicate is that you need to prepare for the huge amount of time it’s going to take after you launch to make your app succeed. Of course you need to believe it’s going to kick ass, but make sure you’ve got a  plan for making that happen. It might take several years of work to really make your web app a success, so be prepared.

Plan on building a business, not just a side project.

I’d love to hear if you agree or disagree, or if you have tips of your own.

Photo Credit: flickr.com/photos/david_han

Related posts:

• Ready to Start your Own Business?
• Will Your Web App Make Money?
• The Thrill of the Launch

Interface 27 from CyberPatrolUnit on Vimeo.

There has been a long tradition in live visuals and motion graphics, inherited from many other media, of maintaining a “secret sauce,” or the guarded formula of eleven herbs and spices. Ironically, for all you hear today “DIY” and “open source” in the same sentence, a lot of the motivation for doing something yourself has historically been doing something no one else can. Keep your secrets, and raise your value.

As our friend Bryant Place / CyberPatrolUnit sends over this latest set of live clips from a recent gig, and I browse through the comments, and reflect on the conversations I had last week at OFFF and during and following my own talk there, though, I’m struck.

The world has changed. First off, the Internet isn’t really about secrets. Your value is almost in direct proportion to how much you can share. Connections are forged through links of mutual exchange and good will. It’s not just about sharing your output or getting fans (the MySpace model), but sharing with a network of enthusiasts, and fellow artists. Those are the people from whom you often get real support (artistic, technical, and personal), gigs – and inspiration. (Even if you hate 8-bit music, that community is a really amazing model: their work to support each other and advocate for the whole subgenre has been I think the single biggest ingredient in their viral success.)

The visualist community increasingly itches not only to improve the quality of their own individual work, but everyone around them. A lot of us are in a battle for the future of this whole medium. Some parts of the world are devoid of live visuals, while others have mass-produced club visuals filling the nightlife.

Before I get carried away, the video itself is just the latest from the ongoing Interface 27 series. It employs a touch interface to control abstract visual pictures formed from streams of particles.

The reason I’m pulling back into the larger question is that these visuals are enabled by a library for Processing, a library we’ve seen here previously, developed by Memo Atken:

MSAFluid for processing (and Java)

If you’d rather use openFrameworks, there’s that version, too, as pictured below running blazingly fast:

ofxMSAFluid for openFrameworks

There’s even an ActionScript 3 port, in case you want to code Flash on the beach.

ofxMSAFluid for openFrameworks from Memo Akten on Vimeo.

So, why do I bring this up? Well, the work done on Processing (Ben Fry, Casey Reas, contributors like Karsten Schmidt, and others), on openFrameworks (Zachary Lieberman, Theo Watson, and their own team), and Memo’s own library, based in turn on many other libraries and implementations, was all a big risk.

It’s not an easy thing to put blood, sweat, and tears into open source. None of those people has exactly gotten rich in the process – not even via the ways you’re supposed to profit from open source, doing the lecture circuit and such. But on the other hand, we’re seeing things that would have been otherwise impossible.

And there’s artistic merit, too. Bryant’s work looks different than Memo’s. The library actually takes on a new life as it gets in someone else’s hands. Bryant actually just wrote me:

As for the Interface video - mention how cool it is that people like Memo post code for other VJ’s to tweak and use.  Mention "FaderTouch" - a 100buk touchscreen off ebay that "vjFader" programmed - using a rear projection onto a translucent screen/ touch sensor we were able to use processing in a very intuitive way.

I got the “mention” part down, I guess. ;)

The responsibility is partly ours to make all of this work: file bug reports, fix bugs if you can, document your work, properly credit the people making it, write documentation for projects, and so on. But it’s not hard to see an ideal start to happen:

1. Person x makes a library / framework.

2. Person y build on that library to make their own tool – and contributes it.

3. Artist uses the tool, gives back to the project, goes in a new direction.

4. More and better work spreads, the project grows, the medium grows, and the audience grows.

None of this happens automatically. We all have a lot more work to do. But having stood onstage in front of a few thousand people calling for just this, it’s nice to keep opening my inbox and seeing it happening. We’re seeing the first seeds planted for what could ultimately be a larger ecosystem. Now, I know there’s also a big gap left – Processing doesn’t have nearly enough contributors, bug squashers, or documenters, and it’s one of the biggest projects, so you can imagine what happens when you get upstream to libraries and the like.

Over the coming months, I think we’ll continue to look for opportunities to help structure some of that involvement and to explaining how you can contribute, too. Stay tuned.

In the meantime, go play with some particles.

For more on Bryant, here he is on his current activities:

- I just did Coachella with [Friend of CDM and contributor] Momo, and in the near future, will be heading to Detroit for http://www.myspace.com/detroitmusicfest

I’m not on the website, however, Kero.fm and Derek Michael - two people who essentially helped build the festival from the ground up 10 years ago - are booking me to play with various acts including CLP, Richard Devine, Drumcell, Busy P (which I did a solo VJ set with at Coachella) so I am super excited to be a part for the first time this year.

Here is a cool video from previous Interface 26:

After Detroit - Mutek.

http://www.mutek.org/

There are also some killer podcasts from past Mutek - http://www.mutek.org/podcast

I am going to meet artists, see the latest AV performances, attend workshops.

I’ll be at Mutek, too, so see you there.