保守可能でありながら有益なユーザー通知メッセージを設計する方法
Webアプリケーションで使用するユーザー通知メッセージのデザインに関連するデザインの問題に直面しています。
念のため、私はJS環境で作業しており、json構造を使用してユーザー通知メッセージを保存しています。ただし、これは高レベルのソフトウェア設計の問題であるため、ここで使用する実際の技術スタックは重要ではないと思います。
私は2つの極端な状況を見て、その中間を取りたいと思います。
- 非常に一般的なメッセージ詳細は提供されませんが、デザインを保守可能で、クリーンで、整理されたものにし、さまざまな状況に適用できます。例として、アプリで新しい本/ユーザー/車などを作成するとします。このアプローチでは、ユーザー通知は次のようになります。
- 成功時：「エンティティが正常に作成されました」
- エラー時：「エンティティを作成できませんでした」
VS.
非常に有益でカスタマイズされたメッセージですが、設計が複雑になります。上記の例に従うと、成功の場合は3つのメッセージ、エラーの場合は3つのメッセージが必要になります。
- 成功した場合：「本が正常に作成されました」/「ユーザーが正常に作成されました」/「車が正常に作成されました」/など。
- エラー時：「本を作成できませんでした」/「ユーザーを作成できませんでした」/「車を作成できませんでした」/など。
さらに、エンティティが追加/変更された場合は、新しいメッセージを追加する必要があります。または、さらに悪いことに、たとえば成功メッセージが変更された場合、エンティティごと（本/ユーザー/車など）に変更する必要があります。このi18nの側面に加えて、保守性が問題になります。
ソリューションをもう少し柔軟にするために、いくつかのJS文字列補間を組み合わせることができますが、それが最善のアプローチかどうかはわかりません。
もちろん、例は少しつまらなくて不自然ですが、私が表現しようとしていることを示していると思います。この設計問題にどのように取り組むことができますか？
システムのアクターについて何を知っていますか？彼らは技術に精通していますか？技術に精通したユーザーにとって、Word Entityはまったく意味がありません。彼らも人間ですか？それらはHTTPクライアントですか？
現実の世界と同様に、メッセージは対話者に適合させる必要があります。
要件はこれらのメッセージについて何と言っていますか？プレースホルダーまたはテンプレートを実装できるように、それらはすべて同じですか？
request.create.resource="${entity} created successfully"
それらはもう少し具体的ですか？
"[User] [X] registered successfully. We sent an email to [email] ...."
エンティティが追加/変更された場合は、新しいメッセージを追加する必要があります。または、さらに悪いことに、たとえば成功メッセージが変更された場合、エンティティごと（本/ユーザー/車など）に変更する必要があります。これらのi18nの側面に加えて、保守性が問題になります。
I18nメッセージは、程度の差はあれ静的リソースであることに注意してください。 DBに保存されている場合でも、メンテナンスのためにスクリプトを実行する必要があります。
一方、アプリに新しいエンティティを追加する場合、新しいメッセージの追加は進化の一部であり、多言語をサポートするためのソリューションが単純であるのと同じくらい問題があります。 「複雑さ」と「怠惰」を混同しないでください。
私の経験では、「最適な」ソリューションは、アプリケーションを再構築および再デプロイすることなく、これらのリソースを解放する方法を容易にするものです。 CDN、DB、またはファイルシステム自体からi18nファイルを動的にインポートできます。インポートはバックグラウンドまたはフォアグラウンドで行われる場合があります。コンテンツは、JSON、CSV、キーと値のペアなど、必要なものであれば何でもかまいません。デプロイメントパイプラインとスタックに最適な実装を見つける必要があります。
まず、成功メッセージとエラー/失敗メッセージは対称的ではありません。成功は明確にしかし控えめに示されるべきです。通常、実行中の操作を示す回転カーソルを削除するだけで十分です。
一方、エラーメッセージは、問題を解決するために利用可能で役立つ情報をできるだけ多くユーザーに伝える必要があります。問題がユーザーから提供されたデータにある場合、メッセージは何が間違っていたかを示し、おそらく正しい使用法に関するドキュメントを示しているはずです。サーバーに問題がある場合、メッセージには、サポートが問題をすばやく特定できるようにする情報が含まれている必要があります。
「エラー：エンティティを作成できませんでした」などのメッセージは、ユーザーにとっても、サポート担当者にとっても役に立ちません。