- Gnome Filesを実際のファイル整理に使う過程で、表示切り替え、パス入力、ヘルプ、ツールチップ、ウィンドウ移動といった基本操作がユーザーを混乱させるという批判
- 「View Options」ドロップダウンは実際には並べ替えオプションを表示しており、表示切り替えはsplit buttonの別の領域に隠れていて、名前と機能配置が食い違っている
- パス表示バーはテキスト入力のように見えるが、マウスでは編集できず、Ctrl-Lショートカットでのみ有効化されるため、GUI機能としての発見可能性が低い
- タイトルバーをなくした上部領域では、ボタンクリック、ウィンドウドラッグ、コンテキストメニューが重なって動作し、隠れたスクロールバーもポインターを載せると位置が動いて基本操作を不確実にしている
- 新しいUIパラダイムは、従来のメニューバー、タイトルバー、一貫したショートカット表示といった実証済みのパターンより良い結果を出せておらず、古い方式が自動的に悪いわけではない
Gnome Filesを選んだ理由と前提
- 批判の焦点はフラットデザインそのものではなく、中核的なプログラム機能へアクセスする方法にある
- 初心者にとって現代的デザインが親しみやすい可能性は認めつつも、1日に何時間もコンピューターを使うパワーユーザーも設計対象に含めるべきだとしている
- インターフェースが多くの機能を隠すほど、ユーザーは機能を発見し学習する機会を失いやすい
- Gnomeは主要なLinuxディストリビューションの標準デスクトップ環境であることが多く、「usable by everyone」「structurally and aesthetically elegant」「distraction free」「traditional desktop is dead」といった方向性を公に掲げている
- Gnome Filesはデスクトップ環境の中心要素であるファイルマネージャーであり、GnomeのUI哲学を確認するうえで重要な事例である
リスト表示切り替えで露呈したメニュー構造の問題
- 第一印象はすっきりして落ち着いており、クリック可能な要素もある程度区別できると評価されている
- 大きなアイコンではなくリスト表示に切り替えようとする過程で問題が始まる
- ツールバーには互いによく似たアイコンがあり、「View Options」ツールチップ付きのドロップダウンは表示オプションではなく、複数の並べ替えオプションを見せている
- 実際の表示関連オプションである「Icon Size」と「Show Hidden Files」は「Main Menu」にあり、「View Options」という名前と実際の構成が食い違っている
- リスト表示切り替えは「View Options」ドロップダウンの一部ではなく、split buttonのトグル領域にある
- ドロップダウンにトグル機能が一緒に並んでおらず、同じウィジェットにまとめられている理由が不明確
- この構造のせいでリスト表示トグルを見つけるのに時間がかかり、構造的な優雅さよりも苛立ちを与える
ヘルプとツールチップの発見可能性の問題
- 組み込みヘルプで「list view」を検索しても、リスト表示を有効にする方法をすぐには見つけにくい
- Gnome Filesのメニューからヘルプを開いても、検索結果には他のアプリケーション関連項目も一緒に表示される
- 「Browse files and folders」はGnome Filesに関係していたが、「Manage volumes and partitions」「Edit contact details」などの項目の後ろに出てくる
- 直接ヘルプを見て回って見つけた「List View」関連項目は、すでにリスト表示を選んだ後にできる操作を扱っていた
- ツールチップは有用になり得るが、Gnome HelpとGnome Filesでは不要なツールチップがむしろ邪魔になっている
- Gnome Helpでは、項目タイトルと同じテキストのツールチップが次の項目タイトルを隠す
- Gnome Files左サイドバーの「Recent」「Starred」といった項目にも自明なツールチップが表示される
- こうした挙動は、ユーザーにツールチップを有用な情報ではなく邪魔なものだと学習させかねない
パス移動とショートカット中心の機能露出
- Gnome Filesのナビゲーション自体はおおむね問題ないが、親ディレクトリへ移動するparent directoryボタンがないのは惜しい
- 戻る/進むボタンはナビゲーション履歴を移動するだけで、親フォルダーへの移動とは同じではない
- 位置表示バーのディレクトリ名をクリックして移動することはできるが、親フォルダーボタンより誤クリックしやすく、便利さでも劣る
- 位置表示バーはテキストボックスのように見えるのに、マウスでは通常の編集モードを有効化できない
- 編集モードはCtrl-Lショートカットでのみ有効化されるようだ
- 機能が実装されていないと思っていたが、検索して初めて分かり、Keyboard Shortcutsウィンドウにはこのショートカットが載っている
- GUI要素がマウスでアクセスできないと、発見可能性は下がる
ショートカットウィンドウとメニューバー代替の限界
- ショートカット一覧は3ページあり検索機能もあるが、何を探すべきか分からないと使いにくい
- Gnome Helpは位置表示バーを「path bar」と呼ぶが、ショートカットウィンドウで「path」を検索しても結果は出ない
- ショートカット一覧には目次やカテゴリを素早く見渡す手段がなく、ページを1つずつ確認しなければならない
- Keyboard Shortcutsウィンドウを開くショートカットもあるが、一部の他のショートカットと違って、Main Menuの該当項目の横には表示されない
- 伝統的なメニューバーはプログラム機能をカテゴリ化して常に見えるようにし、ショートカットを一貫して表示し、見つけたオプションを即座に実行できる
- Gnome Filesでは機能がUIのあちこちに散らばっており、一部の隠れた機能はモーダルなショートカットウィンドウを通じてしか学べない
- ショートカットウィンドウは非対話的でモーダルなため、開いたまま試すことができない
- ユーザーはショートカットを探し、覚え、ウィンドウを閉じたあとで機能を実行しなければならない
- マウス中心の環境で、GUIから機能を見つけて実行する方法がないのは制約が大きく、混乱を招く
タイトルバーのない上部UIの曖昧さ
- Gnome Filesには実際のタイトルバーがなく、ウィンドウ上部領域をクリックしてドラッグすることでウィンドウを移動する
- この上部領域にはツールバーもあるため、すでに機能を持つUIコントロールをクリックした状態でもウィンドウを動かせる
- 検索アイコンをクリックして検索を開くこともでき、同じアイコンをクリックしたままドラッグしてウィンドウを動かすこともできる
- 戻る/進むボタンはコンテキストクリックやlong clickで位置履歴を開けるが、ボタン自体からはその機能が分からない
- この機能にはショートカットもないようだ
- 他の項目でlong clickしてもコンテキストメニューは開かず、動作に一貫性がない
- ウィンドウを前面に出すには、プログラム機能に触れない非クリック領域を探さなければならない
- 検索実行、パス移動、表示切り替え、他機能へのアクセスといった誤操作を避ける必要がある
- 単なるウィンドウのアクティブ化にもユーザーが注意を払う必要があり、認知負荷が増える
- 上部領域を右クリックすると、位置に応じてウィンドウ管理メニューまたはディレクトリ操作メニューが出てきて、現在のディレクトリやクリック位置によって結果が変わる
- 中クリックでは現在のディレクトリを含むディレクトリ名を新しいタブで開くことができ、この機能はコンテキストメニューにもある
隠れたスクロールバーとデフォルトテーマの挙動
- Gnome FilesまたはGTK 4は隠れたスクロールバーを使っている
- デフォルト設定とDebianが提供したデフォルトGTK 4テーマで確認した挙動である
- 隠れたスクロールバーは操作可能性だけでなく、ファイル一覧や文書内で現在どこにいるかを示す情報も隠してしまう
- マウスを動かすとスクロールバーは現れるが、小さくコントラストも低いため見づらいと感じられる
- ポインターをスクロールバーに載せるとスクロールバーが大きくなって見やすくなるが、元の幅のぶんだけ左へ移動するため、ポインターがもはやスクロールバーの上に乗っていない状態になる
総合評価と結論
- Gnome FilesのUIはhaphazardでincoherentであり、ときには危険にすら感じられると評価されている
- 主な問題は次のとおり
- メニュー名と内容が一致せず、実際の表示オプションが複数箇所に分散している
- ショートカットがメニューに一貫して表示されない
- 一部の一般的な機能がショートカットでしかアクセス・発見できない
- ウィジェットの見た目が動作を正確に予告していない
- ツールチップが誤解を招くか、情報価値がないまま邪魔になる
- 機能アイコンをクリックしてウィンドウを動かす方式が誤クリックの危険を生む
- 上部領域でのコンテキストクリック結果が予測しにくい
- デフォルトテーマのスクロールバーはポインターを載せると位置が動く
- ヘルプと実際のGUIで用語が食い違っている
- こうした不一致は、ユーザーがUIについて安定したmental modelを作ることを難しくする
- 機能面ではGnome Filesでファイル管理はでき、他に選択肢がなければUI特性に慣れることもあるかもしれない
- しかし、Gnome Filesのような中核アプリケーションにも、UI設計の観点から悪いと見なせる要素が多い
- 古いデスクトップパラダイムや、すべての既存プログラムが完璧だったという意味ではないが、新しいパラダイムはより良い結果を生むべきだという問題意識が残る
- 批判された問題の大半には、すでに数十年かけて磨かれてきた解決策がある
- 実際のウィンドウタイトルバー
- メニューにショートカットを一貫して表示する方式
- メニューとオプションの一貫したカテゴリ化
- より豊かなデザイン言語
- 古い方式が自動的に悪いわけではなく、新しい方式が自動的に優れているわけでもない
1件のコメント
Hacker Newsでの意見
Filesのリスト表示で新規ドキュメントの作成や貼り付けをしようとすると、空白部分の右クリックだけが許される問題を思い出す
リスト表示ではファイルが少し増えてウィンドウがいっぱいになると、クリックできる空白部分がなくなる
以前にも同じ問題を経験した人たちがいて 0、今もきちんと直っていないようだ 1
調べてみるとThunarでは、
Ctrlを押しながらどこでも右クリックすると、新規フォルダー作成、貼り付け、端末で開く、といったメニューが出るただしファイルが選択されている状態では選択項目のコンテキストメニューが出て、新規フォルダーのオプションは表示されないため、結局は空白部分をクリックして選択を解除するか、
Escapeを知っている必要があり、理想的ではない記事タイル全体、リンクテキスト、画像、広い余白まですべてリンクになっていて、タイル間の細い隙間だけが背景としてクリックできる
タッチ優先設計なら理解できるが、GNOMEのようなデスクトップソフトウェアでも、複数の入力方式を同時に満たそうとして似たような目標が入り込んだように見える
リンク先のIssueには右クリック可能領域を示す画像がある
https://gitlab.gnome.org/-/project/1/uploads/50ac36ab40f9049f4a823f77aa9a8a29/gr-files-right-click-zones.jpg
そのため上位フォルダーへ上がっていき、いっぱいになっていないフォルダーを見つけたらそこでTerminalを開き、また
cdで元のフォルダーまで戻るコンテキストメニューは、右クリックしたオブジェクトに適用できる操作を示すべきであり、「新規ドキュメント」はファイルやフォルダーアイコンの機能ではない
フォルダーを右クリックしたとき、新規ドキュメントを現在のフォルダーに作るのか、クリックしたフォルダーの中に作るのかも曖昧だ
こうした共通操作は、空白部分の右クリックによるコンテキストメニューとは別に、常に表示されるアイコンバーのメニュー項目に置くほうがよい
もっともな批判だが、デザイン言語と細部の作り込み不足から来るUIの引っかかりを混ぜて扱っている
現在のmacOS Finderを見ると、GNOME Filesとデザインがとてもよく似ている: https://a.qoid.us/20240907-finder.png
そのため、ウィンドウをドラッグしにくい、ウィンドウをクリックしてアクティブにしにくいといったデザイン自体の欠点はFinderにもある
ただしmacOSは、筆者が指摘した細かな問題の大半を避けている
表示オプションには似たアイコンがあるが、Finderではアイコン右側の小さな矢印も常に同じボタンの一部であり、筆者が不満を述べたような分割ボタンは使っていない
ヘルプについては、macOS User Guideがアイコンの意味を説明しており、Helpで入力すると全メニューの項目を検索して表示してくれる
「list」と打つと「as List」というメニュー項目が出て、望む操作を実行できる
ツールチップは左側の場所一覧にはなく、ツールバーアイコンにだけあり、それも遅れて表示される
ナビゲーションについては、Finderには事実上ロケーションバーがなく、パスで開くダイアログも隠れており、親フォルダーへ移動する操作も目立たない
それでも、編集できそうに見えるのに編集できない要素はない
スクロールバーはデフォルトで隠れているがウィンドウ右側にとどまり、筆者が不満を述べたように左へ飛び出すことはない
信じがたいなら、マウスのあるデバイスで https://macos9.app を開き、ファイルの整理とブラウズをしてみればよい
いつもNeXTStepから雑に移植したあと、すぐ放置されたように感じていた
全体としてAppleはこの10年ほどでUIの感覚を失っており、macOSをもはや優れたデスクトップUIの例として使うべきではない
有効にできるメニュー項目がある
Appleが自社OSを最も人間工学的だとマーケティングしているのを信じる人がいるなら笑える
ツリー表示のような場所で新規フォルダーを作ったりファイルを貼り付けたりしようとすると、最上位の親フォルダーに入るという具合で、新規フォルダー作成ですら悪夢だ
最近の日付順ソートも筋が通らない
全体としては新しいものから古いものの順なのに、特定の日付や先週といったグループの中では逆に古いものから新しいものの順に並ぶ
ほかにも、この種のおかしな判断が何百とある
Enterキーでファイルを開く代わりにファイル名編集にしたのも理解しがたいほとんどしない作業に主要キーを使ってしまっているわけだ
GNOME はユーザーが誤って押さないように Power off を追加のサブメニューに隠しているのに、Files では Format を「Safely remove drive」のすぐ隣に置いている
optを押すと終了／再起動の確認なしにダブルクリックですぐ実行できるが、GNOME は 4 回クリックに加えて不自然なアニメーションまであるどちらもタイトルバーにコントロールを詰め込みすぎていて、ウィンドウをドラッグするスペースが残っていない
最近 G4 で OS X 10.5 を 1 週間使ってみたが、あの頃がデスクトップの頂点だった気がする
たとえば USB 大容量記憶装置のメニューで「Eject」と「Format」が並んで表示される
一方は無害だが、もう一方は潜在的に破壊的だ
Format の後ろには
...が付いていて、ダイアログが開くという意味で、そのダイアログは 2 段階の手順になっており、最後にはすべてのデータが永久に削除されるという赤い警告が出る誤ってデバイスをフォーマットする方法はない
すばやく電源を切りたいなら、電源ボタンの動作をスリープではなくシャットダウンに変えればよい
こういう記事が読めてうれしかった
自分も GUI の細かいイライラを徹底的に検証し、もっと良くなるべきだと整理してみたいとよく想像していた
Ctrl+Lは文脈なしに見ると妙なショートカットだが、ブラウザを使う中で 15 年間知っていたキーなので慣れているWindows、GNOME、Nautilus がすべて共有している点は、長く使っているユーザーや上級ユーザーには良い
読み返してみると、不満はショートカットそのものよりも それ以外の方法がない ことに近いのかもしれない
記事で触れられていない大きな問題は、現在の GNOME UI が Windows 11 と非常によく似ている一方で、ツールチップやクリック可能なロケーションバーのような細部をかなり台無しにしている点だ
Ubuntu 14.04 と 20.04 で GNOME を使っていたが、22.04 で安定性の問題が出たため、今は XFCE を満足して使っており、長期的な安定性がいちばんだ
現在はバーをクリックするとすぐ編集モードに入れる
GNOME のアプローチで最悪なのは 傲慢さ かもしれない
ユーザビリティ研究をしていると言い、ユーザビリティに集中していると繰り返すため、個人が使いにくいと感じたときに、かえって二重に苛立つ
「平均的なユーザーは満足しているのだから、問題はあなたにある」というふうに聞こえる
実際に障害があるなら、政治的な理由で UI を合わせる優先順位はもっと高くなるはずだ
ときどき GNOME カルトの奥深くに Mother Gnome というただ一人の人物がいると想像すると笑える
法的に視覚障害があり、物理的にキーボードを使えず、コンピューターユーザーの間で伝統的に過小代表されてきたあらゆる集団に同時に属していて、本人はコンピューターを使ったことがなく、Gen Alpha の曾姪孫から iPhone のいくつかの操作を教わった人、という設定だ
これらすべての要素が合わさって UI 設計の効用怪物となり、どんな代償を払ってでもその人に合わせることが絶対的な道徳命令になる、というわけだ
ディストリビューションのどれかがこの役割を担ってくれるとよいのだが
「モダンなデザインパラダイムが初心者ユーザーに多くの面で優しいという点には同意するが、いつか人は初心者ではなくなる。1 日に何時間もコンピューターを使い、複数のプログラムでさまざまな作業を行う人たちも、設計時に考慮されるべきだ。だから私の批判は、いわゆる上級ユーザーの観点から出ている。また、インターフェースが多くを隠すほど、ユーザーが成長し学ぶ機会をあまり提供しなくなる」
ここまで言っておいて、キーボードショートカットを使わなければならないと不満を言うのは行き過ぎだと思う
しかもその機能は、どうせキーボードが必要な機能だ
上へ移動ボタンがないという不満や、リスト表示への批判も説得力が弱い
スクリーンショットではリストアイコンはすぐ認識できたし、重複する機能ボタンをあちこちに配置しないウィンドウのほうをむしろ好ましく見た
「押しにくい」という主張も変だ
本人は 35 年間コンピューターを使ってきたと言いながら、パスの 1 つをマウスでクリックできないというのは納得しにくい
あるシステムにある程度慣れたあとで自分を 上級ユーザー だと思い、他のすべても同じように動くべきだと期待する典型的な不満のように読める
同じ人たちは、ターミナルで
Ctrl-Cでコピーできないと「標準ショートカット」が壊れていると文句を言いがちだ自分にとって簡単だからといって他人にも簡単なわけではなく、それがユーザビリティ作業の前提だ
上のような技術コミュニティが、人間の認知のごく基本的な点にここまで抵抗するのは信じがたい
むしろそのコメントこそが不満であり、元記事は数十年の研究から得られた実データを適用している
以前書いたもの: https://news.ycombinator.com/item?id=41303387
アイコンがトグルだとは思いもしなかったはずだ
トグルのように描画されていないし、表示オプションは 2 つより多いはずだと期待するからだ
パスを貼り付けることもできる
音声入力のような支援技術を使うこともできるし、スマートフォンのように入力方法はあるが
Ctrlを押す方法がない環境もあるもちろんスマートフォン UI は別の基準で見るべきだ
さらに悪いことに、ターミナルアプリケーションごとにどのショートカットを使うかの一貫性もまったくない
めちゃくちゃで、不満を言うに値する
数年前、元記事と似たようにテキストボックスの削除を批判した記事を読んで初めて知った
そうでなければ、キーボードショートカットでパスのテキストボックスを有効化できることなどまったく知らなかったはずだ
UI は使いやすいだけでなく 発見可能 でなければならない
上級ユーザーでも必要な機能を見つけにくいなら、残りの UI が誰にとっても簡単で発見可能だと、なぜ考えられるのか？
正直に言うと UI はほとんど使わず、普段はターミナルを使っていて、キーボードファームウェアをアップグレードするときだけ Jade のファイルマネージャーを使っている
保存ダイアログは直ったのか？
-s filenameと入力したら、現在のファイルが filename として保存されることを期待する拡張子が付く場合もある
gtk-2 の挙動は、filename を入力し始めるとファイル／ディレクトリ一覧を検索し、
Enterを押すと強調表示された項目を選択する、というものだったいずれにせよ、GNOME をインストールして確認するつもりはない
ファイルブラウザが記事で描写されているほどひどいとしても驚かない
jwz の cadt（cascade of attention deficit teenagers）ソフトウェア工学モデルは、もともと GNOME プロジェクトの振る舞いを説明するためのものだった
なので直っている状態だ
「すっきりした」UIにどうしてそこまでこだわるのか分からない
すべてを隠し、広い余白と特徴のないアイコンに置き換えることが、どうして「落ち着いている」ことになるのか理解できない
空き家や使われていない作業場のように、無菌的で冷たい感じがする
それほど複雑でない選択肢が存在するのは良いことだし、すべてのデスクトップ環境が同じように動作しなければならない理由も分からない
ただ動作し、手を入れる必要がなく、邪魔をしない
GNOME で Files も含めて最悪なのは、gtk3 と gtk4 の
gtkfilechooserwidget.cだfile->openダイアログにファイルパスを貼り付けるとエラーになり、ポップアップが出るバグがあるGtk 開発者たちは、filechooser のコードがあまりにもスパゲッティコードなので、filename-entry location-mode を再びデフォルトの挙動にしたいと思う人がいないと言っている
私も同意する
gtk 3.22 と 3.24 で自分でパッチしようと、1年間断続的に試したが、特定プロセスの最初の
File->Open実行時にしか直せず、その後のオープンではまたエラーが出たGNOME UI と 2014年以降の Gtk は、キーボードを使う人を念頭に置いて書かれていない
それが最大の UI 上の弱点だ
GNOME の多くの痛点の一つで、ずっと以前から GNOME につきまとっている問題だ
しかし GNOME はかなり、もしかすると主にキーボード中心だ
3.0 以降「タッチ優先で作られた」というミームがあるが、そう言った人の中にタッチデバイスで GNOME を実際に使った人はいないだろう
悪夢だ
GNOME の主要な操作は、キーボードショートカットか、より速いキーボード代替手段のある大きなマウスジェスチャによって行われる
これらの不満が間違っているわけではないが、実際にどれほど多くのユーザーがこうした点でつまずいているのかは気になる
リスト表示にしたいときにリストのように見えるアイコンをクリックするのは、変な行動ではない
ドロップダウンの挙動が少し変だという点には同意する
同様に、最近の GNOME アプリではタイトルバーにコントロールが入っているものが多い、というのは受け入れられている状態だ
コントロールを正確にクリックできず、マウスをドラッグし始めるとウィンドウが動くことが、そこまで気になるとは思わない
とはいえ GNOME は「私たちのソフトウェアは誰もが使えるように作られている。私たちはユーザー体験を深く重視している」と言っている
すでに GNOME 批判は非常に多く、私もここでいくつか書いたことがあるので、これ以上言うのは時間の無駄のように感じる
開発者たちは自分たちが実現しようとしているものについて非常に明確なビジョンを持っているので、考えを変えないだろう
ユーザーたちもそのやり方を好み、快適に感じているので、考えを変えないだろう
好きではない人や、もう好きではなくなった人たちも、それを奇妙で混乱しやすく制限的だと感じているため、考えを変えないだろう
この方向に進んでから10年以上になるが、ほとんど変わらないだろう
筆者が言うように、GNOME は「どうあるべきかについて非常に声が大きい、つまり独善的な」プロジェクトだからだ
結局、GNOME 流が好きなら使い、そうでないなら別の場所へ行くしかない
ただしこれは「誰もが使えるように」という標語とはやや矛盾している
独自の装飾とウィンドウデザインを実装し、タブがドラッグ可能なタイトルバー領域の95%を占めるため、ウィンドウを移動しようとしてタブを移動してしまうことが多い
このひどい設計状況で誰が先に引き下がるのか分からないが、その代償を払っているのはユーザーだ
正直、ブラウザが変わるべきだ
GNOME はほとんどの人にとってのデフォルトであり、かなり頑固でもあることを示してきた