00:04
はい、9月4日。嘘つけ、7月7日。
時刻は朝9時を回りました。
えー、本日の東京はまだ曇りなようですね。
ただ、台風の話もあるので、どうなんだろうとか、天気は悪くなると思いますけども。
はい、おはようございます。夢見のkeethこと桑原です。
では本日も朝活を始めていきたいと思います。
はい、というわけで今回はですね、タイトルにあります通り、
特編の記事を読むのではなくて、今回は、
前回同様、Weekly Frontend Roundup From Tokyoというサイトですね。
で、フロントエンドウィークリの、いわゆる国内の海外、
国内・海外のフロントエンドの関連情報をとりあえずガーッといろんなものを見て、
その中から10個ぐらいですね、厳選して毎週お届けしているサイトなんですけど、
今週分ですね、第367回目の記事を読んでいきたいかなと思っております。
はい、なんですけど、なんか早速、なんかうちの家のネットワークが早速死んでて、
サイトが表示されないっていう具合に思っちゃってますが、
あー出ました出ました。
はい、では早速10個のリンクを読んでいきたいかなと思います。
で、そのうちの1つを読んでいこうかなっていう感じですね。
はい、では行きましょう。
えー1つ目ですね、1つ目はディクラレイティブ、ディクラレイティブデザインシステムということで、
宣言的なデザインシステムというところですね。
従来のウェブ開発プロセスに則ると、必要となるデザインのパターンがとても多くなってしまうため、
マンメンテナンスな現実的ではありませんと。
代わりに宣言型デザインの考えを提唱してますと。
例として様々な色のボタンを実装することを例に挙げてます。
従来のデザインでは、それぞれの色に対してそれぞれのほぼ味の色を明確に指定しますけど、
宣言型デザインではその代わりに明度を5%低下させるというようなルールをセットすることで、
レジリエントなデザインを実装できますと。
これはCSSでも関数などの機能を使って実現できます。
それぞれのアプローチに優劣はなく、チームごとに適切な方法を採用することをお勧めしましょうということでした。
はい。
では続いてですけど、続いてはレッサー、レッサー派。
known and undelused CSS features in 2022というところで、
あまり知られていないCSSの機能というところですね。
はい。
CSSであまり使われていないが、すごく便利なプロパティ機能となって、
それを紹介していきましょうというところでした。
はい。
これ気になります、ちょっとこれは。
さすがに。
ちょっと軽く開いてみてみます。
結構ソースコード多いんだろうなともちろん思いますけども。
はい。
ちょっと見てみますと、なんかサイトもそもそもカラフルで面白いですね。
はい。
いくつかありますけど、allというプロパティと、
03:08
current colorってやつと、
custom property fallback valueってやつと、
はいはいはいはい。
やなやかやなって他にもあるんですけど、
確かにこれは結構便利そうですね。
便利そうなんですけど、かつちゃんとソースコードも出てきてますし、
コードペンによる実際に実行例も出てきてて、
これはすごく良さそうなんですけども、
ちょっとこれは音読ではしんどそうな気がするので、
今回読みたいけどちょっと割愛しようかなというところですね。
後ほどは自分でも読んでみたいと思いました。
続いてですね。
Don't fight the browser preload scannerって書いてありますね。
ブラウザのプリロードキャスターについての、
プリロードスキャナーについての解説ですね。
ブラウザのパフォーマンスを最適化を行う仕組みの一つに、
プリロードスキャナーというのが存在しますと。
この記事ではこの機能がブラウザの内部でどのようにワークするかを解説して、
その場合パフォーマンス改善のときのどのように合流すれば良いかを説明するということでした。
これもちょっと気になりますね。僕パフォーマンス中の人間なので。
けど全然パフォーマンスチューニングそんなに得意ではないんですけど。
続いてHow to disagreeというところですね。
正しく反対意見を述べるためにはどのようにすれば良いのか、
よくある反論のやり方を分類し、それぞれの特徴とどのようなやり方が良いかを解説します。
面白いね。これフロントエンドの方が気になりますけど、
でもこの人に今刺さったんでしょうね。
続いてTools for better thinkingということですね。
思考整理して深めるために使用できるツールというのを紹介します。
フロントエンドなんかちょっと分からないんですけど、
今後僕らが生きていく中で使えそうなツールが出てくるかもしれないので気になりますね。
残りここはinbriefというやつですね。
一つ目ですけども、inbrief一つ目はGuiding Principles、
Consent over Consensus。
チームで物事を進めるにあたって合意を形成するのではなくて、
同意を取ることの重要性を説いていますよということでした。
なるほど。
続いてCSSですね。
Absolutely Positioning Things Relativelyというやつですね。
この手のやつは目立たない発音の仕方が難しいですね。
Absolutely Positioning Things Relativelyということですね。
CSSグリッドを使用して複雑なレイアウトをレスポンシブにする方法というのを紹介してますよと。
06:00
続いてAvoiding Puppeteer Antipatternsということですね。
Puppeteerのアンチパターンを避ける方法ということでした。
これはもうタイトルからすでに吊られちゃったな。
続きましてAdversarial Testingということで。
アサイトリーアンオーソドックステスティングフィロソフィーということで、
テストを実装するときは物事がうまくいかないではなく、
うまくいかない方に関心を寄せることが重要であるということでしたね。
これも用意したいな。
さすが、厳選してるときあって気になる記事がいっぱい飛んできますね。
最後、10個目ですね。
What you need to know about the block protocolということで、
ブロックプロトコルについての概念を解説しますということでした。
ブロックプロトコリーズなんぞやってところなので、
もうすでに僕はあれですけど。
というわけで以上10個となったんですけど、
今日を読む記事は何にしようか悩ましいですね。
やっぱりパフォーマンス中だってさっきも言った通りなので、
パフォーマンス改善のプリロードスキャナってやつですね。
これも読んでみたいんですが、
画像がすごく大量に出てきてなおかつ、
ブラウザのコンソールとかから出てくる開発者ツールの一つをバリバリ使ってて、
それぞれについて一個一個見てるんですけど、
画像が多いのでちょっと説明、
僕では難しいかもしれないですね。
続いて、How to disagreeのところですね。
どうやって反対意見を述べるかというところですね。
これは読みやすそうですし、かつ僕らに全然活かせそうな感じがしますね。
フロントエンドというかソフトスケールって感じがしますけど。
続いて、Tools for better thinkingですけど、
これも完全にリンク集みたいな感じになってますね。
一個一個こういうツールとかフレームワークとかがあって、
それを使うとよさそうですよみたいなところですね。
例えば石川ダイアグラムとかですね。
これを使うとどういうことが解決できたり、
どういうふうに使っていくのというところがありますね。
とか、Six Thinking Hatsっていうやつですね。
これも結構かわいいですね。
本当にあのハット棒のやつの絵が出てきてて、
それぞれについてこれはどういう意味ですよみたいなのが書いてますけど。
読みやすそうではあるんですけど、
これもなかなか読むの大変そうですね。
ツールの数がですね、
24個、25個ぐらいありますね。
しかもこれら一個一個についての解説記事が載っているので、
よさそうではあるんですけど、
これは結構考えるの大変そうだなと思いましたので、
ちょっと今日は避けたいと思います。
続いて、Avoid Puppeteer and Patternも気になりますね。
09:06
ソースコードもほとんど出てこなくて、
基本的な考え方というか、
こういうところは避けましょうみたいなチップスみたいな感じになっているので、
結構よさそうなんですよね。
次、Adversarial Testingというところです。
これはテストについての考え方なんですけど、
ソースコードもそんなに多くないし短いので、
これをちょっと読んでもいいかもしれないですね。
次、What you need to do about the block protocol.
ブロックプロトコル僕はあんまり実は詳しくないんですけど、
ノーションの画像が同じに使われてますけども。
これも気になるんですけど、めっちゃ長い。
かなり長い記事になるので、
今日一日で読み切れない気がちょっとしてますので、
ブロックプロトコルなー、
しかもフロントエンドの人がそんなに意識しなきゃいけないものなのかも悩ましかったりするので、
保留かな。もちろんプロトコル周りのところは知っておいて損は全然ないと思いますし。
あれですけどね。
ラストもう一個がディクラレイティブデザインシステムですね。
デザインシステムのお話ですね。
これもそんなに長くないので、
気になったので一個一個読んでいこうかなと思います。
今日はデザインシステムのところと、
プリロードスキャナーなパフォーマンス中なので私が読みたいけど、
How to disagreeでその反対意見とかの述べ方っていうソフトスキルの話、
この2つを今日読もうかなと思いますね。
ちょっとフロントエンド関係ないかもしれないですけど、
何やかんやこの先の人生で生きるようなスキルな気がしているので。
前者のデザインシステムもフロントエンドの開発というわけではないですけど、
この辺の思想とか、デザイナーさんが何を考えているかっていうのは知っておくことがいいと思いますので。
じゃあそっちから読んでいきたいと思います。
ディクラレイティブデザインシステムってやつですね。
では早速翻訳をしていきましょう。
宣言型設計という考え方について書いたとき、
多くの人の共感を過去に得たことがあります。
設計や開発において全てを前もって正確に指定しようとする命令型のアプローチには、
一般的にフラストレーションがあると思います。
それはスケールすることはないのです。
JSONの言葉を借りれば、従来のウェブデザインプロセスっていうのは根本的に破綻していますと言ってますね。
はあ、なるほど。
JSONってどなたかちょっと分かんないですけど、
The traditional web design process is fundamentally brokenっていう記事がありますね。
これリンクが別に貼ってあるんで、もし興味があれば見ていただければと思います。
もちろん今日読んだ記事は後ほどTwitterでシェアさせていただきますね。
ちなみにディクラレイティブデザインっていうのも別の記事が貼られてますね。
12:01
ジャーナルがあるのでそこも背景として知っておくのがいいかもしれないですね。
先ほどのJSONの言葉を借りますと、
This is the worst of all worlds.
どこだ、これは。
翻訳されてますかね。
あるはずあるはず。
何重もの成果物を生み出すウォーターホール型のプロセスで、
どれもデザインがブラウザー上でどのように見え、どのように動作するかを正確に把握することはできません。
というふうにJSONという方はおっしゃってますね。
従来のWebデザインプロセスっていうのはいわゆるウォーターホール型のプロセスを使っているそうで、
そこから何重もの成果物をどんどん生み出しているっていう感じですけど、
これはデザインがブラウザー上でどのように見えて、
どのように動作するかっていうのを正確に把握することができませんよと言ってました。
おそらくWebっていうのは水物なので、
しかもどんどん作っていったり物事を進めていく中で変化していくものなので、
これをウォーターホール型でやっていくと正確に把握することは無理だよねっていう話だと予想しながらちょっと読んでみます。
理論的にはデザインシステムっていうのはこの問題を克服するために役立ちます。
前もって多くの時間をかけてコンポーネントを正しくしておけば、
あらゆる状況に迅速に展開することができます。
しかし正しいという言葉はそこで多くの役割を担っています。
命令型の考え方で設計システムに取り組むと、
正しいという言葉は正確という意味になります。
正しいと正確が実は違う言葉だっていうふうに認識されてるんですね。
命令型の考え方でデザインシステムに取り組むと正しいじゃなくて正確という意味になります。
正しいという言葉、このアプローチでは正確な感覚、正確な数字、正確なピクセルが価値あるものというふうに読みなされています。
しかし宣言型の思考でデザインシステムに取り組む場合は、正しいとは弾力的であると意味します。
ちょっと幅があったりとか柔軟性のところがあるものだと言っているんですね。
正確というと基本的に数字的な話に価値があるというふうに置いているけど、正しいという言葉でいくと弾力的であるというふうに意味している。
このアプローチでは柔軟性が価値があるとみなされていて、柔軟なスペーシングであったり柔軟な範囲であったりとか、アウトプットとかその辺を意識しています。
命令型の考え方は正確というところで数字の方に価値を置いています。
宣言型の思考では正しいという、つまり弾力的であるということを意味していて、こちらは柔軟性を重きを置いていますよということですね。
15:03
この2つの考え方の違いがあります。
これらの2つというのは根本的に異なるデザインアプローチでありながら、両者の結果というのはデザインシステムとして表現されることになります。
このデザインシステムという言葉はそのままでは定義するのが難しい言葉です。
ある人がデザインシステムと言うと非常に精密で制御された正確な部品の集まりを意味していますし、
別の人がデザインシステムを言うと部品を生成するため使用できる定義済みの境界条件のセットを意味するというように誤解を生む可能性が1つあります。
ただただデザインシステムといったところで、その人がどういうところですね。
どっちの観点でお話をされているかによって話は全然変わってくるねということですね。
確かによくあるというか言われてみればそうだなと思いましたね。
個人的にはシステムという言葉がデザインシステムの重要な部分だと考えています。
しかしあまりにも多くの場合、デザインシステムはシステムというよりもむしろコレクションであり、
コンポーネントを生成するためのシステムではなくてあらかじめ生成されたコンポーネントのコレクションなのですと。
まあ確かにそうかもしれない。
デザインシステムってシステムというよりも確かにコレクションですね。
そう言われればそうかもしれない。
システム的なアプローチというのはいわゆる宣言型設計の核心になりますと。
ルールと比率をあらかじめ設定しておいて、最終的な実装の詳細は実行時にブラウザに委ねますと。
私が考える宣言型アプローチのコンポーネントの例を挙げてみましょうと。
ここではデザインシステムのコンポーネントの中でもハローワールドと呼ばれる地味なボタンを使ってみましょうと。
今は画面上にコードペンの実行例がバーッと出てきているんですけど、
4つのボタンがあって、デフォルトボタンとアザーボタン、アナザーボタン、ワンモアボタンといって、
結局適当な文言が載ったボタンですね。
別にクリックしても何も起きません。
ここは1個1個違う色を設定されてますよという感じですね。
ただそれだけのボタンです。
ちょっと記事戻りますと、
2年前私はSASの色機能を実行するためのCSSのプログラミングについて記事を書きましたよと。
プログラミングCSS2パワフォームシスタスカラーファンクションという記事がありますよと。
その記事に書いたんですけど、カスタムプロパティやカルキュなどのCSSの機能を使って、
ダークインやライトンなどのミックスインを再現する方法について説明してますよと。
カスタムプロパティとしてエンコートされた色相、サイド、メイドというのを使用して、
ボタンの異なる色の要素を宣言するCSSをいくつか紹介しました。
以下は様々なボタンの例を示したコードペンですと。
ところですね。
これはいわゆるCSSバリューの値を、機能を使って色の設定とか定義をしているということです。
18:04
もしこのボタンが命令型の設計システムの中にあるとしたら、出力が重要な部分となるはずです。
設計システムというのはそのボタンを正確に作るために必要なコードというのを提供します。
もし別のボタンが必要なら、それはバリエーションとして設計システムに追加されなければならないでしょう。
しかし宣言型デザインシステムでは、アウトプットは基本的なルールセットほど重要ではありません。
この場合、次のようなルールがあります。
ボタンのホバー状態は、例えば背景色の明度を5%下げなければならない、みたいなルールがあって、
これをCSSでは次のようにエンコードされます。
ソースコードが出てくるんですけど、音読になるので、想像してください。
ボタンコロンホバーというセレクターが設定されていて、
その中にバックグラウンドカラーが指定されるんですね。
HSL関数にかけています。
その中に1個1個のプロパティとして、CSSバリュームのバーを使っています。
カラーをしています。
もう1個はサチュレーションですね。
最後の3つ目のところにカルキューを使って、
ボタンのカラーというのを-5%みたいな感じにして、
ホバーしたときの半透明5%というのを設定している。
そういう書き方を今回この方はされていますという感じですね。
すでにオパシティでいうかじゃなくて、
単純にHSL関数を使ってちょっと細かく制御しているというような感じです。
このようなデザインシステムというのでは、
いくつかの例を見てこのルールの実行結果を確認することができます。
しかしそれらのアウトプットはあくまで例示であって、
最終的なものではありません。
必要なものを生成するのに必要な情報は得られており、
しかしボタンのホバー状態など、
あらかじめ定義されたルールの範囲内に収まっているはずではありますよと言っていますね。
ここから何が言いたいのか、
現時点ではまだ分からないです。
このまま続き読んでいきたいですね。
この方がよりスケーラブルなアプローチに思えますと、
またより力を与えてくれるようにも思いますけれども、
デザインシステムは組織に組み込む際に最も難しいことの一つは、
人々にそれを採用させることです。
私の経験では上層部から提供される既成のコンポーネント群を採用することを好む人はいません。
それは役に立つことを意味します。
この既成のコンポーネントを使えば、
車輪の再発明する時間を節約できますよということになるんですけれども、
過度にコントロールされているように見えてしまうことがあります。
しかしこれは過度に支配的な印象も与えてしまう可能性があって、
我々はあなたが適切な判断を下せるとは信じていないので、
これらの既成のコンポーネントに固執してくださいと、
21:01
ような支配的な印象を与える可能性もあるよと言っていますね。
難しいところですね。
別にもう最初からできているものがあったり、
それを使えばデザインが表現できるようになったら、
そのまま使えばいいじゃんという思想もなくはないなと思っているし、
あれですけれど、
ただ一方で既存のものがあんまりちゃんと設計されていなかったり、
あとからプロパティ追加したりとか、
イベント処理したいなとなったときに、
既存のものに手を入れるのって面倒ってなったりするので、
ここは結構難しいですね。
はい。
今回の観点とは違うちょっとお話ですけどね。
はい。では戻りますね。
専念型アプローチというのはあまり支配的ではありません。
これは部品を作るためのルールとガイドラインです。
しかしこの正確さに欠けることがその概念の代償となっていまして、
設計システムを使う人は与えられた体系的なルールから
必要な部品を作るというヒントと能力を持つ必要があります。
私の直感ではFigmaとかSketchのようなグラフィックデザインツールには
命令型の考え方がよく似合うと思います。
これらのツールは範囲やルールでなくて正確な数値を扱います。
まあそうですし、結構現代の種類はこっちなんじゃないかと勝手に思ってました。
一方宣言型の考え方はCSSと相性がいいことに感じることが多くなったなって感じですね。
CSSはカスタムプロパティとして、
カルキューとかクランプとかミンマックスなどで
ルールを設定できるように結構柔軟性の方向に進化をしてきました。
ですからいつもと同じようにこのアプローチにも正しいも間違いもありません。
結局これはあなたの組織にとって何が最も適切であるかというところになります。
もし設計者や開発者が命令的な考え方を持っていて、
Figmaファイルシステムが真実の源であると考えられているのであれば、
命令的な設計システムの方が適しているでしょう。
しかしもし公文にもHTMLとCSSで考える設計エンジニアのチームがあるんだったら、
宣言型設計システムは力を発揮するでしょうと。
いわゆるデザインシステム、デザインエンジニアのための方向性になりますよということでした。
というところで、記事は区切られてますね。
はい、なるほどです。
さっきのボタンはほんとただ一つの例、説明のための例だったんですね。
命令型だと、さっきの例えば5%ってやつも最初からコンポーネント群にガンと最初から置いてあって定義してあって、
それを使いましょうという感じなんでしょうね。
命令型の方はそういうルールが置いてあるだけで、
それのルールとしてはCSSが書いているだけみたいな感じだと思いますね。
なるほどでした。
そうすると、宣言型の方ではあんまりそういうフィグマとかスケッチのようなデザインツールを使わないのかな。
デザイナーは多分使うと思うんですけど、デザインエンジニアという考え方でいくから、
作る時もあるかもしれないけど、作るというよりも厳密に言うと、
ルールをどこかにドキュメントにまとめておいて、
皆さんがそれぞれに応じて必要なものをどんどん作ってねという感じの思想になる気がしますね。
リポジトリウィキとか使うのかな。わかんないですけど。
24:02
あとはストーリーブックとかですかね。
ストーリーブックも結局作ったもののまとめではあるので、
宣言、命令型っぽくはないですね、確かに。
でも命令型の人たちもフィグマとかスケッチもそうですけど、
いろんなツールを使ってデザインを起こして、
それを結局ソースコードに落としていくと思うんですけど、
なんだかんだコンポーネントマップとしてストーリーブックを導入する気もしていて、
結構融合する感じはありますけどもね。
ただ、コースを削減するという意味ではフィグマだけでもいい気はしていて、
最終的にストーリーブックってメンテナンスされなくなるっていう傾向がやっぱり強いので、
どうなんだろうっていつも思いながら思ってたので、
一層のこと、宣言型に振り切ってみるっていうのが一つの選択肢としてはありかもしれないですね。
ただ、デザイナーの方が少しプログラマブルというか、
エンジニアライクな考え方ができてくれないと、
こういうチームは作れない気もしましたので、
ここは本当にチームにとって最適な答えっていう最後の答えが、
とてもそうだなっていうような納得がありましたね。
はい、そんな感じです。
じゃあ今ので、デクラレイティブデザインシステムというところのお話は終了にしようかなと思います。
残り時間が昨日30分になってしまったので、
もう一個の記事、How to disagreeってやつですね。
正しく反対意見を述べるためにはどのようにすればいいか。
よくある反論のやり方を分類して、
それぞれの特徴とどのようなやり方が良いかっていうのを解説してるっていう記事があるんですけど、
めっちゃこれ読みたいんですけど、時間が来てしまったので、
こちらはリンクだけ、後ほどツイッターで流すんで、
興味ある方読んでみてくださいっていうところで、
すみませんけど今日の朝方はこちらで以上にしたいかなと思います。
はい、本日も参加させていただいた4名の方ありがとうございました。
明日はまたゆるりと何か読んでいきたいと思いますので、
ご興味あれば参加いただければ幸いです。
では本日も一日頑張っていきましょう。お疲れ様です。
