はじめに

try! Swiftとは、AppleプラットフォームおよびSwiftデベロッパーのための国際コミュニティです。 世界中から参加者が集まり、最先端のSwift技術やAppleプラットフォームの情報、知識、テクニックを共有することを目的としています。カンファレンスは2024年3月22日より3日間にわたって東京・渋谷にて5年ぶりに開催されました。

私は高度なSwiftの知識を持ち合わせているわけではないのですが、今回ありがたいことにオーガナイザーのd_dateさんよりお声がけがありまして、一番最初のセッション登壇者として、macOSやiOSにおけるアプリのUIデザインに焦点を当てた講演を行いました。

これに先立ってnextstep.fmのポッドキャスト「nextstep.fm, episode 73 - try! Swift Tokyo 直前タイムテーブル徹底解説」を聞いていたところ、声がけの時点で私を最初に持ってくる計画があったそうで（！）、実際にその大きな期待にうまく応えられたかはわかりませんが、導入の雰囲気作りに一役買えたのであれば本望です。

当日のビデオは後でアーカイブが公開されるのかな？　されないのかな？
ちょっとまだわからないのですが、私はいつものようにKeynote芸やデモ動画を使った動く解説を多く盛り込んだため、上記スライドよりも、現地で実際に見ていただいた方にはより楽しんでいただけたかなと思います。

今回私に貴重な機会をくださったtry! Swift運営の方々はもちろんのこと、裏方で同時通訳を行ってくださったスタッフの方々、Appleの方々、そのほかの登壇者の方々、来場された多くの方々にも感謝を申し上げます。そして、当時現地で私に声をかけてくださった界隈の方々もありがとうございました。これからも何かしらの機会でお会いしましたらぜひ交流してください。

この記事では講演内容のすべてを紹介することはできませんが、ダイジェスト的に情報を補足なりしてみます。

・・・

幼少期の原体験から得た示唆

私は30年以上のMacintoshユーザーです。幼少期の原体験の一つに、Macのインターフェイスはシンプルで子どもにも扱いやすかったことがあります。ワンボタンマウスの見た目はクリックするための仕組みが明快でしたし、パワーキーを備えたキーボードは、文字入力はできなくとも電源の入れ方だけははっきりと覚えることができました。この「インターフェイスをシンプルに保つこと」の精神は、その後のMac OS X, iPod, iPhoneを経て、現在のApple製品にも息づいているように感じられます。

このような例にあるように、インターフェイスの仕組みをなるべく簡素に、かつ効果的に設計するということの意義は、デザイナーと名乗るようになってからようやくはっきりと理解することができました。また、機能を増やすことは容易いのですが、それを一貫して一つに保つというのは、非常に難しく困難であるということも今ではよく知っています。

Appleプラットフォームとしての「らしさ」

良いアプリケーションというものは、抽象的で、主観的で、はっきりと「これである」とは言い切れないかもしれません。しかし、Appleプラットフォームにおいてのさまざまな「らしさ」を嗅ぎ取り、それらをデザインに取り入れることで、Appleユーザーが良いと感じられるようなアプリを目指すことはできるかもしれません。

例えば共有を意味するシンボルには、Appleでは四角形に上矢印を重ねた“Sharrow”と呼ばれるアイコンが使われます。他のプラットフォームで同様の意味を持つものでは三つのドットを直線で繋いだようなシンボルがありますが、Appleにおいては一貫してSharrowを採用することが大切です。

AppleプラットフォームにはHuman Interface Guidelines (HIG)がありますが、1987年版のHIGを開いてみると、当時からこのような設計原則についての言及がありました。一貫したデザイン、寛容的なデザイン、ユーザーに主導権を持たせるデザイン、美的な整合性が保たれたデザインなどです。残念ながら現在のHIGからはこれらの記載は省かれてしまっていますが、依然として有効な原則であることは間違いありません。

iOSらしい動きをデザインする

UIデザインではインターフェイスの動きにも気配りが必要です。iOSではiOSらしい動きがそのプラットフォームを特徴づけています。仮にカスタムアニメーションを実装するという場合においては、イージングをはじめとした動き方を緻密に設計することが大切です。

アニメーションを実装する際に多く場面ではEaseInOutのイージング関数を採用するかもしれません。しかし、これをiOSのビュートランジションに適用すると、デモ動画のようになんだかぎこちない動きになってしまいます。システム標準のトランジションの動きと比較してみると、その差は一目瞭然です。グラフに表しても違いが分かりやすいでしょう。

要するに、iOSのビュートランジションではEaseInOutを使ってはいけません。今回は私が見つけたマジックナンバーによる再現方法を紹介しますので、これを代わりに使うようにしてください。UIKitの例ですが、Spring Animationの各パラメータに次の値を指定してください。これにより、UIViewControllerやUINavigationControllerの動きと同様のアニメーションが手に入ります。

・Duration: 0.5
・Damping: 1.0
・Initial Velocity: 0.0

アニメーションにバウンス効果を使うべき場面はどう判断すると良いのでしょう？　アニメーションを実装する際に、なんとなく慣性をつけて弾ませたくなると思います。しかし、そこにも設計として理論を持ち込んだ方が「なめらか」なインターフェイスを目指しやすくなります。

基本的には、加速度が伴うようなジェスチャを起点にするならば、その余韻をアニメーションに反映することでより自然に感じられます。すなわち、パンジェスチャなどでオブジェクトを弾くような動作をするインターフェイスなら、慣性を感じられるようにバウンス効果をつけます。逆にボタンをタップして動くようなアニメーションの場合には、そこには概念としてはユーザーからの力が加わらないので、アニメーションはバウンスなしで滑らかに目的地に着地するようにした方が自然に見えます。ちょうど一つ前のビュートランジションのような動きが適しているでしょう。

