Это вторая часть перевода интересного исследования, которое проводили авторы популярного интернет сайта Smashing Magazine. Первую часть вы пожете прочитать здесь. В этот раз авторы затрагивают вопросы капчи, сообщения «Спасибо за регистрацию», кнопки «Отмена» на формах и некоторые другие интересные вопросы.

3. Функциональность форм

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

Обзор и сравнение предложенных хабралюдьми систем

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

Вторая часть длинная (да еще и со скриншотами), если тема не интересна — лучше и не начинить читать :)

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

Часть 1. Вступление.
Часть 2. Сбор данных.
Часть 3. Базовые метрики.
Часть 4. От статистики к аналитике

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

Каким же образом опытные аналитики “залезают в голову” пользователю, имея лишь усредненные данные по сайту? Никакой магии. Они проводят процедуры, которые разбирают эти авгиевы конюшни:

— Сегментируют данные: разделяют всех пользователей на группы исходя из определенных критериев и рассматривают поведение не всех пользователей, а каждой из этих групп в отдельности.

— Строят предположения и проверяют их: выискивают вероятные объяснения для сложившейся ситуации и пытаются повлиять на ситуацию исходя из этих предположений, наблюдая за результатом.

Всем нам знакомо правило первого экрана гласящее «Пользователь не прокручивает страницу, поэтому вся информация должна быть на верху», основано оно на том, что пользователь не использует полосы прокрутки, потому что ему лень.
Ребята в компании cxpartners (Великобритания, Бристоль) решили проверить это утверждение и провели исследование, представляю перевод их отчёта.

В IT индустрии все чаще встречаются проекты с распределенными командами. Это удобно — спецификация, код, баги, мануалы легко перемещаются из одного конца планеты в другой за доли секунд. Это выгодно — аутсорсинг проектных процессов, будь то разработка, тестирование или саппорт, в Индии или Китае обойдется в 3–5 раз дешевле аналогичных сервисов в странах Европы или США.

Никого не удивишь проектом, в котором сейлз, маркетинг и бизнес анализ находятся в Англии, разработка в России, тестирование и саппорт — в Индии. Компания, в которой я работал, специализировалась именно на таких проектах. Наиболее слабыми местами в них, я бы назвал коммуникации внутри проекта и мотивацию его участников. Эта статья описывает эффективный подход к решению этих проблем в проектах с распределенной командой.

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

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

Начало

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

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

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

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

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

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

Часть 1. Вступление.
Часть 2. Сбор данных.
Часть 3. Базовые метрики.
Часть 4. От статистики к аналитике
Часть 5. Разделяй и думай
Часть 6. Action!
Счетчики посещаемости знакомы всем пользователям интернета уже много лет. Многие владельцы сайтов ставят сразу несколько иконок разных счетчиков, и день за днём цифры на них растут и всё больше радуют хозяина.



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

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

В недавней статье об инструментах управления проектами был задан вопрос о различиях Trac и Redmine. Ниже перевод довольно субъективной, но вполне аргументированной статьи о различиях между этими системами.

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

Разумеется, в крупных и солидных студиях имеются квалифицированные арт-директоры, которые доведут любой сайт до лоска. Но, во-первых, далеко не всегда и везде есть такой человек. Например, сайт был заказан у фрилансера, который сделал всё хорошо, но допустил с точки зрения профессионального дизайна ряд мелких ошибок и недочётов. А во-вторых, даже после усердной работы высококлассного арт-директора вполне может остаться поле деятельности для дизайн-аудитора с намётанным глазом.

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

ВНИМАНИЕ: в статье имеется большое количество крупных изображений.

^{Системы рекомендаций:
— Советы от машины
— Холодное начало
— Введение в гибридные системы
— искусственные имунные системы и эффект идиотипов}


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

Для начала все-таки придется дополнить классификацию СР. Przemyslaw Kazienko и Pawel Kolodziejski предложили разделить все СР на пять типов: статистические, коллективные, ассоциативные и информационные. Начнем с самых простых.

