アプリの実装をしつつサーバーについて考えていきます

- 広告 -

サーバーを選定しますよ

以前も一度やりましたが、あれから時が経って状況も変わってきたのでもう一度見直します。
とりあえず、勉強も兼ねて今回はクラウド一択です。
モバイルアプリ向けのサーバーシステムはmBaaS(mobile backend as a Service)とも言います。
クラウドのモバイル向けバックエンドサービスを比較検討して見ることにします。

候補はクラウドサーバーの先駆者[AWS]、Xamarinとの愛称はいいはず[Azure]、Googleもあるよ[GCP]。
今回はこの3つを比較検討していきたいと思います!

機能比較表とか作ってみようと思ったのですが、対応するサービスがよくわかんなかったので、やりたいことに対するハードルで比較することにしました。
そして、アプリのバックエンドとして使うならGCPではなくFirebaseの方が妥当だとわかったので、Firebaseで比較します。

2018.6.1現在

AWS Azure GCP
APIをPython+サーバレスで実装
簡単にDBを実装
アカウント管理ができる(認証)
PUSH通知の実装
アプリ内課金できるか

[APIをPython+サーバレスで実装]
AWS – Lambda
Lambdaを作成するときにpython 2.7と3.6のどちらかを選択する。

Azure – Azure Functions
デフォルトのバージョンは2.7.8だけど3にアップデート可能
*Experimentalサポートと言うところが要注意だけど、今後に期待?

Firebase – Cloud Functions for Firebase
基本的にnode.jsのみ。

[簡単にDBを実装]
AWS – dynamoDB
Azure – Cosmos DB
Firebase – Realtime Database

[アカウント管理ができる]
AWS – Amazon Cognito
Azure – バックエンド サーバー SDK
Firebase – FirebaseAuth

[PUSH通知の実装]
AWS – AWS Mobile SDK
Azure – Azure Notification Hubs
Firebase – Firebase Cloud Messaging

[アプリ内課金できるか]
AWS – サービスのメソッドがあるっぽい

Azure – 自分で実装(サンプルコードあり)
ただしpythonではない。
IAPを検証するAzure関数と言うのがあるらしい。ここだけC#で実装しても問題ないかな。

GCP – 自分で実装?
資料あんまり見当たらない?見つけれませんでした。。。

- 広告 -

初めからAzureに決めてました。(実は出来レースでした)

上の表を見た限りではAWSが最強な気がしますが、アプリをXamarinで作る都合上、Azureの方が相性がいいんじゃないかな?と言うことで、 Azureを使おうかと思います。
では、なんでわざわざ比較検討したの?って話ですが、いざ使い始めて「必要な機能が使えなかった」とか、「別のサービスの方が使いやすかった」とかってなると残念な結果になってしまうからです。
なので、使い始める前に必要な機能が使えるのが、他にもっと良いツールがないかを検討して見ました。

今回の結果を見た感じ、情報の量や機能の充実感だとAWSはダントツ良さげです。Azureはアプリ内課金などの機能は自分で実装する必要がありますが、サンプルコードもあるしネックにはならなさそうです。

そうなると、Xamarinと相性の良いAzureを選ぶのが良さそう。

Zaureを使うとしたらどんな構成になるのでしょう

と思って考えて見たのですが、作ってみないことにはさっぱりわかんないですね。
ということで、実際に試行錯誤しながら作っていこうと思います。

今回はAzureを使うことを前提に機能比較してることもあって、大事なことをやってません。
それは、価格比較。どっちにしろ従量課金なんで正確な料金はわからないですが、なんとなくこんくらいかな〜みたいな感じで算出して見ました。

料金計算ツール

最初の一年はほぼ無料で使えるのでそんなにビビることもないのかもしれませんが。

そもそも、これで全てのリソースなのかも定かではなかったりします。あやふやで申し訳ない。
この辺は実装しながら見つけていこうかなーって感じです。
だれか詳しい人教えて欲しい。。。

- 広告 -

画面遷移とか変えたので設計書も作り直しましょう

- 広告 -

作り直したら名前が設計書から仕様書になってました

設計書なのか仕様書なのか。。。今回作ったのは前半は仕様書、後半は設計書といった感じでしょうか。
前回と同じく、「概要」、「画面遷移図」、「画面仕様」、「ファイル構成」、「データ構成」、「通信仕様」といった構成になっています。
相変わらず、サーバー側の設計がぼんやりしてます(苦笑)。

