アプリケーション標準 - Support and Troubleshooting

アプリケーション標準 Issue コンテンツ アプリケーション標準 設計原則 設計ガイダンス コーディング標準 設計原則 一貫性を保つ より少ない労力でより多くのことを行う 反復 処理 設計ガイダンス ホームページ ウィジェット アプリケーションバー アプリケーション モジュール Lists (リスト) リストの幅 列見出し フィールドサイズ 注意すべきアイテム Forms (フォーム) 全体的な設計プロセス パフォーマンス 一般的な組織 一般的なユーザビリティ セクション ラベル テキストフィールド 複数選択入力 チェックボックス 選択肢メニュー テキストエリアフィールド 関連リンク 関連リスト グローバルインタラクション アクションボタン リンク コンテキストアクション Syspopup ヒント アラートとメッセージ UI ページ コーディング標準 テーブルと列 配送 命名規則 テーブル 田畑 辞書ファイル フィールドとテーブルの属性 ラベル スタイル 選択肢 その他の注目すべき属性 構造規則 文字列 番号 日時 フォームとリスト Forms (フォーム) Lists (リスト) デバッグ

アプリケーション標準 Service-now.com アプリケーションスイートの主な利点の 1 つは、アプリケーション自体の統合性です。インシデント管理は問題管理にフィードされ、変更をトリガーする可能性があります。3 つすべてが、構成管理データベース (CMDB) の基礎となるデータに依存しています。しかし、これらのアプリケーションや他の多くのアプリケーションは、異なるチームによって、異なる時期に、時には異なる場所で書かれています。

アプリケーション設計標準は、これらすべてのアプリケーション、および将来開発されるすべてのアプリケーションが、エンドユーザーに対して予測可能な外観と一連の動作を持つように存在します。

このドキュメントは、3つの主要なセクションで構成されています。

設計原則 ServiceNow プラットフォームの設計アプローチの一般的な考え方。アプリケーションをビルドおよびメンテナンスする前に、これらを参照してください。

設計ガイダンス 最大限のパフォーマンスと使いやすさを実現する方法に関する具体的な詳細を、プラットフォームのコンポーネントと機能ごとに分類します。

コーディング標準 ハードルールとファストルールの両方、およびグッドプラクティスを含む、アプリケーションの基礎となるコードの記述方法。

設計原則

一貫性を保つ アプリケーションを使いやすくするためにできる最も重要なことは、ユーザーの期待に応えることです。1 つのアプリケーションの使用方法を学習すると、その知識は使用する他のすべてのアプリケーションにも引き継がれるはずです。

必要なトレーニングの削減:ユーザーは以前のアプリケーションで得たすべての知識を活用して、学習時間を短縮します。 エラーが少ない:人間の注意力の持続時間は限られています。ユーザビリティ調査では、インターフェイスが目の前のタスクに直接関係しない余分な労力を必要とする場合、ユーザーはより多くの間違いを犯すことが示されています。任意の不整合がそのオーバーヘッドを生み出します。 より幸せな従業員:常にイライラしたりイライラしたりするよりも、期待に沿うものがあれば、気分が良くなります。

より少ない労力でより多くのことを行う 可能な限り少ない関数、フィールド、単語、および行数でタスクを処理する単純なツールを作成することを目指す必要があります。これには多くの利点があります。

メンテナンスの容易さ:保守するコード、更新する機能、文書化する内容が少なくなります。 使いやすさ:人々が一度に処理できる情報は限られています。1か所に詰め込めば詰め込むほど、誰かが重要なことを見逃し、コストのかかる間違いを犯す可能性が高くなります。 速度:ページが小さいほど、読み込みが速くなり、レンダリングが速くなり、サーバーリソースがより有効に活用されます。

反復 処理 コードにコミットする前に、プロトタイプを 2 ラウンド実行し、ユーザーと検証することをお勧めします。アイデアを安価かつ迅速に議論し、ユーザーの問題を解決していると想定するのではなく、確実に解決してください。

