Браузерное приложение или автономное приложение с графическим интерфейсом?

Question

Я уверен, что об этом уже спрашивали, но я не могу его найти.

Каковы преимущества / ограничения использования интерфейса на основе браузера для автономного приложения по сравнению с использованием обычной инфраструктуры графического интерфейса?

Я работаю над программой на Python, которая в настоящее время реализуется с помощью wxPython для GUI. Приложение просто пользовательские формы ввода и диалогов. Я подумываю о переходе на PyQt из-за имеющихся у него виджетов (для будущего расширения), а затем я понял, что, вероятно, я мог бы просто использовать браузер для выполнения многих подобных задач.

В настоящее время приложению не требуется доступ к Интернету, хотя в будущем это возможно. Я думал об использовании Karrigell для веб-фреймворка, если я использую браузер.

---

Редактировать Для пояснения, на данный момент приложение будет основано на браузере, а не на веб-сайте. Вся информация будет храниться локально на клиентском компьютере; не нужно выполнять серверные вызовы и не требуется доступ к Интернету (хотя это может произойти позже). Это был бы просто графический интерфейс браузера вместо графического интерфейса wxPython / PyQt. Надеюсь, что это имеет смысл.

Answer 1

Давайте на мгновение представим, что усилия / затраты на разработку / развертывание / обслуживание равны, и мы смотрим на это с точки зрения пользователя приложения:

Какой пользовательский интерфейс будет полезен пользователю?

в пересчете на

• Удобство использования
• Оперативность
• Знакомые шаблоны навигации / использования
• Больше всего похоже на другие инструменты / приложения, используемые на платформе (т.е. нативные)

Я понимаю, что "полезный" субъективен. Лично я бы никогда больше не использовал (как пользователь, а не разработчик) веб-интерфейс, если бы мне это удавалось. Я ненавижу их.

Некоторые приложения просто не имеют смысла разрабатывать как браузерные приложения.

С точки зрения развития

• Сегодня нет двух доступных браузеров, которые отображают точно одинаково.
• Даже с Ajax, javascript и динамическими адаптивными интерфейсами нетривиально реализовать / отладить.

Есть много-много автономных приложений с графическим интерфейсом, которые просто ужасны, без аргументов. Разработка / развертывание и обслуживание мультиплатформенного графического интерфейса нетривиальны.

Разработка хороших пользовательских интерфейсов сложна, и точка.

Реальность такова, что за последние 10 лет я зарабатывал на жизнь, разрабатывая в основном веб-приложения, потому что они быстрее развиваются, проще в развертывании и предоставляют достаточно утилит, чтобы люди могли использовать их в случае необходимости

Я не верю, что большинство пользователей будут использовать веб-интерфейс, если им предоставят альтернативу.

IMNSHO

Answer 2

Очевидные преимущества для браузера:

• вы можете представить один и тот же интерфейс независимо от платформы
• вы можете легко обновить приложение, и все пользователи имеют одинаковую версию приложения, работающую
• вы знаете среду, в которой будет работать ваше приложение (серверное оборудование / ОС), которое упрощает тестирование и поддержку по сравнению с множеством конфигураций операционной системы / оборудования, на которые будет установлено приложение с графическим интерфейсом.

А для графического интерфейса:

• некоторые приложения (например, редактирование изображений), возможно, лучше работают в собственном приложении с графическим интерфейсом
• не требует доступа к сети

Также смотрите мои комментарии по этому вопросу :

Кроссплатформенные графические интерфейсы - давняя проблема. Qt, GTK, wxWindows, Java AWT, Java Swing, XUL - все они страдают от одной и той же проблемы: полученный графический интерфейс не выглядит родным на каждой платформе. Хуже того, каждая платформа выглядит немного по-разному и чувствует , поэтому даже если бы вы каким-то образом смогли получить инструментарий, который выглядел нативно на каждой платформе, вам пришлось бы каким-то образом кодировать свое приложение, чтобы чувствовать себя как на каждая платформа.

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

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

Answer 3

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

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

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

