2013-02-24

ワイヤフレーム作成ツールの料金プランをまとめてみる

UI/UX

自社のUXの質をあげていこう！なんて意気込んでいて、今後は下の記事でとりあげられているようなワイヤフレーム作成ツールを使っていこうとひっそり考えているのですが、やっぱり会社で導入するとなると気になるのが値段だったり機能の制限だったり・・・。

楽しく作れる！スマホアプリ/サイトのワイヤーフレーム・モックアップ作成支援ツール7選

ということで、今回は上のブログでとりあげられているサービスの料金プランだけに絞ってエントリを書きます。まあキャプチャしたもの貼っていくだけですがw

Fluid UI

http://www.fluidui.com/

f:id:ushisantoasobu:20130224211027j:plain

フリーだと、「1プロジェクト」「10画面」「ファイルアップロード上限10MB」。

Proto.io

http://proto.io/

f:id:ushisantoasobu:20130224211038j:plain

InVision

http://www.invisionapp.com/

f:id:ushisantoasobu:20130224211029j:plain

Prototyper

http://www.justinmind.com/prototyper/

f:id:ushisantoasobu:20130224211039j:plain

フリーのものだと機能が限定されるようだか、有償版との違いはこちらを参考に。

Moqups

https://moqups.com/

フリー

Cacoo

https://cacoo.com/

f:id:ushisantoasobu:20130224211016j:plain

Pencil

http://pencil.evolus.vn/

フリー

はじめに紹介したサイトにも書いてありましたが、それぞれのツールには一長一短があると思います。なので何の目的で、何を達成するためにツールを使うのかというのを念頭に置いて選択するべきかと思います。

自分の場合だと、実際に使われたときに本当にいいUXが得られるのかをプロジェクトの早い段階で確認できるようにしたい、という目的なので、作成したプロトタイプをwebに書き出せる機能（そしてそれを実機で電車の中とかでさわれるようにする）は必須なんじゃないかと思っています。

いまはまだFluid UIを一通り触っただけですが、他のものも触ってみておもしろいことがあったらエントリ書きたいと思います。

2013-02-17

iOSでアプリ側の強制終了はリジェクト対象！？

Objective-C

備忘録として。

現在業務で開発しているiOSアプリでそろそろ佳境を迎えようかというときに、仮に記述していただけなのかもしれませんが同僚の書いたソースコードに、

exit(0);

という記述があってドキッとしてしまいました。というのも、この記述でアプリ自身を強制終了することができるのですが、アプリ側で強制終了するのはリジェクト対象といった内容のサイトで散見していたからです。
ということでアップルのガイドラインをみてみようと思います。

プログラミングによって終了させない
iOSアプリケーションはプログラミングによって終了させないようにします。これは、ユーザがプログラミングによる終了をクラッシュと解釈する傾向があるためです。ただし、外部の状況によってアプリケーションが意図した通りに機能しなくなっている場合、その状況をユーザに伝えて、それについてユーザができることを説明する必要があります。アプリケーションの障害がどれくらい重大かによって、次の2つの選択肢があります。
ユーザの注意を引く画面を表示し、その画面で問題を説明し、修正を提案する。画面は、アプリケーションによる不具合ではないことをユーザに伝えるフィードバックを提供します。ユーザに制御を渡すことで、状況を改善するためのアクションを取ってアプリケーションを継続するか、ホーム(Home) ボタンを押して別のアプリケーションを起動するかをユーザが決定できるようにする。
アプリケーションの機能の一部のみが動作しない場合、ユーザがその機能を有効にしたときに画面またはアラートのどちらかを表示する。アラートは、動作しない機能にユーザがアクセスしようとするときにのみ表示します。

これって・・・どういうことなんだろう？
いずれにせよ、強制終了はさせないほうが無難な気がします。

2013-02-17

"Portrait"に設定しても画面が横向きになってしまう

Objective-C Xcode

現在業務で開発しているiOSアプリ（iOS5以上を対象）の動作確認をしていたときに、
iOS6.xでは発生しないが、iOS5.xだと"Supported interface orientations"を"Portrait"に設定しているのに画面が横向きになってしまう
という不具合が見つかりました。

原因は、あるUIViewControllerのクラスのソースに

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
    return (interfaceOrientation != UIInterfaceOrientationPortraitUpsideDown);
}

という記述があったからです。
デバイスの向きに変更があったときに呼び出される処理で、上の記述だと「検出された向きが上下逆さま以外のときにはその向きに対応する」となってしまっています。

なので縦向きのみに対応するよう以下のように書き換える、

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
    return (interfaceOrientation == UIInterfaceOrientationPortrait);
}

またはこのメソッド自体削除してしまってもOK。