デモ動画のような滑らかな動きを作るにはコツがいるのですが、初速とUIScrollViewが定義する減衰率を用いて仮想の着地点を算出し、そこに向かってアニメーションさせつつ、そこから一番近い吸着地点にバウンスしながら着地するようなロジックを組みます。私はUIKitのUIViewPropertyAnimatorを使って実演しましたが、SwiftUIでも似たような発想で再現できるはずです。

この話には元ネタがあり、私が参考にしたのはWWDC18の803番セッション、Designing Fluid Interfacesです。今回私が紹介したトピックや一部のデモに加え、より緻密な動きのデザイン原則や応用テクニックについて語られています。ぜひチェックしてみてください。

"WWDC18 803 - Designing Fluid Interfaces"

デザインにおける調和と型破り

らしさの追求には、プラットフォーマーに代表されるリーダーによるデザインを忠実に再現する、守ることも一つの手です。しかし、それだけでは単なる模倣に過ぎません。みなさんが手がける素晴らしいアプリをAppleプラットフォームらしくしつつ、同時にみなさんのブランドというものも同居させられることが理想です。

私はよくデザイナーに対して「守破離」を用いて型破りと調和のバランスをとることの大切さを説きます。基本に忠実な姿勢をもちつつ、時には型破りにも挑戦し、そこの塩梅を探ります。完全に独自の流派を立てるには多くの苦労が伴うのであまり推奨しませんが、このことを意識しながら「ちょっとはみ出てみる」くらいを攻めてみると、案外いい感じになったりするものです。

例えばPull-to-refreshのアイディアは今ではあまりにも広く知られ、有用なデザインパターンとして定着していますが、その始まりはちょっとした型破りでした。iOSのUIScrollViewが備えていたバウンスバックの仕組みを逆手に取り、Tweetieがここに「引っ張ったらアクションを実行できる」トリガーを仕込んだのが始まりです。その特許は現在のX社（旧Twitter）が保持しているのだと思いますが、彼らは権利は保持しつつもオープンにする姿勢を示していることから、Appleをはじめさまざまなアプリがこれを採用することができています。

文化を反映する：縦書きと和暦によるUI表現

Appleプラットフォームの特徴の一つに、インクルージョン（包容的なデザインを志向すること）があります。さまざまな文化圏のユーザーたちに向けて一つの製品を出荷する場合に、誰一人として不幸にならないようなデザインを目指すことが大切であるという考え方です。

私は日本人なので日本文化的な視点からこのことを考えてみたいと思います。

日本語には横書きのほか、縦書きの仕組みも備わっています。街中に目を向けると至る所に縦書きの日本語があることに気づくはずです。歴史と文化という観点もありますが、単純に縦書きにした方が収まりが良かったり、便利であるという理由もあるでしょう。私はこのようなスライドを作る際、収まりを意識してKeynoteの縦書き機能を活用することが少なくありません。それだけ日本語が柔軟な言語であることに私は普段から助けられていますし、誇りも持っています。そして、ソフトウェアとしては珍しく日本語の縦書きを扱えるKeynoteには非常に感謝しています。

私はソフトウェアデザイナーを名乗っていますから、自らが手がけるソフトウェア（デジタル製品）においても、日本語の縦書きをはじめとする文化的な特徴を盛り込める余地を確保したいと考えてきました。かつて私がiOSデベロッパーとして手がけたアプリでは、日本語や日本文化の特徴をデジタルのインターフェイスに表すことに注力しました。このアプリには御朱印帳のような見た目のデジタルスタンプ機能が備わっていました。これを設計する際に、私はiOSネイティブの技術を使って、和暦、縦書き、漢数字への対応を行いました。しかもちょうど改元を控えた平成時代末期でしたから、新元号への対応も行わなければなりませんでした。

政府による新元号の発表はギリギリまで行われなかったため、誰一人として今の「令和」号をまだ知りません。しかし改元することは決まっていて、確実に平成ではなくなるという事実だけが差し迫っており、どのようにして対応すればいいのかを考える必要がありました。

まあでも考えてみたら意外とシンプルな方法で解決でき、システム的にも無事改元を乗り切ることができました。iOSのDateFormatterではJapaneseカレンダーで“G”を入れると元号名が取れるので、これを使って今の元号を取得、UIに反映させました。算用数字から漢数字への変換はNumberFormatterで実現できました。よくある方法で日付を整形し、あとはCoreTextに頼って縦書き描画するラベルを自作したらこのUIは出来上がりです。

新元号が発表された後にiOSが対応（アップデート配信）されると、「平成32年」という存在しない年数は自動的に「令和2年」に書きかわります。テストしかできなかったのでちょっと不安はありましたが、過去に記録された平成延長の日付も、新しいOS環境では令和に書き変わったので、私のシステムの改元もうまくいったことを実感できました。

むすび

デザインで「らしさ」を考えることは、さまざまなレイヤーにおける文化を見つめることだと思います。たぶん文化とは積み重ねで成り立っていて、人類としての特徴や言語、民族、国家、法律といった具合に多くの文脈が増していって、その先に私たちが直接関わることになるソフトウェアのプラットフォームが存在するのだと思います。ソフトウェアだけがすべてではないはずなので、その裏側にある多くの文脈を、さまざまな視点から見つめ直し、私たちが直接触れることになる製品のインターフェイスに反映してくことが大切なのだと思います。

おまけ