На самом деле все сводится к тому, разрабатываете ли вы:

1. пользовательский интерфейс
2. приложение для ввода данных

Если вы создаете приложение для ввода данных, оставьте пользовательский интерфейс в браузере и сконцентрируйтесь на основных функциях.

Answer 4

Преимущества интерфейса на основе браузера:

• Легче в управлении: на пользовательских машинах установка не требуется, обновления необходимо выполнять только на стороне сервера и сразу же доступны всем пользователям. Резервное копирование данных может выполняться на одном компьютере, поскольку данные не будут распределены по нескольким клиентам.
• Приложение может быть доступно с любого компьютера с браузером.
• Может легко поддерживать несколько платформ последовательно.
• Требования к памяти и ЦП могут быть значительно меньше на стороне клиента, поскольку на сервере могут выполняться интенсивные операции.
• Повышенная безопасность: данные хранятся на одном сервере, а не на нескольких клиентских компьютерах, и доступ к ним можно лучше контролировать.
• Многие другие преимущества централизованной среды, включая ведение журналов, данные, введенные из нескольких источников, могут быть немедленно доступны от других клиентов и т. Д.
• По моему опыту, зачастую проще отлаживать и быстрее разрабатывать веб-решения.

Преимущества интерфейса на основе графического интерфейса:

• Может быть проще разработать более гибкий и гибкий интерфейс.
• Может использовать функции, специфичные для ОС, которые могут быть недоступны через браузер.
• Не обязательно требует доступа к сети.
• Не нужно беспокоиться о проблемах совместимости браузера.
• Нет единой точки отказа, если сервер отключается или становится недоступным.

Answer 5

Для этой задачи (ввод текста на основе форм) отлично подойдет браузер. Вам не нужно ничего, что даст вам настольное приложение (скорость, гибкость)

Существуют недостатки веб-приложения, такие как ..

Это веб-страница. Есть вещи, которые вы просто не можете (легко) сделать

Вы не можете легко сопоставить клавишу ctrl + j, чтобы что-то сделать. Например: Google Spreadsheet пытается сопоставить сочетания клавиш и работает в большинстве случаев времени, иногда обработка ярлыков в браузерах по умолчанию занимает более длительное время.

Вы не можете делать оповещения Growl (платформа уведомлений OS X). Вы не можете получить доступ к файловой системе. Трудно разрешить доступ в автономном режиме.

Javascript очень загружен процессором.

Попробуйте изменить размер документа Google Spreadsheet или загрузить страницу в Digg (очень тяжелый JavaScript-сайт) - загрузка ЦП браузеров будет некоторое время на уровне 100%. Делать то же самое в собственном настольном приложении тривиально

Когда вы выполняете обновления, вы заставляете их всех ваших пользователей. С настольным приложением у них есть выбор не обновлять. Например, мне не понравилось одно из обновлений Google Reader, но я застрял. Используя NetNewsWire (настольное приложение), если мне не нравится изменение в последней версии, я могу довольно легко использовать его (или попробовать и понизить версию)

Ваш веб-сервер должен быть доступным всегда, всегда

Если сервер исчезнет, ​​ваши пользователи не смогут обратиться за помощью. Приложение пропало. Если он не работает в течение 10 минут, они не могут его использовать.

---

С вашим приложением, хотя я не совсем уверен, что это такое, ни один из вышеперечисленных вопросов не вызывает проблем.