iOS6ではなぜ問題なかったかというと、"shouldAutorotateToInterfaceOrientation"メソッドはiOS6では動かなくなってしまったようだ（参考サイト:shouldAutorotateToInterfaceOrientation:はdeprecatedだよ！）。

「上下逆さま以外の向きに対応」の記述が混じってしまったのは、プロジェクトを作成したときにデフォルトで生成されるUIViewControllerをそのまま使用していたのですが、そこには上記のような記述がはじめから書かれているのが原因だったようです（Xcodeのバージョンにもよるのかもしれませんが）。

いずれにせよ"Portrait"に設定しているのに画面が横向きになってしまうなんてことがあれば、上記メソッドの確認をしてみると解決するかもしれません。

2013-02-03

【第５回】iOSアプリ ticket to UI/UX

UI/UX

Vineのホームメニュー

Twitter社がつい先日リリースした動画共有サービス"Vine"。
まだリリースしたばかりで色々改善中かもしれませんが、一番はじめに目についたのが左上の「ホームボタン」の存在だ。

f:id:ushisantoasobu:20130203195533j:plain

このホームボタンを押せば、以下のようなメニューが上から表示されるわけだが、

f:id:ushisantoasobu:20130203195541j:plain

要はタブメニューの代わりの役目を担っているわけだ。
Vineのタイムライン上のデザインの構成を考えると、もしタブメニューを配置してしまったら、動画画面全体は表示できるかもしれないがプロフィール画像や投稿のタイトルがギリギリ切れてしまう（iPhone4S以下）、ということでの対応だろう。
ただし一度ボタンを押さなければいけない、しかも右利きの人間が片手で操作するときに一番押しにくい（遠い）位置にホームボタンを設置したというこの選択が、先ほどもいったようにリリースしたばかりということで今後も改善がなされてくうえで変更が入るのか、を見守っていきたいと思います。

スクロールをTOPに戻す

現在iOS開発を業務で行っていて、担当している機能の１つに「テーブルビューを用いたリストの表示」があるのですが、同僚に以下のようなことを指摘されてしまった。

「あれ、ステータスバーをタップしてもTOPに戻らないっすね」

・・・実は自分はこれを知らなかった。ただアップルのヒューマンインターフェイスガイドラインにも確かに書いてあった。

ホームページアイコンを配置し直す。 Webサイトは、各Webページの最上部にホームページにリンクするアイコンを表示することがよくあります。iOSアプリケーションにはホームページは含まれないため、この動作は不要です。さらに、iOSアプリケーションでは、ユーザがステータスバーをタップすると、長いリストの最上部まですばやくスクロールして戻ることができます。タップ可能な「ホーム(Home)」アイコンを画面一番上の中央に配置してしまうと、ユーザがステータスバーをとてもタップしにくくなります。

自分が知らなかったからということもあって、「このUIってどうなんだろ・・・ステータスバーみたいな細いところ（ましてや上）タップしづらいよ！！」と叫びそうになってしまいましたw

自分にとって馴染みのあるのは、現在選択中のタブメニューをタップ（またはダブルタップ）するというもの。
下の画像は"Tweetbot" ですが、現在選択中のメニュー（画面でいうタブメニューの一番左のボタン）をダブルタップすることでタイムラインの先頭に一気に戻る。

f:id:ushisantoasobu:20130203203728j:plain

他にも、わかりやすいようにと"TOPに戻るボタン"のようなものを表示させているものもある（下画像の右下の「^」ボタン。"CodeNote"）。ただしこれはメインの画面の上に乗ってしまっているので考慮が必要だ。

f:id:ushisantoasobu:20130203204148j:plain

とはいえ「ステータスバーをタップ」はAppleのガイドラインに書いてあるものなので、何よりもこちらの実装の漏れがないように気をつけよう。

2013-02-03

UITableViewCellの再利用でメモリリーク

Objective-C Xcode

UITableViewCellでハマってしまったので備忘録。

UITableViewCellは基本的に再利用します。アップルのドキュメントをそのまま引用すると

オブジェクトの割り当ては、パフォーマンスに影響します。特に、短期間に繰り返して割り当てを行わなければならない場合(ユーザがTable Viewをスクロールする場合など)は影響が大きくなります。セルを新規に割り当てる代わりに、セルを再利用すると、Table Viewのパフォーマンスを大幅に向上させることができます。

だからです。その方法としては下記のようになります。

- (UnitTableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    UnitTableViewCell *cell = (UnitTableViewCell*)[tableView
                                                   dequeueReusableCellWithIdentifier:@"UnitTableViewCell"];
    if (cell == nil) {
        NSLog(@"cellを新規に生成");
        UINib* nib = [UINib nibWithNibName:@"UnitTableViewCell" bundle:nil];
        NSArray* array = [nib instantiateWithOwner:nil options:nil];
        cell = [array objectAtIndex:0];
    }
    
    [cell setData:[_dataList objectAtIndex:indexPath.row]];
    
    return cell;
}

