iOS8 を含むSwift3対応時の不具合対応

Swift 2.1 から 3 へ移行する際に、大きな不具合が１つあったので、その対応を考えてみました。
※ ただし、多くの端末・バージョンで検証したものではありません。

問題

UITableViewDelegate の table​View(_:​height​For​Row​At:​) に渡される indexPath の値が間違っていました。具体的には、indexPath.row の値が、0, 1, 2, 3, … の順番で渡されるはずが、0, 0, 1, 2, … とずれてしまっていました。いざ表示してみると問題ないように見えるのですが、画面遷移時にレイアウトが崩れてしまいます。

不具合の内容や対応方法に関しては、こちらを参考にさせていただきました。

期待する動作

今回は、「table​View(_:​height​For​Row​At:​) で正しい値を取得する」ということでやってみます。

対応

まずはコードを貼ります。

Objective-C の Method Swizzling という、既存のメソッドを入れ替える機能を利用しました。Swift から Objective-C のコードを扱う方法は省きます。

まず参考サイトのように、問題となっている箇所を探っていくと、iOS8の UIMutableIndexPath *1 の get​Indexes:​range:​ で取得できる値が間違っている可能性があることがわかりました。しかし、UIMutableIndexPath は開発者側には非公開となっているので、直接書き換えることができませんでした。そのため、NSIndexPath の get​Indexes:​range:​ の値を正しい値を取得できる index​At​Position:​ で書き換えたところ、うまく動作しました。

まとめ

今回は、iOS 8 のtable​View(_:​height​For​Row​At:​) で渡される indexPath の値が間違っていることに対し、Objective-C のコードで不具合のあるメソッドを書き換え、正しい値を返す対応を考えてみました。

ただ、やはりこの不具合は怖いので、Swift3 対応をリリースする際にはなるべく iOS8 は切りたいと思っています。

*1:憶測ですが、UIMutableIndexPath はNSIndexPath を継承しているようで、iOS9 移行は使用されていないようです。

mapとforEachとfor

mapとforEach

返り値を必要とするならmapメソッド、要らないならforEachメソッドを使います。書き方は同じ。
以下forEachの例（アルファベットの一覧を作成）。

// a to Z
var chars : [Character] = []
["a", "A"].forEach {
    let scalar = $0.unicodeScalars
    let code = scalar[scalar.startIndex].value
    (0..<26).forEach {
        chars.append(Character(UnicodeScalar(code + $0)))
    }
}

forとforEach

上記コードの「(0..<26).forEach」の部分をfor文で書くと下のようになります。

for i : UInt32 in 0..<26 {
    chars.append(Character(UnicodeScalar(code + i)))
}

定数 i の型を指定するか、内部でキャストする必要があります。
詳しく調べていないので（途中でギブアップ）推測ですが、mapやforEachの内部定数は、それが使われる時に正確な型が決まるのではないかと思っています。用途によってはforEachとかの方が扱いやすくていい。

Form follows function.

"HELLO WORLD 「デザイン」が私たちに必要な理由"を読んでいて気になった、Form follows function =「形態は機能に従う」という言葉から考えたこと。

意味

あらゆるものの外観は、その機能の目的によって決まるということ。デザインするときは、それがどういう機能を有しているかを外観で表現した方が良いということになると思います。

アフォーダンスを備えたものをイメージすると分かり易いかもしれません。例えば、スプーンは指先で持ち、窪んだ部分に食べ物を入れて口に運びやすいようになっています。

もともとはアメリカの建築家、ルイス・サリヴァンの言葉で、Form ever follows function = 「形態は常に機能に従う」というのが本来の言葉だそうです。しかし、スマホのように、形態が機能に従わないケースも出てきました。

対話のデザイン

形態が機能に従わない場合、見る人使う人はそのものに触れなければ理解することができません。どういう機能を持っているのかを外観から判断できないので当然です。