と言うことで、今回作った仕様書はこんな感じ。
仕様書

画面を減らして機能も削ったので、以前作った仕様書よりはかなりシンプルになったはず。
そして、前回の失敗を踏まえ普通のWordで作りました!なので、ちゃんと目次も作れましたよ。
これだと履歴管理機能も使えるし、いいかなと。

- 広告 -

仕様書を作るために必要なことって何だろう

作りながら思ったのですが、これってある程度アプリとかサーバーとかの仕組みがわかってないと書けないですね。
初めてアプリを作ったりする場合は、もっと試行錯誤的に作ると思うので、今回の手法は使えない気がします。
私自身もサーバーは作りながら考えるスタイルなので、仕様がぼんやりしてますからね。

大切なのは、何をやりたいのかを明確にしておくことかな?
実現方法は実装するときに決まると思うので、ここで無理に決める必要もないかも。

アプリの場合は、どんな機能をつけるのか、それはどんな動作をするものなのか。
サーバーの場合はどのリクエストに何を返すのか、データをどうやって保管するのか。
そういったことを決めるのが仕様書であり設計書なのかなと思うのです。

今回はWordで作ったのですが、もっと簡単にWikiとかで仕様の管理ができたらいいのになと思うのです。
色々調べてたんですが、どれにするか決めかねたので結局今回はWordにしてしまいました。
Wikiでやるメリットはぼっち開発よりもチームで開発する方があるように思います。BacklogとかにもWiki機能あるので、それを仕様書として使うのも良さそう。
まあ、今回のプロジェクトはBacklog使ってないですけどね。。。

実は前回の時もアプリを途中まで作ってたんです

仕様も決まったことだし早速アプリを作っていきましょうかね。
そう、前回も仕様書を作った後、アプリを作っていたのでした。あの時はXamarin ネイティブで作ろうとしていたので、まずはiOSから。
ストーリーボードとか使ってほとんどの機能を作りこんでました。

そして、SNS連携が面倒になって。。。その後Androidでも同じように作らなくてはならないのかと思った時の絶望感。。。
「そうだ、Xamarin.Formsにしよう!」とこのとき思ったのでした。

塗り絵の部分はPCLで作っていたのでその部分はほとんどそのまま今回も使いまわせるはず。
そうと決まれば、早速作っていくぞー。
と言いつつ、次回は多分サーバーのお話になるかと思います。

- 広告 -

ペーパープロトタイプからUIを作りますよ

- 広告 -

UIを作るというかデジタルで清書

前回はAdobeの”Experience Design CC”を使いましたが、今回は”Illustrator”を使いました。
“Experience Design CC”は使い勝手があまり慣れていないので、結構苦労しました。もっと手慣れたツールないかなと思っていたところIllustratorがモバイル対応してて意外と使えるのではないかと思い試してみたところ、割と使えたのでこちらで行くことにしました。
やはり使い慣れたツールが一番ですね!
デザイナーさんの間では”Sketch”というソフトを使ってる人も多いみたいです。

“Illustrator”で作るときは、1つの画面を1アートボードに作っていきます。
pixelで作れるのでサイズ感なんかがわかりやすいです。アイコンなどもここで作りこんでおくと後で楽。
聞いた話によると、プロトタイプの段階では白黒で作った方が良いんだそうです。なので、これも白黒。
確かに色を入れてしまうと、色に引っ張られてしまうところがあるかも。

最後にスクリーン用に書き出しすれば、1画面づつの画像ファイルが出力されます。便利!




アートボートを複数作れば、画面ごとにファイルを変えたり、レイヤで分けたりする必要がなくて便利なのも良いですねー。画像を書き出してそのまま仕様書にもできますね。

- 広告 -

清書もプロトタイプにしたよ

これをいつものPOPアプリでプロトタイプにしました。

イラストレーターで作ったプロトタイプ

プロトタイプ見て気づいた方もいるかもしれませんが、トップ画面の仕様を変えました(誰も気づいてないかも?)
Xamarinで開発する予定なのですが、Xamarinで横スクロールのテーブルを実装するのはちょっとめんどくさそう(基本機能にはない)ので、ポップアップから選択させるようにしました。この方がユーザーにもわかりやすいような気がします。

