Chris Dixon posted with two reason why the decline of the mobile web will hurt innovation. There is a third, more important, reason: slower iteration cycles.

Rapid iteration made the web successful as a platform over shipped software.

Product development cycles are extremely short in the web world. Dream up a feature, develop, deploy, learn, and enhance all within a day. Push new code to a server and your users instantaneously have access to the new feature.

The same cycle for apps takes weeks due to longer development time, App Store approval time, and users have to download your new version. Development times can be improved with better frameworks and OS upgrades. Approval times can be reduced to zero (see Android). However, users will still have to actively download or update your app before they can use your new version.

Longer cycles lead to less iterations. Less iterations means your seed round runs out faster.

Last week Jesse (@jessedang) and I welcomed a new labradoodle puppy, Pixel, to our family. Being a tech family, we did what all tech parents do (right???) and turned him into an experiment!

We created Twitter and Instagram accounts along with a Facebook page. We wanted to see how popular we could make them on a budget. Along the way we’ll try to correlate what strategies on each platform drive engagement. Flat out paid advertising is not out of the question but we plan to do it sparingly.

Here are the baseline stats for our first week with only organic growth. No advertising or aggressive following in hopes of follow backs.

• Instagram @hellopixelpup: 16 posts, 14 followers, 4 following
• Twitter @hellopixelpup: 16 tweets, 6 followers, 2 following
• Facebook hellopixelpup: 11 posts, 0 likes (no invitations to like the page)

Most of our posts were cross-posted from Instagram so naturally it’s the most popular account. First lesson, Instagrammers discover content through #hashtags. There is a direct correlation between number of #hashtags and number of likes.

We’ve got some lofty goals for the accounts and I’ll be posting updates periodically. Oh and could you please follow, like, retweet Pixel!

I was cycling up Mount Hamilton this morning when my Mom calls to change our lunch plans. Luckily, I still had one earbud so I was able to answer and confirm. After I hung up, I needed to call my girlfriend, Jesse, to update her. My iPhone was in an armband so I couldn’t see the screen or operate it. I couldn’t stop because stopping on a hill meant unclipping not to mention breaking my pace. Siri to the rescue… or so I thought.

Me: Siri, call Jesse.
Siri: Something went wrong, please try again.
Me: Siri. Call.
Siri: Who would you like to call?
Me: Jesse.
Siri: I can’t do that, try again later.

I tried at least 10 times before pulling off the road to do it the old fashion way. I’m not an avid Siri user, except for some comic relief, but this was the one time I really needed it. The tagline on Apple’s marketing page for Siri is “Siri lets you use your voice to send messages, schedule meetings, place phone calls, and more.” It failed gloriously at something it’s primary use case.

It’s been almost 2 years since Siri was released and it still doesn’t deliver on Apple’s initial promise. iOS7 has no announced API for Siri which means for 3 years since inception Siri won’t be expandable.

During the rest of the ride, I was upset that Siri couldn’t help me with basic things in 3rd party apps like

• Strava, what’s my current distance?
• Rdio, resume playlist.
• Clear, add task “Pick up soda”
• Evernote, add note “new idea, write blog post about how much Siri sucks”

A viable API could be to have apps woken up by Siri, similar to a push notification, with specified keywords. Apps respond with text for Siri to say along with a card for Siri to display. iOS7 already allows apps to be woken up to respond to notifications.

The next step for Siri seems to be “iOS in the car” with heavy Siri integration. If Apple releases an iWatch, you can bet there will be Siri integration. However with Siri’s current state of ineptitude I don’t have high hopes for Apple’s voice driven future.

Last week LinkedIn hosted a summit for the product org. I was lucky enough to participate on “Secrets of the Startup Superstar” panel with other great founders of companies acquired by LinkedIn. One theme that surface was Paul Graham’s start up curve, specifically the Trough of Sorrow. An audience member asked, “How do you iterate on a product after it’s launched?” The discussion that followed solidified some jumbled thoughts I had on this topic so here they are.