使われている状態を見せるのも１つの解決方法です。僕はiPhone 6sのCMを見て欲しくなったのですが、それは新しい機能を数十秒で理解して、使ってみたいと思ったからだと思います。 また、他の製品でもあることですが、機器の説明書を読まない人も多いかもしれません。分かりにくいとか長いとか、とにかく使ってみたいとかいろいろあると思いますが、説明書も含めて一貫してデザインされていると良いのかなと思います。

もう１つの解決方法は、使いながら理解させる方法。この場合、ユーザの操作と結果が結びつかなければひどい製品だと思われる可能性もあります。対話のデザインが必要になるのだろうと思います。ユーザが目的のために無駄に悩むことなく操作し続けることができれば、それが良いUIデザインであり、僕が大事にしたいポイントでもあります。

繊細な仕事

良いUIデザインは、ユーザがその良さに気付きにくいという表面もあり、報われない仕事だと感じるデザイナーがいるらしいことは本書でも書かれています。しかし言い換えると、ちょっとでも間違ったデザインはすぐに悪い評価を下されてしまう、とても繊細な仕事のようにも聞こえてきます。質の悪いものは誰も作りたくないと思うので、とても価値のある仕事だと僕は思います。

形態が機能に従わなくなったとき、デザイナーはすぐに、人とモノとがコミュニケートするための新たな方法を見つけなければならなくなった。

グッドデザイン賞では、円形のディスプレイもありました。こういうものとどうコミュニケーションさせていくか、とても興味あります。

タンジブルとインタンジブル

奥出直人さんの「デザイン思考の道具箱」を読んでいます。半分ほど読み終えました。今回は気になったワード「タンジブル」「インタンジブル」について。

タンジブル、インタンジブル

「タンジブル」とは、実体のあるものとか、触れることができるものという意味だそうです。「インタンジブル」とはその逆で、サービスという言葉に置き換えると分かり易いかもしれません。

例えばディズニーリゾートに行った場合のことを考えてみます。ディズニーランドもシー、いろんなキャラクターと触れ合うことができますし、ミッキーの 耳（カチューシャ）や手（手袋）を付けながら遊ぶことができます。これらはタンジブルといえます。一方、シンデレラ城を背に写真を撮ったり、様々なショーやパレードを見て楽しむこともできます。これらはインタンジブルといえます。

最近始まったアマゾンジャパンの「プライムナウ」はもともとあるサービスにインタンジブルな要素を追加した良い例かなと思います。

相互に変換してみる

普段、アプリやWebの製作ばかりやっていると、あまりタンジブルを意識するケースが少ないように感じます。もちろんサービスの種類にもよりますが、例えばスマホ向けのゲームを開発している場合は、ちょっと難しいかなと思います。 なのでちょっと考えてみようかと。

例えば配達物の不在届け（タンジブル）を情報化して、再配達の日時をスマホや携帯ですぐに設定できるようなサービス（インタンジブル）に変えるとか。ココナラのようなサービスで、サービス会社を経由してお礼の手紙を送ることができるサービスとか。

タンジブル・ユーザインタフェース（TUI）

そんなこんなでタンジブルについて調べてみると、TUIというものがあるらしい。この記事がとても面白かったです。スマホを運んできてくれるところなんか特に面白くて、すごく未来的な感じがする。たまに出かける際にテーブルの上に鍵を置いたまま玄関まで行ってしまうことがあるので、怠惰な僕はテーブルや床が動いて持ってきてくれると面白いなとか考えたり。

おわり

たまにはアプリやWebなどの電子的な情報的なものから離れてデザインを見てみるのも面白いなと思います。デザイン思考関連の本ではいろんなサービスの事例を知ることができるので、とても面白いです。

ポートフォリオサイトを眺める

　ポートフォリオサイトを作ろうと思い、いくつか見てみて感じたことを書きます。

チャレンジ

　以前読んだ「センスは知識からはじまる」で紹介されていた方法を実践してみようかと思っています。やり方は、「定番」「流行」「共通項」それぞれを分析すること。

　まずは「定番」の分析から。といっても、定番のポートフォリオサイトがどういうものか全く分からなかったので、サイトのデザインならWebデザイナーだろうと思い、Webデザイナーが作っているサイトのみ見て回りました。有名なデザイナーや、ポートフォリオサイトをまとめているところを参考にいくつか。

