Someday we may fail to find the images we need on istockphoto. But not today.

Revised: yet another great service ruined by corporate greed… dramatically higher prices, confusing credits.

Huge selection of photo and vector art, good search/lightbox capability, ~~low cost~~, essentially unlimited use (for many purposes), ~~easy pay ‘n download~~.

My favorite feature? Ability to download reasonably clean watermarked comps so we can play around with storyboards and mock-ups until we decide exactly which ones to use.

~~What’s not to like?

Web CSS templates that did not disappoint…

Often a friend will ask me to help them with ideas for their website. Most of the time a turnkey pre-built website offered by most hosting providers will suffice, so that’s what they end up doing.

But last week a friend needed help with a site that needed some flashy storyboard/slideshow features and it all needed to look very nicely crafted. But spending hundreds of dollars (if not thousands of dollars) on the website just wasn’t in the cards.

Thus began my first-ever descent into the world of ready-to-go web templates. It was actually quite interesting.

I won’t even address the zillions of sites offering “free templates” other than to say from what we saw (after looking at hundreds of examples) you (a) get what you pay for and (b) you cannot even tell what you are/aren’t going to get because most sites have a single graphic preview that, well, fails to show how poorly the page source code is designed.

So the bad news is, if you’re serious enough about your website to spend the time to create it, you’re going to pay something for the design.

The good news is, for $50 you can have a selection of nearly 1000 unique designs in 3 or 4 color variations each with all kinds of interactive javascript goodies pre-baked such as sliders and slideshows. In fact, for $50 (one time, not a recurring fee) you can download as many as you want, although limited to 20 per day. (This was helpful because my friend used one template for his site, but downloaded a few other templates just to copy/paste some cool style/javascript goodies from other sites… mix n match.)

For example, my friend went with then modifed the images and tweaked some of the colors.

Curious about the quality of the template implementation I rolled up my sleeves to help my friend tweak his site. His modifications were easy to do because, by golly, the template CSS is properly designed, documented, and then used in the 9 pre-built sample html pages — we did not see a single example of someone manually over-riding the stylesheet, which we often saw on the “free” templates.

**Plus support! ** Saturday evening we we sent an email asking how to turn off the automatic advance between slides on one of the javascript gizmos the template included. Got an email back an hour or two later.

$50. One time. Instant online activation/download permission. With support. Wow.

Great support from a surprising corner: Godaddy

Actually it’s not surprising, their 24×7 support is excellent, and they have mastered the art of turning support calls into selling updates, renewals, and upgrades.

But yesterday was interesting. I called about a slight issue I had installing an app on a domain. They answered within 3 minutes and answered my question, stayed on the phone while I did it, then explained what the next steps would be as the app was automatically provisioned (database created for me, etc., etc.).

About 5 minutes after the call, the same guy called me back, saying he was reviewing the progress and noticed my DNS setting still had the domain forwarded and explained what I needed to do now so I would be able to access my app once the provisioning was complete.

Color me impressed for such proactive support!

Lemons to lemonade when the airline strands you

I always though this was kind of obvious, but a number of friends thought this was clever so I’ll pass it along…

Last week I was supposed to return from NYC (Newark, the *only *airport to use when flying to/from NYC) via Denver back to Spokane. Weather delays the morning of the flight meant not only would we miss our connection in Denver, we could not get a flight the next day either. So we’d be stranded in Denver, on our nickel (no vouchers, since weather delay).

When that happens, I look at the upcoming flights, pick a place I’d much prefer to be stranded instead (San Francisco in this case), and without exception I get the flight I want if (a) there are seats and (b) if it’s closer to my destination than where I’m starting from (e.g., the right general direction) and (c) I point out they won’t be giving me vouchers so the least they can do is send me where I have friends to stay with.

So the next day, my daughter and I had a nice day in San Francisco, saw some friends, ate some dim sum and tapas… essentially a free round-trip for two to SF compliments of United.

Squeeze that lemon.

Outsourcing success tidbits

Last year we did a pretty cool “local O2O” (Online-to-Offline) project with a local TV station. The budget and timeframe were tight. And this project simply *begged *to be done with Ruby on Rails for a host of reasons.

We came in on-time, on-budget, with an exceptional end result after using to find a team in India.

