Greg and Danny at BCIC put it thusly:

Anchoring means that a company has hit a level of maturity where it starts to give back to the community in the form of creating jobs, educating the talent pool, adding credibility to the region, inspiring young entrepreneurs, and spinning out new entrepreneurs, and tax revenue. This is the ultimate goal, and the ideal outcome. However, it doesn’t happen often, so the question becomes how do we make it happen more – or – how do we increase conversion?

Nailed it.

When people talk about Silicon Valley they focus on the investors and the schools – but the large anchor companies are the core of it all. Companies like Apple and HP have spent decades attracting top talent, training them, making them wealthy, and spinning out fresh founders. Their profits fuel that ecosystem.

So we’ve identified the goal: we want an HP, a Microsoft, or a RIM to start here, grow here, and stay here¹. Once that happens, we become Palo Alto, Redmond, or Waterloo respectively. Once you’ve become Palo Alto, your existence may bring neighbours Cupertino and Mountain View into existence, and a technology Mecca is born².

So how do we get an HP, Microsoft, or RIM in Vancouver? BCIC says to simply increase the number of startups. Jesse says to increase the number of startups that exit. Boris says to increase the number of startups that exit or get to Series A. None of these will hurt.

However, anchor companies are not born from landing a big investment, building a revenueless consumer app and selling to Google.

Anchor companies are born from smart people who love where they live, bootstrapping a company to profitability, then growing the shit out of that company.

Companies that are built to be acquired won’t stay in their home town. Acquisitions that happen for talent usually come with the requirement that the employees move to their new HQ³. On the other hand, if a company buys you because you’re profitable, they’ll often let you keep doing your thing.

I’ve been called “old fashioned”⁴, because I have a great fondness for bootstrapping and profitability. As far as I know, Nitobi, Mobify, and iQmetrix were all bootstrapped to profitability. As were HP, Microsoft, and RIM. As was Lululemon, a company that could only have been started in Vancouver. 37signals put Chicago on the tech map with only a couple dozen employees.

So how do we get companies to stay here? We help founders build profitable companies – then grow them.

1. I pick these examples because they are tech giants that grew where there was no giant before.
2. For those who aren’t familiar with Silicon Valley anthropology, HP started in Palo Alto, helping turn the surrounding valley into Silicon Valley. Steve Wozniak worked at HP, but founded Apple in neighbouring Cupertino because HP wouldn’t get on board with his idea of building a personal computer. Like a nuclear chain reaction, success fuelled success and most large tech companies are now founded by ex-employees of other Valley companies.
3. It’s worth recognizing that people returning to their hometown after a big Valley exit are good candidates for later bootstrapping an anchor company here.
4. “Old Fashioned” was the title the Lining Things Up episode I was on recently, referring to my fondness for making things and selling those things.

So far at Steam Clock, we’ve had close relationships with Nitobi and Mobify¹. We’ve shared space with them, worked for them, had beer with them, and been inspired by their ass-kicking. Our relationship with these two larger startups has helped shape our success so far – how could you not stay on the cutting edge of mobile when surrounded by these folks?

New founders don’t yet have these relationships, so where do they come from? For us, most of our startup relationships started through SFU, VanJS, or simply from being in Gastown. The Gastown area proves that higher the startup density, the more easily relationships form – and the highest possible density of startups is at a coworking space.

The premier Gastown-area coworking spaces right now are The Network Hub and The HiVE. Prior to that, WorkSpace served as our startup nexus, and helped inspire me to start Steam Clock. If you participate in an accelerator like GrowLab you’ll likely share space with other startups in the program.

Jesse Heaslip, in an otherwise interesting post about getting startups to stay in Vancouver, has announced a new startup space called Hack Hut. Uninspiring name aside², it will likely be a good option for startups growing past the home office but who aren’t yet able to sublease from another larger, growing company. The price is nice (although it sounds like a money-losing proposition unfortunately) and as long as they don’t end up some distant part of Railtown it should be pretty plugged in to the community.

Bringing startups close to one another is, dollar for dollar, more helpful to the Vancouver ecosystem than tax breaks ever could be.

1. …and Mozilla, and Joyent, and iQmetrix, and Foodtree, and Spacelist, and a host of other awesome Vancouver companies.
2. Both the word “Hack” and the word “Hut” feel unprofessional, making the combo pretty weak. It makes me think of a back room where college students can play with Arduinos.