意外と一貫性が大事

　デザインの一貫性に関してはwebデザインのみならず、デザイン全般に言えることだと思います。そんななか、見ていて気になった一貫性が欠けていると思われる箇所を２点ほど挙げます。

　１つはナビゲーションについて。特にグローバルナビゲーションというか、どのページでも同じように表示されており、各種メインページ（もしくは場所）へのリンクをまとめたものです。ここに「Works」や「About」などのリンクを置いている方が多いように感じる一方、たまに「Blog」を載せている方もいました。もちろん、同一サイト内にブログもある場合は問題無いのですが、別サイトへ飛ぶ場合は設計上良く無いのではないかと考えます。

　別サイトへ飛ぶ「Blog」リンクがグローバルナビゲーション内にあると良くない理由としては、その特性上「どのページでも同じ見た目、同じ順番、同じ機能を有している」べきであるからです。別サイトへ飛んだ時にグローバルナビゲーションが無くなった場合、ユーザを迷子にさせてしまいます。ブログリンクを押した後すぐにブログサイトへ飛ばす必要も無い場合もあるかと思うので、ブログサイトの紹介ページなどを作り、そのページから遷移させるようにすると良いのではないかと思います。

　もう１つは、ちょっと全体的な感じにもなってしまいますが、見出しやコンテンツ領域の見た目です。見出しは、一貫してフォントやサイズが同じであるかどうかで、例えば作品ページであれば「作品」とか「Work」と書かれていたり、作品のタイトルがこれに当たります。コンテンツ領域は、レイアウトや背景に使っている画像等がどのページでも同じであるか、異なったとしても何らかの関連性があるかどうかです。

　WebデザイナーManaさんのサイトが良い例かなと感じています。トップページにある「マナです」から始まる文言とその他のページの見出しのフォントサイズが同じで、さらにこのフォントサイズが結構大きめなので遷移しても見出しであることが明白です。さらに、すべてのページでコンテンツが白い紙のような背景の上に載っており、作品一覧ページ以外は概ね画面に収まる大きさになっています。これらが良くない設計の場合どうなるのか。

　見出しやコンテンツ領域の見た目が異なる場合、ページ遷移した時に再度それらの情報の理解から始めなければなりません。どこが見出しなのか、コンテンツはどこからどこまでかなどです。こういったことを意識させないデザインが必要なのかなと思います。

　主要なページ数が少なくなりがちなポートフォリオサイトが（１ページのみのサイトもあるが）、情報が多くなる場合はこういった点に気をつけてみようと思います。

Webフォント

　Webの知識はちょっと疎いので、画像かと思ってたロゴがテキストだった、というサイトがいくつもありました。コードを見てみるとWebフォントを使用している方もいて、これは難しくなるなぁと感じました。

　大学時代に講義の課題でサイトを作成した際に、もちろんフォントの指定を行いました。ただその時は、WindowsでもMacでも、ちょっと古いOS、ブラウザで見ても表示が崩れないように、という意図から標準的なフォントを指定していました。しかし、近年なのでしょうか、Webフォントを指定するデザイナーが増えてきているとのこと。ということは、全文ではないにしろ、見出し等においてはデザイン的な理由がしっかり求められるようになりそうだなと思いました。必要な箇所でデザインに沿ったフォントを指定していくことが重要だと思うので、フォントについてもきっちり勉強しなければ、と。

レスポンシブ対応

　業界的にはもしかすると当たり前なのかもしれませんが、Web初心者の僕からするとレスポンシブ対応されているサイトはやはりすごいなと感じます。特に３段階に分けてデザインされているサイトは面白かったです。実装上の知識・技術もそうですが、複数の状況に合わせたデザインを考えなければならないため、とても興味深く見させてもらっています。

　スマホで見るサイズとなると、グローバルナビが起きにくくなる場合があると思います。そのため、メニュー用のアイコンを作成し、タップするとメニューがプルダウンで表示されるようなタイプのデザインもありました。また、これはデザイン的な話ではないかもしれませんが、作品一覧画面等は結構重い場合もあるので、一度に読み込む作品の数を柔軟に変更すると良いのかもしれません。

今回のまとめ

　これを始める前は、自分が好きだと感じるサイトを参考にしつつデザインを考えようとしていました。単純にかっこいいとか可愛いという主観のみではデザインとは言えないなと感じ、「センスは知識からはじまる」に書いてあった方法を試し始めました。結果として、まず定番といえるサイトかどうかは分かりませんが、いくつかのサイトを見てみて基本的な要素の一部でも気づけたと思うので、まずは第一歩かなと思います。最初はこんなもんなのかなと。おそらく本で解説されていることと趣旨が異なっていると感じてはいますが、一度このままやってみようかなと思います。

余談

　なんとなくブログの書き方を「ですます調」に変えてみました。これまでも何度か無意識に「ですます調」になっていたので、もしかしたらこっちの方がやりやすいのかなと思い変えました。

「センスは知識からはじまる」を読んだ

クリエイティブディレクターで、good design company の代表である水野学さんの著書「センスは知識からはじまる」を読了。タイトルを書店で見かけた２ヶ月前からずっと気になっていた本で、内容も難しく書かれているものではないので、一気に読んだ。
今回は、前から考えていたことで腑に落ちたことをいくつか。

「わからない」は知識不足

とある絵画に数億円の価値があると聞いて、なんでこんな落書きみたいな絵に？と思った経験は誰にでもあると思うけれど、そもそも芸術に関して深く学んだ経験がある人も多くない気がする。また、よく「見る目が無い」という言葉を聞くけれど、知らないものや情報が少ないものの評価はできない。

身近な例もある。Tシャツ１枚に１万円以上出す友人がいたとして、GUとかで定期的に数枚買う僕からすると、やはり分からない。友人はとてもファッショに詳しく、いろんなお店やブランドを知っているし、買った服の詳細を説明できるが、対する僕はファッションとか服に関する知識は全然無いので、ある値段以上になるとどれも同じ見た目に見える。

見えている範囲の情報でしか判断できないし、例えば生地についての知識が少なければ、その部分の情報を見逃すことになる。見逃した情報が多ければ多いほど、現状知っている狭い範囲内だけで価値を見出すしかない。つまり知っていることが多い人ほど価値観の振れ幅が大きいのだと思う。

感性デザインもロジカルに考えられる

僕は、デザイナーはデザインしたものの説明をできなければいけないと思っている。エンジニアが慎重に、ロジカルに設計を行わないといけないように、デザイナーにも同じようなことが求められると思う。

ノーマンの著書「エモーショナル・デザイン」でも語られているが、使いづらいと分かっていても気に入ってしまうものがある。感性デザインについて深く知ろうとしていなかったこともあるが、「なんとなく好き！」と思わせる感性デザインは作り手のセンスが重要なんだろう、と思っていたので、表題の本とつながった。センスが良いものであるなら、知識をフル活用してデザインされたものであるだろうし、つまり言葉で説明可能である。

センスはつくれる

「かわいいはつくれる」を実現している人たちがいる。顔の形とか身長とか、自分だけではどうしようも無いこともあるが、それ以外の部分には伸びしろがある。

センスが良い・悪いと言われる人やものというのは、おそらく大勢の人にそう言われているのだと思う。１人２人が言っているだけではセンスが良い（悪い）とは言わない。つまり大衆、もしくはあるジャンルの中での大半に受け入れられているということ。アーティスティックに作り上げたものが評価されることもあるだろうが、著者は大衆をよく観察し、長くヒットしているものや流行のものを分析し、そこで得た知識と既存の知識との組み合わせで新しいものを作っている。それが「センスが良い」と言われているのだから、センスも作り出すことができる。

余談

感性デザインについて自分の経験から考えたことを雑に書いてみる。

僕は家で使っているマグカップをとても気に入っているが、ちょっと使いづらい。持ちにくくて、少しの間持っていると取っ手に掛けている指が痛くなる。痛くならない持ち方もできるのだが、カップに直接指が当たってしまい、熱いコーヒーを飲んでいる時にはつらい。でも気に入っている。

