До сих пор в этой серии мы обсуждали, как PHP может быть идеальным дополнением к RPG-ориентированной бизнес-системе, предоставляя высококачественные веб-страницы, которые, по мнению каждого, им нужны. В статьях, которые я видел в Интернете, акцент всегда делается на том, как подключить PHP к RPG или наоборот. Никто никогда не говорит о том, как создавать качественные страницы, как они должны выглядеть, как их структурировать и так далее.
Причина этого проста: нам не нужны никакие вонючие инструкции для этого! Все знают, как создавать хорошие экраны (опп, страницы). Это легкая часть, верно? Ну, может и нет. Нам, конечно, не нужно далеко ходить, чтобы найти примеры, где это просто неправда — страницы, что, если они были разработаны с учетом эффективности и интуитивности, трудно сказать, к какому виду они играли.
Конечно, бизнес-страницы отличаются от страниц, которые мы можем разработать для блога или веб-сайта. Дело не в том, что внешний вид страницы не важен, а в том, как организованы поля ввода и эффективность, с которой можно просматривать страницу и вводить данные, очень важна для бизнес-страниц. Это особенно верно для пользователей i; Зеленый экран, с которым они привыкли работать, не имеет себе равных по скорости и простоте ввода данных. Как бы красиво они ни были, иногда переключение пользователей на экран графического интерфейса приводит к смешанным отзывам.
Итак, в этой статье я расскажу о некоторых вещах, которые стоит рассмотреть, если вы хотите создавать качественные, хорошо структурированные страницы (что мы все делаем, верно?).
Количество переключателей
За мои деньги первое, на что нужно обратить внимание при разработке бизнес-страниц, — это количество «переключателей», когда вы переключаетесь с клавиатуры на мышь, трекпад или полосу прокрутки, а затем переключаетесь назад. Каждый раз, когда вы делаете это, вы должны двигать руками и менять фокус, и нет ничего, что могло бы вызвать ошибки и усталость так сильно, как изменение вашего ментального фокуса. В результате мы хотим стремиться к минимальному количеству переключателей.
Вы, вероятно, говорите: «Да, без шуток». Это кажется очевидной вещью. Но если вы посмотрите на многие страницы, ограничивающие переключатели не являются приоритетом номер один. Один пример, который приходит на ум, — это ввод дат. В мире зеленого экрана вы можете просто ввести дату 20130130 и продолжать. Если вы введете 20130143, появится сообщение об ошибке. Но в веб-мире, когда у вас есть поле даты, появляется всплывающий календарь, и вы можете выбрать нужную дату с помощью мыши или трекпада. В общем, для этого требуется три щелчка и два переключателя, больше, если вы хотите, чтобы дата не была в текущем месяце. Это полностью меняет фокус вашего ума от просмотра персонажей к работе с графическим представлением. Это круто, и все, особенно с новыми возможностями CSS3, но эффективность, а не крутость, является целью при работе с бизнес-экранами.
В примере также показано, как среда бизнес-системы отличается от среды обычной веб-страницы. Кто-то, планирующий отпуск, может получить пользу от просмотра дат в формате календаря. Для них дополнительные нажатия клавиш окупаются с точки зрения меньшего количества ошибок, в частности ошибок, которые невозможно отредактировать, например, выходя в среду вместо желаемого вторника. Но в бизнес-контексте я мог бы читать «запрошенную дату доставки» из бумажного заказа и не должен видеть вонючий календарь. Мне просто нужно поле, где я могу набрать 20130315.
Враг здесь смещает фокус. Как бы нам ни хотелось притворяться, люди на самом деле не все такие умные. Если мы можем сосредоточиться на одной вещи за раз, например, на чтении текста и вводе данных в поля на экране, где курсор перемещается как можно более автоматически, у нас все в порядке. Это сопоставление один к одному, разве вы не знаете? Но когда форматы ввода начинают изменяться и смешиваться, это становится более сложным, что, в свою очередь, делает нас уставшими и более склонными к ошибкам.
Зеркальное отражение задачи, а не базы данных
Давным-давно, когда динозавры правили землей и до того, как люди жили в домах, разработчики создавали бизнес-экран, имитирующий базу данных, которая стояла за ней. У нас была бы функция, которая выполняла сопровождение Product Master, потому что существовал основной файл продукта, и еще одна, которая выполняла сопровождение Product Product, потому что это был файл, и третья, которая настраивала маршрутизацию, чтобы рассказать вам, как создать продукт. Процесс настройки нового продукта будет включать три отдельные функции.
Со временем люди начали понимать, что на самом деле важно не создавать основную запись продукта, а настраивать продукт. В результате вы захотите разработать функцию, которая приведет к созданию продукта. Да, он обновил Product Master, но также позволил вам вводить множество странных полей в ряд других файлов, которые необходимо было привязать к Product Master, чтобы полностью определить новый продукт. Другими словами, ключевым моментом стала бизнес-задача, а не файл, который был затронут.
Это очень важно сегодня, поскольку штат сотрудников сокращается, и все больше и больше людей становятся ответственными за междисциплинарные задачи. Когда у вашего пользователя есть бизнес-задача, последнее, что вам нужно, это чтобы он выполнил две или более функции, чтобы выполнить это. Как технические специалисты, мы очень ориентированы на базу данных, но вам действительно нужно разобраться в том, что делает пользователь, и как вы можете сделать это на одном экране или в одной функции. Вы должны понимать, какие данные они вводят, какие данные им нужны, как часто они вводят или используют определенный фрагмент данных и как различные элементы связаны друг с другом.
Как ты это делаешь? Ну, вы можете спросить, но так же, как свидетели на месте преступления часто общеизвестно ненадежны в том, что произошло, так и многие пользователи не очень хорошо помнят, что им действительно нужно. Вы должны наблюдать за ними в действии, разговаривать с разными людьми, получить четкое представление о задаче, ее компонентах и о том, как она связана с компанией в целом.
Остерегайтесь сгиба
Действительно ли наличие данных «ниже сгиба» действительно влияет на вероятность того, что их увидят? Для бизнес-систем возникает вопрос, влияет ли наличие данных ниже сгиба на эффективность экрана.
Для обычных веб-сайтов, еще несколько лет назад наличие информации ниже сгиба было препятствием для ее просмотра. Сегодня пользователи более опытны и понимают, что прокрутка вниз является важной частью работы в Интернете. Бизнес-страницы немного отличаются, конечно. У пользователя нет выбора прокручивать или не прокручивать, он должен прокрутить вниз, чтобы завершить свою задачу. Это становится еще одной вещью, которую вы должны сделать, которая смещает ваш фокус и, как таковая, это неприятно … особенно если вам приходится делать это более одного раза.
Если вы разместите дополнительные данные на отдельной странице, пользователю все равно придется щелкнуть ссылку или кнопку, чтобы перейти к ним. Так что мы можем сделать? К сожалению, не так много. Лучшее, что вы можете сделать, — это разместить наиболее важные и часто используемые данные в верхней части страницы, чтобы свести к минимуму вероятность того, что пользователю придется прокручивать страницу вниз.
Прежде всего, вы должны смотреть заголовок, который вы положили в верхней части страницы. Мой банк любит, чтобы их логотип и другие бесполезные вещи занимали половину страницы, а это означает, что каждый раз, когда я проверяю свой баланс или делаю перевод, мне нужно прокручивать страницу вниз. Думаешь, это меня не раздражает?
Резюме
Если вы создали один или два веб-сайта и хорошо поработали над ним, вы можете сказать, что здесь все важно для обычных веб-сайтов, помимо деловых страниц. И ты, наверное, прав. Возможно, реальное отличие состоит в том, что приятный внешний вид может побудить пользователей скрыть проблемы, связанные с данными, на веб-сайте, но на бизнес-странице все прямо перед вами, и вы должны сделать это правильно.
Изображение через Fotolia