Aside from insisting on and talking to references and seeing sample work, here’s a few tidbits we learned about making that work. To get a good bid (always go fixed-price) you have to have a good spec. Some keys include breaking the project into Phases, starting with a clear spec for Phase I, breaking that into at least 10 milestones. Some ingredients for a good spec are:

  • A full database schema. A fuzzy idea of the database, and/or turning the schema design over to anyone who’s not proven to be exceptional at it, is a train wreck. I repeatedly heard from good developers that a well-designed database lets them bid one-third to one-half of what it would cost otherwise. Take the money you’ll save and invest it in the schema design.
  • **Mock up screens. **You can not rely upon text, you have to show the fields, the buttons, etc. (It’ll help solidify your thinking, too.) Let me say this. The only three spots where we ran into ambiguity issues were the three places where we played a little loose on the sample screens, thinking it was “obvious” what those screens would look like.
  • Spec the environment. If it has to run on Heroku, make that clear.
  • Spec the unit tests. Contract developers in my experience do lousy job at this unless unambiguously required to do it right. And it’ll cost a lot less if part of the original bid than if you say later “oh hey, what about hitting X% unit test coverage.”
  • Include 2 or 3 major “gotchas”. Purposefully put at least 2 or 3 things into your spec that don’t make a lot of sense or contradict other elements of the spec. See who catches that. It’s instructive in picking a development team. As a trivial example, suppose part of your spec you’re going to run at Heroku. Put some aspect in your spec about storing files in some folder on the website. If they know their stuff they’ll immediately point out Heroku has no local file system, that you’ll probably want to push files over to S3. It’s a fair test IMO, because those sort of gotchas will happen anyway, so you’re entitled to ‘test’ developer’s ability to catch them before they spend you money writing code that won’t work.
  • Daily involvement. Generally, the closer you can come to full time co-involvement, the better the results. We setup a testing tag-team to test every feature as it was implemented, and actually designed the spec for incremental development and testing.
  • Spec comments and readability. I’m all about comments (lots) and code clarity (not using every cool shortcut the language offers, favoring understandability by humans over saving a few CPU cycles.) I provide examples of obtuse but fun little shortcuts that I don’t want to see, and the old fashioned way I do want to see it done instead. If I really wanted uber-dense tight code I’d go back to doing it all in APL or Forth. What I want is code anyone can look at and understand months from now.
  • Git / github. If you aren’t using it, do.
  • **Daily code review. **Review code as it’s checked in. Catch bad habits early.

Obviously that’s the tip of the iceberg, but those simple tidbits saves us a lot of time and hassle.

IMO Tropo not ready for prime time. Went with Twilio.

Subtitle: “When you are betting your ass on a platform, if you have a choice of platforms, bet on the company that *has *to deliver an actual working solution to survive, not on a company for whom the platform is an interesting diversion from their core business.”

I like the folks at Voxeo a lot. But I had to shut down an earlier business because their business model of paying per-port per-year is unworkable for a business with significant peaks and valleys in usage. (The business was a voice message broadcast system for schools, etc., where virtually all of the user activity happens within fairly narrow time frames. But after a short eval period we had to pay for ports 24x7x365 even though our customers’ usage occurred during perhaps 10% of a typical week. And since users expect messages to go out in a timely way, simply having 1/10 as many available channels was not an option.)

So I was very excited a year or two later when they introduced Tropo, cloud based telecom with no per-port fees, pure pay-for-use business model. even though it was too late for the prior business.

When a new project that required voice and SMS came along, I thought Tropo would be perfect. But Twilio looked interesting as well. We built a fairly significant app that handles inbound and outbound voice calls and SMS, and looking at the claimed features, Tropo looked like a hands down winner. Nonetheless, we architected the product to be relatively platform neutral “just in case.”

Once again, my belt-and-suspenders approach to app architecture paid off because Tropo was a lot of cool things, but “ready for prime time” is not among them.

Going into the project, here’s what initially convinced us to incorporate the Tropo platform:

Supposed advantages of using Tropo over Twilio:

  1. Tropo is based on Voxeo, a mature and highly profitable company/technology, Twilio is a startup
  2. Tropo has voice recognition, Twilio doesn’t
  3. Tropo apps can (supposedly) send/receive tweets via an associated Twitter account, allowing you to (supposedly) build very cool automated Twitter apps. Twilio doesn’t. In fact, when you go to their headline reads “Add Voice, SMS, Twitter, and IM to Your Applications”
  4. Tropo has 24×7 tech support, Twilio doesn’t.
  5. Tropo is (supposedly) more robust, built as it is upon the Voxeo platform.
  6. Tropo has a very generous “free for development” policy so you can get up and running without paying for phone numbers and messages.