紙またはホワイトボードにスケッチする:最初のパスを低忠実度で行い、それらのアイデアをプロジェクトに関係のない人によって実行します。頭から何かを紙に書き出すことで、アイデアの核心を客観的かつ迅速に評価できます。 コンピュータープログラムでのプロトタイプ:中忠実度から高忠実度でモックアップします。数人の顧客にエンドツーエンドの体験を案内して建設的なフィードバックを提供することで、コストのかかる多くの落とし穴を回避できます。顧客が求めるものを提供するだけでなく、十分な代表者のサンプルを入手し、行間を読んで満たされていない可能性のあるニーズを判断してください。 コードで最終的な反復を行う: 実装する項目が、他のアプリケーションで動作する、完全に設計された小さな詳細のみになったら、構築を開始します。

設計ガイダンス

ホームページ

ウィジェット ホームページウィジェットは大量のデータをプルし、レンダリングと作業に多くのリソースを必要とするため、注意が必要です。インスタンス全体のパフォーマンスに絶対的な大混乱をもたらす可能性があります。 毎朝午前9:00にウェブブラウザを起動したときに、サーバーが何に対処しなければならないか想像してみてください。 多くのウィジェットを持つホームページではなく、それぞれいくつかのウィジェットを持つ複数のホームページを作成することをお勧めします。 一連の一貫したウィジェットを使用して、さまざまなホームページを 1 つのタスクに集中させるようにしてください。

アプリケーションバー

アプリケーション アプリケーションを使用するユーザーのロールごとにグループ化して、すべてのツールに 1 か所でアクセスできるようにします。 ユーザーが作業に使用する順序と一致するように、上から下に順序付けします。 できるだけ簡潔で機能的に正確な名前を付けてください。従うべきいくつかの良いルールは次のとおりです。 デフォルトの画面サイズで 1 行に収まります。 省略しないでください。完全な単語は見つけやすく、覚えやすいです。 フィルタリングと検索を容易にするために、アプリケーション名に最も馴染みのある用語を使用します。 命名規則を選び、それを守りましょう。 常にアプリケーションヒントを入力してください。 これらは、ユーザーがアプリケーション名をポイントすると表示されます。 以下の ヒント セクションのすべての編集ガイダンスに従ってください。 ラベルの色をカスタマイズするときは、常に使いやすさを考慮してください。 ハイコントラストを使用します。最良の結果を得るには、明るい色で非常に暗いテキストを使用します。 比較的まろやかで彩度の低い色を使用してください。黒のテキストが付いた非常に明るい黄色が表示されますが、画面の残りの部分のグラフ、フォーム、およびアラートメッセージの情報を圧倒する可能性があります。 ラベルが互いに十分に異なり、一目で簡単に区別できることを確認してください。アイデアは、ユーザーが自分の選択を簡単に決定できるようにすることです。これが初めての場合は、オンライン カラースキームデザイナー などのツールを使用して、Tetrad配色から色を選択します。

モジュール モジュールを使用するユーザーのロールごとにモジュールをグループ化して、すべてのツールに 1 か所でアクセスできるようにします。 ユーザーが作業に使用する順序と一致するように、上から下に順序付けします。 できるだけ簡潔かつ正確になるように名前を付けてください。従うべきいくつかの良いルールは次のとおりです。 デフォルトの画面サイズで 1 行に収まります。 省略しないでください。完全な単語は見つけやすく、覚えやすいです。 フィルタリングと検索を容易にするために、アプリケーション名に最も馴染みのある用語を使用します。 命名規則を選び、それを守りましょう。 モジュールをセクションにグループ化して、めったに操作しないモジュールを折りたたむことができるようにします。 良いガイドラインは、セクションを最大5〜7モジュールに抑えることであり、これは使いやすさに最適なサイズです。 注意: セパレーターはフィルターによって「認識」されないため、アプリとモジュール自体の名前内に意味のある単語を作成します。 常にモジュールヒントを入力します。 これらは、ユーザーがアプリケーション名をポイントすると表示されます。 以下の ヒント セクションのすべての編集ガイダンスに従ってください。

Lists (リスト)