What we really need is a facility that provides access to at least some subset of WebKit HTML rendering capabilities at a level between CoreText and UIWebView—something that doesn’t require developers to essentially re-invent HTML and CSS but allows them to render at least some level of HTML formatted text to a native view without the overhead and inflexibility of UIWebView—basically, a next generation version of Mac OS X Cocoa’s NSAttributedString

My favourite “why is native iOS development sometimes expensive” story is the Tale of the Bold Username. In an alpha version of the iPhone app we built for Foodtree, we displayed comments like so:

Allen: These are some great-looking blueberries! This year I’m buying a few pounds and freezing them.

We’d just hired Angelina, who had a background in web development, and her first task was to change the formatting to look like this:

Allen  These are some great-looking blueberries! This year I’m buying a few pounds and freezing them.

She was surprised that we estimated it would take her two days. In HTML this would take a few seconds – possibly a few minutes. Sure enough, it took two full days to get the text layout reimplemented in the low-level C APIs, called CoreText¹.

As soon as we changed to a formatted multi-line label, we had to do a whole pile of work just to lay out the text, specify the character range we wanted to format, wrap the text, actually render, and then get the dimensions of the final output. Things were further complicated by the fact we needed to get the dimensions of the output for every row in the table before it could be displayed, since this determined the height of the rows and therefore the scrolling metrics.

Why not just use a WebView? In most cases we would, but this is was one little element that may appear hundreds of times in a scrolling TableView. The table needs to be able to scroll at 60fps, and there’s no way we can tear down and set up WebView fast enough.

Worse, in order to get the proper scrollbar height at load time, you’d need to render the whole content in every WebView for the entire table. We could reimplement the entire main view of the app in a WebView, but that would have a whole other set of performance and UI consequences, and be a lot of work.

I think Buzz’ conclusion is apt:

I think the absence of such an API on iOS is holding the platform back as a media platform more than almost anything else I can think of.

1. Uncharacteristically, we didn’t bill for the time – partly because she was learning, and partly because it seemed so ridiculous.

Watch me learn design via Prism's add button iterations.

There are a dozen apps that do the same thing as yours¹. To stand out, your users must to be delighted by your product – from icon to settings screen. You get there by designing, aligning, and refining each screen, nook, and edge case.

Most programmers act as if their ability to program prevents them from making something look good. This is bullshit. There are hundreds of counterexamples, ranging from Loren Brichter to Mike Rundle. You get good at design exactly the same way you get good at programming: you do it badly enough times to become mediocre, then you do it mediocrally until you become good.

Maybe you don’t enjoy design, which is fine. However, most engineers haven’t really tried it because they think they’re incapable. If you’re really unsure where to start, do a bit of reading about spacing and alignment. Spend some time trying to reproduce a nice-looking button or effect. Pull apart somebody’s .psd and reverse-engineer it.

Then here’s what you do: next time you’re tasked with adding a feature, take a serious shot at how it should look. Do your best to line up that new button with the existing ones. If the existing styles in the app clearly won’t work, try tweaking one until it’s close.

Your goal is to add a new feature, then have the designer that usually fixes your “programmer art” leave it alone². It may start small – an error message or edge case, or a new element that just needs to be well aligned and balanced with what’s already there.

The more design practice you get, the more opportunities it will open. The prototypes you present to superiors will become more impressive. Your personal website will stop looking like it’s from 1998. The designer time spent on your features will go to polish and “wow” instead of just getting things up to par with the rest of the product.

Before you know it³, you will have become a unicorn. That’s right, every startup’s dream: a Desingineer. You’ll likely continue to focus on programming, but you’ll have become more powerful than you could possibly imagine.

Or at least, you’ll make wonderful looking products that people want to use. That’s a good start.

1. If there aren’t, you’re either crazy, or there will be soon.
2. Admittedly this was very hard at Apple, but I got pretty good at it. The trick was to find some function or edge case that had yet to be mocked up by Design, and implement it so well that it looked like it had been reviewed.
3. Well actually, after thousands of hours of practice, but close enough.

The first 10% of our work on Prism was getting full-screen images loading from a few sites. The other 90% was crazy amounts of polish: captions, multi-threaded loading, Recommended Galleries, generating nice thumbnails, storing images for offline use, not storing too many images for offline use, and so on. We had to make a judgement call between being the best at we do (pulling images out of HTML) or instead focusing on supporting every site in the world. Looking at Prism 1.0, I think we made the right call.

