This looks great, what a good idea! I’ve often found too many pins on iOS maps annoying to deal with (most recently in the app "Eat Street"). I’ll definitely keep Superpin in mind for any future map-based iOS projects.
I expect the binary-only version will account for most of your sales, since it costs 75% less. Sales of the source version might depend on whether that version also includes the right to modify it and redistribute your custom version in your own apps, or is just a look-but-don’t-touch license. You may laugh, but people do try to sell that. Which is it?
Thanks, I'll have to try out the demo. I don't have an iOS device available, but I should try it out in the emulator. Also, when I touch a cluster, does the map zoom in and show the pins in the area?
This behaviour is implemented with few lines of code in the sample app, but we should probably make this the default behaviour in the framework itself with an option to override it.
I'm an iOS developer and I have 3-4 location-based products. Maybe I'm just not in your target market, but this component doesn't solve any problem I have. Seeing a bunch of dots that change places every time I zoom in is visually jarring and not very helpful. Only in rare circumstances would I prefer this visualization over seeing all the pins.
Now if you did a heatmap-type visualization, or had something that crossed over more smoothly between "wide angle" and "close up" zooms, I would be interested--that's actually a problem I would pay something for. But I would be more interested in seeing the component large-format: iPad or Mac or Web. Dashboard-type visualizations to monitor global infrastructure or something. Because people aren't going to do a ten-inch pinch on a phone, they just want to see the ten coffee shops on this street, and notation groups aren't needed for that. But I might want to visualize the whole world's tweets on a ginormous zoomable kiosk or do it in a presentation or a dashboard of my customers or something.
Quite frankly I'm happy to pay for a UI component but I want the vendor to have put in the time and effort to think about the UI so that I don't have to. All the iOS APIs have a lot of thought put into the UI (pages and pages of rationale in the documentation), and for a premium component that's your entry bar. Grouped annotations sounds like the way I would initially try to solve this problem, would prototype it and realize that it didn't work, and then try heatmaps. Maybe heatmaps won't be an effective metaphor either. The value a good premium component has on iOS is NOT that it's a cheaper component, but it takes out a lot of design risk, a lot of bad prototypes. The point is, I'm willing to pay great money for a great UI, and no money for a mediocre one.
The problem with your pricing is that the binary people will need more support from you than the source code people (who can fix the problem themselves, and optionally send you a patch). You need to price a few hours of support into the low-end product especially, so $150 is too cheap. I might just drop that product, as the source product is priced about right and is also a lower support burden.
I'd be really interested in hearing how Sales of this framework either A) Are going currently or B) How they go eventually (if you are just launching this).
I've developed some nice components and libraries for iOS and I'm just wondering how successful one can be selling these. I'd love to hear more about this aspect.
Binary-only version? $599 for the source code? Seriously?
(edit) To reprhase -- the pricing is basically broken.
No developer in his right mind would create a dependency on 3rd party binary library, so the binary-only version is a no go (or you will sell it to the clueless bunch and they will hammer your support to death).
The $599 needs to be broken down into multiple categories depending on the projected usage and/or deployment numbers. A very cheap ($19 or thereabouts) non-commercial use license is a must if you want devs to tinkle with your library and see if it fits their prototypes well. Then give them N days to upgrade to the commercial license if they decide to publish the app. And even then offer tiered licenses. Any given app may or may not get traction in the AppStore, so paying $599 upfront is to assume that the app will succeed. Bind the licensing terms to the number of downloads, and require upgrading one tier up once certain number of downloads is reached... this sort of thing. Essentially try and assume your customers' position and see what pricing model would work (while keeping smaller dev shops in mind).
Red Laser is doing something similar, and being on the other side (we were developing an app that needed to use barcode scanning) I strongly disliked the idea that I have to share my sales data with them. There are also cases where agencies are doing development for their clients and have no overview over sales once they finish the app. Communicating to clients that they have to pay % of sales to some library vendor might be very hard.
Superpin is not an app, and even as a component (in difference to something like an flash/ActiveX chart component) it has a very limited market (iOS devs doing something with maps and needing to handle lot of annotations) and with sale volumes we're projecting, pricing it down to something like $19 would never pay off for the time that went into developing it.
Clustering annotations is not all too hard, but it's certainly not a trivial problem and it will take even an experienced developer (such developer should be charging at least $100/h) a day or two to do it right. If you can buy a well-tested off the shelf solution for this money, why not do that instead? This is basically the thinking behind our "big" price.
$19 is for a license that allows playing with the library, but not publishing the app. A preview license if you will, just to let people see if your stuff is what they actually need.
> If you can buy a well-tested off the shelf solution for this money, why not do that instead?
Sure, but who is to say that it is well-tested? That's exactly what the preview license is for. But all in all, gotta tell you that you have a tough task in front of you. What do you think the size of your target market? I am going to guess that it is quite limited (in fact, you said it yourself), so your best bet here is to try and land a sale to a very large developer or into a massively popular app. In either case you need tiered pricing to fully utilize the opportunity. Think about it. Been there myself a few years ago trying to sell sophisticated networking libraries (that is a much larger niche than yours) and it is tough, really tough.
You believe your little iOS component is worth $150-$600? That's about as much as someone would pay for a fully-featured 3D game engine, something that thousands of man-hours went in to making and that does an incredible ammount of work for them-- and you're saying that a 1-week iOS component is worth that?
23 comments
[ 2.6 ms ] story [ 50.9 ms ] threadI think the price is very fair.
I'm sure Apple are going to steal this eventually, though. :)
Though there's a part of me thinking the designers for Classics.app asked Shipley for permission, but maybe that's incorrect. It's just a feeling.
Btw, if you've got any questions don't hesitate and mail me at martin@getsuperpin.com
I didn’t know there were that many airports in the world!
Now if you did a heatmap-type visualization, or had something that crossed over more smoothly between "wide angle" and "close up" zooms, I would be interested--that's actually a problem I would pay something for. But I would be more interested in seeing the component large-format: iPad or Mac or Web. Dashboard-type visualizations to monitor global infrastructure or something. Because people aren't going to do a ten-inch pinch on a phone, they just want to see the ten coffee shops on this street, and notation groups aren't needed for that. But I might want to visualize the whole world's tweets on a ginormous zoomable kiosk or do it in a presentation or a dashboard of my customers or something.
Quite frankly I'm happy to pay for a UI component but I want the vendor to have put in the time and effort to think about the UI so that I don't have to. All the iOS APIs have a lot of thought put into the UI (pages and pages of rationale in the documentation), and for a premium component that's your entry bar. Grouped annotations sounds like the way I would initially try to solve this problem, would prototype it and realize that it didn't work, and then try heatmaps. Maybe heatmaps won't be an effective metaphor either. The value a good premium component has on iOS is NOT that it's a cheaper component, but it takes out a lot of design risk, a lot of bad prototypes. The point is, I'm willing to pay great money for a great UI, and no money for a mediocre one.
The problem with your pricing is that the binary people will need more support from you than the source code people (who can fix the problem themselves, and optionally send you a patch). You need to price a few hours of support into the low-end product especially, so $150 is too cheap. I might just drop that product, as the source product is priced about right and is also a lower support burden.
I've developed some nice components and libraries for iOS and I'm just wondering how successful one can be selling these. I'd love to hear more about this aspect.
(edit) To reprhase -- the pricing is basically broken.
No developer in his right mind would create a dependency on 3rd party binary library, so the binary-only version is a no go (or you will sell it to the clueless bunch and they will hammer your support to death).
The $599 needs to be broken down into multiple categories depending on the projected usage and/or deployment numbers. A very cheap ($19 or thereabouts) non-commercial use license is a must if you want devs to tinkle with your library and see if it fits their prototypes well. Then give them N days to upgrade to the commercial license if they decide to publish the app. And even then offer tiered licenses. Any given app may or may not get traction in the AppStore, so paying $599 upfront is to assume that the app will succeed. Bind the licensing terms to the number of downloads, and require upgrading one tier up once certain number of downloads is reached... this sort of thing. Essentially try and assume your customers' position and see what pricing model would work (while keeping smaller dev shops in mind).
Superpin is not an app, and even as a component (in difference to something like an flash/ActiveX chart component) it has a very limited market (iOS devs doing something with maps and needing to handle lot of annotations) and with sale volumes we're projecting, pricing it down to something like $19 would never pay off for the time that went into developing it.
Clustering annotations is not all too hard, but it's certainly not a trivial problem and it will take even an experienced developer (such developer should be charging at least $100/h) a day or two to do it right. If you can buy a well-tested off the shelf solution for this money, why not do that instead? This is basically the thinking behind our "big" price.
> If you can buy a well-tested off the shelf solution for this money, why not do that instead?
Sure, but who is to say that it is well-tested? That's exactly what the preview license is for. But all in all, gotta tell you that you have a tough task in front of you. What do you think the size of your target market? I am going to guess that it is quite limited (in fact, you said it yourself), so your best bet here is to try and land a sale to a very large developer or into a massively popular app. In either case you need tiered pricing to fully utilize the opportunity. Think about it. Been there myself a few years ago trying to sell sophisticated networking libraries (that is a much larger niche than yours) and it is tough, really tough.
I mean this in the most sincere way, good luck.