DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 20:29

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 38 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 22 Декабрь, 2011 15:02 

Зарегистрирован: Понедельник, 19 Декабрь, 2011 23:03
Сообщения: 18
В этой теме я хочу рассказать вам, как при проектировании сайта, с помощью "Метода персонажей". Я попробовал вместо диаграмм взаимодействия, нарисовать Дракон-Схемы.

Кратко о методе персонажей:
Метод персонажей это один из самых мощных и эффективных инструментов проектирования взаимодействия.
Мы выдумываем несуществующих пользователей и проектируем для них. Мы называем таких несуществующих пользователей персонажами и они представляют собой необходимую базу качественного проектирования взаимодействия.

О персонаже.
Персонажи- не реальные люди, но они представляют реальных людей в процессе проектирования. Это гипотетические архетипы реальных пользователей. Будучи воображаемыми, они, тем не менее, определяются достаточно жестко и точно. На практике мы не столько «выдумываем» персонажи, сколько обнаруживаем их в качестве побочного продукта процесса расследования. Но мы действительно выдумываем их имена и личные сведения.
Персонажи определяются своими целями. Цели же, разумеется, определяются персонажами. Мы определяем, какие персонажи имеют отношение к делу, а также их цели.

Для того чтобы понять как взаимодействует пользователь с системой, создаются Сценарии взаимодействия (Это описание того как должны работать функции системы).
Существует два типа сценариев:
Первый тип содержит описание последовательности шагов персонажа, идущего по системе.
Второй тип сценариев содержит описание возможных последствий для системы.
Метод сценариев позволяет заставить действовать выявленные персонажи.

Мои Дракон-Схемы писались на основании Сценариев взаимодействия. Вот этих двух персонажей(Олег и Эллина)! Они относятся к пользователям организации для которой разрабатывается сайт и они будут размещать на нем информацию.
ИзображениеИзображение

Ну и вот сама Дракон-Схема.
Изображение
Комментируйте и пишите что вы думаете по этой теме.


Последний раз редактировалось Павел Макаров Пятница, 23 Декабрь, 2011 16:52, всего редактировалось 5 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Декабрь, 2011 15:08 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 189
Откуда: Россия, Санкт-Петербург
Павел Макаров писал(а):
В это теме я хочу рассказать как в проектировании сайта, при помощи "Метода персонажей" я использовал вместо диаграмм взаимодействия использовал Дракон-Схемы.

Павел Макаров писал(а):
Комментируйте и пишите что вы думаете по этому всему.
Я думаю что очень много невладения русского языка.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Декабрь, 2011 15:17 

Зарегистрирован: Понедельник, 19 Декабрь, 2011 23:03
Сообщения: 18
Александр Ильин писал(а):
Павел Макаров писал(а):
В это теме я хочу рассказать как в проектировании сайта, при помощи "Метода персонажей" я использовал вместо диаграмм взаимодействия использовал Дракон-Схемы.

Павел Макаров писал(а):
Комментируйте и пишите что вы думаете по этому всему.
Я думаю что очень много невладения русского языка.

Приношу свои извинения! Отправил черновик! Сейчас все поправил.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Декабрь, 2011 15:40 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 189
Откуда: Россия, Санкт-Петербург
В целом интересно, только слово "сертефикаты" режет глаз. И жаль, что Эллина разведена, очень жаль. А что случилось-то? Муж пил?
А в жизненных целях "дети" во множественном числе - это значит, что она хочет ещё ребёнка родить? Или у неё что-то другое в планах? Усыновление?

Не совсем понятно, зачем после ответа "Да" на вопрос "Закончить работу с сайтом?" нужно ещё "Нажать кнопку выход".
И ещё вопрос: Олег Викторович каждого подтверждения публикации цензурного отзыва должен будет отвечать на вопрос "Закончить работу с сайтом?"? По схеме получается, что так.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Декабрь, 2011 20:30 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
В дракон-схеме Павел Макаров фактически отображает бизнес-процесс.
При этом исполнитель, т.е. персонаж, указывается в верхней части иконы "Полка".

