Application Security Testing: An Integral Part of DevOps
You have one very small window to convince a potential consumer that your application will do whatever they need: entertain them, educate them, connect them, even solve world hunger and win the latest Power Ball with just a single click to download. Hey, you are the one making the promises and assertions, but an application that could guarantee a power ball win might be the best marketing angle ever.
By default, only the first three or four lines of an application description are shown to the user. This is often referred to as the fold, as the user has to work (scroll or click) to see more. These few sentences are an opportunity to sell your application to your future happy, well adjusted user base who will favour compliments over complaints. Well, maybe.
The description preview should clearly explain the intent of the application, as the rest of the description can be used to highlight features and confirm its value proposition. This should be the application’s elevator pitch, which is a well-crafted message to the audience explaining the purpose and goals of an idea, or in this case, the application.
Flowery language need not apply for this coveted description role.
- Something that concisely describes the application and it’s intent. This needs to be first, before reviews, before highlights.
- The unique value proposition. Ok, wut? Did I just throw a mouthful of marketing jargon at you? Yes, guilty as charged. Simply, what makes your application different or better? Why will this application make life better, easier or more enjoyable?
- Highlights or accomplishments. For example, "A Top 10 Free Game in the Windows Store" or "10, 000 users love AppName."
- A teaser. Suggest there is more to discover.
- Complimentary reviews. If someone has given the application a positive review, why not include it in the description, as users will check the ratings and reviews. Keep these at the end, as they are icing on the cake, not the cake itself;)
- What future iterations or versions might be included to keep people interested and assure them the product will be actively supported and updated.
- Keywords. Think about what your user might search for to find your application and see if you can naturally include those words in your description. Don't force them into your description; it will potentially cause distrust in the quality of your product. Keyword tools can be a big help – and I’ve mentioned some good keyword tools in a previous post about How to Name Your Application.
Application Descriptions – The Long and Short of It
Regardless of the application ecosystem, descriptions will have a character limit. For the Windows Store, descriptions have a limit of 10,000 characters, whereas for iOS and Google Play it is 4,000 characters. People tend to just scan the description, so be careful that you're not being unnecessarily verbose. Keep in mind that you have a section dedicated to features as well, so these don't necessarily have to be woven into your description as a bulleted list.
If you're going to talk about features, remember that it's not always about you. Sorry, single children out there who have never had siblings. For most developers, that can be a difficult task as we take great pleasure in things like code simplification, or utilization of some new feature of a language. Some of these things might not be transparent to a user as they exist in the underpinnings of the application code base, so chances are a user isn’t going to be concerned or impressed by it. Think about your user's needs and interests and highlight features that address those.
When you think application description, think elevator pitch. If you haven’t practiced or perfected your elevator pitch, hold tight as that will be the next article in this series.
Reprinted with permission.