Различия в построении пользовательского интерфейса между веб-приложениями и настольными приложениями
Интерфейс для веб-приложений отличается от интерфейса для настольных приложений. Мне интересно узнать, каковы на самом деле основные различия в построении пользовательского интерфейса между двумя стилями приложений в следующих областях:
1. Используемая технология
2. используемые методы
3. Используется управление
4. Экран, изменяющий поведение
8 ответов
Большая разница в дизайне, которую пропускают многие, - это структура самого окна.
- Настольное приложение, как правило, создается с минимальным разрешением по высоте и ширине (часто 800*600) и изо всех сил старается уместить всю релевантную информацию в размер меньше этого, потому что полосы прокрутки обычно очень плохая практика для нетабличные / списочные данные. Там, где требуется больше места, информация обычно делится на новые окна или подоконные панели / вкладки.
- Веб-приложение, с другой стороны, имеет практически бесконечную вертикальную высоту, поскольку большинство людей привыкли к прокрутке в своем веб-браузере. Полоса прокрутки больше не плохая вещь; на самом деле, использование полосы прокрутки в любом месте, где может использоваться основная, обычно считается дурным тоном (за некоторыми исключениями, конечно). Информация, как правило, отображается в одном "окне", поскольку ее разделение потребует как отдельных загрузок страницы, так и повторной загрузки идентичных данных (стилей, меню и т. Д. Да, кеш есть, но он не такой быстрый, как не загружать одну страница). Больше нагрузок всегда медленнее, и вызывают чувство разрыва. Иногда они неизбежны, но вы почти никогда не должны ограничивать свое приложение только видимым размером окна браузера.
- Многие люди используют веб-браузер для чтения. Новости, блоги, комментарии на YouTube и т. Д. Когда вы создаете веб-приложение, оно должно отражать эту привычку, потому что в противном случае вы будете толкать мозги людей через совершенно разные макеты, если они переключаются между веб-страницами и вашим приложением (и вы знаете, что некоторые будут). Может показаться, что вы просто копируете крупных игроков, но последовательность гораздо важнее, чем кажется на первый взгляд.
- Столбцы текста не должны быть сверхширокими, потому что чем шире строка, тем сложнее перейти к следующей строке, чтобы продолжить чтение. Придерживайтесь чего-то похожего на то, что есть в книгах; они были очищены на протяжении веков. Это одна из причин, почему многие веб-страницы имеют фиксированную ширину и предпочитают столбцы по строкам.
- Пустое пространство важно. Это помогает отделить информацию и облегчает обработку. Представьте, что вы читаете этот ответ без пробелов, новых строк или маркеров.
Моя любимая мозоль - текстовые ссылки, которые выполняют частые действия. Если вы на самом деле не "ссылаетесь" на отдельную страницу, не делайте ее похожей на ссылку. Сделайте это контролем, или изображением, или чем-то. Ссылки для перемещения по сайтам, кнопки делают вещи. Большинство людей активно игнорируют синий подчеркнутый текст, когда хотят что-то сделать, потому что они привыкли к кнопке "отправить форму" или к чему-то подобному. Ссылки также довольно малы, и их довольно сложно щелкнуть для повторяющихся действий, и для меня это запах неполного дизайна / кодирования при широком использовании.
Многие веб-приложения, которые я видел, которые, как правило, терпели неудачу, пытаются дублировать настольное приложение в окне браузера... которое вставляет круглый стержень в квадратное отверстие. Это можно сделать, но это не одно и то же, и к ним не следует относиться как таковым практически при любых обстоятельствах.
Частичное исключение - это когда веб-приложение дублирует функцию настольного приложения (т. Е. Google docs). Затем макет все равно должен отражать веб-страницу больше, чем приложение в большинстве случаев, но элементы управления, вероятно, должны имитировать настольное приложение, чтобы помочь людям переходить.
Большинство людей используют программы на своем рабочем столе, чтобы что- то делать. Большинство людей используют свои браузеры, чтобы что-то увидеть (прочитать, посмотреть и т. Д.). Конечно, есть кроссовер, но подумайте о повседневных привычках большинства людей и помните, что другие люди будут использовать то, что вы разрабатываете; это не только ты (и твои клоны) там.
И, хотя он повторяет другие, кнопка "Назад" имеет решающее значение. Если вы сломаете его, пользователи захотят сломать вас. Переопределение меню или поведения при щелчке правой кнопкой мыши также обычно является плохой идеей и в основном раздражает пользователей (а некоторые будут активно предотвращать JavaScript, который делает это, потому что это их так раздражает (включая меня)).
Одна важная вещь, которую вы не можете игнорировать в веб-дизайне, это кнопка "Назад" Тысячи людей пытались отключить или обойти это. Не пытайтесь обойти кнопку назад! Вместо этого сделайте кнопку возврата частью вашего дизайна.
Самым большим отличием является IMO в том, что в веб-приложении вы оказываете очень ограниченное влияние на поведение мыши и то, что у вас есть, противоречит установленному поведению рабочего стола. Например:
- В настольных приложениях щелчок правой кнопкой мыши почти всегда приводит к появлению контекстного меню. В веб-приложении тоже, но это контекстное меню браузера, которое вы не можете (и не должны) изменять.
- В настольных приложениях один щелчок выбирает что-то, двойной щелчок выполняет что-то; в веб-приложении один щелчок уже "выполняет" ссылку, а двойных щелчков не существует.
Настольные приложения, как правило, пишутся с использованием шаблона "при этом событии выполнить этот блок кода". Веб-приложения работают в более блочном режиме: "сервер форматирует всю страницу, пользователь заполняет форму и нажимает кнопку, сервер обрабатывает всю форму, сервер форматирует другую целую страницу".
AJAX слегка мутит воду, потому что браузер может запрашивать некоторые данные в фоновом режиме и обновлять части страницы. Однако основной принцип остается.
Проще заставить графический интерфейс рабочего стола реагировать на определенные движения мыши и щелчки и т. Д. Для веб-приложений, с другой стороны, единственное общение с сервером - это запросы "get" и "post", поэтому пользовательский интерфейс гораздо более неудобен.
Веб-приложения гораздо более портативны, и вы можете использовать только совместимое с клиентом программное обеспечение - совместимый браузер. Эти преимущества управления системой - то, почему люди мирились с немного худшим GUI.
Межкадровое общение сложно в веб-браузере. Например, наличие одного iframe влияет на другой iframe с помощью javascript. Прежде всего потому, что время загрузки может быть разным, поэтому кадру A может потребоваться ждать в цикле таймера для загрузки кадра B.
В веб-интерфейсе обмена сообщениями действительно необходимо учитывать цикл запроса / ответа. Трудно сделать что-то вроде: "если запись изменяется в базе данных, выведите сообщение на экране пользователя". Кроме того, если нажатие кнопки должно обновить 5 различных фреймов, вы можете получить 5 отдельных запросов к серверу. Не нужно беспокоиться об этом в настольном интерфейсе.
Основным отличием является то, что Visual действительно быстро собирается на настольном компьютере и не нуждается в тестировании с другим браузером. Я всегда находил очарование для создания рабочего стола, потому что часть программного обеспечения Visual просто привязана к вашему контроллеру (который содержит вашу модель), и вы на ходу!
Другое отличие - скорость загрузки. Вам не нужно передавать Javascript или CSS для отображения... Вам не нужно архивировать или что-то еще, потому что это всегда доступно в исходном коде на рабочем столе.
Другое дело, что вы можете использовать оперативную память компьютера для выполнения сложных задач, и это, как правило, уменьшает необходимость иметь несколько компьютеров на стороне службы, поскольку вы можете использовать все эти компьютеры для "обработки" большого процесса (при необходимости).
С другой стороны, развертывание сложнее (у вас есть ClickOnce и автоматический инструмент, который может вам помочь), но оно никогда не бывает таким прозрачным для сети. Таким образом, вы должны быть более спланированы, чтобы делать релиз, потому что вы не можете делать "исправления".
Интересно прочитать здесь: Веб-приложения против MS Windows Apps.
Единственное, что я нашел больше всего, это привязка данных. Концепция все та же, но с веб-приложениями вы всегда беспокоитесь о том, следует ли повторно привязать указанный элемент управления, чтобы обновить данные на основе какого-либо другого события. Хорошая вещь о настольных приложениях заключается в том, что это не так важно, поскольку нажатие какого-либо другого события или переход на другую вкладку не приведет к аннулированию данных в элементе управления.