Это еще один из способов отображения бизнес-процессов средствами языка Дракон.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 23 Декабрь, 2011 14:43 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Маршрутной логики бизнес процессов (м.б. показана также, как здесь)... а их сущностный состав визуально отражается схемами типов, как здесь... а организация "персонажа" - схемами исполнителя, как здесь (типа "что в голове и что в машине и как это всё связано" :))...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 23 Декабрь, 2011 18:16 

Зарегистрирован: Понедельник, 19 Декабрь, 2011 23:03
Сообщения: 18
Александр Ильин писал(а):
И жаль, что Эллина разведена, очень жаль. А что случилось-то? Муж пил?
А в жизненных целях "дети" во множественном числе - это значит, что она хочет ещё ребёнка родить? Или у неё что-то другое в планах? Усыновление?

Все личные сведения персонажей выдуманы!

Александр Ильин писал(а):
Не совсем понятно, зачем после ответа "Да" на вопрос "Закончить работу с сайтом?" нужно ещё "Нажать кнопку выход".
И ещё вопрос: Олег Викторович каждого подтверждения публикации цензурного отзыва должен будет отвечать на вопрос "Закончить работу с сайтом?"? По схеме получается, что так.

Спасибо, с учётом ваших комментарий схема немного изменилась.
Изображение

Геннадий Тышов, я читал темы по поводу бизнес-процессов. И окончательно пришел к выводу, что в данном случае исполнителей лучше указывать в иконе "Полка".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 23 Декабрь, 2011 18:24 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Павел Макаров, вы студент, можете рассказать, а другие студенты с Драконом знакомы?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 23 Декабрь, 2011 19:09 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Павел Макаров писал(а):
я читал темы по поводу бизнес-процессов. И окончательно пришел к выводу, что в данном случае исполнителей лучше указывать в иконе "Полка".

Поддерживаю. По моему мнению, Вы совершенно правы. С учетом Ваших слов "в данном случае".

Уважаемый Павел Макаров!

Большое спасибо за Вашу инициативу.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 23 Декабрь, 2011 19:20 

Зарегистрирован: Понедельник, 19 Декабрь, 2011 23:03
Сообщения: 18
Геннадий Тышов, лично я таких к сожалению не знаю. Я на 4 курсе начал изучать "Проектирование взаимодействия". И в этом году, мой научный руководитель рекомендовал, вместо диаграмм взаимодействия на UML, попробовать Дракон-Схемы. Вот так я и начал своё знакомство с Драконом. Первым источником информации для меня была книга "Как улучшить работу ума".


Владимир Паронджанов, позже я планирую разместить Дракон-Схему, по сценариям другой группы персонажей (посетителей сайта). Там возможно, будет реализовано по другому.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 23 Декабрь, 2011 19:33 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Уважаемый Павел Макаров!

Если не трудно, сообщите, пожалуйста, следующее:

1. Полное название ВУЗа.

2. Название факультета

3. Название кафедры

4. ФИО уч. степень и уч. звание Вашего научного руководителя.

5. Это у Вас курсовая или дипломная?

6. Если у Вас есть одна и та же тема на UML и на ДРАКОНе, опубликуйте, пожалуйста, оба варианта. Чтобы можно было сравнить.

Если Вы по каким-то причинам не хотите отвечать, не обращайте внимания на мои вопросы. Игнорируйте их.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 23 Декабрь, 2011 20:17 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Павел Макаров,
вопрос "Закончить работу с сайтом?" - назойливый и непонятно кому, можно сделать сооветствующий пункт "Меню администратора".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 23 Декабрь, 2011 22:14 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Владимир Паронджанов писал(а):
Уважаемый Павел Макаров!
...
6. Если у Вас есть одна и та же тема на UML и на ДРАКОНе, опубликуйте, пожалуйста, оба варианта. Чтобы можно было сравнить.

