【デザイン】Figmaについて

参画しているプロジェクトのデザインツールをFigmaにする案がでているようで、ちょっと調査

www.figma.com

2015年にEvan Wallace氏とDylan Field氏がWeb のアクセシビリティとネイティブ アプリの機能を組み合わせたデザインツールを作成

それをFigma1.0として誰でも無料で始められるようにしたのが始まり

最初はWeb上で共同制作することに対するネガティブな意見があったが、だんだんとポジティブな意見が増えていったとのこと

ビジョンは「To make design accessible to everyone.（誰もがデザインにアクセスできるようにする）」

Google TrendでAdobe XDと比べると徐々に人気がでて追い越してきている模様

日本でも頻繁に導入事例の記事があがっている

メリット

ビジョンにもあるように、デザイナーだけでなく様々な役割の人が触れるようにWeb上で作業できるということ

また、そのことによりURLでデザインやコメントの共有をすることができる

その他にも

• バージョン管理
• コメント機能

など

デザイナーではないのでSketchなどとの細かい使い勝手は不明

価格

プロフェッショナルだと一人当たり$12/月
組織で使う場合は一人当たり$45/月

小規模なら無料ライセンスで十分だが、30 日間のバージョン履歴というのがちょっと気になる

Sketchとの機能比較などや、ショートカットなどは別の日に確認したい

他参考

カスタムプラグインでReactコンポーネントを出力ことができたみたい
今後ここらへんを調査したい

https://note.com/seyanote/n/n787e33f54967

【Design System】ペパボのデザインシステム

この間のWeb24で話に出ていたペパボのデザインシステムについての記事

tech.pepabo.com

気になったワード

Flavor：デザイントークンを差し替えるだけでそのサービスのブランドを崩さずにデザインする仕組み

色や形など、ブランドによって上書き可能なデザイントークンを、Flavorと呼ぶ変数にまとめておくことで、Flavorを差し替えることでブランドイメージを崩さないデザインができるようになります。

とのこと

面白いアイデアはデザイントークンをValue TokenとSemantic Tokenの2種類に分類していること

記事から拝借するとこのような感じ

// Value Token
$blue-400: #afb3ba;
$blue-500: #9297a1;
$blue-600: #3e6f99;
$blue-700: #585c63;
$blue-800: #393c41;

// Semantic Token
$informative-color: $blue-600;
$positive-color: $green-600;
$notice-color: $yellow-600;
$negative-color: $red-600;

.informative-button {
  color: $informative-color;
}

学んだのはタイポグラフィの話で、ページの縦方向のリズム（バーティカルリズム）を揃える話が勉強になった

なんらかの調和する比率をもとにスケールを作り、そのスケールをタイポグラフィのガイドラインにしようという話（モジュラースケール）や、実際にウェブサイトで調和する比率に「調和数列」を用いたという話は以下の記事を参考にされたと書かれていた

ekrits.jp

記事はとても読み応えがある

フォントサイズや行の高さなどを「調和数列」や「フィボナッチ数列」といった「ある秩序」を用いて作ることの美しさにちょっと感動する

キリの良さから何も考えず5px単位で作っていた自分がすこし恥ずかしい

ペパボさんはこの記事のアイデアからウェブ上でバリエーションをプレビューできるツールを作成したとのこと

⚖️ Harmonic Typographic Scale Calculator

今後参考にさせていただきたい

参考

Web24のデザインシステムのまとめ 　 https://togetter.com/li/1708694?page=2

【プロトコル】「QUIC」が正式スタート

新しいプロトコルQUICがRFC9000の発表で正式スタートしたもよう

約5年前にGoogleが独自に開発・運用していたものが度重なる議論の末ついに正式版になった

新しいプロトコルを作るってすごいことだ

www.fastly.com

QUIC

QUICはUDPソケット上に用意したプロトコル

現在最も一般的に使用されているトランスポートであるTCPでは接続初期に何度か往復した通信（3 way ハンドシェイクによる通信前のやりとり、ackによる相手の受信確認など）をする必要があるが、UDPはコネクションレス型のプロトコルで信頼性が低下するものの通信回数を減らすことでパフォーマンスへの影響を減らしている