リストの幅 水平スクロールを行わずに、リストがインスタンスのデフォルトレイアウトに快適に収まるようにします。 リストビューからの一括編集など、タスクのためにリストを長くする必要がある場合は、その方法で使用しているユーザーが UI11 ServiceNow インターフェイスに精通しており、左側のペインを折りたたんでスペースを増やす方法を知っていることを確認してください。

列見出し 列ヘッダーにはセンテンスケースを使用します (最初の単語のみを大文字にします)。

フィールドサイズ テキストフィールドのサイズを、表示されているコンテンツに合わせます。 テキストフィールドは、デフォルトで 40 文字に切り捨てられます。これは、フィールドの辞書エントリで上書きできます。 上書きする理由に注意してください。表示する情報が少なすぎると、他の列からスペースを奪うため、そもそも列を含めないよりも悪い場合があります。 注: フィールドの折り返しはデフォルトではオフになっていますが、ユーザー設定によって上書きできるため、表示が異なる場合があることに注意してください。

注意すべきアイテム リストまたは関連リストの最初のフィールドは、参照フィールドにしないでください。 最初に利用可能な表示フィールドにレコードへのリンクが自動的に作成されます。最初に参照フィールドを使用すると、リンクが 2 番目の列に配置されるため、混乱し、一貫性がなくなります。 回避できる場合は、主に空白の列をリストしないでください。 リスト内でジャーナル、複数行テキスト、または html フィールドを使用しないでください。 これらのスタイルのフィールドは、リストレイアウトで奇妙な動作をし、使いやすさやコンテンツの可視性を損なうさまざまな方法で失敗します。情報表示の互換性と堅牢性を最大限に高めるために、他のタイプに固執します。

Forms (フォーム)

全体的な設計プロセス ユーザーを理解し、ユーザーを中心にアプリを構築します。 人々が実際に役に立たないツールを作るのは簡単です。ユーザーのニーズに注意を払って、これを回避してください。 最高のパフォーマンスを実現するための構造フォーム。 微妙な設計上の決定により、速度、帯域幅の使用、およびユーザーの生産性に大きな違いが生じる可能性があります。 ユーザビリティを最適化するフォームを設計する。 フィールドの配置、ラベル、命名規則、全体的な一貫性など、すべての詳細に注意してください。

パフォーマンス 可能であれば、フォームは 1 秒未満でロードされます。 ヒューマンファクターの調査によると、それを超えると、タスクの完了、エラー率、全体的なユーザー満足度など、ユーザビリティに大きな影響を与えることがわかっています。 各ロールに最適化されたフォームビューを作成します。 本当に必要なフィールドのみを表示します。削減すればするほど、ServiceNow の全体的なパフォーマンスが向上します。 クライアントスクリプトの使用方法には注意してください。 情報処理では、集中的なクライアント側処理よりも AJAX 呼び出しを使用したサーバー処理を優先します。 ユーザーインターフェイスには、指定されたクライアント側のアプリケーションプログラミングインターフェイス (API) を使用し、特定の HTML/CSS の詳細に依存するクライアントスクリプトの使用を最小限に抑えます。 UI ポリシーの使用を最小限に抑えます。 大きなチャンクを表示/非表示にする必要がある場合は、ロールごとに個別のフォームビューを作成します。 添付する関連リストの数に注意してください。 リストが長いと、フォームのロードに多くの追加のレイテンシーが生じます。 フォームのロード時にサーバーへの同期呼び出しを使用しないでください。 これらは、フォームのロード時に影響を受ける依存関係の自然なレイテンシの影響を乗算します。 適切な場合は、セッションキャッシュを使用してフォームのリロードを高速化します。 これによりセキュリティ上の問題が発生するため、使用するコンテンツには注意してください。

一般的な組織 関連するフィールドをグループ化します。 人々は、スキップするのではなく、1つのセクション内で特定のタスクを達成できる必要があります。 フィールドを重要度順に配置します。 密接に関連するフィールドを縦に積み重ねて、簡単にスキャンしてタブ移動できるようにします。 フォーム間でフィールドを同じ場所に保持します。 左か右かを問わず、同じ列、フォーム上の同じ一般的な位置またはセクション、および同じ名前のセクションに配置してください。 この分野が広く使用されればされるほど、このルールは重要になります。たとえば、情報技術インフラストラクチャライブラリ (ITIL) アプリケーションでは、 番号 、 名前 、 アサイン先 フィールドをすべてのフォームの左上にある必要があります。 各列に同じ数のフィールドが存在するように列のバランスを取ります。 例外:デフォルトの画面解像度に設定されているときにフォーム全体がユーザーのモニターに表示される場合は、それらを 1 つの列に配置できます。