Да, мне тоже было бы интересно посмотреть на аналогичную схему на UML.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 23 Декабрь, 2011 22:18 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Павел Макаров писал(а):
Комментируйте и пишите что вы думаете по этой теме.

Ввод логина и пароля однозначно определяет пользователя (сотрудника).
У разных пользователей (сотрудников) могут быть одинаковые права (обязанности), а могут быть и разные.
Из приведённой схемы видно что у Олега и Эллины права (обязанности) разные.
Имхо, в этом случае лучше скрывать возможности, неиспользуемые данным пользователем (сотрудником).

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

Наверно, логичнее было бы построить алгоритм независимой обработки информации на сайте.
Тогда пользователи (сотрудники) не зависели бы друг от друга и могли бы работать в произвольные моменты времени, в т.ч. и параллельно.

Чем виртуальные персонажи лучше обезличенных, например, администратор — модератор?

Обновление информации о ценах и загрузка файла с прайс-листом это одно и то же?

Павел Макаров писал(а):
я читал темы по поводу бизнес-процессов. И окончательно пришел к выводу, что в данном случае исполнителей лучше указывать в иконе "Полка".

С учётом сказанного выше, предложу свой вариант схемы (см. рис. ниже):
Вложение:
log1.png
log1.png [ 67.41 КБ | Просмотров: 25077 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Декабрь, 2011 11:09 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Ильченко Эдуард писал(а):
Чем виртуальные персонажи лучше обезличенных, например, администратор — модератор?


Ответ я нашел в сети. Лучше всего прочитать оригинал с картинками:
http://www.gui.ru/platon/?p=20

Но если кому не хочется смотреть ссылку, я кое-что скопировал

Цитата:
28.09.2006Платон Днепровский
Комментариев: 14

О пользе персонажей

Практика, Инструментарий

Использование персонажей (persona) – один из способов сбора и формализации требований к интерфейсу. Но, по мнению некоторых коллег и заказчиков, их польза часто сомнительна, и кажется, будто персонажи – «красивая сказка», не имеющая практической ценности.

Цитата:
Платон, у меня такой вопрос по практическому использованию вами персонажей: насколько велика, на ваш взгляд, связь между характеристиками разработанных вами персонажей и интерфейсом созданной системы? Как осуществляется переход от персонажей к самому интерфейсу? Есть ли вообще польза в их использовании?

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

– сомневается в эффективности персонажей Геннадий Драгун в комментариях к статье про работу.


В отсутствие персонажей как таковых, даже при наличии полных и формальных требований к целевой аудитории (ЦА), все, что мы держим в голове о пользователях в ходе проекта – это то, что они вообще есть.

Как правило, если в маркетинговом исследовании написано, что наша ЦА – это пожилые женщины с минимальным уровнем компьютерной грамотности, мы представляем пользователей так (как нам хочется):

Эдуард, тут хорошая фотография

Cферические кони в вакууме

При этом все понимают, что это не совсем так.

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

Основные (и проверенные на опыте) плюсы от использования персонажей следующие:

■Сбор персональных пользовательских требований к интерфейсу

■Структуризация и ранжирование требований

■Повышение качества коммуникации с другими участниками проекта

■Упрощение организации юзабилити-тестирований

Немного поподробнее о каждом пункте.

Сбор требований

Каждый раз, создавая персонажа, мы «вживаемся» в него, чего не происходит при простой фиксации характеристик ЦА. Да, мы все знаем, что если уровень компьютерной грамотности у пользователей низкий – нужно любой шаг системы максимально «разжевывать», а если пользователь в возрасте – делать контролы крупнее. Это «знание» - один из аргументов против применения персонажей: дескать, итак все уже известно, и нечего тут писать ЖЗЛ вместо ТЗ.

На самом деле главная прелесть персонажей – не фиксация их характеристик, влияющих на интерфейс, а прослеживание их действий полностью, учитывая всякие отвлекающие задачи, дополнительные артефакты и прочее. И, поверьте, отсюда «выкапывается» огромное количество полезной информации, которая, подчас, очень сильно влияет на конечный продукт. Примеров множество. В одном случае осознание того, что в автосервисе у мастера могут быть грязные руки повлияло на всю идеологию системы. В другом, одном из наших любимых примеров, моделирование работы страховых операторов (проект для Росгосстраха), выявило ряд «мелких» особенностей, как-то: желание как можно раньше уходить с работы (сразу по окончании рабочего дня) или нередкое отсутствие части необходимых документов у страхователей. Эти особенности очень сильно изменили не только интерфейс, но и системные «потроха», и формат БД. В частности, пришлось вводить возможность промежуточного сохранения документов, чего не было предусмотрено изначально.

Структуризация и ранжирование

Даже имея под рукой все (пользовательские) требования, зачастую очень непросто их транслировать в интерфейс. Некоторые требования, например, напрямую противоречат друг другу. Когда же они разбиты по персонажам, степень важности которых также известна, все значительно проще. Одному персонажу эта функция нужна, другому мешает? Давайте смотреть, кто для нас (в смысле реализации бизнес-задачи) важнее. Давайте смотреть, кто с какой частотой пользуется системой. И в результате мы наверняка сможем «спрятать» неудобную для кого-то функцию, оставляя ее при этом доступной для другого пользователя. Или выясним, что необходимы несколько вариантов интерфейса – кстати, достаточно частый случай, но имея все требования «в куче» это совсем не очевидно. Вообще «заточка» интерфейсов под персонажей часто весьма эффективный способ. Иначе в лучшем случае придумываются «Лайт» и «Про» версии, но чаще реализуется «все в одном».

Коммуникация

Не такое явное, но, тем не менее, весьма полезное преимущество. Как правило, в проекте принимают участие минимум 2 стороны (заказчик и разработчик интерфейсов), чаще 3 (+ техразработчик), иногда 4 (+ бизнес-консультант). И практически любое более-менее серьезное предложение со стороны юзабилити-специалистов всегда обсуждается разными сторонами. Поверьте, намного проще аргументировать идею, говоря, что именно эта штука, которая затянет разработку на 2 недели и увеличит бюджет, жизненно необходима не вообще «нашим пользователям», а конкретному Петру Михалычу со зрением -6, особенно если Михалычи составляют процентов 40 всех пользователей. Да, когда мы описывали и обсуждали жизнь Михалыча, все смеялись и не принимали его всерьез. Но потом оказывается, что поставить себя на место Петра Михалыча значительно проще, чем на место сферического коня в вакууме.

Те же самые техразработчики, имея перед собой портрет Петра Михалыча и его жизнеописание (а мы стараемся в каждом проекте сделать такие листовки) принимают значительно более адекватные самостоятельные решения, нежели «просто ни для кого». Проверено не раз.

В качестве примера вспоминается тот же проект с «Росгосстрахом»: уже после завершения проекта ИТ-команда поехала на пробное внедрение куда-то «в регионы». Нам ребята потом рассказывали, как их поразило точное совпадение аудитории с теми персонажами, что мы смоделировали в проекте. И насколько проще им было найти общий язык с ними, так как все их нужды и особенности были продуманы и сто раз обсуждены, пусть со смехом и скепсисом.

Юзабилити-тестирование

Готовые или полуготовые интерфейсы тестируются на группах пользователей – фактически, на тех же персонажах, только реальных. А подготовка к тестированию требует значительного количества ресурсов: необходимо разработать сценарии тестирования, дополнительные задания, да и просто составить «скринеры» для рекрутинга респондентов. Имея же описание персонажей, мы «легким движением руки» получаем из них необходимые данные. Так что здесь мы прилично экономим на трудозатратах.

Это все действительно работает, хотя в начале нам тоже это казалось игрой. Можно не называть эти модели «персонажами», но когда делаешь все «по уму», в результате все равно выходят ОНИ – как в том анекдоте, когда, что ни спроектируй, при сборке все равно получается танк. Можно не давать им имена, не включать в описание проекта «типичный день Петра Михалыча», не визуализировать (подбирать фото). Но раз вся информация уже собрана, почему бы не потратить еще 15 минут, и не получить полноценную модель – она сильно облегчит работу хотя бы в плане коммуникации.

И все будут помнить, что, на самом деле, пользователь у нас таков:

Эдуард, тут чудесная фотография

Реальный Пётр Михалыч

И еще раз кратко остановлюсь на вопросе Геннадия:

Как осуществляется переход от персонажей к самому интерфейсу?

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

И, во-вторых, в ходе разработки-доработки-оптимизации интерфейса, в режиме «быстрых правок», нам банально проще встать на место Петра Михалыча.

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

Дальше идут Комментарии (14)

Цитата:
Богдан 02.10.2006 10:49

Вопрос: А как из десяти выбранных персонажей определить главного, под которого будет проектироваться И.?


Цитата:
Иван Дегтяренко02.10.2006 15:56

Основная идея следующая. У нас, допустим, есть персонаж A и персонаж B. Интерфейс, разработанный под персонажа A “подгоняется” относительно небольшой кровью под персонажа B, а интерфейс, идеальный для персонажа B ну никак не подходит персонажу A, то нужно проектировать подпероснажа A.

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


Цитата:
Евгения04.10.2006 16:30

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


Цитата:
Геннадий Драгун05.10.2006 19:35

Спасибо огромаднейшее за статью. Даже и не ожидал, что тот мой немного скептический пост вызовет такую вот реакцию. Сразу бросился перечитывать литературу по тематике персонажей (до Купера, правда так пока и не добрался, лежит себе в темном уголке винчестера).

А вывод я сделал простой и очевидный: «У каждого из орудий юзабилити инструментария есть своя область применения. » Это орудие наиболее эффективно, когда применяется именно в этой области, когда соблюдаются определённые начальные условия.

Так и с персонажами. Вывод про них такой: «Персонажи не берутся с потолка.» Они должны быть на чем-то основаны: на описании целевой аудитории, маркетинговом исследовании, на результатах собственного наблюдения за целевыми пользователями…

Расскажу о своей ситуации - offshore разработчика интерфейсов. Коммуникация с заказчиком идёт чаще всего виртуально, прямой контакт очень редок, чаще через посредника в виде Бизнес-Аналитика или Менеджера Проекта. К самому целевому пользователю доступа нет. Он нём вообще ничего не известно кроме пары строк текста.

У заказчика о нем свои, обрывочные, не всегда точные представления. Бывает, что даже составить какую-то модель пользователя составить невозможно. (Попробуйте представить себе, как будет работать с вашей системой китайский инженер?)

В такой ситуации персонажи, да и многие другие юзабилити методы, связанные с получением информации непосредственно от конечных пользователей, не работают. Тут эффективнее методы discount/ guerilla юзабилити, опора на логику и на ревью.


Цитата:
Геннадий Драгун05.10.2006 19:43

Богдан - если выбрано целых 10 персонажей, то значит неправильно выбирали. Перефразируя закон Парето: в 4 случаях из 5 вашей системой будут пользоваться только 2 основных. Остальные 8 - в оставшемся одном случае. Разрабатывать нужно под этих главных 1-го или 2-х, но так чтобы система оставалась хотябы минимально пригодна для пользования и неосновными 8-ю.
Когда-то читал статью на похожую тему, о том, что невозможно разработать систему для большого количества персонажей - максимум 2-3. У User-Cenered людей есть поговорка: “Дизайн для всех - дизайн для никого.” Хотя с этим можно поспорить.



Цитата:
Платон Днепровский09.10.2006 17:50

Евгения,
Сведения собираются в основном именно так, как Вы и написали - интервью, тестирования и полевые наблюдения. Да, это и ресурсов требует, и не всегда возможно.

Если не получается - мы стараемся собрать побольше информации от заказчика, иногда он нам предоставляет весьма полезные маркетинговые исследования.

Но в этом случае максимум, что нам дается - это именно описание характеристик “персонажа”, а всю нужную нам информацию о контексте работы мы вынуждены моделировать сами.

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

Вот этот случай - самый сложный, тут приходится искать и сторонние публикации и описания, и выуживать у заказчиков специалистов, представляющих работу пользователей с разных сторон. А потом интегрировать это все в “полусинтетического” персонажа.

Вообще без пользователей нельзя. Другое дело, что иногда в роли пользователей могут выступать друзья, коллеги, да и сами разработчики (если подходят) - вот, пожалуй, единственный случай “малой крови”.

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



Цитата:
Проектирование от Microsoft. Современное состояние дел04.05.2007 21:55
7

[…] На выходе получилась диаграмма с описанием типовых предприятий (2 типа), их внутренней структуры (5 отделов), внутренних процессов (33) и работников (61). Работники представлены в виде персонажей. […]


Цитата:
About Face 3 - предисловие | Перепроектируйте это немедленно!02.07.2007 16:07
8

[…] и внедрение методики персонажей, усовершенствование текстовых сценариев […]


Цитата:
HCI, лопата, тачка и Яма 2.0 | Взгляд изнутри03.07.2007 18:01
9

[…] и контекст работы пользователей (для чего необходимы персонажи), и банально иметь возможность менять что-то в […]



Цитата:
Yoshi11.12.2007 12:58

Отличная статья…
А как проходит вживание в роль?


Цитата:
Антон05.01.2008 14:27

Я описываю несколько персонажей для зарубежного сайта. Как мне понять и убедится, что я близок к Петру Михалычу, а не к сферическим коням в вакуме? (Думая о решении,а не о проблеме) Что вы думаете о том, если прислать жизнеописание Петра Михалыча похожему Ивану Фёдоровичу, скажем на Facebook и попросить его прокомментировать?


Цитата:
Денис20.06.2008 01:27
12

Описанный подход был использован для производства на свет урода. Он называется MS Office 2007. Какие-то функции полезны очень, а общий интерфейс - полная сумятица и неразбериха, потому что либо слишком много персонажей, либо делали только под одного: того, который увидел компьютер третий раз…
А вообще спасибо за статью



Цитата:
� руглый стол RusCHI №1 at ALSEDI Group15.12.2008 20:03
13

[…] подход в юзабилити и его сравнение с методикой персонажей“. Применение теории деятельности позволяет […]


Цитата:
Валентин07.01.2009 17:09
14

Автор фотографии — Владимир Ролов, выдающийся фотокорреспондент советских времен. Эта фотография не постановочная, за ней — настоящая история приобщения пожилого человека к компьютеру; старику действительно приходилось так печатать.

Будет здорово, если вы укажете автора в статье.




Последний раз редактировалось Владимир Паронджанов Суббота, 24 Декабрь, 2011 11:36, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Декабрь, 2011 11:13 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Маленькие замечания по тексту схемы Эдуарда:

1) В разных ветках переменная кейс-выбора "меню администратора" - ясно, что во втором (более правом) случае д.б. "модератора".

