А какой календарик для блога сделал ты?

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

1. Олдскул

Помнится раньше везде были календарики, на которых даты, в которых были записи, линковались. Это считалось очень крутым. Лично я всегда считал, что толку от таких календариков никакой — пользователю не интересно, что было написано автором 3 ноября, ему интересно просто последние записи, ну, максимум, разбивка по месяцам (редко).

Видимо бессмысленность подобного типа календаря поняли все и потому сегодня я с трудом нашел даже один для примера:

2. Гугел

В ЖЖ вообще перестали использовать календари (возможно, я ошибаюсь, но раньше они там были), пользователям вполне хватает ссылки [<< Previous 20].

Но все же некоторым пользователям хочется знать, что написал автор в прошлом месяце (году), поэтому Гугл на своем Блоггер.ком сделал разворачивающийся календарик по годам и месяцам. Покажу на примере моего сайта:

Удобная штука — можно просмотреть сколько записей было в каждом месяце. Однако если бы я писал по 1-2 поста в день, то календарь превратился бы в кашу. Но Гугл не верит, что я на это способен, поэтому показывает в календаре не только названия месяцев, но и названия постов. Не верит и правильно делает :)

3. Сам себе дизайнер

Для наших корпоративных новостей я сделал нечто похожее. Только названия постов в календарь я не стал вставлять, как и мусорные буллиты.

Кроме того, я посчитал, что если в месяце нет записей, то его все равно нужно отображаться (сереньким и не линковать). Т.е. у меня в году всегда 12 месяцев и пользователь не гадает, почему после января сразу идет март:

4. Яндекс

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

5. Ойфанчег

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

Впрочем, для данного ресурса такое решение вполне оправдано:

Выводы

Идеальных календарей не существует. Для каждого случая необходимо искать свое решение.

Прототипирование на чистовую

В среде профессиональных разработчиков интерфейсов часто обсуждается, какой инструмент прототипирования лучше, мощнее, дешевле, быстрее. Рискуя прослыть еретиком, скажу, что для некоторых веб-сервисов лучшее средство прототипирования — HTML.

Обычно веб-проект проходит следующие этапы:

1. Набросок, рисунок, схема;
2. прототип системы — часто содержит различные варианты исполнения для сравнительного тестирования;
3. дизайн, верстка;
4. кликабельный HTML-прототип;
5. программирование;
6. шлифовка всего — дизайна, интерфейса, кода.

Конечно, эти этапы — не закон. Всё зависит от политики разработчика, от сложности сервиса. Бывает, что один человек сел и сделал все этапы в один присест, например, Записочки именно так и сделаны Максимом Чечелем.

Но, если сервис более-менее сложный, то без перечисленных этапов не обойтись. Однако, как мне кажется, в среде проектировщиков интерфейсов существует тенденция опускать 4-й этап кликабельного HTML-прототипа, но фокусироваться на 2-м этапе прототипирования в специальных программах.

Средств прототипирования интерфейсов существует великое множество. Платных, бесплатных, даже онлайн. Существуют и обзоры на эту тему. Эти средства активно обсуждаются, люди делятся секретами их использования.

Я же хочу поделиться примером, как мы совместили сразу несколько этапов — прототипирование, дизайн, верстку, кликабельный прототип — при создании сервиса 3115.ru о котором я уже рассказывал.

Плюсы прототипирования на HTML

Создание этого сервиса уложилось всего в 3 этапа:

1. Набросок;
2. кликабельный HTML-прототип;
3. программирование;

Мы создали полный клон сервиса на статическом HTML + немного динамики на JS. На прототипе все нажималось, как на настоящем сайте (ну, почти все), а главное он выглядел, как готовый сайт.

Плюсы чистового прототипирования с помощью HTML:

1. Сокращение этапов разработки. Дизайн, верстка и прототип делаются одновременно.

2. Прототип выглядит в точности как готовый сервис. Это облегчает согласование с заказчиком/начальством — нужно показать всего один раз, а не три (картинка, прототип, верстка). Кроме того не приходится объяснять, что эта серая плашечка — это только прототип, а на самом деле тут будет коллаж, который пользователю все разъяснит.

3. На этапе прототипа можно проводить достаточно качественное тестирование — пользователь видит не набор стандартных набросков, а красочные страницы с нажимаемыми кнопочками.

Минусы прототипирования с помощью HTML:

1. Подходит только для относительно небольших проектов. В больших проектах при изменении вводных данных плюсы данного подхода мгновенно превращаются в минусы.

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

3. Разработчик интерфейса должен хорошо владеть HTML+CSS и иметь навыки дизайнера.

Вывод: прототипирование веб-сервисов с помощью HTML может быть очень полезным, однако применять его нужно осторожно.

И помните, самое сложное объяснить инвестору, почему он видит работающий сайт, где всё нажимается, а с него требуют еще 3 месяца на программирование и кучу денег :)

Ах да, я же обещал в каждом посте картинку: