02-15-2013 08:32 AM
02-15-2013 09:08 AM
I just had another app rejected, e-Mmanuel Bible Reader for BlackBerry 10, and I wasn't surprised by the rejection. What I was surprised about, were their reasons, which could only be because they did not test my full version (activated via in-app purchase, using a service integration they would like to see). I would have thought they would check all of your app, particularly knowing that devs may intentionally lock out some features for the free version?
Specifically, their comments and my response:
The features which are unlocked with full version purchase are listed for the user in the opening screen. This opening screen also disappears with purchase of the full version.
02-15-2013 10:49 AM
This leads me to the question: Will each new clock app be rejected, because a clock app already exisit on the device?
I think a lot of people like cool clocks. And there is a market for many different types of clocks in different designs. But at the current state a clock will only pass, if the reviewer "detects" an intertainment value or the clock has additional features other clocks don't have. Is a different design enough? Yes? No? Or sometimes yes, sometimes no?. Who knows?
Yes, who knows? My clock was rejected as a "single simple function" app. Admittedly, it doesn't make coffee :-), but it has unique functions that seem popular with users of the PlayBook version.
I guess the example of jetstreamblue's Bible app, is one more reason to believe that the reviewers simply don't have time to look properly. My app hides all controls after 30 secs of inactivity (cp. UI-guidelines "content is king"), so who knows ... maybe the reviewer loaded the app while still dealing with the previous one, then looked over, saw nothing but a clock face and straightaway reached for the automatic rejector button ...? Hard to believe, but who knows ...
My app : Get set - Get up! Get ready for the snooze revolution.
02-15-2013 02:07 PM
With your experiences in mind i want to give another ficual example.
When i want to provide a chess clock it will not qualify because
- the reviewer does not know speedchess, so he does not see any "user benefits"
- the reviewer knows speedchess but the app has only a single simple function therefor it will not qualify.
As a result a user will never see the chess clock app in the BFBB section. He will look in the other section and between 20 Android-ported chess clocks he will propably see mine.
And the user will say: "Oh, its a Cascades chess clock. Nice. But why is it not in the B4BB section? It did not qualify? Maybe there is something wrong with this app. Better i don't touch it".
Another, more brilliant developer inserts a chessrule reference in his chess clock app (its useless, because someone who needs a chessclock will know the rules). Now this app qualifies because of this additional feature.
Then i add the same feature (still useless) into my app too. Again it will not qualify because a similar app already exists.
Does this make any sense?
02-15-2013 02:21 PM
02-15-2013 02:32 PM
I will not judge about the BFBB program in this post.
About visiblity in the store and all those Android **bleep** I would say this will get sorted automatically. We shouldn't be afraid of all this Android stuff. At least not in the long therm.
I've seen a lot of 1 or 2 star Reviews in the store: "warning, this is only a Android App"
In comparison a example from one of my own Apps:
After realizing how the Port-A-Thon works I've created for the last one myself some of this "very special" applications I would have never created without this program, just because I were too scared to waste my time and to damage my own reputation with those "cr*p". But I needed the money to pay the hotel and my travel costs for the BB Jam Amsterdam.
Among others I've created a simple Torch light with some additional, minor useful functions. And to my surprise I've got today a very positive review which highlighted that it is a native BB10 app!
If this example establishes itself in the mood of the Users the most Android apps except the really good ones will get invisible with their 1 Star reviews and "our" well made native BB10 Apps will remain at the top of the list. At least I hope so.
NEVER GIVE UP!
02-17-2013 12:08 PM - edited 02-17-2013 12:09 PM
I think the initial idea of BFBB was to encourage developers to use the new UI-controls of the different BB10 SDKs in theire apps. This is exactly what the term "Built for BB" says and this is what the examples in the webcast and the checklist are suggesting: Even a simple game, and a simple calculator will qualify.
But then BB decided to exclude these simple (not useless!) apps and converted BFBB into a label for "premium" apps. At this point the confusion begun.
A premium section is not a bad idea at all. But mixing it with the BFBB-label is.
I am looking for a solution which has benefits for all, BB, developer and user and have two different ideas:
Simple BFBB apps can enter the BFBB section too, but will be listed behind the BFBB "premium apps" and will not be advertised by BB.
Simple BFBB can not enter the BFBB section. They will be listed in the common section, but they can use the BFBB label in the description and the keywords, so user are able to separate them from the Android ports. In this case the current BFBB section needs to be renamed ( "Premium Section" for example) to prevent confusion.
As a result BB has its "premium" section, but the user will also find also BFBB-certified apps in the common section.
Even more important is to improve the qualification process itself. The developer should be able to add a spreadsheed where the criteria are listed. The developer can describe the user benefits (from his point of view), the parts of the app where services are used, why , for example, he disabled copy paste and so on - all the points which are important for the qualification process. This little additional work gives the developer a chance to check all the points again, before pressing the "Apply" button in the vendor portal.
And it will speed up the reviewing process too, because the reviewer is guided to the important parts of the app. When the reviewer rejects the app, he can add his comments to the spreadsheed, so the dev knows exactly where the critical points are.
I think, the current situation is far from perfect, isn't it?
What do you think? Is there any demand from you to get these issues improved?