"Это веб-страница" : формы и диалоговые окна легко создавать в HTML и javascript (или даже с использованием серверных сценариев, например <?php if($_POST["email"] ==""){echo("Are you sure you want to continue?); ?>)

«Javascript очень загружен процессором» : не похоже, что ваше приложение потребует какой-либо Javascript (возможно, некоторая проверка ввода на стороне клиента, когда пользователь нажимает «Отправить», чтобы предупредить их о любые ошибки ввода?)

«Принудительное обновление» : я полагаю, что это может быть желательно, поскольку вы не хотели бы, чтобы пользователи вводили данные по-старому.

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

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

Answer 6

Есть довольно убедительные доказательства того, что проблема козырей в большинстве случаев заключается в возможности развертывания и поддержки. Приложения для браузера в целом занимают меньше места; Внедрение и поддержка более двух десятков пользователей может потребовать значительных ресурсов поддержки.

Год или два назад я видел таблицу, на которой было что-то вроде:

Качество пользовательского интерфейса - Рабочий стол
Детализация проверки - Рабочий стол
Отзывчивость - Рабочий стол
Принятие пользователем - Рабочий стол
и т. Д. - Рабочий стол
и т. Д. - Рабочий стол
Установка и поддержка - Браузер
и браузер выигрывает.

Answer 7

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

Когда я смотрю на окно своего браузера, когда я набираю его, оно имеет высоту, вероятно, 12 дюймов, но окно, в котором я печатаю, составляет всего 3 дюйма. И из этих 12 дюймов в целом, возможно, два полных дюйма занимают панели инструментов браузера, вкладки, ряды закладок и строка состояния, ни одно из которых не имеет ничего общего с веб-приложением, с которым я взаимодействую. Там много потерянного пространства (например, окно редактирования не такое широкое, как окно в целом), пространство, заполненное ненужными мне вещами и т. Д. Некоторые из наиболее фундаментальных элементов управления (кнопка «Назад», I ' смотрю на тебя) может полностью сломать плохо спроектированные веб-приложения.

Не говоря уже о том, что если я наберу достаточно длинный ответ, я получу два набора полос прокрутки. stackoverflow.com частично решает эту проблему, давая мне изменяемый размер текстовой области, но мне все равно приходится взаимодействовать с внутренней полосой прокрутки для прокрутки редактируемого текста, а затем прокручивать все окно вверх или вниз, чтобы получить доступ к элементам управления приложения вверху или внизу окна редактирования.

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

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

Answer 8

Мое решение это

1. Приложения веб-сайтов, очевидно, работают в браузерах
2. Сетевые приложения, которым не требуется доступ к клиентскому компьютеру, запускаются браузером
3. Любое приложение, к которому одновременно должен обращаться более чем клиент, просматривает браузер
4. Приложения, которые будут использоваться для каждого клиента без очевидной необходимости в сети, будут работать с графическим интерфейсом, и это может включать в себя программное обеспечение, которое требует большой безопасности при его использовании (хотя такая же безопасность может быть применена и для браузера на основе).

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

Во всех решениях действительно ваше! Как Java-разработчик, использующий JavaFX и Swing, может решить мою проблему с этой проблемой.

Answer 9

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

Веб-интерфейс будет более переносимым, поскольку не привязывает разработку к одной платформе, и если приложение работает в удаленном режиме, его проще обновить и протестировать все (кроме GUI ...) на согласованная среда (ваш сервер). Но вы должны понимать, что, несмотря на то, что все это замечательно и действительно потрясающе, оно также имеет ряд серьезных недостатков. Вы должны не только отлаживать приложение под всеми целевыми системами, но и под каждым отдельным браузером, работающим на каждой отдельной целевой системе ... и не забывайте, что многие версии одного и того же браузера могут сосуществовать в течение некоторого времени, и что настройки каждого браузера вероятно, будут запущены разные наборы (и версии) популярных плагинов, что заставляет его вести себя по-разному, и, вероятно, настройки сети будут настраиваться пользователями. Если приложение находится в удаленном режиме, оно открывает много интересных новых проблем, начиная с другого интернет-провайдера, который может вызвать различные проблемы в середине или простои служб из-за сетевых проблем вашего сервера, компьютеров пользователя или где-то посередине. Удаленное приложение не подходит для всех пользователей в странах, где сетевые услуги имеют низкое качество или не имеют разумной цены; То же самое относится и к вам: вы можете начать предоставлять такую ​​услугу, только если в вашей стране пропускная способность разумна и по разумной цене. И если приложение должно делать что-то нетривиальное в системе пользователя, вы все равно будете обречены на создание большого количества зависимого от платформы кода.

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

Answer 10

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

Я все за это ...