We dabbled with both at first, to get our feet wet, then proceed to build our app on Tropo. Addressing each of those (supposed) Tropo advantages in order, here’s why we were absolutely compelled to switch to Twilio.

  1. The overall impression I got was that Tropo being a disruptive pay-for-use business model offered by hugely successful company is that, well, they’re just dabbling with this… that Voxeo has no current profit motive to make it work right… their mainline business is (a) doing just fine thank you and (b) might even be disrupted if Tropo works *too *well. That’s just my impression, but it’s based on the following:
  2. Voice recognition. This claim is actually true, although Tropo does not offer (built-in) the full range of VXML grammars that make voice recognition practical. And we found that ambient noise makes it unusable for Real World Apps if your users are commonly on cells, in restaurants, or cars.
  3. Twitter. UPDATE: This seems to have been fixed recently. So far so good. In my experience, attaching a Twitter account to Tropo app works for maybe one day. Then the connection to Twitter silently dies, and there is NO way to tell it’s happened. YouR app just stops receiving tweets. There is no API to verify or restore the connection. You have to remove the Twitter account, then re-add it, manually. But remember… you have no idea when your Tropo/Twitter connection is broken. We tested several Tropo apps, with several Twitter accounts, over several weeks and the results were absolutely repeatable… Tropo apps fail to respond to Tweets within a day or two. It just plain doesn’t work. And it’s not Twitter’s fault… another thing we tested was whether an app like Hootsuite would ‘keep’ it’s connection to Twitter persistently and during the same several weeks of testing, had zero problems with Hootsuite. Now, I’m all about ‘things will get better over time’ except… well… when the company’s *headline *says it works… it kinda needs to work.
  4. **Tech support. **Actually this was a tie. We’d send support requests at midnight and get a prompt “I’ll have someone look at this” reply from a human at Tropo, but the actual answers came faster from Twilio about half the time. And on some major issues (Twitter, ‘lost’ SMS messages) it took Tropo a week, even two to respond, whereas we never waited longer than a working day from Twilio.
  5. In our experience, Twilio is more robust, period. Let me count the ways: – UPDATE: this ‘feature’ was finally removed so they no longer opt-out your users for you. If your user texts the word STOP to your Tropo app, your app does not get to handle the opt-out… Tropo does it automatically, and silently throws away all traffic to that user. Your app never knows about it (neither does the user!), and for all you know your messages are going through. This is wrong. A telecom platform should *not *silently throw away messages. (Twilio doesn’t presume to opt-out your customers, they let your app do it so you can keep track of it!)

Tropo silently fails to deliver SMS messages if your app sends them too fast. And there’s no specific rate, just general guidelines of ten per minute. Twilio lets your blast them out as fast as it wants, then Twilio handles the rate limiting to 1 per second. In other words, Twilio is designed for reliable message delivery, Tropo is “best efforts” and (even worse) does not **inform your app when something went wrong.
– To simulate modest concurrent user loads, we wrote a two very simple tester apps: one app sends 10 SMS messages to another app. **We never, not once, got all 10 SMSs to make it on Tropo.
Twilio never missed a message. Tropo support said that’s strictly an artifact of apps-talking-to-apps related to their gateway, that it would not happen if multiple cell phone users were talking to, but…. would you bet your ass on that? (Me neither.)
– Tropo doesn’t have the very helpful callbacks Twilio offers that let you do post-sessions.
– There’s five more items on my list, but candidly, IMO the issues of Tropo discarding or losing messages, silently, under multiple circumstances, should be enough to cross them off any developer’s list.
6. Free vs pay-for-use during development. Tropo is free. Twilio isn’t. At Twilio a phone number costs $1/month at Twilio. Text messages or phone-minutes are 2 or 3 cents each. *Dude, if you’re building a business do you even **care **about $20 to $40 in telecom charges during a month of testing?* (Me neither.) What you do care about is building something that works reliably when your users use it.

So that’s why we are deploying based on Twilio, not Tropo. (Though we left our Tropo code in place for when they get it together on the message-delivery-reliability front, and get Twitter working, we’d love to use that feature.)

But the moral of the story is clear to me: if your providers aren’t betting their asses on doing a great job for you, you may not want to bet your ass on their services. Ditto hosting, web design, you name it.

What’s in a name?

“… as in … ‘howdy pardner’ … my parents had a real fine sense of humor” is a common refrain when meeting new people. True enough.

There’s at least one more… a gentleman in the Philippines, whose parents saw the Clint Eastwood movie Paint Your Wagon and naturally assumed Pardner was a perfectly normal American name. Who am I to throw stones? I named my second daughter Jemima after I first saw the name in the credits of a movie filmed in England. (When I say ‘first saw’, syrup bottles don’t count.)

And there’s an “almost” … a gentleman in southern Cal who goes by Pardner since that’s what he was called from birth, including by his godfather, Bing Cosby, who attended his baptism.