Навеяно очередным письмом про редезигн фидспота ; )
Навеяно очередным письмом про редезигн фидспота ; )
systat -if
Rule 1a. To make an interface habituating, it must be modeless.
Rule 1b. To make an interface habituating, it must be monotonous.
When using a product to help you do a task, the product should only help and never distract you from the task.
В качестве основных принципов отмечены:
1. Отсутствие модальности. При использовании какого-либо жеста (хоткея, пункта в меню под номером N) пользователь должен всегда получать один результат.
2. Монотонность. Для каждого действия должен существовать только один жест.
4. Акцент на формирование привычек. Главное чтобы пользователь мог сформировать привычки и выполнять действия не глядя.
3. Видимость. Всё что программа может сделать должно быть так или иначе видимо.
5. Человек может уделять внимание только одной задаче. Всплывающие сообщения на краю экрана или даже запросы подтверждения скорее всего будут не замечены.
В этом наборе единственное сомнительное правило это видимость, поскольку, как только привычки сформировались, она становится не нужна. Все остальные требования подтверждены рядом ссылок на исследования и опытом большинства пользователей.
Несмотря на то, что это замечательные принципы автор не может им следовать до конца. Так с первых страниц описания своего интерфейса он предлагает разрешить выделение и запуск команд не только с клавиатуры, но и при помощи графического устройства ввода (ГУВ), что является явным нарушением требования монотонности. Также он предлагает вместо одного выделения использовать стек выделений и позволить командам использовать произвольное число последних выделений как аргументы, что нарушает принцип видимости, поскольку глядя на название команды сложно определить сколько она требует аргументов. Кроме того автор, видимо никогда не использовавший Windows-клавиатуры, предлагает решить проблему apple-клавиатур на которых для удаления символов существует только backspace, введением режимов для курсора ввода текста (если его перемещали, то backspace работает как delete. После набора одного символа снова работает как backspace) и нарушением первого правила, вместо простого добавление клавиши Delete на клавиатуру. Также автор явно забывается и пытается перенести элементы интерфейса из Canon Cat (http://ru.wikipedia.org/wiki/Canon_Cat по описанию Раскина очень интересная машина) в zoomable user interface. Так в Canon Cat отказались от использования иерархической файловой системы. Вместо этого все документы были соединены в один длинный текст, содержащий символы разрыв документа, обозначающие начало и конец отдельных документов. В ZUI такой подход выглядит более чем странно уже потому, что при нём теряются плюсы от способностей человека к пространственной навигации. Описание ZUI в этой книге — это первое место, где действительно необходимо ГУВ. Использование ГУВ в остальных описанных в книге случаях противоречило требованию монотонности и, при применении GOMS анализа, давало как минимум не лучшие результаты. Но так как автор не заметил этой проблемы (или решил не описывать подробно по той причине, что он не знает как добиться видимости без ГУВ) нет ни одного слово про mouse-less ZUI. Так что вопрос их эффективности придётся решать читателю. Чтоб не быть голословным вот common-lisp.net реализация такого клавиатурного интерфейса и видео common-lisp.net с примером его использования.
Таким образом в книге стоит читать только первые четыре главы. Весь остальной текст, зачастую, не соответствует собственным принципам автора. Но при этом я таки вынес оттуда пару полезных ссылок на другие труды. Из того, чем хочется поделиться, это Psychology of computer programming за авторством Weinberg G.M.
citeseerx.ist.psu.edu ). Это замечательно, кроме двух основных идей:
1. Разработка должна быть нацелена только на создание языка верхнего уровня, что в приложении к современным интерфейсам значит вылизывание See-and-Point интерфейса.
2. Язык верхнего уровня должен быть безопасным в том смысле, что любой набор команд в данном языке должен делать что-то осмысленное.
Когда оба этих пункта используются одновременно, то интерфейсы получаются статичными и учитывают только те use case'ы, которые разработчики смогли придумать. Если же отказаться от безопасности в пользу богатства языка, либо от фокусировки на языке верхнего уровня в пользу красоты и удобства языка среднего уровня, то в результате должны получаться более удобные системы.
Сегодня построение интерфейсов соответствует идеям M.P.Ward высказанным в статье Language Oriented Programming ( 1. Разработка должна быть нацелена только на создание языка верхнего уровня, что в приложении к современным интерфейсам значит вылизывание See-and-Point интерфейса.
2. Язык верхнего уровня должен быть безопасным в том смысле, что любой набор команд в данном языке должен делать что-то осмысленное.
Когда оба этих пункта используются одновременно, то интерфейсы получаются статичными и учитывают только те use case'ы, которые разработчики смогли придумать. Если же отказаться от безопасности в пользу богатства языка, либо от фокусировки на языке верхнего уровня в пользу красоты и удобства языка среднего уровня, то в результате должны получаться более удобные системы.
Enough said.
А потом один раз сам идеальный интерфейс, помню во сне я еще ахуевал какой он идеальный и пиздатый, а применить его можно почти везде лишь немного доработав. Жаль что утром помнил только что ахуевал, а сам интерфейс нет)
А что снится тебе ?
festlang.berlios.de
как заставить фестиваль (синтезатор речи) говорить на москальской мове
как заставить фестиваль (синтезатор речи) говорить на москальской мове