web-dev-qa-db-ja.com

デスクトップアプリを模倣するWebサイトの開発。そのパラダイムと戦う方法は?

Webサイト/アプリがデスクトップアプリに似せて設計されている会社があるとします。

彼らは追加するのに苦労しています:

  • スプラッシュスクリーン
  • ドロップダウンメニュー
  • タブページ
  • コンテンツとともに下向きに成長しないページ。コンテキストはスクロール可能な領域内にあるため、ページはデスクトップアプリの1画面の制限に似ているかのように固定サイズになります。
  • モーダルウィンドウ、ポップアップなど。
  • ツリービュー
  • 機密性の低いコンテンツであっても、最初にログインしない限り、コンテンツへのアクセスは絶対にありません。スプラッシュ画面が消えると、ログイン画面が表示されます。
  • リンクなし-シミュレートされたボタンのみ。
  • 固定ページサイズ。
  • 別のタブでリンクを開くことができません
  • 直接印刷する印刷ボタン(印刷可能なページが表示されないため、ユーザーはブラウザの印刷コマンドを使用して印刷できません)
  • ブラウザが独自のアニメーションでコンテンツを示している場合でも、コンテンツをロードするためのプログレスバー
  • フォントと色は、Visual Basic、PowerBuilderなどで作成されたデスクトップアプリをアミュレートします。

すべてのアプリは、まるでVisualBasicで作成されたかのように見えます。

彼らはこの要素を拒否します:

  • パン粉
  • 古き良き下線付きリンク
  • 生成された/動的なナビゲーション、使用量ベースの提案
  • 複数のタブでリンクを開く機能
  • ページネーション
  • 印刷可能なページ
  • 特定のStackExchange質問へのリンクを誰かに送信するときのように、アイテムへのリンクを保存または共有できるURLを作成する機能。唯一のURLがメインのURLです。
  • 戻るボタン

これを実現するには、大量のJavaScriptコードが必要です。ビジネスとは関係がないが、そのボタンを非表示/表示したり、このリストボックスを更新したり、そのラベルをグレーアウトしたりする必要があるもののためのJavascriptおよびAjaxコードがたくさんあります。

あるパラダイムを別のパラダイムに強制することによって生成される複雑さは、コードのほとんどの行がデスクトップアプリの錯覚を維持することに専念していることを意味します。

この考え方を変えて、Webを受け入れ、デスクトップの模倣ではなく最新のWebアプリの作成を開始するための最良の方法は何ですか?

編集:

これらのサイトはイントラネットサイトです。ユーザーはこれらのアプリを嫌います。彼らは絶えず彼らについて泣き言を言います、しかし彼らは彼らの毎日の仕事をするためにそれらを使わなければなりません。これらのサイトは社内ソリューションであり、エンドユーザーはそれらを使用するしかありません。彼らは「捕らえられた聴衆」です。また、コストが高いため、代替は発生しません。しかし、少なくともその考え方が変更された場合、新しい開発はよりWebに似たものになるでしょう。

3

これは根本的な問題が適応の失敗であるように聞こえます。彼らにもそうすべきだと説得するのは難しいでしょう。私はあなたの最善の策は物事の組み合わせだと思います:

  1. 大企業(Google、Microsoftなど)のWebアプリケーションを指す
  2. デスクトップアプリとウェブアプリの違いと、同じように行動しようとすべきではない理由について、適切なリストを作成してください
  3. 他のすべてが失敗した場合は、小さなサンプルプログラムを作成します。たとえば、メモ帳の交換です。それを「ウェブ上のデスクトップ」スタイルにし、典型的なウェブアプリスタイルにします。人々がWebアプリスタイルを使用する可能性が高い理由を上司に示してください。
  4. 最後に、Webアプリが理由で彼らのやり方であることを彼らに示してください。それは複数の方法で安いです。開発にかかる時間が短くなり(HTTPがステートフルプロトコルであるかのように振る舞うのは時間の無駄です)、実行するリソースが少なくなり、顧客は販売しているものすべてにお金を払う可能性が高くなります。

