|
 |
Персональные инструменты
Просмотры |
|
Персональные инструменты |
|
||
|
|
Психбольница в руках пациентовМатериал из CustisWikiЭто снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений. «Психбольница в руках пациентов. Алан Купер об интерфейсах. Почему высокие технологии сводят нас с ума и как восстановить душевное равновесие. Издание исправленное»
Рецензии наших сотрудниковСтас ФоминНеоднозначная книга. Хотя надо видимо, отдать должное, в свое время (1999 год), она видимо дала здорового пинка разработчикам, развернув маятник от одной крайности — «Пользователь идиот, если не обладает Компьютерной Грамотностью», к другой — «Идиот — это программист, не выпускайте его из трюма к Людям, спускайте ему Еду и Разжеванные Задания». Да, идеи Купера — что разработкой интерфейсов должны заниматься только специально обученные и генетически отобранные[1] люди. Эти Непогрешимые Проектировщики Интерфейсов имеют абсолютную власть и полный карт-бланш — не ограничено время проектирования («лучше день потерять, затем за час долететь …и завоевать весь рынок…»), проблемы и экономия времени программистов их не волнует — «если вы настоящие гики, вы должны любить сложные задачи, так что SHUT UP и сделайте на 100% как мы скажем». Соответственно в книге практически нет положительных кейсов — в основном, истории об ограниченных ленивых программистах, не просчитавших последствия, сделавших как легче им и не подумавших о Пользователе… …прости не увидел, пропали билеты, засохли цветы ©…. Вот если бы были Идеальные Проектировщики (ну очевидно, как пример предлагается фирма Купера), то вот, они бы года за три поняли правильную ментальную модель пользователя и спроектировали интерфейс, по которому любой пользователь стартует без обучения и не приходя в сознание. Что можно сказать на это? Ну да, программисты склонны к локальной оптимизации, при отсутствии четко известных требований к продукту (а это почти всегда так), они склонны оптимизировать единственный более-менее ощущаемый параметр — собственные трудозатраты (ну плюс стоимость работы субподрядчиков или покупных средств/библиотек). И это на самом деле не так уж и плохо. Ведь откуда взять в реальном мире Настоящих Идеальных Проектировщиков Интерфейсов? Откуда взять Настоящие Пожелая Пользователя, особенно, когда их не знает он сам? На практике получится что-то типа: Принцип работы жаждоутолителя очень интересен. Когда нажата кнопка Напиток, он мгновенно, но очень точно анализирует вкусовые бугорки клиента, производит спектральный анализ его обмена веществ, и посылает пробные микросигналы в центры вкусоощущения, чтобы проверить, что клиент лучше всего переварит. Тем не менее, никто точно не знает, зачем он это делает, потому что он неизменно выдает чашку жидкости, которая почти, но все-таки не совсем, непохожа на чай. Жаждоутолитель разработан и прозводится корпорацией Сириус Кибернетикс. Отдел жалоб этой фирмы занимает сейчас все материки трех первых планет звезды Тау системы Сириуса. © Дуглас Адамс. Путеводитель хитч-хайкера по Галактике. Или еще более веселый пример, когда совсем уж идут на поводу у клиента, руководствуясь принципом «User is the King»:
Но даже, если уверовать и в существование Идеальных Проектировщиков, очевидно, что полно ситуаций, когда «У нас это не работает» © IT Crowd. Например, коммерческий софт для кассовых-учетных-промышленных систем. Это никакой не плейер или фотошоп. Во-первых, у пользователя нет почти никаких врожденных ментальных моделей сложных бизнес-процессов или промышленных операций, особенно если этот клерк, кассир или рабочий видит только фрагмент общей картины. Да такой интерфейс не обязан быть sexy, ему не обязательно быть самоочевидным. За работу с ним люди получают деньги, они вполне могут пройти обучение по работе с ним, а дальше — он может быть внешне достаточно дубовым, но главное, чтобы он был адекватен пользовательским задачам, чтобы там не было ежедневно проходимых «кружных путей» или «острых углов» раздражающих пользователя своей регулярностью и неизбежностью. Во-вторых, важна тут именно скорость реализации — если вы встанете в позу, что процесс разработки будет идти по жесткому каскадному процессу с долгим проектированием Идеальными Юзабилистами до спуска ТЗ программистам, то результат ГАРАНТИРОВАННО будет одним — система будет реализована. Гораздо быстрее. Конкурентами. И в—третьих (по сути, дополнение во-вторых), каскадное долгое проектирование «не покатит» из-за постоянного дрейфа требований, изменений бизнес-процессов, технологий, и т.п. Так что наверное, про эту книгу, в отличие от книги, например, Джефа Раскина, нельзя рекомендовать как MUST READ для программистов. Не стоит. Хотя, с другой стороны, столкнувшись с очередным убогим вебинтерфейсом, или наблюдая унылые формы «enteprise software», хочеться распечатать большой демотиватор «Читай Раскина и Купера, псих! Читай их до конца, сука!» (отсылка к классике — «Погладь кота!». Ссылки
Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации. |
 |
 |
 |
