November 29, 2006

Не мейнстрим (или снова про дизайн UI)

Интересно наблюдать за движением мысли в сообществе. Сначала были разговоры про юзабилити, потом переметнулись на SOA, сейчас вот HR стал почти основной темой дискуссии. Здорово!

А я снова буду не по теме, точнее вернусь к дизайну графического интерфейса. Сегодня Jeff Atwood высказал на своём блоге правильное, на мой взгляд, мнение:

 Deep down inside every software developer, there's a budding graphic designer waiting to get out. And if you let that happen, you're in trouble. Or at least your users will be...

В том же посте приводится пример ужасного диалогового окна и, что самое интересное, описана эволюция этого диалога от простого  к сложному и далее к устрашающе сложному.

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

Не могу не согласиться так же с выводом, который делает Jeff в заключении поста. Дизайн интерфейса, даже для самого простого диалога, должен разрабатываться профессионалом в области дизайна, а не программистом.


Comments:
Немного не соглашусь. Например, при компрессии/декомпрессии видео количество параметров, так или иначе влияющих на процесс велико. Поэтому сделать тут просто - это потерять гибкость, присущую программному продукту, что негативно скажется на пользователях. Разумеется, можно городить многостраничные помошники, позволяющие сделать ввод параметров пошагово, но... опять же будут звучать крики "да когда это закончится".

Идеально, если в программе соблюдена золотая середина - есть интерфейс и для специалиста, и для чайника. Но, если погнаться за двумя зайцами, есть риск не поймать ни одного. Поэтому надо отдавать отчет, где упрощение интерфейса допустимо (например, в КИСу на рабочем месте оператора) и где оно не принесет никакой выгоды (программа для видеомонтажа).

 


Совершенно согласен, что умеренность нужна во всём, в том числе и в простоте интерфейса. Но, скорее всего, для сложной функции (того же видеомонтажа) количество параметров изначально известно, и весь дизайн строится изначально с прицелом на э
ти параметры.
Про видео копрессию есть замечательный пример: GordianKnot. Замечательная утилита (ну или набор утилит, как угодно), но интерфес! Не пожелаешь и врагу. И есть AutoGK, который просто наворочка над GordianKnot'ом с почти полной автоматизацией и разумными значениями по умолчанию. Мне лично хватает последнего, кнопок мало, а результат такой же.
Посему, да! надо исходить из требований и знаний пользователя. Кому-то консоль с тыщей переключалок, кому-то большую кнопку с надписью "Do it".

 


Да уж, окно страшно. Причем его довольно легко сделать пригодным для использования – каждую группу вынести на отдельную закладку.

Но, вообще то, далеко не всегда оправдано большое количество настроек. Очень часто в настройки выносятся параметры, которые разработчики не знают как лучше сделать. Это показатель не более удобного и настраемого приложения, а его непродуманность. Чаще всего туда попадают настройки интерфейса (например, показывать/не показывать подписи к кнопкам тулбара).

То booter: В приложении не должно возникать 2-х разных интерфейсов (для чайников и для спецов). Любое приложение должно быть позиционировано под одну из групп. Это нужно не только для позиционирования приложения при продаже, но и при проектировании функционала и разработке интерфейса. Если изначально простое приложение при развитии начинает пухнуть то надо разделять проект на 2-3 проекта (Standard, Pro и т.д.).

 


Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?