この後はようやく仕様書です。やっと、前回やってたところまでたどり着きます!

時間が経つと、色々考え方とかが変わってくるので、早く作るのがやっぱり大事だなーと思います。
仕事の合間にちまちま進めているので、仕方がないことですが。。。今回はちゃんとリリースまで持っていきたい!いや、持って行く!!

と決意を固めた所で、続きは次回〜

- 広告 -

画面遷移が変わったのでプロトタイプも作り直すよ

- 広告 -

画面遷移図を見直してみた

前回作った画面遷移図も見直していたら、もっとスッキリできるんじゃ無いかと思い書き直しました。

これで、トップ画面からのリンクは「絵本」か「設定」の2つだけになりました。スッキリだね!!

この遷移図を元にプロトタイプも書き直そう

画面遷移が変わるということは画面構成も変わるということ。すなわち、UIも作り直しなのね。
前回のは若干もっさいなと思わなくもなかったので、今度はもっとスタイリッシュに作り直したいと思います!
私にスタイリッシュとかいうデザインセンスがあるのかは別問題として!

画面は全部で7画面!これはかなり少ない(当社比)画面構成です。じっくり作って行きましょう。

- 広告 -

まずはプロトタイプ!

軽くラフを描いて全体像を掴んで見ました。

こういう落書きって実は頭の中を整理するのに最適だったりします。気ままに鉛筆を動かしていたら、意外なアイデアが浮かんできたり。
思いついたらその場で描き起こせるのも良いですね。
今回も設定画面のレイアウトとか、落書きしながら思いついたんですよ。

それから、以前作ったテンプレートを使ってペーパープロトタイプを作成。
今回も”pop”というアプリを使ってプロトタイプを作ります。

プロトタイプ

実は前回、少しばかりアプリを作っていたので、その時のUIなんかも参考にして作ってみました。
ページ数が少ないと、それだけ一つのページに心を配れるので、機能を沢山盛り込んでここの機能がおろそかになるよりも一つ一つ丁寧に作れていいなと思いました。

さて、次回はこれをベースにUIを作りますよ。

- 広告 -

もっとミニマムにしなくては!

- 広告 -

今回は、前回の「仕切り直しをするよ!」で言っていた、まだまだ最小限になっていない問題。
どうやって見直そうかというお話です。

機能を見直すよ!

前に作った機能表から、いらないんじゃないかというものを消してみました。

解析ツールも特にいらないか。ということで付属機能としていたものはPush通知と絵本のダウンロードだけになりました。

細かい仕様を見直す

機能表を元に作った仕様を変えてみました。
機能表修正版

SNS連携をやめてカメラロールに保存できるようにしました。
もっと変わるかなと思ったのですが、意外と他は触る必要ないかな?って感じでした。やっぱり初めからかなり機能は削ってたんですね〜。
解析ツールを外したくらいですかね。
iOSもAndroidもインストール数やアクティブユーザー数くらいはわかるし、広告を打つわけでもないから、どこからインストールされたかとかを気にする必要もないですしね。

- 広告 -

画面遷移も作り直し!?

機能を削除したので画面遷移も変わりますよね。という事で作り直して見ました。

機能一つ削っただけで随分スッキリしました。これでかなり作りやすくなったように思います。
お知らせを見る機能も削っちゃいました。今の所お知らせすることも特にないですしね〜。新しい絵本を追加したとか、バージョンアップしたとかならわざわざ後から見る必要もないですしね。見ればわかる。

アプリをミニマムにするためには、機能の本質を見失わないようにしなくちゃいけないなぁと思いました。

- 広告 -

仕切り直しをするよ!

- 広告 -

長らく停滞しておりましたこのコーナー「アプリを作ろう」ですが、再スタートしますよ!

この一年何をしていたかというと、本業の方で違うアプリを作っていました。もちろんXamarinでです。
そこで新たに色々と考えるところがあって、以前作りかけていたアプリを作り直そうと思います!

以下のような感じで見直していきますよ〜。
(1)まだまだミニマムにはなっていなかった!
(2)Xamarin.Formsを使おう。
(3)本当にAWS一択なのか?

まだまだミニマムにはなっていなかった!

以前、ミニマムスタートが良いよというお話で、必要最小限の機能でスタートしようと言っていました。
しかし、作っている最中に「これは、最小限になっていないのでは?」と思い始めたのです。

