App Stores StackExchange
I am a big fan of the StackExchange model of questions and answers. I participate on multiple sites (see my badge on the right). If you are still using traditional forums to try and get answers to your questions, you're really missing out. I am a developer so I use StackOverflow all the time, but there are plenty of sites related to all sorts of topics.
One of the really nice things about StackExchange is their willingness to develop communities based around nearly any topic. There's a process of following, definition, and commitment required to get any new community up and running to ensure it isn't just another dead site. This is all done on Area51 the StackExchange staging zone.
One of the new proposals I am pretty excited about is the App Stores site. It aims to fill in the gap with questions related to App Store deployment (Apple, Android, WP7, etc.) that aren't directly related to programming (StackOverflow) or design (User Experience). From the proposal:
Proposed Q&A site for developers who have questions about the technical and business aspects of submitting apps to App Stores and Markets. (Typically for mobile, but not exclusively limited to.)
There are a lot of things to learn when it comes to app development - regardless of platform. Once you've designed, created, and tested your app it can seem like you should basically be done. Unfortunately, the last few steps of actually distributing your app(s) can be quite challenging - especially the first time.
There can be huge delays as you try and sort through the layers of policies and requirements. Trying to use outdated advice from Google is extremely frustrating and it can be pretty stressful trying to figure out the dynamics of an App Store when all you want to do is get your app out there.
I wish this site had been around the first times we submitted to the Apple App Store, Android Marketplace, Amazon Appstore and the WP7 Marketplace. Each had it's quirks and surprises. If you've had experience submitting to or working with any app store, consider following and then committing to this proposal. Let's take the lessons we've learned and share them. It's a great idea and will be a fantastic resource - so check it out!
Pricing Your App (and is WP7 worth it?)
Setting the price of any product can be difficult. You have to balance the costs (development, licensing, maintenance, promotion, etc.) with what is fair to charge for your product, what the market will bear, competition, etc. Apps are no different. Unfortunately, there also isn't a lot of publicly available information on actual sales, historical trends, or successful strategies. Add to that that apps are a lot harder to compare to each other (in contrast to something like office furniture), and you end up with a lot of guessing, experimentation, and frustration.
One of the interesting things about the above Dilbert comic is that it contradicts the marketing campaigns of Apple, Google and Microsoft that imply anyone with a free weekend, some mild development talent, and a magical idea is practically guaranteed a million dollars. Can you make money developing apps? Absolutely. However, many starting developers and their mothers may be surprised to learn that there is a lot more to it than just making something that works.
I couldn't tell you the number of times people have found out that I am part of an app development company with multiple apps on multiple platforms and been amazed that I'm not making millions of dollars every month with all that sweet app money. After that there's usually a moment of awkwardness where they are trying to figure out how I screwed up something so obviously "easy".
It just isn't that simple. There's a lot that goes into a "successful" app that has nothing to do with traditional development. One of those things, is your app's price. You need great screenshots, marketing, luck, well written descriptions, reviews, more luck, etc., but if a customer isn't willing to pay whatever you're asking then, too bad. It's not my goal to discourage new developers/companies or to provide exact guidance on how to price your individual app. There are plenty of articles out there all about the "right formula" but I've not found them too helpful. What has been helpful are the few articles that give insight into specific experiences. I won't be giving out exact numbers due to licensing restrictions, but I still wanted to talk a little about our experiences with one of our apps, THE DOG.
THE DOG is a breed guide app featuring Artlist's beautiful and unique photographs of dogs and made in conjunction with 4Kids Entertainment. It is currently available for iOS and WP7 and the Android version will be available in the next couple of weeks.
We did some experimentation on the App Store (Apple) by setting our apps at a series of price points and comparing the number of downloads. Our guess was that at the higher prices we would have fewer downloads but higher overall profit. However, we found that the number of downloads was so much higher at $.99 that the profit was greater for that price point than any other.
We feel THE DOG is a quality app and well worth at least $4.99 considering that's a one time fee that includes lifetime updates, no ads, hundreds of photos, tons of information and more. We had some customers that agreed with us and purchased at that price and at the various prices between that and $.99 (Thank you!). However, even at $1.99 the number of downloads was less than half of what they were when we switched to $.99. Then considering that higher numbers of downloads leads to higher rankings within the store and therefore higher numbers of downloads and higher rankings... and so on, and it was a pretty easy choice for us to change the pricing.
I recently read this article, Microsoft Wants Expensive Apps on Windows Phone, and was a little conflicted. As a consumer of apps myself, I really enjoy the amazing low prices of some really cool software. But as a developer, I understand that the push from consumers for higher quality apps with more and more features, lifetime updates, beautiful graphics, and full social media integration all for $.99 or in many cases free - seems unsustainable (or at least unprofitable) using traditional development methodologies.
Overall, I like Microsoft's idea of increasing app prices (along with quality, integration, etc.) and am excited about the new opportunities with the upcoming Mango release, but the App Store has already set the trend that only truly exceptional or niche apps should be priced higher than $.99 if you are to have any sales. Perhaps while the Marketplace is still relatively small (currently 20,000 apps), higher price points will be possible. But with an influx of apps (competition) those price points are bound to drop.
Part of the problem for us developers is that none of the app platform companies are totally partnering with us. They are providing amazing platforms, great tools (for free in nearly every case), ongoing support, community interaction and more. But they are also taking 30% of all sales and $99 a year from developers, effectively making us their customers/employees.
This means they have to balance enabling our success (after all they make the most money when we do) with keeping up an image of huge opportunity for little investment to keep us all coding. This sometimes leads to misleading or generic statistics that can often lead to disappointment for the vast number of developers (even some really good ones). It's hard to know what to include, when to release, and how much to invest - let alone how much to charge.
Going back to THE DOG, we decided to port the app to WP7 to try and get in early while the competition was still low. Android and iOS have many dog apps, and while we are confident that our app is as good and in most cases better than those apps, it can be easy to get lost in a sea of apps that all make similar claims. In addition, C# and the development environment (Visual Studio) for Windows Phone was already very familiar to us and made getting started very quick and easy. Porting the app required a complete rewrite from the iOS version but was still considerably easier than starting from scratch. This made the required investment relatively small and a worthwhile experiment.
We assumed that since the competition was so low, app sales would be as good or better than the iOS version. The iOS version is doing very well, unfortunately, as of right now the WP7 version is not(?). Actually, it's hard to tell if our app is doing well (at least relatively) without base line numbers to compare it to. But from our perspective of the amount of sales needed to justify the costs (let alone show a profit), it isn't cutting it.
I would suspect this has less to do with our app, and more to do with the size of the market. For now, the number of potential customers is just so much smaller for Windows Phone.
There are other things we can do and may try in the next couple of weeks (Trial mode, offer a free version, extensive marketing, etc.), but we are seeing similar results for another ported product - Panda! (iOS, WP7). Panda! is one of our only completely free apps (No charge and no ads) and is released mostly to make me laugh. Although, Panda! is also one of our only apps to not actually serve any useful purpose, people still like to download it. Even though it's free, we are seeing the same reduction in overall downloads as with THE DOG (WP7 downloads are at roughly 5-10% of iOS downloads for the same periods).
This means that there is an even more fundamental question you have to answer besides your price point. Is developing the app even worth it?
We will probably continue to develop some WP7 apps (We love the OS and Mango is too good to ignore), but in some ways it's an act of faith. Faith that the platform will get better (and more popular) eventually leading to more profit and faith that our customers (end users and those contracting us to make the apps) want our products on multiple platforms.
All indications are that our faith is not misplaced. The app market (all platforms) is estimated to grow tremendously leading to more opportunity and (hopefully) more profit. WP7 is predicted to gain more market-share, and our customers have indicated they want us to support multiple platforms. We also love what we do and that certainly doesn't hurt!
But wait - weren't we talking about setting your app's price? Mobile development is a complex business and there is a lot to consider. Setting your app's price is just one part of that complexity and can be a bit (lot) like guesswork. Bottom line is that if you develop a good app and market it well, the price can be fiddled with until you hit the spot that's most profitable. You'll still probably have to adjust it from time to time, but your time is probably better spent trying to guess your way through everything else involved in becoming an overnight millionaire.
WP7 InputScope Tester
When developing a Windows Phone 7 app, you are going to use a TextBox control at some point. When you do, please set an InputScope value. This is one of the easiest ways to improve your user's experience, but it's amazing how many apps are released without using this feature. The InputScope changes the software keyboard and/or the behavior of the TextBox.
The InputScope shown to the left is "Chat", with the smilies selected.
As Shawn Wildermuth points out in his Ten Pet Peeves of WP7 Applications:
"... the default input scope on TextBox's do not offer AutoCorrect. So at a minimum changing the InputScope to Text will give the user auto-correct options. Using the case-specific InputScopes like EmailSmtpAddress, Chat, Number and FullName can help the user input data."
Setting the Input Scope is as easy as changing this XAML:
<TextBox x:Name="txtMyText" />To This:
<TextBox x:Name="txtMyText" InputScope="Text" />Wowee, AutoCorrect and Word Suggestions magically start working! This is an area that new developers seem to miss and can find difficult to implement (Intellisense only shows you the possible values if you use the long notation). You can find an example of the long notation and a list of InputScopes here.
Reading the Imaginative Universe blog linked above and using some of the code demonstrated, I wrote an app to help me see and use the various InputScopes. I will provide a link to the full project below.
The app binds a ListBox to the full list of InputScopes (and so will automatically include any additional InputScopes added in future releases). Select an InputScope from the list and then tap the TextBox to see it in action. Pretty simple, but useful for exploring the various InputScopes.
The code is the property of WireBear, but you can feel free to use sections of it and to distribute this app (for free) with the WireBear name and link intact. Hopefully this helps you make more intuitive apps so that if nothing else, our experiences as users get improved!
Resources:
- WireBearScoper (WP7 C# Project)
- Ten Pet Peeves of WP7 Applications (See # 1)
- WP7 InputScope (Scope list and examples)
Batch Updates with SharePoint 2007 Services
One of the biggest irritations to me coming from a SQL background is trying to do SQL like things in SharePoint 2007. One of those irritations is performing a simple update through the web services. In SQL, I could write something like:
UPDATE ListTable SET FieldName = FieldValue WHERE QueryFieldName = QueryFieldValue
In the generic T-SQL above, any row where the QueryFieldName column had a value equal to the QueryFieldValue would have it's FieldName Column set to FieldValue. Pretty straightforward for anyone with a database background.
With the SharePoint Web Services, however, there isn't a simple UPDATE command like this. Instead of the one simple command above, we have to make 2 calls to the Web Service and provide some complicated XML parameters. This can be a big hassle the first time you do this, so to hopefully save you some headaches, I'll provide most of the code required below...
Can’t Use the Word Fox in App Store Description?
We ran across the following warning today when updating our App Store Description for our dog iPhone app:
The following is not recommended for use in this field: Fox. Your app may be rejected if you use this term.
Our app has a list of nearly 100 dog breeds with one of them being the Wire Fox Terrier. I guess we don't understand when Fox became a word that was off limits.
Does anybody have any ideas why using the term Fox is not recommended in your app's App Store description?
LiquidOffice Retry on Exception
LiquidOffice tasks can fail for a number of reasons. By default, a failed task halts the entire process and you will have to manually skip the task, delete the process or take some other action using Management Console. Sometimes, however, wouldn't it be nice if the failed task waited a certain amount of time then retried?
We have found this to be especially helpful for web service tasks. Calls to web services can fail if the server has gone offline for a minute, but could recover if tried in 10 minutes or so. So we have added an exception loop to each of our web service tasks that retries indefinitely.
Here is the process:
On this process you can see we have a Form task and then a script task called FailTask. The FailTask is pretty simple, it just throws an exception. Here is the code inside the FailTask:
void enteredActive(State state) { Log log = LogFactory.getLog(); log.info("FAIL"); thisProcess.setFieldValue("FakeField","panda"); }
So we write a message to the log then try to set the value on a field that doesn't exist. FAIL! The next task, Other Stuff, will never be reached in this particular example, but is representative of the rest of your process.
The other four tasks are the interesting ones. First is an Exception task. An exception task is just a task that becomes active when the task it is connected to (with a red line) throws an exception - pretty straightforward. After the exception task we have placed a Delay task. This is the task that determines how long the process should wait before retrying.
The most important task is the Reset State script task. Here is the code inside:
void enteredActive(State state) { thisProcess.getTaskByName("FailTask").forceToState(State.READY); }
(This Code can also be placed in the Delay task on the enteringDone event, we have separated it into a separate Script task just to make it easy to understand)
This code retrieves the failed task (whatever task you are attaching the exception loop too) and sets its' state to READY. This command will fail if the task is not currently at state ABORT, so just make sure to only put this code inside your exception loop.
The last member of this loop is the strangest, the Loop task. The loop task is between the Delay task and the Exception task and does NOT link back to the main process (Fail Task). Resetting the state of the Failed task immediately activates it (which is why we reset AFTER the delay task). The loop is only there to reactivate the exception task so that if the Failed task fails again, the exception loop starts over.
In our example above the process will retry forever until it succeeds. You could easily add conditions to the loop task to determine how often it should run and this will be the equivalent of a retry count (since the exception task will never be reactivated).
Adding these types of loops to your processes can help them to be more robust and keep you from having to intervene on recoverable tasks.
Run as different user
If you've ever had to run a program as a different user than the one you were logged in as you might have been surprised the first time you used Vista or Windows 7 to not see the friendly "Run as different user..." option in your context menu.
On Vista, this option was removed completely. On Windows 7 you have to hold Shift while right-clicking to get it to show up. This is not obvious and can be irritating.
I recently came across a tool by Sysinternals (now Microsoft) called ShellRunas. Go get it. To restore your context menu do this:
- Extract the ShellRunas.exe to your C:\Windows\System32 directory
- Open a command prompt (as Administrator), type:
ShellRunas.exe /reg
Your context menu has been restored! That's pretty awesome by itself, but something I like to do is use it to create shortcuts.
A common occurrence for me is the need to run Microsoft SQL Management Studio as a different user to login to a server that only accepts Windows Authentication. This is a classic Run as different user scenario, but I can't tell you how many times I have opened it up and tried to connect only to remember I have to restart the whole program with the Run as different user option. So I created a shortcut by doing this:
- Copied my current shortcut to Management Studio and pasted it to create a new one
- Right-Clicked on the shortcut and selected Properties
- Changed the target to:
C:\Windows\System32\ShellRunas.exe "C:\Program Files (x86)\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe"
(your path may be different)
Now when I run that shortcut I am automatically prompted for my credentials! But there is another feature of ShellRunas that can make your shortcut even better. If I change the target setting from above to this:
C:\Windows\System32\ShellRunas.exe /netonly "C:\Program Files (x86)\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe"
That /netonly section uses the alternate credentials only on remote calls. This means that in Management Studio (or whatever program) I can access all my documents (as long as they aren't mapped to a network share) and still be using the correct credentials when accessing the remote server!
Just a simple but effective tool that makes my job easier.
Free SharePoint 2007 Themes
A while back Microsoft released 10 new SharePoint 2007 themes (for MOSS or WSS). They look pretty good (see screenshots below), but they packaged them in a very strange way. Instead of releasing them as WSP packages for end users to install, they released them as Visual Studio projects requiring a developer to compile them into packages to be deployed.
Download the original samples from Microsoft
While I see a lot of value in having sample code for theme deployment, most SharePoint admins don't have all the tools required to compile these into a usable format. That means the above download is basically unusable for anyone who doesn't have these tools.
A guy named Daniel Brown made the WSP packages available, but all the links are now dead (it has been a while). I have the tools, but even I was annoyed that I had to open each project, compile/package them, and then deploy. So... I have decided to release the packages myself! I've looked through the EULA included with the original download and I don't think I'm in violation, but I'm sure I'll soon find out if I am!
I have not modified a single image or line of code from the samples. All I did was package them up to provide to you along with the instructions to make these a part of your server. Having said that, WireBear claims no ownership or credit for these themes nor do we provide any guarantee of success, warranty, support, etc. But they are free...
Adding color to your Dynamic tables in LiquidOffice
In many of our LiquidOffice forms we use the dynamic table controls with row addition and removal turned on. You can see a sample on the left of a very simple form showing this behavior in Internet Explorer. This works pretty well, but we recently had a seemingly simple request to change the color of the add (+) and remove (-) buttons. There are several things you can customize in your form just by adjusting some properties, but the color of these buttons are not currently available as settings.
So what are our options? We posed that question to Autonomy technical support and they came back with a couple of methods to get to these buttons in javascript and to set their color there. We needed this behavior on multiple tables on the same form and on multiple forms so we put together a method using their help to come up with a pretty simple solution...
Adding a Suicide Loop to your LiquidOffice process
If you've ever created a semi-complex process in LiquidOffice you might have run into a common problem - zombie processes. Zombie Processes are processes that never completed but they aren't being actively used either. Generally these have to be manually killed using the Management Console.
This isn't LiquidOffice's fault, it's doing what it's supposed to, but depending on your environment this can be a big problem and a huge irritation. Fortunately, we can use LiquidOffice to solve this problem quickly and simply with just a few additions to your process...
Latest Tweets
RT @theChrisKent: WireBear Awesemulator is available free at http://t.co/6aJM0bF Take skinned screenshots, video overlays & more for Win ... - posted on 09/06/2011 14:09
RT @theChrisKent: Blogged: Support the App Stores Area 51 proposal! http://t.co/VcPo3nH #stackexchange #Wirebear #AppStore - posted on 08/16/2011 10:01
Check out THE DOG on the Android Market! http://t.co/Spx6y4d - posted on 07/28/2011 06:37
theChrisKent
Why are there new female bounty hunter movies every year? Is it really that interesting? (Nope) - posted on 05/19/2012 21:29
Guy in my book just said, "Cool on you!" Not sure if I can continue. In fact the Dark Tower series isn't nearly as good the 2nd time through - posted on 05/19/2012 10:11
The title "Dances with Wolves" is misleading. There's only 1 dancing scene and it's only with 1 wolf. More like "Danced with a Wolf" - posted on 05/19/2012 09:57
Categories
- Apps
- Cell Phones
- Development
- iPhone
- iPhone Development
- iPhone Marketing
- Javascript
- LiquidOffice
- SEO
- SharePoint
- Silverlight
- Smartphones
- SQL
- StackExchange
- Tools
- Uncategorized
- Windows Phone 7
- WireBear