Czy stosowne jest umieszczanie znanych problemów bezpośrednio w oprogramowaniu?

Przejęłem konserwację aplikacji na Androida i jest kilka pozostałych problemów, które mniej więcej naprawiłem, ale nadal mam problemy z powodu różnych wersji systemu operacyjnego Android.

Na przykład wysłanie żądania internetowego za pomocą klasy MediaPlayer ma niestandardowe nagłówki HTTP usuwane przez system operacyjny przed wysłaniem żądania, ale tylko na Androidzie 4.X (dokładnie przetestowałem), co powoduje, że ta szczególna funkcja nie działa, ponieważ jest zależna na tych nagłówkach.

Jest to znany problem i próbuję go obejść, ale czy dobrym pomysłem byłoby sprawdzenie warunkowe

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

Oczywiście odnotowalibyśmy to na naszym kanale wsparcia, ale zastanawiam się, czy dobrym pomysłem (zakładając, że wszystko jest śledzone) jest osadzenie tych znanych problemów w oprogramowaniu i przedstawienie ich w razie potrzeby, takie jak opisałem powyżej.

Ciągle otrzymujemy wiele złych recenzji i wiele e-maili dotyczących pomocy technicznej w oparciu o tego rodzaju problemy, więc moim zdaniem zaoszczędziłoby wszystkim dużo czasu i bólu głowy, po prostu blokując funkcję, o której wiadomo, że nie działa poprawnie.

Widzę dwa potencjalne problemy:

1. Użytkownicy prawdopodobnie nigdy wcześniej nie widzieli czegoś takiego jak okno dialogowe „znany problem”; wielu użytkowników może nie rozumieć, co to znaczy.
2. Jest trochę narzutów związanych z programowaniem - trzeba by pamiętać o tych problemach gdzieś w kodzie. Na szczęście dzięki adnotacjom Java każda taka kontrola warunkowa może być poprzedzona @KnownIssuelub coś w tym rodzaju, co bardzo ułatwia znajdowanie / modyfikowanie.

Czy umieszczanie podpowiedzi „znany problem” w oprogramowaniu ma sens?

Edycja : Dodam, że jest to problem, który zaczął się pojawiać około tydzień temu. Naprawiłem problem w połowie i bardzo mało prawdopodobne jest, żebym mógł go naprawić w wersji 4.X, ponieważ przyczyną problemu jest system operacyjny. Mógłbym wydać nową wersję z poprawką i sprawić, że 50% bazy użytkowników znów będzie szczęśliwych, i ostrzec pozostałych 50% (użytkowników 4.X), że problem będzie występował na wersji 4.X, i zasugerować aktualizację (lub coś w tym stylu) ). Pytanie brzmi, czy zrobić to w oprogramowaniu (tzn. Pokazać okno dialogowe użytkownikom 4.X), czy też pozwolić im spamować nam wsparcie e-mailami z informacją „Twoja poprawka nie działa !!!” a następnie skieruj je na stronę pomocy technicznej, która szczegółowo omawia problem.

Tak, jest to bardzo akceptowalne w przypadku niektórych bardziej niejasnych funkcji, szczególnie gdy są one ukryte w menu opcji. Być może lepiej jest wyłączyć przyciski i dodać dodatkowy tekst „ta funkcja w XXX i poniżej” lub „ta funkcja działa optymalnie w XXX i wyżej”, jeśli działa tylko częściowo.

Nie, nie jest to dopuszczalne w przypadku kluczowej funkcji, która zajmuje 75% ekranu po uruchomieniu aplikacji. Twoje zastosowania będą naprawdę denerwujące za każdym razem, gdy zobaczą wyskakujące okienko. Lepiej jest po prostu ukryć tę funkcję, nie trzeba przekopywać użytkowników o coś, czego nie mogą naprawić.

Byłoby inaczej, gdyby użytkownicy mogli to łatwo naprawić, na przykład instalując dodatkową aplikację. Często widziałem komunikaty typu „Aby skorzystać z tej opcji, musisz zainstalować (bezpłatną) aplikację kompasu” lub „Aby skorzystać z tej opcji, musisz zaktualizować aplikację do płatnej wersji pro” itp.

Najważniejsze jest to, że możesz to zrobić, ale tylko po uważnym rozważeniu i po niepowodzeniu innych rozwiązań, a nie jako szybki skrót. Będzie to zirytowało użytkowników, ale może to być akceptowalny kompromis.

(ps. Mam wrażenie, że to pytanie powinno przejść do UX )

Wiele złych recenzji + mnóstwo e-maili dotyczących wsparcia == niezadowoleni klienci. Czy zamierzasz ich uszczęśliwić, „grając bardziej wdzięcznie” w określonych warunkach? Może. Jednak gdybym był tobą, zastanowiłbym się, czy wypuściłem oprogramowanie przedwcześnie i powinienem właśnie rozwiązać niektóre z tych problemów, zanim pojawią się one przed klientem.

Aktualizacja: jeśli jest to problem, którego nie da się naprawić z powodu środowiska, wstawiłbym monit o poinformowanie użytkowników (ORAZ również udokumentowanie i wysłanie wiadomości e-mail). Działa to w przypadku takiego izolowanego problemu, ale nie radziłbym tego jako ogólnego rozwiązania dla każdego „znanego błędu”. Jeśli jest ich wiele, robisz coś złego.

Jeśli problematyczne funkcje są dostępne za pomocą opcji, przycisków lub czegoś podobnego, możesz wyłączyć lub ukryć te elementy: Oczekuję, że będzie to mniej frustrujące dla użytkownika niż zaoferowanie funkcji, o której powie się „nie działa”. Jeśli wiesz, że to nie zadziała, to nie spraw, aby wyglądało to tak, jak mogłoby.

• Wyłączenie opcji / przycisku pozwoli Ci dodać notatkę z informacją „nieobsługiwane w twoim systemie operacyjnym”.
• Ukrywanie opcji / przycisku nie dezorientuje nowych użytkowników, ale może powodować skargi istniejących użytkowników, którzy nie są już w stanie znaleźć elementu.