そして、独自に一定の信頼性を保つ実装を組み込みつつHTTPに適した効率的でレイテンシの小さな通信を行えるようにしたのがQUIC

暗号化にはTLS 1.3を採用し、このQUICにHTTPを適用させたのが「HTTP/3」

QUICをサポートしているWebサーバはざっと調べた感じあまりまだなさそうだが

一部Cloudflareのサービスが対応していたり、NGINXがプレリリース版がでたりと続々と対応を進めている

あとは、2018年には既にGoogle CloudのHTTPSロードバランサーがQUICプロトコルに対応していたり、Fastlyがサポートすると発表したりしている

ちなみに

QuickはIETF9000ではQuick UDP Internet Connectionの略ではなくなったとのこと

他参考

https://www.rfc-editor.org/rfc/rfc9000.html

https://www.publickey1.jp/blog/20/quichttp3ietfrfc.html

https://www.publickey1.jp/blog/20/fastlyhttp3quic.html

https://www.publickey1.jp/blog/18/google_cloudhttpsquic.html

【デザイン】Airbnbの2021年デザインアップグレード

Airbnbがこのコロナ禍でWeb・ネイティアプリのデザインアップグレードを行った

リモートワークによって人々は外出先での束縛が少なくなり、いつでも移動できるようになったことで旅と生活と仕事が曖昧になっているという

曖昧になったということで旅行者には検索の『柔軟性』が不可欠になっているとのこと

news.airbnb.com

そこでAirbnbは『柔軟性』の観点で、3 つの新しい検索方法を導入した

https://news.airbnb.com/2021-release/

flexible date（一番左）

日付を指定して検索するだけではなく、週末の休暇、1 週間の休暇、さらには 1 か月の滞在を検索できる

flexible matching（真ん中）

検索条件のすぐ下に検索結果の物件リストを表示

flexible destination（一番右）

特定の目的地の検索ではなく、たとえば、日本の旅館、イタリアのトルッロ、スペインの城のような検索ができる

他にも理想的な場所を見つけやすくなるように検索機能を大幅に改善している

例えば

• より迅速なチェックアウトプロセス：新しいゲストが最初の予約を確認するための手順の数を減らす
• 到着ガイド：チェックイン前に、ゲストが必要とするすべての役立つ情報 (道順、ドア コード、Wi-Fi、ホスト オプションのメッセージ) に簡単にアクセスできる
• レビュー：ゲストは、批評から賛辞まで、滞在を評価するためのより完全なスペクトルを持つようになった
• より明確なキャンセル:：更新されたキャンセル ポリシーにより、ゲストとホストの両方が明確になる

確かに、アフターコロナではユーザーの考え方が変わっているかもしれない

ニュースタンダードに応じて自分が携わるサイトのアップデートも必要だと思う話だった

他参考

https://news.airbnb.com/wp-content/uploads/sites/4/2021/05/Airbnb-Report-on-Travel-Living.pdf

【Elasticsearch】restore時に正規表現をつかってrenameする

Elasticsearchのindexをrestoreする場合に正規表現を使えるのは知っているが、数字を扱う場合\dが使えるのか[0-9]の方がよいのかわからなかったので調べた

例えば、Elasticsearchのindexをバージョニングしている場合で、例えば以下のようなindexが存在している場合

• my-index-v1.1.1-apple
• my-index-v1.1.0-banana

これのスナップショットを取得して以下のようにrenameしてrestoreしたい

• restore-my-index-v1.1-apple
• restore-my-index-v.1.1-banana

restoreする際のrenameはrename_patternとrename_replacementを使えばできる

www.elastic.co

POST /_snapshot/my_backup/snapshot_1/_restore
{
  "indices": "data_stream_1,index_1,index_2",
  "ignore_unavailable": true,
  "include_global_state": false,              
  "rename_pattern": "index_(.+)",
  "rename_replacement": "restored_index_$1",
  "include_aliases": false
}

このとき使える正規表現は以下に書かれていた

www.elastic.co

