Подходит для постановки известных проблем непосредственно в программном обеспечении?

Я взял на себя обслуживание приложения для Android, и есть несколько остаточных проблем, которые я более или менее исправил, но все еще есть проблемы из-за разных версий ОС Android.

Например, при отправке веб-запроса с помощью класса MediaPlayer пользовательские заголовки HTTP удаляются ОС перед отправкой запроса, но только на Android 4.X (я исчерпывающе протестировал), что приводит к сбою этой конкретной функции, поскольку она полагается на этих заголовках.

Это известная проблема, и я пытаюсь ее обойти, но было бы неплохо иметь условную проверку вроде

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

Очевидно, мы бы отметили это на нашем канале поддержки, но мне интересно, будет ли хорошей идеей (при условии, что все отслежено), чтобы эти известные проблемы также были встроены в программное обеспечение, и представлять их, когда и где это необходимо, например, что я описал выше.

Мы продолжаем получать множество плохих отзывов и множество писем в службу поддержки на основе таких проблем, поэтому, на мой взгляд, это сэкономит всем много времени и головной боли, просто блокируя функцию, которая, как известно, не работает должным образом.

Я вижу две потенциальные проблемы:

1. Пользователи, вероятно, никогда раньше не видели ничего подобного диалогу «известной проблемы»; многие пользователи просто не могут понять, что это значит.
2. Есть некоторые накладные расходы на разработку - нужно обязательно следить за этими проблемами где-то в коде. К счастью, в Java-аннотациях любой условной проверке, подобной этой, может предшествовать @KnownIssueили что-то подобное, что делает поиск / изменение их очень простым.

Имеет ли смысл вводить подсказки «известная проблема» в программное обеспечение?

Изменить : Я добавлю, что это проблема, которая только начала возникать около недели назад. Я наполовину исправил проблему и вряд ли смогу исправить ее в 4.X, потому что именно ОС вызывает проблему. Я мог бы выпустить новую версию с исправлением и снова порадовать 50% пользователей, и предупредить остальных 50% (пользователей 4.X), что проблема сохранится на 4.X, и предложить обновление (или что-то в этом роде). ). Вопрос заключается в том, стоит ли делать это в программном обеспечении (то есть показывать диалог пользователям 4.X), или просто разрешить им рассылать нам спам на электронные письма поддержки с надписью «Ваше исправление не сработало !!!» а затем направьте их на страницу поддержки, на которой обсуждается проблема более подробно.

Да, это очень приемлемо для некоторых более неясных функций, особенно когда они скрыты в меню параметров. Возможно, лучше отключить кнопки и добавить дополнительный текст «эта функция в XXX и ниже» или «эта функция работает оптимально в XXX и выше», если она работает только частично.

Нет, это неприемлемо для ключевой функции, которая занимает 75% экрана при запуске приложения. Ваше использование будет действительно раздражаться каждый раз, когда они видят всплывающее окно. Вам лучше просто скрыть эту функцию, не нужно совать своих пользователей о том, что они не могут исправить.

Было бы иначе, если бы ваши пользователи могли легко это исправить, например, установив дополнительное приложение. Я часто видел сообщения типа «Чтобы использовать эту опцию, вам нужно установить (бесплатное) приложение компаса» или «Чтобы использовать эту опцию, вам нужно перейти на платное приложение Pro» и т. Д.

Суть в том, что вы можете сделать это, но только после тщательного рассмотрения и после сбоя других решений, а не в качестве быстрого ярлыка. Это будет раздражать ваших пользователей, но это может быть приемлемым компромиссом, который вы сделаете.

(PS. У меня такое чувство, что этот вопрос должен идти в UX )

Множество плохих отзывов + тонны писем поддержки == недовольных клиентов. Собираетесь ли вы сделать их счастливыми, «отказываясь более изящно» при определенных условиях? Может быть. Однако, если бы я был вами, я бы переосмыслил, выпустил ли я программное обеспечение преждевременно, и мне следовало бы просто исправить некоторые из этих проблем, прежде чем они предстали бы перед заказчиком.

Обновление: если это не решаемая проблема из-за среды, я бы добавил приглашение для информирования пользователей (а также задокументировал и разослал по электронной почте). Это работает для такой изолированной проблемы, как эта, но я бы не советовал ее как общее решение для любой «известной ошибки». Если их много, значит, вы делаете что-то не так.

Если проблемные функции доступны с помощью опций, кнопок или чего-то подобного, вы можете отключить или скрыть эти элементы: я ожидаю, что это будет менее разочаровывать пользователя, чем предлагать функцию, которая будет сообщать «не работает». Если вы знаете, что это не сработает, не создавайте впечатление, будто это возможно.

• Отключение опции / кнопки позволит вам добавить заметку о том, что «не поддерживается в вашей ОС».
• Скрытие опции / кнопки не смущает новых пользователей, но может привести к жалобам со стороны существующих пользователей, которые больше не могут найти этот элемент.