web-dev-qa-db-ja.com

省略表現の認識性

現在、モバイルアプリのワイヤーフレームに取り組んでおり、カスタマイズされたアイテムが小さな画像としてリストされているプラ​​イマリオブジェクトについて話し合うときに、w /を使用して「with」と発言しています。

私の質問は次のとおりです。消費者向けアプリケーションで使用される場合、従来の意味での速記の認識/理解を示す研究を知っていますか、または見たことがありますか?

2
Ariel Spaulding

これは興味深い質問だと思いました。私は略語でかなり問題に出くわします。公式の標準を無視している間、彼らにとって意味のあるものを使用することを好む人もいますし、その逆もあります。省略形は興味深いオプションのようです。

かなりの調査をした後、私は1つの研究しか見つけられず、それは私が期待したものとは正確には一致していません。研究は、「研究の実用的な値速記」​​に焦点を当てています。完全一致ではありませんが、興味深い見識が得られます。それはさらなる研究への出発点になるかもしれませんが、残念ながら、私はその日の私の研究時間を使い果たしました。

他に何もなければ、それは短い読みであり、いくつかの興味深い洞察を提供します。

https://archive.org/details/educationalandp00soregoog

1
Johnny UX

略語は、ユーザーとスタッフおよび開発者の間の摩擦の一般的な原因です。たとえば、ユーザーが支払いプロセス中に理解できない略語に遭遇し、支払いをキャンセルする必要があるとします。彼らは、彼らとは何の関係もないと言っているメンテナンスに連絡します。ユーザーはかなりすぐに迷惑になるので、メンテナンススタッフもそうです。次に、メンテナンスを開発者に依頼して修正するように伝えますが、開発者には他にも重要な作業があります。

あなたがポイントを取得します。また、システムが支払いなどの重要な問題を処理しているかどうかにかかわらず、あまり知られていない省略形wellをユーザーから遠ざけるのが賢明です。あなたの問題に対する私の提案:

  • 開発中は省略形を使用できます。たとえわずかであっても、プロセスはより速くなります。
  • システムが稼働する前に、システムから未定義の省略形をすべて削除する必要があります。
  • 残っている略語の定義を提供する必要があります。これは、「略語テキスト(ATH)」の形式でよく行われます。この後、定義なしで略語を使用できます。

主に文法の正確さと国際標準への準拠のためのいくつかの参照:

また、文法ページから:

書くときに、あなたが読んでいるものを忘れてしまうような短い形式を理解するのに読者があまりに行き詰まらないことが重要です。

従うべき良いアドバイス。ユーザーが関係する場合は、略語は慎重に使用してください。

0
ArtOfCode