«Ориентация на пользователя и все остальное будет следовать» — это философия, которая может создать или сломать продукт.
Разработчики программного обеспечения стали известны тем, что сосредоточились на шаблонах реализации и пренебрегали пользователем. Легко заблудиться в грандиозных концепциях на абстрактном уровне и увлечься вещами, которые облегчают вашу работу в качестве разработчика; таким образом, потребности и желания «реальных» пользователей могут иногда отойти на задний план. Выявление ограничений юзабилити и разработка внутри них позволяет сосредоточиться на пользователе.
Ограничения юзабилити
Пользователи имеют определенные базовые симпатии и антипатии с различными типами взаимодействия. Они действительны не только при взаимодействии человека с компьютером, но и в реальной жизни. Удаление того, что не нравится пользователям, и концентрация того, что им нравится, — первый шаг к повышению удовлетворенности пользователей. Ниже перечислены 10 вещей, которые пользователи ненавидят:
Пользователи ненавидят обучение
Обучение требует когнитивных инвестиций со стороны пользователя. Не имеет смысла изучать новые взаимодействия, если нет возврата инвестиций, которые мы должны сделать, чтобы изучить их. Использование в интерфейсе стандартных элементов и визуальное согласование этих элементов между взаимодействиями позволяет пользователю один раз изучить, а затем применить эти знания в любом месте. Метафоры реального мира могут ускорить обучение и помочь пользователям понять мельчайшие детали, поскольку они позволяют разработчику использовать то, что пользователь уже изучил в реальной жизни.
Например, метафора путешествия, используемая во Всемирной паутине, упрощает серфинг для всех, а скос кнопки предлагает пользователю «нажать».
Каждый пользователь имеет собственную предсуществующую модель, когда он приближается к интерфейсу. Интерфейс должен быть достаточно гибким, чтобы вместить все эти пользовательские модели. Например, пользователь может ввести номер телефона как 617-493-4984 или (617) 493 4984, поэтому интерфейс должен быть готов принять и то, и другое.
Характерно, что пользователи будут пытаться узнать позиции различных элементов в интерфейсе и впоследствии пытаются взаимодействовать с ними, не глядя на элемент каждый раз. Помогая пользователю запоминать важные элементы, а исправление местоположения этих элементов повысит эффективность обучения. Интерфейс должен быть чистым и простым — это облегчает опытным пользователям запоминание вещей и предотвращает потерю новых пользователей в интерфейсе. Распределение элементов по группам сохраняет интерфейс незагроможденным. Персоны также могут помочь разработчикам предотвратить распространение функций и сосредоточиться на пользователе.
Пользователи могут легче узнавать новую информацию понемногу, поэтому предоставление пользователям нескольких новых задач за раз может быть более эффективным, чем наводнение их информацией. Однако учебный материал не должен препятствовать доступу пользователя к реальному контенту; таким образом, элементы интерфейса должны быть как обучаемыми, так и сканируемыми. Это позволит начинающим пользователям изучать новые функции, а опытные пользователи смогут быстро выполнять задачи.
Например, кнопки должны иметь текст / подсказку и значок. Текст / всплывающая подсказка делают кнопку доступной для изучения, а значок — ее можно просматривать. Поддержание медленной эволюции интерфейса также помогает пользователям учиться и опирается на предыдущие успехи в создании зрелого продукта. Тестирование новых функций на незначительной части реальных пользователей предоставляет разработчику реальную производительность модификаций и позволяет медленной эволюции происходить.
Пользователи ненавидят повторять
Никто не любит вводить данные; нам нравится повторять данные еще меньше. Сколько раз вы пропускали ввод личной информации в Интернете? Что вы чувствуете, когда теряете данные, на которые вы потратили время и силы (например, вопрос или комментарий в веб-форме)? Автоматический сбор данных и повторное использование информации избавят ваших пользователей от хлопот ввода данных.
Пользователи хотят получать или записывать данные один раз и иметь возможность использовать их где угодно. Любые данные, которые могут быть собраны автоматически, такие как контекстная информация о местоположении, задаче, состоянии и т. Д., Должны быть получены таким образом. Основное преимущество многофункциональных интернет-приложений заключается в том, что они поддерживают обогащение данных даже на стороне клиента и позволяют повторно использовать загруженные данные с помощью логики на стороне клиента. Информация должна быть способна перетекать, в соответствии с взаимодействием пользователя с сайтом, в другой связанный контент. Использование стандартных форматов для хранения данных сделает пользователя счастливым благодаря возможности такого взаимодействия. Блокируя данные в определенном приложении, пользователи могут использовать приложение, но они будут ненавидеть его, если оно не поддерживает определенную задачу, которая им нужна.
Значения по умолчанию для различных компонентов в интерфейсе должны отражать большинство предпочтений, но их также следует легко удалять, чтобы пользователь мог устанавливать новые значения. Например, текстовые поля должны быть заполнены значениями по умолчанию и предварительно выбраны, чтобы можно было легко удалять. Автозаполнение является еще одним способом повторного использования данных, даже если программное обеспечение не полностью понимает эти данные. Хранение всех данных, собранных на сервере, дает пользователю возможность непрерывно работать на разных устройствах. По этой причине данные должны быть скопированы, а не перезаписаны, чтобы предотвратить потерю данных.
Пользователи ненавидят ожидания
Ожидание появления кого-то или чего-либо утомительно. Сколько раз вам надоело ждать, когда появится друг? Мы ненавидим ждать еще больше, если не знаем, как долго нам ждать. Поэтому важно быстро загружать данные и показывать прогресс — пользователь может планировать и приспосабливаться к другим задачам. Предоставление пользователям доступа к предыдущему заданию и отображение прогресса будет занимать внимание пользователя и держать его в курсе во время загрузки данных. Переключение между задачами во время ожидания требует усилий пользователя — и это еще одна причина, по которой важна скорость. Отображение частично загруженных данных также поможет минимизировать ожидаемое ожидание.
Если нельзя избежать длительного времени ожидания, пользователь должен быть проинформирован о том, что он получит предупреждение после загрузки данных.
Соответствующие оповещения следует отправлять по завершении ожидающих запросов, когда пользователь возвращается в онлайн. Различные типы предупреждений необходимы для предотвращения беспокойства пользователя во время выполнения важной задачи. Например, один тип предупреждения появляется со звуком, независимо от того, что делает пользователь. Другой тип оповещений объединен в список, который пользователь увидит, когда он будет свободен. Еще один всплывает на тикере в боковой панели, на который пользователь будет смотреть, когда они станут доступны. Оповещения должны настраиваться пользователем.
Пользователи ненавидят поиск
Невозможность найти то, что вы ищете, может разочаровать. Невозможно запомнить, где находятся вещи, если их местоположение часто меняется. Поддержание согласованной навигации важно, чтобы помочь пользователям найти информацию, которую они хотят. Когда мы находимся в новом месте, мы обходимся, обращаясь к кому-то за помощью или глядя на знаки. Точно так же поиск и навигация очень важны при поиске материала в онлайн-среде.
В реальном мире мы распределяем время между задачами и размещаем информацию по темам. Мы также хотели бы, чтобы в одном месте было удовлетворено как можно больше наших потребностей — это просто и экономит время.
Вот почему супермаркеты и торговые центры оказались настолько популярными. В случае веб-приложений пользователь ищет задачи, которым он может следовать для достижения конкретных целей. Последовательность задач делает процесс; Процесс варьируется для разных пользователей. Разработчик может не иметь возможности предусмотреть на этапе проектирования все процессы, которые пользователь может захотеть выполнить в приложении. Некоторые сценарии могут измениться на более позднем этапе; некоторые сценарии могут даже не существовать на этапе проектирования. Поэтому проще спросить, куда пользователь хочет перейти от задачи, чем перечислить все возможные процессы. Если интерфейс разработан на основе жесткого процесса, пользователи могут чувствовать себя запертыми. Одним из преимуществ html является то, что пользователь может быстро и легко перемещаться по информации сайта так, как этого не ожидал дизайнер. Приложение должно позволять пользователю создавать личные процессы, которые по мере необходимости охватывают группу услуг и контент.
Процессы успешно направляют пользователей к цели, накладывая минимальную когнитивную нагрузку, но они ограничивают интересную работу творческих пользователей. Начинающие пользователи любят следить за задачами, которые попадают в процесс по умолчанию. Задачи, связанные жесткими навигационными системами, легче использовать, хотя эти же системы часто ограничивают опытных пользователей. Чтобы не задушить творческий потенциал пользователя, интерфейсы на основе задач должны быть слабо связаны. Переход от одной задачи к другой через множество аспектов, в которые попадают эти задачи, хорошо подходит для опытных пользователей. Плохо спроектированные интерфейсы, скорее всего, будут организованы вокруг определенной функции или внутренней структуры, предоставляя пользователю возможность выяснить, какая последовательность функций будет выполнять его конкретную задачу. Ориентированный на задачи интерфейс направляет пользователя через последовательности действий, устанавливая задачи и связывая их с помощью контекстной навигации.
Пользователь также может быть направлен на идеальный процесс с помощью эффективной информационной архитектуры. Собранные навигационные данные также можно использовать для направления пользователей к процессам, которым следовали другие. Панель задач Microsoft является хорошим примером обеспечения контекстной навигации между различными задачами.
Разделение приложения на интерфейсы на основе задач и присвоение каждой задаче URL-адреса позволяет связать их из Интернета. Ссылки из Интернета на различные задачи в приложении упростят его поиск пользователями.
Пользователи ненавидят чтение
Картина говорит тысячу слов. Вы бы пробежались по страницам табличных данных, если бы вы могли просматривать ту же информацию в виде графика? Чтение информации в виде текста требует от нашего мозга визуализации данных. Графическое представление этой информации может уменьшить эти усилия.
Люди хорошо умеют сканировать, и мы распознаем и запоминаем изображения легче, чем текст. Графические элементы облегчают сравнение длины, формы, ориентации и текстуры. Анимация может показать изменения во времени. Цвет помогает нам делать различия. Изображения помогают нам достичь этих целей гораздо эффективнее, чем текст.
Графические элементы для большинства людей более доступны, чем текстовые, но у некоторых пользователей с ограниченными возможностями возникают проблемы с оценкой графических элементов. Компьютеры также не могут хорошо понимать графические данные.
Текст — это формат, который можно интерпретировать повсеместно. Таким образом, данные, поступающие с сервера на интерфейс, более полезны, если они текстовые. Интерфейс должен представлять эти данные так, чтобы они были доступны всем пользователям.
Пользователи ненавидят нарушения безопасности
Хотя мы рады поделиться с некоторыми людьми некоторой информацией, мы предпочитаем сохранять ее конфиденциальность. Непреднамеренное предоставление другим программам доступа к частным данным может иметь катастрофические последствия. Например, если разрешить любой программе доступ к пользовательской адресной книге Microsoft Outlook, откроется банка червей.
Пользователи не любят вводить свою информацию — они предпочитают, чтобы она собиралась автоматически. Разработчик должен иметь возможность контролировать совместное использование этих данных, чтобы предотвратить нарушения безопасности. Согласие пользователя должно быть запрошено до передачи его личной информации или других собранных данных. Перечисление проблем и преимуществ, которые могут возникнуть из-за того, что пользователь разрешил сайту делиться своей информацией с другими, поможет пользователю принять решение. Если пользователь дает разрешение на обмен данными, они должны быть доступны для различных сторон в стандартных форматах.
Настройки безопасности по умолчанию очень важны, так как немногие пользователи пытаются их пройти. Всегда лучше начать со строгой политики безопасности и ослабить ее по мере необходимости, чем пытаться перейти от свободной политики к более строгой. Влияние всех новых функций и данных на безопасность и конфиденциальность следует учитывать перед внедрением.
Пользователи ненавидят монотонный взгляд
Монотонные интерфейсы скучны. Люди хотят выделяться в группах, к которым мы принадлежим, и хотят распространять свою идентичность на то, что мы используем; нам нравится, что наши вещи отражают нашу личность. Фон, скины и звуки — это несколько способов дать пользователям возможность изменять внешний вид приложений, которые они используют. Простое предпочтение настройки фона и звуков удовлетворит большинство пользователей.
Но будьте осторожны! Хотя пользователям нравится новый внешний вид, им не нравится изучать новые взаимодействия, поэтому лучше сохранять элементы интерфейса визуально совместимыми с взаимодействиями — таким образом, пользователям не придется заново изучать интерфейс, если они применяют новый скин для вашего приложения.
Пользователи ненавидят ограничения платформы
Мы ненавидим тех, кто мешает нам делать то, что мы хотим. Законы были сделаны, чтобы предотвратить ограничения в реальном мире. «Сделай это доступным для всех и везде!» — вот девиз. Приложения не должны быть ограничены конкретной операционной системой, форм-фактором или возможностями пользователя.
Пользователям нравится учиться использовать приложение один раз, а затем иметь возможность использовать его где угодно: на компьютере, на портативном устройстве или на планшете. Пользователи с различными способностями также должны иметь доступ к приложению с помощью специализированного программного обеспечения.
Возможность развертывания приложений в различных операционных системах в разных программах обеспечения доступности является важным критерием при выборе платформы разработки.
Пользователи ненавидят жесткую функциональность
Один размер не подходит для всех. Функциональность инструмента значительно снижается, если он не подходит пользователю идеально. Каким был бы мир, если бы был только один размер обуви?
Опции для добавления, удаления и изменения различных функций должны быть предоставлены пользователю. Маловероятно, что пользователи изменят все настройки, чтобы приложение подходило им. Они ожидают, что приложение будет создано специально для них, или что оно будет автоматически знать, чего они хотят, следуя их действиям.
Различные предустановки могут быть доступны для пользователей в зависимости от того, какие лица вы определили как вероятные для использования продукта. Настройка предпочтений может быть упрощена, если панель управления связана с контекстом, в котором пользователь может захотеть внести изменения. Такая функция, как увеличение размера шрифта, может быть очень полезна для многих пользователей.
Пользователи ненавидят ошибки
Мы ненавидим делать ошибки, но часто нет способа их предотвратить. Возможность отмены наших действий может позволить нам оправляться от ошибок и учиться на них. Как было бы здорово, если бы функция отмены присутствовала в реальном мире!
Ваше приложение должно отслеживать все действия пользователя и разрешать им отменять эти действия. Автосохранение всех действий предотвращает потерю данных, если приложение было закрыто по ошибке. Данные, собранные функцией отмены, могут также помочь пользователю отслеживать путь навигации, по которому они следовали. Отслеживание действий пользователя позволяет получать интересные метаданные от взаимодействия пользователя с контентом; способы, которыми люди могут использовать эти метаданные для улучшения своей работы, также могут стать очевидными благодаря этому процессу.
Разделение отдельных действий пользователя также может помочь в разработке макросов для повторения действий пользователя. Если определенное действие необратимо, пользователю должно быть представлено сообщение «Вы действительно, действительно уверены?», Прежде чем его запрос будет выполнен. Лучше сделать резервную копию данных и дать пользователю возможность отменить свои действия, чем наводнить пользователя этими сообщениями.
Отслеживание всех действий пользователя имеет огромное преимущество в процессе регистрации действий. Веб-браузер информирует владельца сайта о странице реферера, но оставляет пробел в информации отслеживания, когда пользователь покидает сайт. Богатые интернет-приложения должны быть в состоянии собрать все пользовательские действия, которые имеют огромное значение для дизайнера и могут определять будущий путь приложения.
«Выпускать раньше и выпускать чаще» — это принцип, позволяющий быстро учесть отзывы пользователей в программном обеспечении. Лучшую обратную связь можно получить, протестировав новую функцию на примере реальных пользователей. Ошибки, возникающие при попытке пользователя изучить интерфейс, а также проблемы с самими измерениями можно минимизировать путем прямого тестирования.
Полезная архитектура
Несмотря на многолетний опыт разработки программного обеспечения, нам еще предстоит разгадать загадки сложности программного обеспечения. Для разработки пригодных для использования многофункциональных интернет-приложений необходимо, чтобы процесс разработки был как можно более простым, не пренебрегая ни одним из вышеуказанных ограничений удобства использования.
Шаблоны облегчают работу архитектора, предоставляя ему систему для хранения уроков, которые они извлекли. Большинство программных шаблонов помогают разработчику познавать проблемы, с которыми сталкиваются другие, и обходить их стороной. Шаблон, который уменьшает сложность для программиста, не позволяя им потерять пользователя, пойдет на пользу разработчику приложения.
Чтобы спроектировать сложную структуру, одним из эффективных методов является обнаружение жизнеспособных способов ее разделения на полунезависимые компоненты, которые соответствуют ее многочисленным функциональным частям. Дизайн каждой части может быть выполнен с некоторой степенью независимости — поскольку каждая из них будет влиять на другие в значительной степени благодаря своей функциональности — и не зависит от деталей механизмов, которые выполняют функцию.
Сложность приложения уменьшается, когда оно разбивается на менее зависимые части. Такое разделение на управляемые части также сделает приложение способным к эволюции, а не к революции, поскольку этот подход позволяет легко и с небольшими изменениями вносить изменения.
Теперь возникает вопрос: как нам разбить богатое интернет-приложение, чтобы проектирование с учетом вышеупомянутых ограничений удобства использования стало проще? Разделение приложения на страницы и навигация помогут. Каждая страница состоит из данных, компонентов, логики и представления. Страницы заключены в оболочку навигации, которая снова содержит данные, компоненты, логику и представление.
страница
Страница представляет собой совокупность данных, компонентов, логики и представления. Все взаимодействия, которые выполняются вместе, группируются для формирования задачи. Страница инкапсулирует все эти взаимодействия. Пользователи взаимодействуют, визуализируя и изменяя различные объекты на странице через различные представления. Изменение объекта в одном представлении может быть немедленно отражено в других представлениях на странице, поскольку многофункциональное интернет-приложение имеет дело с моделью данных объекта, а не с представлением данных объекта.
Локальное отражение модели данных также позволит автономно взаимодействовать. Например, табличный объект данных может отображаться в разных представлениях. Таблица со всеми столбцами, ползунок с максимальными и минимальными значениями столбца и поля для отметок, содержащие значения столбца, представляют собой несколько представлений объекта данных таблицы, с которым пользователь может взаимодействовать. Настройка вида ползунка должна обновлять представление таблицы в режиме реального времени. Изменения, внесенные в данные, могут быть отправлены на сервер, когда пользователь подключается к сети.
Отделение навигации от страницы не означает, что страницы не должны содержать ссылок на другие страницы. Если страница соответствует процессу по умолчанию, навигация должна быть интегрирована в нее, чтобы помочь начинающим пользователям. Чистые и простые страницы легко усваиваются. Простота может быть достигнута за счет сокращения количества элементов в интерфейсе и разделения их на группы. Архитектор взаимодействия отвечает за дизайн страницы на основе задач.
навигация
Навигация предоставляет ссылки с данной страницы на различные другие страницы, в зависимости от контекста исходного местоположения пользователя. Это совокупность навигационных данных, навигационной логики, навигационного представления и навигационных компонентов на страницах. Данные навигации организуют отношения между страницей и другими страницами в различные аспекты.
Стандартные форматы, такие как Xfml (eXchangeable Faceted Metadata Language), могут использоваться для хранения навигационных данных. Другие данные, такие как путь навигации, по которому следуют пользователи, также могут использоваться в навигации.
Наличие последовательного навигационного макета поддерживает более легкий просмотр страниц сайта. Категоризация связанных ссылок или уменьшение количества ссылок упрощает навигацию. Если дать URL-адрес страницам и сделать их доступными из Интернета, приложения будут доступны для поиска.
Информационный архитектор отвечает за структуру навигации и контекстное связывание различных страниц.
Данные
Данные разделяются в богатых интернет-приложениях, поскольку они поступают с сервера или собираются отдельно на стороне клиента. Некоторые из различных типов данных включают в себя данные приложения, данные предпочтений, данные журналов и данные навигации.
Некоторые данные существуют только на стороне клиента, но, отражая все данные на сервере, пользователь получает согласованные данные на разных устройствах. Веб-сервисы на стороне сервера обрабатывают сложности отправки данных приложения в соответствии с полученными запросами. Ограничение общего доступа к данным и эффективное управление им между приложениями поможет владельцу сайта поддерживать безопасность. Кроме того, использование стандартных форматов для хранения данных обеспечит взаимодействие между приложениями.
логика
Логика — это код, который описывает поведение приложения. Он соединяет компоненты, презентацию и данные. Объектно-ориентированные принципы могут быть использованы для уменьшения сложности в логике. Программист приложения отвечает за логику, которая входит в приложение.
Компоненты
Компоненты являются основными строительными блоками интерфейса. Несколько типов компонентов — это компоненты взаимодействия, компоненты загрузки данных, компоненты навигации и компоненты агента / оповещения.
Компоненты взаимодействия обеспечивают визуализацию и получают взаимодействия от пользователя для определенного типа данных. Отделение компонента от логики, представления данных и структуры поможет быстрой разработке и даст разработчику приложения гибкость для реализации доступных пользовательских интерфейсов. Компоненты должны принимать текст и обеспечивать доступную визуализацию для всех пользователей.
Предоставление различных способов ввода одной и той же информации помогает пользователям взаимодействовать с приложением без изменения их пользовательской модели. Компоненты с возможностью автозавершения также снижают рабочую нагрузку на пользователя.
Обеспечение возможности изучения и сканирования компонентов делает их удобными как для начинающих, так и для опытных пользователей. Компоненты должны иметь возможность регистрировать действия пользователя и выполнять действия, чтобы включить функцию отмены.
Реальные метафоры и возможности позволяют пользователю взаимодействовать с программным обеспечением без изучения новых вещей. Различные метафоры могут быть использованы для упрощения взаимодействия с компонентами.
В Интернете используется метафора путешествия, где пользователи нажимают на объекты, чтобы перейти на новую страницу для выполнения операции. Настольные приложения используют метафору семинара, где у нас много инструментов для работы с различными выбираемыми объектами. В морфической графической системе задачи появляются на самих объектах после их выбора, что соответствует метафоре исследования. Набор стандартных отраслевых компонентов, соответствующих последовательной метафоре, позволит пользователю освоить один раз и использовать эти знания в любом месте.
Компоненты загрузки данных управляют данными на стороне клиента и на стороне сервера. Они предоставляют обновления прогресса на странице, отправляют частичные загрузки данных в компоненты взаимодействия и обеспечивают бесперебойный онлайн и офлайн доступ к данным. Компоненты навигации инкапсулируют страницу и навигационную информацию в приложении. Компоненты оповещений или агентов работают в фоновом режиме и выдают пользователю различные типы оповещений.
презентация
Презентация имеет дело с визуальным отображением компонентов. Расположение, размеры, цвета и фон компонентов определяются презентацией.
Последовательное расположение для аналогичных типов элементов поощряется путем отделения представления от приложения. Большинство преимуществ, которые приходят с использованием CSS на веб-страницах, применимы и здесь. Визуальный дизайнер отвечает за презентационную часть приложения.
Преимущества шаблона
Таким образом, шаблон предоставляет разработчику и разработчику приложений ряд преимуществ, которые помогают им разрабатывать полезные многофункциональные интернет-приложения. Шаблон…
- отделяет задачи в соответствии с областями экспертов, что позволяет разрабатывать полупараллельные приложения
- позволяет разработчикам работать в рамках ограничений юзабилити
- отделяет компоненты от программного обеспечения, ускоряя разработку
- создает среду, в которой страница не зависит от навигации, которая поддерживает своевременные процессы
- делает презентацию независимой от страниц, способствуя согласованному макету страницы
- обеспечивает большую масштабируемость приложения за счет уменьшения сложности
- облегчает обслуживание благодаря разделению приложения на разные части
Даже если текущие инструменты не поддерживают этот шаблон, выгодно думать о приложении таким образом из-за преимуществ, которые он предоставляет: он обеспечивает гибкость, дает независимость экспертам в области и упрощает проблему, не теряя при этом ограничений юзабилити. ,
Наличие нескольких вариантов иногда ошеломляет новых дизайнеров и увеличивает сложность. Ограничения, введенные посредством шаблонов проектирования, порождают креативность в рамках ограничений дизайна.
Шаблоны помогают уменьшить сложность и облегчают понимание данной проблемы. Тем не менее, шаблон проектирования не является «серебряной пулей» или панацеей для какой-либо проблемы, и его следует применять только тогда, когда его гибкость действительно необходима.
Для получения дополнительной информации см .:
Время HTML прошло. Давайте двигаться дальше.
http://www.boxesandarrows.com/archives/htmls_time_is_over_lets_move_on.php
Macromedia центральная белая бумага.
http://www.macromedia.com/software/central/whitepaper/central_wp.pdf
Модель интеллектуального клиентского приложения и .NET Framework.
http://msdn.microsoft.com/netframework/using/building/windows/analystreports/smartclient.aspx
Java Web запускает архитектуру.
http://java.sun.com/products/javawebstart/architecture.html