一般的なユーザビリティ 関連するフィールドをグループ化します。 人々が一箇所をちらりと見て、特定の種類の仕事の状況を確認できるようにします。 可能な場合は、必須フィールドをグループ化します。 ユーザーが必須タスクを実行するために画面外にスクロールしたり、数秒で調べたりする必要がないように、それらを一緒に保持します。 必須フィールドを最小化します。 これらすべてが、タスクを完了するためのオーバーヘッドの最小量に追加されます。ある時点を過ぎると、オーバーヘッドが非常に大きくなるため、ユーザーは実際にフォームへの入力を避けるようになります。情報の完全性に対するニーズと使いやすさのバランスをとる必要があります。 フィールドの総数を全体的に最小限に抑えます。 短い形式は、習得しやすく、使いやすく、あらゆる点でパフォーマンスが高速です。フィールドの数が多いほど、フィールドの意味や機能が重複するリスクが高くなり、ユーザーのミスが増えます。

セクション 関連フィールドをセクションにクラスター化します。 それらを使用する最良の方法は、画面を サブヘッド に分割して、フォームをすばやくスキャンし、すばやく入力する必要がある情報の種類に焦点を絞ることです。 理想的には、各セクションは、フォームが表すタスクのライフにおける ステージ を表し、次に何をする必要があるかが一目で簡単にわかるようにする必要があります。 フォーム全体でセクションに一貫した名前を付けて順序付けします。

繰り返しになりますが、一貫性は繰り返しを生み出し、それが使いやすさを生み出します。

ラベル ラベルは簡潔で意味のあるものでなければなりません。 これは、使いやすさとスペースの使用に役立ちます。 冗長な単語を切り捨てる - フォームを更新 の代わりに、 更新 を使用するだけです。 the のような定冠詞をカットしてください。たとえば、 ソリューションを受け入れる の代わりに、 ソリューションを受け入れる を使用します。 ラベルは最小画面サイズで折り返さないでください。 個々のラベルが長い場合は、情報の一部をヒントに取り込んでみてください。 長い重複したコンテンツを含むラベルのセットの場合は、それらのラベルを独自のセクションにプルし、共有ワードを小見出しの一部にしてみてください。 それでもラップする場合は機能しますが、ノイズが発生し、スキャン可能性が妨げられます。 ラベルテキストには センテンスケース を使用します。 ラベルの最初の文字のみを大文字にします。 固有名詞などの例外を設けてください。 ラベルは、すべてのフォーム、アプリケーション、およびプラットフォームで一貫している必要があります。 標準化:同じ種類の情報がどこでも同じ方法で管理されている場合、ユーザーはアプリケーションをより迅速に操作できます。

テキストフィールド テキストフィールドの長さは、入力するデータの長さと一致する必要があります。

名前や住所など、変動の激しい情報は、完全な行を取得する必要があります。 郵便番号や州など、短くて予測可能なデータには、フィールドのサイズが正確に収まるようにする必要があります。 作業メモなどの情報の長いエントリは、ユーザーが書くのに十分なスペースを確保できるように、ゆったりとしたサイズにする必要があります。 テキストフィールドの長さは、すべてのフォーム、アプリケーション、およびプラットフォームで一貫している必要があります。

標準化:たとえば、郵便番号の場合、どこでも Zip+4 を処理するために同じフィールド長と戦略を使用します。これにより、より定期的なデータとより優れたユーザーエクスペリエンスが作成されます。