ぶっちゃげSNS連携とかって必須じゃないですよね。もしSNSにアップしたければ画面キャプチャしてあげれば済む話ですしね。
別に連携部分を作るのが面倒だったとかじゃないんだからね!
という事で、機能をもう少しシェイプアップします。

- 広告 -

Xamarin.Formsを使おう。

Xamarin始めた頃はiOSとAndroidの画面を共通化とか無理じゃね?みたいなノリでやっぱネイティブだよね。と思っていたのですが、実際やってみると一度作った画面を別のプラットフォーム用にもう一度作るってかなりの苦行でした。
で、お仕事で受けたアプリはFormsを使ってみたのですが、意外と共通化できたので、こっちのアプリもそれでいこうと思います。
やっぱり、プラットフォームごとにカスタマイズが必要なところや、そもそもOSに依存する処理はネイティブ側で書く必要がありますが、体感で80〜90%くらいは共通化できる気がします。
2回も同じ画面作るならクロスプラットフォームにした意味ないですよね!(今更)

本当にAWS一択なのか?

そして、バックエンド用のサーバ。以前はAWS一択みたいな事言っていた気がしましたが、最近気になる存在が現れました。
その名もAzure。
ご存知マイクロソフトの運用するクラウドサービスです。もちろんXamarinとの親和性もバッチリ。しかも、こちらもAWSと同様に1年間無料で使えるようになりました。
これは使わない手はない。

てな感じで、なんとなく1から作り直しな気がしなくもないですが、次回からは使用設計からやり直しますよ!!

- 広告 -

設計書を作成するよ

- 広告 -

設計書を何で作るのかが問題だ

本来、開発時に作成する文書は、「仕様書」「設計書」「詳細設計書」などがあるんですが、今回は面倒なので「設計書」一つで済ましてしまいました。

もしも、複数人数で開発するのであれば、「仕様書」「詳細設計書」「API通信仕様書」など必要でしょうし、DB(データベース)を作るんだったら、ER図なんかも必要になってきます。

今回もER図は必要な筈なんですが、おいおい作っていきます。。。

大事なのは、開発するにあたって何が必要なのかを整理すること、どういった目的で処理をするのかを分かること、だと思っているので、作っている過程で矛盾や不都合があれば随時変更していけば良いんです。

会社なんかによって、仕様書・設計書の書き方って違ったりします。普段はその会社の書き方に合わせるんですが、自分で書く時は自由にできる反面、どうするか悩ましいですね。

WordかExcelが主流だと思うんですが、Excelで文書を作るのはなんとなく違う気がするので、Wordで作ってみました。

印刷するんであればWordが一番良いと思うんですが、文書をプリントアウトするのは自然にも優しく無いので、今時はあまり無いですよね。大量に紙を消費しますから。。。

今回、なんとなくデザインレイアウトで作ってみたら、見出しとか目次とかwordの便利機能が全然使えなくて、正直「しまった」と思いました。デザインレイアウトはどちらかというと、Power Pointに近い感じですね。普通にWord文書で作る方が良いと思います。

仕様書作る便利ツールがあれば、是非活用したいな。それがWordなのか。。。

- 広告 -

仕様書を作ってみました

スピード開発時代において、文書を書いてる時間が勿体無いと感じるかもしれませんが、備忘録替わりにも仕様書を作ることは必要じゃないかなと思います。

作っている最中はいいけど、しばらくして改修しようと思ったら、「どういう意図でコーディングしたか思い出せずに苦労した」って経験ある人、多いんでは無いでしょうか。

コードにコメントを残していくことである程度予防できますが、どうなってたっけ?てなった時にコードから拾うのも大変です。

かと言って、ここに時間をかけすぎるのも面倒なので、さらっと必要事項だけ入れてみました。それでも20P越えてしまいました。

出来上がった設計書はこちら

最低限必要だと思う項目をピックアップしてみました。

(1)画面遷移図

これは、設計初期段階(画面遷移図を作るよ)で作ったものがあるので、それをコピペで良いでしょう。ここまでの段階で仕様が変わっていったので、その部分だけは修正しました。このツールは本当に便利ですね!

(2)画面仕様

前回(プロトタイプを清書してUIデザインにしよう)で作ったUIを元に、その画面でどのような動作を行うかを決めます。

