12

I've taken over maintenance of an Android app, and there are a few residual problems that I've more or less fixed, but still have issues because of different Android OS versions.

For example, sending a web request with the MediaPlayer class has custom HTTP headers stripped by the OS before the request is sent out, but only on Android 4.X (I exhaustively tested), and that causes this particular feature to fail because it relies on those headers.

This is a known issue and I'm trying to work around it, but would it be a good idea to have a conditional check like

if (OS.VERSION == 4) {
    knownIssueDialog(This feature will not work on your Android version... etc.");
}

Obviously we would have this noted on our support channel, but I'm wondering if it would be a good idea (assuming everything is kept track of) to have these known issues also embedded in software, and to present them when and where necessary, such as what I described above.

We keep getting multiple bad reviews and a lot of support emails based on these kinds of issues, so in my mind it would save everyone a lot of time and headache by simply blocking a feature where it is known not to work properly.

I see two potential problems:

  1. Users have probably never seen anything like a "known issue" dialog before; a lot of users simply might not understand what it means.
  2. There is a bit of development overhead - one would need to make sure to keep track of these issues somewhere in the code. Fortunately, with Java annotations, any conditional check like that could be preceded by @KnownIssue or something like that, making finding/modifying them very simple.

Would putting 'known issue' prompts in software make sense?

Edit: I'll add that this is an issue that just started occurring about a week ago. I have half-fixed the issue, and am very unlikely to be able to fix it for 4.X because it's the OS that is causing the problem. I could release a new version with the fix and make 50% of the user base happy again, and warn the other 50% (4.X users) that the issue will persist on 4.X, and to suggest an upgrade (or something). The question is whether or not to do that in software (i.e. show a dialog to 4.X users), or to just let them spam us support emails saying "your fix didn't work!!!" and then direct them to the support page that discusses the issue in further detail.

  • 2
    "This feature will not work on your Android version." What do you do instead? Just fail unglamorously and say nothing? – Robert Harvey Aug 3 '15 at 14:43
  • @RobertHarvey The request is for Text-to-Speech. The 'online' version requires an HTTP request, which fails if the headers aren't present (so it breaks in 4.X currently). However, if that fails then we fall back to the device's TTS. The problem is that most device TTS sucks, which is why the online one is the first method. We fall back gracefully, but on some older devices (about 20% of our user base), TTS is horrendous... – Chris Cirefice Aug 3 '15 at 14:45
  • Is requiring a certain OS version to allow installation an option? At least the complaints are limited to a lack of backward compatibility. – JeffO Aug 3 '15 at 14:46
  • I don't think users will be unduly puzzled by a message saying "This feature will not work with your OS version, please upgrade to 5". Frustrated, perhaps, since the upgrade isn't easy to perform... – Kilian Foth Aug 3 '15 at 14:46
  • Doesn't their TTS work equally bad in every other app as well? – Robert Harvey Aug 3 '15 at 14:47
6

Yes, this is very acceptable for some more obscure features, especially when they are hidden away in the option menu. Perhaps it's nicer to disable the buttons and add some extra text "this feature on XXX and below" or "this feature works optimal on XXX and above" if it only works partial.

No, this is not acceptable on a key function that takes up 75% of the screen when you start your app. Your uses will get really annoyed every time they see the pop-up. You are better off just hiding the feature, no need to poke your users about something they can't fix.

It would be different if your users can easily fix it, for example by installing an additional app. I've often seen messages like "To use this option, you need to install the (free) compass app" or "To use this option, you need to upgrade to the paid pro app" etc.

The bottom line is, you can do this, but only after careful consideration and after other solutions fail, not as a quick shortcut. It will annoy your users, but that might be an acceptable trade-off you make.

(ps. I have the feeling this question should go to UX)

3

Multiple bad reviews + tons of support emails == unhappy customers. Are you going to make them happy by 'failing more gracefully' for certain conditions? Maybe. However, if I were you I'd rethink whether I released the software prematurely and I should have just fixed some of those issues before it would get in front of the customer.

Update: If this is an un-fixable issue due to environment, I'd put in the prompt to inform the users (AND also have it documented and sent out in an email). This works for an isolated issue like this, but I would not advise it as a general solution for just any 'known bug'. If there are many of these, then you are doing something wrong.

  • 4
    I think what he's really asking is "Should we tell people that their phone sucks?" – Robert Harvey Aug 3 '15 at 14:49
  • Good point, however we haven't actually released a half-baked version. This just started being a problem as of 5 days ago; we already have 10+ support emails, and I've half-fixed it. Before release, I want to figure out whether or not putting something like this in is a good idea, just to avoid saying hey everybody we fixed TTS except for you, Android 4.X users. You don't get a fix, because you suck. Unfortunately, this is an OS-specific issue, and not something I can fix at all. Android strips HTTP headers, nothing I can do about that! – Chris Cirefice Aug 3 '15 at 14:53
  • @RobertHarvey: I guess I read the question in a more generic sense... this answer might not apply for issues that come up because 'people's phones suck' – c_maker Aug 3 '15 at 14:53
1

If the problematic features are available via options, buttons or something similar, you could disable or hide these elements: I expect this to be less frustrating to the user than being offered a feature only to be told "doesn't work". If you know it's not going to work, then don't make it appear like it could.

  • Disabling the option/button will allow you to add a note stating "not supported on your OS".
  • Hiding the option/button will not confuse new users but might cause complaints by existing users that are no longer able to find the item.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.