25.08.2014 |  support@ida-web.ru

Частые ошибки начинающих веб-мастеров

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

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

 

Внутренние и внешние сайты различаются

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

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

    Важно понимать, что эта особенность влияет практически на все.

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

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

    Важно понимать, что эта особенность влияет не только на оптимизацию, но и на алгоритмы.

    Например, внутренняя система может позволить себе хранить изображения больших размеров. Скорость внутри сети достаточно большая. Свободного дискового пространства на компьютере много. Для рядовых интернет-сайтов ситуация несколько иная. Скорость обмена данными может серьезно варьироваться не только из-за провайдера и хостинг-компании, но и из-за удаленности конечного пользователя от сервера с сайтом. Да и дисковое пространство, обычно, достаточно ограничено.
  • Требования к механизмам и к внутреннему устройству. Безусловно, существуют метрики, такие как скорость и производительность, которые применимы как к сайтам, так и ко внутренним системам. Но, все же есть особенности, которые могут сильно влиять на внутреннее устройство и механизмы. Внутренние системы разрабатываются только с расчетом на них самих. Максимально, с расчетом на интеграцию с другими системами. Веб-сайтам же приходится учитывать другие требования. Начиная от источников пользователей (поисковые системы, социальные сети, ссылки на других ресурсах и прочее). Заканчивая техническими особенностями (кэширование, мета-теги, требования к контенту, поведенческие факторы и прочее).

    Важно понимать, что требования могут серьезно влиять на все приложение в целом.

    Например, во внутренних системах можно использовать практически любой контент. Для интернет-сайтов, отсутствие учета SEO может серьезно сказаться на посещаемости.

    Еще один пример. Структура меню веб-сайтов, включая названия каждого пункта, может кардинально отличаться от структуры похожих внутренних систем. Например, при разработке внутренних систем, совершенно не обязательно серьезно задумываться о дубликатах, об общем количестве ссылок на странице и об их анкорах. Конечно, это не означает, что не стоит продумывать структуру. Это означает лишь то, что для веб-сайтов структуру важно продумывать не только с учетом удобства использования.
  • Время доступа. Это одно из серьезных различий внутренних систем и веб-сайтов. Интернет-сайт должен быть доступен 24 часа в сутки 7 дней в неделю. Внутренние же системы могут ежедневно проходить техническое обслуживание.

    Важно понимать, что это различие может серьезно влиять на все приложение.

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

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

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

 

Использование дизайна других систем

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

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

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

 

Обилие функциональности не означает "лучше"

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

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

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

 

У пользователя всегда должен оставаться путь

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

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

Решать данную проблему много разными способами. И вот несколько из них:

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

    Например, в фразе "Произошла ошибка. Сессия была закрыта. Перелогинтесь" есть самое главное "Перелогинтесь". Даже если пользователь не понял сути проблемы, то у него все равно остался выход.
  • Уточнение деталей. Если вы хотя бы раз заполняли универсальные бланки, то знаете, что у них всегда существуют пункты, которые заполняются только при определенных условиях, и что отсутствие такой информации превращает заполнение бланка в проверку вашей стойкости. Особенно, когда бланк приходится заново заполнять более трех или четырех раз. Точно так же происходит и с информационными сообщениями. Даже небольшие детали позволят пользователям быстро сориентироваться в ситуации.

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

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

    Еще пример. Представьте себе, что перед вами огромный сливающийся воедино список. И необходимо отредактировать много строк. Через десяток другой операций, вы обрадуетесь тому, что вместо "операция выполнена успешна", перед вами появилась фраза "сохранен объект № 657-325". Особенно, если вас постоянно будут отвлекать. Ведь, вы всегда сможете быстро сориентироваться на текущей выполненной строчке и перейти к следующей.
  • Перечисление возможных причин, факторов и обстоятельств. Если одно и то же сообщение может появиться по разным причинам, то имеет смысл их перечислить. В случае ошибок, пользователь будет знать, что ему стоит проверить и что он может предпринять. В случае информационных сообщений, пользователь будет понимать, с чем может быть связано сообщение и какие шаги привели к его появлению.

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

    Еще пример. Фраза "Вы попали на данную страницу по следующим возможным причинам: 1. Объект перемещен или удален. 2. Ссылка устарела. И прочее" даст пользователю намного больше, нежели фраза "некорректная ссылка".

Даже такие простые способы оставят пользователям хоть какие-то пути.

 

Компания "IDA-Web" надеется, что данный материал позволит Вам лучше понять особенности разработки в ИТ-индустрии



Так же советуем

Обратная связь

Я согласен с вашими правилами и условиями

Опыт Знания Умения