Appropriate to put known issues directly in software?

Question

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.

Answer 1

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)

Answer 2

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.

Answer 3

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.