One important lesson that we learned at Maybe was “Get on a higher growth curve.” Or visually:

If the product is growing at a rate of 10 users per day, it will take forever to get to a million. It’s not the curve you want to be on long term. You need to do something that will get you on a growth curve of 100 or 1,000 users a day even if it means dramatically changing the product. Even if it means alienating the 100 users you’ve already acquired.

You maybe resistant to changing the product, starting over, or admitting your initial product hypothesis was wrong but ask yourself why? What do you have to lose, what are you trying to protect?

You have to take risks because the goal is not to have 1,000 users but a 1,000,000 users. The only way out of the trough of sorrow is to acquire users. How fast you acquire users is directly proportional to the time spent in the trough.

In the book Beautiful Code (read for free here) a chapter titled “Correct, Beautiful, Fast (in That Order)” explains a process to write fast and beautiful algorithms. This same framework, except replace correct with possible, is the key to success when designing and building products.

Possible

Since there is no “correct” answer for a product, possible is simply a better word. The goal is to make a live working prototype of your product regardless of how ugly or slow it is. Why? Something magical happens when a product is real. It’s exciting when things actually start working. You’ll immediately see what works, what doesn’t, and discover things that are invisible in a wireframe. Lastly, do not underestimate the energy it provides. It’s going to be a long arduous road, but when something is “real” the path suddenly becomes straight and clear.

How do you accomplish this? Grab a bold sharpie and starting drawing. The boldness will force you to make broad strokes and not get bogged down in tiny details. Trash and start over as often as needed.

When you have a decent sharpie mock, start writing code. That’s right, start coding. Do not make pixel perfect mocks. Remind yourself that the goal is to make the product possible first. Live in a web browser, live on an iPhone, something usable that does X and then Y and finally Z.

As for dev, a quick prototyping language is a must. Use the framework’s scaffolding where ever possible (Rails scaffolding, bootstrap, UIKit, etc). Avoid refactoring, avoid over thinking the code, and definitely do not optimize. A small feature you thought was awesome in the design phase but will take hours to code? Put it on the back burner for now.

Remember, your goal is to simply make it possible.

Beautiful

Now that you have a working product, it’s time to polish. I love this part because a beautiful product can be the difference between a sign up, a download, or a user walking away. Beautiful means much more than shiny buttons (or flat now a days). It means filling in all the gaps of your product. Work on things like the right sign up flow, the fringe things that will make your product more intuitive and more approachable.

Play with color palettes, animations, polish, polish, and polish some more. Smooth out the rough edges until it’s something you can be proud to launch. If you have a designer, consider yourself lucky! Work closely with them to make sure everything is pixel perfect, including all those 1px adjustments.

Fast

Now that you have a beautiful live product, it’s time to make it fast. It’s been proven, speed matters. Refactor your code, follow the page speed rules, make things take 1/10th of the time they used to. Reduce the sign up flow from four steps to one.

The goal of framework is to get your product launched without wasting time and effort. If you have a task ahead, first classify it as possible, beautiful, or fast. Don’t do it if it’s not helping you to reach one of those three goals. Your products will be better products and they will be built faster.

image credits: possible, beautiful, fast

It’s been 2 months since Maybe, a company I co-founded, was acquired by LinkedIn. I have a few “lessons learned” drafts that I’ll clean up and post in the future. But for now, a therapeutic retrospective…

Maybe started with the idea of making decision emails a better experience. You know, those emails you send to friends with 5 airbnb links to pick between for the weekend. Or the email you send to your photographer friend with the 3 digital cameras you’ve been eyeing. Everybody’s sent or received them.

The first prototype was a bookmarklet that collected URLs and sent out a nice email. There was potential and friends & family we pitched it to immediately identified with the problem. The space also fit our criteria of 1) consumer, 2) infinite, and 3) a problem we had ourselves. We formed a company, raised a round of money, and we were off!