2) В кейсе для этого самого выбора "меню модератора" дважды одинаковый вариант (значение переменной); по аналогии с "администратором" можно предположить, что второй вариант - это "Изменение информации о заводе".

Понятно, что образуются из-за "неконтролируемого копипастинга" при "сочинении в машинном карандаше". :) Ежели бы редактор проверял пространства имён схем - как показано для ВЛ-семредактора в ролике отсюда: viewtopic.php?f=93&t=1542&p=68332#p68332 - видимо, сочинителю бы указывалось на такие вещи... ;)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Декабрь, 2011 11:36 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Владимир Паронджанов писал(а):
Ильченко Эдуард писал(а):
Чем виртуальные персонажи лучше обезличенных, например, администратор — модератор?


Ответ я нашел в сети. Лучше всего прочитать оригинал с картинками:
http://www.gui.ru/platon/?p=20

Но если кому не хочется смотреть ссылку, я кое-что скопировал
...
В общем, если в этом цитатнике заменить "персонаж" на "исполнитель" - то укладывается в то что говорил alexus - скажем, здесь: viewtopic.php?f=62&t=3630&p=66850&hilit=+%D0%BA%D0%B2%D0%B0%D0%BB%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F#p66850.

Можно сопрячь и с Коберном - но это уже отдельно... ибо ДРАКОН (и вообще импер-язык) тут будут, как обычно, лишь частью картины...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Декабрь, 2011 12:49 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Павел Макаров писал(а):
Кратко о методе персонажей:
... это один из самых мощных и эффективных инструментов проектирования взаимодействия.