複数選択入力 複数選択フィールドは、後で予測可能な形式でキャプチャされた場合により強力になるデータを収集するのに役立ちます。 たとえば、 Priority は High 、 Moderate 、および Low の値を持つと合理的に想定できます。このように標準化されたフィールドを作成することで、意味のある方法でメトリクスを抽出できます。 ラジオボタンは、意思決定に必要なすべての情報を読み取り可能な形式で公開するという点で優れています。 2 つまたは 3 つのパスの間で決定する際に、明確にする必要がある大量のコンテンツが必要な場合は、垂直方向に積み重ねます。 特にサーベイのような長いリストでは、 はい/いいえ スタイルの選択肢としてインライン形式にします。 選択リストメニューは、主にスペースを節約するために役立ちます。 リスト全体を公開すると画面スペースを占有しすぎる場合 (特にフォームの整理に役立つ場合) に使用します。 長くしすぎないように注意してください。リストが長すぎて画面の下部から消えてしまうと、頻繁に使用する選択リストが非常に遅くなり、使いにくくなります。リストを異なるウィジェットに分割するなど、問題を処理する別の方法を見つけます。

チェックボックス これらを 1 つの列にまとめます。 これにより、ユーザーはすべての選択肢をすばやく簡単に視覚的にスキャンできます。 可能な場合は、右側の列のチェックボックスフィールドのままにします。 これは純粋に視覚的なデザインの提案です。チェックボックスは、フィールド全体よりも場所を取らず、視覚的な重量も少なくなります。すべてのチェックボックスが右側にあり、列間に大きな空白の隙間がない場合、フォームの見栄えが良くなります。

選択肢メニュー タイトル ケースを使用 すべての重要な単語は大文字です 。 入力メニューのデフォルト状態に注意してください。 一般に、メニューのデフォルトの選択を none 値にすることをお勧めします。これにより、省略された場合にフォームを保存しても、不適切なデータが自動的に入力されません。 その場合は、デフォルトのテキストとして Choose... を使用します。省略記号 (...) は、後で確認する詳細情報があることを示しており、オペレーティングシステムのメニューに標準で表示されています。 メニューがデフォルトでデータになっている場合は、ユーザーがデフォルトを使用して続行した場合の作業を最小限に抑える方法で、その選択を行っていることを確認してください。 データに合わせてメニューのサイズを変更します。 メニュー選択肢のテキストを切り捨てないでください。メニューのサイズが適切であることを確認してください。

テキストエリアフィールド 可能であれば、これらを他の入力フィールドの最後にグループ化します。 これらは長いコンテンツエントリ用であるため、サイズを大きくする必要があります。 ほとんどの場合、フォームの全幅を指定します。 これらのタイプの入力では、小さすぎるよりは大きすぎる方が良いです。 一貫した 倍数 の行でサイズを設定します。 たとえば、異なるサイズにする必要がある場合は、2 行、4 行、6 行などの一貫したパターンを使用します。これにより、より予測可能で審美的なレイアウトが作成されます。 テキストエリアフィールドを全幅の列に配置します。 半幅の列に入れる ことができます が、これは他の問題を引き起こす傾向があります。 たとえば、一方のサイズを変更してももう一方のサイズは自動的に変更されないため、外観および使用感に一貫性がなくなります。 さらに、SafariやChromeなどの多くのWebブラウザーには、テキストエリアフィールドのサイズを変更する機能があり、これは私たちが提供するコントロールを上書きします。ユーザーは、左側の列のフィールドを非常に広くして、他の列の内容を押しのけるようにすることができます。この問題を完全に回避し、完全な列を与えるのが最善です。

関連リンク このエリアは、最高のユーザビリティのために整理してください。 それは生来の構造を持っていないので、時間をかけてそれを作り、さまざまな形でそれに固執してください。可能な限りデフォルトのリストと同じ順序にすることをお勧めします。これにより、ユーザーは以前の知識とシステムへの精通度を活用できます。 可能な場合は、類似アイテムをまとめてグループ化します。 リンク名は短く、要点を絞ったものにしてください。 ボタン名と同様に、できるだけ多くの単語を削除します。 センテンスケースを使用しますが、センテンスの句読点は使用しないでください。 フォームやアプリケーション間で関連リンクの一貫性を維持します。

