1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ブラウザ動画編集ソフトの「使いにくい」を直した話 ― タイムラインUI改善で学んだ設計原則

1
Posted at

はじめに

Timeline Studio は、ブラウザ上で動作するローカルファーストのオープンソース動画編集ソフトです。

プロジェクトを公開したばかりの頃、GitHub Star は80前後でした。WebCodecsによる動画書き出し、複数トラック、字幕、音声、エフェクトなど、技術的に面白い部分はすでにありました。

一方で、実際に触った人からは次のような感想も届きました。

機能は多いけれど、UIが少し使いにくい。
タイムラインの挙動が直感と合わないことがある。

当時の実装を見直すと、その指摘は正しいものでした。

私は「ブラウザで実現できるか」を考えすぎて、「編集している人が次に何を期待するか」を十分に考えられていませんでした。

現在、リポジトリは500 Starを超えています。ただし、今回書き残しておきたいのはStar数ではありません。新しい機能を追加するより先に、既存の「使いにくさ」を一つずつ直した過程です。

機能が存在することと、正しく使えることは別

初期版にもクリップ分割機能はありました。

実装上は、選択中のクリップを再生ヘッド位置で分割するだけです。

selectedClip -> split(selectedClip, playheadTime)

しかし、ユーザーがメイン映像の途中に再生ヘッドを置いて分割ボタンを押しても、クリップを明示的に選択していなければ「先にクリップを選択してください」と表示されていました。

コードの都合としては正しくても、操作としては不自然です。ユーザーは再生ヘッドの位置と画面上の映像によって、すでに十分な意図を伝えています。

現在は次のルールに変更しています。

if 明示的に選択されたクリップがある:
    そのクリップを分割
else:
    再生ヘッド直下のメイン映像を探す
    見つかった映像を選択して分割

ピクチャー・イン・ピクチャーや音声を選択している場合は、その明示的な選択を優先します。何も選択していない場合だけ、最も一般的な対象であるメイン映像を使います。

追加された機能はありません。不要な質問を一つ減らしただけです。

連続ジェスチャーの途中で意味を変えない

動画編集のタイムラインでは、ホイールやトラックパッドに複数の役割があります。

  • トラックの縦スクロール
  • タイムラインの横移動
  • タイムラインのズーム
  • Shift+ホイール
  • Ctrl/Cmd+ホイール
  • ピンチズーム

初期実装では、各wheelイベントが発生するたびに、ポインター直下の要素から操作モードを決めていました。

ところが、タイムライン自体がスクロールすると、固定されたポインターの下に別のクリップが移動してきます。空白領域から縦スクロールを始めたのに、途中でクリップがポインター下に入るとズームへ切り替わる場合がありました。

利用者から見ると、同じ指の動きを続けているのに、ソフトが途中で考えを変えたように見えます。

修正後は、連続するホイール入力を一つのジェスチャーとして扱います。

gestureTarget = 開始時のヒット対象
gestureMode = resolveMode(gestureTarget, modifierKeys)

ジェスチャーが継続している間:
    gestureModeを固定する

短い停止時間の後:
    次のジェスチャーで対象を再判定する

現在の挙動は次の通りです。

  • 空白領域から始めた縦操作はトラックスクロール
  • クリップ上から始めた操作はタイムラインズーム
  • Shift+ホイールは横移動
  • Ctrl/Cmd+ホイールとピンチは明示的なズーム

重要なのは、どのキーに何を割り当てたかではありません。一度始まった身体的な操作の意味を、終了まで変えないことです。

ユーザーが操作しているのはassetIdではなくクリップ

一つの動画を分割すると、複数のタイムラインクリップが同じソースファイルを参照します。

sourceAssetId: video-001

clip A: source 0s - 5s
clip B: source 5s - 12s
clip C: source 12s - 20s

初期の「音声を分離」処理は、sourceAssetIdを強く基準にしていました。そのため、clip Bのコンテキストメニューから音声分離を実行しただけなのに、同じ素材を共有する兄弟クリップまで影響を受ける可能性がありました。

内部データ上では同じ素材でも、ユーザーが操作したのはclip Bだけです。

現在は、クリップスコープの操作として処理しています。

  • 対象クリップのソース範囲だけを抽出する
  • トリムと再生速度を維持する
  • 抽出した音声を音声レーンに配置する
  • ピクチャー・イン・ピクチャーの場合は二重再生を防ぐ
  • 生成された音声を選択し、タイムライン上に表示する
  • 操作されていない兄弟クリップは変更しない

分割されていない元素材をソース音声トラックへドラッグする場合は、素材全体を基準にする意味があります。しかし、クリップの右クリックメニューから実行された処理にまで同じルールを使うべきではありません。

