As a co-founder of ITA Software (travel search) and founder of the company that makes http://inky.com (email), I often see unexpected parallels between travel search and email. In both spaces we get periodic design documents and slide ware that look really cool and get everyone all excited. But in both spaces these designs rarely get implemented, much less reach production.
The reason is that the domain details are so extensive and difficult that almost nobody can get past them. I like to describe both these problem domains as "fractal," because when you're 100,000 feet up it looks pretty simple, but the closer you get the more details there are. If I had a dollar for every hacker who told me how easy it would be to make a travel search web site or an email client, I'd be rich.
In both spaces, a very small number of players create the core technologies, and a much larger set of players layer on top of these cores. In travel, for example, you have the GDS companies (Sabre, Amadeus, etc.), ITA, and Expedia. Everybody else -- literally, everybody else -- layers on top of one these systems. Kayak? ITA customer. Hipmunk? ITA customer. Etc. This means the vast majority of players don't actually have to deal with the fractal domain complexity. And almost nobody has any clue there's any difference between say, an ITA and a Hipmunk, even though one has a million lines of code and runs thousands of machines and the other has a fairly standard website. (#)
Similarly, in email, a handful of players create real mail stacks. These are the usual suspects (Microsoft, Google, Apple, IBM) and a handful of others (Inky, Sparrow, Thunderbird) Everybody else -- literally everybody else -- layers on top of GMail or Outlook. Mailbox.app? Layer on top of GMail. Xobni? Layer on top of Outlook. Postbox? Fork of Thunderbird.
In the mail space, there are at least some decent open source libraries to use. In the travel search space there is literally nothing to start from but a blank sheet of paper. Carl de Marcken did most of the early work figuring it out for ITA, and it nearly killed him.
I actually seek out domains like this; either because they're defensible, or because I'm insane. I'm not sure which yet.
(#) If you're thinking it's necessary or even better to own the million lines of code and run thousands of machines, think again: Kayak created substantially more value for its shareholders than ITA did, with a lot less effort.
I imagine it's a similar problem to online payments. From 100,000 feet payments looks like shuffling bits around and keeping track of them. And in some sense it is. But in reality that technical problem is maybe only 1% of the business, the rest is things like customer service, fraud protection, auditing, regulatory compliance, relationships and integration with other financial companies, relationships with governments and law enforcement organizations, etc. Each of which is a hugely different problem and vastly more difficult. The funny part is if you translated the problem to the physical realm few people would fool themselves into thinking that a bank could be reduced to little more than a ledger.
I actually disagree. I think getting users is a subproblem of creating a MVP (Minimally Viable Product), which is incredibly hard in these spaces. You can't get users unless you have an MVP. But what if your MVP takes 1000 person years to create? (That's not the case for email or a travel web site, necessarily, but certainly is the case for an airline reservation system... or a web browser.)
Remember Vonage? All they had to do was offer an MVP for voice phone. But it turns out that if a customer picks up the phone once a month and doesn't get a dial tone and a clear connection, they're going to abandon you.
The Lean Startup wisdom about focusing on an MVP and getting to market fit is absolutely right. The issue is: what exactly is the MVP for your space? Not all MVPs are equally easy to create. Try creating an MVP for a nuclear reactor, for example. Well understood tech? Yes. Easy? No.
<a href="mailto:mail.added@by.js" />
some
<span style="display: none" />☃</span>
person@gmail.com
</a>
And here I can either click the link or copy the text and it isn't all messed up. A simple function can easily generate that HTML for any email string.
You're being downvoted with no explanation. The issue with that is that your email address is easily harvested by combing through websites. The comment above yours is describing a way to get around this by obfuscating the email address in HTML and using CSS trickery to get it to show normally.
Clicking that link to inky.com, I had to roll my chair 2 meters backwards to view that screenshot without getting the feeling it's pushed into my face. Large fonts and design is great, really, but in my personal opinion this is too large.
Edit: And I hear from others that they can actually download it. I was looking for "where the hell is their call to action, can I test it somewhere?" but there is just nothing. Turns out that Windows users do get a download link, and Linux users are told "shut up you are not supported and we have no clue that humans invented emulation software that might just work, or at least tell them they can try it in a Windows VM".
You have a point. The question for us is: do we want to promote Inky under Wine as a supported platform? Since we don't run it that way ourselves (ever), we're not terribly comfortable doing that.
We do have the core running under Linux and are working on getting the UI up under Linux. We'd really like to have Linux Inky for ourselves, if nothing else, because Linux offers the best environment for dev/debugging. So it's coming. :)
> In travel, for example, you have the GDS companies (Sabre, Amadeus, etc.), ITA, and Expedia. Everybody else -- literally, everybody else -- layers on top of one these systems.
I thought Southwest was known for having their own system. Under the hood are they actually using a Sabre, Amadeus, etc.?
I actually seek out domains like this; either because they're defensible, or because I'm insane. I'm not sure which yet.
I see this quite a bit. In fact, I strongly believe there are only two types of businesses that make competition improbable: A) those that pick normal problems, show up to the market early, and price to discourage competition, forever locked into low margins, and B) those that choose incomprehensibly hard problems and solve them better than anyone else.
So do you see this concept as a better or worse Kayak? I feel that google has done the best job with flights and they are my go-to location. This concept seems great for trips, but I'm not sure how many people per year are flying for a vacation vs flying for necessity.
There are lots of great ideas here, and the design is lovely. But my guess is that many of the design concepts would disintegrate when intersected with the practical considerations of actual airline data and systems.
Totally random side note: my friend Jason Rubin (co-founder of Naughty Dog, which I worked for in the mid 90s) suggested the map-with-flight-path-arcs representation when I showed him prototypes of QPX, ITA's travel planning system, circa 2000. I like the idea visually, but in practice it gets messy (think around-the-world trips).
Yeah I didn't really think of the around the world use case. At that point, you'd need to change the visualization to a globe which would probably confuse most travelers.
The reason is that the domain details are so extensive and difficult that almost nobody can get past them. I like to describe both these problem domains as "fractal," because when you're 100,000 feet up it looks pretty simple, but the closer you get the more details there are. If I had a dollar for every hacker who told me how easy it would be to make a travel search web site or an email client, I'd be rich.
In both spaces, a very small number of players create the core technologies, and a much larger set of players layer on top of these cores. In travel, for example, you have the GDS companies (Sabre, Amadeus, etc.), ITA, and Expedia. Everybody else -- literally, everybody else -- layers on top of one these systems. Kayak? ITA customer. Hipmunk? ITA customer. Etc. This means the vast majority of players don't actually have to deal with the fractal domain complexity. And almost nobody has any clue there's any difference between say, an ITA and a Hipmunk, even though one has a million lines of code and runs thousands of machines and the other has a fairly standard website. (#)
Similarly, in email, a handful of players create real mail stacks. These are the usual suspects (Microsoft, Google, Apple, IBM) and a handful of others (Inky, Sparrow, Thunderbird) Everybody else -- literally everybody else -- layers on top of GMail or Outlook. Mailbox.app? Layer on top of GMail. Xobni? Layer on top of Outlook. Postbox? Fork of Thunderbird.
In the mail space, there are at least some decent open source libraries to use. In the travel search space there is literally nothing to start from but a blank sheet of paper. Carl de Marcken did most of the early work figuring it out for ITA, and it nearly killed him.
I actually seek out domains like this; either because they're defensible, or because I'm insane. I'm not sure which yet.
(#) If you're thinking it's necessary or even better to own the million lines of code and run thousands of machines, think again: Kayak created substantially more value for its shareholders than ITA did, with a lot less effort.