Kuehar's Blog

 何はともあれコードを書こう ちまちまCourseraのSwiftUI関連のコースとかの勉強を進めてはいるが、実践的なアプリを作ってみたい気持ちが出てきたので、土日を使ってサンプルを作ってみた。 ソースは ここ 。 単純なアプリなので、MVCモデルで作ればいいやの考え方で処理の書き方が分からない箇所は他に作っていた方の処理を真似しつつ、なんとか作り終わった。 仕様としては トップ画面に検索バーを用意し、入力した文字列を元にGitHubに存在するユーザーを検索する クエリで得られた結果を同画面内で行単位で表示し、ユーザーをタップした場合にはそのユーザーのリポジトリを表示する。 というもの。 ここどうすんだって迷ったポイント・他人のコードを読んでなんだこれってなったポイント ModelでGitHubとの通信をしてUserやらRepositoryの情報をfetchするのは良いけどJSON周りの処理ってどう書くんだ？ →とりあえず他人がどう書いているかを見て解決。JSONDecoderで一発だった @MainActorってなに？ →クラス単位で@MainActorをつけておくと、そのクラスのすべてのメソッドがメインスレッドでよばれるようになる。関数につけた場合はその関数だけが呼び出される。 今回は後者のパターン。 Taskとか初めて存在を知ったんだけどこれどういう風に使えばいいの？ →そもそもasync,awaitを知るところから始めるべき。 備忘として書くと、それぞれ非同期処理を書くときに使用する書き方。asyncはメソッドが非同期作業を実行することを明確にするメソッド属性、awaitはasyncな非同期メソッドを呼び出す際に使われるキーワード。そしてTaskはプログラムの一部として非同期で実行できる作業の単位のこと。細かい書き方は省くが、それぞれの非同期処理の単位を一まとめにしてくくり、実行単位をまとめるようなイメージ。 ＠Publishedってなんだっけ・・・ →Combineフレームワークの一部として提供されているProperty wrapper。ObservableObjectプロトコルに準拠したクラス内のプロパティを監視し、変化があった際にViewに対して通知を行う。なお、クラス内のプロパティに付与することができるが、structなどの値型には付与できない。 他

  ユーザー指向デザイン アプリを改善していく方法として、実際にそのアプリを使用しているユーザーに対してインタビュー、使用中の観察を行うことを総称して ユーザーリサーチ という。 これを行うことで、ユーザーはアプリを使用する上でどのように、何を考え、何を達成しようとしているのかを知ることが出来る。 その中でもユーザーからの意見をデザインにどのように改善していくことができるかを確認する方法として カスタマージャーニーマップ を作成するという方法が存在する。 例えば、 メニューボタンが分かりにくい 商品のカテゴライズが曖昧である バスケットボタンが存在せず、商品が追加できたか分からない ホームボタン、戻るボタンが存在せず、途中からのやり直しができない 注文のために必要な情報を全て入力したにもかかわらず、バリデーションエラーが表示される などがユーザーリサーチで分かった場合、カスタマージャーニーマップにはこれらのユーザーの体験を整理する。 カスタマージャーニーマップを作成することで、最終的には、ユーザーに共感し、再設計を改善するのに役立つ一連の教訓を得られる。 良いカスタマージャーニーマップは詳細、かつ粒度が細かく、あらゆる場面でのCXを理解することを手助けします。 一般的に、カスタマージャーニーマップは以下の５つの要素が存在していることが多い。 アクター シナリオと期待値 ジャーニーフェーズ 行動、態度、感情 機会 それぞれを見ていくと、 アクター ペルソナやユーザー。カスタマージャーニーマップ上ではデータ駆動型。１つのマップに１つの視点を用意することでより粒度が細かくなる。 シナリオと期待値 カスタマージャーニーマップが扱う状況のこと。アクターの目標やニーズ、何を達成するかの期待と関連する要素。Amazonであれば商品を選ぶ際の意思決定や注文を完了するために必要な全ての情報にいかに簡単にアクセスできるかなどが含まれる。 ジャーニーフェーズ 行動、思考、感情といったジャーニーマップの残りの情報を整理するもの。 行動、態度、感情 アクターの行動、態度、感情であり、各フェーズでマッピングされる項目。例えば、行動はアクターの実際の行動を物語化したもの。顧客から直接引用することが理想的。 機会 UXをどのように向上させることが出来るかを考察する箇所。この情報を使って何をするべき