Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Native Development Knowledge Base

Difference between rejected and accepted BFB Application - Example: ClipMan

by Developer on ‎06-27-2014 04:53 PM (1,419 Views)

I would like to try to explain the difference between a rejected and a accepted Built for BlackBerry App, at least from my personal point of view. I'm not sure if this is according to the internal guidelines of BlackBerry but perhaps this may help others to understand what may be needed.

How will I do this?

It's simple. One of my Apps was rejected from Built for BlackBerry a while ago. After a lot of frustration I gave it a second try and improved my small application in a private coding marathon. I was now finally able to get it through the Built for BlackBerry testing. At the second try. Yay!

So we have now something we could compare in a before / after scenario.

I will try to explain in this posting what I've changed in my project. Since the Z10 launched in the meantime, I had to remove my old version from the store to avoid confusion, so you're sadly unable to check out the two versions yourself to see and compare the small differences. So I will try to write in this posting about the differences. I know, every project is a totally different story. But perhaps other developers may get by this example an idea what could be the small difference which is needed to get an application approved.

What is this application about?

ClipMan is a small clipboard manager. That's it. It watches for changes in the clipboard while opened and stores every appearing text in a small database. Such a clipboard history can get very handy while texting. You get often to a point at which you recall a similar sentence you've written before. If you have copied those to the clipboard you are now able to get the text back fast, even if you have restarted your device in the meantime.
At least I'm using a similar application called ditto at my desktop frequently. And it really improves my response and especially my developing speed.
ClipMan is the mobile replica of one of the most useful tools at my developer machine. :smileyhappy:


So, enough advertising. Only this single useful aspect is not enough for the Built for BlackBerry certificate. I tried, trust me. You will get: "basically only a single core function", even if there were a lot more (write protected stuff, database import / export, clean up, share functionality - it was simply not good enough).

So, what have I done?

Lets look and compare how it looks after the first startup: (Note: use the desktop version of this site if the picture is not visible)
640_Part01 - Startup.jpg
On the left we have the original version. The screen is empty, the user has no idea what the application could do. In contrast to this empty startup screen we have now the current version with a SystemToast message with a short description. The database is already filled up with 6 more or less useful example messages with data related to the user itself (BBM PIN for example). The app is ready to play around with its features.

Here we see the two versions filled up with 6 text items:
640_Part02 - Appearence - Lock Feature.jpg
It looks very similar, all items are unlocked. If you asked yourself now what this unlocked means you got already an idea why the old version was bad by design. The user sees on the left 6 red symbols, an unlocked padlock. But the user has no idea what this means. In the new version, the fix was implemented simply by showing no lock indicator.

We get a better Idea of this when we open an item:
640_Part03 - Appearence - Lock Feature - Detail - unlocked.jpg
On the left we see the red unlocked status indicator. On the new version at the right there is no indication since nothing happened yet.

In the menu bar in the old version, there is a green lock, the function the user may trigger by tapping this symbol. We have a very similar symbol at the right, but it acts differently.

Let's see what happens by tapping this symbol:
640_Part04 - Appearence - Lock Feature - Detail - locked.jpg
Now we have the Item locked. In the old version, the symbols have simply changed. The user still doesn't know what's the point of this function. But in the new version, the lock in the menu got activated (according to the design guidelines) and we have at the top a clear indicator, including an explanation of what happened.

The IMHO important aspect: The user was not confronted with any kind of indication that this feature may exist until he finally tried it the first time. No confusion, clear functional design.

Here we see how the list looks now:
640_Part05 - List Locked Item.jpg
The old version was for me as the developer of the app clear and understandable. The color was indicator enough, all features worked. But as I learned in a session about good design in Amsterdam: The application should work for everyone, also colorblind people. Those usergroup had an obvious handicap in the old version of ClipMan.

Cleaning Up:
640_Part06 - Clean Up.jpg
This is very similar in both applications. The dialog should explain in detail what happens and what the user may expect.

The result:
640_Part07 - Cleaned List.jpg
All Items except the locked were deleted. Additionally the database got compressed to keep it fast. But we shouldn't bother the user with this feature. Only we, the developers should care about the application performance.

If you wan't to inform the user about more details of the software, put it inside the info screen:
640_Part08 - Info screen.jpg
The old version was very rudimentary. The new version, clear in the beginning, more detailed in the long text below.

How I have improved the core functionality of the list in the main screen?

Context Menu:
640_Part09 - Context Menu.jpg
It was not really needed since in the old Version every function was available by simply opening an item. But if I understood the design guidelines correctly every ListView should have a context Menu. The user expects this behavior.

Search function:
640_Part10 - Search.jpg
I added a search function to the list. Since I'm keeping myself the list always very empty I had no demand for a search button. Personally I have the list only filled with the stuff I'm currently using. But others may use this application in a different way. So a search function was needed.

Built for BlackBerry means built especially for BlackBerry10. And so the application should integrate itself in every aspect into the BB10 system.