上の例だと、"setData"メソッドでそれぞれのセルの情報をセットしています。

しかしなぜか何度も再利用しているとメモリリークで落ちてしまうという現象が発生しました。。。
よくあるミス（他の方のブログをみて、または自分自身でも経験ありw）が、セルのidentifier名の割り当て漏れ。下画像赤枠部の箇所にはしっかり同名のidentifier名を入れてあげましょう。

f:id:ushisantoasobu:20130203143340p:plain

これについては、"cellを新規に生成"というログが毎度毎度出力されないことが確認できればOK。
（逆にいうと、ここの出力数でいくつのセルを生成してあとは再利用されているのかがわかります）

ただし今回のエントリで言いたいのはもっと凡ミスな話です。
というのは、上の"setData"メソッド内で、つまりはセルに情報をセットしてあげるたびに以下のようにある表示オブジェクトを毎度インスタンスとして生成していたからでした。

    _canvas = [[CanvasView alloc] initWithUnitData:data.unitData];
    [self addSubview:_canvas];

再利用しているのですからこれではどんどんメモリがたまっていきますね。なので以下のようにして再利用前にインスタンスを削除する、またはそのインスタンスの中身を変更するようなメソッドを用意してあげればいいです。

    if (_canvas) {
        [_canvas removeFromSuperview];
        _canvas = nil;
    }
    _canvas = [[CanvasViewController alloc] initWithUnitData:data.unitData];
    [self addSubview:_canvas];

いやー、凡ミスですねw
ただセルの中身が複雑だとついこのようなことがあるかもしれないので注意です >

2013-02-02

「ユーザーを虜にするUI/UXとは！？－実務と学術の両面的視点から徹底解析！！－」に参加してきました

UI/UX

はじめて勉強会のエントリーを書いてみようと思います。幾分個人の勝手な解釈も含まれていることと思いますがご容赦を。。

参加してきた勉強会は、2013/01/28にレバレジーズ株式会社本社にて開催された「ユーザーを虜にするUI/UXとは！？－実務と学術の両面的視点から徹底解析！！－」です。
サブタイトルにもある通り、前半は実務（企業）サイドから、後半は学術サイドからの講演という構成。そのあとで、４人によるパネルディスカッションが行われた。

スライドのデザインがそれぞれ企業/アカデミックらしくて個人的におもしろかった。

つくるべきものをつくる

藤井幹大氏・坂田晃一氏（株式会社ジェネシックス）

つくるべきモノをつくる from Mikihiro Fujii

まずおもしろかったのが、「なにをつくるべきか？」「よいものとはなにか？」という答えを出すために「UXデザイン定義書」というものを作成し運用しているという話だ。中身としては、

課題
ゴール
ユーザモデル
UXデザイン定義ステートメント

の４点を仮説項目として挙げそれをチーム全体で共有することで、「精度の高い仮説と継続的コンセンサス」を実現できるというものだ。コンセンサスという言葉の意味を知らなかったのですが、ここでは個々人の意識の統一という意味であってると思います。
ではこれで本当によいデザインがつくれるのかというと、、、答えは「ノー」という（orz）。なぜならデザインはどんなに考え抜いてもそれはあくまで仮説でしかないからとのこと（納得！）。ではどうするべきか、、、リーンスタートアップの考えを参考にしたという。
リーンスタートアップ。さすがに言葉は知っているけれど細かなことは正直知らなかった。なので大雑把にしか理解できなかったのですが、「仮説→検証・計測」を素早く繰り返すことで、さきほどの「あくまで仮説にすぎない」ものの精度をもっと高めていく、ということだと思う。「仮説→検証・計測」を素早く繰り返す上で実際に行われることとして、プロトタイプの作成（実際に動くものをつくることが大事でペーパプロトタイプは推していなかった）、ツールを導入してのユーザの行動の計測などの話をされていました。
他、個人的に心に響いた話としては、

エンジニアはプロトタイプの作成だけでなく、計測などのフィードバックサイクルにも関わっていけるようにならないといけない
上の立場の人間の意見にどうしても納得いかないときは、自ら仮説を立ててそれを計測して示してやればいい

といったものです。ここらへんは非常に興味深いし、もっと自分でもやっていきたいと思いました。

（すいません、タイトルのメモ忘れました）

五十嵐悠紀氏（日本学術振興会特別研究員PD（筑波大学））

次は少し趣向が変わって手芸の話。手芸とUI/UX！？少し戸惑いがあったが、内容としては「オリジナルの手芸作品をつくるのにおいて、型紙をつくるのは大変難しい。そこで"インタラクティブなぬいぐるみデザインシステム"というのものを作った。これまでは限られた人にしかできなかったようなことを、このシステムを用いることで誰もが簡単にオリジナルの手芸作品の設計をできるようになった」というもの。デモもありましたのでわかりやすかったです。で、そういったシステムを使いやすいものにするUIだったりを（ぬいぐるみなので３次元での情報を表示するところもありましたが難しいですよね）ワークショップなどを通じて研究しているといるとのことですが、具体的にどういった工夫をそのUI設計に適応しているのかなどの話をもっと聞きたかったです。