これで、全体の開発ボリュームが分かるんじゃ無いかな。受託の時も、この段階の仕様でお見積もりすることが多いように思います。

iPhone,iPad,Androidでレイアウト違ったりしますが、どうせ作るの自分なので不精してiPhone画面のみにしました。

(3)データ構成

サーバやアプリで取り扱うデータの内容を決めます。データ名と型、概要なんかを書いておけば良いと思います。表形式にすると上手くまとまります。制限なんかがあればそれも記載します。(例えば最大10文字までとか、数値なら0以上とか)

DBを作るのであればER図もあると良いですね。

(4)通信仕様

データ構成に似てますが、アプリからのリクエスト内容とそれに対するレスポンスを決めます。

多くの場合、アプリ作成者とAPI作成者は別の人なので、この取り決めはきちんとしておかないと、後で動かない原因になります。

今気づいたんですが、エラーコードの一覧なんかも作っておかなくてはいけませんね。エラーパターンなんかを考慮しなくてはいけないので、今後追加していくことにします。

こうやってみてみると、アプリの設計書は慣れているので良いのですが、サーバ側の設計書はやはり未知の部分が多いのでつい後回しになってしまいます。実装しながら不足分を追加していきます。

大事なのは、作りっぱなしにせずにメンテナンスを必ずすること。でないと意味のないゴミとなってしまいますからね。

個人的な考えとして、「資料は1つにまとめる」と言うのがあります。今回みたいに一つの文書にしてしまわなくても良いので、ここを見ればすべてわかる。と言うものにしておくことが大事だと思うのです。あの資料はあっち、この資料はこっち、と言う状態だと探すのも大変だし、見落としたりもします。

今後問題となるのは、履歴管理なのですがwordの機能を使うのも良いですが、今回はEvernoteに登録していこうと思います。なぜなら、デザインレイアウトだと履歴機能が使えなさそうなのと、webで公開するのに便利だから。gitで管理すると言う手もあると思います。

早く実装したくて、設計書を作るのが雑になった気がしますが、これから実装しながら手を加えていきますよ。

- 広告 -

プロトタイプを清書してUIデザインにしよう

- 広告 -

Xamarinに振り回される日々を送っていました

お久しぶりです。。。実は。。。

ペーパープロトタイプを作って、次のUIデザインに移る前に、初挑戦になるXamarinがどんなものなのか、試していました。

前回作ったような色ぬりツールをiPhone用、Android用で作ってみようと思ったのですが、これが大変でした。

Xamarin自体はそれなりに使える環境だとは思うのですが、突然フリーズしたり、エミュレーターが動かなくなったりと、やや動作が不安定。さらに、まだ日本語のドキュメントは少ないため、何かを調べるにも英語のドキュメントを読まねばならないのですよ。

Xamarinでお絵かきする時の悪戦苦闘記はQiitaに書きためておきました。

ここまで時間が経っている自覚がなかったので、ほぼ2ヶ月ぶりのブログに正直ビックリです。

Xamarinの感想としては、多少動作に不安があるもののの、アプリを開発したことのある人にとっては、あまり違和感なく使えるのではないでしょうか。Xamarin.Formsと言う、iPhone,Android同時にUIが作れるフレームワークもあるのですが、UIはネイティブで開発した方が自由度が上がると思ったので、別々に開発する方を選択しました。

Androidも開発経験あれば違和感なく開発できたと想像できるのですが、なんせほとんど経験なかったのでiPhoneとの違いに翻弄されっぱなしでした。ライフサイクルとか考え方が全く違うので、その違いを頭に叩き込んでおく必要があります。

どちらも開発経験があれば、Xamarinはとっても便利な開発ツールになるんだろうなーと思いました。

- 広告 -

手書きのプロトタイプをデジタルで描き起こしてUIデザインにしてしまいます

前回作った手書きのペーパープロトタイプを、プロトタイプツールを使って清書しました。ここでUIデザインを決めてしまいましょう。

デジタルでプロトタイプを作るツールはいくつかありますが、今回はAdobeのExperience Design CCを使いました。

せっかくクラウドに入っているので、使わないのはもったいないですからね!

このツールも微妙に使えるのか使えないのか。。。これでデザインを作り上げるには、少し力不足な感じです。

