Я взял на себя обслуживание приложения для Android, и есть несколько остаточных проблем, которые я более или менее исправил, но все еще есть проблемы из-за разных версий ОС Android.
Например, при отправке веб-запроса с помощью класса MediaPlayer пользовательские заголовки HTTP удаляются ОС перед отправкой запроса, но только на Android 4.X (я исчерпывающе протестировал), что приводит к сбою этой конкретной функции, поскольку она полагается на этих заголовках.
Это известная проблема, и я пытаюсь ее обойти, но было бы неплохо иметь условную проверку вроде
if (OS.VERSION == 4) {
knownIssueDialog(This feature will not work on your Android version... etc.");
}
Очевидно, мы бы отметили это на нашем канале поддержки, но мне интересно, будет ли хорошей идеей (при условии, что все отслежено), чтобы эти известные проблемы также были встроены в программное обеспечение, и представлять их, когда и где это необходимо, например, что я описал выше.
Мы продолжаем получать множество плохих отзывов и множество писем в службу поддержки на основе таких проблем, поэтому, на мой взгляд, это сэкономит всем много времени и головной боли, просто блокируя функцию, которая, как известно, не работает должным образом.
Я вижу две потенциальные проблемы:
- Пользователи, вероятно, никогда раньше не видели ничего подобного диалогу «известной проблемы»; многие пользователи просто не могут понять, что это значит.
- Есть некоторые накладные расходы на разработку - нужно обязательно следить за этими проблемами где-то в коде. К счастью, в Java-аннотациях любой условной проверке, подобной этой, может предшествовать
@KnownIssueили что-то подобное, что делает поиск / изменение их очень простым.
Имеет ли смысл вводить подсказки «известная проблема» в программное обеспечение?
Изменить : Я добавлю, что это проблема, которая только начала возникать около недели назад. Я наполовину исправил проблему и вряд ли смогу исправить ее в 4.X, потому что именно ОС вызывает проблему. Я мог бы выпустить новую версию с исправлением и снова порадовать 50% пользователей, и предупредить остальных 50% (пользователей 4.X), что проблема сохранится на 4.X, и предложить обновление (или что-то в этом роде). ). Вопрос заключается в том, стоит ли делать это в программном обеспечении (то есть показывать диалог пользователям 4.X), или просто разрешить им рассылать нам спам на электронные письма поддержки с надписью «Ваше исправление не сработало !!!» а затем направьте их на страницу поддержки, на которой обсуждается проблема более подробно.
источник
Ответы:
Да, это очень приемлемо для некоторых более неясных функций, особенно когда они скрыты в меню параметров. Возможно, лучше отключить кнопки и добавить дополнительный текст «эта функция в XXX и ниже» или «эта функция работает оптимально в XXX и выше», если она работает только частично.
Нет, это неприемлемо для ключевой функции, которая занимает 75% экрана при запуске приложения. Ваше использование будет действительно раздражаться каждый раз, когда они видят всплывающее окно. Вам лучше просто скрыть эту функцию, не нужно совать своих пользователей о том, что они не могут исправить.
Было бы иначе, если бы ваши пользователи могли легко это исправить, например, установив дополнительное приложение. Я часто видел сообщения типа «Чтобы использовать эту опцию, вам нужно установить (бесплатное) приложение компаса» или «Чтобы использовать эту опцию, вам нужно перейти на платное приложение Pro» и т. Д.
Суть в том, что вы можете сделать это, но только после тщательного рассмотрения и после сбоя других решений, а не в качестве быстрого ярлыка. Это будет раздражать ваших пользователей, но это может быть приемлемым компромиссом, который вы сделаете.
(PS. У меня такое чувство, что этот вопрос должен идти в UX )
источник
Множество плохих отзывов + тонны писем поддержки == недовольных клиентов. Собираетесь ли вы сделать их счастливыми, «отказываясь более изящно» при определенных условиях? Может быть. Однако, если бы я был вами, я бы переосмыслил, выпустил ли я программное обеспечение преждевременно, и мне следовало бы просто исправить некоторые из этих проблем, прежде чем они предстали бы перед заказчиком.
Обновление: если это не решаемая проблема из-за среды, я бы добавил приглашение для информирования пользователей (а также задокументировал и разослал по электронной почте). Это работает для такой изолированной проблемы, как эта, но я бы не советовал ее как общее решение для любой «известной ошибки». Если их много, значит, вы делаете что-то не так.
источник
Если проблемные функции доступны с помощью опций, кнопок или чего-то подобного, вы можете отключить или скрыть эти элементы: я ожидаю, что это будет менее разочаровывать пользователя, чем предлагать функцию, которая будет сообщать «не работает». Если вы знаете, что это не сработает, не создавайте впечатление, будто это возможно.
источник