内部IDとユーザーが指定した操作範囲は別物です。

自動配置で既存の編集を壊さない

音声レーンの自動配置にも似た問題がありました。

新しいボイスクリップが既存音声と重なったとき、レイアウトアルゴリズムが既存クリップを別レーンへ移動して重なりを解消することがありました。

結果だけ見れば重なりはなくなります。しかし、ユーザーがすでに整理したクリップの場所まで変わっています。

現在は以下を原則にしています。

  • 既存クリップは元のレーンから動かさない
  • 新しい音声が空いているレーンを探す
  • 必要なら新しい通常音声レーンを作る
  • AI音楽は専用Musicトラックへ配置する
  • 分割後の通常音声は、ユーザー操作でレーン間を移動できる

自動化が解決すべきなのは「新しく追加された要素をどこへ置くか」です。確定済みの編集を勝手にやり直すことではありません。

メイン映像をスクロールで見失わせない

画面、オーバーレイ、字幕、動画原音、ナレーション、音楽が増えると、縦スクロールは避けられません。

すべてのトラックを一緒にスクロールさせると、下の音声を編集している途中でメイン映像トラックが画面外へ消えてしまいます。これでは、最も重要な基準を失います。

現在はメイン映像トラックをルーラー直下に固定し、オーバーレイと下位トラックだけをその下でスクロールさせています。

見た目としては単純ですが、position: stickyだけでは完了しません。

次の処理で同じ座標系を共有する必要があります。

  • ポインターのヒットテスト
  • 素材ドロップ先の判定
  • メイン映像からオーバーレイへの移動
  • オーバーレイからメイン映像への昇格
  • レーンをまたぐドラッグ
  • ドラッグ中の自動スクロール境界

UIを固定したときは、表示位置だけでなく操作判定も同じように更新する必要があります。

モバイル版はPC版を小さくしたものではない

最初のモバイルUIは、PC版のパネルを狭い画面へ押し込んだものでした。

機能自体は残りますが、それぞれの領域が小さくなり、タッチ操作には向きません。

現在のモバイル版は、別の優先順位で構成しています。

  • 上部にプレビューを配置
  • 直下にタイムラインを配置
  • 再生ヘッドを中央へ固定
  • 選択中のクリップに必要な操作だけを表示
  • 詳細プロパティはボトムドロワーへ集約
  • タッチしやすい操作領域を確保
  • PC用キーボードショートカット説明を表示しない

PC版とモバイル版は同じプロジェクトモデルを編集します。しかし、同じモデルを同じ画面構成で見せる必要はありません。

レスポンシブ対応とは、すべてのパネルをすべての画面幅に残すことではなく、ユーザーの作業を残すことだと考えるようになりました。

小さな状態の不一致が信頼を失わせる

今回直したものには、実装だけを見ると小さな修正も多くあります。

  • Exportボタンをもう一度押すと設定ポップオーバーを閉じる
  • アイコンだけのボタンに、現在の言語に対応したツールチップを表示する
  • ロック済みクリップに選択状態のような破線枠を付けない
  • 実行可能な「人物を解析」「物体を解析」は主ボタンとして表示する
  • 解析中の「キャンセル」だけを中立的なスタイルにする
  • 生成音楽や変換音声を勝手にタイムラインへ挿入しない
  • 複数回生成した音声を0秒地点に重ねず、既存ボイスオーバーの末尾へ追加する

どれも新しいモデルや目立つ機能ではありません。

しかし、すべて「次にクリックしたら何が起きるか」を予測できるようにするための修正です。

「ブラウザで動くか」から「人は何を期待するか」へ

開発初期に考えていたのは、ほとんどが技術的な問いでした。

WebCodecsで書き出せるか。
WebGPUで推論できるか。
タイムラインへ新しいトラックを追加できるか。
Agentからプロジェクトを変更できるか。

これらは必要な問いでしたが、技術デモを作る問いでもありました。

エディターが製品らしくなり始めたのは、問いを次のように変えてからです。

この場面で、ユーザーは何が起きると考えるだろうか。

この問いから、余計な確認を減らし、ジェスチャーを安定させ、操作範囲をクリップ単位にし、自動処理を控えめにし、モバイルUIをタッチ中心に組み直しました。

Timeline Studioは現在も開発中です。まだ見つかっていない不自然な挙動もあると思います。

早期版を触って「機能は面白いけれど、操作しにくい」と感じた方がいれば、現在も同じ問題が残っているか、ぜひ率直なフィードバックをいただけるとうれしいです。

特に知りたいのは「新しいAI機能を追加してほしい」だけではありません。

Xになると思って操作したが、実際にはYになった。

こうした報告が、動画編集ソフトを一番前に進めてくれます。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?