- 1994〜2012年ごろのデスクトップGUIは、OSが違っても共通ルールが多く、熟練ユーザーは新しい環境にも素早く適応できたが、最近はその土台が弱まっていると見る
- スマートフォンの小さな画面とタッチ入力に合わせた単一アプリ・パラダイムがデスクトップに持ち込まれ、キーボードと精密なマウスを前提とするマルチウィンドウ利用と衝突している
- Windows 10アプリ、Slack、Chrome、Firefox 75、QT5、Gnomeアプリの事例では、タイトルバーのウィジェット、megabar、自動非表示スクロールバー、消えたメニューバーのように、従来のUI概念を曖昧にする変化が繰り返されている
- ドロップダウンメニュー、明確なタイトルバー、ウィンドウフォーカス表示、識別しやすいボタンや入力フィールドは、プラットフォームを越えて学べる共通言語だったが、アプリごとに異なる動作は別個の学習を要求する
- 画面領域の節約、変化の不可避性、Electronのマルチプラットフォーム上の限界、無料ソフトウェアであることを理由に、実証済みのUI概念を壊すことは正当化しにくく、影響力のあるプロジェクトや企業には一貫性の基準が必要である
デスクトップGUIで弱まった共通ルール
- 1994〜2012年ごろには、合理的なコンピュータ活用能力を持つユーザーなら、ほぼどのOSのGUIの前に座っても素早く適応できた
- Windows、MacOS、CDE、OpenStep、OS/2だけでなく、Amiga、Atari、BeOSのような環境でも、違いより共通点のほうが多かった
- 当時のウィンドウは、おおむねタイトルバーによってドラッグ、識別、現在の入力フォーカス表示を提供していた
- File、Edit、View、Helpのような標準化されたドロップダウンメニューは、新しいアプリの機能探索やショートカット学習を容易にしていた
- ボタン、入力フィールド、そのほかのウィジェットは、3Dベベルのような視覚的手がかりのおかげで、操作可能な要素だと分かりやすかった
- 一部の例外的なアプリはルールに従わなかったが、重要な基本領域では大半のソフトウェアが同じ慣習を共有していた
スマートフォンのパラダイムがデスクトップに持ち込まれた問題
- スマートフォンのような比較的新しいプラットフォームでは、入力方式や画面との相互作用がデスクトップと異なるため、新しいパラダイムが必要になることはありうる
- 問題は、キーボードとピクセル単位のマウス操作が可能なデスクトップに、このパラダイムが広がっている流れである
- フラットデザインと結びつくことで、UI要素はより大きくなる一方、装飾やコンテンツとの区別がつきにくくなる傾向を見せる
- デスクトップアプリケーションのデザインは、複数のアプリやウィンドウを同時に表示できるという前提を弱め、スマートフォン的な単一アプリ利用へと引き寄せられている
- すでに多くのユーザーに筋肉記憶のように定着しているデスクトップUIの慣習を迂回する点が、より大きな不便につながる
ウィンドウ管理: タイトルバーはもはやウィンドウだけの領域ではない
- Windows 10の複数の人気アプリのタイトルバーは、同じコンピュータで数分のうちにキャプチャした画面であるにもかかわらず、一貫性の欠如が際立っている
- 6つのウィンドウはすべてアクティブウィンドウを示しているが、OutlookとSlackは非アクティブ状態とほとんど変わらず、ほかのウィンドウもcmd.exeを除けばアクティブ・非アクティブの差が非常に微妙である
- ほとんどのタイトルバーには、ツールアイコン、タブ、ドロップダウンメニュー、またはその組み合わせが入っている
- ウィンドウ移動、フォーカス、手前への移動といった従来の操作のためのクリック可能領域の幅が、アプリごとに異なる
- タイトルバーをウィンドウ操作領域として学んだユーザーは、意図せずアプリ機能を実行しやすい
- Visual Studio Codeの小さなロゴのように、アイコンに見えても実際には装飾にすぎない要素もある
- 6つのアプリのうち4つがMicrosoft製アプリであることから、このような不規則なデザインが標準のように広まる可能性がある
- Slackの最新バージョンでは、Windows 2時代から可能だった上端の境界線と角のドラッグによるリサイズ領域が大きく縮小している
- 赤い領域は残っているリサイズ・ホットスポット、青い領域はウィンドウ移動ホットスポットを示す
- 残りの空間は非標準ウィジェットの組み合わせが占めている
- 2020年4月22日のアップデートで、Slackのデスクトップ版は非アクティブウィンドウのタイトルバーを少し暗く表示するようになった
ブラウザUI: ツールチップとアドレスバーが従来の概念を揺るがす
- Chromeは、タブにマウスを載せたとき即座に表示される大きなタブツールチップを提供する
- 一般的なブラウザのタブツールチップは、少し遅れて小さなフローティングツールチップとして表示される
- Chromeの新しいツールチップは遅延なしで現れ、下のUIの大きな領域を覆う
- タブツールチップ自体の有用性も議論の対象だが、この形は気が散り不必要な要素として扱われている
- Firefox 75のURLバー変更はmegabarと呼ばれる
- 予測しにくいタイミングで飛び出す
- 消しにくく、下のブックマークツールバーを覆う
- テキスト入力フィールドは少なくとも1980年代初頭から基本概念が維持されてきた古いUI要素だが、megabarはその動作を大きく変えてしまう
スクロールバー: 非表示化と低コントラストが位置把握を難しくする
- 自動非表示スクロールバーは、スマートフォンでは小さな画面領域を確保でき、親指でそのままスクロールできるので有用かもしれない
- デスクトップでは、スクロールバーが現在のコンテンツ位置を示す状態表示として機能する
- ユーザーは作業を止めてマウスを握らなくても現在位置を把握できる
- フォーカスのないウィンドウでも位置確認が可能である
- tailingログファイルリーダーやデバッグストリームのあるコマンドプロンプトでは、最新出力位置を見ているか確認するのにスクロールバーが役立つ
- 自動非表示スクロールバーでは、この確認がより難しくなり、より不明確または面倒な別の方法を使わなければならない
- QT5のデフォルトのスクロールバー描画は、バーとトレイの区別が難しく、コントラストも非常に低い
- 少し明るい部分がバーだと分かっていても、誤クリックが頻繁に起こる
- 古くて安価なノートPCの画面では、バーとトレイの違いを見分けにくいことがある
- QT5はツールによってより伝統的な外観に設定できるが、新規ユーザーにはそれが分かりにくいため、デフォルト外観が重要である
メニューバーとGnomeアプリの不一致
- メニューバーは、Windows、Mac、Unix系でおおむね似たように動作していた最小公倍数だった
- 伝統的なFile、Edit、View方式は、アプリ機能を探索する標準ルートだったが、Gnomeのデザインはこれを別の方法で置き換えている
- ハンバーガーメニューはスマートフォンでは便利だが、横長画面を使うデスクトップでは、水平方向の空間不足を解決する必要性が薄い
- Gnomeでは、ハンバーガーメニューはほかの場所に配置されていないUI操作を収める用途で使われているようだ
- EvinceのハンバーガーメニューにはOpen、Save、Print、Closeがある
- Gnome-MPVのハンバーガーメニューにはOpenやCloseがなく、ファイルを開くには左側のプラスアイコンボタンを押さなければならない
- Gnome-MPVのアプリアイコンボタンにはpreferencesとquitオプションがあるが、Evinceのアプリアイコンボタンは別のメニューを提供する
- アプリ間の一貫性が低く、ユーザーは同じ機能を探すために異なる場所を学ばなければならない
- 一般的なドロップダウンメニューや一部のハンバーガーメニューと異なり、これらのメニューは開いたあとキーボードでどう移動すればよいのか見つけにくい
Gnomeのタイトルバー統合と追加ツールバー
- Gnomeアプリは、ツールバーをウィンドウタイトルバーに統合する新しいパラダイムを採用しており、Windowsアプリの事例で批判したタイトルバー占有のやり方を制度化している
- 別のウィンドウマネージャを使うと、タイトルバーとアプリ自体の閉じるボタンが重複して見えることがある
- ウィンドウ移動のための領域をある程度残そうとするため、以前ならタイトルバー下のツールバーに入れられたウィジェットが、別途開く構造になっている
- Evinceの検索ボックスは別途展開される形で提供される
- 注釈ツールバーはアイコン2つしか含まないのに、それを開くために別のアイコン1つを使っている
よくある反論への回答
- 「技術は進歩し、変化は止められない」という言い方は、実際の論証なしに使われる決まり文句に近い
- UIデザインを変えるのは自然の力ではなく、人間の決定である
- 変化それ自体が改善を意味するわけではなく、目標は変化ではなく改善であるべきだ
- 「過去にとどまっている」という反論は、伝統的UI要素を好むという点では当たっているかもしれないが、すべての現代的デスクトップがWindows 95やCDEのように見えるべきだという意味ではない
- 基本概念を壊さずに、UIの見た目や使い心地を改善する別の道はある
- 「Electronアプリは単一プラットフォーム標準に従えない」という反論については、マルチプラットフォームアプリであるほど、共通プラットフォーム間で翻訳可能なパラダイムを守るべきだ
- ドロップダウンメニュー、すっきりしたタイトルバー、明確なウィンドウフォーカス表示は、実装が難しい概念ではない
- マルチプラットフォームフレームワークは、こうした概念を実装しやすくし、回避しにくくするべきである
- 「無料ソフトウェアに文句を言うべきではない」という反論に対しても、GnomeやKDEのような大規模FOSSプロジェクトは、MicrosoftやGoogleのようにユーザー、デザイナー、プログラマに大きな影響を与える
- 模範を示すプロジェクトであるなら、それにふさわしい基準が適用されるべきだ
画面領域の節約とUIの複雑さ
- タイトルバーに要素を入れれば、ある程度の画面領域は節約できる
- しかし一般的な画面領域は、もはや大きな問題ではないと見る
- コンピュータを十分に使うユーザーなら、約US$200で2560x1440解像度の大きなモニターを買える
- 最も安いノートPCでも、通常は少なくとも1366x768の解像度を備えている
- 画面領域の問題は、むしろ現在のUIデザインの広い余白のせいで大きくなっている
- 昔の単純なリクエストウィンドウが、全画面アプリケーションのように見える例がある
- 13インチのノートPCで一日中コーディングするユーザーは、数ピクセルよりも背中、首、手、肩の健康を心配すべきだと見る
- UI設計が難しく、常にすべてのユーザーを満足させることはできないのは確かだが、何十年にもわたって実証されてきた基本UI概念を意図的に壊す理由にはならない
- アプリごとにウィンドウ装飾や操作方法の細かな違いを別々に学ばなければならないなら、ユーザーは繰り返しその差異を解釈するために時間とエネルギーを費やすことになる
1件のコメント
Hacker News の意見
この10年ほど、UI/UX チームとずっと戦っているような感覚があり、核心は、プロ向けツールから消費者向けコンテンツ消費のパラダイムへ設計基準が移っていったことにあるように見える
20年前のソフトウェアはたいていプロ向けツールだったが、今では利用量ベースで動画・ソーシャルメディアのような消費者向けソフトウェアが中心になっている。デザイナーたちは、「用事を片づける」製品にもコンテンツ消費のルールを適用しようとしている
典型的には、「よりすっきりして直感的」だとして、見えていたツールを三点メニューの裏に隠し、1回のクリックを2回のクリックに変えてしまう。そしてツールの利用者はそれを1日に何百回も繰り返すことになる。表は、以前なら20項目と6〜8個の詳細情報を表示していたスペースに、10項目と4個の詳細情報しか表示せず、ダッシュボードはグラフ10個の代わりに4個だけを表示し、メニューがアプリ上部の10〜20%を占め、H1見出しは巨大になる
より良い配置があるからではなく、今の配置に飽きたというだけで家具を頻繁に動かす叔母がいるのだが、PM や UX 方面にはこうした傾向がよく見られるように思う。製品に4つ目の表ビューを追加しながら「まったく違うスタイルを使うべきだ」と言うのも、より良いからではない。COVID 以降、毎週友人たちと Google Meet をしてきたが、ほぼ毎回どこかが変わっていて、最近は参加リクエストのフローがまた変わったものの、良くなったわけではない
どこかの時点からは、ただ受け入れて、より良い方法が新しいベストプラクティスになるまで待つようになる
ところが、もともとの問題を直そうとする流れがどんどん増幅され、すでに行き過ぎていることに誰も気づかなかったように見える。あるいは、昔の UI の文脈を知らない新しいデザイナーたちが、すでに修正済みの UI に同じ処方をもう一度適用しているのかもしれない
振り子が戻ってくるというより、脱出速度に達してしまった感覚がある
画面上のすべてのボタンやスクロールバーが「できるが、まだやっていないこと」を絶えず語りかけてくるのが、デザイナー個人にとってはあまりに煩わしく露骨なので、結局すべて消したくなるのだろう
平均的なユーザーに必要な程度のスキューモーフィズムへ、UI の流れがいつ戻るのか気になる。Web リンクというパラダイムでさえ、高齢者や経験の少ないユーザーには難しすぎるようで、いつか避けられないデータとして明らかになる気がする
PM や UX 担当者たちも仕事をする対価として給料をもらっており、彼らの仕事は UI/UX を変えることだ。ほぼ完成したソフトウェアを維持するために給料をもらうなら、リファクタリングや細かな修正に時間を使うことになるだろうが、違いは、私たちがするすべてのことがユーザーに見えるわけではない点にある
UX 側が何をしようとかまわないので、Ctrl-K を押して、望むコマンドの頭文字を入力できるようにさえしてくれればよい
2000年ごろから Web・モバイル・関連 UI だけを設計してきた UX デザイナーとして、変化のための変化が多くのユーザビリティ問題を生むという点には同意する
しかし、より大きな問題は、実際に設計している人たちの間で、専門的な議論やまともな設計分析がほとんど消えてしまったことだ
一緒に働くデザイナーの多くは、広い意味で何が「使える」ものにするのかを説明する語彙や知識を持っておらず、微妙なインタラクション設計や情報表示の問題を解く能力も不足している。基本的なヒューリスティックへの知識や関心がないため、どこから始めればよいのかも分からない
そのため、Figma の中で色、形、効果をいじって暮らし、同じ UI の変種をいくつか「ユーザーテスト」に出す程度にとどまる。本来の目的を完全に見失った、意図的に無知な「非技術的」イノベーションのカルトになってしまった
自分の職業が恥ずかしいと言っても誇張ではない。あまりにも大きく失敗した
当時は、UI/UX デザイナーたちにとってはもっと馴染み深い世界を、私たちが少しかじっているのだと思っていたが、そうではないのかもしれない
多くの人が、文脈、エコシステム、設計判断のシステム的効果を考えるよりも、貧弱な調査で狭い問いだけを投げかけ、また「きれいに」することへ戻っている
HCI 入門と優れたデザイナーたちから得たごく基礎的な知識はあるが、まだ技術的・形式的なレベルではない
報酬を得るために必要最低限の精神的労働だけを投入しているわけだ
責めたいわけではない。彼らは飽和した分野で働いており、ユーザビリティよりも視覚的な魅力や雰囲気を重視する役員たちの気まぐれや好みに左右されている
結局はマーケティングなのだ。人々が使いたいと思わなければ、その製品がどれほど使いやすいかには大した意味がない。軍隊のようにユーザビリティの高いものを作る産業も多いが、たいていは見た目が悪いだけだ
投稿者はmacOSについては経験不足なので判断を保留すると言っていたが、ここでも同じ低下が起きている。特にAppleは、遅いホバー効果と、あまりにも微妙なグレーの濃淡の裏に機能を隠すことに夢中になっているように見える
おそらく洗練されて見せるためだろうが、インターフェースの発見可能性を損なっている。何かがホバーアニメーションの裏にあると覚えても、実際の対象領域はマウスをその位置へ正確に移動してからでないと表示されず有効にもならないため、狙いを定めにくい。Musicアプリと通知の挙動は特にひどい
ウィンドウのタイトルバーでどこがドラッグ可能なのかもはっきりしない。ある1ピクセルではウィンドウをドラッグできるのに、そのすぐ下のまったく同じ見た目のピクセルではできない理由を理解できたことがない
私の考えでは、AppleのUIユーザビリティは昔から強みではなかった。MacとPCの両方を使わなければならない立場からすると、macOSも多くの面でPCと同じくらい、あるいはそれ以上にひどい
Appleが得意なのは、自社エコシステム全体におけるデバイス統合の使い勝手だ
ところがmacOSは画面切り替え時にもっさりしたアニメーションを再生する。オフにはできず、同じように遅い2種類のうちどちらかを選ぶことしかできない
これを正当化できる良い理由が思いつかない。どんなユーザーモデルから「ウィンドウを切り替えるときは遅いアニメーションがよい」という結論が出たのかわからない
両面印刷はサポートされておらず、手作業でやる必要があるし、一部のアプリはページを逆順に印刷するので並べ直さなければならない
テンキーの
.を,ではなく.として使うには、まともなデフォルトのためにアプリをダウンロードしなければならない英語キーボードを使っていないと、ターミナルでAlt+.も使えない
ダウンロードしたアプリを実行するには、起動して、失敗を受け入れて、設定とセキュリティに行き、ブロックされたアプリを探して許可しなければならない。Windows Vistaより悪い
あるアプリに権限を与えるには権限の種類を知っている必要があり、アプリ基準で検索できない。こういうことが延々と続く
今でもFinderのサイドバーにある青みがかったグレーのアイコンの形を読み解くのに、あまりにも多くの時間を使っている
ファイル構造、さらにはファイルという概念まで隠す方向へさらに進んだ。技術に詳しくないWindowsやMacユーザーにファイルがどこに保存されているか尋ねてもわからない。クラウドにあるのかと聞いてもわからない
さらに悪いのは、UIと同じく、アプリごとにデータを保存する場所が一貫していない点だ。ファイル拡張子を隠すという馬鹿げたことも忘れてはいけない
Windowsは英語以外のユーザーには嘘までつく。たとえばドイツ語ではホームディレクトリが「Benutzer」にあると言うが、実際にはそんなディレクトリはなく、「Users」しかない。複雑さを隠そうとする試みが、結局は混乱とさらなる複雑さを生んでいる
最初の正社員としてのiOSの仕事で遭遇した別の問題を思い出す。アプリの説明に「button」と書き、ドイツ語訳は「Knopf」だったのだが、Appleの禁止語フィルターに引っかかった。おそらく「Knopf」が「knob」の訳でもあるからだろうが、ドイツ語の「Knopf」には英語の「knob」のような性器をほのめかす意味はない
Appleは「ファイル」という概念から離れ、「コンテンツ」を複数のアプリ間で移動させる方向を最も強く推し進めている側のように感じる。ところがアプリごとに共有、読み込み、書き出しのパラダイムも少しずつ違う
今ではiCloud Driveの「ファイル」アプリまである。それが何を意味するのか、自分のスマホ上にあるのか、iCloud Drive上にあるものを表示しているだけなのか、どうやってわかるのか。雲アイコンはダウンロード済みという意味なのかそうでないのか、少し濃いグレーと少し薄いグレーならまた何を意味するのかもわからない
最も技術に疎いユーザーでさえ、ファイル拡張子が何で、どう動作するかを知っているのに、それでもそうなのだ
いったいMicrosoftは何をしているのかわからない
Explorerのもう一つの退化は、以前は中身のあるディレクトリの横に小さな「+」表示があったのに、Microsoftがそれをなくしてしまったことだ
左側パネルの上にカーソルを通過させると、そのときになって理由もなく表示される。あるいは、広く理解されている「+」記号から、馬鹿げた三角形へさらに退化したのかもしれない
もう退化についていくことすらできない
デスクトップの使いやすさをモバイル互換性のために削ったにもかかわらず、多くの環境はいまだにモバイルでは存在感がない。もういい加減、スクロールバーを返してほしい
以前、ある設定を探すのに私と開発者がかなりの時間を費やしたことがあったが、ウィンドウの下にさらに内容とチェックボックスがあることを示すものがまったくなかった。隠しスクロールバーが流行る前なら、当然見えていたはずのものだ
問題は、ポインタがほぼ常に置かれているナビゲーションパネル上にあると、別のパネルのスクロールバーが隠れてしまう点だ。スクロールバーという視覚的な手がかりがないので、別のパネルにさらに内容があることに気づくためにポインタを動かす理由がなかった。今では境界線も全部なくしてしまったので、そもそも別のパネルなのかさえ分からないことがある
開発者にスクリーンショットを送り、最新版を使っていると確認したところ、「下にスクロールしてください」と返ってきた。もちろん私がバカだったのだろう。/s
モバイルのように、すべてのUI要素を手当たり次第に触って動作を探らなければならず、そうして覚えた技は特定のアプリ1つにしか通用しない。タップして、長押しして、長押しする時間を変えて、もっと速くタップして、やたら押して、「ググって」、今度はUI要素にすら見えない場所へドラッグしなければならない
「チェックボックスにチェックが入っていますか？」が「スライダースイッチはオンですか？」ほど曖昧だったことはない。チェックボックスは画面スペースも少なくて済む。これはスペースもユーザーフレンドリーさも最適化しておらず、単に見た目に最適化しているだけだ
もっと平たくして2つの四角形のように見せれば、さらに悪くできるかもしれない。暗い部分がスイッチ部分なのか？ 誰が気にするというのか。きれいで邪魔な要素がないように見えればそれでいい。スイッチの状態が分かってしまうなんて、私はよほど気が散っていたらしい
その本は、モードを避けるべきだと紙幅を割いて述べ、その理由も説明している。70ページにあるUIの「すべきこと」と「してはいけないこと」は、繰り返す価値がある
すべきことは、オブジェクトの外観をユーザーができるだけ制御できるようにすること、動作するメニューコマンドには動詞を使うこと、警告を自己説明的にすること、メニューコマンドだけでなくコントロールやグラフィックを使うことだ
してはいけないことは、モードの乱用、マウスのほうが簡単な作業にキーボードを強制したりその逆を強制したりすること、特にスクロールのように画面の見た目を予期せず変えること、オブジェクトを不必要に再描画すること、標準メニューと同じ名前の独自メニューを作ることだ。About、File、Editと、その中に入る内容まで、この本が定義していた
私たちは、アプリごとに異なる唯一の正解UIがあり、すべてのユーザーに同じ形で強制されるという奇妙な局所最小に入り込んでしまった。一方で産業制御のように、5万ドルの機器に付属するアプリを1〜3人が使う領域では、レスポンシブなモバイルインターフェースをスライドデッキを作るように簡単に配置でき、カスタムダッシュボードもウィジェット1つで済む
クラウドが靴を作ったなら、芝生用とコンクリート用の靴は別々にあるだろうが、すべて同じサイズなので、足が大きければつま先を切り落とさなければならず、小さければ詰め物を入れなければならないだろう
スクロールへの不満に関連して、古いデスクトップUIを見ているとはっきり分かる、デスクトップ特有の原則がある。コントロールは絶対にスクロールせず、コンテンツだけがスクロールする
コントロールがウィンドウ内に収まらない場合、そのウィンドウをスクロール可能にはせず、タブで分けるか、ボタンから開く別ウィンドウに追加のコントロールを入れる。少なくともWindowsとmacOSでは、一般的な原則に見える
チェックボックスのほうがずっと良く、ラベルに二重否定さえなければいい。たとえばチェックすると何かが無効になるように作る開発者は、夜明けに銃殺ものだ
滑る丸が実際にオンなのかオフなのかも分からないのに、半分はオンとオフのどちらが自分の望むものなのかさえ分からない。二重否定があふれ、表現はおかしく、実際の影響についての表示もない
すべてがおかしくなっているように思える
Googleのようなところが最近A/Bテストにますますのめり込んでいると言われていたが、ユーザー調査の歴史上、どんなA/Bテストも、ボタンが何らかの理由で移動したときにパワーユーザーから噴き出す激しい怒りをきちんと測定したことはない
携帯音楽プレーヤー、昔の言い方ならWalkmanやMP3プレーヤー、今風に言えば DAP 分野が、私の定番の不満です。現在売られているプレーヤーは使い勝手があまりにひどくて、誰が買いたがるのか理解できません
良い製品は、ストリーミングサービスとAndroid端末の組み合わせに押されて消えてしまいました。今では、軽くてシンプルで、大容量で、物理ボタンがあり、バッテリー持ちの良いプレーヤーがありません。ポケットに入れて走っても青あざができない、そういうもののことです
読みやすい画面、まともなメニュー構造、ファイルのタグを読み取れてプレイリストをそのままドラッグして入れられる機器。こういうものを望む人は確かにいるのに、メーカーは突き出たノブや奇妙な角、バッテリーを食う巨大なタッチスクリーン、ひどいAndroid派生OSを載せた巨大なレンガを出してきます
「これはDACが2つあります！」と言うのですが、本当に？ 私は1万ユーロのモニターがある防音の試聴室ではなく、イヤホンをつけてバスに乗っているんです
レビューは携帯音楽機器で最も重要な側面をほとんど扱わず、ワイン評論家のように音楽の香りや味のようなものを絶賛します。半分は冗談です。評判の高いレビュアーほどたわごとを多く書き、重さやサイズへの言及すら見つからないことがよくあります
言及していても間違っています。たとえば「Shanling Q1は軽い携帯機器」だと言いますが、まったく違います。ひどいOS、悪いバッテリー持ち、過敏すぎるボタンを備えた、ひどいレンガです。音がどれだけ良くても、プレイリストを入れられず、重くてインターフェースがひどくて使いたくないなら、興味はありません
13年前のSansa Clip+のRockboxは素晴らしかったです。今日の技術でそれをそのまま作れるなら、ばかげて高価で巨大なレンガたちよりも、私はそれを選びます
実際、UI、形状、タッチスクリーンといった悪い設計判断が、まともなハードウェアを台無しにしているのは心が痛みます
何時間も費やした末に、使える解決策を見つけました。Amazonで Hifi Walker H2 を買ったのですが、誤字を含む悪いUI設計はあるものの、ハードウェアは良いです
そこに RockBox をインストールし、少しカスタマイズしたところ、ひどいUIの問題は解決しました。残念なのはRockBoxがBluetoothやUSB DACをサポートしていない点で、こうした機能が必要なら問題になります
「画面スペースを節約しないといけないので……メモ確認……画面全体を占めるボタンを入れようと思います」
「タイトルバーに移せば画面スペースを節約できる」という話で、いつも引っかかる部分です
最近また腹が立つのは、多くのアプリケーションが起動中に何度もフォーカスを奪うことです。ばかげた フォーカス奪取 のせいで、チームチャットにパスワードを誤って投稿してしまった人があまりにも多いです
iOSが 長押し を導入した時点で、ほとんど終わったと感じました。あるUI要素を押したときに何をするのか分からず、全部タップしてみる必要があり、今では別の動作をさせるには長押ししなければなりません
アプリができるはずだと思うこと、あるいは期待することを見つけるために、すべての要素をタップしてから長押しすることに時間を使うわけにはいきません
当然そう動作すべきように見えたのに、今では長押しが勝手気ままな用途に使われています
証明はできませんが、こうしたUI/UXの惨事は、ソフトウェアが生きていることを示すために常に変わらなければならないというプレッシャーから生じる場合があると思います
2023年にあるアプリがユーザビリティの頂点に達したと想像してみましょう。完璧ではないものの、そのアプリの使いやすさをさらに改善する想像可能な方法がない状態です。ユーザーはかなり熟達しており、アプリを学ぶうえでの本質的な壁を越えれば、すべてがだいたいうまく噛み合います
この状態は維持できるでしょうか。そうではありません。UIをそのままにしておくと、ソフトウェア業界ではそのアプリを「古くなった」、あるいは死んだものだと受け止めることがよくあります。だから変えなければならないのです。しかしユーザビリティの頂点を過ぎてから何かを変えると、必然的にUXを悪化させ、ときには壊滅的なほどになります
これが、一部のアプリやデスクトップ環境のまともだったUIが徹底的に壊される理由の一つだと思います
高速な常時接続インターネットの普及が、この問題を大きく悪化させました。昔はソフトウェア開発者が製品をCDやフロッピーなどに入れて店頭に送る必要があり、簡単にアップデートする機会がなかったため、少なくとも明確な目標と締め切りが必要でした
アップデートを出すときも、ユーザーに新バージョンを入手してインストールする手間を受け入れさせるだけの、意味があり実質的なものでなければなりませんでした。一方、現代のソフトウェアは、うちの国のことわざを大ざっぱに訳すなら「侍には目標がなく、道だけがある」という言葉に最もよく当てはまります
私の理想は、愛され広く使われる製品を作り、可能な限り顧客サポートや運用上の問題をすべて自動化したうえで、別の製品に移るか、ビーチで休むことです
誰も変化を望んでいません。UIが変わるたびに不満を言う集団は見てきましたが、その反対側で真の信者たちが同じくらいの規模で押し寄せてくるのを見たことはありません
初期段階では、人々に自社製品を好きになってほしいと願い、気を配り、耳を傾け、ユーザビリティにリソースを割きます。幸せな顧客が私たちを幸せにします
中間段階では、ユーザビリティが難しいことに気づき、人間工学やアフォーダンスを作ることが思ったほど簡単ではなく、国際化まで付いてくると分かります。この領域をきちんと教えてくれる人はいないため、ほとんどは自分たちで学ばなければならず、請負業者は高額です
衰退段階では、もっと多くの機能を作りたいのでプログラマーを増やし、ユーザビリティチームは「必要なことはすべてやった」として解雇します。ドキュメントチームも解雇します。ソフトウェア開発者はエンジニアなのだからFAQくらい書けるだろうと考えます
どん底の段階では、立派なスプリントで顧客に機能を大量に投げつけたのに、顧客は不幸なままです。「顧客はなぜこうなんだ？」と問うことになります
Office 2007以降しばらく、OpenOffice/LibreOfficeの開発者たちが慌ててRibbonを実装しないでほしいと息をひそめていました。今まで持ちこたえているのは、ささやかな明るい点です
ほぼ完璧なv1では役に立っていたUXチーム全体にも給料を払い続けているので、彼らに仕事を与えなければなりません