Startups are a constant battle against ever-increasing complexity. When you move to having multiple price options for your product, your complexity goes up. When you add an important feature/app, your complexity goes up. It’s one more thing to track adoption of. It’s one more thing you have to promote to your customers (so they know it’s there). It’s one more decision to make (should we include this feature in the free product, or use it to drive upgrades?). It’s one more hungry mouth to feed when you’re trying to allocate limited product/engineering resources. It’s one more row in your pricing/feature matrix. Every one of those things cost money. They just may not show up on your P&L on day one. They’re subtle and somewhat hidden, but they’re very, very real.
So, STOP! Before you just go add that feature because you know it’s going to help you drive more adoption, revenue, etc. Spend a little bit of time thinking through what the actual costs for this feature will be over its lifetime. You don’t have to analyze it to death, but it’s deserving of some time spent that is proportional to how big the feature is.
Quotes
Dropbox, on the other hand, was designed around files, both from a UI point of view and an API point of view. This means their file syncing is very, very good. If a file gets put into a Dropbox somewhere, it ends up everywhere quickly, basically with absolute reliability… If you’re building an app that needs to sync, that kind of reliability is exactly what you’re looking for… Apps can build better UI on those files whether they’re stored locally, stored in Dropbox, or stored in iCloud. But Dropbox has proven it’s reliability, and iCloud hasn’t.
So while there is an argument to be made that Dropbox’s UI is a relic, its value as a syncing engine is still huge, precisely because it’s built around the paradigm of files, a paradigm we have decades of experience working with.
Steve Streza, Files as UI vs API
As much as iCloud is the right idea still not realized, Dropbox is the wrong thing done brilliantly well. And at the end of the day, that still amounts to the wrong thing.
Those of us used to, and clinging to, traditional file systems love it, and will continue to love it as it becomes marginalized into obsolescence, as the growing mainstream — those who aren’t power users but are increasingly empowered users, and who won’t get it and shouldn’t be subjected to it — sweep past it and into newer, better things.
iCloud could be that better thing, if Apple can nail it. Big if. So could something else, including a new version of Dropbox. But nothing and no one is there yet. So, as iPhones and iPads and other appliances bring computing to a broader user base than ever before, the services that bind them remain stuck between the best-ever version of the past, and a still sputtering and stammering future.
Further investigation revealed that, in these places, the average page load time under Feather was over TWO MINUTES! This meant that a regular video page, at over a megabyte, was taking more than TWENTY MINUTES to load! This was the penalty incurred before the video stream even had a chance to show the first frame. Correspondingly, entire populations of people simply could not use YouTube because it took too long to see anything. Under Feather, despite it taking over two minutes to get to the first frame of video, watching a video actually became a real possibility. Over the week, word of Feather had spread in these areas and our numbers were completely skewed as a result. Large numbers of people who were previously unable to use YouTube before were suddenly able to.
I think this is something to remember when we’re coming up solutions to “dealing with” older versions of Internet Explorer: whether it’s a dumb solution like mine or a clever solution like Jake’s, we shouldn’t have to do this. We shouldn’t have to worry about IE7 just like we don’t have to worry about Netscape 4 or Mosaic or Lynx; we should be free to build according to the principles of progressive enhancement safe in the knowledge that older, less capable browsers won’t get all the bells and whistles, but they will be able to access our content. Instead we’re spending time coming up with hacks and polyfills to deal with one particular family of older, less capable browsers simply because of their disproportionate market share.
When we come up with clever hacks and polyfills for dealing with older versions of Internet Explorer, we shouldn’t feel pleased about it. We should feel angry.
So this is the dirty little secret in our industry. The best designers and developers rarely have more talent. They simply have more time.
Resolved, that the flag of the United States be thirteen stripes, alternate red and white; that the union be thirteen stars, white in a blue field, representing a new Constellation.
Flag Resolution, Second Continental Congress, June 14, 1777
But none of this answers the original question: why do we have an <img> element? Why not an <icon> element? Or an <include> element? Why not a hyperlink with an include attribute, or some combination of rel values? Why an <img> element? Quite simply, because Marc Andreessen shipped one, and shipping code wins.
Mark Pilgrim: Why do we have an IMG element? [dive into mark]
Comments. I got rid of them. I know this is going to be contentious. My current view on comments is I really don’t like them — at all, anywhere on the internet. I’m all for communication between author and reader, but comments are the lowest possible denominator. More often than not, they bring out the absolute worst in people.
Steven Frank (of Panic) on his self-authored blog platform (via marco) (via phonkmeister) (via )
mkg completely disagrees, loves comments, and can’t see why should anyone blog if he or shes not interested in what readers think.
I’m extremely intereted in what readers think—but many readers don’t think when leaving comments. Once in a while you get a really brilliant one—but it’s about 1% post spam filtering. Another 9% or so are arguably worth their bandwidth. If somebody leaves a comment you want to respond to, there’s no way to get in touch with them. Comments are to communication what bathroom stalls are to art or poetry. Once in a while there will be a real gem—but you’re usually better off combing through the monkey-typewriter transcripts.
(via squashed)
Bureaucracies are built by and for people who busy themselves proving they are necessary, especially when they suspect they aren’t.
Ricardo Semler (via marco)