Различия в построении пользовательского интерфейса между веб-приложениями и настольными приложениями - PullRequest
2 голосов
/ 05 декабря 2008

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

1. Используемая технология

2. Используемая техника

3. Используемые элементы управления

4. Экран, изменяющий поведение

Ответы [ 8 ]

7 голосов
/ 05 декабря 2008

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

5 голосов
/ 05 декабря 2008

Большая разница в дизайне, которую пропускают многие, - это структура самого окна.

  • Настольное приложение, как правило, строится с минимальным разрешением по высоте и ширине (часто 800 * 600) и изо всех сил старается уместить всю необходимую информацию в меньшем размере, потому что полосы прокрутки обычно очень плохая практика для не табличных / списочных данных. Там, где требуется больше места, информация обычно делится на новые окна или подоконные панели / вкладки.
  • Веб-приложение, с другой стороны, имеет практически бесконечную вертикальную высоту, так как большинство людей привыкли к прокрутке в своем веб-браузере. Полоса прокрутки больше не плохая вещь; на самом деле, использование полосы прокрутки в любом месте , где может использоваться основная, обычно считается плохой формой (конечно, за некоторыми исключениями). Информация, как правило, отображается в одном «окне», поскольку ее разделение потребует как отдельных загрузок страницы, так и повторной загрузки идентичных данных (стилей, меню и т. Д. Да, кеш есть, но он не такой быстрый, как не загружать одну страница). Больше нагрузок всегда медленнее и вызывает чувство разрыва. Иногда они неизбежны, но вы почти никогда не должны ограничивать свое приложение только видимым размером окна браузера.
  • Многие люди используют веб-браузер для чтения. Новости, блоги, комментарии на YouTube и т. Д. Когда вы создаете веб-приложение, оно должно отражать эту привычку, потому что в противном случае вы будете ломать мозги людей через совершенно разные макеты, если они переключаются между веб-страницами и вашим приложением (и вы знаете, что некоторые будут). Может показаться, что вы просто копируете крупных игроков, но последовательность гораздо важнее, чем кажется на первый взгляд.
  • Столбцы текста не должны быть сверхширокими, потому что чем шире строка, тем сложнее перейти к следующей строке, чтобы продолжить чтение. Придерживайтесь чего-то похожего на то, что есть в книгах; они были усовершенствованы в течение столетий . Это одна из причин, по которой многие веб-страницы имеют фиксированную ширину и предпочитают столбцы строкам.
  • Пробел важен . Это помогает отделить информацию и облегчает обработку. Представьте себе, что вы читаете этот ответ без пробелов, новых строк или маркеров.

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

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

Большинство людей используют программы на своем рабочем столе, чтобы делать что-то. Большинство людей используют свои браузеры, чтобы видеть что-то (читать, смотреть и т. Д.). Конечно, есть кроссовер, но подумайте о повседневных привычках большинства людей и помните, что другие люди будут использовать то, что вы разрабатываете; там не только ты (и твои клоны).

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

3 голосов
/ 05 декабря 2008

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

  • В настольных приложениях щелчок правой кнопкой мыши почти всегда приводит к появлению контекстного меню. В веб-приложении тоже, но это контекстное меню браузера, которое вы не можете (и не должны) изменять.
  • В настольных приложениях один щелчок выбирает что-то, двойной щелчок выполняет что-то; в веб-приложении один щелчок уже «выполняет» ссылку, а двойных щелчков не существует.
2 голосов
/ 05 декабря 2008

Настольные приложения, как правило, пишутся с использованием шаблона «при этом событии выполнить этот блок кода». Веб-приложения в более блочном режиме: «сервер форматирует всю страницу, пользователь заполняет форму и нажимает кнопку, сервер обрабатывает всю форму, сервер форматирует еще одну целую страницу».

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

Легче заставить настольный графический интерфейс реагировать на определенные движения мыши и щелчки и т. Д. Для веб-приложений, с другой стороны, единственная связь с сервером - это запросы "get" и "post", поэтому пользовательский интерфейс намного более неудобен. 1005 *

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

1 голос
/ 05 декабря 2008
  • Кросс-фреймовое взаимодействие затруднено в веб-браузере. Например, наличие одного iframe влияет на другой iframe с помощью javascript. Прежде всего потому, что время загрузки может быть разным, поэтому кадру A может потребоваться ждать в цикле таймера для загрузки кадра B.

  • В веб-интерфейсе обмена сообщениями действительно необходимо учитывать цикл запроса / ответа. Трудно сделать что-то вроде: «если запись изменяется в базе данных, выведите сообщение на экране пользователя». Кроме того, если нажатие кнопки должно обновить 5 различных фреймов, вы можете получить 5 отдельных запросов к серверу. Не нужно беспокоиться об этом в настольном интерфейсе пользователя.

1 голос
/ 05 декабря 2008

Основным отличием является то, что Visual действительно быстро собирается на настольном компьютере, и не нужно тестировать с другим браузером. . Я всегда находил очарование при создании рабочего стола, потому что визуальная часть программного обеспечения просто привязана к вашему контроллер (содержащий вашу модель) и вы в пути!

Другое отличие - скорость загрузки. Вам не нужно передавать Javascript или CSS для отображения ... Вам не нужно архивировать или что-то еще, потому что это всегда доступно в исходном коде на рабочем столе.

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

С другой стороны, развертывание сложнее (у вас есть ClickOnce и автоматический инструмент, который может вам помочь), но оно никогда не было таким прозрачным для веба. Таким образом, вы должны быть более спланированы, чтобы делать релиз, потому что вы не можете сделать «оперативное исправление».

1 голос
/ 05 декабря 2008

Интересно прочитать здесь: Веб-приложения против MS Windows Apps .

0 голосов
/ 05 декабря 2008

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...