UIキットもあるにはあるのですが、キーボードも縦はあるけど横がなかったりともう一声!って感じかな。

ただ、イラレやフォトショで作ったデータをコピペで貼り付けれるのは、流石Adobe製品なだけありますね。

パーツはイラレやフォトショで作成して、Xdで形成しました。

プロトタイプを作るには、上の図のようにパーツから紐付けするだけで画面遷移を作ることができるので、楽チンです。通常のpush動作のみでなく、上下スライドやディゾルブなんかも選べるので、動作感を見るのはいい感じです。

ただ、フリック動作などは取れないので、フリックでページ遷移みたいな動作は作れませんでした。(0.6.8.6Beta)

スクロールはできますが、1部分だけスクロールさせる、といった複雑な動きはできないようです。

こんな感じで、四苦八苦しながら作ったプロトタイプを、第3者に触ってもらいました。

そこでまた、新たな改善点を見つけたので、それをここでフィードバックします。

そうして出来上がったのがこちら

我ながら所々雑ですが、ご了承あれ。

これってクライアントさんとかに見せるには最適ですよねー。iPhoneで見たらフル画面で見れるのも良いですね。

今回はiPhoneでデザインしましたが、デバイスは選べるので、AndroidやiPadでデザインすることもできます。

Xdを使う場合でも、いきなりこのツールで描き始めるのではなく、一度は手書きで紙に書いてみる方がスムーズにアイデアが出ると思います。

本棚に戻るアイコンが気に入らないんだけど、何かいい感じのアイコンないでしょうか。

もう少しブラッシュアップが必要ではありますが、こんな感じでプロトタイプ&UIデザインができたところで、次は設計書を作りますよ!

ようやく開発らしくなってきました。コーディングはいつ始めるんだ!?って感じですyoね。。。

- 広告 -

プロトタイプを作るよ

- 広告 -

プロトタイプを作っていくよ

前回の更新から、随分と時間が経ってしまいました。。。いろいろ忙しかったんです。。。(ということにしておく)

気を取り直して、再開しまーす!

気付いたら、最初に立てた工程と若干変わってきている気もしますが、気にせず行っちゃいますよ。

今回はプロトタイプを作ります。

プロトタイプとは、実際にプログラミングする前に、画面遷移などの動作を検証するために作る試作品のことです。

今回はペーパープロトタイプ、つまり紙で作ったプロトタイプを作ります。

紙にiPhone6の縦横比に合わせた四角を用意します。

前回作った画面遷移図や機能詳細に沿って、各画面に必要な要素を配置し、アイテムやボタンを並べていきます。

webデザインとかだとワイヤーフレームと言われるものに近いです。

ここでアプリの使い勝手などが決まってくるので、慎重に進めたいところです。

ここは試行錯誤を繰り返し、ああでもない、こうでもないと書き直しながら進めていきます。

書いたり消したりが面倒だったので、PCやスマホのアプリで書くツールがないかと試してみたのですが、なんだかんだ、紙に手で書くのが一番早かったです。頭の中にあるものをアウトプットするのは、やっぱり紙が一番ですね。

色やデザインの詳細までを作り込む必要はありませんが、大体のレイアウトを決めていきます。

逆に、この時に細部まで作りこんでしまうと、この後に変更したいと思った時に悲しい気持ちになってしまいます。

ペーパプロトタイプ用のテンプレートを作ってみました。必要あれば、お使いください。

iPhone用

Android用

スマホは画面サイズやアスペクト比が多様なので、一つのサイズに絞ることが難しいですが、基本となるレイアウトを決めてしまい、フローレイアウトで合わせるのが良いと思います。

体感的に、iPhoneに合わせることが多いように思います。

また、iPhoneとAndroidでボタンの位置などを変えたりすることもあります。Androidは画面の外に戻るボタンがあるので、画面の中に戻るボタンがある必要がなかったりします。まあ、そのまま付けてるアプリもありますけどね。

- 広告 -

プロトタイピングのためのツール

プロトタイプを作るツールとして、今回POPアプリを使ってみました。

このアプリは紙に書いた画面デザイン(ワイヤーフレーム)を撮影して取り込み、タップ動作などを登録することによって、実際にアプリを動かした時の操作を疑似体験できます。

プログラムを書かずに、画面遷移を作ることができるので、UI(ユーザーインターフェイス)の検証にお役立ちです。

