« March 2010 | Main | June 2010 »
May 21, 2010
My new bike is on the way
Dan and the good folks over at Dutch Bike company in Boston are hard at work on my new Swift. I am SOOOO excited to get it!
Check The DBC website while major renovations progress... *
*www.dutchbikes.us <http://www.dutchbikes.us> Let us know what you think.
*The Dutch Bicycle Compa**n**y* 161 Broadway | Somerville, MA 02145 | USA | 617.591.1234 | skype name: dutchbikeshq | www.dutchbikes.us <http://www.dutchbikes.us/>
Posted by Martin at 1:55 PM | Comments (1) | TrackBack
May 20, 2010
The heavy hand of Groupon
I have been in the technology business for a very long time. There is always a darling of the moment. One such darling is Groupon (disclosure my company Tippr is in competition with them). I am always intrigued by how many of these darlings screw up their position and customer good will by being heavy handed in some clumsy way. Facebook is getting the riot act recently over their heavy handed Privacy Policy changes. Google has lost some luster over collection of the geocode of your home WIFI (and sucking some data) without your consent. Groupon seems to still be in the honeymoon phase, but there are an increasing number of cracks starting.
Most people saw that Groupon was sued in class action for violating consumer protection laws and quickly settled it with an offhand joke. I don’t tend to think flaunting consumer protection laws is a joke.
Three more came through our merchant calls at Tippr this week that the general public doesn’t know about yet. I am just here to help.
First up: the “Groupon Platinum Partner program”. Google it and you will find nothing. It is not on their web site, not in any of their press. Because it is a 24 month exclusive contract with a Merchant that locks out any other group buying or on-line promotion partner for the merchant. The terms would make Microsoft lawyers proud. Merchant signs up for 24 months to only offer daily deal promotions through Groupon. Groupon pays a spiff in the back-end if the contract is upheld. Now of course any two businesses can decide to have an exclusive relationship anytime they want. But this contract goes beyond the pale in terms of penalties on merchants and the scope of exclusivity. What if Groupon underperforms your expectations, would they sue? Are you allowed to cancel? Good questions. Locking in your merchants with lawsuits is very heavy handed.
Next up: “I’m from Groupon and I am here to sue you”. Groupon’s merchant contract used to say you can’t run a better deal within 60 days of running on Groupon. Now that there is real competition (Tippr, etc.), it says you can’t run ANY deal within 60 days of Groupon. Yesterday over at Tippr Boston, we featured a great local merchant. They ran a Groupon 58 days ago. 2 days to go. A lawyer from Groupon called and threatened to sue to recover all revenue paid to from Groupon during their last promotion. Did I mention it was only two days? Way to build merchant trust guys. Tippr of course does not have the exclusive language, only the “better deal” language. Tippr took down the offer as a service to our merchant, and are looking forward to featuring them again soon after Groupon’s lawyers cool off. Made me smile a little that Big Boy Groupon cares about little guy Tippr.
Frequent readers already read my Groupon API rant. Again, heavy handed “you must follow Groupon’s view of the world and can’t show my deals with anyone else’s” tactics. Developers are significantly limited in what they can do with the data. They are also restricted from showing Groupon deals along side any other deals (like all the aggregators are doing). That is basically putting yourself above the fray. Fine, you are the big dog you can do that. But don’t try to put on a happy friendly face and expect to get credit for being a good corporate citizen because you are not.
I appreciate Groupon’s trail blazing efforts to expand awareness about group buying. Keep executing your don’t play nice with others or merchants strategy. I think it is a winner.
Posted by Martin at 2:54 PM | Comments (1) | TrackBack
May 17, 2010
iPad initial thoughts…
Ok, I have had two weeks with the Ipad. My Twitter followers have already gotten a tweetful, mostly about the various ways the device is crippled. Well here are my thoughts somewhat organized:
SUMMARY:
A cute device that i will keep (reluctantly) mostly for mobile consumption of a limited number of applications, mostly entertainment focused. This device does not replace my laptop (sadly) because it lacks full browser functionality (Flash, Silverlight, etc.), can’t save or edit documents effectively, and lacks sufficient storage.
Biggest regret: This is ONE MORE THING TO CARRY. I was hoping it would replace something. It replaces nothing and doesn’t do enough unique things to earn love as a device. I carry it grudgingly.
LIKES:
- Great form factor. Typical high quality Apple design.
- Netflix over 3g/Wifi RULES. This app alone makes the device worth it as a mobile entertainment device. Just replaced my DVD player on car trips.
- Mail and calendar are finally integrated in an interesting way. You can see in calendar the threads related to that appointment. Cool. Mail alone is a good implementation. This device is way better for mail than the iphone.
- Many of the Iphone apps I have used have been upgraded to take advantage of the larger screen and improved functionality. Like Analytics HD. WSJ, Kindle ans of course Suzie’s Sushi.
- 3G makes the device useful. Data plan is affordable.
- Scrabble. Love it. Best app yet (after NetFlix)
DISLIKES:
- Read all my posts on #ipadfail on twitter. The biggest issue is the fact that EVERY DAY i find a new site that doesn’t work well on the iPAD. This is not just a couple sites. This is not just the lack of FLASH. This is 90% of the web sites that I use are crippled in some way. The problems fall into four broad categories
1. Lack of Flash support. So many sites use it. Come on Steve.
2. Lack of certain tag support. Like what I need to edit documents in Google Docs (contenteditable). Really? Yea it might be in 4.0 release, but come on. (Thanks @lindvall for the clarification)
3. Random missing stuff. When in google apps through Safari on the iPhone I see all the apps including Tasks. on Ipad, no Tasks on the menu. why? Lots of sites are just missing certain options. I think it is probably because the site recognizes the iPad and turns off certain features not supported, but this is annoying.
4. Touch vs Mouse interaction incompatibilities. I expect to be able to do everything with a touch device that I can with a mouse. Silly me. For example, the click and drag you would do in BaseCampHQ to reorder a task on a to-do list. Not supported in touch. No click and drag.
- IPad apps are too expensive. Many are not upgrades from the iPhone but have the upgraded price. I know the iPad software is cheap compared to desktop software but remember, this is not replacing my laptop/desktop. It is a playtime device like the iPhone. Apps should be priced like entertainment, like the iPhone.
- Need more native apps. This will come I am sure. Or maybe not, if many people don’t find a place in their bag for this new device.
- Sync of music and movies is hard when my library is 2TB and the device is 32gb. There are not good ways (without reordering your whole library) to sync just a few things.
WISH IT HAD:
- camera
- more memory
- real productivity apps
Posted by Martin at 7:39 AM | Comments (2) | TrackBack
When is an API not an API?
Ok, I will say right up front that this is going to be somewhat of a rant. As my Twitter followers know, when I see a product crippled in obviously selfish ways (#ipadfail), it hits a particularly sore note with me. Over the weekend I found yet another such product.
Over @Tippr we are in the final stages of developing our API to allow third party developers to take our local deals and use them in their own applications. At a technical level, an API (Application Programming Interface) is simply a structured way for programs to communicate with standard information calls to receive standard structured data. Overlaying the technical details is the fundamental idea of openness and all the Web 2.0/3.0 “we are all in this together” love. When you say “my application has an API”, most people will give you props for being part of the love. When you tie lots of strings to that API, or cripple access to important parts of data, you have broken a core tenant of the implied API code. You have broken trust. Developers will figure this out. I don’t understand why companies provide API’s if they then cripple through the TOU the use of the API/data so much that it makes the API useless.
OK, now to the fun part, the guilty party (ack call the lawyers): Groupon. Check out some of the terms in their API Terms:
“You agree that you will not, and will not assist or enable others to:
- cache, record, pre-fetch, or otherwise store any portion of the Groupon Content, or attempt or provide a means to execute any “bulk download” operations;
- modify the Groupon Content, or use it to update or create your own database of business listing information;
- create or disclose metrics about, or perform any statistical analysis of, the API or Groupon Content;
- use the API on behalf of any third party;”
So what does this mean for a developer using the Groupon API?
1. Their application can’t do any caching which could include Groupon data. Caching is an important performance tool for every application I have ever developed. Having to fetch Groupon data on every page load could cause serious performance problems.
2. You may not store any Groupon content in a database of “business listing information”. Humm can’t store data I get from your API in a database, can’t cache it. Now what can I do with it?
3. You may not do any statistical analysis of the API or content retrieved therefrom. So I can’t say create an application which aggregates daily sales from Groupon across my state and shows trends? I can’t use New Relic to measure the response time of the API calls to Groupon’s servers. I can’t even use Google analytics to track the API calls. Back to the data, my application can’t do any statistical analysis of “Groupon Content” at all. Like say showing sales trends, pricing trends, category trends, geotag bucketing, category analysis, pretty much any kind of analysis which might add value to the “content” delivered through the API. So why is my application retrieving this data again?
4. A software developer may not use the API for their client. That would be “using the API on behalf of a third party.”
Well you say, there may be legitimate technical reasons for all the above legal gobblygook like Groupon wants you to always have the most up to date information and doesn’t want competitors scraping their site, and yes I can make a long list of excuses too. But wait, there’s more. Yes because Groupon is fundamentally all about building a consumer brand and protecting it, there is an additional little missive from their lawyers happily entitled “Groupon Branding Requirements”. I will have to admit this is the first time I have seen this level of hubris from any company. Just a few choice snippets.
“If you’re only going to recreate the functionality of Groupon’s own web site or mobile apps, save yourself the trouble and just put up a link.” Ah, now that’s how you motivate a developer community!
“Don’t aggregate our deals with other providers.” Humm but my application is actually trying to provide consumer value. A major way of doing that is compare/contrast and help navigate the various daily deal site data. Oh, but Groupon doesn’t want that level of scrutiny of their deals.
“Wherever you display our content, you must prominently display our logo.” I don’t have problem with credit, but the logo’s come with minimum sizes that are quite large and have specific color schemes that may not work with my application.
After reading all the documents and requirements around the Groupon API it is clear that they have take the “my data and brand is more important than your application” approach to their API. That is fine. Good luck with that.
Posted by Martin at 6:57 AM | Comments (1) | TrackBack