Это в книжке написано или личный опыт?

Владимир Паронджанов писал(а):
Ильченко Эдуард писал(а):
Чем виртуальные персонажи лучше обезличенных, например, администратор — модератор?


Ответ я нашел в сети. Лучше всего прочитать оригинал с картинками:
http://www.gui.ru/platon/?p=20

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

Владислав Жаринов писал(а):
1) В разных ветках переменная кейс-выбора "меню администратора" - ясно, что во втором (более правом) случае д.б. "модератора".

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

Владислав Жаринов писал(а):
2) В кейсе для этого самого выбора "меню модератора" дважды одинаковый вариант (значение переменной); по аналогии с "администратором" можно предположить, что второй вариант - это "Изменение информации о заводе".

Да, здесь ошибка. Исправил ниже.

Геннадий Тышов писал(а):
Павел Макаров,
вопрос "Закончить работу с сайтом?" - назойливый и непонятно кому, можно сделать сооветствующий пункт "Меню администратора".

Поддержу. (см. ниже)
Вложение:
log2.png
log2.png [ 65.32 КБ | Просмотров: 25041 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Декабрь, 2011 13:15 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Ильченко Эдуард писал(а):
...
Владислав Жаринов писал(а):
1) В разных ветках переменная кейс-выбора "меню администратора" - ясно, что во втором (более правом) случае д.б. "модератора".