関連リスト 最高のパフォーマンスを得るには、この領域を小さくします。 使用するエントリと列はできるだけ少なくしてください。フォームがロードされると、すべての関連リストを取得する必要があります。このプロセスによりレイテンシーが非常に長くなり、フォームが応答しなくなり、数秒間フリーズしたように見えることがあります。 リストまたは関連リストの最初のフィールドは、参照フィールドにしないでください。 最初に参照フィールドを使用すると、実際のレコードへのリンクが 2 列目または別の列に表示されるため、混乱を招き、通常のリストの動作方法と矛盾します。レコードを最初のリンクとして保持します。 他の場所にあるリストを複製する場合は、忠実に複製します。 列の順序や列数などを同じに保つことで、ユーザーのメモリと認識が情報をすばやく解析できるようになります。 リストを使用して別の形式のデータを表示する場合は、不要な列をすべて削除します。 たとえば、レコードの P1/2/3 ステータスのみを強調表示する場合は、他のすべての列を遠慮なく削除してください。 これにより、無関係な情報が少なくなるため、バックエンドとユーザーインターフェイスのパフォーマンスが向上します。 これらのリストの順序は、フォームやアプリケーション間で一貫性を保ちます。 ソートスキームを選択し、インスタンス全体でそれに従います。予測可能で、ユーザーにとって馴染み深いものほど良いです。

グローバルインタラクション

アクションボタン フォーム内の状態やデータを実際に変更するものにボタンを使用します。 これらは、所有者の変更、編集、閉鎖などの作業が行われたことを示します。 各フォームのアクションの数は妥当な数に抑えます。 ユーザビリティの観点からは、3 つから 4 つのアクションが最適です。最大で5つを目指します。 それ以上になると、それらを見つけて覚えるのがはるかに難しくなります。 タイトルケースを使用 名前はできるだけ短く、意味のあるものにしてください。 これは、使いやすさとスペースの使用に役立ちます。 冗長な言葉をカットする。既にフォームが表示されているため、 フォームの更新 の代わりに 更新 を使用します。 the のような定冠詞をカットしてください。

リンク リンクを使用して、現在作業しているフォームまたはコンテンツの外部に存在する補足コンテンツに移動します。 フォームの状態が失われないように、リストやフォームなどのアプリケーションとの間のリンクは、新しい Web ブラウザーウィンドウにポップする必要があります。 Wiki やナレッジ記事などのコンテンツサイト内のリンクは、同じウィンドウ内でリンクする必要があります。

コンテキストアクション コンテキストアクションを使用して、現在選択されている情報にドリルダウンする、より詳細なフィルタリング、ソート、またはその他のアクションを実行します。 使用するコンテキストアクションはできるだけ少なくします。現在、コンテキストアクションを見つけるのは困難です。それらをより見やすくする方法を検討していますが、それまでは、可能な限りこれらのコマンドを 常に表示 してください。

Syspopup Syspopups を使用して、別のフォームへの完全なラウンドトリップを必要とするコンテキストフォームデータを提供します。 ポップアップを編集して、必要最小限の情報を表示します。 デフォルトは現在のビューと同じです。 ビューが小さいほど、ロードと表示が速くなります。

ヒント それらを使用して、ユーザーが提供する必要のある情報のタイプに関するコンテキストヘルプを提供します。 ラベルを繰り返すだけでなく、他の方法では知らない情報を提供します。 フィールドレベルのヒントは必須です。 アプリケーションとモジュールのヒントはオプションですが、常に使用する必要があります。 短く、本質的なものにしましょう。 短い宣言文として最適に機能し、完全な文である必要はありません。 1 つの文の末尾に句読点を使用しないでください。例外は複数の文がある場合ですが、これは通常、冗長性を示しているため、避ける必要があります。 センテンスケースを使用します。 フレーズ内の最初の単語または固有名詞のみを大文字にします。 それらを完全な文章にしないでください。余分な言葉や句読は必要ない。 一貫性を保ちます。 すべての音符の長さ、声、トーン、単語の選択に注意してください。 類似のラベルのヒントは、フォームやアプリケーション間で同じに保ちます。 定冠詞または不定冠詞を最初の単語として使用しないでください。 このデバイスの DNS 名 (解決可能な場合) (正しくない) このデバイスの DNS 名 (解決可能な場合) (正しい)

アラートとメッセージ 短く、本質的なものにしましょう。 短い宣言文として最適に機能し、完全な文である必要はありません。 1 つの文の末尾に句読点を使用しないでください。例外は複数の文がある場合ですが、これは通常、冗長性を示しているため、避ける必要があります。 センテンスケースを使用します。 フレーズ内の最初の単語または固有名詞のみを大文字にします。 メッセージを お願いします で始めないでください。 メッセージに{0}、{1}などの置換を使用して、適切な翻訳が可能であることを確認します。

UI ページ UIページは基本的に白紙の状態であり、ユーザーインターフェイスを任意のものに完全に変更できます。 すでに詳細が組み込まれていないため、使用できる唯一の設計アドバイスは、ServiceNow プラットフォーム内の他のすべてのオプションを使い果たしない限り、それらを使用しないことです。その理由は次のとおりです。 アップデートは物事を壊す可能性があり、時にはひどいこともあります。 ServiceNow が新しいアップデートを展開するたびに、プラットフォームでビルドされたアプリが自動的に更新されます。他のテクノロジーを使用してビルドされたワンオフ機能は自動的に更新されないため、大規模な作業を実行するまで完全に機能しなくなる可能性があります。 メンテナンス時間とコストの増加。 あからさまに何も起こらなくても、ServiceNow は伝播しない改善を行う可能性があります。たとえば、新しい UI では、ServiceNow はビジュアルスタイルを更新するため、これらの改善をアプリに個別に実装する必要があります。また、まったく得られないウィジェットの改善があるかもしれません。たとえば、検索フィールドでの先行入力予測が大幅に改善されます。 不整合がユーザーエクスペリエンスに忍び寄ります。 ServiceNow プラットフォームで何かを構築する場合、特定のウィジェットには多くの追加機能があります。同じように見える別のテクノロジを持つウィジェットを追加する場合、必ずしもそれらの利点があるとは限らないため、時間をかけて同じように機能させないと、ユーザーがどこにいるかによって異なることを行う、似たような外観のコントロールになります。これらの問題は使いやすさを低下させ、最終的にはユーザーの信頼と信頼を損ないます。 次のリリースで開始される作業を複製できます。 場合によっては、プラットフォームが80%到達し、UIページを使用してインターフェイスを構築することで、必要なものを正確に取得できます。ただし、構築に多くの時間と時間を費やして、ServiceNow が次のバージョンでまったく同じ機能をリリースするだけかもしれません。これは費用対効果の分析に帰着するため、簡単な答えはありませんが、段階的な改善に多くの時間を費やすことには注意してください。 UI ページが存在するのには理由があり、プラットフォームがサポートしていない方法で新しいツールを統合する必要がある場合があります。ServiceNow では、ビルドする前に必要であることを確認することをお勧めします。 UI ページを使用して、焦点を絞った永続的なプラットフォームからの逸脱を実現します。 根本的に異なる情報の視覚化を作成します。たとえば、あるイノベーター・オブ・ザ・イヤー賞は、完全にインタラクティブで閲覧可能なフロアプランに資産をマッピングした顧客に授与されました。ServiceNow が現在提供している機能を上回る大幅な機能強化であり、すぐに廃止されることはないでしょう。 業界固有のインターフェイスを作成します。フォームとリストによって駆動される現在の ServiceNow インターフェイスでは、非常に多くの問題を解決できますが、根本的に異なるフロントエンドを使用すると、共通のタスクをはるかに効率的に完了できる場合があります。その場合、継続的な投資の価値がある可能性があります。

コーディング標準

テーブルと列

配送 テーブルは、プラグインディレクトリ内の.xmlファイルとして配布されます。

命名規則

テーブル テーブル名は 30 文字以内にする必要があります。 テーブル名は、スペースの代わりに「_」を使用してすべて小文字で定義されます。例:my_table_name。 共通の目的を持つテーブルは、共通のプリフィックスを共有する必要があります。 次のプリフィックスは予約されています。

