Author Archives: Manabu

viewport-fit=cover is confusing for app developers

(Updated on Dec 8, 2017) First, you know the Safari on iPhone X automatically applies paddings. The contents will be restricted inside the safe area by default. Fig1. Safari with default paddings – portrait Fig.2. Safari with default paddings – … Continue reading

iPhone X – Screen Real Estate Comparison

Now a question is raised. If you cannot place elements around the notch and under the bottom swiping space, is iPhone X’s screen real estate where developers actually place elements really that large (+20%) in comparison with iPhone 6/7/8′s? OK, I have tested with the simulators.

Apple deleted the “Design Principles” from its Human Interface Guidelines for Mac

Among software designers, Apple’s “Human Interface Guidelines (HIG)” is a very popular document. According to Mike Stern, Design Evangelism Manager at Apple, this document was first released in 1978, and it has been occasionally revised along Mac OS updates until … Continue reading

神輿のオブジェクト指向性について

神輿とその渡御には様々な方式があるようだが、そこにはオブジェクト指向プログラミングに通じるコンセプトがあるように思う。 インスタンス 神輿は祭の際に一時的に神霊を運ぶ輿であるが、神輿が氏子の町内を渡御している間、神様は神社を留守にしているのだろうか。複数の氏子町内で同時に渡御が行われることも普通であろうから、ひとりの神様が一度に一ヶ所にしか存在しないと考えるのは不自然だ。やはり同時に複数存在できるのだろう。これはインスタンス化のコンセプトと似ている。神社にある宮神輿がプロトタイプであり、その性質を継承した町内神輿がインスタンスとして new されていると考えるとよいだろう。 カプセル化 神輿は神社をかたどっている。神社は神様の家だ。神棚などと同様に、擬人化した偶像ではなく、その家をもって神のメタファーとしている点が興味深い。神殿の中には神様がいるはずだが、その中を覗くことはできない。社というインターフェースがエクスポーズされているだけだ。人々はそのインターフェースを通じて神とインタラクトする。これはカプセル化のコンセプトと同じだ。 ポリモーフィズム 神輿の形状や担ぎ方には様々なスタイルがあるだろうが、概ね似ている。人々は何本かの棒の上に社を乗せて、それを担いで運行する。神輿はとても重く作られているし、担ぎ棒は決して人間工学的に担ぎやすいようにはできていない。むしろできるだけシンプルでプレーンな構造を保っているから、それを担ぐものは身体的苦痛を余儀なくされる。しかしその苦痛が祭の高揚感と相乗して、独特の興奮をもたらす。神輿の楽しみは、神輿自体のインターフェースにあるのではなく、それを担いた者の内部に起こる集団心理的なエクスタシーから成っている。このシンプルなインタフェースと多様なアウトプットは、ポリモーフィズムと言えるだろう。

プロレタリア絵本

プロレタリア文学やプロレタリア児童文学というジャンルはあるが、プロレタリア絵本というのは聞かない。 そこで単なる思いつきではあるが、好きな絵本の中でそれっぽいものをとりあえず三つ挙げる。 3位 – 『みんなの世界』 マンロー リーフ(光吉 夏弥 訳) 「もしも、このひろい世界に、人がたったひとりしかすんでいなかったら」という問いかけで始まるこの本は、民主主義のコンセプトを、身近な事柄を例にしながら順序立てて、子どもに教えてくれる。(そこまでプロレタリアというわけではない…) 社会とはどういうものか、なぜ社会にはルールがあるのか、なぜ選挙で投票に行くべきなのか、といったことを、暮らしの中の必然として、やさしい言葉と無邪気な絵で説得していく。 2位 – 『絵で見る日本の歴史』 西村 繁男 巨匠西村繁男の歴史もの。各時代を見開きで描き、石器時代から戦後の高度経済成長までの、日本の生活風景を絵巻のように展開する。 普通、歴史ものというと、各時代の権力闘争や上流階級の文化様式が主題となる。しかしこの絵本の主人公はあくまでも市井の人々だ。 弥生時代に卑弥呼は出てこないし、安土桃山時代に戦国武将は出てこないし、太平洋戦争の時に兵隊は出てこない。描かれるのは、農民、古墳や城を築く労働者、空襲で逃げまどう銃後の人々である。 1位 – 『とべバッタ』 田島 征三 田島征三も名作ぞろいだが、これはもう歴史的大傑作と言わなければならない。「とにかく騙されたと思って読んでみな」と言われて読んだら、途中から瞳孔が開きっぱなしになった。 内容については、もう、「とべバッタ! とべバッタ! とべバッタ!」としか言えない。 以上。