Нет, здесь ошибки нет. Это одно и то же меню администратора, но для разных пользователей. По крайней мере, я так понял логику изначальной схемы.
...
В общем, те самые разные варианты использования для разных персонажей. :)
Владислав Жаринов в viewtopic.php?f=62&p=68880#p68880 писал(а):
...
Можно сопрячь и с Коберном - но это уже отдельно... ибо ДРАКОН (и вообще импер-язык) тут будут, как обычно, лишь частью картины...
Т.к. это явно одним ДРАКОНом не ограничишь - ответил в отдельной теме: viewtopic.php?f=86&t=3729.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Декабрь, 2011 13:29 

Зарегистрирован: Понедельник, 19 Декабрь, 2011 23:03
Сообщения: 18
Владимир Паронджанов писал(а):
Уважаемый Павел Макаров!

Если не трудно, сообщите, пожалуйста, следующее:

1. Полное название ВУЗа.

2. Название факультета

3. Название кафедры

4. ФИО уч. степень и уч. звание Вашего научного руководителя.

5. Это у Вас курсовая или дипломная?

6. Если у Вас есть одна и та же тема на UML и на ДРАКОНе, опубликуйте, пожалуйста, оба варианта. Чтобы можно было сравнить.

1. Российский университет кооперации. Волгоградский кооперативный институт (филиал)
2. Факультет:Торгово-технологический. Специальность: 080801 Прикладная информатика (в экономике).
3. Кафедра: Информационных систем в экономике.
4. А.В. Игнатьев, к.т.н., доцент кафедры ИСЭ или пользователь форума alignat
5. Дипломная работа
6. На UML в данный момент (по этим сценариям) нету, но можно будет сделать для сравнения!


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 38 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 4


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB