WAVE / WAVEの16ステップは、なぜ横スクロールにしたのか

確認できているのは「狭い画面では横スクロール」という一点

WAVE / WAVEは、4つの音を16ステップに並べてループ再生するリズムスタジオです。パッド演奏の録音、テンポ、スウィング、トラックごとのミュート、3つのお手本、取り消しがあります。保存にも対応しています。狭い画面ではステップが横スクロールになります。

この説明から言えることは次の3点です。

• ステップ数は16のままで、画面に合わせて減らしてはいません。
• 画面が狭いときの対処として、縮小や折り返しではなく横方向の移動が選ばれています。
• 広い画面では、この横スクロールが必須ではないと読めます。

一方、次の点は確認できていません。横スクロール中にトラック名やミュートの操作が左端に固定されるのか。再生中に再生位置が自動で追いかけてくるのか。何px以下の幅から横スクロールに切り替わるのか。これらは作品を開いて確かめる部分です。

40pxで並べると、16ステップは何px要るか

物差しとして「マス1つが40px四方以上」を置くと、必要な幅は単純な掛け算で出ます。マスの間に4pxの隙間を入れると、次のとおりです。

• 16個を1列、計算：16×40 + 15×4、必要な幅：700px
• 8個ずつ2段、計算：8×40 + 7×4、必要な幅：348px
• 4個ずつ4段、計算：4×40 + 3×4、必要な幅：172px

ここで幅が400px前後の画面を考えてみます。トラック名やミュートの欄が左に付くと、実際にマスへ使える幅はさらに減ります。16個を1列に置けば700pxが必要なので、画面に入るのは9個ほどです。つまり40pxを守る限り、1列では収まりません。この算数が、「縮めるか、流すか」という二択の背景にあります。

縮める・折り返す・減らす・流す

16ステップを狭い画面で扱う方法は、大きく4つ考えられます。どれが選ばれたかは確認済みですが、他の3つは比較のための仮定です。

• 縮めて全部見せる、守られるもの：16ステップの一覧性、失われるもの：マスの押しやすさ。隣のマスを誤って押しやすくなる
• 8個ずつ折り返す、守られるもの：画面内の一覧性と押しやすさ、失われるもの：1本のループとして左から右へ読む感覚。行が倍になり縦に長くなる
• ステップ数を減らす、守られるもの：画面内の一覧性と押しやすさ、失われるもの：16ステップという仕様そのもの
• 横に流す（採用）、守られるもの：ステップ数と押しやすさ、失われるもの：一度に全体が見えること

折り返しは、ループが1周する様子を目で追うときに不利になります。1段目の終わりから2段目の頭へ視線が飛ぶので、「次に鳴る位置」を追う作業が増えます。ステップ数を減らすと、16ステップで作れるリズムの幅が狭まり、お手本のパターンも成り立たなくなる可能性があります。縮める方法は、押し間違いが増える代わりに全体が見えるという交換です。

横スクロールは、この中で「一度に見える範囲」だけを手放す方法です。設計から読み取れるのは、16ステップという中身と、指で確実に押せる大きさを優先し、全体を一望する便利さを後回しにした、という順番です。なお、リズムの入力画面は「押す」回数が多い画面なので、押し間違いが積み重なる縮小よりも、移動の手間のほうが許容されやすい、という見方もできます。これは仮説であり、作者の意図として断定はできません。

自分の端末で確かめる手順

手放したものがどのくらいの重さなのかは、自分の画面で測ると判断できます。まずWAVE / WAVEを開いて、次の項目を記録します。

1. 画面の幅を、ブラウザの開発者ツールの端末表示などで3段階（狭い・中くらい・広い）に切り替えます。
2. 各幅で、一度に見えているステップの個数を数えます。
3. 各幅で、マス1つの縦横を測ります。開発者ツールで要素を選び、表示される寸法を読みます。サイトのプレイ画面は別オリジンのiframeの中なので、iframe内の要素を選べるかどうかも確認してください。
4. 横スクロール中に、トラック名やミュートの操作が見えたままかを確認します。
5. 再生を始めて、再生位置が画面外に出たときの様子を見ます。
6. OSの「動きを抑える」設定を切り替えて、スクロールや表示の違いを見ます。

測りにくい場合は、次の最小の試作で「40pxで16個を並べる」感覚を先に体験できます。これはWAVE / WAVEのコードではなく、比較用の最小構成です。HTMLファイルとして保存してスマートフォンで開いてください。

<!doctype html>
<meta name="viewport" content="width=device-width,initial-scale=1">
<style>
 .scroll{overflow-x:auto;border:1px solid #888;padding:4px}
 .row{display:flex;gap:4px;margin-bottom:4px;width:max-content}
 .row button{width:40px;height:40px;flex:none}
 .row button.on{background:#2a7}
</style>
<div class="scroll" id="grid"></div>
<script>
const grid=document.getElementById('grid');
for(let t=0;t<4;t++){
 const row=document.createElement('div');row.className='row';
 for(let s=0;s<16;s++){
  const b=document.createElement('button');
  b.setAttribute('aria-label','トラック'+(t+1)+' ステップ'+(s+1));
  b.onclick=()=>b.classList.toggle('on');
  row.appendChild(b);
 }
 grid.appendChild(row);
}
</script>

試作では、width:40px;height:40px を 28px に変えると、全体が見やすくなる代わりに押しにくくなる様子を比べられます。.scroll の overflow-x:auto を外して .row の幅を画面に合わせると、縮小案も試せます。

結果の読み方と、起こりやすい誤り

測った結果は、次のように読みます。

• 狭い幅でもマスの縦横が同じ大きさのまま、見える個数だけが減るなら、「大きさを固定して範囲を流す」設計だと読めます。
• 幅によってマスの寸法が変わるなら、一定幅までは縮めて、それ以下で横スクロールに切り替える設計の可能性があります。
• トラック名やミュートが画面から消えるなら、手放したものは「一覧性」に加えて「今どの行を触っているか」という手がかりです。固定されていれば、横スクロールの弱点を補っていると読めます。
• 再生位置が追従せず画面外に出るなら、見えない範囲を鳴らす場面で戸惑いやすくなります。追従するなら、それを補う工夫と読めます。

起こりやすい誤りもあります。

• 開発者ツールの端末表示と実機は、指の太さも画面の密度も違います。寸法の数値はツールで読めますが、「押しやすいか」は実機で試してください。
• ブラウザやページ全体を拡大していると、同じ画面でも見える個数が変わります。プレイ画面の拡大を使った場合は、拡大前後で別々に記録してください。
• 1回の確認で結論を出さないでください。幅ごとに2〜3回ずつ、同じ手順で測ると、偶然の違いと設計の違いを分けやすくなります。
• ここで得られるのは「読み取れること」であり、作者の意図の証明ではありません。

次の行動

WAVE / WAVEを狭い画面で開き、見えるステップの個数とマスの寸法を、3つの幅で書き出してみてください。そのうえで試作の 40px を変えて、「押しやすさ」と「見渡しやすさ」のどちらを残したいかを自分で決めてみてください。自分のゲームに16個以上並ぶ操作がある場合は、この比較表をそのまま設計の判断材料にできます。