The MVP ended up being a combination of Pinterest and Quora, at least that’s how Robert Scoble described it (love the positive comments). Launch day, June 29th, 2012, we fired up extra EC2 instances, eagle eyed the logs, read the blogs, and ate cake. At this point the team was 3 co-founders Haider, Omar, and I plus Vivian, our designer (eventually 2 ex-AdMob stars joined, Chris and Nick).

A week after, launching, we were adding features from simple things like suggestions, threaded discussions, and automatic Yelp ratings. We built technology to determine the nature of URLs that were being Maybe’d  (yes, we invented words). For example, using the URL alone, we could determine that a site was for a hotel then automatically show a map of the area, best price, and traveler reviews/ratings.

Feature after feature, we always thought Maybe was one more away from the ideal. Meanwhile, initial launch sign ups dwindled and dailies were consistently down. Retention was also down, even amongst the team.

This was bad. Did users not get it? Did we build too much? Did we overestimate the value prop of the product? The answer was all of the above. At the end of the day, the problem boiled down to retention.

Maybe wasn’t very good at retaining users. Initial users who went through the effort of creating a decision didn’t get enough value to make a second decision. Users who voted on a decision didn’t come back to make a decision or vote again. The time difference from when a user discovered Maybe and when they actually needed Maybe was too large.

We were wrong.

But, we had runway, an all-star team, we just needed a product so we pivoted and started on a new product. Then LinkedIn came calling.

At the time, our new product was in the midst of a beta and almost ready to launch. Our decision was between going to LinkedIn or go through with an official launch. We debated intensely, there were merits to both paths. We were at a crossroads.

Finally, after long discussions, Omar summed the decision up succulently, as he’s prone to do, “Startups are about expected value.” The expected value for the team by launching a new product was low since it was inherently high risk. Being acquired was near zero risk so naturally a higher expected value. LinkedIn is a fantastically run company, the team would stick together, and we would get to do what we do best; build kick ass products.

We decided to join LinkedIn and end the Maybe journey.

I can’t say what the team has been working on the last two months since it’s unannounced. However, LinkedIn is a tremendously focused company that we’re happy to be a part of.

Last week, we finally got around to having a small celebration in SF near the Giants’ ballpark. I’m definitely not the first to make a baseball analogy about startups but I think the following nicely sums it up….

We stepped up to the plate hoping to hit a home run. Instead, we hit a double, but that’s alright because most strike out. We’ll be at bat again. The game isn’t over.

Today, I decide to see if Sublime Text 2 could be my next great text editor. The “vintage (read: partial VIM)” support had matured just enough to make editing text bearable so I’m giving it a shot for a week. Why invest time in beta testing an essential part of my toolchain? I’m glad you asked (ok, let’s just pretend you did).

Back in college, I dropped by a professor’s office for a quick meeting. He was busy at his computer and asked me to wait a second while he updated the course web page. He was editing at a pace, at the time, I had never seen done before. He was navigating, updating, auto-completing, literally shredding his way around a text file at lighting pace. His hands never once moved from their natural typing position except to type one last command… :wq

I was shell shocked. I never gave a second thought to the text editor I was using. If I recall, I was editing code in notepad at home or kwrite (gulp) in the lab. After watching my professor literally dominate code, all the while never touching his mouse, my perspective of text editors changed.

I started to view them as tools that needed to be learned. A little investment up front would provide big returns in productivity. A great editor allows me to literally produce the most amount of code in the shortest amount of time. The less time I spend doing things like navigating between files, find/replace, hunting for syntax errors, even typing, means (quoting Atwood) “less time between thinking that thought and expressing it in code.”

My advice, for anybody that writes code, is to pick a text editor and learn the shit out of it. You’ll be better off in the long run.

I’ve been using the Nexus 7 for a couple days now. Here are some thoughts.

