Персональные инструменты
 

Интерфейсы — битва за право влияния (Ольга Павлова, ADD-2011)

Материал из CustisWiki

(перенаправлено с «1a3-ui-battle-for-influence-pavlova»)
Перейти к: навигация, поиск

Аннотация

Докладчик
Ольга Павлова
  • Кто и почему влияет на интерфейс?
  • Как контролировать партизанские изменения и использовать их на благо проекта?
  • Что делать, если вас поставили перед фактом модификации интерфейса?
  • Есть ли способы удержаться от бесплодных дискуссий и ограничиться продуктивными?
  • И наконец, почему всем так важно приложить руку к интерфейсам и можно ли направить эту энергию в мирное русло?

Видео

Скачать
http://ftp.linux.kiev.ua/pub/conference/peers/addconf/2011/1a3-ui-battle-for-influence-pavlova.avs.avi


Для этого доклада нужен подкаст (аудиозапись)?

  •  Да, многое понятно и без видео части, есть смысл его прослушать.
  •  Нет, аудиозапись бесполезна (не понять без видео или вообще мало смысла в докладе).

Презентация



Примечания и отзывы


Ольга Павлова рассказывала больше про то, как убедить себя, что интерфейс должен делать профессионал. Если честно, я был в тумане после собственного доклада, так что скорее всего слушал мимо. ©
Ольга Павлова подняла знамя борьбы за права пользователей. Круто. ©
Ольга Павлова поразила просто. Наверняка я в сто первом ряду поклонников, но тем не менее. Стиль, подача, энергия, материал — аплодирую стоя. ©
У Ольги Павловой был интересный лично для меня доклад о необходимости избежания хамства в интерфейсе. Я сейчас довольно плотно занимаюсь пользовательским интерфейсом и стараюсь делать его лучше, удобнее, более открытым и дружелюбным. Не всё получается. Что-то получается хорошо но не с первого раза, что-то так и не удается доработать до идеала. Хотелось бы воспользоваться услугами Usability Lab, попробую поставить вопрос перед руководством 8) ©

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

Что касается практических советов, то я услышал один — выделяйте роли, для которых проектируете интерфейс. Хорошо, если они выделяются в исследовании бизнеса, но даже если такой возможности нет, роли «с потолка» лучше, чем их отсутствие. Наверняка были и другие советы — раньше, чем я пришел.

В целом, для меня доклад — относительно понятные вещи. Но по опыту — они понятны далеко не всем разработчикам. И на конференции, по отзывам — не все эти идеи воспринимали, может быть из-за несколько директивной энергетики доклада. Хотя это просто общая энергетика докладчика проявляется, а никак не позиция знающего истину и учащего ей. Мне доклад очень понравился.

Докладчик — Ольга Павлова из Usability Lab.

Рассказ про проектирование взаимодействия. Мне показались знакомыми основные идеи, озвученные в докладе — читал их в книжке Алана Купера «Об интерфейсе. Основы проектирования взаимодействия». Укажу основные моменты доклада.

  • В начале процессе проектирования взаимодействия происходит выделение персонажей (ролей) и проектировании интерфейса взаимодействия для них. Персонаж — некий собирательный образ одного из пользователей интерфейса (кстати, по мнению Купера важен полный портрет — пол, возраст, образование, профессия, семейное положение и т. п. Этот персонаж даже получает собственное имя). Затем юзабилисты пытаются построить модель взаимодействия персонажа с разрабатываемой системой.
  • Ряд проблем при проектировании:
  1. Избыток контролов
  2. Тексты на интерфейсе (формулировки). Считает, что самовольные правки текстов — преступление.
  3. Сообщения об ошибках
  4. Интерфейсное хамство
  • Недоделанную работу показывать нельзя — можно отвратить пользователя. Если всё-таки приходится — нужно обставить это «ритуалами».
  • Бесконечные согласования неважных деталей интерфейса с заказчиком — зло. Но в процессе согласований можно получить и действительно важную для проектирования информацию (?)
  • Результаты обсуждения необходимо фиксировать в модели, а не в виде «бантиков сбоку».




Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».