結果
ブログ
目標：月 8 回（週2回）更新
結果：月 9 回 更新
読書
目標：月 1 冊
結果：月 2 冊
反省点など
Vueもさわれたし勉強会もいくつか参加できたので、久しぶりに良い内容だったかなと思います。
来月に向けて
そんな忙しくなければSAPの勉強も再開したいですが、その前にいろいろ今後に向けてやりたいこと整理する期間にしようかなと考えています。
UX MILK All Night
9/12-13に行われた UX MILK All Night を視聴したので、見たセッションの気になったことなどをメモします。
アーカイブもあるのであまり詳しくしない程度にとどめたいと思います。
目次
- A1-2 : UXデザイナーが作るサービスの業務フロー設計
- A1-3.5 : 受託制作におけるデザインシステム
- A1-4 : UXデザインにおける眼と手と動きの解像度を上げる技
- A1-5 : しなくていいUX
- A1-8 : インクルーシブデザインとUX
- A2-4 : システム開発でデザイナーは何をすればいい？
- A2-7 : 複雑性と難易度の高いサービスリニューアルにおけるサービスデザイン
- A3-2 : 良いUXを実現するために、まずはチーム内にデザインを浸透させている話
- A3-10 : 1人でこっそり始めるUXデザイン
A1-2 : UXデザイナーが作るサービスの業務フロー設計
受託型の業務フロー設計、PoC時のUXデザイン手法について
スピーカー：高橋一成さん（株式会社オロ）
まとめnote：UXデザイナーが作るサービスの業務フロー設計 @ UX MILK All Night
前提
UXデザインはユーザーを理解するところから始まる
チャートでの設計手法
システム中心の書き方の3つの手法
- アクティビティ図 => ユーザーのシステム上での行動を把握しやすい
- ユースケース図 => システムでできることが把握しやすい
- シーケンス図 => データの流れが把握しやすい
今回のフローチャートはユーザーの行動が中心の書き方。
UXフロー図
アクティビティ図はシステムの分岐視点になるが、UXフロー図はユーザー体験中心の視点の図ができる。
ステークホルダーや関係ツール全体の行動や振る舞いを一覧化することで
- 予算感が見える
- フェーズが立てられる
こともメリット。PoCなど全体が見えづらいプロジェクトに適している。
- ユーザーの行動を追いながら
- ユーザーのタッチポイントを考えながら
- 必要な機能を確認しながら
などリアルな行動を意識しながら書くと良い。
プロジェクトの進め方
サービス全体からアプローチ版（PoCの場合はこちらが多い）
- ［UXフロー図］サービス全体をイメージする
- ［UXフロー図］必要なフローや機能を見つける
- ［UXフロー図］機能・画面・フローを考える
- ［ワイヤーフレーム・実装］ワイヤーフレーム・モックを作る
- ［ワイヤーフレーム・実装］機能・画面フローを調整する
ユーザーの理解からアプローチ版
- ［インタビュー・ペルソナ・エクスペリエンスマップ］ユーザーの行動を観察する
- ［インタビュー・ペルソナ・エクスペリエンスマップ］ユーザーのインサイトを見つける
- ［インタビュー・ペルソナ・エクスペリエンスマップ］ユーザーの課題を見つける
- ［ワイヤーフレーム・機能実装］サービスのアイデアを考える
- ［ワイヤーフレーム・機能実装］機能・画面・フローを考える
感想
受託でPoC案件が前提の話だったのでいまいる会社に近い感じもあり熱心に聞けました。
UX設計やります、っていっても1つではないアプローチの方法があってそれを実践できるようにしたいなと思いました。
A1-3.5 : 受託制作におけるデザインシステム
受託制作における汎用的なデザインシステムについての知見
スピーカー：石原隆志さん（GrowGroup株式会社）
スライド：Design system for Client Work - Speaker Deck
デザインシステムを作った経緯
事業規模拡大、理念体系の変更により時間をつくったり、共通認識となる旗が必要と感じたため。
デザインシステムの導入
デジタルプロダクトの目的を達成するために首尾一貫したルールで編成された、お互いに関連付けられたパターンとその実践方法。
吉幾三。こういうのオンラインだと難しそうですね・・・
今回は受託制作の会社の場合のため、汎用性を持たせること、どこまでの自由度があるのかなどの共有が難しかった。
これらの課題に対して
- デザインシステムに関する勉強会、ミーティングの実施
- デザイナーのコーディングスキルの習得（Udemyなど中心に）
- クロージングミーティングの開催
- 社内で運用システム、フロー（委員会）を構築
- ツールの拡充
- ドキュメントの充実化
などできるだけスキルレベルに依らず使うようにするためハードルを下げる施策を行った。
感想
自分も2人や20人の受託Web制作会社で今まで社内ツール作るのに頓挫した光景を見る経験を何度もしているので、めちゃくちゃしっかりやっててすごいなと思いました。
A1-4 : UXデザインにおける眼と手と動きの解像度を上げる技
眼と手と動きの解像度を上げる方法
スピーカー：安藤幸央さん（株式会社エクサ）
スライド：UX MILK All Night 2020 (Yukio Andoh)
眼
- 中心視野はかなり狭い
- 視野の移動をなるべくさせない
- 白黒・色反転・左右反転・補助線・比較でゲシュタルト崩壊を防ぐ
手（指）
- 体験の解像度を下げる（おじさんでも爪を伸ばしてみる）
- 人間は35,000/1日、選択している（2秒に1回）
- 選択を分解して人の体験を分析する（コーヒーと角砂糖）
- Netflix は登録なしで見れるように
動き
なぜUIアニメーションさせるのか
- 画面や要素が切り替わったことを知らせる
- 変化をより把握しやすいものにする
- 小さなものにも注意を促す注目をしてもらう
- 動きによって楽しみを感じてもらう
- 正しい情報構造の理解を手助けする
人間は情報を順繰りに渡される方が理解しやすい
オブジェクトを触わってから
- 50~100msあとにアニメーション開始
- 300~400msでUIアニメーション
- 50~100msあとにアニメーション停止
すると動きを知覚しやすい
感想
話慣れてるなー感がすごかったです。
なぜUIアニメーション必要なのか、自分は極力必要ないならしない方向に持っていってしまいますが、理論化、言語化して提示くださったので、その方法で考えていきたいと思いました。
A1-5 : しなくていいUX
スマートロックのUXについて
スピーカー：神谷郁さん（Qrio株式会社）
スライド：しなくていいUX - Speaker Deck
しなくていいUXとは？
- ユーザーが抱えている負の体験を「しなくていい」
- ユーザーが製品を使う上で余計な体験を「しなくていい」
「ユーザーが抱えている負の体験を」「これまでよりもスマートな体験で」解決するアプローチ => 課題解決のアプローチと近い
Amazon、Uber、サマリーポケットの例
Qrio LockのUXデザイン
ユーザーが抱えている負の体験を「しなくていい」
=> 本来したいことに時間を使える
=> 家を出たらカギが閉まって家に帰ってきたらカギが開いてほしい
出かける前 / 出かける時 / 外出中 / 帰宅した時 / 在宅中 のステージごとに課題・不便を抽出
ユーザーが製品を使う上で余計な体験を「しなくていい」
=> 余計な階層を辿らなくていい
=> 新しい技術を覚えなくていい
=> セットアップに時間をかけなくていい
セットアップに対して「自分でもできる」感を訴求
・貼り付けるだけで使える訴求
・既存設備に取り付けられる訴求
感想
先ほどの解像度のセッションもですが、不自由・負の部分の洗い出しを行ってから設計するということで、ハードウェア・ソフトウェア関係ないのかなと感じました。
カギをかけない人はいない、って言っていてビクッとしました。
A1-8 : インクルーシブデザインとUX
インクルーシブデザインでできることについて
スピーカー：佐野実生さん（株式会社コンセント）
スライド：インクルーシブデザインとUX（PDF版）
インクルーシブデザインとは
- インクルーシブデザイン => デザインプロセスに多様な人を巻き込む
手法 - ユニバーサルデザイン => すべての人が利用できるデザインである
状態 - アクセシビリティ => すべての人がアクセスできる
状態
多様な人 は特定の誰かではなく、みんなのことを指す。
極端ユーザーからの顕在ニーズを抽出すして未来の当たり前をつくること。
例）未来の当たり前
特定の環境や制限のある状態は誰にでも当たり前にあり得る。
インクルーシブデザインチームの取り組み&実体験
どうすれば伝わるだろう？という問いかけを意識する
- 画面に頼らない説明をする
- コピペ最高
- 字幕はあるに越したことはない
感想
画面共有のココ問題、自分もリモートになって感じました。
UDトーク、噛んじゃいけないプレッシャーもありそうですがめっちゃよかったです。
本当に言っている通りで倍速で追いやすいですし、自分にとっては一番良いインクルーシブデザインの例でした。
A2-4 : システム開発でデザイナーは何をすればいい？
システム開発の要件定義・設計フェーズにおいてデザイン思考をどのように取り入れてるか
スピーカー：高見祐介さん（株式会社電通国際情報サービス）
スライド：UXMILKallnight_システム開発でデザイナーは何をすればいい？
不確実性を下げる
要求定義・要件定義・基本設計・詳細設計で2つの思考
- システム思考（全体・抽象化志向） => 物事を全体的&体系的にとらえ、多くの視点から構造化し可視化する
- デザイン思考（部分・具体化志向） => 完成的なアプローチで観察、発想、試作を何度も繰り返し共創する
フェーズ別のアプローチ
- 要求定義 => ペルソナ・カスタマージャーニーマップマップなど仮説
- 要件定義 => UI設計書をつくる（デザイナーが）
- 設計 => 対象ユーザの決定とユーザビリティテスト
実施したアクションの合意形成（クライアントと伴走することが大事）
- 画面イメージを検討し、該当業務プロセスで必要とされる機能を洗い出す
- 早い段階からUI画面のレイアウトと仕様項目のイメージをつかむ
- 画面遷移と発生イベントを優先的に確認する
デザイナーががんばること
- 言語化
- 共創
- 合意形成
要求・要件定義フェーズから参画しましょう
感想
開発会社の方なので他の方とはちょっと毛並みが違って面白かったです。
「正しいものを正しく作る」まわりの話をデザイナーさんが意識しているとこのような解釈方法になるんだという新しい発見がありました。
A2-7 : 複雑性と難易度の高いサービスリニューアルにおけるサービスデザイン
CULTIBASE のサービスデザインについて
スピーカー：瀧知惠美さん（株式会社ミミクリデザイン）
スライド：複雑性と難易度の高いサービスリニューアルにおけるサービスデザイン - Speaker Deck
サービスデザインの特徴的なアプローチ
This is Service Design Doing サービスデザインの実践 より
- 人間中心
- 関わる人の体験を考慮する
- 共働的であること
- 関係者が積極的に関与する
- 反復的であること
- プロセスは探索・改善・実験の繰り返し
- 連続的であること
- サービスを行動の連続として捉える
- リアルであること
- 現実世界でリアルに調査、実験する
- ホリスティック（全体的）な視点
- サービスと企業全体まで含めた視野をもつ
利害関係者を巻き込んだ「共創」を大事にしたい
=> 「同感的にかかわり」ではなく「共感的かかわり」（1人称視点+2人称視点）
サービスデザインで大事にしていること
- 「ユーザーにとっての理想」と「自分たちが目指す理想」を徐々に折り合いをつけていく
- 1人称視点でと3人称視点でこれまで培われたサービスの特色を大事にする
- 既存ユーザ・新規会員・社内メンバーとのコミュニケーション
サービスデザイン（リニューアル）の難しさと取り組み方
リニューアルが失敗する要因 => 一新したことで既存の価値が損なわれることが一般的
なぜそうなりやすいかというと、既存・新規の2つのユーザーに考慮し、既存・新規の2つのサービスを動かさないといけないから
- 2つのユーザーへの対応方法
- 既存ユーザーと新規ユーザー両者にとって快適なあり方の探求
- 既存ユーザー＋新規ユーザー2人のペルソナを作成
- 2つのサービスへの対応方法
- リニューアル前とリニューアル後のスムーズな接続の設計
- リニューアル後の世界観へ徐々に移行させていく
一新する（renewal）ではなく、洗練させる（refine）。
感想
サービスという範囲がわりと広いものだと思っているのですが、リニューアルの話は一般的なWebサイトでも通じることがあるかなと思いました。（要求・要件にもよりますが）
A3-2 : 良いUXを実現するために、まずはチーム内にデザインを浸透させている話
Qiitaなどを提供するIncrementsでUXデザインを浸透させている話
スピーカー：綿貫佳祐さん（Increments株式会社）
note：UX MILK ALL Night - 良いUXを実現するために、まずはチーム内にデザインを浸透させている話｜綿貫 佳祐 / Ateam, Increments｜note
なぜ「チーム内」か
- 優れたUXデザイナーはチームに「UXと向き合う文化」を導入している
- デザインは「デザイナーだけでやるもの」ではないと思っている
- 組織にこれまであまりデザイナーがいなかった
取り組み
デザインスクラムというエンジニアがデザインの勉強する取り組みを実施
- サービスの立ち上げの調査や企画
- Figmaを使って自分でUI作成
良い変化
- デザイナーの考えが分かるようになった
- 一連の流れが理解できるようになった
- UIにまで踏み込んだので制作する際の勘所が良くなった
苦労したこと
- 実務ですぐに何か成果が出るかというと、出ない
感想
スライドがめちゃめちゃ見やすかったです。
QiitaのUIも段々良くなってきていますが、もっとよくなればいいなあと思います。
A3-10 : 1人でこっそり始めるUXデザイン
UXデザインを身近な所からはじめてみましょう、というお話
スピーカー：鈴木毅さん（株式会社メンバーズ）
何から始めればいい？
ユーザー調査 => ユーザビリティ調査
- インパクトが大きい
- テクニカルスキルがなくてもできる
- 制作者は始めやすい
具体的な始め方
- 準備
- 協力者を探そう
- 実査
- イントロ
- 事前インタビュー
- タスク実施
- 事後インタビュー
- 分析
- 有効さ・効率・満足度
- 共有
- チームメンバー・ステークホルダーに共有
感想
一人ではじめる、なのでスモールスタートで参考書や書籍に書いてあることは全部やろうとしないでいいんじゃないかと言っていてなるほどなと思いました。
確かにUXの書籍に書いてある内容を実践しようとするには、仰々しい部分もあるかなと思うので・・・
全体の感想
自分はエンジニアで登壇されている方はデザイナーの方が多いと思いますが、そういう職種の垣根を超えて仕事をしているのだなという発見と刺激を受けました。
「共創」「伴走」や「負の体験を取り除く」「不自由から学ぶ」のような近しいキーワードもセッション間で見受けられ、デザインする対象がハード/ソフトに関わらず、制作の考え方が勉強になるイベントでした。
ゆっくり見たいもの見たい派なのと、朝型なので今回アーカイブ形式を購入してみましたが、セッション内容的にとても満足でした。
【読書メモ】ウェブタイポグラフィ - 美しく効果的でレスポンシブな欧文タイポグラフィの設計
前回の オブジェクト指向UIデザイン に続いて、同じ時期に話題になっていたウェブタイポグラフィを読みました。
ウェブタイポグラフィ─美しく効果的でレスポンシブな欧文タイポグラフィの設計
- 作者:リチャード・ラター
- 発売日: 2020/06/29
- メディア: 単行本（ソフトカバー）
目次
章立てはシンプルですが各章でボリュームあります。
対象としてはIAやデザイナー、エンジニアということで、HTMLやCSSに関してはある程度の基礎が分かっていると楽しく読み進められるかなと感じるレベルかなと思います。
ポイント
はじめに
ウェブですばらしいのは、さまざまな形を取れること、そして読み手がニーズに合わせてそれを形づくれることです。これは弱みではなく強みであり、バグではなく機能です。
ウェブデザイナーには柔軟性が求められるのです。ウェブデザインは読み手の緩急王に順応するものであるべきで、読み手がニーズに合わせてデザインを調整することが不可欠です。
これは特にタイポグラフィに限った話ではなくウェブのプレゼンテーション全体の話だと思うのですが、自分もこういう考え方で良い妥協点を見つけれる人がウェブのデザインがうまい人かなと思っています。
1章:読まれるための組版
読むということ
インタフェースデザインの心理学 にもあったサッカードなどの話。
ただそれよりも詳しい内容 中心視では一度に4、5文字しか読めないが脳はすべてのテキストに焦点が合っている。
フォントサイズの単位
主に em rem ch px がある。
ただし基本的には、ページと一緒に要素を拡大縮小したい場合は rem を使用し（グローバルなサイズ設定）、コンポーネント内で拡大縮小したい場合は em を使用します（ローカルサイズ設定）。
段落のデザイン
可読性のバランスを支えるのは以下の3つ。
- カラム幅（行の長さ）
- 文字サイズ
- 行間
カラム幅
一般的な印刷物は1行45〜75文字で設定されている。
画面で読むには行が長め（最大100文字）でも悪影響は出ない。ただし読み手は短めの行を好む。
スマホは1行で42文字がおおむねちょうどよい。
（和文の場合はこれらの文字数の半分強を目安にする）
文字サイズ
段落にはデフォルトの文字サイズを使用する。
各デバイスメーカーは適切な初期サイズとして16pxを採用。
アクセント付きの文字をベースにデザインしたフォントはxハイトが低いので、同じ16pxでも他のフォントに比べて小さめになる場合も。
行間
行の高さは文字サイズとカラム幅に合わせる。
line-height: は単位無しで指定する（自分は単位無し= em で指定だと勘違いしていました）
フォントによって調整が必要だが1.4を設定するところからスタートする。（和文は1.7程度から）
快適な行間を設定するにはカラーのの均一化とカラーに対して心地よい黒みの量にすることを目指す。
- フォントのストロークが太い => カラーが濃くなりがち => 行間をやや広げて重さを減らす
- 幅が広く隙間がある、xハイトが小さい => カラーは薄くなりがち => 行間をやや狭めて重みをもたす
レスポンシブな段落
目からテキストまでの距離と適正フォントサイズ
Size Calculator
とはいえテキストは過度に大きすぎても読みにくくなるのでプロトタイプをなるべく作りましょう/プロトタイプのコンテンツもできるだけ実際のデータ（に近いもの）をいれた上で行いましょう
2章:タイポグラフィのディテール
記号、符号、アクセント
- さまざまなスペース
- ノーブレーク
/ヘア /シンスペース がある
- ノーブレーク
- アクセント記号を勝手に消さない
- 特に人の名前は礼儀を欠くことになる
- 適切な約物を使用する
- その他
- エリプシスは3つのピリオドではなく
… - 乗算記号はアルファベットの
xではなく×
- エリプシスは3つのピリオドではなく
階層とスケール
タイプスケール（あらかじめ定義された文字サイズのセット）を意識する。選択肢が制限されるため、組版に規律と一貫性をもたらすことができる。
- レファレンス（小） => 注釈など
- リーディング（中） => 本文
- ディスプレイ（大） => 見出しなど
最も小さいサイズを先に決めてから大きいサイズを選ぶ。
Modularscale や Simple Scale を使うとかんたんに試せる
デフォルトの文字サイズの場合、スマートフォンでは問題ないが、PCなど大きな画面ではコントラストとインパクトが減少してしまう
この場合、別のスケールセットをつくるのではなく、メディアクエリを使用して端末サイズをemで分岐してあげる
意味とセマンティクス
見出し
見出しの強調はスペーシングだけでそれなりにうまくできるはず。足りない場合にスタイルやウェイトの違いをもたす
CSSではh1〜h6までスタイルを指定する。デザインにない場合（h5やh6）にもh4と同じスタイルを当てておく。
レディング（行間）は狭くする
テキストまわり
- はじまりを明確にする
- 空白スペースやドロップキャップ
- リードはリードらしく大きな文字にしたりする
- リスト項目が少なく数行だけの場合は、項目感のスペーシングを防ぐ
- アンダーラインでは強調しない
- リンクと慣習上リンクとみなされるため
- リンクは明確かつ控えめにする
- アンダーラインを第一選択肢に
- アンダーラインなしの場合は周囲とのコントラスト比を3:1にする（かなり明らかにする必要性）
テーブル
p.144 に実際のサンプルがあるが、たしかに見やすく感じる
- テーブルは引き伸ばさない
- 装飾や色付けは最小限に留める
- テキストは左揃え、数字は右揃え、見出しはデータに揃える
- 余白を利用してグループ化と分離を行う
- 数値にテーブル用ライニング数字と一貫した精度を適用し、繰り返す（$マークなど）を省略する
トラッキングとカーニング
- レタースペーシングは慎重かつ例外的に
- 特別に理由がない限りは小文字をレタースペーシングしない
- 読み手が単語として把握するのが難しくなる
- 大文字や数字が連続する場合はレタースペーシングする
- 大きいボールドの幅広フォントは軽く詰める
- 字間を広げる場合は合字を無効に
- 特別に理由がない限りは小文字をレタースペーシングしない
見出しとインパクト
タイポグラフィの2つの役割
- 小説 => 没頭させること => 読む
- 広告看板 => 割り込むこと => 見る
ディスプレイテキストはまず見られてから読まれるテキスト
バーティカルリズムを適用する
参考： なぜタイポグラフィにおいてVertical Rhythm（バーティカルリズム）は重要な手法なのか？ | POSTD
ページのバーティカルリズムは、本文の行の高さを指定した時点で設定されます。本文テキストを16px、行の高さを21pxとした場合、縦方向のスペースの基本単位は21pxになります。ページのバーティカルリズムを持たせるには、マージンやほかのテキストの行の高さなどを含むすべての縦方向のスペーシングを21の倍数にしてください。
配置と構成
モバイルファーストの哲学を採用する
画面が小さいので必然的に優先順位と階層の扱いが大事になる
メインのテキストブロックをななめ読みできるようにする
- 全体的な読む体験は最初のななめ読みで決まるので、可能な限りひと目で注意を引き込むようにする
- 小見出しは明確に識別でき、理解しやすいものにする
- 左側の端を明確にすることで、ページを下方に進む際の視覚的な手すりを読み手に提供する
3章:フォントの選択と使用
フォントが画面にレンダリングされる仕組み
画面はピクセルと呼ばれる極めて小さい光の点の面滅を放射します。
ラップトップやデスクトップの多くは、約140ppiの画面解像度を備えています。アップルのRetinaディスプレイなどの高解像度画面でも400ppi以下です。一方のプリンターは、比較的安価なレーザープリンターでも600dpiの解像度があり、プロ仕様のデジタルプリンターではx2,438dpiもあります。
各オペレーティングシステムにはテキストレンダリングエンジンが備わっていて（複数備えていることもあります）、それぞれのウェブブラウザがどのレンダリングエンジンを使用するかをコントロールしています。
→ つまり同じOSでもブラウザによってテキストの見た目が大きく異る可能性がある。
フォントはベクターでデザインされラスタライズされて表示される。ラスタライズされるときにエイリアス/グレースケールスムージング/サブピクセルアンチエイリアスのアンチエイリアス処理がある。
ただこのそれぞれの処理には何らかの欠点があったり、向いてない端末が出てきてしまう。
そのときに使うのがヒンティング。
参考） ヒンティング - 印刷用語集
Verdana、Geogia、Arialなどの主要なウェブ用のフォントはすべてのサイズで可読性が高くなるようにヒンティングの調整がされている。
マイクロソフトは正確さよりも鮮明さを優先させるというスタンス（へぇ〜となりました）
ウェブデザイン全般に言えることですが、デバイス間ですべてが同じようにレンダリングされることを期待してはいけません。自分の選択をベースに、何かがただ違って見えるだけなのか、または質が低下しているのかを評価します。
実際的及び実用的考慮事項
- すぐにフォントを選択しない
- どのフォントを使用するかは、特定の要件、文脈、成約、信頼性、そして最後は好みで決まる。
- 美的判断より実用的な要件を先に考慮する。
- どのフォントを使用するかは、特定の要件、文脈、成約、信頼性、そして最後は好みで決まる。
- ウェブサイトの性質をよく理解する
- 今後複雑な機能を要求されるか
- 読み手を没頭させるのか、流し読みで十分なのか
- 必要な文字が揃っている書体を選択する
- アクセント、約物が用意されているか
- 必要なスタイルが書体に備わっているか
- フォントのパフォーマンスを考慮する
- レンダリング
- ファイルサイズ
- ブランド要件に対して現実的に対応する
本文書体の決定
- 読み手とテキスト感の摩擦を取り除く
ディスプレイテキストの書体を選ぶ
- かしこまらず、押しつけず、ありふれたものにせず
- 書体を通じて感覚に働きかける
- ディスプレイテキストは「読む」前に「見る」
- 信頼性やトーン、コンテンツに対する先入観を刺激する
- モフモフの子猫が大好き
- さまざまなディスプレイ書体を試す
- 働き者、個性派。柔軟性よりも個性を重視する
- ディスプレイテキストにディスプレイスタイルを使用する
- 書体を通じて感覚に働きかける
ウェブフォントを使用する
ペイロードとレンダリングタイミングの2点を最適化する必要がある。
- WOFF は TTFとOTFのラッパー。WOFF2は圧縮最適化した新しいフォーマットだがすべての環境でサポートされていないのでフォールバックを用意する。
- @font-face でWebフォント指定していても、フォントは必要なときのみ（該当するセレクタが存在するときのみ）ダウンロードされる。
- ペイロードの軽減
- 使用するフォント数の制限（特にアジア圏のフォント）
- 必ずWOFF2オプションを提供（平均30%の節約）
- ページのレンダリングタイミングを最適化する
- 重要なフォントはプリロードする
- フォントイベントでウェブフォント戦略を微調整する
感想
ウェブのタイポグラフィでも、古いときから使われている技術やルールをかなり大事にするべきなのだなと感じた。ウェブはウェブなので、、が通じるとこがもっと多いと思ってました。
自分の悪い癖だと思うのですが、文字をひとつのデザインや見せ方として捉えている部分があって、そういう手癖でやっていたこと（本文でわりとレタースペーシング入れる、テーブルの横幅100%など）は見づらいよと書かれており反省しました。。
最初に入った会社で朗文堂通ってたタイポグラフィ詳しい方にWebだけではなく文字周りの知識をある程度は教えて頂いたのですが、最近は特にデザインもする機会もなく忘れかけていた分野だったので若干なつかしさを覚えました。
結構この分野って知識の他に日々文字を眺める機会が誰でもあると思うのですが、それを見てどう感じてということの繰り返しで身につける系のスキルかなとも思っていて、文字詰めとかも最初はなんとなくでやっていたけど、やっていくにつれて覚えていけた感があります。
本書で触れている行間の設定なども結局デザイナーの目がものをいう部分も多々にあるんだなと思いつつ、カラーなどの概念を知らないでなんとなくいい感じを脱するためには学んだほうが良い知識が揃っていました。
イギリスの リチャード・ラターさん が著者で、監訳は 鈴木丈さん が行っていますが、日本語の場合はうんぬんかんぬんも補足しないといけないこともあるのでタイポグラフィ関係の翻訳めちゃ大変そうだな・・・と思いました。
この本に関してではないですが、やっぱり和文で扱い方が全く異なることもあると思うので、そこにフォーカスした本も読んでみたいなと思いました。
ただ ウェブ × タイポグラフィ でも割と狭い世界な印象なのでなかなか難しいのかなとも思います。
ほか参考
Nuxt.js・楽天市場APIでWebアプリをつくる
Nuxt.jsと楽天市場APIでWebアプリを作成しました。
構成
API
今回は特にAPIにこだわりなかったので使いやすそうな 楽天市場API を使いました。
Amazonの商品APIは登録や制限の縛りがきつそうで、e-Stat API は種類が多すぎるのと、統計をグラフ等で可視化するために時間かかりそうで手軽に使えるAPIにしました。
フロント開発
Nuxt.js の SPA で開発。
Vuexをはじめて使ったのですが、今までバケツリレー的なことをしていたのでこれ使いこなせるとかなり便利ですね。
ただgetter/setterの概念などまだまだ理解できていないところもあるのでもっと使いこなせるようにしたいです。
CI/CD
どこまでがCI/CDの範囲かは微妙ですが、GitHub Actions を使ってGitHubリポジトリのマスターブランチにプッシュしたら自動でビルドしてGitHub Pagesへデプロイするようにしました。
GitHub Actionsいまいち分かっていなかったのですが、色々モジュールが用意されていてどれを使うか選択して、オプションやパラメータをyamlで設定するような流れなのですね。
モジュールは公式のものもMarket Place的にサードパーティや個人製のものもあるって感じで、確かにGitHubをリポジトリとするプロジェクトの場合は広がりがあるなあという印象でした。
ただホスティングする場所にこだわりなければ、ちょっと複雑すぎる印象もあるのでNetlifyなどの方が手軽にはできるかなと思います。
感想
久しぶりにNuxt.jsを触ることになってしまったのですが、今回Nuxtで詰まったというよりGitHub Actionsの設定周りで時間を費やしてしまったのでごりごり開発できた感はありませんでした。
例えば、リロード時に検索条件をlocalStorageに保存する、詳細ページからも検索できるようにするなどのもう少し細かいところを詰めたかったですが、次回以降も勉強でNuxt触ると思うのでだんだんできるようになっていければと思います。
関連ブログ
参考記事
Nuxt.js
Github Actions / Github Pages
Nuxt.js のサイトを GitHub Actions を使って GitHub Pages へ自動デプロイする
結構詰まってしまったのでメモ
概要や大枠はこちら
GitHub Actions による GitHub Pages への自動デプロイ - Qiita
Nuxtの場合はこちら
Vue Nuxt アプリを GitHub Actions で GitHub Pages にデプロイ - Qiita
やりたいこと
- Vue CLIで作成したNuxtアプリ（SPAモード）をGitHub Pagesで公開したい。
- /dist ファイルをリポジトリにプッシュしてホスティングするのではなく GitHub Actions を使用してmasterブランチのファイルから静的ファイルを自動生成したい。
ざっくり流れ
- nuxt.config.js でルーティング設定
- .envファイルの設定
- ACTIONS_DEPLOY_KEY の設定
- generate, deploy設定 を /.github/main.yml に記述（ブラウザのGitHub Actionsから作成）
main.yml に関しては最初に貼ったQiitaの記事をほぼコピペしましたが、細かい所で突っかかりました。
つまったその1 envファイルの読み込み
dotenv を使用
.env
APPLICATION_ID=XXXXXXXXXXXXXXXXX
nuxt.config.js
require('dotenv').config(); const {APPLICATION_ID} = process.env; export default { // ... env: { APPLICATION_ID }, ... }
ここまでは Nuxt.jsで.envファイルを扱う@nuxtjs/dotenv - Qiita の通り
GitHub Pages でこの環境変数を使うには、
GitHubのリポジトリページ > Settings > Secrets の New secret から .env と同内容のNameとValueを設定する。
その後、 main.yml のgenerateタスク時にそのSecretsを参照するように指定する
jobs: build-deploy: # ... - run: npm run generate env: APPLICATION_ID: ${{ secrets.APPLICATION_ID }} # ...
つまったその2 ACTIONS_DEPLOY_KEY 設定
秘密鍵、公開鍵の生成
ターミナルで
ssh-keygen -t rsa -b 4096 -C "$(git config user.email)" -f gh-pages -N ""
リポジトリに公開鍵を設定
GitHubのリポジトリページ > Settings > Deploy keys の Add Deploy Key から生成した公開鍵を（gh-pages.pub）を登録。
Title は ACTIONS_DEPLOY_KEY
Key は gh-pages.pub の中身のコピペ
Allow write access にチェック（しないとデプロイ時にパーミッション許可してと怒られる）
リポジトリに秘密鍵を設定
GitHubのリポジトリページ > Settings > Secrets の New secret から生成した秘密鍵を（gh-pages）を登録。
Name は ACTIONS_DEPLOY_KEY
Value は gh-pages の中身のコピペ
これで main.yml のデプロイ設定が動作した
jobs: build-deploy: # ... - name: Deploy uses: peaceiris/actions-gh-pages@v2.5.0 env: ACTIONS_DEPLOY_KEY: ${{ secrets.ACTIONS_DEPLOY_KEY }} PUBLISH_BRANCH: gh-pages PUBLISH_DIR: ./dist # ...
GitHub Pages の設定（GitHubのリポジトリページ > Settings内）はSourceの
Branch は gh-pages
ディレクトリ はルート
に設定すると変にnuxt.config.jsいじっていなければgh-pagesブランチではルート階層にdistファイルを生成してくれる。
成果物
Vue.js Tips： Vuex で Action への複数パラメータ渡し / `v-on:` で複数のメソッド呼び出し
過去記事では制作過程の記事の中に紛れ込ませていましたが、検索しづらいので Vue.js Tips としてまとめていきたいと思います。
Vuex で Action にパラメータを複数を渡す
パラメータを1つ渡すときは
.vue
this.$store.dispatch('items/getItems', this.data01)
store.js
// ... export const actions = { async getItems({ commit }, hoge) { // ... const variable01 = hoge // ... } } // ...
のように書きますが複数の引数を渡す場合、第3引数が使えないので
.vue
//... data() { return { data01: 'データ01', data02: 'データ02' } }, methods: { ...mapActions({ getItems() { this.$store.dispatch('items/getItems', { hoge: this.data01, fuga: this.data02 }) }, }) } //...
store.js
// ... export const actions = { async getItems({ commit }, { hoge, fuga }) { // ... const variable01 = hoge const variable02 = fuga // ... } } // ...
参考： Vuex で Action, Mutation に第3引数を渡したくなったら
v-on: で複数のメソッドを呼び出し
input( @click="getItems(); toggleCheck();" type="checkbox" ) // ... methods: { getItems() { // ... }, toggleCheck() { // ... } }
【読書メモ】オブジェクト指向UIデザイン ─ 使いやすいソフトウェアの原理
UI/UX系の知識を身につけるということで、少し前に発売して話題にもなった「オブジェクト指向UIデザイン」を読みました。
オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 (WEB+DB PRESS plusシリーズ)
- 作者:ソシオメディア株式会社,上野 学,藤井 幸多
- 発売日: 2020/06/05
- メディア: 単行本（ソフトカバー）
UIまわりの本ですが、こういうボタンはどういう見た目にしよう、のようなスタイル的な話ではなくソフトウェアの設計が主題です。
タイトルに入っている「オブジェクト指向UI（OOUI）」について、特にスマホアプリを普段扱っている人にとってはおそらく慣れた（普段から意識している）指向なのかなと思います。
ただ実際にソフトウェアを設計する際の方法論や実例を学ぶことなく「なんとなく」決めていることが多いと感じています。（自身はそうでした）
この本にはその方法論や実例が多く説明されていたので、気に留めておこうというポイントを中心にメモしておきたいと思います。
目次
- 1 オブジェクト指向UIとは何か
- 2 オブジェクト指向UIの設計プロセス
- 3 オブジェクト指向UI設計の実践
- 4 ワークアウト：基礎編
- 5 ワークアウト：応用編
- 6 オブジェクト指向UIのフィロソフィー
使いやすい or 使いづらいと感じる画面（UI）にはどんな特長があるのか、なかなか論理的・客観的に説明するのは難しいですが、技術評論社の記事 動詞ではなく名詞を起点に画面を構成する ～OOUIでソフトウェアを使いやすく～ にも書かれている通り、下記の考え方で設計することであらゆるソフトウェアの構成が整理され使いやすくなります。
タスクではなくオブジェクトを起点に画面を構成する。もっと一般的な言葉を使うと，「動詞（やること）」ではなく，「名詞（もの）」を起点に画面を構成する。たとえば「本を買う」であれば，「買う」ではなく「本」を起点にする。これだけのことです。ごくシンプルですよね。
4章の実践では、こういう要件があるものはどのような考えで作るのかが説明されていますが、本を通してメインで説明されている核は上記です。
5章のワークアウト基礎編では何個かお題があり、これまで説明された内容で自身でアプリケーションデザインをしてみて答え合わせしましょう、という内容です。
6章のワークアウト応用編では既存のタスク指向のアプリケーションをどのように改善すると良いUI（OOUI）になるかを考える設問と答えが掲載されています。
ソシオメディアさんというUI分野で古くから有名な会社に所属する方が書いており、さまざまなプロジェクトを通して得たノウハウが詰まっているように感じました。
ポイント
なぜオブジェクト指向UIなのか（はじめに）
ユーザーインターフェースという言葉は「コンピューター画面」などにとどまらず、使う人とその対象をつなぐものすべて。
そもそも扱うべき対象 = オブジェクトが「在る」という前提そのものが、UIの概念なのです。UIははじめから存在論的であり、オブジェクト指向なのです。
オブジェクト指向UIとは（p.9）
オブジェクト指向UIとは、オブジェクトを手掛かりに操作設計されたUIのことです。
オブジェクトとは、アプリケーションが扱う情報 オブジェクトのことであり、ユーザーが操作するときの対象物のことです。
例えば蔵書アプリの場合、最初に表示される画面で
- 「登録する」「確認する」・・・などユーザが行うタスクを始点とするのではなく（動詞 → 名詞）、
- 本の一覧表示でその中のひとつを選択すると編集作業や詳細ページでの確認ができるような、対象物が始点となるソフトウェア（名詞 → 動詞）
がオブジェクト指向となる。
オブジェクト指向UIの原則（p.11）
- オブジェクトを知覚でき直接的に働きかけられる
- オブジェクトは自身の性質と状態を体現する
- オブジェクト選択 → アクション選択の操作順序
- すべてのオブジェクトが互いに協調しながらUIを構成する
タスク指向UIとは（p.17）
CLIのように、動詞を起点として設計された操作モデル。動詞 = やることを指向しているという意味
タスク指向の例としてATMや券売機、自動販売機など。
UIがタスク指向になってしまう背景（p.29）
UXへの注目の高まりによって、ユーザーの体験価値の向上がUIデザインのひとつの重要なゴールとして認識されてきていることも関係しているのではないでしょうか。
体験をデザインするということが、ユーザーの利用手続きをデザインするという意味で捉えられることが多いのです。
オブジェクト指向UIの設計プロセス ソフトウェアデザインのレイヤー（p.42）
モデル、インタラクション、プレゼンテーションのレイヤーに分けることができる。
- モデル
- ユーザーの関心対象の模式
- ユーザーの特性、業務の形態、情報の書式、要求事項の種類と関係性などをもとに、システムが扱うオブジェクトの構成をモデリングする
- ユーザーの関心対象の模式
- インタラクション
- プレゼンテーション
- スタイルやレイアウト（ルック）
- 表層。オブジェクトを表象するグラフィックの形や色、画面レイアウトなど。
- スタイルやレイアウト（ルック）
オブジェクト指向UI設計の基本ステップ（p.51）
ステップ1,2,3はどこからはじめてもOK、行きつ戻りつ進めていく。
下記の各ステップ例は学校名簿アプリケーションを想定
ステップ1. オブジェクトの抽出（モデルレイヤー）
- タスクのサンプルを何個か挙げる
- 「ある生徒が所属している部活を確認する」、「3年C組のある生徒の成績を確認する」など
- 名詞を抽出する
- 「ある生徒」「部活」、「3年C組」「ある生徒」「成績」など
- 名詞とそれらの関係を抽出する
- 「ある生徒」-「部活」、「3年C組」-「生徒」-「成績」など
- 名詞を汎化し、粒度を揃える
- 「生徒」-「部」、「組」-「生徒」-「成績」など
- 名詞の関係性をつなげ、オブジェクトを特定する
- 「成績」-「生徒」-「部」など
- オブジェクトの中で「メインオブジェクト」となるものを特定する
- 「生徒」など、ユーザーの関心領域に置いて主要なものは何か？を考える
- メインオブジェクトに負づいするオブジェクトをプロパティとする
- 「生徒」の場合、氏名/成績 など
- タスクからアクションを見つける
- タスクとは最初に挙げたもの。「新規」「削除」など。「確認」は詳細ビューで表示されるので特記しない。
ステップ2. ビューとナビゲーションの検討（インタラクションレイヤー）
- 基本のビュー形式
- コレクション（一覧）とシングル（詳細）の2通り。
- メインオブジェクトにコレクションとシングルのビューを与える
- コレクションビューとシングルビューの呼び出し関係を検討する
- 互いに参照可能性のあるビューを矢印でつなぐ
- メインオブジェクトの中からルートナビゲーションを選定する
- メインオブジェクトで優先度の高いもの、ユーザがアプリケーションを使用する際に最初に思い浮かべるオブジェクトを選定する。
- 動詞ではなくオブジェクト名を用いる（語尾に「管理」などを用いない）
- ルートナビゲーションを選択すると、そのオブジェクトのコレクションが表示される
ステップ3. レイアウトパターンの適用（プレゼンテーションレイヤー）
特にこれは書籍の図解のほうが分かりやすいです。
（参考）ソシオメディアさんWebの UIデザインパターン
- ルートナビゲーションの配置パターン
- 下固定 / 開閉式
- ビューの配置パターン
- 単一メインオブジェクト / 複数メインオブジェクト
- ドリルダウンの方向性（上→下、左→右、同ページなど）の決定
- コレクションビューの表示パターン
- コレクションの性質や用途に合わせて表示形式を決定
- 1項目1行の1次元リスト / 1項目複数行の1次元リスト / 1項目複数行の1次元リスト（高さ可変） / サムネールのグリッド/ マッピング
- フィルタリングのパターンとしては下記がある
- キーワード検索 / グループ / AND条件 / クエリビルダー / ソート
- コレクションの性質や用途に合わせて表示形式を決定
- シングルビューの表示パターン
- 他のオブジェクトのコレクションの一部を表示する
- 他のオブジェクトのコレクションを強調する
- 他のオブジェクトのコレクションだけを表示する
- シングルビューの性質や用途に合わせて表示形式を決定する
- アクションの性質や用途に合わせて表示形式を決定する
- ビジュアルデザイン
- やっとこさUIのグラフィックに着手します
オブジェクト指向とは（おわりに）
オブジェクト指向UIは、単にナビゲーションのラベルを「名詞」にしたり、操作順序を「対象選択 → アクション選択」にするといった表現上のスタイルのことではなく、ユーザーの前に対象の理念をストレートに表象するということです。ユーザーに手順を指示するのではなく、目当てそのものを差し出す態度なのです。
とあるように、決まりきった手順で操作するのではなくユーザーが自由にUIを触れる感覚を持たせるようにする。
良かった点
- 図やイラストが分かりやすい
- 基本的な思想や設計方法の説明〜ワークアウトまで網羅している
- 章構成もよい感じ。6章のフィロソフィーがはじめの方に来てたら心折れそうな気がするので
- 補足も適切
中身の話でないですが、レイアウトはきれいだったのですが文字が小さいところが残念ポイントでした。
まとめ・感想
なかなか会社のプロジェクトでこのレベルの設計面から携わる（口が出せる）機会はないのですが、設計する人 / デザイナー / エンジニアみんながこの思想や設計方法を理解していると、かなりスムーズに機能を絞れたり開発が進むような気がします。
読む前は正直ちょっと胡散臭い感じがしていましたが、ふだん触っているアプリ（Spotify や Uber Eats）もオブジェクト指向UIですし、その仕組みや設計の方法を学べたのでとてもよい機会になりました。
本で出される例に関して、例えばメールアプリ、メモ帳アプリ、アドレス管理アプリなどがありますが、どれも Apple の純正アプリと画面構成が同じでオブジェクト指向UIになっています。
HIGなどにも書かれているとは思いますが、Appleも社内で設計する際に同じような手法なのかなと感じました。
これから使うアプリやサービスを見るときもこの本で学んだ視点で見ることができるかなと思います。