これによると、\dは使えないみたい

やりたかったことは以下で実現できた

{
  "indices": [
      "my-index-v1.1.1-apple",
      "my-index-v1.1.0-banana"
      ],
  "ignore_unavailable": true,
  "include_global_state": false,
  "include_aliases": false,
  "rename_pattern": "my-index-v1.1[0-9]-(.+)", 
  "rename_replacement": "restore-my-index-v.1.1-$1"
}

【Web】AOMとは

AOMというワードを聞いたので調べた

AOM (Accessibility Object Model)

AOMとはアクセシビリティオブジェクトモデルの略で、アクセシビリティオブジェクトモデルとはユーザーと開発者のウェブページと支援技術間の相互作用に関する体験の一部を向上する取り組み

この取り組みは、開発者が API に情報を提供し、ブラウザがそれらの API に提供する情報を理解できるようにする Web プラットフォームへの追加を開発することを目的としている

masup9.github.io

背景

単純に<div>などでマークアップされたサイトの場合、株価の表示や、Twitter のフィード更新、進捗の表示やそれらに似たコンテンツは、目に見えないユーザーのための支援技術 (AT) が認識できない方法で DOM を変更することになるかもしれない

現在、これを解決する手段としてARIA（Accessible Rich Internet Applications）を使用する方法があるが、Web アプリはAPI がまだ十分でない

AOMはこれに対処するための HTML および関連する標準に対する一連の変更を行うことをさす

詳しくは以下

github.com

https://developer.mozilla.org/ja/docs/Web/Accessibility/An_overview_of_accessible_web_applications_and_widgets

【Web高速化】Webフォントを正しく扱う

Webフォントは重たいので、パフォーマンスの観点であまり導入しないほうがよいと思っていたが

軽量化を試みればパフォーマンス影響をほとんどなくすことができると知って調べた

サブセット化

対策としてよく知られているのが、「サブセット化」という手法で、使用頻度の低い文字を除外してファイルを軽量化する

Googleフォントの場合のサブセット化についてのドキュメントは以下

developers.google.com

導入には以下の記事が参考になった

www.webcreatorbox.com

GoogleフォントのURLのクエリパラメータにtext=xxxxxxxで使いたい文字列を指定するだけ

<head>
  <link href="https://fonts.googleapis.com/css2?family=Kosugi+Maru&display=swap&text=Webフォントを使う文字列" rel="stylesheet">
</head>

記事ではスピードインサイトのスコアが91→100になったといっていて、100ということはパフォーマンス観点ではほとんど影響ないということがわかる

unicode-range

unicode-range は 特定の文字範囲を設定し、その範囲の文字が該当ページで使用されている場合のみ対象のフォントリソースを提供するようにできるCSSプロパティ

フォント提供者が設定する

developer.mozilla.org

Googleフォントの Noto Sans JP ではこんな感じ

/* [0] */
@font-face {
  font-family: 'Noto Sans JP';
  font-style: normal;
  font-weight: 400;
  src: url(https://fonts.gstatic.com/s/notosansjp/v28/-F62fjtqLzI2JPCgQBnw7HFowwII2lcnk-AFfrgQrvWXpdFg3KXxAMsKMbdN.0.woff2) format('woff2');
  unicode-range: U+25ee8, U+25f23, U+25f5c, U+25fd4, U+25fe0, U+25ffb....;
}
/* [1] */
@font-face {
  font-family: 'Noto Sans JP';
  font-style: normal;
  font-weight: 400;
  src: url(https://fonts.gstatic.com/s/notosansjp/v28/-F62fjtqLzI2JPCgQBnw7HFowwII2lcnk-AFfrgQrvWXpdFg3KXxAMsKMbdN.1.woff2) format('woff2');
  unicode-range: U+1f235-1f23b, U+1f240-1f248, U+1f250-1f251, ...;
}

unicode-range はページ中の出現頻度が高い文字をちゃんと考慮して範囲を指定しているみたい

他参考

https://developers.googleblog.com/2018/04/google-fonts-launches-korean-support.html

https://twitter.com/clockmaker/status/1396964812433674242?s=20