Обсуждение

Купер практик - так что он всегда остается в поле конкретной ситуации. Что касается новизны, то первое издание было написано в 1999 году - тогда это было в новинку.

Мысли практиков, а Купер - практик, всегда интересны. Поэтому книга находит понимание у разработчиков реальных продуктов. Общие места они тоже полезны. Требуется некоторое время и некоторые действия, чтобы новое ( новое может только для конкретного человека) стало общим местом. Однако наиболее известны книга и автор "персонажным" подходом к проектированию. Когда в дизайнеры Микрософт выдумывают портрет и имя персонажа, для которого создается программа - это после Купера. Василий Петрович - интерфейс - система, а не "пользователь" - интерфейс - система. Фокус в этом. Ваш "идеальный акционер" не дает информации для проектирования интерфейса, а значит и системы.

Модель Larry Keely из Doblin Group и описание Кея - разве это не концепция ежа Коллинза?

Только, пожалуй, перевёрнутая - не для предпринимателя, а для клиента.

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

А ведь и правда!

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

Я бы подходил сначала к пониманию, какая модель организации должна быть отражена в софте, каким концептам нужно пользователя обучить. Затем уже -- интерфейс, проектируемый под персонажа. Хотя и может быть закономерен предварительный вопрос -- научить тому, чему мы хотим учить нужно какого именно персонажа ;) Так что мы, возможно, сочинению персонажа посвятим некоторое время прямо сейчас.

Для ещё большей гибкости Tapestry реализует пользователей в качестве интерфейсов, когда указанный пользователь не является однажды установленным, а генерируется при каждой имплементации.