7 inch size is perfect for one handed reading in any orientation. Vastly superior reading experience than an iPad which not only requires two hands but makes reading lying down near impossible.

The screen is no where as nice as the new iPad (expected) but definitely better than the iPad 2 (not expect). This is only exacerbated by the terrible compression on some of the stock wallpapers.

Jellybean feels like a nice evolution of ICS. (Last android device I owned was a Nexus S). It even feels more modern than iOS 5. The larger screen real estate also helps in certain places such as widgets and the task switcher.

Chrome is wicked fast. Browsing is now on par with an iPad in my opinion.

For the price, I opted for the 16gb version, it is the best tablet on the market. I have an original iPad 1 and a kindle touch and the Nexus will replace both of them.

If/when apple releases an iPad mini, I have no doubt they will sell like hotcakes. The form factor is simply better suited for some tasks. I just hope some of those customers will give the Nexus 7 a shot. It may impress them.

An update to my previous post about the MacBook Pro Retina now that I’ve used it daily for 2 weeks.

The rMBP should really be considered as 2 pieces of technology, the hardware and, separately, the display. The hardware design encompasses non-upgradable integrated components, cpu, thinner profile, no dvd, no ethernet, MagSafe 2, weight, and size.  The display encompasses the retina display, obviously, but also the graphics hardware that pushes all the pixels.

Let’s talk about the hardware, the easy part. Coming from a 13″ MacBook Air 2011 i5, I’ve come to appreciate the raw power the Pro offers at the cost of weight and size. Apple’s pricing scheme means that the rMBP is an absolute no brainer if you’re considering a 15″ Apple laptop. For an extra $400 you’ll get 2x the RAM, an SSD, and essentially what equates to the high resolution display option on the base MacBook Pro. All these options in a base MBP will drive the cost up to $2,500. More bang for your buck. I can’t recall the last time I put a DVD in any computer I own and every network I connect to is N so the omitted hardware is a non-issue.

If you’re deciding between a MBA 13″ and a rMBP, that’s a tougher decision. All I have to say is be prepared to give up mobility with the rMBP. Even though it’s lighter than a non-retina MBP, it’s not even in the same ballpark as an MBA.

Now let’s talk about the display. It is not worth it. 99% of third party apps are not retina optimized so you’re staring at blurry assets 24/7. (I don’t use Safari.) I recently noticed severe display lag in everything from scrolling to expose. AnandTech has a great article on this topic and there numerous videos on YouTube showing the effect. Anand points out that Mountain Lion will improve the situation but at the end of the day, the graphics technology has not caught up yet.

Regardless of performance, the best resolution (for me) to run is equivalent to 1680×1050 which gives me more screen real estate. Apple’s recommended setting gives 0% more real estate, rather pointless to me. For all the marketing Apple has done, the hype just doesn’t match the reality.

In short, there are many reasons to buy a rMBP but the retina display is not one of them. I have no clue how Apple will manage their laptop line ups in the future and how they’ll converge but my recommendation for the “average” consumer would be the 13″ MBA. It’s definitely the sweet spot for performance, price, and weight.

I picked up a new base MacBook Pro Retina to replace my 2011 13″ MacBook Air i5. Here are some random thoughts on the first 24 hours with Apple’s current king of the hill.

