タブ内でタブをデザインするとユーザーエクスペリエンスが低下することを示唆する証拠はありますか？
複雑なWebアプリケーションを設計していますが、タブパネルを使用することは悪い考えだと同僚は考えています。私はもっとあいまいです。
誰かがこの事例を回避すべきかどうかを明確にするのに役立つ可能性のある証拠（事例ベースまたは調査ベース）を指摘できますか？.
私は例 here を提供しました。
うわー、私はこの方法で答える唯一の人になります：適切なコンテキストで問題ありません！
あなたの例は間違ったコンテキストです。ウィザードのステップはタブではありません。ただし、次のルールに従っている場合は、タブ内でタブを使用しても問題ありません。
- タブの各レベルは視覚的に区別するである必要があるため、どのレベルの組織に取り組んでいるかが明確になります。
- 制限数タブの数。無限は悪いです。 5が最大です。 （下に示された）。
- 「オン」状態は非常に明確である必要があります。ホットカラーを使用して、その色をはっきりさせます。ユーザーは何も考えずにいつでもどこにいるかを知る必要があります。
- 情報アーキテクチャを試してはいけません。タブは編成の機能です。創造的であり、組織が直感的であることを確認してください。
- タブがステップではなく実際のタブであることを確認してください。 （あなたの例）
複雑な例。強力なナビゲーションと多くの機能を備えたB2bアプリケーション。
1998年に設計したアプリケーションの別の例：
ネストされたタブは、Windows 7およびWindows VistaのWindowsユーザーエクスペリエンスインタラクションガイドラインに違反しています（pg182を参照）。これには、同じウィンドウでの水平タブと垂直タブの組み合わせが含まれます。たぶん、彼らがこれを禁じた証拠はたくさんあります。問題は、ユーザーがどのタブのどのページにいるのか簡単に混乱し、クリックする場所が混乱することです。
タブをネストする唯一の理由は、階層的に編成された情報がある場合です。ただし、階層情報をナビゲートするためのオプションは他にもたくさんあります。パン粉と木がすぐに思い浮かびます。
あなたの例では、あなたが本当に階層的な情報を持っているかどうかはわかりません。ユーザーはサブステップから任意のステップにジャンプしますか？もしそうなら、それはそのステップのデフォルト/最後に訪問したサブステップになる頻度はどれくらいですか？ステップとサブステップを区別する理由はありますか？それらをすべてステップにしないのはなぜですか？概念的なフレームワークを提供する必要がある場合は、静的テキスト（たとえば、「サイボーグを設計する（ステップ1〜5）」、「サイボーグをプログラムする（ステップ6〜8）」、サイボーグを破壊する（ステップ9 ）」）
ユーザーエクスペリエンスはすべてコンテキストに関するものであるため、タブ内のタブが意味をなし、適切に実装されている場合に優れたユーザーエクスペリエンスを提供できる状況が発生する可能性があります。
しかし、原則として、それは手元の状況に最も適したソリューションであることを示す証拠がない限り、避けるべきものだと思います。
ネストされたタブを使用したい特定のコンテキスト（あなたの例）に関しては、それらは完全に不適切で無意味だと思います！タブは（タブのコンテンツへの）ランダムアクセスを可能にしますが、（線形）ステップベースのプロセスを実装しようとしているため、ステップの単一のタブセットでもジョブの（ナビゲーション）ツールとして不適切です。タブ内にタブをネストするだけ！
ステッププロセス内のナビゲーションを前方および後方（および終了/中止）に制限し、ステップにサブステップ/タスクが本当に必要な場合は、親ステップのページのセクションにリストすることをお勧めします。
はい*アスタリスク付き。しかし、私が尋ねる最初の質問はこれです：
他にどのようにしてこの設計問題を解決できますか？
代替手段が楽しく単純ではない場合、ネストされたタブが Microsoftガイドライン に違反しているという事実にもかかわらず、私はtabset-on-a-tabソリューションを検討します。どうして？ GUIデザイナは常に単純な問題の解決を任されるとは限らないため、特にWebのドメイン外では、クライアントが「ユーザーXを伝える」または「ユーザーXを伝える」よりもはるかに複雑な問題を引き起こす可能性があり、ユーザーが複雑なタスクをウィザードのようなステップに時間化したり、不定期のコントロールを徐々に公開してユーザーインターフェイスを簡素化したり、デザイナーが使用できるその他のトリックを妨げたりする特定のニーズ。
タブの広い解釈で、この質問への答えははい*であると思いますアスタリスク。アスタリスクは次のとおりです。おそらく、タブセットの外観は異なる必要があります（これにより、nameタブ以外の何かになる可能性があります—ナビゲーションバー、ブラインド、ウィザードなど）。何をするにしても、設計が複雑な場合は、プロトタイプをユーザーに確認してください。タブとタブの組み合わせが複雑すぎますか？その場合は、上記の最初の段落をもう一度読んで、反復する準備をしてください。
個人的な注意として、私が取り組んでいる複雑なプロジェクトには、ネストされたナビゲーションを含むプロトタイプがすぐに機能します。ユーザーがどのように機能するかを確認するために、ユーザーとのテストを楽しみにしています。今から1か月後、実際のユーザーでデザインをテストし、ユーザーテストで重大な問題が明らかになった場合はデザインを適応させます。
これは調査を必要としないはずです。少なくともグラフィカルな方法では、タブをタブの下に置くことは間違いなく混乱しています。タブロジックを使用できますが、タブの外観はありません。一番気になるのは、「ステップ」という単語が表示されているので、最初の意図が、ユーザーがタブを介して構成/設定の手順を実行するように導いているかどうかを疑問に思います。その場合は、ウィザードを使用することを強くお勧めします。
それは常にそれらがどのようにレンダリングされるかに依存します。これをチェックしてください alt text http://www.ubuntu-pics.de/bild/54446/screenshot_017_69kTK2.png 。それらはどこにでも存在しますが、その下のタブの存在には影響を与えないでしょう。
あなたの例では、タブが互いに近すぎたため、各「母」タブには別のタブのグループしか含まれていないように見えました。それはぎこちなく見えます。
Charisの言ったように、タブの外観なしでタブロジックを実行できます。私は、タブロジックをタブロジック内で使用するべきではないと言う研究は存在しないと思います。 UXExchageを含め、ほとんどのサイトがこれを行っています。この問題は、物事が視覚的にレンダリングされる方法に関するものです。
この場合、タブの代わりにステップを示す矢印を使用できます。
複雑なイントラネットアプリケーションのタブ内でタブを1回使用しましたが、メインナビゲーションには水平タブを使用し、サブナビゲーションにはファイルやフォルダーのような垂直タブを使用し、明確な色分けを行いました。
残念ながら、表示する画像はありませんが、ターゲットユーザー（政府部門）が簡単に認識できると考え、ユーザーテストでその仮定が明らかになったため、「フォルダー」というメタファーを非常に厳密に追跡しました。
お役に立てば幸いです。
私はCharisと一緒です-ネストされたタブは絶対に避けてください。モックアップでは、ユーザーが線形のステップバイステッププロセス、そしてウィザードまたは進行状況バー（例 http://developer.yahoo.com /ypatterns/navigation/bar/progress.html ）の方が適切でしょうか？