“UI/UX”？～恥をかかないための15分UXD入門

安藤昌也氏（千葉工業大学デザイン科学科准教授）

“UI/UX”？～恥をかかないための15分UXD入門 from Masaya Ando

安藤氏が今回の講演で一番時間を費やしたのが、先日twitterで話題になっていた（少なくとも私のTL上ではw）「UIの改悪がUXを改善させる場合」について。真意はわかりませんが、「もっと各々が本当に良いUIとは、UXとは」を突き詰めてほしいということだと思います。他ご自身もおっしゃっていたように説教臭い内容がいくつかあって、たとえばUXとUXDの違いをしっかり理解してほしいという話もされていました。

UX = 個人的な体験
UXD = どんな経験をしてもらうかの計画をすること、またその生産（量産）の仕組みをつくること

他面白かったのはUXを４つの時間的区分に分けていた話。「予測的UX」「一時的UX」「エピソード的UX」「累積的UX」。確かに、学問としてUI/UXを掘り下げるのもおもしろい話がたくさんあったり、有用なものがあるんだろうなと思えました。

パネルディスカッション

これについては個人的に印象に残っている話をいくつか書いていこうと思います。

Twitterで自社サービスについてつぶやいてくれたユーザをみつけたとき、そのユーザのつぶやきを一番古いものからみていって「どんな人生歩んできた人なのか」を調べ、そこからグルーピングしたりもした
良いUIをつくるには、悪いUIをみつけることが大事だ。なぜならそこには「こうあるべきだ」というものが存在していたから。だからその悪いUIはなぜ悪いUIなのかを調べることで良いUIができる
悪いUIをみかけたらすぐにシャッターをきってEvernoteにためている

以上になります。最後に余談。

禿同 @prototechno: アンケート書かせたいのならば、椅子の移動はなるべくさせないとか… 導線の設計がまったく出来ていない… 空間設計してください… #hikalab
— ばやちゃんさん (@planair) 2013年1月28日

この手の勉強会の開催はこういうこと指摘されるから大変だww

2013-01-25

Xcodeのコードスニペットを活用する

Xcode Objective-C

今回も備忘録として。

現在業務ではXcodeでのiOS開発を行っていますが、コードスニペットをちょいちょい活用しています。

Xcodeで"for"などとコードを入力すると、for文のテンプレートが表示されるアノ機能のことです（下画像）。

f:id:ushisantoasobu:20130125020546p:plain

似たような記述が多く出てくるところ、たとえば

・delegateを実装するさいのプロトコルまわりの記述（最後に記載）
・APIのリクエスト/レスポンスの記述

なんかに自分は利用しています。他にもいろいろ使いどころはあるはずですが。。

スニペットを用いることでdelegateも臆することなくガンガン使えるようになりました（笑）。
利用方法は簡単で、

スニペット化したいコードを選択して、ユーティリティエリアのライブラリペインのコードスニペットライブラリへドラッグする
新規スニペット登録画面になるので、スニペットのタイトルやスニペット呼び出しのショートカット文字列を指定する

だけです。

次のサイトが個人的に一番細かくまとめられていると思いました。
http://cocoadays.blogspot.jp/2011/06/iosmac-xcode4.html

で、今回備忘録として書いておきたかったのが、そのサイトにも説明されているのですが、文字列を置換用に塊として設定する方法のメモ。
といっても簡単なことで、スニペット編集画面にて

<#XXXXXXXX#>

と囲んであげるだけでした。ということで自分は下記のようなスニペットをdelegateを書くときに利用しています。

f:id:ushisantoasobu:20130125020533p:plain

まあdelegateのプロパティは@Interface内に移さなくてはという作業は発生しますが、、、
もっとなにかいい方法あれば教えていただけませんか？？

Fluid UI

Proto.io

InVision

Prototyper

Moqups

Cacoo

Pencil

Vineのホームメニュー

スクロールをTOPに戻す

つくるべきものをつくる

藤井幹大氏・坂田晃一氏（株式会社ジェネシックス）

（すいません、タイトルのメモ忘れました）

五十嵐悠紀氏（日本学術振興会 特別研究員PD（筑波大学））

“UI/UX”？～恥をかかないための15分UXD入門

安藤昌也氏（千葉工業大学 デザイン科学科 准教授）

パネルディスカッション

五十嵐悠紀氏（日本学術振興会特別研究員PD（筑波大学））

安藤昌也氏（千葉工業大学デザイン科学科准教授）