Немало копий уже сломано в битвах Инкубаторы vs Стартаперы.
Сломаем еще одно, через колено.
Ломать копья — не строить копья, верно?

Многие социальные сети предлагают пользователям такую платную услугу как «подарки». Обычно это символические знаки внимания, представленные в виде картинок, которые можно подарить другому пользователю, оплатив подарок sms-кой. Типичная стоимость подарков лежит в диапазоне от доллара до $7 за штучку.



Мы задумались: а что можно изобрести нового, необычного, интересного в этой области? И посвятили теме подарков недавнюю встречу клуба Brain Exchange. Участники встречи генерили новые мысли в формате мозгового штурма, поэтому часть идей может показаться странными или не подходящими — но наверняка их можно развить во что-то полезное. Мы делимся этими идеями со всеми желающими.

Приветствую!

Решил поделиться с сообществом своим проектом.
opentodo — система управления задачами, написанная на языке Python (Django Framework).

Возможно, по тем или иным причинам вам не подходят существующие системы наподобие Basecamp, Мегаплан и т.п. И вы хотели бы использовать более простое решение с открытым исходным кодом, которое вы сможете бесплатно установить на своем сервере в интернете или внутри сети компании, и при необходимости доработать под свои нужды. Тогда opentodo может заинтересовать вас.

Особенности

• Простой, удобный интерфейс в стиле Gmail
• Добавление задач, назначение ответственных и сроков выполнения
• Возможность прикреплять файлы к задачам и проектам — скриншоты, документацию и т.п.
• Жизненный цикл задач: Новая, Принята, Завершена, Одобрена
• Цветовое кодирование задач в зависимости от статуса
• Комментарии к задачам
• E-mail уведомления
• Управление пользователями с помощью стандартной панели администрирования Django
• Разграничение доступа пользователей к проектам

Онлайн демо

Посмотреть в работе можно здесь: demo.opentodo.ru

Где скачать и как установить

Архив для загрузки и инструкция по установке доступны на странице проекта на Google Code:
code.google.com/p/opentodo

Исходный код под управлением системы контроля версий на сайте GitHub:
github.com/mgrigoriev/opentodo

Условия распространения: GNU General Public License v3.

Надеюсь, мой скромный проект для кого-то окажется полезным и поможет в организации работы :)

P.S. Спасибо участникам дискуссионной гугл-группы django russian, а также всем, кто прокомментировал пост на design.leprosorium.ru, за отзывы и ценные советы по улучшению opentodo.

UPD: убедительная просьба — полегче в демо! Анонимность не оправдывает вандализм :)

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

Вторая версия статьи, расширенная и дополненая.

Большая часть готовилась для моего выступления на «РИТ: Клиентские технологии», куда я, к сожалению, не доехал.

 



К сожалению огромная армия даже опытных, «модных» и эффектных дизайнеров забывают, что результатом их творчества должен быть сайт, а не только «супер-скриншот» годный только для портфолио.

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

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

Постановка задачи

В проекте есть на данный момент 2 зоны:

1. географическая зона, реализованная на базе Google Maps, которая отображает нанесенные пользователями на карту географические объекты (маркеры, маршруты и области);
2. информационная зона, которая представляет собой большой иерархически организованный каталог, содержащий информационные материалы.

Необходимо было решить задачу одновременного текстового поиска по 3-м типам объектов: географическим объектам, категориям информационной зоны и материалам информационной зоны — c возможностью фильтрации по дате публикации объектов и категориям, к которым они относятся.

ВРЕМЯ ПРИНАДЛЕЖИТ ВАМ, А НЕ ВЫ ВРЕМЕНИ

Этот текст служит цели оптимизации вашей деятельности.
Но не увлекайтесь оптимизацией — делайте дело.

Следствие: Традиционная учёба (стационар, 5 лет) — это опасная вещь. Нужно иметь очень веские основания (конкретную цель), чтобы потратить столь огромный кусок времени на неизвестный результат. К тому же принцип 50-50 (теория-практика) неприменим при учёбе, там все с точностью наоборот, что (на мой взгляд) свидетельствует об ущербности текущих методов обучения.

1. Необходимость времени (причины)