インタラクティブなオフィスマップの作成、パート2

昨年の夏、私たちはオフィスでのオリエンテーションプロセスを促進する試みについて話しました。その結果、会社の全従業員の居場所を確認できるマップが作成されました。 過去に新しいオフィスに移りました(それで、もっと良いことをしたかったので)、得られた経験を考慮してカードを再設計することにしました。



オフィスの地図を作成する必要があった理由を簡単に思い出してください。 当社は近年非常に急速に発展しており、従業員の数は絶えず増加しています(現在、300人を超えています)。 したがって、非常に多くの人々の中から必要な同僚を見つけることは困難である可能性があり、カードを使用すると、彼がオフィスのどこに座っているかを正確に簡単に見つけることができます。 多くの場合、逆の問題を解決する必要があります。人は視覚的に馴染みがあり、職場の場所はわかっていますが、名前もメールアドレスも思い出せません。 このデータは、マップ上の目的のテーブルをクリックして取得できます。



だった->なった



一般的に、マップは完全に再作成されました。 これは、開発者が長い間改善を望んでいた瞬間を改善したいという願望だけでなく、以下で説明するいくつかの技術的および法的側面によっても促進されました。



新しいエンジン


古いバージョンのマップはうまくスケーリングされ、原則として、移動後のマップの使用を妨げるものはありませんでした。 しかし、前回の記事へのコメントでは、Yandex.Maps APIのユーザー同意書は、以前のバージョンが機能することに基づいて、私たちのやり方で使用すべきではないと言われました。 Yandexのサポートはこの事実を確認しました。私たちは法を順守しているので、Yandexカードからオープンソースのリーフレットマップ表示エンジンに「移動」することが決定されました。



ちなみに、当時のLeaflet 0.4.3の現在のバージョンでは、必要な平面投影がなく、独自に実装する必要がありました。 現在のバージョン0.5では、この機能が存在しますが、座標の計算方法は少し異なります。 したがって、これまでのマップは、古いバージョンのエンジンで機能します。



前回の投稿へのコメントでは、グラフィックエンジンの他のいくつかのオプション(Planner 5Dまで)に注意を払うことも推奨されましたが、リーフレットはOpenLayersよりもわずかに余裕を持って勝ちました。



新しいマップの開発における主な問題は、AutoCADからデータベースへのテーブル(つまり、それらを示すデータ)のエクスポートでした。 一方では、これは必須ではありませんでした。マップ上にテーブルをすぐに配置できるからです。 しかし、一方で、テーブルは水平ではなく、どこかを向いている人は誰でも、手動で「回転」する必要がありますが、これはしたくありませんでした。



その結果、次のように機能するスキームが実装されました。



  1. AutoCADでは、テーブルは別のレイヤーにシフトされました。
  2. このレイヤーは、Lisp上の特別なスクリプト(インターネット上で見つけました。念のため、 ここにあります )によって処理され、独自の形式でデータをエクスポートしました。
  3. さらに、このデータはpythonのスクリプトに入力され(処理が簡単でした)、データベースへのSQL挿入スクリプトに変換されました。 同じ段階で、AutoCADの用語からLeafletの用語へのテーブルの対応の座標が再計算されました。


元々存在しなかったオブジェクト(会話など)を「仕上げる」必要がある場合、スキームを繰り返しました。AutoCADでオブジェクトを作成→別のレイヤーに移動→Lispスクリプトでデータをエクスポート→SQLに変換→データベースに挿入。



その結果、カードの外観が変更されました。



それは:







次のようになりました:





カードは会社のイントラネットポータルにあり、スケジュールに従ってデータが同期されます。



従業員の移転


以前のバージョンのマップでは、従業員を「移植」するために、マウスでマップ上のテーブルを物理的に移動する必要があり、特定のテーブルに従業員を再割り当てする可能性はありませんでした。 言い換えると、テーブルが所定の位置に残っている場合、状況は不可能であり、テーブルに座っている従業員のみが変化します。 その段階で、私たちにとって最も重要なことを見つけることだけが重要でした。人々がカードを必要とするか、それを使用するかということです。そのため、すべてをできるだけシンプルにしました。



原則として、これには何も問題はありませんが、テーブルをコピーできるのは開発者だけです。 マップの関連性を維持する使命が人事部門に割り当てられるように計画されていることを考えると、マップを操作するプロセスを可能な限り簡素化する必要がありました。同社は、場所から場所へ定期的に移動する300人の従業員を雇用しており、これらすべての移動を追跡することはすでに容易ではありません。



その結果、人事部門はマップ上のテーブルをクリックして、ドロップダウンリストからそのテーブルに座っている従業員を選択するだけです。







ユーザー役割の紹介


もう1つのイノベーションは、カードを操作する際のログインです。 以前のバージョンは静的であったため、認証を使用できませんでした。 カードの現在のバージョンは、サーバーアプリケーションに固有の機能(アクセス権、「移植」、「テーブルの検索」など)を実装できるMVCアプリケーションです。



認証には、組み込みのASP.NET NTLMメカニズムと、アプリケーション構成でグループを直接指定できる単純な自己記述型の役割システムを使用します。







さて、ところで、地図上に新しいテーブルを描く可能性はありません。 新しいオフィスには従業員よりも多くのテーブルがあり、新しい仕事の組織化はまだ計画されていないという事実のため、しばらくの間、この機能は需要がありません。 もちろん、それは必要なことですが、将来的には実装する予定です。



計画



ごく最近、同僚の間で調査を実施し、その結果、多数のアイデアを収集することができました。 たとえば、オフィス全体の写真を撮り、このパノラマ(Googleストリートビューなど)から抜け出してオフィスを仮想散歩できるようにするというオリジナルの提案がありましたが、これまでのところ、この革新の適切性はマップ開発者によって疑問視されています:)。



さらに、計画には以下が含まれます。





洗練度と必要性の度合いが異なる他のアイデアがあります:マップ上のレイヤー(たとえば、同じプリンターと他のオフィス機器)またはMS Exchangeとの統合(会話をクリックするとき、いつ、誰がビジーで、誰が自由になるか、クリックするときを表示する)カレンダーからスケジュールされた予定を表示する従業員)。 将来的には、おそらくこれを実装するでしょう。



デモ



前回の記事のコメントで、実際にカード自体を示すように頼まれました。 デモを作成することができましたが、これはまだ社内のプロジェクトであり、イントラネット上にあり、外部からアクセスできないため、パブリックバージョンの機能は制限されています。



UPDソースを投稿しました。



コメントで質問にお答えします。 いつもあなた、 MikeOzorninevgekonカード開発者



All Articles