バージョン管理: Figmaの横スクロールの実現に向けた3つの試み

レイヤーパネルへの横スクロールの追加は、UI3に採用される前、しばらくの間ユーザーから寄せられていたリクエストでした。ネストされたフレームが表示範囲外に押し出された場合、スクロールバーで表示範囲に戻す必要があります。簡単そうですが、実はそうでもありません。Figmaでプロダクトデザイナーを務めるGiorgio Cavigliaは次のように述べています。「簡単に解決できそうに思えたのですが、デザイン、エンジニアリング、コラボレーションの観点から、非常に興味深い課題が生まれました」

まず、Giorgioによればレイヤーパネルは「非常に実用的」です。「常時使用するため、高い信頼性が求められるという点で、扱いが難しい部分です」さらに、このパネルは単なる親要素と子要素の静的リストではありません。「それらは生きもののようなものです」と彼は言います。「レイヤーを非表示にし、ロックし、折りたたみ、展開できます。そうした要素は、スクロールするとどうなるでしょうか?」仮想化によって難易度はさらに上がっていました。パフォーマンスを高めるために、現在表示されているレイヤーのみがレンダリングされる仕組みだったのです。パネルを上下にスクロールすると、別のレイヤーが表示されますが、レイヤーによってテキストの長さが異なることで、横スクロールに問題が生じます。こうした要因によって、ユーザーが階層構造を理解し、まだスクロールできるとわかるようにする、という最終的な目標の達成が難しくなります。

この複雑な問題を解消するために、GiorgioはソフトウェアエンジニアのAmy ShanとGrant Phelpsが率いる開発チームとともに、スムーズかつ直感的な操作感を実現するさまざまな試行錯誤を重ねました。ここでは、リリースには至らなかった3つの試みと、その過程で学んだことを3人に紹介してもらいます。

バージョン1: 表示範囲外の左側の挙動

Giorgioはすぐにコードによるプロトタイピングを作成し、JavaScript、HTML、CSS、Reactを使用して、各アプローチがどのようなものになるかを確認しました。Giorgioは次のように述べます。「コードでプロトタイプを作成するのが好きなんです。デザインとエンジニアリングの優れた点を両方活用できますから」と彼は言います。「コードベースの制約内で作業しつつも、デザインの細部や見た目にこだわることに集中できます」特にスクロールのような動的機能の場合は、実際に手を動かして試してみることに意味があります。Giorgioは続けます。「無数のレイヤー、複数のスクロール方向、複雑なインタラクションを扱う場合は、どのように動作するかを実際に確認する必要があります。静的なデザイン作業では、あらゆる状況を予測できません」

横スクロールによって生まれた疑問に、ユーザーがネストされたノードを深くスクロールしたときに生じる余白をどうすべきかというものがありました。あるバージョンでは、レイヤーがパネルの左上から右下に移動する際に、対称的に見せる処理を試みました。レイヤーが画面外に押し出されると、レイヤーがある側にアイコンが表示されます。Giorgioは次のように述べます。「対称的なデザインの上下にフレームアイコンを表示すれば、ユーザーが自分がレイヤー階層のどこにいるかを把握できると考えました」

しかし、このアイデアはエンジニアリング的に難しいことが判明しました。アイコンをパネルの端に固定するよう変更するのは簡単でしたが、スクロール中にレイヤー名のテキストを隠すために不透明な背景が必要ですが、これがレイヤー行の構造と干渉してしまいました。Amyは次のように述べます。「横スクロール中に起こるさまざまな場面で、背景は一部のレイヤー要素の下に表示されつつ、他のレイヤーの一部を隠します。ただし、このスタイルを設定したコンポーネントが、上に重ねられた要素の位置を正確に把握しなければ、実現するのは困難です」

また、デザイン的にも理想的とは言えませんでした。右にスクロールすると、左上寄せで表示されたレイヤー名のテキストの末尾がきれいに揃いません。Giorgioは次のように述べます。「多くの方が、対称的なデザインにこだわりますが、これはあくまで理想で、現実には多くの場合、皆さんが思っているよりも複雑です。これは、解決策が新たな問題を呼ぶ典型例です。何より、この試行錯誤がきっかけになって、表示レイヤー上の余白に取り組むことができました」

バージョン2: 選択したレイヤーへの自動スクロール

