Веб-разработка ради людей

Wiki-системы, багтрекеры, системы контроля версий являются эффективными инструментами для разработчиков, но начинают сильно сдавать, когда в команду попадает нетехнический специалист с навыками на уровне пользования Microsoft Word.

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

С разметкой зачастую больше всего проблем - человек просто думает другими категориями, у него в голове нет понятия “тег A”, он хочет “ссылку на другой документ”.

Как можно облегчить эту задачу? Визуальными средствами.

На примере wiki это легко сделать - при вставке ссылки нужно спросить пользователя, является ли эта ссылка внутренней или внешней (ведёт на другой сайт). Если ссылка внешняя, нужно запросить адрес и текст ссылки. А если внутренняя, то можно значительно облегчить задачу, предоставив пользователю древовидный список всех имеющихся в текущем разделе документов (с возможностью выхода на уровень выwе и так далее).

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

Кроме прочего, это устранит и ошибки, так как все адреса будут выбираться из списка, а не вводиться вручную.

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

Если выводится короткое сообщение “Произошла ошибка.” - это ему не понравится даже ещё больше, потому что здесь ему даже подумать не над чем.

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

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

Если же это пользователь сделал что-то такое, чего емy делать
не нужно, то ему также нужно об этом явно сообщить.

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

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

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

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

Не читает тот, кому не надо. Тот, кому надо - читает целиком.

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

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

Совсем выбрасывать продвинутую разметку не нужно - более опытные пользователи захотят ею воспользоваться. Но навязывать нельзя.

Хороший сайт не должен раздражать пользователя. Баннеры - это то, что визуально раздражает больше всего. А так как от баннеров отдача минимальна, если у вас не большой раскрученый проект, то выходит, что вы зазря мучаете своих пользователей.

Поэтому, если вы не понимаете, какую реальную пользу вам приносят баннеры, лучше уберите их.

Человеко-Понятные УРЛы - это большое доброе дело на каждом уважающем себя сайте.

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

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

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

А то очень легко попасться в ловушку.

Обилие малополезного функционала скроет от глаз пользователя самое ценное.

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

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

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

Особенно хороши в этом смысле системы наподобие Orphus Дмитрия Котерова, которые позволяют пользователю даже не писать сообщения об ошибке. В современном мире AJAXа всё это можно сделать настолько удобным, насколько позволит ваша фантазия.

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

Позвольте пользователям помогать вам - от этого выиграют все.

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

Поэтому, если у вас есть выбор между оптимизацией ресурса по скорости и оптимизации по простоте в администрировании, выберите оба пункта :-)

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

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

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

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

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

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