#2のいくつかの出発点:

  • 顧客があなたのウェブアプリを離れたことを確実に知ることは物理的に不可能です。 HTTPはステートレスです。ポーリングはできますが、これは良くありません。
  • Webアプリはインストールする必要はありません。これは彼らの最大のセールスポイントの1つです。それを必要としないもののためにログインを要求することによってこれを台無しにしないでください。
  • ユーザーのブラウザウィンドウのサイズを確実に知ることは物理的に不可能です。これが、流れるようなレイアウトが非常に優れている理由です。ウィンドウサイズに合わせて動的に調整されます。それに比べて、デスクトップスタイルのアプローチは通常、固定レイアウトであり、正当な理由もなく、基本的に多くの無駄な画面スペースで立ち往生しています。
  • Webアプリでは、誰かがWindowsとは異なるOSを使用してWebサイトにアクセスしている可能性があります。きちんと見えるフェイルバックフォントがない限り、一般的なフォントを使用するように努め、独自のフォントに依存しないようにする必要があります。
  • HTTPはステートレスです。そうでないふりをすればするほど、それを「真」にするために必要なリソースが増えます。最高の状態では、基本的にはWebサイトへのリクエストごとに、最後のアクセス以降のすべてのリクエストからWebサイトへのすべてのデータを送信する必要があることを意味します。インターネットはより高速になり、サーバーはより強力になっていますが、見栄えの良い40マイル/ガロンの車が同じことをより少ない費用で行うのに、なぜ5マイル/ガロンのガスガズラーを80,000ドルで購入するのですか。
  • ユーザーは不便を嫌います。あなたのウェブサイトがステートフルで、何かを購入しようとしていて、誤って独自の戻るボタンではなくブラウザの戻るボタンを押した場合、最初からやり直す可能性があります。彼らは、製品をもう一度見つけて情報を入力し、実際に製品を購入するのではなく、他の場所にビジネスを移す可能性があります。
  • ユーザーがコンテンツへのURLを共有できるようにする必要があります。これがおそらく最も重要なポイントです。 「このURLにアクセスしてこれを確認する」または「このURLにアクセスして検索をクリックし、「スーパーベーコンクッカー」と入力して、3番目の結果であるスーパーベーコンクッカーXLをクリックして、それを見てください」....ユーザーがこれらのプロセスのどれを行うかを推測できますか決してしませんか?あなたは無料の広告が欲しいかどうか?
4
Earlz

あなたの質問のどこにもエンドユーザーについて言及していません。 「デザインAとデザインBのどちらを使用すべきか」などのすべての質問。ユーザーのニーズから始める必要があります。彼らは現在のデザインに満足して生産的ですか、それともこれらの変更を求めているのですか?

あなたが言及したことの多くは、成功したアプリと失敗したアプリの両方で使用できます。物事を変更しようとする前に、変更によってユーザーエクスペリエンスが向上することを確認してください。現在のスキームが彼らのために働くならば、なぜ変わるのですか? 「私考えるこれは私のユーザーのエクスペリエンスを改善するだろう」と考えているなら、それは間違った答えです。 「私知っているこれは私のユーザーのエクスペリエンスを向上させるだろう」と自信を持って言えるように、ほんの数人の実際のユーザーのほんの少しのユーザビリティ調査を行う必要があります。

チームの考え方を変えたい場合は、a)それはすべてユーザーに関するものであり、b)ユーザーは現在の設計によってサービスを受けていないことをチームに理解してもらいます。彼らがこれらの点のいずれかに同意しない場合、あなたは誰かを説得するのに苦労するでしょう。

3
Bryan Oakley

Web業界にはパラダイムシフトがあります。 SPA(シングルページアプリケーション)という用語は、大規模なプロジェクトや新興企業が日々素晴らしいWebアプリを作成し続けているため、日々ますます注目を集めています。

Webは絶えず急速に変化しているため、Webを採用することはあいまいな用語IMOです。古い同期。 HTMLを使用してページ全体をロードするrequest-responseは、asyncを介してjsonに置き換えられています。リクエスト。

現在、Webには、WebサイトとWebアプリの2種類の「モノ」があります。それぞれに独自の長所/短所があります。

programmers.SEはWebサイトです。 「Webサイト」の概念はQAネットワークですでに有用であるため、「アプリ」機能は必要ありません。

一方、Basecamp(オンラインプロジェクト管理ソフトウェア)はWebアプリです。すべてに個別のページ、全ページの読み込みなどを含む従来のWebサイトの方法は、プロジェクト管理ソフトウェアには実際には適合しません。代わりに、SPAモデルを使用すると、デスクトップアプリの機能を備えたWebブラウザーで使用できるソフトウェアが得られます。両方の長所。

問題は、いつものように、どのタイプ、WebサイトまたはWebアプリが製品に適合するかを選択する必要があることです。意思決定を行うときは、エンドユーザーエクスペリエンスを前面に出してください。

1
Hakan Deryal

デスクトップ形式に固執するのではなく、Web形式を利用した大企業による成功したWebアプリを紹介します。 Wordpressが頭に浮かぶ。Googleのビジネスアプリも。

0
System Down

もちろん、彼らはWebアプリがデスクトップアプリと同じように動作することを望んでいます。あなたは彼らにこれをすべて落とすように説得したいのですが、彼らはそれを機能させるために誰かにお金を払っても構わないと思っています。

今、彼らがあなたが同じ時間と同じ量のパフォーマンスで同じ価格でこれを開発することを期待しているなら、あなたは議論を持っています。彼らが彼らが支払うものに対して何を得るかを知っている限り、あなたは配達するべきです。私がソフトウェアにお金を払っていて、従業員が私の費用でこれらすべての余分なベルとホイッスルを望んでいた場合、私はプログラマーではなく不平を言う人になるでしょう。

あなたは私の友人の雇用保障を持っています。簡単だとは誰も言いませんでした。

0
JeffO