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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

с точки зрения

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

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

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

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

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

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

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

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

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

IMNSHO

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

Если ваша основная особенность не является самим интерфейсом (« Если это основная бизнес-функция – сделайте это самостоятельно, что бы ни случилось », см. Раздел «Защита не-изобретенного синтаксиса от Joel on Software» ), я считаю, что браузер будет иметь возможность выполнять визуализацию и обработку формы лучше, чем создавать графический интерфейс с нуля. Кроме того, не говоря уже о том, что для кодирования графического интерфейса потребуется гораздо больше времени, а не генерировать HTML-формы и обрабатывать их после того, как они будут загружены браузером.

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

То, что действительно происходит, заключается в том, развивается ли вы:

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

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

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

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

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

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

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

Я видел столик год-два назад, который показал что-то вроде:

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

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

Есть обратные ссылки на веб-приложение, например ..

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

Вы не можете легко сопоставить клавишу 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 (возможно, какая-то проверка на стороне клиента, когда пользователь нажимает «Отправить», чтобы предупредить их о любых ошибках ввода?)

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

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

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

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

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

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

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

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