• Heavy, much heavier than the Air. Before the Air I used the older 15″ Pro exclusively and now the weight is back. Holding an open Pro by the corner vs holding an Air by the corner is night and day.
• Immediately changed resolution to 2nd highest allowable (Preferences says “Looks like 1680×1050”). More screen real estate. Doesn’t appear you can get to full native 2880×1800.
• Display is unreal for retina optimized apps. Doesn’t have the dramatic effect of the new iPad’s display but still impressive.
• However, get used to blurry assets everywhere. Non-retina apps, non-retina websites (even on Apple’s own site) is going to be the norm for who knows how long. This shift will definitely not be as quick as the New iPad or iPhone 4.
• Less battery life. I was very used to checking the battery meter on the Air and see 6 hours remaining. In fact Air lets you sticky the Remaining Time in the menu bar but not the Pro. My guess is due to the unpredictable hit caused by switching between integrated and discrete graphics.
• Fans are not 100% silent but much less intrusive as the Air. Normal fan noise if you get the Pro worked up (eg. install XCode)
• Migration assist is the best thing in Lion. In less than 2 hours, I picked up on the Pro right where I left off on the Air.
• Fast, no doubt about it, the Pro is much faster than my 2011 Air. Plenty of benchmark reviews out there for you to compare.
• MagSafe 2 sucks. Countless MagSafe 1 adapters I’ve strategically left around the house are now useless.
• Thunderbolt display now plugs in on the same side, power and Thunderbolt being on the same side of the laptop is a small but important thing.

The pure power of the MacBook Pro might just be enough to outweigh (pun intended) the featherweight MacBook Air.  That is until Apple releases a MacBook Air 13″ Retina.

As I watched the iPhone 4S and Siri announcement today, I was reminded 3 years ago when Siri was kind enough to drop by the AdMob offices. They came by to demo and get feedback on their app. At the time I was impressed with the technology but I could never envision myself using it.

In the past couple years, since switching to Android, the only use case I have for voice actions is sending a text while driving. However, Apple thinks Siri is cool, $200 million cool. Cool enough to make it a marquee feature of the iPhone 4S. Why?

Then it dawned on me. Siri is not for me (or you). Siri is for your Mom.

Go take a look at the iPhone 4S Siri feature page. For every task that you can ask Siri to do, a techy can do faster with a UI. Need to find a Greek restaurant in Palo Alto. Open up Yelp, type in Greek and you’re done. Need a location gated reminder for when you arrive home? Tap the reminders app, location gate a new reminder, done. What time is it in Paris? Google search “time Paris”.

Now think of your Mom, or some other non-techy in your life. Could they answer the same questions or complete the same tasks? That’s where Siri comes in. In plain English, anybody can now unlock the full magical potential of the iPhone. Apple’s goal is to sell an iPhone to everybody on the planet. Making it easier to use is the best way to accomplish this goal.

I do look forward to Siri’s promise of being your own personal HAL 9000. I just think it’s going to be delivered in two or three generations.

You know what’s easy to come by? Ideas. You know what’s hard to come by? Ideas.

I’m sure everybody has doc sitting in the cloud or on their desktop where they jot down the best ideas that come to mind. (If you don’t, start immediately.)

One day, you’ll end up opening that doc to decide which one of your ideas deserves to be turned into a product. How do you choose? They all seemed so good when you had those epiphanies.

At Churn Labs we have an idea sheet shared amongst everybody. Everybody is encouraged to contribute. We’re closing in on over 100 ideas and every one of them seem good. The problem is we only have a finite number of people to execute these ideas. How do you separate the “good” ideas from the cruft ones? Here’s my list of criteria when evaluating an idea.

• Solve a real problem – Even better if it’s a problem that you personally have. When you’re chasing a solution to a problem you’ll never need to know what to do next.
• Take advantage of emerging trends/technology – Is your idea only possible now because of an emergent trend/technology? At Churn, we ask is this idea only possible now because everybody has a smartphone in their pocket? Ride the waves.
• Risk : Reward – How quickly can you create an MVP? Crazy ideas are worth testing if you can build and launch a product fast.
• Less crowded spaces – How many other startups are in the general space your idea occupies? Ideally, the answer should be close to zero. Less noise, greater chance of lift off.
• Distribution – There are literally a thousands of startups. Once again, how do you rise above the noise? If you’re idea is inherently viral, it will be much easier to gain traction. You’ll spend much less effort and time to acquire every new user.

Qualifying ideas well help you sort out your own noise and you’ll spend less time on ideas that looked great at first blush.