Here we have the minimized applications on the home screen:
640_Part11 - Task View.jpg
Easy to see which one is the old, and which is the new version. In the new version you get only in the first 2 seconds a minimized version of your list. From this point on it displays always the current content of your clipboard. Via the extension of all this swipe and peek stuff. "Not sure what you have currently in the clipboard?" - Minimize your current app, look at the ClipMan app to check and go back to your task before pasting the wrong text.
Simple, clear, useful.

Overall integration

Since the share functionality was a selection criterion in the BFB checklist ClipMan had a share button even in the first version.

Neat feature, simple to implement, but surely not enough. Why? Every app with a text field has a share function integrated by default via the context menu at a selected text. So why should an extra button for sharing a text be this special?

Thanks to jtegen and also the already accepted FancyTran application I got finally an idea about the whole BB10 flow concept. It shouldn't be needed to leave a application to do something useful with another application.

So ClipMan got an invocation target:
640_Part12 - Invocation Target.jpg
There are 2 possibilities as you see in the screenshots. Share via the normal dialog and I integrated it additionally into the text selection context menu. Perhaps not a good idea for every application. Personally I would hate to have every application integrated into this menu. But since a text is now marked and the context menu is opened, the most users want now to interact with the clipboard. If copied and ClipMan is opened the text will get pushed to the ClipMan database. If you know you haven't opened ClipMan you can push now your text using this button to your clipboard manager.

This is the nature of ClipMan as a clipboard manager, extend the functionality of the clipboard. So in this case it is a good idea to have it placed in every application near the Cut, Copy, and Paste Buttons. Most applications should be fine by simply integrating the share button via which the app you want to use gets selected. It's only a single additional tap away.

But this invocation integration delivers also an additional benefit:

A user is now able to select a text and replace it with a different one without leaving the current task.
640_Part13 - Invocation Target - Put Text to Clipboard.jpg

push a different text to the clipboard

640_Part14 - Invocation Target - Paste Text.jpg
paste it into your application, in this case an email

Simply mark a text, open it in ClipMan (the text gets stored for later use) - you can now go back to what you have done before OR select a different text, push it to the clipboard, go back to your app and paste the text snipped wherever you want. Even in a form in the next text area.

And I would say now we got the BlackBerry 10 flow.

Store experience:
I had two versions of ClipMan in the store. A free app and a paid app. Sadly this is also a bad design. I got this explained at several places so I guess it played also a role to get it rejected. "Bad store experience."

The user downloads the free version from the store, got a first impression but with a limited functionality. You have to explain this in many places and dialogs. And you have to do some kind of advertising in your app why the user should pay now to get more. If the user was bugged enough he has to go to the store, search for the paid version, he has to pay and install the full version and after this, uninstall the old version manually.

And think about the data the user has already created (in ClipMan perhaps no problem since the free had the store function disabled), but in other applications the user has the problem that he may lose all settings and stored data from the free version since the paid gets installed to a different "sandbox" and has no access to the old data.

Because I had not enough time (deadline) I decided to simply remove the free version and concentrate myself only on a single version, the paid. But the better solution, instead of two versions or simply only a paid would be an upgradeable free version with in app purchase. The Freemium model.

Sadly we are unable to revert a once made decision after an app got published. Once in the store we have to stick to paid. We can't change the licence model and ask the people who have already paid for the old version to pay again to activate the new free version to get again what they have already paid for. This could cause a **bleep**storm at your app reviews.

I'm currently creating a small but perhaps useful tool application to test this freemium model myself and how to integrate it into my apps. But I'm sure, my next big application will have this integrated from the beginning. No free / paid versions of the same app anymore. Only free, paid, or freemium. Not several versions of the same app anymore.

Bug fixes:
Last but still very important: My app was unable to handle different text encoding correctly. I found the bug and it is now able to store and handle also Arabic, Chinese, Cyrillic, Greek, Japanese, and many other character encodings.

Bottom Line:
There can't be a universal recipe for every app. And it's completely in vain to simply copy and recreate my application or one of the other BFB applications since they won't accept several of the same app type. Perhaps you have the luck to have currently already created an app which could get a Built for BlackBerry with some minor modifications as mine. Or you realize now that your app could never reach this level as some of my other applications may never have a chance to get BFB even if they are really good at their core functionality. I would say both insights are better compared to utter cluelessness. :smileyhappy:

I hope this posting was worth a read and may help some other developers with their projects. At least I hope my time was not totally wasted.

If you have any questions don't be shy to ask. But be warned, I don't know any internals and I have no Idea which of the changes I explained above were crucial to get accepted. If you have an app which got also approved at the second or third try, please post also your story to give other developers an impression what could be needed. And as always don't forget to hit the like button if you want to honor the work behind this "essay". :smileywink:

Thanks to jtegen, peter9477 (was great to met you in Amsterdam :smileyvery-happy:), neilwick, connyhald and all the other developers in this forum and at twitter who helped, comforted and motivated me a lot. :smileywink:

Users Online
Currently online: 4 members 902 guests
Please welcome our newest community members: