2015年11月ぐらいからiOSアプリを二つ制作してみました。
iOSはiPhone3GSから使っていたので、わりとアプリのインターフェースは簡単にできるだろうと楽観していましたが、どうしてどうしてデザインが決まるまで難渋しました。
こんな感じのアプリです。
|
|
よくあるまとめブログのビューアーです。
一つは「やる夫」でもう一つがSSを扱っています。
やる夫はまとめブログのコンテンツとしては特殊で、ものによっては100ページを越える長編物もあります(!)。たいていが1ページで完結するまとめコンテンツと違って、連載を順番に表示することがアプリとして必要になります。
そうなると普通のまとめブログのアプリやニュースアプリが提供しているいくつかのジャンルにわけて時系列で一覧表示するだけだと、ちょっと機能不足になるわけです。
ページタイトルの一覧だけではダメで、連載名が必須になります。さらに連載を継続して見られるように連載をお気に入り登録できるようにしなくてはいけません。またコンテンツの寿命はとても長く初出が2010年であってもずっと需要があるものも多いです。匿名掲示板とは思えないほど作品の作者が意識されてもいます。
イメージとしては「データベース的な操作ができる索引」機能です。これに近い情報を操作するアプリだとApp StoreとかiTunes(ミュージック)アプリが思いつきました。まとめブログアプリ、ニュース系アプリのようなデザインにこれを組みあわせられないかと考えました。
が、どうしてこれがiOSインターフェースの作法と合わせると難しい。
試行錯誤の末ようやくできたのが上記の画像のようなインターフェースです。
以下、各インターフェースの感想です。
UITabBarController
画面構成的にはこれが一番の親になる。moreボタンで選択肢を増やせるので割と気軽に使える。バッジ表示できるのもいい。
選択肢とその内容がそれぞれが別物の場合に使うのがよさそう。例えばメイン画面と設定画面というふうに。
逆によく似ている画面があると利用者が迷いそう。例えばpixiv。これは同一の「イラスト」を人気とかお気に入りユーザーなどの属性での表示切り替えをタブでしている。
またダイス/スライスといったデータの見せ方をコロコロ変えるような場合にはタブ移動が発生することになるので、それもよくない。
真っ先に試したUIだが、いろいろ実現したいこととそぐわなかったので結局使わなかった。
UINavigationController
ドリルダウンの表現に最適といか、そのもの。
UITabBarControllerよりは子で、位置情報を現わす基本になる。
これを使うとiOSらしい階層インターフェースになる。
と同時にこれを使うということはこれに合わせる必要がでてくる。お約束が多く、いろいろクセがある。わからないうちはこのコントローラーの制約で難渋したことが多かった。
やる夫RSSでは解決できずにではこれがうまくいってないころがある。
ボタン画像がOSに組み込まれているが種類が少ない。
タイトルの両脇にボタンをつけられる。文脈としてこのボタンは位置と連動しているかは関係なく使える。Apple純正アプリでは両方の使い方が見られる。
タイトル部分をボタンなど別のUIを埋め込むことができると結構柔軟に使える。
面倒も多そうだが積極的に使いたいインターフェース。
UISegmentController
UITabよりも表示する内容や形式があまり変わらないものに適する。
選択肢はせいぜい5個まで。文字の長さによっては上限は下がる。
ステータスとアクションを同時に表示できるので、説明不足で意味がわからないといったことは起きにくそうだ。
UITabと違ってUISegmentは選択が勝手に変更されてもあまり違和感がない。
かなり好みのインターフェース。
UIToolbar
UITabBarControllerと同じ画面下部に配置される。高さが少し低い。
UITabが選択状態を表現するのと違ってアクション用のインターフェース。
UITabを押してモーダルウィンドウが表示されるのはおかしいが、UIToolbarだとOK。
UITabは親として必ず表示され続けるが、こっちは表示モードごとにボタン内容の変更があっても違和感がない。
実際に使っているアプリは少ないような気がする。Safariくらいか。モード切り替えができるUITabがデザインの上で強力だからか。
ボタン画像がOSに組み込まれているが種類が少ない。Androidみたくもっと標準でつけてほしい。
UISearchbar
検索用UI。よくある表現は3つ。
- UINavigationControllerに検索ボタンがあって、それを押すとUISearchbarが表示されるもの。
- UITableViewの中に最初から表示されているもの。
- UITableViewのヘッダーに表示されつつも、初期表示では隠されていて、スクロールすると表示される(例:iOSの設定項目)
3番目はすっきりして開発者的には好みなのだが、気づきにくい仕掛けなので余程のことがなければ使うべきじゃない、と思う。
1はデータ全体からの検索という印象がある。2と3はフィルターとしての文字入力という感じ。
ページ内のUI
例えばApp Storeでのアプリのダウンロードボタン。ページ内部で詳細情報とあわせてアクション用のインターフェースとして配置されているもの。
狭い画面でいろいろな操作をするにはここで工夫するのがよさそうだが、センスも問われそう。
アップル純正の「ミュージック」は綺麗に配置していわかりやすい。クックパッドやpixivはやりすぎ感がある(個人的な感覚だが)。
やる夫RSSとでんぶんSSでは、これに該当するUIを「次ページ」「前ページ」のボタンしか用意しなかった。連載の各話表示ページで、作者や掲載サイト更新日などを表示してそこから再検索するというのもありだったが、見た目が冗長だと早々に見切ってしまった。
UIButton
フラットなデザインがいきすぎて、デフォルトの見た目だとボタンなのかわかりにくい。
やる夫RSSでは角丸の枠線をつけてボタンっぽくした。
このUIを使うたびにフラットすぎるデザインがきらいになる。
アイコンのような小ささだと当たり判定が厳しいと感じる。判定領域を広げている。
UITableView
作品のリスト表示に使った。
各項目の高さを計算する機能を自前で用意しなくてはいけない。Androidにはそういうったのは不要だったので最初はiOSの開発って面倒なのだとかなり萎えた。といっても開発を進めていったらAndroidにあった面倒なところがないのも多いと気づいたが。
これを表示しているとこからモーダルウィンドウを画面回転しつつ表示すると、Y座標がずれるのを何とかしてほしい。