Looking forward, there are a lot of sites we’d like to add support for – Twitter, Facebook, Google Reader, and Flickr are some big ones, but the sites users request will get support first. If you’re interested, please give Prism a try and let me know what you think.

Onward!

Buzz Andersen, a longtime Objective-C developer, has a good example in  his post about dogmatic Native vs. Web arguments:

To me, one of the textbook examples of something the web is made for but is practically rocket science on iOS is text rendering. While users are accustomed to thinking of iOS apps as exceptionally beautiful and visually sophisticated, UIKit’s text rendering capabilities turn out to be frustratingly primitive, making it quite a challenge for even expert iOS developers to match the advanced page layout and text formatting capabilities of web browsers.

The point is that although ignoring the great strengths of native code can lead to an inferior app, ignoring the great strengths of Webkit can also lead to an inferior app. Dogma doesn’t help build wonderful products – choosing the right tools does.

JSConf was the largest crowd I’ve presented to so far (about 200 by my count) but it was worth the pressure for sure. Any feedback on my presentation style would be really helpful. Maybe next year I’ll give a talk entitled ‘Eliminating all the “uh”s and head bobbing you see in videos of yourself giving talks’.

A huge component of that polish is responsiveness: giving the user an instant reaction to everything they do. Making your app faster and more efficient is good, but there’s more to responsiveness than speed.

60 frames

Your goal is 60 frames per second: the natural frame rate of the device, faster than the user can perceive. During animations and transitions, 60fps means a smooth transition with no stuttering. Although this is important for all animations, it is crucial in animations that are responding to a user’s touch. Even a very subtle delay between touch and response will give the feeling that the app is sluggish. This is a big reason that JavaScript “fake scrolling” gets such a negative response from users.

When responding to user feedback, 60fps means no stalling. If your app stalls for a frame on any supported device, it’s a bug. As long as the delay is small it might not be a high priority bug, but it is still an opportunity. Profile your app to get an idea of where your frame rate drops. It’s often worth keeping an older device to do this testing on, since if you can even get the older device up to 30fps, you’ll be in good shape on newer devices.

Actually getting a faster frame rate often involves either avoiding waste like drawing offscreen views, unnecessary opacity, or inefficient algorithms. Often though, getting a smooth frame rate involves moving work off of the main UI thread.

Threading

By default, any code you write runs on the main UI thread. If you do anything on the main thread that takes more than 16 milliseconds, you’ve dropped a frame and there will be a perceptible stutter. 16 milliseconds is a really long time, especially on newer hardware, so this isn’t as dire as it sounds.

Your biggest thread-blocking monsters are I/O operations. If you read or write a file or do any network operation, you need to do it in a background thread. On iOS this is a lot simpler than it is in plain C. The NSURLConnection class works asynchronously by default, plus Grand Central Dispatch and Blocks make most things straightforward to make asynchronous.

Although moving file, network, and data crunching to separate threads is important for any app, it’s doubly vital on mobile. Your phone doesn’t have a wait cursor, and its network quality can be incredibly bad. If you block for long enough, the OS will kill your app.

Spinning

Now that your work is asynchronous, you need to let the user know something is happening. Provide a progress indicator if possible and worthwhile. Otherwise, get spinning.

Activity indicators (whether spinning, pulsing, or jiving) let your user know that you’re on the job and should go up after any perceptible delay. Without feedback, your app could have crashed, or it could have finished but without the results the user expected. You never want people wondering what your app is doing.

A special kind of activity indicator is placeholder content. Users can sometimes navigate through your app faster than you can render content, especially if you need to fetch something from the internet. For things like avatars and other peripheral information, a tasteful placeholder is definitely preferable to a distracting spinner.

Backend responses

So you have spinners now, but want to show them as briefly as possible. Although ideally you respond within 16ms, users are used to waiting for internet content to be delivered, especially when they know their wireless connection is weak. Even on a good wifi connection, your app’s request will have perceptible latency to get to the server and come back with a simple response.

Unfortunately, any time your backend servers take in responding is in addition to that latency. Every moment it takes for you to get a response back to the user is more frustration and impatience. Your goal should be to get content back to the user in 100ms¹. After one second, users lose their feeling of task flow. On the web, users are intolerant of waiting for servers to respond. Within a mobile app, they are even less tolerant – if you can’t provide a faster experience than a normal web site, you might as well just have a web site.

