データグリッドで同様のタイトルを切り捨てるベストプラクティスは？
次のテーブルがありますが、テーブル自体に十分なスペースがないため、名前が最大14文字で切り捨てられています（実際には、いくつかの列があります）。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
しかし...そのリストが非常に類似した名前で構成されている場合があり（非常に長い場合がある）、ユーザーが各エントリの背後にある実際の名前を知らない場合があります。
次のUXパターンについて考えていました。
- ツールチップの追加-リストが非常に長くなる可能性があるため、お勧めできません
- 最初の列のフィクスチャ位置と他の列の水平スクロールを追加しますか？
列は例示ですが、スペースを確保するために列を除外することはできません。
タイトルを切り詰めて、両端から意味がわかるようにします。
使用事例：
- SomeBrandname Chocolate
- SomeBrandname Bread
- SomeBrandname Tea
8：6に分割します（全長は14のままです）
切り捨ては次のようになります：
- SomeBran ... colate
- SomeBran ...パン
- SomeBran ... me Tea
追加のロジックで8：5に分割
ロジック：
- パート1は最初の8文字です
- 8文字を超える場合は、パート2を追加します
- パート2は、スペース（またはダッシュ）の最後のインデックスから数えた最初の5文字です。
切り捨ては次のようになります：
- SomeBran ... Chocol ...
- SomeBran ...パン
- SomeBran ... Tea
更新
Brandnameを分離できればより良いでしょうが、それでも重要な情報が失われる可能性があります。例：
- 有機緑茶の葉
- オーガニックカモミールティーバッグ
複雑なサーバー側ロジックを使用すると、タイトルを切り捨てて固有の部分を少し節約できます。 16文字の制限を維持すると、例は次のようになります。
- Org.Gre.Tea Leav
- Org.Cha.Teaバッグ
しかしそれでも：2番目のお茶は「チャイ」または「カモミール」のお茶ですか？
トランケーションは情報の損失につながります
自問する質問：
- 情報の損失はどのくらい許容できますか？
- 何らかの情報の損失によって引き起こされる影響は何ですか？
- データを作成するときに、情報の損失が最小限に抑えられるようにシステムが簡単にデータを切り捨てられるように構造化できますか？
上記の例を見ると、切り捨てによって混乱が生じる可能性があることは明らかです。それにもかかわらず、切り捨ての精神で、ここに3つのプロトタイプがあります https://jsfiddle.net/phaze_phusion/vwdb72f3/
長いテキストを切り捨てるいくつかの方法は次のとおりです。
- 必要に応じて、2行を使用します。
- 名前の中央または重要度の低い部分に省略記号を使用します。
- 最初と最後に2つの省略記号を使用します。
- font-sizeを縮小します。テキストを読みやすくする一方で、フォントサイズを小さくして、さらに数文字を収めることができます。
フィールドまたは列内で水平スクロールバーを使用することはお勧めしません。
全文を表示するには、デスクトップデバイスのホバーまたはタップデバイスのタッチで表示されるツールチップを利用できます。アイコンなどを使用して、クリック/タップで操作することもできます。 （ この他の質問 関連があるかもしれません）
テーブルのデザインを変更することは可能ですか？ここに私が提案しているものの大まかなアイデアがあります。色、見出し、および背景は、実装する場合はもっと考える必要があります。
個人的には、テーブルの意味と矛盾するので、プロダクトマネージャーとしてもユーザーとしても、切り詰められたテーブルは好きではありません。テーブルは、その一部ではなく完全なデータを提示する必要があります。コンテンツ全体を表示するために各フィールドにカーソルを合わせる必要はありません。さらに、ツールチップからテキストを貼り付けることができません。
これは私が何をするかです： 
ブランド名と住所を1つの列に結合します。色、フォントサイズ、行間隔などで操作できます。これらの列は長い列であるため、テーブルに多くのスペースが追加されます。さらに、この情報を組み合わせて、読み取りフローとスキャンを改善することをお勧めします。
次に、すべての列にチェックボックスが付いています。これはブール値なので、2つの異なる色のアイコンを使用します。1つはtrueで、もう1つはfalseです（駐車場アイコンのように）
場所に関しては、私はそれが相対的だと思ったので、ここでは、各州への距離または特定の色の有無のテキストを指定できます。別のオプションは、色が何であるかを理解するためのツールチップのアイコンのみを持つことです。
タイトルと同様に-それらは2行に分割するか、フォントサイズで遊ぶことができます
オプション1：ユーザーが表示したい列を選択できるようにして、名前用のスペースを作成する
オプション2：サイズ変更可能な列
単語を切り捨てると、ユーザーエクスペリエンスが低下します。ユーザーが実際に何を意味するのかを理解するのが難しくなります。
では、表形式のテーブルを使用しないのはどうですか？
たとえば、代わりにカードベースのデザインを使用できますが、これはテーブルに表示されているレコードの数によって異なります。
https://www.smashingmagazine.com/2016/10/designing-card-based-user-interfaces/
カードは情報をコンテンツのチャンクに編成します。ユーザーはチャンクコンテンツを高く評価します。これは、スキャンしやすくなるためです。テキストの壁を回避するのに役立ちます。カードは、テキストの段落が文を個別のセクションにグループ化するのと同様に、コンテンツを意味のあるセクションに分割します。さまざまな情報を収集して、1つの一貫したコンテンツを形成できます。
カードの利点は、名前とコンテンツのためのスペースがはるかに多いことです。つまり、おそらくカードを切り捨てる必要はありません。これにより、表形式のテーブルよりも少しコンテンツを整理することができます。
写真を追加して、写真をより豊かにすることもできます（必要な場合）。将来的には、モバイルへの移植がはるかに簡単になります（これを実行したい場合）。
レコードがたくさんある場合でも、カードベースのデザインを使用できますが、ユーザーが興味のあるカードを簡単に見つけられるように、追加の検索と参照メカニズムを提供する必要があります。ファセットナビゲーション。
http://alistapart.com/article/design-patterns-faceted-navigation
ガイドナビゲーションおよびファセット検索とも呼ばれるファセットナビゲーションモデルは、メタデータフィールドと値を利用して、クエリを明確化および調整するための表示オプションをユーザーに提供します。ファセットナビゲーションは、間違いなく過去10年間で最も重要な検索イノベーションです。統合されたインクリメンタル検索とブラウズのエクスペリエンスが特徴で、ユーザーは従来のキーワード検索から始めて、結果のリストをスキャンできます。また、コンテンツとその構成に関する洞察を提供し、さまざまな便利な次のステップを提供するカスタムマップ（通常は結果の左側）を提供します。ファセットナビゲーションがその威力を発揮するのは、ここです。プログレッシブ開示とインクリメンタル構築の原則に従って、ユーザーは一連の小さく単純なステップを実行することにより、高度なブールクエリに相当するものを作成できます。ファセットナビゲーションは、狭めるという普遍的なニーズに対応します。その結果、構造化されたメタデータが利用可能であり、製品の見つけやすさを向上させる明確なビジネス価値があることを考えると、このパターンはeコマースでほぼ遍在的になっています。ファセットナビゲーションは、非常に多様なコンテキストとプラットフォームに急速に展開されています。検索の世界では、ファセットナビゲーションが至る所にあります。
テーブルの一部の列は、カードをより管理しやすいセットにフィルターできるようにするファセットになります。駐車場、Wi-Fi、ファミリールーム、場所と割引。
私は次のようにします：
- カードを使用する代わりに、各エントリ間でデータを垂直方向および水平方向に比較するのに役立つため、管状のテーブルのままにしておきます。
- 駐車場+ファミリールーム+ Wifiを「追加」と呼ばれる1つの列に結合し、それぞれのアイコンに代わりにアイコンを使用しますチェックマーク。それぞれのアイコンにツールチップが表示され、その意味を説明します。より長い長さを必要とする列のためにより多くのスペースを得るこの方法。
別のアプローチは、隣接するアイテム間で最長共通サブシーケンスアルゴリズムを使用することです。次に、テキストが長すぎる場合は、サブシーケンスの一部を削除します（可能な場合）。
例えば
SomeBrandWidget -> S...Widget
SomeBrandGizmo -> S...Gizmo
ACMEWidget -> ACMEWi...
私見あなたの質問はより広いです。あなたが本当に求めているのは、「ユーザーに必要な情報を簡単に見つけさせるには」これが私の提案です。
ユーザーはresize列の幅を指定できる必要があります。列の幅が小さすぎるときに文字列が完全に表示されない場合、既に示唆したように、文字列は中央に省略記号である必要があります。
さらに、ユーザーが検索語を入力できる場所にfilter textfieldも追加する必要があります。フィルターに一致しないすべての行は、ユーザーのビューから非表示になります。
テキストフィールドフィルターは、最初の列のみ、またはすべてをフィルターにできます。列に同様のデータが含まれている場合は、列ごとに異なるテキストフィールドフィルターを選択することもできます。これは実際にはアプリケーションに依存します。
別の良いアイデアは、列ごとにテーブルsortableを持つことです。
表形式のままにしますが、ブランド名、住所、営業時間を組み合わせると、横に拡大するためのスペースが増え、データを切り捨てることなく表示できます。フォントのスタイルでブランド名、住所、営業時間を区別するだけです。より優れたまたは悪い使用アイコンを書く代わりに、より多くのスペースを節約します。
ありがとうございました！
私の応答は、noadaviの応答と非常によく似ています。これがモックアップです。違いを説明するために、これに従います。
注記
アクセシビリティの理由で情報を伝えたくないので、色を適用していません。色は簡単に追加できますが、伝達されるメッセージの一部としてではなく、純粋に視覚的な関心のためのものでなければなりません。
Noadaviと同じように、同じセルの2行にブランド名と住所を含めました。これはより広い幅を提供し、ユーザーの観点からは事実上同じ情報の2つの部分になります-人間が場所を探している場合、おそらく場所の名前を住所の最初の行として扱います！ （もちろん、仮定なので、いくつかの調査で確認する価値があります）
noadaviのアプローチのバリエーション：
- カラムの幅を狭くするために、コストの表示を微調整しました
- 駐車場、Wi-Fi、ファミリールームの列は保持していますが、チェックボックスを使用するのではなく、アイコンを使用してこれらのプロパティの存在を表示しています。アイコンは列に配置され、優れた代替テキストで同様の意味を伝えることができます-チェックボックスのチェックされたバージョンの代わりにアイコンを使用し、チェックされていないバージョンの代わりに空白を使用しています。
- これらのアイコン列の列ヘッダーをそれらの列にまたがるように作成しました。アイコンはそれぞれ、列の意味を十分に伝えています。
- 「良い場所」を詳細に移動しました...しかし、それが実際に何を意図しているかは100％わかりません。 「悪い場所」を宣伝したくない人はいないので、その情報から誰が恩恵を受けるのか、そしてそれがデータの存在に人々が反対する理由になるのかどうか、私は一生懸命考えます。
したがって、すべてのデータが存在し（「割引」を除く-忘れてしまい、追加する時間がありません。別の「詳細」になります）、同じ列にありますが、より凝縮されて表示されます仕方。
Noadaviは場所の列にも距離を追加しました。これは、「場所」が良いか悪いか（「大声の場所に近い」または「素晴らしい環境にある」とは対照的）である場合、ここで複製できます。場所の列は、それらのアイコン列の最後に配置されます。それが別の種類の場合は、「静かな場所」または「きれいな場所」のアイコンに分解することもできます-基本的には視覚的な「タグ」列です。
2017年2月17日、コメントに続いて追加
以下の Joao Carvalho からのコメントに促されて、「1泊あたり」をコスト列ヘッダーからデータセル自体に移動する理由を明確にする必要があります。私にはそのような2つの理由がありますforこれを行う。
- 列の幅-ヘッダーの「1泊あたり」により、列がはるかに広くなり、幅を減らすことが質問の元の目標でした
- 1泊以外の基準で利用できる宿泊施設に対応するという点で、デザインに柔軟性を追加します。例として、タイムシェアとホリデーレットは、多くの場合、週単位と価格スケールでのみ利用可能です。そのようなものに日次レートを提供することは、日次レートに基づいて短期滞在を予約しようとする人にとって直観に反します。
ただし、トレードオフがあります。非常に強い理由がありますしないそれを行うには。
- 行間の比較を行うためにユーザーが通らなければならない解釈と変換の追加のステップを追加します。
- 設計に柔軟性を追加する場合、つまり、読み違い、誤解、またはその他の単純な混乱を容易にします。
全体として、ほとんどの場合、共通の時間単位の方が優れているという点でJoaoに同意します...しかし、テーブルの幅を圧縮することはそれほど役立ちません。 1泊あたりの宿泊施設がその場所では利用できない場合。
場所が異なるタイムスケールで提供されている場合、これらのタイムスケールを視覚的に区別するために、ここで示したよりも多くの作業が行われることを期待しますが、その区別必要になる場合があります。