今すぐ登録サーバー監視の再設計:設定アラートサーバ監視ツールは、アラート設定するためのインタフェースを必要とします。これらのツールの中でどれくらいが先行的と言えるでしょうか?アラートは、監視サーバーで不可欠な一部であり、トライアルを成功させている顧客はいくつかのアラートを設定する傾向があります。当社のお客様であるPreactから収集された分析データーがこのことを証明しています:当社がアラート設定のUIを再設計するためにちょうど2ヶ月費やしてきた理由はここにあります。この再設計を成功させるためには、ユーザーから多くのフィードバックと大量のデータが必要になります。幸いなことに、受動的および能動的プロセスを通じて、当社は毎日のフィードバックを収集しています。サポートチケットにより、ユーザーがで苦労していることを把握できます。ユーザビリティテストもユーザーが苦労している理由を示してくれます。顧客のアカウントを調査すれば、ユーザーが当社が提供するどの機能を使用しているか教えてくれます。Analytics分析により、お客様の成功のためにどのようなアクションが不可欠であるか、どこで摩擦を削減するか定義できます。Densityを毎日使用することにより、ユーザビリティの問題またどの機能が欠けているかなどが明確になります。この新しいUIは、多くの研究、思考、ユーザビリティテストと反復の成果と言えます。この記事の中で、私は、設計プロセスがアラートを設定するための先行的な方法につながったかを共有するつもりです。私は自分たちが解決した問題、どのようにまた何をユーザビリティテストを示したか、最初のコンセプトをいかに改善したかをご紹介します。待機とリピートの再考サポートチケット、ユーザビリティテストおよび顧客口座からのデータから、ユーザーが正しく待機とリピート時間を使用していなかったことが示されました。一部のユーザーは、図像学を知らなかったり、待機とリピート時間を理解していませんでした。アラート設定においては、待機時間が以下のような質問への回答を教えてくれます。:すぐに通知されるようにしますか、それとも自分が気にするまでその状態を数分間持続する必要がありますか?繰リピート時間は以下のような質問に答えてくれます。:問題を解決する前に一度だけかX分ごとに通知を受けたいですか?これらはアラート通知のスパムや疲労を軽減するために、これらはサーバ監視ソフトウェアの重要な部分です。これらの概念では、かなりのサーバ監視の経験を必要とします。このように、当社は、UIがこれらの概念を説明すべきであると結論付けました。当社は、アクションを起こせるようなキーワードで完全な文を使用しています。:これはいくつかの利点があります。必要なサーバ監視の知識が包括的に説明があり、理解することが簡単です。議論を呼ぶような図解はなし!データアラートなしなどエッジケースを説明するために多くのスペース利用可能です。待機とリピートテストでは、新たな待機とリピートのUIは直感的で使いやすいことが示されました。有用なテストは、比較的経験の浅いユーザでした。UIがデフォルトの待機で構成されていた場合には、より迅速にテストを完了したでだろうと提言しました。以下のスクリーンショットでは、左側は待機時間なし、右の2分の待機時間を示しています。:右側の設定の方がより多くを示していますが、それは良いデフォルトでしょうか?顧客データは、デフォルトの待機時間は、サーバ監視ソフトウェアにとって重要である警告スパムを減少させることを示しました。2分のデフォルトの待機時間として、新たにアラートの設定がされてます。秒を使用して待機時間を設定する機能が削除しました。60秒または120秒よりも90秒の待機時間を設定することが重要ではないことを示しました。そのため、このオプションを削除することにより、UIが迅速に理解できるようになりました。メトリックを簡単に見つけられます。様々なメトリックを監視することができますし、カスタムプラグインも書くことができます。3つのレベルのメトリックを見つけることは困難であることを示しました。古いUIは、一般的なドロップダウンを多用しました:これは、うまくいきましたが、それはユーザビリティの問題がありました:手動で3レベルのアイテムを見つけるために時間がかかります。ホバリングや誤ってクリックすると、容赦がありません。再起動する必要があります!ドロップダウンは、スペースがかなり多くを占めています。キーボードコントロールをサポートしていません。当社は1月に新たな「アコーディオンドロップダウン」を実装した最新の値のウィジェットをリリースしました。:メトリックを見つけることで、ほとんどの問題解決するので、これを使用することにしました。ユーザビリティテストは、すでにこのコンポーネントは使いやすく、強力であったことを示しました。当社はさらなるテストを通して、より良くできると知っていました。開発者は、キーボードによる操作を好むので、当社はそれらを改善するために多くの時間を費やしました。20以上の改善点につながりました。これらの改善点は、アラートを設定を迅速に作成を可能にするキーを押すことへに直感的に反応できるUIを開発しました。これは容易ではなかったので、私はユーザビリティテストが明らかにしてくれたポイントをご説明しましょう:可能な限り、ネイティブの要素を使用する。機能性をコピーし、ユーザーの期待にマッチできるように、ネイティブの要素から動作を拡張。スペースバーだけでなく、ダウン、アップ、入力や終了キーに反応する要素を選択し、それらを閉じる時に焦点を当てる。単一の相互作用を見逃さない:詳細キーボード管理を実行すれば、それが欠けている場合耳障りになります。フォーカスのスタイルは非常に重要であり、ブラウザ間で非常に矛盾しています。1つのキー入力は2つ以上よりも無限に使いやすい。検索は、経験豊富なユーザーにとっては強力なツールですが、経験の浅いはユーザが必ずしも正しく、それを使用していません。将来的に経験の浅いユーザーを助けようするために、ユーザーの期待にマッチしているかを確認するよう当社は検索の記録を開始します。当社はスペルミスや代替の命名の規則の許容範囲内に構築するAlgolia(当社のお客様)を探索します。半自動的にアラートを設定するのは、もう一つのオプションです。当社は、キーボード操作の結果に非常に満足しています。今では複数のアラートを設定するには、ほんの数秒ですみます。開発者は、自分のコンピュータと対話するために多くの時間を過ごす方法と一致するために、この機能に力を入れてきたことを喜んでいます。小さな画面上の利便性を向上サーバ監視インタフェースは、かなり多くの情報を示しています。4つのフィールドまたは5つのフィールドをを含むことができます。これらのフィールドが窮屈になると利便性が低下します。当社は、スペースを節約する必要がありました。1つのオプションは、スペースを大量に保存したテキストだけを残して、パディング、マージン、ボーダーとシャドーのようなすべてのビジュアルツールを削除することでした。:しかし、利便性の懸念がありました。ユーザーは、この設計に対処する方法を知っていますか?当社は、後ほどこれをテストすることになります。当社はお客様のアカウントを調べ、開発者に話を聞きました。そこで以下のようなことが明らかにしなりました:アラート設定が有効である場合、ユーザのエラーにより無効な場合は、それは重要ではありません。少なくとも一つのアクションが実行されると知っておくことが重要です。どのアクションが実行されるか知ることはあまり重要ではありません。待機、リピート、アクションの設定はは、単一のドロップダウンの内側に隠すことができます。検証エラーがある場合は、警告がオンになっていると確認することは重要ではありません。これらの調査結果を使用して、提案したすべてのデザインは、スペースを節約できました。それでも、アラート設定が複数行にラップすべきであるという事実に対処しなければなりませんでした。課題は、読みやすさを犠牲にすることなく、これを実行することでした。ラッピングを引き起こす可能性が最も低いアラート設定の一部は、メトリック、比較値によって構築される文です。ディスクの使用率が90%以上でした。devに関するディスク使用率が90%以上です。devの対象を文の最後に移動させることにより、ラッピングはより破壊的でなくなりました。それから以下のアラート設定とブレンドさせないように、新しい行の最初の要素をインデントしました:より多くのスペースを節約するために、ユーザーが最低限のアラートを設定することを表示しています。開発者に話をすると、彼らは初めに「比較メトリック値」という文を期待していることを示しました:ユーザーがメトリックを設定したら、アラート設定の残りの部分が表示されます。ユーザーはより多くの情報の検証エラーを見ることができました。ユーザーはこのプロセスを終了すると、検証エラーがオン/オフ切替えによって置換されています。これにより、スペースを節約できましたが、フィールドが次第に明らかにされるように簡単なアラート設定することができました。これにより、ユーザーは重要なことに集中することができます。ユーザビリティテストは、スペースの節約する。結局、当社は、テキストベースのアプローチに対して決定しました。このアプローチでは、ユーザーが対話のために必要な多くの要素を削除しました。これは、ドロップダウンまたはテキスト入力でしょうか?どこでその要素が起動し、終わっていますか?当社は、フォント、フォントの重みと色を使用して、これらの問題を解決しようとしました。伝統的なアプローチの方が、明らかにより使い易かったのでした:しかし、当社は、使いやすさを犠牲にしませんでした。これは、モニター·サーバーの非常に重要な部分であり、当社にとっても重要なのです。当社はユーザーテスト中に他に決定したことは、ロード及び保存された状態を追加することでした。当社はAJAX駆動型アプリケーションに精通している開発者はそれを見逃すことはないと想定しました。これは真実ではありませんでした。開発者は、変更点の保存の再保証を求めており、当社はロードし、保存された状態を追加しました。スペースを節約することは、解決するのが困難な問題でした。サーバ監視ソフトウェアにdevopsチームが運んだデータには柔軟性があり、非常に長くなる可能性があります。最終的に当社は、これを考え出すに多くの時間を費やしたことをうれしく思います。UIの全体的な使いやすさに大きな違いを生み出しました。通知のアクションを明確にする。)を通知するためにアラートを設定することは、直感的でないことを示しました。当社は2つの仮説を持っていました。仮説1は、古い受信者のアイコンが混乱を引き起こしたということでした。「ユーザー」または「人」を示し、統合を示してませんでした。当社が提案するそれぞれのアイコンは複数の方法で解釈されるので、代わりにテキストを使用することにしました。仮説2は、ユーザーとの統合の両方が含まれていたため、古いリストは直感的ではなかったということでした。開発者は、HipChatチャンネルと同じリスト内に直感的にユーザーを配置していませんか?それは、恐らくありません。最低限サポートチケットで2つの異なる統合が同じ名前を持っている場合に、1つの長いリストが問題を引き起こしたことを示しました。当社は、ワイヤーフレームが以下に示すように、見出しを複数のリストで示すことによって、これを解決します:当社は、このアプローチを実践し、ユーザーはそれを確認するためにテストするだろう。ミスを犯したことを認識する。開発中に当社は提案したアプローチに欠陥していることが疑いました。当社は、第二の再設計にコミットする前に証拠を求めていました。数週間後にユーザビリティテストからのフィードバックが十分な証拠となりました:特定のユーザを見つけることは困難でした。当社は、ユーザーが検索を使用すると想定していますが、多くは、スクロールすることを好んでいます。ユーザーは必ずしもスクロールできると気づきませでしたが、彼らはスクロールするとイライラしていました。リストはどのアクションが選択されるかを説明するには長すぎました。誤ってドロップダウンを閉じるのはあまりにも簡単でした。ユーザーは、アラートが開いたときに何が起こるかいう十分な属性を持っていませんでした。ユーザーがこれをテストすると、結果は圧倒的に陽性でした。私は、ユーザビリティテストは、当初の設計に欠陥があることが証明されたことをうれしく思います。どのくらいのサーバーの監視インタフェースに決して解決のされないこのような種類の問題がありますか?アラートを停止する。サポートチケットは、少数のユーザーがアラートを一時停止する方法を理解していなかったことを示しました。アラート通知スパムを防止するので、これはサーバ監視ツールの重要な特徴です。仮説1は、ユーザーは「休止」または「再生」のアラートを考えていなかったということでした。他の用語が必要でした:仮説2は、単一の再生/一時停止ボタンを使用により混乱したことということでした。Fiまたはカセットプレーヤーは、再生や停止用に別のボタンがあり、ボタンを押した時に、ダウンの状態になります。当社のインターフェイスでは、ボタンは再生アイコンに変更します。アラートがオンまたはオフであるため、この機能は、理想的にはトグルに適しています。このアプローチをテストするために、当社は、開発者にが新しいUIで見たすべてのものを記述するように依頼しました。オン、オフのような言葉を避けたタスクを設定します。この結果はかなり決定的でした。ユーザーはすぐにこの新しいアプローチを理解しました。使用できるサーバ監視ソフトウェアを開発のための新たな旅立ちへの重要な勝利です!オープンアラートを見つける。当社の経験で、ユーザーがアラート設定画面に行くための2つの理由があることを分かりました:一般的に一度だけ行う新しいアラートを追加します。一般的に唯一のオープンアラートに行うアラートを編集します。第1の理由には既に満足できましたが、、すでに第2の理由はそうでもありませんでした。解決策は単純に出てきました。それが開いた場合、アラート設定の開いたマーカーを追加します。アラート設定の左側にある赤いバーは、UIの残りの部分とうまくマッチします:簡単ですよね?実際にはそれほど簡単ではありません。驚くことに、サーバーの監視の経験を持つ開発者は赤いバーは、アラートがオープンしたことが示すと誰一人として知りませんでした。一部の人々は、それは、アラートが無効であった​​ことを意味すると考えて、他の人は、アラートがオフになったことを意味すると考えました。一つの可能な修正点は、通知センターのアイコンの付いたバーを交換することでした:しかし、これは正しいとは思いませんでした。アイコンは、通知センターへの通信に適していますが、このアラートがオープンの際にはそうではありません。数十億のユーザーの世界的なFacebookのユーザーは、通知アイコンがどのように動作するかを知っているので、当社はそのアプローチを取りました:オープン·アラートのアイコンは今はないアイコンとして同じスペースを占有するために、既存のユーザーは、最初は混乱しました。新規または経験の浅いユーザーはそのように混乱をしていませんでした。ユーザビリティテストで、既存のユーザーがすぐに適応していることが分かったので、すべての変更をしませんでした。サーバー監視のための使い勝手が大切です。当社は、新しいアラートの設定UIがサーバー監視におけるユーザビリティのための重要なステップであると考えます。世界中のdevopsチームが間単にサーバー監視をできための多くの高度な機能のの強固な基盤になります。図像、適切なデフォルト値、キーボードコントロールと全体的な使いやすさなどのいくつかの興味深い情報を提供するのと共に、私はこのポストで手堅い設計プロセスの価値を証明したいと考えています。研究、ユーザビリティテストとその繰り返し、総合的なデザインの一部です。これにより、インターフェイスが直感的で使いやすいものにできるのです。今すぐ15日間の無料トライアルを試してみましょう。登録が無事に完了しました!ご登録有難うございました日本語のツイッターのアカウントもフォローして下さい。@serverdensityjp。