マグカップにはムーミンの絵が描かれている。ムーミンだけでなく、ムーミン谷の他のキャラクター達も微笑ましく描かれている。僕と同じ２０代で知らない人はいないだろうし、嫌悪感を抱く人もいないと思う。もともとフィンランドの芸術家が風刺画として描いていたこともあり、原作はちょっと怖さが混じっている。お国柄の表現もあるのだろうけれど、その独特の表現はデフォルメされた後は可愛らしいのだが、全面的に幼稚なイメージであるわけではない。このあたりはもう少し深掘る必要はあるが、若い大人にも受け入れられるような見た目だと思う。さらにこのマグカップを色違いの２種類用意しておけば、カップルの目にとまるだろう。一緒に買うということになれば、お互いのお気に入りにもなると思う。

iOS HIGを半分程読んでみて

iOS ヒューマン・インタフェース・ガイドラインを半分程読んだので、一旦考えたこと等をメモ。

いつ停止しても良いようにする

ユーザはいつアプリを閉じるか分からない。僕の場合は、ちょっと処理が重いなとか、画面が固まってしまった場合にアプリを閉じることがある。そのとき、データが消えてしまうことは許容できる場合もあるが、怖いなと思うものもある。
こういう場合の安心感の与え方は、やはり経験を積ませることだろうか。例えばデータの同期（サーバとの通信）に時間がかかりすぎてアプリを閉じたユーザが再開したときに、同期の続きを行うかどうかを問えば（もしくはうまく同期されていたことを伝えれば）、前回の自分の操作の続きという缶感覚になるので安心感につながるのではないかと思う（自分の操作が無かったことになったわけではなく、そのステータスが分かるので）。

モーダル型の画面

iOS標準のメールアプリでメールを新規作成するときは、モーダル型の画面が下から出てくる。メールを書くことに専念できる画面が表示される。何をすべき画面なのか分かりやすいし、ナビゲーションバーにある送信ボタンかキャンセルボタンを押さないと画面は消えないので、誤って画面が消えることもないだろう。
今度、もう少し考えてからまとめて書こうと思うが、ニュース系アプリとSNS系アプリでは、URL（web上の記事）を開く際の挙動が異なるように思う。ざっくりいくつかのアプリを見ただけだが、ニュース系アプリは画面遷移を伴って（右方向へのスワイプで戻れる状態で）記事のサイト、もしくはダウンロードしておいた記事を表示する。対してSNS系アプリではモーダルビューとして表示するので、ナビゲーションバーにある閉じるボタン等を押さないと閉じない。後でもう少し意図を探ってみたい。

色のコントラスト比

このあたりは全然知見が無いのだが、前景色と背景色の輝度の対比を測定することが推奨されている。理想としては4.5:1ということらしいが、まだちょっと分からない。これがWebのWCAG 2.0規格で計算式が決められているとかで、そういうのもあるんだなと。

色の使いすぎ注意

たくさんの色を使うのを注意しようというわけではなくて、iOS標準アプリのような色の少ないアプリにおいて、ナビゲーション用のボタンと同じ色をコンテンツ領域で多用するのは良くないのかなと思った。理由としては、アクセントとか重要なポイントに色を付けることはあるかもしれないが、色が付いている箇所をユーザがボタン等と思ってしまう可能性があるのではないかと。なんの意味があるんだろう、と思わせてしまってはいけないので、初心者の自分はちょっと注意が必要かなと思っている。

HIGは勉強になる

数年前に軽く読んだことがあるが、内容が結構抜けていた。改めていろんなアプリや自分の経験と照らし合わせながら考えていくと、面白く学べることが多い。
読んでいて感じたのは、デザイナーだけが読むべきものでは無いということ。デザイナーだけではユーザに届けられないようなことも書かれている。例えば、いつアプリが停止しても良いように、コンスタントにデータを保存するようなことはエンジニアが必ず関係してくるので、お互い理解しておく必要があると思う。