TablePage: regular→long の動線が非自明

[iilj]

問題の概要

• 現状，7問以上構成の yukicoder contest XXX が開催されると， yukicoder contest (long) タブ内に表示する仕様としているが，この仕様がわかりづらいとの声がある

問題の詳細・原因

• TablePage を開いたユーザは， YukicoderRegularTable に yukicoder contest の全問題が含まれていることを期待する可能性がある
  • 一部コンテストが別タブに移動していることの説明が特にないことも一因
  • 特に7問以上構成の yukicoder contest 終了直後，最新のコンテストが YukicoderRegularTable に含まれない（longタブ内に表示している）状態になるので，戸惑うユーザもいる
• Writer/Tester 目線では，問題が YukicoderRegularTable に表示されたほうが動線の確保が容易で好ましいと考えられる
• タブを操作して (long) タブへ移動する動線が頼りないのは，各タブ内のコンテンツ量の差も手伝っているかもしれない
  • AtCoder Problems では ABC/ARC/AGC/... と多くのタブを用意しているが，その動線は問題となっていない．ユーザは「AGCの問題を見よう」というように目的を持ってタブを移動すると考えられる．
  • (regular) タブから (long) タブへの移動は，上述の例ほど明確な目的を持って行われるとは考えづらい
• 今後，仮に7問以上構成のコンテスト割合が増えれば，コンテンツ量の相対的な差は小さくなる
  • ...ので，その時になって (long) タブが市民権を得るまで，この問題を保留するという選択肢もある

[iilj]

対応案

long タブへの動線の確保というよりは，A~F問題へリーチしやすくする点に主眼を置いた対応案が中心．

6問目までは YukicoderRegularTable に入れ，余りは別表とする

• 対応内容
  • 脱葉さんはTwitterを使っています 「@iiljj 前話したyukicoder problemsの件ですが，純粋にA~Fは全て纏めてtab1において，G~以降の問題が存在する場合はtab2にG~以降だけ置くというのはどうですか」 / Twitter
  • G以降がある場合には別テーブルへの動線を作ることも考える
    • 「<」「>」ボタンをフロートさせるか，ボタンをテーブルに統合するなどして実現する
• 利点：7問以上構成でもFまでの問題へリーチしやすくなる，ボタンをフロートさせるだけであれば実装は容易
• 欠点：同一コンテストの問題が複数テーブルに分断されるため，意味的におかしなことになる，テーブル側の実装がハード

テーブルを横スクロール可能にする

• 利点：対応が容易，標準コンポーネントのみで対応可能
• 欠点：画面幅が微妙に狭い非モバイル端末においてUIが不細工になりユーザビリティにも問題が生じる，8問目以上へ辿り着くためのスクロール量が多い，table data 領域右側に大量の空白領域ができる

G問題以降を折り返して表示する

• 利点：1つのテーブルを見るだけで yukicoder contest 全ての問題にリーチ可能
• 欠点：折り返しつつG以降であるとわかるように表示するためには，コンポーネントの標準的な使用法から外れる必要があり，実装がややハード

よりよりタブ名称を考える

• 対応内容：yukicoder contest (long) のようなタブ名称を，よりわかりやすくアクセスしやすいものに変更する
  • これにより，ユーザの動線の問題が解消することを期待する
• 利点：名称さえ決まれば対応が容易
• 欠点：よい名称が思い浮かばない

何らかの註記を表示する

• 対応内容：一部の問題が YukicoderRegularTable に含まれないこと・別タブ内に表示されることを伝える内容のテキストを表示する
• 利点：対応が容易
• 欠点：メインのテーブルの手前に置くことになるので見た目がくどくなる，そもそも註記がなくても自然に使えるページ構成を考えるべき

[iilj]

補足

• 現在，7問以上構成の yukicoder contest を別タブで切り出している理由
  • yukicoder contest 57 が10問構成であり，通常のテーブルに収めるには問題数が多すぎた
    • yukicoder problems 開発開始当時，ほかに yukicoder contest 220 (7問構成) があり，その他の yukicoder contest は全て6問以下構成だった
  • tab1 に10問無理やり表示するという構成のテーブルを開発初期に作ってみたが，文字を小さくする等したとしても，デザイン的にかなり無理があったため，この案は没になった
  • その結果，実装の選択肢として次の2つが残った
    1. G問題までtab1に表示し，10問構成コンのみtab2とする
    2. F問題までtab1に表示し，7問以上構成コンをtab2とする
  • 最終的には，tab2 にコンテストが1つだけ浮いてしまうのはバランスが悪い点，tab1 内のテーブルのデザイン上の優位性（G列がほとんど用いられないにもかかわらず，一定の画面幅を占有し続けてしまう）といった理由から，7問以上を別タブとする案を採った．

[iilj]

関連 issue として #128 を生やしました．
7問構成のコンテストの増加に伴い，通常テーブルに7問まで詰めたほうがユーザには優しそうな状況になってきたので，変更を加えるつもりです．