私の妻は薬剤師です。 ライフバゲッジ-2つのエンティティ（高等教育を含む）と男性プログラマー。 2番目は、コンピューターに関する非識字のアドバイスに対して一般に保険がかけられていることを示唆しています。 そして最も重要なこと-何か明確でないことがあれば、常に尋ねて徹底的な答えを得る機会があります。 しかし、問題は「理解不能」が悪いことの兆候ではないという事実にあります（少なくとも常にではありません）。 これは絶対に正常です。 理解できない人は、説明を得る機会によって単にサポートされなければなりません。 通常のデスクトップアプリケーションについて話をする場合、マニュアルの対応するセクションへのヒントまたはクイックアクセスは、このような機会を提供する非常に普通の方法です。 そして、夫プログラマはこれらの方法の1つにすぎず、比較的普遍的です:)
これまでのところ、事実はありません。上記は小さな叙情的な紹介でした。 私は別のつまずきのブロックについて話したかった。
悪が隠れています...ポイント。 悪が隠れています！ 自明性のためにすべてのアクションがユーザーに理解可能であり、結果が期待される結果を満たしていない場合、これは実行されたアクションの内容（実装の本質）が、独自のビュー（つまり、インターフェイス）によって形成されたユーザーの期待を満たしていないことを意味します。 なぜこれが起こるのですか？ 最初に、私は人生から新鮮な例を説明します：
専門的な活動では、妻は主に2つの目的でコンピューターを使用します（現在、業界固有の特殊なソフトウェアツールを考慮していませんが、一般的なツールについてのみ説明しています）。
- 電子通信（電子メール）を使用する
- インターネットで情報を検索して読む
最初の点では、すべてが整然としています。 彼女は自分の行動の本質を完全に理解しており、他のオフィスモンキーのようにメモリ内の固定画像のボタンを押すように訓練されていないため、さまざまなメールクライアントを自由に使用できます。 些細なこと？ おそらく。 しかし、あきらめないでください-読んでください、そして、私はあなたにその重要性の程度を伝えることができることを望みます。
パラグラフ2に関しては、自宅（つまりインターネットにアクセスできる場所）で、そして主に職場（オフラインで「ロシア語」で話す）で読書に必要な記事の検索に携わっているという状況です。 彼女が必要とする情報の検索では、かなりうまくいっているようです。 しかし、XとYが同じ活性物質の組成で使用するために異なる適応症を持っている理由をクライアントが発見したときに、明日必要になる記事があります。 彼女の観点から、記事で何をする必要がありますか？ 彼女を救ってください。 また、ユーザーの行動の非合理性を非難することは困難です。 そして、保存されたページをUSBフラッシュドライブに書き換え、薬局に持ち込み、開きます...写真はどこにありますか？ 写真はどこに行きましたか？ なんてf ***でも、彼のこのLinuxは、彼に写真のないページを救ってくれました！ （はい、私のLinuxはすべての問題の古典的な犯人です:)
彼女は、htmlコンテンツを含むファイルをUSBフラッシュドライブに転送しただけで、画像が個別に保存されている特定のディレクトリが必要であることをまったく知らなかったと推測するのは簡単です。 そして、彼女は再び間違った行動のせいにされることはできません。 あなたの質問に答えてください-彼女は何を保持しましたか？ 答えはページです。 ファイルではなく、HTMLではありません。 すべてのコンテンツを含むページ。 つまり 正確に1つの（！）エンティティ。 それでは、追加のディレクトリを書き換える必要はどこから来たのでしょうか？ 論理的で直感的ですか？ 私の意見では、これはまったくのナンセンスです。 ユーザーが知る必要のないものをユーザーから隠しました。 称賛に値する願望。 しかし、実装が悪いと、実際にはユーザーのトリック（！）につながります。 彼は望ましくない結果を回避するわずかな機会を与えることなく、誤解されて黙ってそれを行った。
メールに戻ります。 ここでさまざまなツールを使用しても問題がないのはなぜですか？ それらのそれぞれで作業するとき、それは常に、手紙、宛先、フォルダなどのような応用概念の分野に留まるからです。 この場合、アプリケーション領域を超えることなく、ファイルシステム内のファイルまたはディレクトリの存在を疑わないすべての権利があります。
保存されたページの場合、ユーザーとして、彼女はアプリケーション領域の概念（サイト、ページ、検索エンジンクエリなど）からファイルおよびディレクトリレベルに切り替えることを余儀なくされました。 そして、彼女はこのレベルが悪化することを知っていたので、彼女に彼に対処することができませんでした。 そして何よりも、システム（ブラウザー+ OS）によって提示されるこの遷移のロジック（明確な対応「ページ->ファイル」として認識される）が完全に異なることが判明したためです。
少なくとも誰かがこのナンセンスを修正するために少なくとも一度は何かをしたことを神に感謝します。 そして、この試みはMHTMLと呼ばれていました。 しかし、結果は実際には達成されていません。 互換性のために、両方の脚に足が不自由です。
Firefoxについては、FirefoxのMHTMLの該当するセクションを参照してください。
Operaには、保存時に適切なオプションがあります。 ただし、オペラにmhtml形式で保存する機能がある場合でも、保存オプションのリストは次のようになります。
-HTMLファイル
-画像付きのHTMLファイル
-Webアーカイブ（単一ファイル）
-テキストファイル
また、一般的に、完璧の限界からはほど遠い。 これはすでに「理解できない」というカテゴリーにずっと近いものです。 しかし、まだやるべきことがあります。
前述からいくつかの結論があります。
- ユーザビリティの観点から見たソフトウェアシステムの品質の重要な指標の1つは、アプリケーション領域の境界がインターフェイスで観察される明瞭さです。 説明したページ保存の例と明確に対照的な良い例は、 Mozilla Firefoxの ScrapBook拡張機能です。 既に表明されているもう1つの例は、MUA（メールユーザーエージェント）です。
- システムが何らかの形でアプリケーション領域から他の情報モデル（ファイルシステムモデルなど）またはその逆への移行を含む場合、この移行はアーキテクトおよび設計者が特別に注意して検討する必要があります。
批判するのは簡単だと思いますが、このワークショップの同僚の皆さん、この小さなメモで同様の設計上の決定を行わないように警告したいと思います。