Серед багатьох бізнес-користувачів та клієнтів існує загальна думка, що коли він виглядає повноцінним, він майже завершений. Як ви, напевно, знаєте, це далеко не правда. Можливо, це виглядає добре, але без бекенда, і деякі користувачі думають, що зробити його красивим - це 80% роботи, а не 20% ( або інші 80% ).
Незліченна кількість розробників може розповісти про це страхіття - отримати макет сторінок, зроблених в Microsoft Word, за допомогою знімків екрана якогось іншого інструменту, і клієнт сказав: "так, ви майже зробили це?"
Потрібно відстежувати його так, щоб усі деталі були зроблені, коли це зроблено. Спроба зробити все заднім числом, а потім весь передній кінець призведе до того, що кінцевий користувач подумає, що ви нічого не робите, і запитає, чому вам платять, коли за це нічого не показувати. З іншого боку, спершу переднім кінцем, і ви знайдете, що кінцевий користувач вносить зміни, не потребуючи всьому часу.
Найгірший випадок із "одним першим, а другим", коли ви потрапляєте в іншу частину, виявляєте, що він зовсім не відповідає дизайну.
Таким чином, будуйте і те, і інше. Покажіть прогрес в передньому кінці, змусьте задню частину працювати з тим, що ви будуєте. У багатьох випадках є гарною ідеєю надати додаткові складання і переконатися, що ви робите те, що хоче клієнт (це потрапляє в Agile). Якщо занадто довго виходити з «видимих авансів», це може зашкодити відносинам з клієнтом (це для обох випадків «все виглядає зроблено рано» і «нічого не робиться до самого кінця» - клієнту важко бачити, як написано рамки або одиничні тести або санітарія даних у міру виконання).
Джоел писав про це у "Айсберг-секрет", відкритий :
Важливі наслідки два. Якщо ви покажете непрограмеру екран, який має користувальницький інтерфейс на 100% гарний, вони подумають, що програма майже зроблена.
Люди, які не є програмістами, просто дивляться на екран і бачать деякі пікселі. І якщо пікселі виглядають так, як вони складають програму, яка щось робить, вони думають, "о, боже, наскільки складніше можна зробити так, щоб це фактично працювало?"
Великий ризик тут полягає в тому, що якщо ви знущаєтесь над інтерфейсом спочатку, імовірно, щоб ви могли поговорити з клієнтом, то всі будуть думати, що ви майже готові. І тоді, коли ви будете проводити наступний рік, працюючи «під прикриттями», так би мовити, ніхто насправді не побачить, що ви робите, і вони подумають, що це нічого.
Це ще раз підтверджено в дописі на блозі Не робіть демонстраційний вигляд виконаним, у якому є такий корисний графік:
Зверніть увагу на те, що два варіанти, як правило, відображають "завершити роботу інтерфейсу" (і тоді ви очікуєте, що незабаром будете виконані) та "завершити запуск" (і тоді клієнт переживає за те, щоб ви пропустили термін).
Як щось зроблено, має відповідати тому, як щось зроблено.
Кожен розробник програмного забезпечення зазнавав цього багато разів у своїй кар’єрі. Але інструменти для настільних публікацій призводять до того ж головного болю для технічних письменників - якщо ви показуєте комусь грубі проекти, які ідеально оброблені та відформатовані, вони вважають це більш виконаним, ніж ви хотіли б. Нам потрібна відповідність між тим, де ми є, і де інші сприймають нас.
Ця стаття також пропонує важливий момент щодо типу зворотного зв'язку, який ви отримуєте з різними рівнями виконаності користувальницького інтерфейсу. Якщо у вас щось виглядає повноцінним, ви, швидше за все, отримаєте відгуки про те, "чи можете ви змінити шрифт", ніж "цей макет не працює - вкладки занадто багато".
Для тих, хто бореться з цим у світі Java Swing, є зовнішній вигляд, який називається Нарізка, завдяки чому інтерфейс користувача не виглядає повноцінним (навіть якщо він є).
Головне тут - зробити так, щоб він не виглядав зробленим. Наявність інтерфейсу користувача виглядає повноцінним - це сигнал багатьом діловим користувачам про те, що додаток є повним (навіть якщо на ньому є лише кілька статичних сторінок без будь-якої логіки за ним чи щось вбудоване в конструктор інтерфейсів).
Подальше читання (та посилання зі статті):
