背景
10年前、2GISがまだ小さかったとき、2GISのマップは独自のシステム「DGPP」で作成されました。 彼らが言うように、それはシンプルで理解しやすいツールでした。
毎年、その中の機能はより多くなりました。 より多くのオブジェクトを作成し、非常に迅速に作成する必要がありました。 10年間の「洗練」の後、DGPPは次のようになりました。
乾燥残渣中：
-古いテクノロジー。
-その神聖な意味が何世紀にもわたって失われたアーティファクト。
-操作が難しいコントロールの山。
-新機能の導入に関する問題。
完成度に制限はありませんが、さらに製品を「改善」および「変更」することは不可能でした。 新しいシステムを作成する必要がありました。
準備する
信念体系
最初は、イデオロギーについて考えました。 何が良いのか、何が悪なのか、どの原則がこの決定を決定するのかを理解する必要がありましたか？
工業用マップのレンダリングは簡単なプロセスではなく、独自の微妙な点があります。
- マップはいくつかの段階で作成されます。
まず、衛星画像から描画され、その後地上で検証されます。 たとえば、写真から建物を描くことができますが、地上で和解した後にのみ階数を指定できます。 - オブジェクトクラスを作成するときのシーケンスに従う。
川、地域、家、通りなどは、特定の順序で描かれるべきです。 たとえば、道路は家を横断できますが、川を横断することはできません。 - 都市の非定型デバイス。
たとえば、複雑な水路の都市の存在から、道路の交差点の特徴や建物の特定の構造から。
顧客はタスクの複雑さを理解しており、「直感的なインターフェイス」の作成について誰も話しませんでした。 ただし、特定の各段階内で、インターフェイスは透明になり、可能な限りユーザーが進むべきパスをユーザーに促す必要があります。
ノリノセ
マップの作成は費用のかかるプロセスです。 数十万のアクション地図製作者で構成されています。 トランザクションが数回クリックされるだけで、最終的に企業にとっては、この変更に多大な費用がかかる可能性があります。
したがって、最初の原則は「害を及ぼさない」ことでした。 美しい製品を作り、前の製品よりも基本的なアクションを実行するのに時間がかかることを理解するのは残念です。
コンテンツが最初に来る
マップ上のオブジェクトのジオメトリに加えて、製品には大量の関連データが含まれています。
たとえば、建設には、目的、住所（通り+番地）、建築材料、入り口と床の数、高さ、名前、および表示する必要のある2つの異なる属性があります。
これにより、2番目の原則が得られます。 地図のレンダリングに付随する属性とデータは、表示され、明確に区別され、失われないようにする必要があります。
時間節約
確かに、あなたの1人がサイトの異なるページに入力されたデータの損失を経験しています。 正確な住所、姓と名を書き、2番目の画面に移動し、[保存...]を押します...ラグ...データがすり減り、狂犬病、最初から始めます。
私たちの場合、失われたデータはただの悔しさではなく、会社の資金の無駄です。 システムがユーザーの作業を引き継ぐ必要があります。 デフォルトのデータを使用すると、あらゆる種類の自動化と事前計算がこれに役立ちます。
継承
DGPPは時代遅れですが、多くの利点がありました。 次のプロセス、応答性、ランダムエラーに対する保護など。 ユーザーは習慣を形成しており、その一部は作業を高速化します。 私たちにとって、これは第3の原則になりました。古いインターフェイスに前向きで便利で便利なものがある場合、これを保持する必要があります。 これにより、ユーザーの忠誠心が高まり、新製品に切り替える際の痛みが軽減されます。
拡張性
外部機能は、コンテンツに関連付けられた新しい機能を定期的に追加します。 内部製品の場合、これは常に要件を追加し、新しいデータを維持する必要があることを意味します。 この事実は、システムを開発する際にも考慮する必要があります。
シンプルさ
歴史的に、企業の開発者は、インターフェイスを研ぐよりも新しい機能を作成することに重点を置いてきました。 そして、実装が問題になると、ビジュアルコンポーネントよりもよくできたロジックが優先されます。 したがって、見栄えは良いが、シンプルなデザインの方が生産に入る可能性が高くなります。
これらの原則により、物議を醸す問題についてコンセンサスを得て、最も適切なアイデアを決定することができました。
ブロックへの分解
私たちはルールに同意しました。開発を始める時です。 より正確には、分解あり。
まず、マップをレンダリングするプロセスを調べました。 幸いなことに、技術者はビジネスプロセスを詳細に、そして愛をもって説明してきました。 うまくいかなかった場合、その答えは前身のシステムまたはユーザーに直接送られました。
彼らはプロセスを書き留め、それらの中で一般的なアクションを選び出しました。 たとえば、アクションに関しては、家と道路を描くことは同じです。 オブジェクトを描画=>属性を入力=>保存。 このようなグループ化に基づいて、同じ目標を持つ機能ブロックを特定しました。
タスクが分解されると、すべてが単純になります。 機能に個別に優先順位を付けて解決します。
交差点
はい、交差点の作成は別の機能です。 より正確には、交差点を作成および編集するプロセスの視覚化。
サブジェクト領域に少し飛び込みます。 交差点があります-これが道路リンクの交差点です。
交差点には、禁止されている機動に関する情報があります。 たとえば、ある道路から別の道路に曲がることはできません。または、中庭の入り口に障壁があります。
タスク調査（要件の収集）
まず、既存のソリューションに目を向けました。
属性情報を入力するために、ウィンドウが外れました。
ユーザーはデータを入力し、「OK」をクリックしました。 肯定的な点：ウィンドウ内のデータは事前に入力されています。
たとえば、「level」フィールドには、交差点に接続されているリンクのレベルの値が記録されています。 禁止されている機動のリストは、同じ原則によって作成されました。 ほとんどの場合、[保存]をクリックするだけです。 さらに、各操作を禁止するには、1回のクリックが必要でした。明確にするために、操作が強調表示されました。
しかし、操作の識別マークとしてのリンクIDがあまり有益ではないことは印象的でした。 「輸送モード」（禁止が適用される輸送モードを意味する）の列も自信を刺激しませんでした。
2つの理由があります。 まず、いくつかのタイプのトランスポートがテーブルに表示されません。 第二に、特定の種類の交通機関の交通を禁止するには、各操縦に3回のクリックが必要でした。 禁止スケジュールの選択にも3回以上のクリックが必要でした。
顧客やユーザーとのコミュニケーションの後、情報価値のないIDの仮説が確認されました。 ユーザーは、IDよりもマップ上の操作のハイライトをよく見ます。 ただし、チェックマーク付きの禁止事項の配置は便利であると考えられます。 また、演習のスケジュールはめったに導入されず、重要なケースではないこともわかりました。
その後、いくつかのアイデアがありました。
- 機動の配置方法を維持する必要があり、 ユーザーはそれに慣れています。 ただし、より視覚的にする価値があります。
- 操縦の禁止の配置を自動化することは不可能です。なぜなら、 これを確実に100％実行できる兆候はありません。 したがって、すべての操作をデフォルトで有効にすることは理にかなっています。 これが最も一般的なケースです。
- リンクと属性を同時に表示する必要があります。 そのため、属性がマップとオーバーラップしないようにします。
- 操作の識別マークとしてのリンクIDは機能しません。 それを置き換えるものが必要です。 たとえば、通りの名前。
- オブジェクトを作成した場所で編集できるようにします。 地図に交差点を描く場合、必要なすべての禁止事項を同じ場所に配置できるのは理にかなっています。 マップで禁止された機動を編集するというアイデアがありました。
- 特定のタイプの輸送の禁止はあまり頻繁ではなく、顧客はアクションの数を減らすという問題を提起しません。 ただし、ピクトグラムを使用する場合、この要素をよりコンパクトで直感的にすることができます。 これにより、決定全体にポイントが追加され、ロイヤルティが向上します。
- 禁止スケジュール-ケースはまれであるだけでなく、アクションの多くの可変性も必要とします。 したがって、高速化を試みることは難しいだけでなく、お勧めできません。
これらの考えを念頭に置いて、私たちは先に進みました。
研究アナログ
そして、質問がありました：誰もが同様の問題を解決しようとしましたか？ そして、それは何から来たのですか？ 検索を始めました。
30を超える製品を調査した結果、2つのパターンが特定されました。
- 禁じられた機動をリスト形式で表示します（JOSM）。 テーブルビューよりも視覚的に見え、IDをストリート名に置き換えることは私たちの考えと一致していました。
- マップ上の禁止事項の視覚化。
しかし、もう少し進んで、これら2つのアプローチを組み合わせたいと考えました。 したがって、習慣を維持し、より視覚的で技術的なツールを提供したいと考えました。
最初のアイデア
次のステップは、お客様に私たちのアイデアをもたらすことです。
最も簡単で最速の方法は直接通信です。
会議では、アイデアのスケッチを描き、それらがどのように機能するかを説明し、すぐにフィードバックを受け取りました。 私たちのアイデアが似ているかどうかを理解するだけでなく、何が適切ではないのか、その背後にある実際の事例を見つけることが重要でした。
問題の解決策を統一的に把握するために、顧客から最大限の適用情報を取得しようとしました。
いくつかのダイアログの後、コンセプトは次のようになりました。
- 交差点の属性情報は、右側のパネルに表示されます。
- データの事前入力を保存します。
- （マップから、および属性のdocpanelを介して）操作を編集する2つの方法を残します。
- 属性の編集は、2行の要素のリストの形式で行われます。
- マップを介した編集は、ベクトルマップの上に描かれたアイコンを使用して行われます。 同時に、マップをスケーリングする機能は保持されます。
プロセス設計
全員が同意した後、プロセスの視覚化の最初のバージョンを作成しました。
実際、マップ内の操作を編集するためのコントロールは、交差点とその関連リンクに重ねられたラスターアイコンです。
アイコン間の距離は固定されており、スケールに依存しません。
同時に、マップの縮尺を変更することも可能です。
ソリューションが顧客に示された後、さらにいくつかのニュアンスが浮上しました。
- 2行の要素が使用されていたため、操作のリストは面倒でした。 また、その中の要素の数は多くなる可能性があるため、スクロールは必ずしも便利ではありません。
- リンクには常にストリート名が付いているとは限りません。 市内でも、多くの道路には名前がありません。 たとえば、あらゆる種類のクォーター内車道、公園の路地など。
- マップ内のコントロールが複雑な交差点でどのように動作するかは明確ではありませんでした。 リンクが鋭角で交差する場合、アイコンが互いに重なり合うことは今すぐ明らかでした。
そして、私たちはさらに考えに行きました。 新しいオプションはこれでした：
新しい視覚化では、交差点を構築する複雑なケースを考慮しました。 マップ上に同じタイプのオブジェクトが多数近くにある状況と同様に。 さらに、さまざまな縮尺で交差オプションを示しました。
その結果、次のことを可能にするソリューションが得られました。
- 最も一般的なケースではフィールドが自動的に入力されるため、 交差点をすばやく作成します 。 つまり、これを回避できる場合は、ユーザーにデータの入力を求めません。
- より視覚的な方法で禁止された機動を作成します。 道路標識の画像を含むピクトグラムはチェックボックスよりも理解しやすいため、リスト内の禁止事項の配置。 同様に、マップを介した操作の作成により、複雑なインターチェンジを使用する際のタスクが容易になります。
- 簡単に適応できます。 パネルの外観と位置が変更されたという事実にもかかわらず、その構造と入力データのシーケンスは保持されています。 さらに、リストに禁止を設定する機会を残しました。 これにより、ユーザーは新しいインターフェイスにすばやく慣れ、トレーニングの時間を節約できました。
- 収集されるデータの量を増やします。 属性パネルのブロック構造により、交差点に関する新しいデータを収集する必要がある場合、ブロックを簡単に拡張できます。
- ワンクリックで特定の種類の輸送を禁止します。
デザイン=>開発=> ???
ユーザーが満足しているので、開発者の時間です。 開発者がすべての段階でソリューションの作成に参加したことをすぐに言及する価値があります。
各コンセプトは、その実現可能性に関して開発者と議論されました。 最終的に提案されたソリューションは使いやすく、技術的に高度であり、交差点編集機能は製品の最初のリリースにとって重要でした。
しかし、その実装には時間がかかり、チームの力を遅らせることになります。 機能性と利便性のバランスを見つける必要があったため、タスクの詳細を決定しました。
操作はサイドバーからすばやく編集できます。 同時に、古いシステムの同様のソリューションよりも良く見えました。 マップから操作を編集する機能は便利に見えますが、ユーザーはそれを待たないため、最初のバージョンでない場合は動揺しません。
そして最後に
過酷なエンタープライズの世界では、グラフィカルインターフェイスは、「方法」や「理由」という質問よりも、「何を」という質問に答える可能性が高くなります。 ソリューションのシンプルさと利便性に十分な注意を払うことなく、どこでも機能的な問題を解決するシステムを見つけることができます。 しかし、本当に便利で、ユーザーの問題や習慣に従うだけで、本当に便利な製品を作成できます。
したがって、インターフェースに時間を費やし、便利なソリューションを探すことを恐れないでください。 ユーザーの時間、会社のお金、開発者の神経を本当に節約するクールな製品を作成します。 あなたの仕事は無駄になりません。