1. После того, как определены заголовки, надо внутри каждого раздела накидать сырых тезисов.
Предварительную работу я обычно делаю в MindManager — очень легко кидать туда тезисы, а потом их структурировать, перекидывая от одного раздела к другому.
Кто-то уже спрашивал об этом в Хабре. Попробую сформулировать собственный подход:
1. Определиться с целями статьи. Их не должно быть много — от одной до трех, максимум. Цели вам помогут выкинуть лишнее и добавить недостающее.
2. Сделать скелет статьи в виде заголовков неких смысловых блоков. Каждый следующий блок должен плавно вытекать из следующего (логически связан). При этом автор идет от общего к частному (в текущей версии статьи общее и частное тщательно перемешано, как в блендере).
3. Желательно использовать трехчастную структуру повествования — вступление, завязка и катарсис (разрешение).
— Во вступлении мы вводим читателя в контекст статьи и сообщаем нечто достаточно понятное сразу. Если автор применяет некую специальную или неустоявшуюся терминологию, желательно дать краткие определения.
— В завязке мы ставим проблему (проблемы) — заинтересовываем читателя, чем больше читатель знаком с проблемой тем больше шансов, что он будет читать дальше.
— В катарсисе мы показываем как эти проблемы разрешаются.
Желательно в самом конце сделать краткие выводы из статьи. Эти же выводы можно поставить, наоборот в самом начале статьи, чтобы читатель мог понять — интересна ему вся статья или нет? Еще этот блок поможет блоггерам, которые смогут выводы быстро поставить его в качестве цитаты внутри своих сообщений по поводу вашей статьи. То есть в этом случае повышается шанс, что обсуждение вашей статьи разойдется по сети.
Жду хорошей статьи с разархивированными смыслами :), а также с разбитием на главы, а если еще будут и иллюстрации в виде интерфейсов, то цены ей не будет.
Статья весьма плотно набита информацией и поднимает интересную тему — автору спасибо! Но написана несколько сумбурно — нет четкой постановки задачи и четких путей решения. Я понимаю, что она дискуссионная, но в этом случае структура статьи все же должна быть явно выраженной — тогда будет проще комментировать те или иные выкладки автора.
А вообще мне кажется сомнительной идеей, что все именно фреймворк является центром вселенной разработки, то есть, получается некий framework-oriented design. Все же фреймворк это внутренний артефакт разработчика, пользователь сталкивается с его внешним проявлением, но не более. Не может фреймворк являться движущей силой проектирования интерфейсов.
Автор в тексте смешал количественные и качественные исследования.
Предпосылка Нильсена действительна только для чисто качественных юзабилити-тестированиях. В случае количественных, количество респондентов в должно быть >10. Если же брать тепловые карты и обрабатывать их по одному (поводя качественное исследование), то можно делать некоторые выводы (в том случае, если эксперимент поставлен очень надежно и данные воспроизводимы).
Однако, если вы хотите делать выводы по суммарной карте, то 5 человека на целевую группу совершенно недостаточно! Вообще сами поставщики систем регистрации движения глаз говорят, что необходимо более десятка на целевую группу (некоторые исследования рекомендуют брать не менее 40 респондентов с избытком — количество зависит, конечно, от доверительного интервала). Дело в том, что только, если человек действительно много, то, только в этом случае, добавление нового практически не добавляет ничего нового в картинку. Если же всего 5 человек, то слишком велики флуктуации. Когда мы проводим качественное юзабилити-тестирование то не даем никаких статистических данных — они не имеют основания. Также и тут обобщенная тепловая карта не имеет смысла.
У вас очень поверхностное представление об основах, поэтому у нас с вами нет предмета спора. Ваша интерпретация того, что влияет на поведение пользователя является поверхностным пересказом малюсенького кусочка когнитивной психологии, а кроме нее есть еще теория мотивации, теория деятельности. Деятельность, социальное давление, и прочие факторы влияют на пользователя гораздо сильнее нежели его физические, ментальные и психические потребности.
Вот уже тут вы ошибаетесь — факты это нечто, что не зависит от чего-либо мнения. Ваша же статья — констатация вашего мнения. И это информационный повод хотите вы или нет. Точнее хотите, так как опубликовали.
Если про статью, то мне достаточно одного тезиса, где вы обвиняете юзабилити в ненаучности. Есть такое понятие, как юзабилити-тестирование — это эксперимент направленный на выявление проблем при взаимодействии пользователей с неким интерактивным продуктом. Если интерфейс это гипотеза (=теория), то ю. тестирование это проверка гипотезы. Вполне себе научная деятельность. Вы о тестировании в статье не сказали ни слова.
К сожалению, в вашем тексте такая мешанина из понятий и предположений причем не связанных логически, что, я предполагаю, нет смысла в онлайн общении. Вообще, в вашей статье форма превалирует перед содержанием, эмоции и уже софрмированное отношение к предмету затмевают желание в нем разобраться.
Предлагаю вам посетить одно из юзабилити событий, например, WUD 2009 (http://community.livejournal.com/ru_ucdesign/473938.html#cutid1) и там пообщаться лично.
forums.vl.ru/read.php?23,1355886,1359481,quote=1:
решает только опыт, никакой юзабилити не существует на самом деле, это все выдумки недалеких людей, которые пытаются оправдать свою неграмотность недоработками и недоразвитостью системы!
Взято из статьи Беркуна:
www.scottberkun.com/blog/2009/when-visualizations-go-wrong/
1. После того, как определены заголовки, надо внутри каждого раздела накидать сырых тезисов.
Предварительную работу я обычно делаю в MindManager — очень легко кидать туда тезисы, а потом их структурировать, перекидывая от одного раздела к другому.
1. Определиться с целями статьи. Их не должно быть много — от одной до трех, максимум. Цели вам помогут выкинуть лишнее и добавить недостающее.
2. Сделать скелет статьи в виде заголовков неких смысловых блоков. Каждый следующий блок должен плавно вытекать из следующего (логически связан). При этом автор идет от общего к частному (в текущей версии статьи общее и частное тщательно перемешано, как в блендере).
3. Желательно использовать трехчастную структуру повествования — вступление, завязка и катарсис (разрешение).
— Во вступлении мы вводим читателя в контекст статьи и сообщаем нечто достаточно понятное сразу. Если автор применяет некую специальную или неустоявшуюся терминологию, желательно дать краткие определения.
— В завязке мы ставим проблему (проблемы) — заинтересовываем читателя, чем больше читатель знаком с проблемой тем больше шансов, что он будет читать дальше.
— В катарсисе мы показываем как эти проблемы разрешаются.
Желательно в самом конце сделать краткие выводы из статьи. Эти же выводы можно поставить, наоборот в самом начале статьи, чтобы читатель мог понять — интересна ему вся статья или нет? Еще этот блок поможет блоггерам, которые смогут выводы быстро поставить его в качестве цитаты внутри своих сообщений по поводу вашей статьи. То есть в этом случае повышается шанс, что обсуждение вашей статьи разойдется по сети.
А вообще мне кажется сомнительной идеей, что все именно фреймворк является центром вселенной разработки, то есть, получается некий framework-oriented design. Все же фреймворк это внутренний артефакт разработчика, пользователь сталкивается с его внешним проявлением, но не более. Не может фреймворк являться движущей силой проектирования интерфейсов.
Предпосылка Нильсена действительна только для чисто качественных юзабилити-тестированиях. В случае количественных, количество респондентов в должно быть >10. Если же брать тепловые карты и обрабатывать их по одному (поводя качественное исследование), то можно делать некоторые выводы (в том случае, если эксперимент поставлен очень надежно и данные воспроизводимы).
Однако, если вы хотите делать выводы по суммарной карте, то 5 человека на целевую группу совершенно недостаточно! Вообще сами поставщики систем регистрации движения глаз говорят, что необходимо более десятка на целевую группу (некоторые исследования рекомендуют брать не менее 40 респондентов с избытком — количество зависит, конечно, от доверительного интервала). Дело в том, что только, если человек действительно много, то, только в этом случае, добавление нового практически не добавляет ничего нового в картинку. Если же всего 5 человек, то слишком велики флуктуации. Когда мы проводим качественное юзабилити-тестирование то не даем никаких статистических данных — они не имеют основания. Также и тут обобщенная тепловая карта не имеет смысла.
Если про статью, то мне достаточно одного тезиса, где вы обвиняете юзабилити в ненаучности. Есть такое понятие, как юзабилити-тестирование — это эксперимент направленный на выявление проблем при взаимодействии пользователей с неким интерактивным продуктом. Если интерфейс это гипотеза (=теория), то ю. тестирование это проверка гипотезы. Вполне себе научная деятельность. Вы о тестировании в статье не сказали ни слова.
Предлагаю вам посетить одно из юзабилити событий, например, WUD 2009 (http://community.livejournal.com/ru_ucdesign/473938.html#cutid1) и там пообщаться лично.
Юзабилити — такой же миф, как снежный человек: все о нём говорят, но никто точно не может сказать, что это такое.
www.opennet.ru/openforum/vsluhforumID3/52561.html:
А «юзабилити» — не существует. Есть привычки, навязанные Вам m$.
forums.vl.ru/read.php?23,1355886,1359481,quote=1:
решает только опыт, никакой юзабилити не существует на самом деле, это все выдумки недалеких людей, которые пытаются оправдать свою неграмотность недоработками и недоразвитостью системы!