1 декабря 2010 г.



Книга месяца: «Психбольница в руках пациентов», Алан Купер

Вот и началась зима - в этом году как никогда по расписанию. Уже два дня назад в Гродно резко выпал снег и столбик термометра упал в чувствительный для организма «минус». Лично у меня зима ассоциируется с таким «основательным» временем года. Когда хочется сесть в теплое кресло, заварить чашку чая и внимательно изучить какую-нибудь новую книжку или разобраться в новой технологии. Другими словами, рабочее настроение улучшается.

Если месяц назад мы рассматривали легкий и до безобразия позитивный «Rework» от основателей 37signals, то в этом месяце, как и полагается зимой, книжка будет более глубокая и требующая внимания. Да-да, и это несмотря на название: «Психбольница в руках пациентов» за авторством Алана Купера, эксперта в области взаимодействия приложений с пользователем.

Эта книга далеко не новинка и пережила уже одно переиздание на русском. Любой, кто интересуется проектированием взаимодействия и юзабилити давным давно ее прочитал. А так ли это? Я, конечно, не эксперт в этих областях. Но в целом они мне достаточно интересны, чтобы покупать и читать книги и статьи других авторов - Стива Круга или Якоба Нильсена. Но, к сожалению, на эту замечательную книгу я обратил внимание только недавно. И причина этому очень проста - убогость дизайна обложки первого русского издания. Именно это оттолкнуло меня от прочтения этой книги раньше, посудите сами и посмотрите на старую обложку под катом.

Ужасно, неправда ли? Ну кто станет такое читать? Ощущение что внутри третьесортный бульварный роман. Ну да ладно, вернемся к содержанию. Все же второе русское издание выглядит нормально.

На мой взгляд эта книга из разряда MUST READ. Причем независимо от того, занимаетесь ли вы проектированием взаимодействия и юзабилити приложений. Более того, если вы этим не занимаетесь, то вам тем более нужно ее прочесть. Как пишет сам автор, это не книга-руководство, это книга-обоснование. Обоснование того, почему и насколько сильно важно предварительное проектирование взаимодействия для технологических разработок, будь то софт или очередной гаджет. Каким образом это сможет значительно улучшить ваши разработки и поможет достичь с ними успеха. Конечно, есть в этой книге и так называемая практическая часть - некие поверхностные знания о проектировании взаимодействия и полезных для этого инструментах отсюда можно подчерпнуть.

Но мне в этой книге понравилось даже не это. В первую очередь я хочу отметить мысль автора о том, что мы, пользователи, должны освободиться от разработчиков (в моем конкретном случае от себя же самого :). Почему практически весь софт такой ужасный? Потому что он проектируется и разрабатывается в мире, где главные - программисты. А программисты, со всем уважением, могут сделать приложение, которое понравится только таким же как и они программистам (Homo Logicus) или апологетам (которые давно смирились с положением вещей и думают, что по-другому и быть не может).

Мы используем программы такими, какие они есть, и даже не задумываемся, что все может быть совсем по-другому. Мы уверены, что пользователь должен быть компьютерно-грамотным, чтобы эффективно взаимодействовать с нашими приложениями. Мы чтим архитектурную красоту и степень повторного использования кода в приложении вместо наглядности и простоты взаимодействия. Правы ли мы? После прочтения этой книги я начал сильно в этом сомневаться.

Почему Microsoft Word постоянно спрашивает хочу ли я сохранить свой документ, давая мне шанс случайно нажать «Нет» и потерять все свои изменения? Почему приложение не может решить такой простой вопрос вместо меня? Зачем мне, пользователю, знать, как настроить себе почтового клиента, как правильно заполнить миллион настроек? Мы, программисты, называем это компьютерной грамотностью. А ведь те времена, когда с компьютером работали исключительно люди в белых халатах, уже давно прошли. Теперь пользователю намного важнее быть исключительно грамотным в своей области. И компьютер должен лишь помогать решать проблемы пользователя в этой области, не заставляя изучать все свои внутренности. А проектирование взаимодействия до непосредственной разработки ПО должно в этом помочь.

Короче говоря, очень рекомендую эту книгу к прочтению. В первую очередь, разработчикам и их начальникам. Пока создавать действительно хорошие и полезные приложения!

Полезные ссылки:




Понравилось сообщение - подпишитесь на блог Подписка на блогFollow grodnosoft on Twitter




Читайте также:


3 комментария:

  1. в некоторых гигандтах типа офиса, при попытке сделать по-новому и удобнее наступает ещё больший капец.
    а некоторые пакеты, требующие особой грамотности, не стоит упрощать. например дизайнерский софт: корел сразу знает, что нужно сохранить бэкап документа. умный корел. так же он знает сразу, что нужно использовать настройки цветов для профессиональной печати. плохой корел. т.е. если в приложении есть куча настроек, то всё-таки придётся их изменить при первом запуске.
    это я к тому, что не стоит заниматься оптимизацией ради оптимизации.
    меня вот первое время бесил отсчёт элементов с нуля в "высших", "приближенных к человеческому" языках программирования. и по началу казалось, что ставить грабли, чтобы всё было с единицы - гораздо удобнее. но не программисту ;)

    ОтветитьУдалить
  2. @ iogan

    Такие огромные программные комплексы как Офис (как MS, так и Open) уже, пожалуй, не исправишь. Основная разработка давным давно позади и тратить огромные ресурсы на перепроектирование и разработку с нуля вряд ли кто-то будет. Хотя, MS сделали что-то похожее с Windows Phone 7 и результирующий продукт выглядит очень неплохо с точки зрения взаимодействия с пользователем (для меня пока только в теории :-)

    Что касается пакетов, требующих подготовки, тут главное не попасть в ловушку - можно любое непрактичное решение программистов оправдать тем, что, мол, пользователи подкованные, разберутся как-нибудь. Оптимизация ради оптимизации, конечно же, никому не нужна. Но это не отменяет проектирования взаимодействия, т.к. у подкованных пользователей спец. софта в любом случае есть свои цели и задачи, и они хотят их эффективно решать. Просто задачи эти более высокого уровня.

    ОтветитьУдалить
  3. со спец. софтом по сему и сложности - логично чтобы всё шло на упрощение использования опытными пользователями - но это усложняет использование новичками. получается опытный пользователь может решить свои проблемы гораздо быстрее, а для новичка всё усложняется.
    тут уж как вариант - переключатель воркспэйса, аля нуб/про.
    ну и изначально хорошо спроектированное взаимодействие терпит крах, когда в новых версиях на его модернизацию забивают и больше уделяют внимания новым плюшкам. так например в Adobe совсем дурдом. он как бы подразумевает взаимодействие флэша, иллюстратора и фотошопа, но:
    - векторное рисование в фотошопе по прежнему убого по сравнению с иллюстратором.
    - выкупленный у макрамедии флэш так и не доведён ни в векторной графике до иллюстратора ни в растровой до фотошопа по удобству.
    плюс появляются просто колоссальные по трудозатрамам плюшки вроде псевдо-3д, а простейшая оптимизация самых популярных инструментов ползёт очень медленно.
    в итоге для нормального решения задачи даже ПРО приходится заниматься постоянным импортом объектов из одной программы пакета в другую при создании или модификации. новичёк там вообще голову сломит, хотя плюшек аля "сделать красиво" появляется уйма.
    пришлось подумать на этот счёт для себя как для пользователя(плюс как для того, что будет модифицировать код в дальнейшем) при сборке персонального фото-хоста. линк в скайпе ;)

    ОтветитьУдалить