Also, share your ideas with everybody, don’t be secretive. The mere act of talking through an idea with another person will help you solidify it. You’ll be forced to formulate your ideas into coherent sentences. You’ll be surprised how a great idea on paper sounds utterly ridiculous when you say it out loud.

On the other side, if you’re lucky enough to be a sounding board for someone with an idea, do NOT start off by putting up road blocks. “I don’t think that will work because ….” or “but what about …” are absolutely the worst things you can say. Instead, pause and think about how you can make the idea better. Fan the flames of creativity instead of extinguishing them. At the very least you’ll be exercising your idea muscle.

image from bitzcelt

A small blog post for those attempting to create multiple UITapGestureRecognizers handled by one function. Coming from JavaScript, it’s easy to “attach” arbitrary data to elements or objects and references them on the event handler. (el.rel = ; var photoId = event.target.rel;). I explored all options in Objective-C from using the UIGestureRecognizer’s .hash in an NSDictionary to finding out how to implement an NSMapTable in iOS. (Currently NSMapTable is not available in iOS 5).

Finally, I RTFM’d the UIView base object documentation and found exactly what I was looking for; .tag. Although limited to NSInteger, more than enough to identify which view the taps were coming from.

For example, if your project programmatically creates multiple UIImageViews and you want one function to handle all incoming taps, the code is as simple as.

int i;
for(i = 0; i < count; i++) {
    // some image
    UIImageView *imageView = [[UIImageView alloc] initWithImage:image];
    // attach to some view
    imageView.tag = i;

    UITapGestureRecognizer *g = [[UITapGestureRecognizer alloc]
                                    initWithTarget: self
                                           action: @selector(imageTap:)];
    [imageView addGestureRecognizer:g];
}

// handler
- (void)imageTap:(UITapGestureRecognizer *)sender {
  // identifier can be referenced in sender.view.tag
}

The CR-48 is the pilot program for Google’s new Chrome initiative ChromeBook. CR-48 is a basic non-branded ChromeBook handed out to a lot of Googlers as a Beta program. I brought mine on vacation last week to Asia to experience what life would be like with a ChromeBook as my primary computer (and admittedly I didn’t want to risk bringing a $2,000 MacBook).

Pros

• Instant On – Forget booting in 8 seconds, the best thing about ChromeBooks is their instant on. You never shut them down so you’ll never have to boot them. Flip the lid and you’re on the web instantly.
• Full Keyboard – Having a full keyboard (say over your mobile or a tablet) is an absolute must for a primary computer. I despise cranking out full emails or doing heavy duty web surfing on tablets.
• Shareable – With guest mode, the CR-48 was easily shareable with my girlfriend. Open up the laptop, click on guest mode, and she has a blank slate to work with. I can imagine it being a communal device as opposed to the your iPad which is very personal.

Cons

• Web Limited – I need to import some .RW2 formatted files while I was on vacation and unfortunately no image services I could find accepted them. (Not Picasa, not Flickr, not Imageshack, etc). I ended up going to the hotel’s business center and downloaded a simple shareware program.
• Needs more Horsepower – The CR-48 just couldn’t keep up in some cases (eg. full screen HD YouTube). This is something that can be fixed as components become cheaper. However, the newest ChromeBooks announced from Samsung are pushing the upper price ceiling.

The canonical question is of course, how is the ChromeBook better than a netbook? My answer is that it’s not. A better question to ask is, “Is there room for another device in a world of desktops, laptops, tablets, and mobile phones?”

Last week I had the pleasure of speaking at Google’s largest conference, Google IO. It was 30 minute overview of how to build a business instead of just building a mobile app.

Don’t just build a mobile app. Build a business.

After Gawker had a massive security leak, I began to rethink my password solution. I had essentially 3 classes of passwords, high, medium, low. High security passwords, used for financial instituions, were unique for each site and saved in an email thread in my Gmail. Medium and low security had a handful of rotating passphrases and easily guessed 4-8 letter passwords. In general, I didn’t care if one of my medium or low level security accounts was hacked since access to those would net nothing.