今回作ったプロトタイプはこちら

心なしか、スワイプが効いてない気がしますが、参考まで。

まずは、自分で動かしてみます。

想像で考えていたよりも違った印象になるのではないでしょうか。ここで、気付いたことをメモっておきます。

できれば、何人かに触ってもらい、初めて触る人がどのような操作をするのかを観察します。また、して欲しい操作などを指示し、目的にたどり着けるかもチェックしましょう。ここで気付いたこともメモっておきます。

今回気付いたもの。

1)全体にチュートリアルは必要。また、色ぬり画面は別途ヘルプボタンを用意しておいた方が良さそう。

2)アイコンに統一感がない。

3)色ぬり画面の保存などはスワイプで引き出すようにしていたけど、タップの方が使いやすそう。

4)設定画面のFacebook,twitterはログイン設定ということがわかるようにテキストを追加する必要あり。

次回は、今回の反省点を考慮して、UIを確定させていきますよ。

 

- 広告 -

画面遷移図を作るよ

- 広告 -

やっと本格的にアプリを作っていきますよ

前回から、少し時間が経ってしまいましたが、ようやくアプリ開発らしいことをやっていこうと思います。

機能は決まったので、次は「画面遷移図」と言うものを作ります。

「画面遷移図」とはアプリの操作の流れを見える形にしたものです。

こんな感じ。

どうやって考えていくかというと、必要な機能を画面単位で分けていきます。後は、画面を順番に並べていって矢印でつなぎます。

行ったり来たりするものや、いろんな画面から呼ばれるものもあるので、思いつくまま矢印を書いていきます。

どういった操作で画面を移動するのかもメモっておくと良いかも。

書いている段階で順番を入れ替えたり、画面構成自体を変えたりすることもあるので、何回も書きなおしたりします。ポストイットを使えば良いのでは、と今気づきました。。。

必要な画面を並べたら、どれをTOP画面(起動して最初に表示する画面)にするか考えます。

一般的には、一番使用する機能をTOPに持って来ることが多いです。twitterやfacebookならタイムライン、フリマやオークションアプリなら商品閲覧画面、などです。

で、今回のアプリで最初に表示すべきは、絵本を選ぶ画面(本棚)でしょう。

次に、絵本を普通に読む画面、塗り絵をする画面がメイン機能ですよね。なので、HOME画面からすぐに移動できるようにします。

塗り絵は保存したり、SNSに投稿したり

各種設定をする設定画面や案内画面(するのでその画面も必要です。関連アプリや作者紹介など)も欲しいところです。

画面ではないですが、チュートリアルも欲しいですね。

SNSのログイン設定画面もいるのかな?

で、考えた結果がこちら。結局、一回作った後に何度か修正しました。

そんなもんですよね!

- 広告 -

画面遷移図を描くツールを探す旅に出る。

画面遷移図を作るのに便利なツールがないか探していたら、面白いツールを見つけました!

-> もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った

この記事からリンクされているこちらからダウンロードします。

macの場合はguiflow-darwin.zipをダウンロードしましょう。

マークアップ方式と言って、あるルールに則ってテキストを記述していきます。

そうすると、ほら素敵!簡単に画面遷移図がかけちゃいます。見た目?このくらい整ってたら十分でしょう。何よりもメンテナンス性が最高に良いです。

よくある、エクセルやワードで作ったものに比べると、格段に修正しやすいですね!

実際に使ってみて、出来上がるスピード感が全然違いました。今まではエクセルとかパワーポイントとかで作っていたんですが、それがバカバカしくなるくらいスピーディーに作れます。

マークアップだと難しいと感じる人もいるかもしれませんが、即座に図を表示してくれるので、ビジュアル的に確認しながら書くことができますね!

保存するファイルはテキストデータなので、gitなどのバージョン管理ツールで管理しておくことも可能です。文書のバージョン管理って地味に面倒なんですよね。なんて素敵。

とは言え、いきなりこのツールに向かうのはお勧めしません。まずは手書きで良いのでアウトラインを作りましょう。

頭で考えていることを、ダイレクトに出力するには手で書くのが一番みたいですね。

このブログを書きながら、ツールが見つからなくて途方に暮れていたのですが、最後の最後に良いツールに出会えてよかったです。

 

- 広告 -