左右論序章

Mac の Cocoa フレームワークには First Responder という概念がある。First Responder は、ユーザーのマウス操作やキーボート操作などのイベントに最初に反応するオブジェクト、つまり現在フォーカスされているUI要素を参照する変数である。ユーザーがアプリケーションを操作してフォーカスが別のコントロールに移ると、First Responder の示す先もそれに応じて変わる。これは GUI におけるポリモーフィズムを実現するための仕組みだ。例えば Finder のメニューバーには「File > Open」という項目があるが、現在フォルダが選択されている時にこれを実行するとそのフォルダが開き、アプリケーションアイコンが選択されているとそのアプリケーションが起動し、ドキュメントファイルが選択されていると適当なアプリケーションが起動してそのファイルを読み込む。このように選択されているものによって処理が異なるのだが、メニュー項目の「Open」が行っているのは、現在の First Responder に対して “Open” というメッセージを投げることだけである。フォルダ、アプリケーション、ファイルなどはそれぞれ種類の違うオブジェクトだが、いずれも “Open” というメソッドを持っているので、それぞれが自分の Open メソッドを実行して、それぞれの振る舞いをするというわけだ。Open 以外にも、Close、Save、Print、Select All、Find、Undo など標準的な名前のメソッドを各アプリケーションが実装していれば、キーボードショートカットも含めて、システム全体で操作が一貫する。 GUI におけるポリモーフィズムというのは、インタラクションデザインの上で重要な意味を持つ。GUI における操作シンタックスの基本は「オブジェクト選択 → アクション選択」である。操作の対象となるオブジェクトが画面に見えていて、ユーザーがそれをマウスなどで選択し、次にメニューなどからアクションを選択する。このシンタックスこそが GUI を GUI たらしめているのであり、CLI との最大の違いはこのシンタックスにある。CLI では先にコマンド(アクション)を指示するが、これはあらかじめユーザーが学習によって記憶しているか、あるいは操作の度にヘルプを参照しなければならない。GUI … Continue reading

Apple をインスパイアした(かもしれない)Textwell/DraftPad の機能

シェアメニュー 他のアプリにコンテンツをルーティングするための一元的なメニュー。Textwell/DraftPad のアクションメニューとほぼ同じコンセプト。今でこそ当たり前の機能だが、ルーティング用のメニュー(しかも項目を追加していける)というものを iOS で最初に作ったのは DraftPad だと思う。 アクションシートのエクステンション アクションシートにサードパーティがアクションを追加できる。Textwell/DraftPad のアクションと似たコンセプト。 アプリ内からツイート OS X と iOS ではアプリ内からツイートする仕組みがある。それができる前、Twitter の iOS 用 SDK もない頃から、テキストエディタである DraftPad 内から直接ツイートできた。 自動保存 OS X のドキュメントベースアプリケーションでは、適当なタイミングで自動保存がかかる仕組みがある。Textwell/DraftPad が先にやっていた。(デスクトップではよくある機能ではあったが) 自動ヒストリー OS X のドキュメントベースアプリケーションでは、適当なタイミングで自動保存がかかり、それはバージョンと呼ばれるヒストリーとしてドキュメント内部にスタックされ、あとからリストアできる。これも Textwell/DraftPad が先にやっていた。バージョンでは、リビジョンを通じての検索はできない。Textwell/DraftPad ではできる。(検索できないとリビジョンを作る意味が半減すると思うのだが) フリーカーソル iOS 8 から、テキストビュー上でカーソルを指の動きに合わせて全方向に移動できるようになった。ほぼ同じ実装を Textwell … Continue reading