However, so many of my web services are crosslinked that it was becoming difficult to keep track of my security holes (see the Twitter hacks as a good example).

So, I figured it was high time that I start using a password manager. After looking at my options, I chose 1Password. My requirements:

• OS X support – my main computer and laptop
• Chrome extension – main browser
• Dropbox integration – Drop dead easy syncing between all my devices
• Android Support – currently my main phone
• iPhone Support – previously my main phone but I’d like to keep my options open

1Password fulfilled all these and fulfilled them extremely well. The OS X is easily one of the most well thought UIs I’ve used in a long time. Dropbox integration is built directly into both the OS X and Android applications. Agile Web Solutions, the company behind 1Password, is a commercial endeavor. Usually I favor open source solutions, but in this case I’m guaranteed longevity. (I imagine migrating to another password manager will be a nightmare.)

I spent a few hours transferring and changing my passwords on all the accounts I could remember. The count is up to 51! Odds are that 1 out of 51 of these sites will have a security breach at some point. Now that all my passwords are unique, I can sleep easy.

jQuery Mobile Alpha was released yesterday and it’s very good for an alpha. I think John Resig and team have a long way to go but the project itself is very ambitious. A full mobile framework for iOS, Android, Blackberry, webOS, MeeGo and more is nothing to sneeze at.

For example, after a few minutes on Android, I noticed that the persistent footer nav doesn’t always stick to the bottom of the screen. Since most mobile browser do not have css fixed positioning this ui paradigm is one of the hardest problems to solve. Notice that toolbars simply disappears on touch and reappear.

I look forward to the the next release, at the moment I wouldn’t say it’s ready for a production deploy. It is an alpha after all.

After seeing Leah Culver’s blog post entitled “iPhone Pull to Refresh“, I was disappointed when I clicked through to find out that it was an ObjC library and not a javascript library. So I set out to see how hard it would be to replicate the UI pattern in javascript.

DEMO | javascript source

This is a prototype/proof of concept which gives a good idea of how to implement pull to refresh in javascript. It uses no javascript libraries so you could easily port it over to your favorite.

To implement the UI pattern properly, javascript must take over the browser’s default scrolling functionality. Any touch javascript framework already does this (PastryKit, jQtouch, etc). Mobile browsers block rendering when the user is scrolling so exposing the “Pull and Release to Refresh” hint is impossible. This limitation also makes it difficult to develop a plug and play javascript library because each framework handles scrolling differently.

This code works on iOS/iPhone and Android. Please don’t abuse this UI pattern too much. 🙂

Every web developer knows that browsers have a max number of concurrent connections that can be opened to a host at a time. Modern browsers have anywhere from 6-8 per host. You can test this on my simple concurrent connections test page. Open the link and wait ~3 seconds and count the number of boxes you see with content. If you’re in Chrome or Firefox 3+ you’ll see 6 boxes fill up at a time.

Mobile browsers are exactly the same except iOS 4 and Android 2.2 (Froyo) allow 4 concurrent connections. Surprisingly, iPhone OS 3.x allows for 6 (this includes the iPad with 3.2). I’m not exactly sure why Apple decided to drop the max concurrent connections but 2 less connections per device would lessen the load on operator networks (*cough* AT&T).

I don’t have any older Android or iPhone 2.x devices lying around. If anybody has any, feel free to use my concurrent connections test page and post the results in the comments. I’ll update once I get my hands on some more devices next week.

From Tapulous Blog, founder Bart Decrum:

As part of Disney Interactive Media Group, we’ll develop more games, more quickly and with the resources of the world’s leading entertainment company.

Congrats on the exit, it appears Tapulous went in the right direction after former co-founder Mike Lee left. Lee’s vision of useful apps, (remember FriendBook and Twinkle?), was beat by numerous TTR clones.