Mac アプリケーションが個性を出すべきではない部分

MacDev

Reeder が独自タイトルバーを採用しているように、ここ数年 Human Interface Guidelines を一部無視して作られたアプリケーションが人気になっているし、“The HIG is dead”みたいな話もときどき目にする。

確かに HIG はあらゆるタイプのアプリケーションが違和感なく共存できるように考えられていて、アプリケーションによっては無駄を感じられる部分もある。

それでも、いくつかの要素に関しては変えてしまうと個性というより違和感になってしまうので、個人的に気になるものをまとめてみる。

細かいことばかりに思われるかもしれないし、「こんなの UI デザインの本質ではない」とか言う人もいるかもしれない。だけどこういう“細かいひっかかり”だって積もれば山になるし、そんな部分が比較的少ないことが自分が Mac を使う理由でもある。

スクリーン座標と UI 部品のレイアウト

Mac では昔からウインドウ内の UI 部品が、左上から右下にかけてだいたい次のように並んでいる:

↖ [削除] [閉じる] [キャンセル] [前へ] [次へ] [完了] ↘

これが統一されている意味は大きく、ダイアログでキャンセルしたければテキストを確認しなくても自然にカーソルを左に動かすし、作業を次に進めたければ右下を探す。アプリケーションに慣れる時間を大幅に短縮できる。

記号とその意味

機械に慣れていない人でも CD プレーヤーを操作できるのは、▶ を押せば再生、止めるときには ■ を押せばいいと誰もが知っているからである。Mac の UI においても、同じ意味に対しては共通の記号を用いるべきだと思う。

Apple は履歴を移動するボタンを三角 [◀ | ▶] で統一しているし、そうでない移動(iPhoto など)には矢印 [← | →] が使われることが多い。

メニューを表示するボタンは ▼ をつけるべきという話があるけど、Apple 製アプリケーションも含め、つけないものが増えているのが残念。

UI における表記

記号と同じ。すべての項目を選択したいとき、メニューから“すべてを選択”を探す。これがアプリケーションによって“一括選択”とか“全部選択する”のようにバラバラだったら、探すのに時間がかかるだけで何のメリットもない。Windows には Windows の、OS X には OS X のための文字列を用意するべきである。

Mac アプリケーションの日本語リソースにおける法則については Mac Apps + Japanese というページにまとめてあるので、参考にどうぞ。

ユーザの操作に対する移動量

ユーザがトラックパッドやマウスで行った操作がどのように反映されるかは非常に重要で、プラットフォームの操作感を大きく左右する部分でもある。

ありがたいことにマウスカーソルの移動は完全にシステムが管理しているため、どのアプリケーションでも同じ。この速度や加速度がバラバラだったらと思うとぞっとする。

しかしピンチジェスチャとか 2 本指スクロールをしたときの移動量が違うアプリケーションはいくつかあり、非常に気持ち悪い(例:Photoshop CS6)。Photoshop は CS3 では自然なスクロールだったのになぜ変えてしまったんだ!

光源

ウインドウの影を見ればわかるように、OS 9 までは左上にあった光源が OS X では中心ちょっと上に移動している。グラデーションやドロップシャドウを見れば、メニューバーからボタンやアイコンまで、スクリーン上のすべてが共通の光源を持っているのがわかる。

全体の光源を無視して影を右下に置くようなアプリケーションは安っぽく見えてしまうので注意。

フラット...?

Others

個人的には iOS 7 での変更は 3 割好きで 7 割嫌い。

  • 初めて見る人が、あのロック画面で何をどうスワイプすればいいのかわかるのだろうか。
  • ボタンが消えて、タップ可能部分を見分ける基準が文字/記号のカラーだけなのはどうなんだろう...
  • アイコンは共通のグリッドに沿って作られているらしいけど、以前より統一感を感じない。しかもシンプルになったにしては以前より見分けにくくなってないか?
  • どのアプリケーションが起動しているかどうか意識しなくて済む点では iOS 6 までの方が好き。表面的には“最近使った App”のリストに見えるタスク切り替えバー、気に入っていたのに...
  • あのマルチタスク画面、昔どこかで見たぞ。web、なんだっけ。
  • よく「フラットデザインにはユーザがコンテンツに集中できる利点がある」という人がいるけど、ナビゲーションバー/ツールバー/タブバーなどの UI 部分とコンテンツ部分の差がなくなってしまったら、どちらにも同じだけ目がいってしまい逆効果ではないかと思う。UI が強く主張すべきではないというのはわかるけど、コンテンツと同列にするのは違う気がするのだ。

良くも悪くも、ジョブズがいなくなって分岐した先の未来にいるんだと実感。ジョブズがいたらまだフォーストール主導だっただろうし。

変化についていけない人を置き去りにする会社だとはわかっているので、慣れるしかないけど...
お願いだからこのデザインは Back to the Mac しないで!

2015.3.14 追記

長く使って感じ方が変わった部分や触る前の思い込みだった部分などいろいろあって、今読み返すと面白かった。

“ひ to り go と”の更新頻度が落ちている理由

Site

忙しい

これを言っていたらきりがない。

このサイトが @2x 画像を用意していないので Retina ディスプレイで見るとモチベーション低下

Retina 対応させるため、画像を Sketch で作り直している。意外に数が多いので大変。

そういえば Sketch は Adobe の Creative Cloud 一本化騒動のあと、日本でもだいぶ有名になった感じがする。勉強会まで開かれたらしい。

バージョン 2.0 の頃DrawIt と同じバグを引きずっていたりしてまだまだ未完成感が強かったけど、その後いい勢いでバージョンアップを重ねてバグは減り、パフォーマンスや描画品質も大幅に改善されている。今後も期待できそうなアプリケーションだ。

更新の手間が増えた

MobileMe の時代は RapidWeaver で作られていた“ひ to り go と”。記事を書いたらボタン一つでサーバ(iDisk)にアップロードできた。

サーバを変えてからは PHP + SQLite + .txt ファイルによる自作システムに移行。
Web ブラウザ上の作者専用ページで記事の管理をできるようにしたけど、動的なページをサポートしない Apple のサービスに長年いたせいか、「Web サーバのデータはローカルのコピーである」主義を引きずっているためちょっとややこしい。

手間がかかるけど、ローカルの管理ページで更新したあと、変更されたファイルをサーバにコピーしている。

あらゆる記事に貼ってある画像が一つのフォルダに入っているなどディレクトリ構造がごちゃごちゃしている部分を 1 日かけて整頓したのでだいぶ更新しやすくなった。