Launch time

While launching an entire app in one frame is not likely, launching before the user feels a wait is possible, and launching in a second is often straightforward. Launch time affects the most important use case for your app: first use. If you can’t get the app loaded and fully functional in a second, you should at least get it awake and giving activity indication in that time.

Doing some simple profiling of app launch will usually reveal unnecessary work you’re doing at launch. Whether it’s building views that aren’t being displayed yet, loading content that isn’t necessary, or blocking on some operation that could be threaded, you can often get some easy wins without a lot of work.

Tap highlights

Every tap should have consequences when you lift your finger. First, though, comes an indication of a successful tap when you touch down. This provides a visual response for actions that cause a few frames to drop but last less than 100ms. Unlike with a keyboard or mouse, the user has no tactile feedback that they tapped successfully. They have no way of knowing they tapped on the right thing until it highlights.

Result: Joy

Congratulations! You now have a responsive app that is a joy to use. Of course, it also needs to be functional, usable, beautiful, and useful. But that is for another day.

1. IBM did this research decades ago, but Jakob Nielsen has various explorations of it online.

However, consumers have never bought in. Businesses do, prosumers do, enthusiasts do, but normal people don’t. For a decade people have tried to make “micro-subscriptions” a reality – a way for normal people to pay a small amount to get a content or service. They’ve all failed utterly.

There is no way people will put in their credit card info into various sites and apps to pay a $1/mo fee. The cognitive pain of creating accounts, entering and maintaining payment info, and being billed for it makes the whole thing a complete non-starter to most consumers. And so, consumer apps continue to be offered as advertising-supported affairs that need giant scale to be profitable, or, more recently, pay-once apps.

iOS subscriptions finally change this. Although Apple takes 30%¹, the one-click nature of the process and safety net of the App Store means for the mass market you’ll get way more than a 30% boost in sales.

The same app offering the same value to the mass market is going to get 50x as many customers through one-click subscribing at $1/mo than it would get through sending them to enter their credit card information on some website. I may be wrong – it may be more like 500x.

Entire products that were infeasible before are now feasible. Micro-subscriptions are here. Enough writing – back to writing an app that kicks ass with them.

1. I am aware Apple’s cut makes the “you must offer in-app if you have subscriptions” rule a slap in the face for some business models. Apple can’t really charge much less than 30% because they sell iTunes cards at retail, plus it would provide a way to route around their cut for app sales. Still, forcing everything through them sucks.

Now, it’s true there are some ways to make money from web apps already. There are actually three¹:

1. Sell advertising on your multimillion-user site. Often this requires VC to ramp up to a huge user base.
2. Sell your app as a service to companies that subscribe. This can be quite profitable but consumers aren’t willing to do this.
3. Get paid directly to build custom web apps.

The Chrome App Store is irrelevant for the above categories of software since they’re profitably humming away. However, there are a lot of potential web apps that don’t fit into the above categories. Specifically, consumer-oriented apps that aren’t appropriate for the “scale huge, sell ads” model. Some examples:

• Games
• Specialty consumer software (like WeddingDJ)
• Personal productivity and finance software
• Magazines and newspapers
• Most stuff on the iOS App Store

Most web developers in the above markets attempted to do the obvious: charge customers to use their sites. However, having to put in your credit card info or jump through a PayPal hoop to pay for something online is a pain in the ass. It can’t be understated: a credit card entry form is a brick wall to most consumers. The vast majority of them would never consider putting their credit card info in to pay for a web site, no matter how good it is.

Those same people don’t think twice about paying for apps, especially as a one-time fee. Hence, the great success of the iOS App Store. The App Store, and iTunes before it, and Amazon before it, showed that people will pay to buy things online if they can just click. Developers flocked to the iPhone because you can make money there, myself included.

A lot of people would love to make web apps for consumers, but their ideas aren’t viable under the advertising model. It’s insanely hard to bootstrap a consumer-facing web startup because of this. As a consequence, startups that would have been building web apps five years ago are now building iOS apps. The web is a great platform, but if consumers aren’t paying you, then you’re limited in what you can build.

So now we wait and see if consumers embrace the Chrome Web Store. If they do, expect to see a whole new wave of web apps.

1. Arguably, the fourth way to make money on a web app is to wrap it in PhoneGap and stick it on the iOS app store. While tangential, the fact this is a popular route reinforces my argument.