Over the past few weeks at Zywave, I’ve been tasked with researching and defining a mobile readiness coverage scale to attach to the miscellaneous products we develop. We have a wide range of products, and their usability on mobile devices varies between them, so we wanted to have something to easily see which products are ready for mobile and which products aren’t, and then what amount of overall functionality is offered.
The Grading Scale
I began by researching the basic key phrases I could think of in Google:
mobile coverage grading scale, product functionality available on mobile, how to rate my product’s ability on a mobile device, how to determine what features to remove from mobile, what to tell a customer who asks about my mobile software, compare mobile coverage to desktop, etc.
Unfortunately, I found that I wasn’t able to pinpoint a widely used list, or set of guidelines by the mobile development community. Perhaps this was because I wasn’t able to figure out the best Google phrase. Or possibly because I don’t know the websites to go to, in order to find a list like I was looking for. I’m hoping those aren’t the reasons, and I can just blame it on the fact that one doesn’t really exist. However I did learn quite a bit about mobile testing limitations if testing on a desktop computer. More on that later.
Since I was overall unsuccessful in my endeavors, I set out to use the little bits I found, and to create a list that would work for Zywave’s products. I found a few different ideas for informing customers of how much of your application’s functionality is available on mobile, such as percentage based system, yes/no for mobile availability, a number scale (which seemed to be somewhat like percentage), a list of features available or missing, and a grading scale. I chose to try out the grading scale for our use.
This is what I came up with, and continuously under review, so a handful of things could change over time, or we might scrap it all together and start over with a different idea (the joys of agile).
A
Application is mobile ready, approved by business for use, and complete. This signifies that all or nearly all application functionality that is available on a desktop browser is also available on a mobile device (perhaps with a small amount of business-decided features removed from mobile). This also signifies that the features available on a mobile device are without bugs, and a mobile device can be used by the consumer as a desktop alternative, when preferred. This grade also refers to active and immediate development support and a high level of external advertising for use on mobile devices.
B
Application is mobile ready, approved by business for use, and complete. However, this signifies that about half of the feature set of the product is available on mobile, and the mobile device can only be used for those features. This typically would refer to a business decision to only release a subset of features, so the consumer can utilize these features when on the go, but the preferred method of product use is via a desktop browser. This might also refer to a product with more than half of it’s functionality available to the user on a mobile device, but with a large amount of known compatibility issues across mobile platforms. This grade also refers to a fair amount of mobile development support, and some external advertising for use on mobile devices.
C
Application is mobile ready and approved by business for use, however, a very limited subset (about 25% or less) of functionality is available to the user, regardless of business decision or code limitations. This could also refer to a product in active mobile development for production, attempting to reach a better grade, but testing is incomplete or there are many known compatibility issues. This grade also refers to a low amount of mobile development support, and little external advertising for use on mobile devices.
D
Application could be mobile ready, but business decisions are made to ignore this product. Or, product is available on mobile and can be logged into, but no functionality is available to the user or functionality works incorrectly. This grade also refers to no mobile development support, and no external advertising for use on mobile devices.
F
Application cannot and will not be mobile ready due to business decisions, code limitations, or time restraints. This product has no mobile functionality, it cannot or should not be logged into, and no mobile development support exists for this product. There should be no mention of this product’s functionality for mobile use.
Why The Grading Scale
After spending some time thinking about which option would work best for Zywave, I landed on the Grading Scale option because it seemed to categorize our products into groups that could easily be defined by a paragraph or two. However, it’s possible this could group two products together in the same Grade, that shouldn’t belong together, or, we might need to further evaluate spacing out the Grades a bit more so that D and F don’t feel too close together.
I thought about the simple Yes/No option, but this didn’t account for the list of functionality coverage of the product, nor did it inform the end-user of anything beyond: “Yes, you can access our product from a mobile device.” Should I be able to do anything? Should I expect bugs? How about using my favorite feature in the product, can I do that?
The Percentage Based System would have worked great to define the list of functionality coverage of the product, but this could have easily gotten outdated with the additional of one new feature-set. Additionally, I didn’t want to assume I knew 100% about every product at Zywave, and all of it’s functionality, and then look into how much of that is available on mobile, then do the simple calculation:
I also found that the number system could always be at 50%, even though your product is releasing more and more mobile functionality. Here’s an example:
Say your desktop product does four things total, and two of those things are available for use on a mobile device (due to the product being older, and there isn’t time or support for the two missing features). Business decides to release two more features, but only one of them is to be available on mobile, the other is strategically decided not to be covered. Technically you still have a 50% coverage, even though this could promote your product to the next letter grade.
The Number System could be used in two different ways. It could nearly mimic the Percentage Based System, perhaps with some rounding for feature expansion, but at some point, it’s still inaccurate, it just doesn’t require quite as much updating or tracking. However, it could also be used similar to my Grading Scale, in that a higher number (or lower if you’re into golfing) represents a paragraph of defined coverage, availability, business plans, and more. This does allow more options (1-10) and therefore better definitions between numbers. The problem I encountered was that the numbers naturally locked your brain into a percentage-like system, and I wanted to steer away from that.
My overall dilemma, however, is how to recognize when a product has gone from one grade to another. Perhaps a big list of features was just released to production, and the business has decided not to build and support mobile coverage for it (which I actually have built into Grade A still, but for arguments sake, we’ll pretend the Grade is going down). I was previously at an Grade A, but now that puts me down to a Grade B. Is it that easy? Perhaps it is as easy as updating our spreadsheet of products and their mobile readiness. But if not, maybe that would an opportunity to redefine our grades.
All Encompassing
How do you develop one list that can work for all your applications? We develop a vast amount of products at Zywave, with entirely different capabilities on mobile devices. To write one list that defines it all can be tough, but I attempted to do so. Maybe I should have just written a paragraph about each product individually and been done with it, but where’s the fun in that.
Does anyone have experience with this? Is there already a list out there that does what I’m looking for? Comment below with your thoughts, suggestions, personal recommendations, or anything!
Life of a Tester 
Leave a comment