sys_ > システムテーブル sys:システムテーブルでの使用は廃止>。sys_を使用します。 cmn_:cmn_company や cmn_department などの一般的なテーブル> u_:> ユーザーテーブル。このプリフィックスが付いた ServiceNow テーブルは使用しないでください。

フィールド フィールド名は 30 文字を超えてはなりません。 フィールド名は、スペースの代わりに「_」を使用してすべて小文字で定義されます。例:my_field_name。 フィールド名は目的を表す必要があります。たとえば、 caller_id や assigned_to は適切で、 user1 と user2 は適切ではありません。 共通の論理フィールドを使用する場合は、適切なフィールド名を使用します。 name:モノの名前 description:同じものの説明 order:物事のシーケンス コメント - テーブル上のコメントまたはセルフ ドキュメント

辞書ファイル テーブルは、テーブルと同じ名前の.xmlファイルで配布されます。例:my_new_table -> my_new_table.xml。 .xmlファイルごとに 1 つのテーブルのみ。

フィールドとテーブルの属性

ラベル デフォルトでは、テーブルの XML で指定されたフィールドのラベルは、その名前に基づいて生成されます。ラベルは、アンダースコアをスペースに置き換え、単語をセンテンスケースで書式設定することによって生成されます。たとえば、 incident_state という名前は インシデントステータス 」というラベルになります。

label 属性は必要な場合にのみ使用してください。以下では、 num_chunks と num_consistent_chunks の目的ラベルが名前と一致しませんでした。

スタイル フィールドスタイルは、テーブルの.xmlの要素定義内で指定する必要があります。 ライトグリーン と トマト は、それぞれグリーンとレッドの好ましい代替品であることに注意してください。構文については、以下を参照してください。

Choices (選択肢) フィールドの選択肢は、テーブル定義で直接指定する必要があります。以下の構文例を参照してください。

その他の注目すべき属性 目がくらむほど明白でない限り、すべてのフィールドに hint 属性が必要です。 計算フィールドの使用はお勧めしません。 選択肢フィールドの choice 属性は、次のいずれかに設定する必要があります。 choice="1" (ドロップダウンに - なし - (デフォルト値の指定必須)) choice="2" (提案) choice="3" (ドロップダウンと - なし - )

構造規則 コア フィールドは複製しないでください。 sys_created_on フィールドは既に存在します。独自の タイムスタンプ を追加しないでください。 ストレージには適切なタイプを使用します。日付は文字列フィールドに格納できますが、日付は格納すべきではなく、数値も格納すべきではありません。

文字列 2 文字の状態コードを格納するなど、やむを得ない理由がない限り、すべての文字列フィールドの長さは次のいずれかである必要があります。

40 - システムのデフォルト 80 - 長い 1 行テキスト 255 - 小さな複数行フィールド 4000 - 中程度の複数行フィールド xxlarge—large (CLOB (Character Large Object)) フィールド

番号 特定のデータフィールドに対して可能な限り単純な数値タイプを使用します。 integer が機能する場合は、 decimal の代わりに使用します。

日時 glide_date_time:タイムスタンプ (例:2010 年 12 月 25 日 12:34:56) glide_date - 日付 (例:7 月 4 日) glide_time - 時刻 (例:午後 4:00) glide_duration:時間のスパン (例:4 時間)

フォームとリスト

Forms (フォーム) UI に直接リンクがない場合でも、すべてのテーブルにはデフォルトのフォームが必要です。

Lists (リスト) UI に直接リンクがない場合でも、すべてのテーブルにデフォルトのリストが必要です。

デバッグ プロパティを使用してデバッグ機能を制御します。これにより、ユーザーがスクリプトを変更してデバッグを有効にする必要がなくなります。

//get debug state from property var debug = gs.getProperty("com.snc.my_app.debug", false); if (debug) gs.print("My app just did this"); 大量のデバッグ出力を使用する予定の場合は、ログテーブルではなく、コンソールにのみ書き込みます。 デバッグログ モジュールを実行して出力を確認するようにユーザーにアドバイスします。