Textwell のスクリプトでURLエンコードする意味と方法

この記事は、ノンプログラマー向けに、URLエンコードとは何かを簡単に説明するものです。 Textwell のアクションでは、T( ‘urlScheme’ ) というコマンドを使って、Safari を呼び出したり、他のアプリを呼び出したりできます。 例えば、Apple のホームページを開きたければ、アクションのソースとして以下のようにスクリプトを書きます。 T( ‘urlScheme’, { url: ‘http://www.apple.com’ } ); “url:” という記述の後ろに、Apple ホームページのURLがクォーテーションで囲んで書かれているのがわかると思います。このURLの部分を変えれば、他のホームページやアプリケーションを呼び出せるようになります。スクリプトでは、任意の文字列(この場合はURL)はクォーテーションで囲まなければいけません。 T( ‘urlScheme’, { url: ‘http://www.google.com’ } ); このようにすれば、Google のページが開きます。 次に、Textwell のアクションから Google で何かのキーワードを検索させるにはどうしたらよいでしょうか。 Google のページでは、キーワード入力欄にキーワードを入れると検索が実行されて検索結果ページが表示されますが、ページ上でキーワードを入れなくても、URLの後ろにキーワードをつけたしてそれをブラウザで開くことで直接検索結果ページを開くことができます。 例えば、”Apple” というキーワードを検索した結果ページを開きたければ、ブラウザのURLに次のように打ち込みます。 http://www.google.com/search?q=Apple “http://www.google.com/” という Google … Continue reading

エレベーターのボタンについて

UI理論101問題: このボタンは全て無くすことができますが、ひとつだけ残すとしたらどれでしょうか? pic.twitter.com/UFcG2h4PE8 — Manabu Ueno (@manabuueno) 2015, 12月 18 このツイートが意外にもたくさんRTされていたので、解説してみる。 UI設計理論としてはまず、「目的達成までのユーザーの運動と認知の負荷を減らす」という考え方をするのが基本だ。同じ結果を得るためなら、操作や選択肢は少ない方がよい。UIはユーザーにとってオッカムの剃刀であることが望ましい。 ただしシステムを利用して目的を達成するプロセスには「テスラーの複雑性保存の法則」というものがあり、入力しなければいけない情報を一定以上減らすことはできない。 一般的なエレベーターを利用する上で必要となる最低限のインプットは、次の6つだろう。 エレベーターを呼ぶ合図 乗るためにドアを開ける合図 乗った後にドアを閉める合図 行き先階 出発の合図 到着した際にドアを開ける合図 テスラーは、複雑性は減らせないが移動はできると言っている。必要なインプットの負担をユーザー側からシステム側に移動することで、ユーザーにとっての労力を減らすことができる。 一般的なエレベーターにおいては、上記の6つのうち、2, 3, 5, 6 については適当なタイミングで自動的に行われるようになっているので、ユーザーが行うのは 1 と 4 だけである。1 はエレベーター外の上下ボタン、3 はエレベーター内の階数ボタンを使ってユーザーがインプットする。 これらはユーザーが特定の階に移動するために必要な操作だが、実際にはこれらに加えて、自動化された動作をキャンセルする機能があるのが普通だ。すなわち次の2つ。 ドアが閉じようとするのをキャンセルする合図 一定時間を待たずにすぐにドアを閉じる合図 7 は開くボタン、8 は閉じるボタンで行われる。開くボタンについてはスプリング式になっていて、押し続けている間その合図が継続する。また開くボタンは、エレベーターが移動している最中には安全のためにディスエーブルになっている。ふたつ以上の合図が同時に発せられた場合は、安全な方に寄せて他は無視される。 開くボタンは、自動的に閉まろうとするドアに(自分を含めた)誰かが挟まれないよう、エレベーター内の人が押すためのもので、安全のためのスイッチだ。一方、閉じるボタンは、急いでいる人が早くエレベーターを出発させたい場合にのみ使うものであるため、重要度は低い。閉じるボタンが無いエレベーターも存在する。 またドアには通常、安全装置があり、物が挟まるとドアが開くようになっている。これに加えて、赤外線センサーによってドアに物が接触するのを防ぐ機能を備えているものも増えている。 … Continue reading

タッチジェスチャとコンストレイント

iOS には、あらかじめいくつかのタッチジェスチャを認識する API が用意されている。 ジェスチャとは、プリミティブな入力イベントの特定の組み合わせをひとつの意味として扱うものだ。例えばパソコンであれば、マウスボタンの押し下げ(マウスダウン)やそれを放すこと(マウスアップ)がプリミティブな入力イベントの例であり、このふたつを連続して一定面積内で行うと、クリックというジェスチャになる。一般的なマウスのジェスチャには他にも、ムーブ、ダブルクリック、ドラッグなどがある。 タッチデバイスではマウスのかわりにタッチイベントが用いられるが、プリミティブな入力としては、例えばタッチの開始や終了がある。指をスクリーンに触れて、それを一定面積内で放すと、タップというジェスチャになる。 iOS では、基本的なジェスチャとして次の7種類が想定されており、これらの動作を検出する API が用意されている。 タップ ピンチ ローテーション スワイプ パン スクリーンエッジパン ロングプレス それぞれには更に、指の本数や、動作の段階(ジェスチャが開始された、継続中、終了した)ごとに処理を変える仕組みが含まれている。 つまりタッチジェスチャは、マウスのジェスチャに比べて、バリエーションが多い。 バリエーションが多いと言っても、例えばダブルクリックがシングルクリックの二連続でできているように、ジェスチャによっては他のジェスチャの組み合わせでできているものもある。例えばスワイプジェスチャは、水平もしくは垂直方向に、一定以上のスピードでパンすることを意味している。 別な言い方をすれば、ある指の動作が、AのジェスチャなのかBのジェスチャなのかという判定は、マウスの場合に比べて、かなり微妙なものになっている。 また、同一画面上で同じ種類のジェスチャが複数の意味で実装されていることも多い。例えば iOS 9 のホーム画面では、水平方向のパンはアイコン一覧のページめくり、下方向へのパンは検索窓の表示、画面下辺付近からの上方向パンはコントロールセンターの表示、画面上部付近から下方向のパンは通知センターの表示、というふうに、いくつものパンジェスチャが実装されている。 複数のジェスチャを同一画面上に実装する場合は、通常、ジェスチャ同士に優先度をつけて、あるジェスチャが発動したら他のジェスチャはキャンセルされるようになっている。ホーム画面の例であれば、下方向へのパン操作が行われた時、それが画面上辺付近から開始されていれば、通知センター表示が優先され、検索ボックス表示の処理はキャンセルされる。 ジェスチャのバリエーションが複雑な分、こういった優先度づけやキャンセル条件などの処理は非常に入り組んだものになりがちだ。操作の示唆が暗黙的な分、ユーザーはうまく操作できないこともあるだろう。 Apple Watch のデジタルタッチ Apple Watch では、サイドボタンからフレンドを選んでデジタルタッチと呼ばれる特殊なメッセージを送信することができる。 デジタルタッチには三種類のモードがある。スケッチ、タップ、ハートビートだ。スケッチは指で線画を描くもの。タップはスクリーンをトントンと叩くもの。ハートビートは現在の心拍をモニターする。 これらのデジタルタッチは、リアルタイムに相手のウォッチ画面に表示される。タッチデバイスならではの非言語的なインスタントコミュニケーションだ。 デジタルタッチによるやりとりが実際に面白いかは置いておいて、その仕様はよくデザインされていると思う。 Apple Watch ではデザインガイドラインとして、ユーザーに複雑なことはさせるなと謳っている。デジタルタッチを送る時にも、送信ボタンを押したりモード変更の操作をする必要はない。 どのようにモードが決定されるのかというと、指でスクリーンをなぞる(パンジェスチャ)とスケッチモード、指でスクリーンを軽く叩くと(タップジェスチャ)タップモード、二本指でスクリーンを押さえつけると(二本指ロングプレス)ハートビートのモードになる。 … Continue reading