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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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