これは以前に尋ねられたことがあると思いますが、見つかりません。
スタンドアロンアプリケーションにブラウザベースのインターフェイスを使用することと、通常のGUIフレームワークを使用することの利点/制限は何ですか?
私は現在GUI用のwxPythonで実装されているPythonプログラムに取り組んでいます。アプリケーションは単にユーザー入力フォームとダイアログです。ウィジェットがあるため、PyQtへの移行を検討しています(将来の拡張)、それから私はおそらくブラウザを使用して同じことの多くを行うことができることに気づきました。
アプリケーションは現在インターネットアクセスを必要としませんが、将来的には可能性があります。ブラウザベースの場合、Webフレームワークに Karrigell を使用することを考えていました。
Edit明確にするために、現時点では、アプリケーションはWebベースではなく、ブラウザベースになります。すべての情報はクライアントコンピューターにローカルに保存されます。サーバー呼び出しを行う必要はなく、インターネットアクセスも必要ありません(ただし、後で来る可能性があります)。これは、wxPython/PyQtGUIではなく単にブラウザーGUIになります。それが理にかなっていることを願っています。
開発/デプロイメント/メンテナンスの労力/コストが等しいと少し考えて、アプリケーションユーザーの観点から見てみましょう。
ユーザーがより便利だと思うUIはどれですか?
の面では
「役に立つ」は主観的なものだと理解しています。私は個人的に(開発者ではなくユーザーとして)Webインターフェイスを使用することはありません。 I hateそれら。
ブラウザベースのアプリとして開発する意味がないアプリケーションがいくつかあります。
開発の観点から
ただひどい、議論のないスタンドアロンのGUIアプリケーションはたくさんあります。マルチプラットフォームGUIの開発/展開、および保守は簡単ではありません。
優れたユーザーインターフェイスの開発は困難です。
現実には、私は過去10年間、主にWebベースのアプリケーションを開発して生計を立ててきました。なぜなら、それらは開発が速く、展開が簡単で、必要に応じて人々が使用できる十分なユーティリティを提供するからです。
代替手段が与えられた場合、ほとんどのユーザーがWebインターフェイスを使用するとは思わない。
IMNSHO
ブラウザベースの明らかな利点:
そしてGUIベースの場合:
この質問 に関する私のコメントも参照してください:
クロスプラットフォームのGUIは古くからの問題です。 Qt、GTK、wxWindows、Java AWT、Java Swing、XUL-これらはすべて同じ問題に悩まされています:結果のGUIはネイティブに見えませんさらに悪いことに、すべてのプラットフォームのルックアンドフィールfeelはわずかに異なるため、どのようにしてすべてのプラットフォームでネイティブに見えるツールキットを入手できたとしてもプラットフォームでは、各プラットフォームでネイティブであると感じるように、何らかの方法でアプリをコーディングする必要があります。
それは決定に帰着します:開発の労力を最小限に抑え、各プラットフォームで見た目も使い心地も良くないGUIを使用したいですか、それともユーザーエクスペリエンスを最大化したいですか? 2番目のオプションを選択する場合は、プラットフォームごとに共通のバックエンドとカスタムUIを開発する必要があります。 [編集:またはWebアプリケーションを使用します。]
私が今持っていたもう1つの考えは、アプリケーションが操作するデータの種類とその保存場所、およびユーザーがそれについてどのように感じるかについても考慮する必要があるということです。 Facebookのプロフィールデータをウェブサーバーに保存しても大丈夫ですが、MYOB)のような財務アプリケーションを作成していて、個人の財務情報をすべて自分のサーバー。それを機能させることはできるかもしれませんが、必要なセキュリティを実装し、ユーザーベースにデータが安全であることを保証するには、多大な労力が必要になります。そのような状況では、全体的な労力が少ないと判断する可能性があります。ネイティブGUIアプリを使用します。
ユーザー入力フォームを使用した単純なデータ入力に関しては、ブラウザーベースのソリューションを使用する方がおそらく開発がより簡単で迅速になると思います。
コア機能がインターフェイス自体でない限り( "コアビジネス機能の場合-何があっても自分で実行してください。"、 In Defense of Not-Invented-Here Syndrome from Joel on Software )では、ブラウザがフォームのレンダリングと処理をより適切に実行できるようになると思いますGUIを最初から開発するよりも。また、言うまでもなく、ブラウザによってPOSTされた後にHTMLフォームを生成して処理するのとは対照的に、GUIのコーディングにははるかに長い時間がかかります。
過去に見つけたのは、友人から調査結果を入力するための申請書を書くように頼まれたことです。最初は、Javaアプレットを作成して、すべてのラジオボックスで調査自体を表示していましたが、フォームを生成する単純なHTTPサーバーを作成したほうがよいと思いました。それらを処理します。
本当に重要なのは、開発しているかどうかです。
データ入力アプリケーションを作成する場合は、ユーザーインターフェイスをブラウザーに任せて、コア機能に集中します。
ブラウザベースのインターフェイスの利点:
GUIベースのインターフェースの利点:
ほとんどの場合、切り札の問題が展開可能性とサポート可能性であるというかなり良い証拠があります。ブラウザアプリは一般的にオーバーヘッドが低くなります。数十人を超えるユーザーを実装およびサポートすると、かなりのサポートリソースを消費することになります。
1、2年前に、次のようなテーブルを見ました。
UI品質-デスクトップ
検証の粒度-デスクトップ
応答性-デスクトップ
ユーザーの受け入れ-デスクトップ
等。 -デスクトップ
等。 -デスクトップ
インストールとサポート-ブラウザ
そしてブラウザが勝ちます。
このタスク(フォームベースのテキスト入力)には、ブラウザーが最適です。デスクトップアプリであることがあなたに与えるものは何も必要ありません(スピード、柔軟性)
次のようなWebアプリケーションであることには欠点があります。
これはWebページです。(簡単に)できないことがあります
Ctrl + Jキーを簡単にマップして何かを行うことはできません。例:Googleスプレッドシートは、キーボードショートカットをマッピングしようとし、ほとんどの場合ほとんど動作しますが、ブラウザのデフォルトのショートカット処理が引き継ぐ場合があります。
Growlアラート(OS X通知フレームワーク)を作成することはできません。ファイルシステムにアクセスできません。オフライン中にアクセスを許可することは困難です。
JavascriptはCPUに非常に負荷がかかります。
Googleスプレッドシートドキュメントのサイズを変更するか、Digg(非常にJavaScriptの重いサイト)にページをロードしてみてください-ブラウザのCPU使用率はしばらくの間100%になります。ネイティブデスクトップアプリケーションで同じことを行うのは簡単です。
アップグレードを実行すると、すべてのユーザーにforceが適用されます。デスクトップアプリケーションでは、アップグレードしないことを選択できます。 。たとえば、私はGoogle Readerのアップグレードの1つが気に入らなかったが、行き詰まっていた。 NetNewsWire(デスクトップアプリケーション)を使用すると、最新バージョンの変更が気に入らない場合は、これを簡単に使い続けることができます(または試してダウングレードできます)
あなたのウェブサーバーはいつでもアクセス可能でなければなりません
サーバーが消えた場合、ユーザーは頼りになりません。アプリケーションはなくなりました。 10分間ダウンすると、使用できなくなります。
あなたのアプリケーションでは、それが何であるかはよくわかりませんが、上記のどれも問題になるとは思われません。
"これはWebページです":フォームとダイアログボックスは、HTMLとJavaScriptで(またはサーバーサイドスクリプトを使用して、たとえば<?php if($_POST["email"] ==""){echo("Are you sure you want to continue?); ?>
)
"JavascriptはCPUに非常に負荷がかかります":アプリケーションでJavascriptが必要になるようには思えません(ユーザーがクライアント側で入力を検証する場合があります) [送信]をクリックして、入力エラーについて警告しますか?)
"強制アップグレード":ユーザーが古い方法でデータを入力することを望まないので、これが望ましいと思います。
「サーバーにアクセスできる必要があります」:問題になる可能性がありますが、大きなものになるとは思いません。保存したいとします。中央データベース内のすべてのユーザーデータ、この問題はとにかく避けられなくなります-Webおよびデータベースサーバーを実行し続けることは、データベース(GUIが接続するため)だけよりもはるかに多くの作業ではありません
また、他の人が投稿したメリットも得られます。一度開発すれば、正常なブラウザを実行できるすべてのオペレーティングシステムで同じように実行されます。
WebベースのUIについて私が嫌うことの1つは、それらが別のウィンドウ内で実行されるという事実です。つまり、アプリケーションとは関係のないコントロール(おそらく数十個)があります。使いやすさの観点から、これは混乱を招く可能性がありますが、私たちのほとんどは余分なものを「調整」することで適応しています。
これを入力するときにブラウザウィンドウを見ると、ウィンドウの高さはおそらく12インチですが、入力するウィンドウの高さはおそらく3インチです。そして、全体の12インチのうち、おそらく2インチは、ブラウザーのツールバー、タブ、ブックマークの行、およびステータスバーで占められていますが、これらはいずれも、私が操作しているWebアプリとは関係ありません。無駄なスペースがたくさんあります(たとえば、編集ウィンドウはウィンドウ全体ほど広くありません)、不要なものでいっぱいのスペースなどです。最も基本的なコントロールのいくつか(戻るボタン、私はmあなたを見ている)は、設計が不十分なWebアプリケーションを完全に破壊する可能性があります。
十分に長い応答を入力すると、2セットのスクロールバーが表示されることは言うまでもありません。 stackoverflow.comは、サイズ変更可能なテキスト領域を提供することでこれに部分的に対処していますが、編集中のテキストをスクロールするために内側のスクロールバーを操作してから、ウィンドウ全体を上下にスクロールして、上部または下部のアプリコントロールにアクセスする必要があります。編集ウィンドウの。
全体として、Webベースのアプリケーションはデスクトップアプリケーションの使いやすさと比較することはできません。私にとって、質問は単に「ユーザビリティにもっと興味があるのか、それとも(開発者としての)生活を楽にすることに興味があるのか」ということです。
使いやすさが必要な場合は、デスクトップアプリケーションを使用してください。デプロイとサポートに関心がある場合は、Webアプリを検討する必要がありますが、実行時にネット経由で更新できるアプリを作成するなど、デスクトップアプリをデプロイする簡単な方法はまだたくさんあります。
すべてに長所と短所がありますが、次のとおりです。
ローカルホスト、イントラネット、またはインターネット上で、使いやすく、応答性が高く、HTML/JS/CSSの制限によってユーザーインターフェイスが厳密に制限されていない、単一のブラウザベースのアプリケーションをまだ使用していません。
注:Flash/JavaベースのUIは例外です(ただし、いくつかの点でさらに悪化しており、ここで実際に話していることではないと思います)。
私の解決策はこれです
これは難しい方法で学んだことです。これの主な理由の1つは、ブラウザベースのアプリのインストールと管理がGUIベースよりもはるかに簡単であると顧客が感じていることです。
すべての決定は本当にあなた次第です!。 Java JavaFXとSwingを使用する開発者は、この問題に関する私の問題を解決できます。
ブラウザベースのUIの概念はここにとどまると思います。 Web自体ほどポータル性のあるものはなく、まともなjavascriptライブラリの境界内にとどまっている限り、レンダリングはほぼ同じです。さらに、レンダリングは頭痛の種ではないため、ビジネスロジック自体の開発にもっと関心を持つことができます。
私はそれですべてです...
リッチクライアントGUIは、一般に、ユーザーが扱い慣れているルックアンドフィールとより高速で統合されます。これは、ベルやホイッスルを意味するだけでなく、キーボードショートカットなどの多くの時間を節約する機能も意味します。
WebベースのUIは、開発を単一のプラットフォームにバインドしないため、より移植性が高くなります。アプリケーションがリモートで実行されている場合は、一貫性のある環境ですべて(GUIを除く...)を更新およびテストする方が簡単です(あなたのサーバー)。しかし、そのすべてが素晴らしく、本当に画期的である一方で、いくつかの重大な欠点も伴うことを理解する必要があります。すべてのターゲットシステムでアプリケーションをデバッグするだけでなく、各単一のターゲットシステムで実行されている各単一のブラウザでもデバッグする必要があります...同じブラウザの多くのバージョンがしばらくの間共存する可能性があり、各ブラウザの設定を忘れないでくださいおそらく、人気のあるプラグインのさまざまなセット(およびバージョン)を実行しているため、動作が異なり、ネットワーク設定はユーザーによってカスタマイズされます。アプリケーションがリモートにある場合、さまざまなISPから始まり、途中でさまざまな問題をドロップしたり、サーバー、ユーザーのマシン、または中間のどこかでネットワークの問題が原因でサービスがダウンタイムしたりするなど、多くの興味深い新しい問題が発生します。リモートアプリケーションは、ネットワークサービスの品質が低い、または手頃な価格ではない国のすべてのユーザーにとってオプションではありません。同じことがあなたにも当てはまります。あなたの国で帯域幅が合理的で手頃な価格である場合にのみ、そのようなサービスの提供を開始できます。そして、アプリケーションがユーザーのシステム上で重要なことをしなければならない場合、とにかくプラットフォームに依存するコードをたくさん作成することはおそらく運命にあるでしょう。
結論として、今日、2つのソリューションのいずれにも長所と短所があります。リッチクライアントモデルの下で実際に開発する必要のあるアプリケーションもあれば、Webベースのパラダイムの下で実際に開発する必要のあるアプリケーションもあります。両方のオプションがあるのは良いことです。開発/展開/サポート戦略に最適な方法を明確に理解することが重要です。さらに、どちらか一方をあたかもそれであるかのように追いかけるのはばかげています。瞬間の流行に続く決定的な銀の弾丸です。
ブラウザはインターネットでどこからでもアクセスでき、サーバーにデプロイします。デスクトップアプリは自分のコンピューターにデプロイする必要があり、同じOSや同じバージョンであっても、各コンピューターには何らかの形で独自の独自性があります。これはあなたに多くの面倒をもたらす可能性があります。 Webにアクセスします。