Co to jest zawsze "Standard"? Jeśli specyfik nie powiedział tego, należy założyć?

Question

Czy są jakieś standardy, które uważasz za tak oczywiste, że zakładano, że są w jakimkolwiek spektrum?

Na przykład, czy trafienie w ucieczkę zawsze należy anulować? Czy dwukrotne kliknięcie separatora nagłówka kolumny zmienia rozmiar kolumny?

Kiedy klient mówi "to jest oczywiste i" standardowe zachowanie ", oznacza to, że nie jest to błąd" - czy są one czasem poprawne? Jeśli tak, czy są jakieś zasoby, które mogą pomóc w mediacji?

Pamiętam, że profesor prosił nas o napisanie każdego szczegółu związanego z prostymi zadaniami - i jak śmiesznie by to było możliwe. Nie chcę, aby nasze specyfikacje były śmieszne, ale mam dość słuchania tego i myślę, że nasze specyfikacje nie są wystarczająco szczegółowe.

Answer 1

Możesz sprawdzić wytyczne doświadczenie użytkownika Windows dla „oczekiwanym” zachowania elementów GUI: http://msdn.microsoft.com/en-us/library/aa511258.aspx

Answer 2

pytań dotyczących interfejsu użytkownika, możesz skonsultować się z istniejącą wytyczną UI, takie jak Apple's lub Microsoft's . Jest ich jeszcze sporo, ale ci dwaj są wystarczająco grali, że ich wytyczne prawdopodobnie odzwierciedlają to, czego użytkownicy oczekują w większym stopniu niż większość innych.

Edit: zamknięcie okna dialogowego za pomocą klawisza Escape jest pokryta Microsoft guideline (przewinąć w dół do „Interakcje”):

Naciśnięcie klawisza Esc zawsze zamyka okno dialogowe czynną. Dotyczy to okien dialogowych z opcją Anuluj lub Zamknij, a nawet jeśli Anuluj został zmieniony na Zamknij, ponieważ wyników nie można już cofnąć.

Nie wyglądałam bardzo ciężko, ale nie widziałem nic o automatycznej zmianie rozmiaru kolumn - a to dość niezwykłe, że byłbym raczej zaskoczony, gdyby tam był.

Jako taki, gdybym był odpowiedzialny za to, powiedziałbym, że jest to decyzja podzielona (że tak powiem). Rozsądne jest, aby klient oczekiwał, że klawisz Escape zwolni okno dialogowe (bez jego jawnego określenia), a niepowodzenie to powinno zostać uznane za błąd.

Automatyczne zmienianie rozmiaru kolumny w odpowiedzi na dwukrotne kliknięcie granicy nagłówka kolumny nie jest rozsądne, aby można się było spodziewać bez jej określenia, więc implementacja powinna być uważana za dodatkową funkcję.

Ostrzeżenia:

1. Jeśli rozwijanie czegoś, co ma swoje własne wytyczne UI (np Mac lub iPhone), takie są zasady, których należy przestrzegać. Udział w rynku Microsoftu sprawia, że ​​są oczywistym wyborem dla celu, który nie ma własnych wytycznych UI.
2. Jest to wyraźnie kwestia relacji z klientami. Jasne jest, że nie chcesz stracić swojego najlepszego klienta nad czymś, co możesz wdrożyć dość łatwo. Jeśli automatyczna zmiana rozmiaru kolumn ma dla nich ogromną różnicę, a oni są dobrym klientem w inny sposób, może to mieć dla nich sens - ale powiedz im, że robisz im przysługę, ponieważ doceniasz ich wartość. . Trzeba tylko uważać na równoważenie ciepłego, rozmytego "bo jesteś wyjątkowy" z łagodną winą ", więc robimy ci przysługę, a teraz jesteś nam winien ..." (IMO, to zwykle lepiej nie powiedzieć "a teraz jesteś nam coś winien" część głośno, ale nie znam twojego klienta).

Answer 3

Utwórz specyfikację płyty kotła, która zawiera/odniesie we wszystkich projektach o tym samym ogólnym projekcie. Ta specyfikacja powinna się rozwijać i zmieniać, gdy dowiesz się więcej o potrzebach klientów/klientów. Ta specyfikacja powinna również odnosić się do odpowiednich wytycznych interfejsu użytkownika dostarczonych przez Apple lub Microsoft. Nawet jeśli korzystasz z jednej platformy, zdecydowanie zalecamy zapoznanie się z inną specyfikacją w celu uzyskania wglądu w lepsze sposoby robienia rzeczy lub zidentyfikowania możliwej czkawki. Istnieje również kilka dobrych książek na temat projektu interfejsu użytkownika, od których możesz pożyczyć.

Answer 4

standardową praktyką jest określenie standardów interfejsu użytkownika, nie zakładają im

na przykład, dwukrotnie klikając nagłówek kolumny w siatce, aby zmienić rozmiar jest nie standardowe zachowanie okna GUI. Podwójne kliknięcie na separator kolumn, aby zmienić rozmiar kolumny, jest jednak.

Warto podać standardowe zachowanie GUI, aby uniknąć zamieszania; jeśli możesz odwołać się do istniejącego standardu, który jest w porządku, ale upewnij się, że klient się na nim podpisuje

"Nie mogę odczytać twojego umysłu, a takie i takie nie jest zachowanie standardowe/domyślne" jest logiczne ripostuj ... ale niezbyt uprzejmy. ;-)

Answer 5

Mój ulubiony cytat z koledżu "Wspaniałą cechą standardów jest to, że jest ich tak wiele do wyboru".

Zakładam, że zadajesz to pytanie, ponieważ niestety uwikłałeś się w spór "ale nie prosiłeś o to". To może postawić cię w trudnym położeniu. Ogólnie rzecz biorąc, chcesz, aby firma zapewniała Ci standard, lub - jak wspomnieli inni - możesz wspólnie uzgodnić standard strony trzeciej. Jeśli prowadzisz firmę, która produkuje wiele tego samego typu aplikacji, powinieneś poświęcić czas na wygenerowanie "standardu".

Jeśli siedzisz w miejscu podpisania, a ktoś odmawia zapłaty z powodu "standardowych" funkcji, musisz mieć kilka przykładów miejsc, w których nie jest to standard. Na przykład w twoim przykładzie zamknij formularz na klawiaturze escape jest tylko standardowy w systemie Windows (nie w Internecie), a następnie tylko w przypadku firmy Microsoft. Właśnie otworzyłem trzy aplikacje na moim komputerze, w których ESC nie zrobił nic na formularzu.

Prawie nic nie jest standardem. W każdym danym umyśle umysł "standard" będzie oznaczać coś nieznacznie innego, a jeśli nie zostanie określony do jakiejś mierzalnej definicji, spowoduje argumentację na drodze.

Answer 6

Nic nie jest standardem, o ile nie jest zapisane i określone gdzieś w związku z projektem (lub powiązane z dokumentem specyfikacji). Jeśli nie jest zapisane, to nie jest standardowe, więc klient musi to zdefiniować.

Na innym uwaga:
Jeśli biblioteka UI robi to w jeden sposób, a to wymaga kodowania zrobić to w inny sposób (głupi przykład: chcesz, aby użytkownicy kliknij przyciski z prawej MouseButton) następnie należy zatrzymać i przemyśleć temat czego użytkownicy mogą się spodziewać.