2020年9月 振り返り

月次振り返り

結果

ブログ

目標：月 8 回（週2回）更新
結果：月 9 回 更新

読書

目標：月 1 冊
結果：月 2 冊

反省点など

Vueもさわれたし勉強会もいくつか参加できたので、久しぶりに良い内容だったかなと思います。

来月に向けて

そんな忙しくなければSAPの勉強も再開したいですが、その前にいろいろ今後に向けてやりたいこと整理する期間にしようかなと考えています。

UX MILK All Night

UI/UX イベント

9/12-13に行われた UX MILK All Night を視聴したので、見たセッションの気になったことなどをメモします。
アーカイブもあるのであまり詳しくしない程度にとどめたいと思います。

f:id:jotaki:20200921181854p:plain

目次

A1-2 : UXデザイナーが作るサービスの業務フロー設計

受託型の業務フロー設計、PoC時のUXデザイン手法について
スピーカー：高橋一成さん（株式会社オロ）
まとめnote：UXデザイナーが作るサービスの業務フロー設計 @ UX MILK All Night

前提

UXデザインはユーザーを理解するところから始まる

チャートでの設計手法

システム中心の書き方の3つの手法

  • アクティビティ図 => ユーザーのシステム上での行動を把握しやすい
  • ユースケース図 => システムでできることが把握しやすい
  • シーケンス図 => データの流れが把握しやすい

今回のフローチャートはユーザーの行動が中心の書き方。

UXフロー図

  1. ステークホルダーを書く
  2. それぞれの行動を書く
  3. ステークホルダーが表示する画面を書く
  4. 機能やシステムの振る舞いを書く
  5. パーツとしてならべる
  6. 矢印を使ってフローをつくる

アクティビティ図はシステムの分岐視点になるが、UXフロー図はユーザー体験中心の視点の図ができる。
ステークホルダーや関係ツール全体の行動や振る舞いを一覧化することで

  • 予算感が見える
  • フェーズが立てられる

こともメリット。PoCなど全体が見えづらいプロジェクトに適している。

  • ユーザーの行動を追いながら
  • ユーザーのタッチポイントを考えながら
  • 必要な機能を確認しながら

などリアルな行動を意識しながら書くと良い。

プロジェクトの進め方

サービス全体からアプローチ版（PoCの場合はこちらが多い）

  1. ［UXフロー図］サービス全体をイメージする
  2. ［UXフロー図］必要なフローや機能を見つける
  3. ［UXフロー図］機能・画面・フローを考える
  4. ［ワイヤーフレーム・実装］ワイヤーフレーム・モックを作る
  5. ［ワイヤーフレーム・実装］機能・画面フローを調整する

ユーザーの理解からアプローチ版

  1. ［インタビュー・ペルソナ・エクスペリエンスマップ］ユーザーの行動を観察する
  2. ［インタビュー・ペルソナ・エクスペリエンスマップ］ユーザーのインサイトを見つける
  3. ［インタビュー・ペルソナ・エクスペリエンスマップ］ユーザーの課題を見つける
  4. ［ワイヤーフレーム・機能実装］サービスのアイデアを考える
  5. ［ワイヤーフレーム・機能実装］機能・画面・フローを考える

感想

受託で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設計書をつくる（デザイナーが）
  • 設計 => 対象ユーザの決定とユーザビリティテスト

実施したアクションの合意形成（クライアントと伴走することが大事）

  1. 画面イメージを検討し、該当業務プロセスで必要とされる機能を洗い出す
  2. 早い段階からUI画面のレイアウトと仕様項目のイメージをつかむ
  3. 画面遷移と発生イベントを優先的に確認する

デザイナーががんばること

要求・要件定義フェーズから参画しましょう

感想

開発会社の方なので他の方とはちょっと毛並みが違って面白かったです。
「正しいものを正しく作る」まわりの話をデザイナーさんが意識しているとこのような解釈方法になるんだという新しい発見がありました。

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/UX

前回の オブジェクト指向UIデザイン に続いて、同じ時期に話題になっていたウェブタイポグラフィを読みました。

ウェブタイポグラフィ─美しく効果的でレスポンシブな欧文タイポグラフィの設計

ウェブタイポグラフィ─美しく効果的でレスポンシブな欧文タイポグラフィの設計

目次

  • はじめに：わたしたちは皆タイポグラファ
  • 1章:読まれるための組版
  • 2章:タイポグラフィのディテール
  • 3章:フォントの選択と使用
  • おわりに

章立てはシンプルですが各章でボリュームあります。
対象としては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 ではなく ×

階層とスケール

タイプスケール（あらかじめ定義された文字サイズのセット）を意識する。選択肢が制限されるため、組版に規律と一貫性をもたらすことができる。

  1. レファレンス（小） => 注釈など
  2. リーディング（中） => 本文
  3. ディスプレイ（大） => 見出しなど

最も小さいサイズを先に決めてから大きいサイズを選ぶ。
Modularscale や Simple Scale を使うとかんたんに試せる