次に、自動スクロールの挙動をプロトタイプとして作成しました。ユーザーがキャンバス上で選択したレイヤーが、レイヤーパネルでは見えない場合、スクロールバーが自動的にそのレイヤーを移動して、パネルの中央に表示します。この挙動に理論的な問題はありませんでしたが、実際には混乱を招きました。ある社内テスターは次のように述べています。「ネスト構造の下の方をクリックするとレイヤーツリーが水平方向と垂直方向に同時にスクロールするため、非常に違和感がありました。また、クリックしたとたん、親アイテムとの関係がまったくわからなくなりました。

Giorgioは、これをGoogleマップを見ながら運転するのに似ていると述べます。地図が突然別の場所に飛んでしまったら、どこに行けばいいのかわからなくなります。Giorgioは次のように指摘します。「デザイナーにとって、作業中のレイヤーが、階層のどの位置にあるのか、名前はなにか、親コンポーネントの一部かどうかを正確に把握することは非常に重要です。レイヤーパネルは、デザイナーが作り出したメンタルモデルの反映です。レイヤーパネルで迷子になると、デザイナーは自分に確信が持てなくなります。ユーザーが望むのは自分を助けてくれるツールであり、その逆ではありません」

バージョン3: レイヤー名の変更

また、横スクロールの導入により、レイヤー名の変更に関する問題も新たに生まれました。あるレイヤーをクリックしてテキストボックスを編集し、次に別のレイヤーにスクロールした場合、入力したテキストを新しいレイヤー名に設定する方法だと、ユーザーが意図せずに名前を変更してしまう可能性がありました。Giorgioは次のように述べます。「スクロールは、変更を確定するシグナルとしては弱いと感じました」

代わりに、ユーザーがスクロールすると右側に拡大するテキストボックスを試しましたが、画面端でボックスの表示が不安定になり、UIとして問題がありました。Grantは次のように述べます。「基本的に、要素のサイズ変更にJavaScriptを使用していたため、パネルサイズを水平方向に変更する際に生じる描画の遅延を回避する方法がありませんでした。左端を基準にサイズを変更すると右側が不安定になり、右端を基準にサイズを変更すると左側が不安定になります」ユーザーエクスペリエンスとして問題があるだけでなく、ユーザーが入力を続けた場合、テキストを表示領域に収めるために、スクロールバーが突然元の位置に戻る場合があります。自動スクロールを試した経験からも、許容できないと判断しました。

最終バージョン: 適切なバランスを見つける

最終的に、こうした試行錯誤を通じて、表示されているレイヤーの上部の余白は、レイヤーパネルの下部の余白にあわせて完全に余白として残し、レイヤー名はスクロールする前にユーザーが編集していたとしても単純にリセットするという、重要な決定を下しました。

自動スクロールの問題に対処するためには、表示範囲外のレイヤーが選択された場合にどのタイミングで、またどの程度スクロールバーを調整するかを決定するヒューリスティックを開発しました。たとえば、レイヤーアイコンとテキストの長さが、レイヤーパネルの左端から50ピクセル以上はみ出した場合、スクロールバーは追加のコンテキストが表示されるとともに、デザイナーの作業フローの妨げにならない程度に左側にシフトします。ただし、仮想化に特有の技術的な課題も生まれました。ユーザーがレンダリングされていないレイヤーをクリックした場合に、テキストの長さに関する情報がないと、レイヤー内のアイテムを整列させるためにどの程度自動スクロールすればよいかがわかりません。Amyは次のように述べます。「Grantと私は行を移動する前に、非表示のままレンダリングする方法を見つけました。レンダリングした行のサイズを測定して、自動スクロールに使用すれば、完全に整列させられます。

プロトタイプを作成し、複数のバージョンをテストしたおかげで、自動化すべき機能、ユーザーの操作に任せる機能、あえて単純なままにすべき機能を見極めることができました。Giorgioは次のように述べます。「機能を複雑にしすぎず、技術的な制約を考慮して動作が遅くならないようにすることが非常に重要です。退化ではなく、進化したと感じてもらえる製品を開発する必要がありました。今日、スクロールバーの挙動は理に適ったものとなっています。しかし、ほとんどの場合そうですが、そうしたシームレスな挙動は、膨大な試行錯誤とプロトタイプ作成の結果なのです。Giorgioは次のように指摘します。「ちょうど良いと感じられるソリューションは、最初からちょうど良かったわけではありません。それはしばしば、狂気のような試行錯誤から生まれるのです」

4月30日にUI2の提供を終了し、UI3に移行いたします。このたびの変更の理由と、できるだけスムーズな移行方法について詳しいご説明をご覧ください。