見出し画像

「入門GUI」と「WEB+DB PRESS」に寄稿しました

miyaoka

本日4月23日ですが、明日24日に発売される WEB+DB PRESS Vol.116 にフロントエンド技術の記事を寄稿しました。🎉🎉🎉

内容は「現場で使える！ モダンフロントエンド技術」という連載で、その第1回目担当として「作って学ぶGUIのしくみ - カルーセルを実装してみよう」というタイトルで書きました（全6回予定でROXX社のメンバーが順に書いていきます）。

スクリーンショット 2020-04-23 8.31.37

（ビュンビュンしてるタイトルの様子）

複雑GUIの会による「入門GUI」

さかのぼって、先月の技術書典8にて「入門GUI」という本を5人のメンバーで作りました。

こちらのイベントはオンラインのみの開催となってしまいましたが、反響はけっこう良くて300部以上購入いただけたとのことです。

で、以前の記事に書いたんですが 複雑GUIの会 という謎の会合をやっていて、その中の有志で技術書典用に本を書こうということで形になったのがこの「入門GUI」という本です。

（複雑GUI会の様子）

（はっしゅろっくさんによる「入門GUI」紹介）

そんなわけでせっかく本を出したのでブログ書こう書こう…と思ってたんですがなかなか書けないままで、気づいたらWEB+DBのほうにも寄稿したのでそのへんをまとめて振り返るというのが本記事です！

どんな内容か？

「入門GUI」ではドラッグでリスト要素の並び替えをするUI（Sortable）、WEB+DBのほうではカルーセルUIをテーマにして、求める機能をどのように策定して実装していくかという話を書きました。

昨今のフロントエンドではいかにstateを破綻なく管理するかというあたりが焦点になっていて、GUIについてはちょっと複雑なものはライブラリを使うのが普通だと思います（GUIと言ったらフロントエンドの世界はすべてGUIですが。例えばカレンダーとかみたいな複雑機能のGUI）。ライブラリがあるのにGUIを一からスクラッチで作るというのは多くのケースでは必要ないですし、車輪の再発明なところでもあります。

このへんは現場の肌感なんですが、おそらくQiitaとかを見てもフロントをいかに運用するかという話が多く、いざGUIを作ってみようにもそもそもどうやってある程度複雑なGUIを作るの？という疑問があるんじゃないかなと思います。

なので、そうしたGUIづくりの世界に一歩踏み入ってみるための本というのが「入門GUI」のコンセプトです（おいでよ！GUIの沼）。WEB+DBのほうも同様にGUIへのいざないを目指して書かれてます。

わからん！もっと具体的に😡😡😡

キャプチャを載せましょう。

スクリーンショット 2020-04-23 9.30.58

スクリーンショット 2020-04-23 9.31.06

スクリーンショット 2020-04-23 9.31.21

スクリーンショット 2020-04-23 9.31.31

これは「入門GUI」の僕の原稿ですが、GUIをどっから作るかという話で僕はGUIに触れずにデータのtestから作る話を書きました。書きましたけど、これはわりと理想論ですし、やるかやらないかでいったらやらないほうが多いと思います。じゃあなぜ書いたかっていうと、まあGUIの本質的な要求ってわりとふわふわしてて、せめてデータの部分をカチッとしてからやるとブレにくいんじゃないかなーという想いですね。

実際ふだんやるのって、ある程度GUI作ってみて、なんか細かい挙動が自分でもよく分からん、ちゃんと規定しよう！ってところでtest書いて仕様を詰めていくことが多い感じはします。

スクリーンショット 2020-04-23 9.44.14

WEB+DBのほうでは、カルーセルには特徴的なループするスクロール挙動があることや、そのへんをどのような考えで実装するのか、みたいな話を書いてます。

なので興味あったらぜひ読んでみてください！

金曜GUI

あと、複雑GUI会の面々と金曜の夜にライブコーディングでGUI開発する会をなんとなくやってます。

不思議なGUIが並んでますが、たとえば僕が作ったのはトイレットペーパーの垂れてる部分をホイールスクロールすることで紙を引き出してクリックでカットするというGUIです。このGUIはなんの役に立つんでしょうか？ 分からないですね。金曜GUIは完全に素振りの世界です。ここで役に立たなくてもあとで知見を活かしてヒットが打てればいいんだと思います。

最近やってるGUI

スクリーンショット 2020-04-23 10.18.48

ふだんSTUDIOという会社でWebサイトをGUIで作れるサービスを開発しているのですが、ここではとにかく機能を実現するためにGUIが作られまくってます。

現在はSTUDIO3.0という大型アップデートの作業中で、新たに追加されたCMSの動的データをデザインエディタ上でどう選択させるかというあたりでも何度も試作を重ねてGUIが作られてます。

STUDIOの開発は、プロダクトの仕様や実装について話すと各々がこうあるべきと主張し合って毎度コンフリクトが生じ、揉めに揉めることが多いです。

noteでの最初の記事に書いたように、GUIの設計はとにかく意見がぶつかり合います。どっちかっていうと僕はエンジニアの技術都合で考えがちで、対してCPOのケイマくんはコードが分からないユーザーが何も考えずとも使えることをとことん追求してます。

このへん技術的な設計の正しさを主張すると、ユーザーの都合というのはむしろ正しくないとさえ感じることもあります。しかしなんだかんだでやはりユーザーにとっての都合の良さを追求するのがGUIなんだと思います。

画像10

（技術都合とユーザー都合がぶつかりあう様子）

たとえば、ブラウザには元々URL入力欄と検索入力欄がそれぞれあるのが普通でした。これは技術的な都合ですし技術的に正しいと思います。2つのデータは別々のものなので。

スクリーンショット 2020-04-23 10.38.33

（検索とURLが別々）

スクリーンショット 2020-04-23 10.41.39

（検索とURLを兼ねたomnibox）

しかし今では統一されてるのが普通です。ユーザーからしたら、URLだろうと検索語だろうと、やりたいことは一緒なのです。

ただ、別々のものを一個にする場合はやはり競合するところも出てきます。たとえば https://example.com という文字列を入力したらURLと解釈されてそのページが表示されますが、やりたいことが 「URLの文字列を含むサイトを検索したい」ということもあります。そういうケースを考えるとやはり成立しないから一個にまとめるのは正しくない！と技術視点では主張したくなります。

ただ実際には現行ブラウザで当たり前に使われているように問題は解決されてます。?を入れてから入力すれば検索モードになるので使い分けたいときには使い分けられるわけです。

STUDIOでGUIを作っているとしばしばこういう議論が起こります。なにかを都合よくしようとすると、細かいところではうまくいかないところが出てきがちです。しかしそれはそれで ?接頭辞をつけるようになにか対処をすれば済むというケースもよくあるのです。

まとめ

最後に「入門GUI」に収録した座談会の様子を一部載せときます。

スクリーンショット 2020-04-23 11.10.26

スクリーンショット 2020-04-23 11.11.52

なにかしらの問題解決のためにGUIが存在して、そもそも問題が解決されてしまえばGUIも存在しなくていいとかそんなようなことをちょくちょく話し合ってます。

この記事が気に入ったらサポートをしてみませんか？