デフォルトの文字サイズの場合、スマートフォンでは問題ないが、PCなど大きな画面ではコントラストとインパクトが減少してしまう
この場合、別のスケールセットをつくるのではなく、メディアクエリを使用して端末サイズをemで分岐してあげる

意味とセマンティクス

見出し

見出しの強調はスペーシングだけでそれなりにうまくできるはず。足りない場合にスタイルやウェイトの違いをもたす
CSSではh1〜h6までスタイルを指定する。デザインにない場合（h5やh6）にもh4と同じスタイルを当てておく。
レディング（行間）は狭くする

テキストまわり
  • はじまりを明確にする
    • 空白スペースやドロップキャップ
  • リードはリードらしく大きな文字にしたりする
  • リスト項目が少なく数行だけの場合は、項目感のスペーシングを防ぐ
  • アンダーラインでは強調しない
    • リンクと慣習上リンクとみなされるため
  • リンクは明確かつ控えめにする
    • アンダーラインを第一選択肢に
    • アンダーラインなしの場合は周囲とのコントラスト比を3:1にする（かなり明らかにする必要性）

テーブル

p.144 に実際のサンプルがあるが、たしかに見やすく感じる

  • テーブルは引き伸ばさない
  • 装飾や色付けは最小限に留める
  • テキストは左揃え、数字は右揃え、見出しはデータに揃える
  • 余白を利用してグループ化と分離を行う
  • 数値にテーブル用ライニング数字と一貫した精度を適用し、繰り返す（$マークなど）を省略する

トラッキングとカーニング

  • レタースペーシングは慎重かつ例外的に
    • 特別に理由がない限りは小文字をレタースペーシングしない
      • 読み手が単語として把握するのが難しくなる
    • 大文字や数字が連続する場合はレタースペーシングする
    • 大きいボールドの幅広フォントは軽く詰める
    • 字間を広げる場合は合字を無効に

見出しとインパクト

タイポグラフィの2つの役割

  • 小説 => 没頭させること => 読む
  • 広告看板 => 割り込むこと => 見る

ディスプレイテキストはまず見られてから読まれるテキスト

バーティカルリズムを適用する

参考： なぜタイポグラフィにおいてVertical Rhythm（バーティカルリズム）は重要な手法なのか？ | POSTD

ページのバーティカルリズムは、本文の行の高さを指定した時点で設定されます。本文テキストを16px、行の高さを21pxとした場合、縦方向のスペースの基本単位は21pxになります。ページのバーティカルリズムを持たせるには、マージンやほかのテキストの行の高さなどを含むすべての縦方向のスペーシングを21の倍数にしてください。

配置と構成

モバイルファーストの哲学を採用する
画面が小さいので必然的に優先順位と階層の扱いが大事になる

メインのテキストブロックをななめ読みできるようにする

  1. 全体的な読む体験は最初のななめ読みで決まるので、可能な限りひと目で注意を引き込むようにする
  2. 小見出しは明確に識別でき、理解しやすいものにする
  3. 左側の端を明確にすることで、ページを下方に進む際の視覚的な手すりを読み手に提供する

3章:フォントの選択と使用

フォントが画面にレンダリングされる仕組み

画面はピクセルと呼ばれる極めて小さい光の点の面滅を放射します。

ラップトップやデスクトップの多くは、約140ppiの画面解像度を備えています。アップルのRetinaディスプレイなどの高解像度画面でも400ppi以下です。一方のプリンターは、比較的安価なレーザープリンターでも600dpiの解像度があり、プロ仕様のデジタルプリンターではx2,438dpiもあります。

各オペレーティングシステムにはテキストレンダリングエンジンが備わっていて（複数備えていることもあります）、それぞれのウェブブラウザがどのレンダリングエンジンを使用するかをコントロールしています。

→ つまり同じOSでもブラウザによってテキストの見た目が大きく異る可能性がある。

フォントはベクターでデザインされラスタライズされて表示される。ラスタライズされるときにエイリアス/グレースケールスムージング/サブピクセルアンチエイリアスのアンチエイリアス処理がある。
ただこのそれぞれの処理には何らかの欠点があったり、向いてない端末が出てきてしまう。
そのときに使うのがヒンティング。
参考） ヒンティング - 印刷用語集
Verdana、Geogia、Arialなどの主要なウェブ用のフォントはすべてのサイズで可読性が高くなるようにヒンティングの調整がされている。

マイクロソフトは正確さよりも鮮明さを優先させるというスタンス（へぇ〜となりました）

ウェブデザイン全般に言えることですが、デバイス間ですべてが同じようにレンダリングされることを期待してはいけません。自分の選択をベースに、何かがただ違って見えるだけなのか、または質が低下しているのかを評価します。

