velarix

1. Все экраны списка имеют понятный заголовок.
2. В любой момент пользователь может понять:
 2.1. какая страница отображена сейчас, 
 2.2. сколько всего пунктов в списке,
 2.3. сколько пунктов отображено на текущем экране.
3. Навигация размещается над списком и под списком.
4. Присутствует интерфейс для подтверждения перехода к предыдущему и следующему экранам (отображается только в том случае существавания таких экранов).
5. Показано общее число экранов.
6. Показано 5-10 ссылок для перехода на конкретные (соседние) экраны.

Полезные ссылки: 
Переводы на тему из книги Interaction Design Patterns на webmascon.com 
Примеры на смашингмагазин
Ещё примеры 

Бывает не просто объяснить, сколько стоит разработка сайта, проектирование, дизайн или кодирование.
Хуже всего, если потенциальный заказчик начинает полагать, что его водят за нос с целью вытянуть побольше денег, используя пространные рассуждения.

Примерно пол года назад читал интервью с Лебедевым, в котором он в качестве аналогии со стоимостью сайта использовал стоимость снятия кинофильма. Мне понравилось, я теперь тоже использую этот ход, никому ведь не придёт в голову придти к режисёру и спросить "Сколько стоит пять кино"? Ещё работает аналогия со стоимостью постройки здания. 

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

Вот ссылки на мнения, которым я, отчасти или полностью, импонирую:
lipka.ru
indestudio.org
blog.coderab.com

По моему мнению, Axure неявным образом склоняет проектировщиков к тому, чтобы плодить убожество. И в первую очередь своим идиотски-скудным набором паттернов а-ля horizontal menu, vertical menu и прочим старьём.

P.S. Если есть желаение, можете меня переубедить, или подтвердить/дополнить мой пост =)

На FF тоже спросил

Поскольку понимание потребностей пользователей (User Centered Design philosophy) позволяет разрабатывать более удобные, востребованные и эффективные программные продукты (а следовательно, ведёт к всеобщему счастью и удовлетворённости =), необходимо найти инструменты, позволяющие эффективно извлекать и обрабатывать информацию о требованиях пользователей. 

В свете вышесказанного предлагаю обсудить такие методологии, как Варианты использования и Сценарии использования (Use case and Usage scenarios). Вышеназванные методологии отлично зарекомендовали себя (Karl E. Wiegers, 2004), в их эффективности и чрезвычайной пользе я убедился на собственном опыте. 

( Read more... )

В 30-м выпуске Юзабилити Бюллетеня опубликована моя статья на тему проектной документации "Проектная документация. Задачи, требования и практика". Всем столкнувшимся с проблемой выбора формата документов для проектирования веб-сайтов посвящается. Эта статья даст вам основание для дальнейших размышлений и практики.

Далее цитирую...

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

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

Итак, зачем проектировать?

( Read more... )

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

Необходимо хранение видео, аудио, текстовых (txt, docx, pdf и др.) и ещё много каких типов файлов. 
Необходима поддержка версионности всех типов файлов и записей, быстрый поиск (видимо, необходимо периодическое индексирование)...

Кто-нибудь вообще с подобной задачей сталкивался? 
Может быть использовать wiki-движок или CMS, может быть ERP?
Задача вырисовывается глобальная, но думаю, что она стоит затрат, поскольку должна здорово повысить персональную продуктивность.