実際的及び実用的考慮事項

  • すぐにフォントを選択しない
    • どのフォントを使用するかは、特定の要件、文脈、成約、信頼性、そして最後は好みで決まる。
      • 美的判断より実用的な要件を先に考慮する。
  • ウェブサイトの性質をよく理解する
    • 今後複雑な機能を要求されるか
    • 読み手を没頭させるのか、流し読みで十分なのか
  • 必要な文字が揃っている書体を選択する
    • アクセント、約物が用意されているか
  • 必要なスタイルが書体に備わっているか
  • フォントのパフォーマンスを考慮する
  • ブランド要件に対して現実的に対応する

本文書体の決定

  • 読み手とテキスト感の摩擦を取り除く
    • 堅牢な書体の選択
    • アクティブなテクスチャとむらのないカラーでスムーズに読めるようにする
      • 読み手が長い朗読の聞き手だとすると、好奇心をそそりながらも、うんざりさせない程度に声に変化をつけた朗読（この朗読者の声のバリエーション = 書体のテクスチャ = 書体のコントラスト、フロー、サイズ）
      • Museo Sans と FS Emeric の例。わかりやすかった。
    • テキストに沿った書体を選ぶ
      • 文章の特徴をつかみ、テキストが醸し出す雰囲気をうまく表す言葉と考え、その感じやムードをデザインに取り込む必要がある
    • 自分の好みを信じる（！）

ディスプレイテキストの書体を選ぶ

  • かしこまらず、押しつけず、ありふれたものにせず
    • 書体を通じて感覚に働きかける
      • ディスプレイテキストは「読む」前に「見る」
      • 信頼性やトーン、コンテンツに対する先入観を刺激する
      • モフモフの子猫が大好き
    • さまざまなディスプレイ書体を試す
      • 働き者、個性派。柔軟性よりも個性を重視する
    • ディスプレイテキストにディスプレイスタイルを使用する

ウェブフォントを使用する

ペイロードとレンダリングタイミングの2点を最適化する必要がある。

  • WOFF は TTFとOTFのラッパー。WOFF2は圧縮最適化した新しいフォーマットだがすべての環境でサポートされていないのでフォールバックを用意する。
  • @font-face でWebフォント指定していても、フォントは必要なときのみ（該当するセレクタが存在するときのみ）ダウンロードされる。
  • ペイロードの軽減
    • 使用するフォント数の制限（特にアジア圏のフォント）
    • 必ずWOFF2オプションを提供（平均30%の節約）
  • ページのレンダリングタイミングを最適化する
    • FOIT = flash of invisible text = 見えないテキストによるちらつき
    • FOUT = flash of unstyled text = スタイリング前のテキストによるちらつき
    • font-display: を使用してブラウザの振る舞いを調整
  • 重要なフォントはプリロードする
  • フォントイベントでウェブフォント戦略を微調整する

感想

ウェブのタイポグラフィでも、古いときから使われている技術やルールをかなり大事にするべきなのだなと感じた。ウェブはウェブなので、、が通じるとこがもっと多いと思ってました。
自分の悪い癖だと思うのですが、文字をひとつのデザインや見せ方として捉えている部分があって、そういう手癖でやっていたこと（本文でわりとレタースペーシング入れる、テーブルの横幅100%など）は見づらいよと書かれており反省しました。。

最初に入った会社で朗文堂通ってたタイポグラフィ詳しい方にWebだけではなく文字周りの知識をある程度は教えて頂いたのですが、最近は特にデザインもする機会もなく忘れかけていた分野だったので若干なつかしさを覚えました。
結構この分野って知識の他に日々文字を眺める機会が誰でもあると思うのですが、それを見てどう感じてということの繰り返しで身につける系のスキルかなとも思っていて、文字詰めとかも最初はなんとなくでやっていたけど、やっていくにつれて覚えていけた感があります。
本書で触れている行間の設定なども結局デザイナーの目がものをいう部分も多々にあるんだなと思いつつ、カラーなどの概念を知らないでなんとなくいい感じを脱するためには学んだほうが良い知識が揃っていました。

イギリスの リチャード・ラターさん が著者で、監訳は 鈴木丈さん が行っていますが、日本語の場合はうんぬんかんぬんも補足しないといけないこともあるのでタイポグラフィ関係の翻訳めちゃ大変そうだな・・・と思いました。

この本に関してではないですが、やっぱり和文で扱い方が全く異なることもあると思うので、そこにフォーカスした本も読んでみたいなと思いました。
ただ ウェブ × タイポグラフィ でも割と狭い世界な印象なのでなかなか難しいのかなとも思います。

ほか参考

Nuxt.js・楽天市場APIでWebアプリをつくる

Nuxt.js GitHub フロントエンド

f:id:jotaki:20190924093802p:plain

Nuxt.jsと楽天市場APIでWebアプリを作成しました。

構成

f:id:jotaki:20200916091603p:plain

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 Nuxt.js

f:id:jotaki:20190315114020p:plain

結構詰まってしまったのでメモ

概要や大枠はこちら
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ファイルを生成してくれる。

成果物