00:03
はい、8月18日木曜日ですね。地獄浅久寺を回りました。今日の東京はあいにくの雨ですね。朝から結構強めな雨が降っている感じです。
おはようございまーす。みなみなkeethくんのくわんはらです。 本日も朝活を始めていきたいかなと思います。
いきなり余談から入るんですけど、
会社のスラックでちょっとフィードバックをもらったんですけど、 いつもピンマイクを使って配信をしてるんですけど、
音声聞き取りづらいというか、やっぱり音声の質が悪いので、今日はピンマイクじゃなくてiPhoneのデフォルトのスピーカーでやってますけど、どうなんですかね。
どれだけ違いがあるかわからないので、ちょっと試しにやってみてるって感じです。 じゃあ、今日の朝活やっていきたいと思います。
昨日なんだっけ、 話題を読もうと思っているものの中に、リアクトのパフォーマンス周りの改善の記事を読もうかなみたいな話をしてたんですけど、
軽く述べた通りですけど、要はリアクトの、
フックスの中にあるんだっけ、 ユーズメモとか、ユーズコールパックとか、メモとかですね。
レンダリングの計算回数ですね、再評価とかリレンダリングの回数を減らしましょうとか、 あとはそもそもの計算処理そのものを減らしましょうみたいな感じで、
結局チップスのまとめを見たんですけど、結局よくある話だったなという気がしたので、 ちょっと読むのやめようかなと思いました。
じゃあ今日何を読むかはいつものですけど、タイトルのあるとおりですね。 アウイクリフロントエンドラウンドアップフロム東京さんの記事ですね。
その中の最新の更新が入ったので、それを見てみたいかなと思いました。
モリューム373ですね。 要は10個ぐらい記事バーッと
ピックアップされて、それが完結まとめられたってやつですね。 これを読んでいって、
何か刺さったものとか深く読んでいこうかなというものを決めていこうかなと思います。 じゃあ早速ですけど10個読んでいきたいかなと思います。
ねぶさんと、
おむらさんですね。おはようございます。 正式にはECさんですね。はいおはようございます。ご参加ありがとうございます。
では読んでいきましょう。 一つ目ですね。
一つ目、How Netflix Creates Immersive UX Design and What We Can Learn From Themですね。
ネットフリックスのUXデザインから学ぶっていうところですけど、 ネットフリックスが提供している機能とか仕組みについて取り上げ、それがどのようにUXを
改善しているかについて解説していきましょうと。 またそこから学べることを次の4点でまとめている。
一つ目はユーザーがクリックしたくなる明確なCTAを備えたシンプルなUIにすべき。 二つ目はパーソナライゼーションをしましょうと。
三つ目がブランドに継続的に勝ちづけを行う。 ネットフリックスのオリジナルのように競争上の優位性を持つと。
最後4つ目ですね。顧客を情報に対しビジュアル、アニメーションまたはゲーミフィケーションで引き付ける。
03:03
この4つっていうのを解説してますよということでした。
これはちょっと、早速一発目の記事から気になると思うんですね。
2つ目の記事ですけど、テクニカルライティング for Developersですね。 テクニカルライティングニューモンというふうに今訳されてますけど、
エンジニアにとってテクニカルライティングはコーディングと同様に重要な要素であります。
この記事ではプログラミングとライティングをどのように組み合わせ、 テクニカルライティングを行えばよいかというのをちょっと解説してみましょうというところでした。
3つ目の記事ですね。3つ目はモデリングストラテジックチョイスですね。 戦略的選択のモデル化というふうになってますけど、
現実の戦略的選択の効果を測定することは難しい。 この効果を測定する一つの方法というのは情報アーキテクチャを調べること。
戦略的選択というのは情報アーキテクチャに具体的に並ばれますというふうに言ってますね。
これはちょっと気になったな、僕はですね。 4つ目です。4つ目はWhy your cached JavaScript is still slow and
increases performance overheadと書いてますね。 JavaScriptがキャッシュされ、ブラウザーキャッシュから読み込まれた場合にも、
JavaScriptの読み込みに伴うオーバーヘッドが発生し、 パフォーマンスに影響する可能性がありますと。
この記事ではキャッシュされたJavaScriptの実行に関わるオーバーヘッドについて、 着目しそれがどのように発見・改善を行うかというのを解説しますと。
最近ちょっとパフォーマンス周りすごい気になっているので、 この記事は気になるんですけど、多分ソースコードだらけなんじゃないかと
予想しますが、ソースコードというよりも画像だらけですね。 ブラウザーの会社ツールからいろんなものを見ていますよという感じですね。
一応読めはしますけど、多分僕ばっかりが理解する感じになっちゃう感じですね、これは。 かなり画像がふんだんに使われているので。
すごく読みたいんですけど残念ですが、これちょっと今日割愛します。 後ほどツイートするので興味ある人は見てみてください。
じゃあ続いていきますが、
じゃあ続いていきましょう。 戻ってきて、いくつ目でしたっけ? 1、2、3、4、5つ目ですね。
5つ目は、The Many Faces to Themarable Design Systemsですね。 テーマ適用というのが可能なデザインシステムはどのように実現できるのかと。
テーマが必要とされるユースケースを想定しながら、 それをどのような設計で実現してもらえるかというのを考察してみましょう。
という感じですね。はいじゃあ続いて残り5個ですね。 インブリーフで残り5個読みます。6つ目の記事ですけれども、
What is the best way to make up an exclusive button group?
リレイアウトというサブタイトルがありますけど、 ボタングループはどのようにマークアップすべきかの議論を、ツイッター上で行わない、どのような方法が最適かというのを
06:00
検討しますと。 ツイッター上で議論をしたんですね。
なるほど でまぁそれを一応
ツイートをバーっとまとめてるとかピックアップして、それを記事にした感じですね。 これは読めそうですね。かつそんなに長くなかそうですね。
気になったらって感じですけど。はいじゃあ続いていきましょう。7個目ですかね。 ネーミングコンベンションスポーデザインシステムですね。
デザインシステムにおける命名規則のベストプラクティスについて紹介しましょうと。 論理的、スケーラブル、シンプル、標準的の4つのポイントについても紹介していきますというところでした。
はい。続いて8つ目の記事ですね。
Where is the button? Designing for mode confusionですね。 モードという概念がユーザーを混乱させる例を挙げ、それがどのように対処すべきかについて紹介をしています。
で続いて9つ目ですね。リアクトフックス the deep cuts って書いてますね。リアクトであんま使われてない種類のフックスについて解説をしましょう。
これ多分ソースコードだらけですけど気になっちゃったなぁ。 はいラスト10個目ですね。
a particle guide to changing code so you can understand it ですね。テストがないソースコードをどのようにリファクタリングしていくかについてステップバイステップで解説しましょうと言いますね。
はい。 さすがラウンドアップフロム東京さんですね。ちょっと今日は
ほぼ全部読みたくなっちゃったので悩ましいですけど、今の10個から何を読もうかなってことですが、 やはりデザイン周りのところとか、ユーザーに沿ったお話とか結構気になるんでそこも読みたいんですけど
えっとですね一番気になったのは結局モデリングストラテジックチョイスイズのところですね。 戦略的選択のところですね。
が気になったので読みたいと思います。 で残った時間でまあなんか別のガチャガチャ読んでいきたいんですけどそのリアクトフックスの話も
すごく気になるんですけど案の定、今ざっと眺めてるんですが、 ソースコードだらけなのでこれはやめた方が良さそうですね。
かつ、はいはいはい。 あと最後に出てきたプラクティカルガイドツーチェンジコードほげほげってやつですね。
テストについての周りの話ですけど、これもソースコードだらけなのと久しぶりにこれ多分Rubyかな?
Rubyのコードっぽいですね。なんか久しぶりだな。 なので、ちょっと僕があんまりRubyを理解しないというのもあるので今日は断念しようかなと思いました。
じゃあえっと早速ですけども
さっきの モデルの方の話になりたいと思いますね。
では行きましょう。あんまりちょっと長くない。結構短い記事なのでスパッと終わっちゃうかもしれないですけど。
09:06
我が家のネットワークが遅くて、DeepLの翻訳がすげえとろい。 開きましたね。じゃあ行きましょう。この記事のバージョンというのは私のニュースレターに最初に掲載されました。
このような記事を毎週日曜日に受信するためにサブスクリプションでご覧ください。
多くの方がチェスを主に戦略ゲームだと考えています。 私もそうでしたが最近になってチェスというのは主に戦術のゲームだと考える人がいることを知りました。
つまり基本的な遊びの小さなセットを学ぶことでより強いプレイヤーになれるということですね。 まず手を、手というのはまあいろんな
戦略とかいわゆる確実したものをマスターして、それを戦略的に展開をしていきましょうという感じです。
なるほどね。戦略ゲームじゃなくて戦術だというふうに言っていると。 チェスが成功するのは戦略と戦術のバランスをモデル化し、勝つためにリソースをどのように配置するか
各プレイヤーに主体性を持たせているからだというふうに言っています。 偶然性というのはほとんどなく、ほとんどが技量に依存します。
そして他の多くのゲームと同様にシナリオっていうのは安全であると。 つまり負けた時の結果が深刻ではないよねと。
モデルもシンプルなので盤面を見れば誰が勝っているのかっていうのは全然わかります。 しかし現実の世界ではそうはいきません。
ビジネスのような複雑な領域では戦略的戦術的な意思決定を完全に代行できる個人というのはごくわずかになります。
多くの場合、ある人が意思決定し、ある人がそれを実行します。 現実の世界では戦略的選択の効果を測定することも非常に困難ですと。
戦術的イニシアチブの効果を、結果を戦略的決定に容易にマッピングすることもできませんし、誰がなぜ勝っているのか、勝っているのかっていうのを周りを見渡すだけでは判断できませんと。
はい、なんかもう本当その通りだなって感じがしますね。
で、 もうちょっと続けていきたいとおもいますが
僕のパソコンが固まった気がします。 このタイミングで固まるのはちょっと勘弁してほしいなと思いますが
固まりましたね。 ちょっと待って、ほんまに困る。
マジで困る。 しかし仕方ないので。
パソコンが固まったのではなくて、ディプエルが固まったっぽいですね。 なるほど、なのでちょっと翻訳変えますね。
なんだっけ、Google翻訳はちょっとしょぼいというか、あんまり信頼性がないので、昔使っていた未来翻訳っていうのがあるのでそれを使いたいと思います。
未来翻訳、ご存知の方もいるかもしれないですけど、割とクオリティ高いんで、 これはこれでお勧めしますね。一応有償版もあって、それもサポートされてるんでいいんですけど。
12:00
では未来翻訳から翻訳していきましょうと。 本当にうちのようなネットワーク問題ひどいんで、引っ越しを真剣に考えようと思いますね。
戻ります。戦略的選択の効果を把握する一つの方法というのは一応あって、その一つの方法というのは、
製品の情報アーキテクチャを調べることですと。 システムの構造上の違いっていうのは私たちの戦略的意図について多くを明らかにします。
例えば、プラットフォーム戦略を具現化した製品。 そのあちサードパーティー制で構築できるものですね。
というものは閉鎖的なワンストップショットになるということを目指したものとは異なる編成になるでしょうと。
またテスラというのはちょっと考えてみましょう。 他の自動車メーカーというのはディーラーを通じて販売していますが、テスラは消費者に直接販売している。
戦略が大きく異なり、結果も異なります。 テスラは見込み客をサードパーティーに引き渡すのではなく、体験を端から端までコントロールします。
テスラ.comでの行動の呼びかけというのは、ディーラーを見つけるではなく支払いを続けることで、これは大きな違いです。
そしてそれはテスラのウェブサイトに反映されています。 言われればそうですね。
車って言うと確かにそもそもディーラーを探す感じは確かにしますけどね。 ちなみに僕は車持ってないんですけど。
情報アーキテクチャというのは抽象化と実行にまたがるため、多くの場合、戦略的選択の最初の具体的な形となります。
デジタルの文脈ではIAは戦略が現実のものになるとところであり、これまで要約の中で議論されてきたアイディアというのがスプレッドシートやスライドデッキを通じて初めて具体的に現れたものになります。
そして具体的で戦略的な選択を行うことができるようになります。 もちろん戦術ってのも重要です。
CSと同じようにどんなに健全な戦略的意図であっても、実行がうまくいかないと失敗することがあります。
優れた画面レベルのデザインというのはテーブルの杭であります。 しかし戦略的思考よりも戦術的実行を改善する方がもちろん簡単です。
建築上の区別というのは、建築上というかアーキテクチャですね。アーキテクチャの上の区別というのは戦略的選択というのを具体化しています。
その結果情報アーキテクチャというのはモデリング戦略の強力なツールとなります。
戦略に基づいたIAというのは、世界での異なる生き方のための足掛かりを確立します。
それは組織に新しい可能性をもたらすのです。というところで今回の話は締められていました。
ちょっと抽象度の高い言葉かつ、戦略と戦術の
はっきりとした定義というのは書かれてなかった気がしますね。
個人的にはなんだっけ、クラストインスタンスみたいな感じに聞きましたね。実体というか実行するものが戦術の話であって、戦略はそのためにどうするかみたいなところだと思いますけど。
どっちも大事なんですけど、やっぱり戦略がそもそもみたいな話に僕は聞こえましたね。でもそれは本当にその通りだと思うし、
でも両方のバランスは取らないと結果的なものが全然変わってくるというのもあるので、しっかりその辺も加味してくださいねというふうにおっしゃるというふうに思いましたね。
15:07
はい。 まあまあまあ
当たり前のことを当たり前にちゃんと言語化したというところですけど、当たり前とかシンプルなものであるほど、実際に現実で落とし込むというとかなり難しいので、この手の議論は永遠に続く気はしますけど、でもこれを
続けていくことがやっぱり人類の進化に繋がる、技術の進化にも繋がると思うので、これはありがたいですねと思います。
はい。またその、何ですかね。 現時点でのモダンですけど、これがまた5年後とかになると全然また違う議論がされている可能性もあるので、この辺の話はずっと
僕らもしっかり追っていくのがいいかなと思いましたね。はい。以上、モデリングスタテジックチョイスでした。はい。戦略的選択のモデルの話でしたね。
以上ですね。残りは12分で、12分で何を言おうかちょっとまた悩ましくいいですね。 それぞれの記事が割と長いんですけども、
どうしようかな。割と読みたいものはたくさんありすぎて困っておるが、
いけるかな。 前回もちょっと技術的な話ばっかりだったので、ちょっとデザインの話いきますかね。
いや、リアクトのフックスの話はやっぱり読みたいんですけど、案の定ソースコードのオンパレードで、 ざっくり、タイトルだけ、テーブルオブコンテンツだけ見ましょうかね。
はい。テーブルオブコンテンツで、ユーズリデューサーとユーズレフト、ユーズインプラ、インプラティブハンドルか。
ユーズメモとユーズコールバックと、最後にファイナルソーツですね。 ファイナルソーツでこの辺のものを使ってみてくださいってところですけど。
はいはいはい、なるほどね。ファイナルソーツの中でさらに、 以下のリソースといって他の記事ですね、とかリンクとかが、参考になったらリンクの記事はばーっと貼ってあるので、
これはわかりやすそうですね。 それぞれ一個一個見ていくのがいいかもしれないですけど。
というので、ここもちょっと割愛をして、 最後何読もうかってことですけど、
Where is the button? ボタンの話ですね。デザイン for mode confusion です。 ユーザーが困惑しないようなデザインどうするの?みたいな話だと思うので、
これ辺を読んでいこうかなと思います。 ちょっとデザイン的なお話になってしまうんですけども。
はい、では行きましょう。
やっぱダメか、ディープウェルさん死んでますね。
はい、いきます。
私の画面が見えますか?と。チャットウィンドウが表示されません。 セスという友人の声に緊張感が感じられます。
彼が前者会議で発表するのを始めていた。代表の方かもしれないですね。
彼はこの役には新参で登場することを恐れており、最初のこれらの障害は彼を動揺させました。
セスさんはビデオプレゼンテーションの共有に失敗することを心配しているわけではなくて、
その経験がストレスの多い瞬間を強めているとのままでも確かではありますね。
18:00
ソフトウェアは素晴らしいものですけど、我々はそれが酷いものになり得ることを身をもって知っています。
私たちが普段使い慣れているツールを使って予想外の体験をするのは気が引けてしまいます。
自分自身や製品に自信を持たせることなんでもできません。
これらのエクスペリエンスは次のことによってトリガーをされます。
結構ありますね。
大幅な設計の更新だったり、役割と権限の変更、製品のさまざまな側面のアクセス、
あとは状態の変化、インターネット接続が失われたとか、あとモードの変更。
モードの変更というのは多くの人によって結構混乱のポイントになります。
これらは例えばキャプスロックキーをオンにして入力するような日常的な動作になる可能性もあります。
誰がキーを必要とするんだってみたいな。
そうですね。ぶっちゃけキャプスロックキーって本当誰が必要なんですかね。
いまだにわからないし、ずっと外してほしいという機能だったなと僕も思いますね。
まあ、ちょっとわからないですけど。
また誤って、キーボードショートカットを入力して新しいモードを起動することもできます。
このようなデジタル体験というのは、自分が属していない部屋に入ることにも似ています。
最悪の場合、あなたはどのように去るかを知らないかもしれません。
そうですね。
結構コンピューターとかパソコンに慣れていない人とか、キャプスロックキーをいきなり起動して外せなくて、
それと同じようなことがあなたにも起きるかもしれない。
もしくはユーザーに起きるかもしれないですね。
ではモードとは何でしょうか。
モードはアクティブな状態に応じて、システムによってユーザー入力の解釈が異なります。
同じ入力でも結果は異なります。
一つのモードというのは、製品がアプリ内の異なるエクスペリエンスでユーザーを集中させる方法になります。
目的というのはユーザーが特定のタスクを実行できるように支援することですよ、という話でした。
以上、今のが導入ですね。
では早速、ここから具体的な本文に入っていきたいと思いますね。
デザインの記事は控えそうですけど、さっきの記事よりより抽象度が高いので、
僕が理解できるかというところも、少しの、1末の不安はありますね。
では行きましょう。
When modes are useful.
モードが便利な場合、もしくは使いやすい場合みたいなところですかね。
モードというのは、ツールが複雑でユーザーが実行できるアクションが多数ある場合に便利です。
その恒例が、Photoshopの歪みモードですね。
歪みモードって言うとあれですけど、インクイファイモードですかね。
僕はPhotoshopを全然使わないので、そういうモードがあるんですね。
このモードに入ったユーザーというのは、どのようにしてそこに到達したかというのを理解します。
このモードでは、特定のレイヤーを操作する特定のアクションにユーザーがフォーカスされます。
モードを終了する簡単な方法もあります。
モードの別のユースケースというのは、ユーザーがプライマリーモードとは異なる特定の意図を持っている場合です。
Google Docsの提案モードというのはその一例であります。
ああ、はいはい、そういうことですね。
このモードでは、ユーザーはテキストを提案できますが、既存の作業を完全に上書きする権限はもちろんありません。
キャンバス上の提案インジケーターというのは特定のモードであることをユーザーに知らせるために優れた手がかりですよということですね。
21:04
Google Docsの提案モード、僕も結構好きですね。
あれはわかりやすいし、ちゃんと意図を表明できる、かつ上書きをするわけではない、その場でいわゆるコミットするわけでもないので、
全然リスクなくガンガン書き込めたりもできるので、あれは素晴らしいですよね。
で、管理者の方が後でそれを見て、これは入れましょう、これは違うね、みたいなこともできたりするし、
その提案についてのコメントもできたりするというのがよく設計されているものだなと思ったりしますね。
はい。余談、余談が挟まったので戻りますが、
続いてですね、Do you need a mode? そもそもモード必要ですか?というところです。
はい。ユーザーエクスペリエンスにとってモードが重要でない場合は、別のコースを選択することを検討してください。
なぜならば、モードというのはユーザーエクスペリエンスに多くの摩擦をもたらすからです。
ほう。オペレーターが誤ったモードを想定してシステムと対話する場合、重大な状況が発生する可能性があります。
このような状況の動定と分析というのは、システム設計とオペレーターのメンタルモデルの両方を考慮する必要があります。
ああ、まあそうね。設計というよりもメンタルモデルのところか。そこをベースに設計するはずですから確かにそうかもしれない。
なるほどね。 続いてモードコンフュージョンですね。そこから次にモードの混乱という話に移ります。
例えば航空業界を取り上げてますけど、航空業界はモードの混乱、いわゆるタイトルですね、モードコンフュージョンですけど、という公式用語を作っているそうですね。
がありました。パイロットにとっての疑問は、私がコントロールしているのか、それとも自動操縦なのかということですね。
ああ、はいはい、そういうことね。モードですね。航空業界とは異なり、ほとんどの製品でモードの混乱は精子にかかる問題ではありませんが、その重要性を見過ごしてはいけないということではありません。
大きなプレゼンの場合、落ち着きを取り戻そうと奮闘しているチームメイトの切磋を見てください。
モードの混乱というのはユーザーに不要なストレスを追加します。ストレスの高い状況ではモードの混乱は苦痛な契機になります。
はい。 なるほどね。
航空業界は確かにモードが間違っていたら思いっきり精子にかかりますからね。それは確かに怖い話ですね。
なのでこうやってちゃんと公式用語が作られたというぐらいだと思います。 普段の僕らが使うアプリケーションで死ぬことは確かないんですけど、
でも確かに重要な問題になる可能性もあるし、ユーザー離れてしまう可能性もあったりするので、全然無視もできない話ですよね。
かつそのモードが違ったりして、その不一致によるストレスは確かにずっと苦痛な経験ですもんね。
はい。 モードの混乱というのは、しっかり言葉の定義をしてみましょう。
技術システムの観察された動作というのがユーザーのメンタルモデルの動作と同期していない場合だというふうに言っています。
モードの混乱を2つの潜在的な問題に分けてみましょう。
モードスリップ。 ユーザーがあるアクションを実行しようとしているが、そのモードの曖昧さのために別のアクションを実行してしまう場合というのがあります。
24:08
これがよくある話だと思いますね。 もう1個がモード固有の機能の発見可能性と言っています。
もしくは学習可能性。 ユーザーが特定のモードの機能に戻る方法を見つけて記憶する方法ですね。
なるほどね。 モード固有の機能の発見可能性もしくは学習可能性。
ここは結構でもUIとかUXの設計にかなり依存するような気はします。 そもそも見えなかったりわからなかったりするものに対してユーザーは知る余地はないので、
そういうモードがあるんだっていうのを変な操作でいきなりバンって出たらそれは体験が悪いので、発見可能性とか学習可能性を高めると結構大事な話かもしれないですね。
続いていきましょう。あと3分。あと3分でいけるかな? いけそう。
そこからですね。 So, how do you design to prevent mode confusion? ということですね。
ではモードの混乱防止にどうしたらいいでしょうかというところですけど、 システマティックモードのスリップというのはまず識別しましょう。
ユーザーがモードスリップに陥ったかどうかをシステムが識別できますでしょうか。 例えばユーザーがログアウトした場合、別のユーザーがプロジェクトの状態を変更する場合、
操作を行った場合、またはインターネット接続を失われた場合はどうなりますか。 スリップが発生する可能性のある原因の一覧を作成してそれに合わせて設計をします。
これ最初にどこまでそういう想定ができますかとか、そういうデータベースがあるかっていうのも結構大事かもしれないですね。
そういうモードスリップっていうふうにこの人たちは言ってますけど、そのモードスリップ、いわゆるテストでいう異常系ですよね。
その一層がどこまで豊富であるかっていうのは結構大事かもしれません。 それに合わせて設計ができるので。
明確に識別可能なモードインジケーターですね。 ユーザーが非プライマリーモードになっている場合はそれを明確にします。
それはステータスバーかもしれないし、Google Docsの例のようなキャンバスインジケーターかもしれません。
レイアウトの変更、色の変更、アイコンの変更、見出しとテキストの変更など様々な方法があります。
どんな方法を選ぶにしてもそれを明らかにしてくださいということですね。
続いてモードの影響に対する期待値を設定しましょうという話ですね。 ツールヒントとインジケーターを使用してユーザーの期待というのを確立します。
例えばユーザーの機能が制限されているか拡張されているかというのを通知します。 優れた例としてユーザーが破壊機能を持つようになった時の色とアイコンの警告があります。
同様にユーザーにできることできないことは知らせますようですね。 これはまあ多分しつこいというか使っててたまにイラッとするかもしれないですけど確かに大事かもしれないですね。
下手に破壊コードを押してしまって全部消えたよとか元に戻らないんだけどってなるぐらいだったら先にしつこさを出した方がいいかもしれないですね。
27:00
続いて有用なエラーメッセージと処理を記述しましょうという話です。 モードの曖昧さが原因でユーザーがハードにぶつかった場合はその理由を明確にします。
ユーザーがこの混乱を回避するのに役立つ簡潔なメッセージを記述します。 特定のアクションを実行できない理由または突然そのアクションを実行できる理由を理解できるようにしましょう。
ユーザーはセカンダリーモードに慣れていない場合があるためそれらのモードについてしっかり説明をしてくださいという話でしたね。
続いてクリアエグジットドアですね。
今のモードからいわゆる抜けるためのドアというところをしっかりしましょうとですね。 出口ドアのクリア。エグジットマークが公共の場で少しやりすぎに感じるのにはやっぱり理由があります。
ユーザーがストレス化で理解できるように設計されています。 モードでも同じバラダイも使用します。ユーザーは特に
モードスリップによって入力したモードを明確にエスケープできる必要があります。 ユーザーが知っているプライマリーモードに戻る簡単な方法を定義しましょうという話でした。
ちなみに余談ですけど、エグジットマークってよく見たらですね、あの緑と白の人が何か出口に向かって走っているマークあるじゃないですか。
あれ緑と白逆転してるんですよ実はよく見ると。 あれちゃんと意味があって出口に近い方がどっちだっけ
どっちだっけやばい忘れた。 人が白い方か人が緑の方か忘れましたけど出口に近い方と出口の方向に向かわせる方で2つあれ
実はエグジットマークって色分けされてるんですよね。 どっちがどっちか忘れてるのであまり僕は意味なかったんですけどまぁ一応雑学でした。
続いて明確な確認のもとに良好な摩擦を実現。 良好な摩擦って面白いですね。
グッとフリクションって書いてますね。 パソコンのゴミを出したことありますか。確認なしポップアップなしの対話について考えてみてください。
これらのファイルを完全削除しますかというようなこのような状況での警告ってのは適切な摩擦になりますと。
エクスペリエンスを向上させるためにユーザーの速度が低下します。 まあそう良いフリクションというのはその山道の脇のガードレールもしか悪いフリクションは
道路を塞ぐ倒木と考えることができます。 特に不慣れな環境ではユーザーが自分のアクションと確認の意味を理解できるようにしましょうという
ふうに言ってますね。 なかなか今回の表現というか
あれはわかりやすい引用というかわかりやすくて面白いですね。 パソコンのゴミの削除ですね完全の削除のところのポップアップ
確かにわかりやすい例だと思いますね。 絵として人はあんまり見てない気もしますけどね。適当にもういいから削除しちゃおうと言って削除して後から
やべぇあれ消してしまったっていうのはあったりするので最低限パソコンというかシステムとしては ユーザーのための保証はしましたよっていうところはありますけどね。
続いてstrong safety nets 強力なセーフティーネットですね。 gmail にも送信取り消し機能があります。これは送信した内容を再行した
30:01
場合に便利です。しかし意図しない全員に返信というのはどうだろうかと。 もしセーフティーネットがユーザーが返信を後回しにできるようにしていたらとか
全ての電子メールにインデントなしで返信することはモードの混乱に対する迷惑で危険な結果の完璧な例になります。
メールは結構ねこれは議論の余地はずっと永遠に続く気はしますけどもそもそも電子メール そのもそのもみたいな議論もあったりしますが
はありますよね。ただ送信取り消し機能があるのは結構面白いですよね。 送信ボタンを押したらいきなりパッとくるんじゃなくて実は数秒間待ってから実はあれを送っているんですよね。
数秒中は実はストップできるんですよね。 個人的にはあれ結構ありがたかったりしますね。
ミスタップとかミスクリックであの送信してしまったというものがあったりしますからね。 はいというところでした。続いて
モードを使用しないことも検討しましょうということです。 モードの混乱を軽減する優れた方法の一つというのはモードレスインターフェースというのを作成することですと。
別のモードが必要ですかとかそうでない場合はCore Experienceに組み込むことを検討してください。
というところでした。 そもそものモードの使用可否っていうか存在価値というところですね。
もういけたら確かに面白いですね。 気づいたら30分を超えたんですけどあとほんとちょっとなので走り切っていきたいと思います。
続いて前提条件のテストですね。 推奨できる最も簡単な最も重要なアドバイスというのはユーザーテストを実行することです。
そりゃそう。私たちは簡単に自分たちのデザインは間違いないと信じるマナーに陥ります。
多くの場合そうではありません。テスト学習反復というのはしっかりしてください。 クライアントワークだったらちゃんとクライアントの方が
レビューしてくれたりするんですけどとはいえやっぱりアプリ作ってたりその先に進んだところで 実際にユーザーに使わせてみると微妙とかなることが全然あり得るので
ユーザーテスト、タイミングですよね。テストするタイミングとかあとペルソナとか 誰にテストさせるか何人にテストさせるかって結構その辺も重要になってくるんですけど
設計段階でそこまでやるのは結構限界はあるのでしっかり作ってそこをリリース する前にテストしてもらってそれを反映して改善してというサイクルを繰り返すのがいいと思いますね。
はい。繰り返しますとキープイテレーティングですね。モードの混乱というのは設計するのがもちろん簡単ではありません。
私たちは力づくでこの記事を書いているのではなく何度かミスを犯したものとして今は積極的に後片付けをしています。
痛みを持ってこの記事を書いたとこですね。
ラストです。これ結論というかラストですね。
ウェブフローの私のデザインチームにこの議論にかかってくれたことに対して大きなエールを送ってください。
チャーリーフードとモリートラファティという方が書いてくれたそうですね。
というところで一応サンクス的なものを書いたって終了です。
あと一応フットノートとして他の記事いくつか載っているのでその辺も見てくださいということでした。
はいというわけでちょっと時間またオーバーしてしまいましたけど以上
ウェアズザボタンデザインフォーモードコンフュージョンというところでした。
33:02
あんまりボタンの話は出てこなくてボタンは多分タイトルにはわかりやすく使っただけであって
主題としてはモードコンフュージョンのところでしたねというお話でした。
参考になるというかしっかりその辺は議論しなきゃいけないなと思いますし
モードっていう概念で切り口からデザインっていうのを見たことは
僕ら開発者だからあんまり考えたことないですけどユーザー側に近い目線から
この話を聞くと確かにそうだなっていうのはいっぱいあるので
UXってことを考えるときにそのモードのコンフュージョンというところですね
今自分どういうモードですかっていうのを意識的にユーザーに認識させるっていうのは結構大事だなって思ったし
その観点からも今後はレビューしてみたくなりましたね。
はいっていう感じでした。
じゃあ以上で今日も結局グダグダになってしまったんですけど
朝活終了したいかなと思います。
じゃあまた明日ですね。明日はまたちょっと技術的な記事かなをちょっと探そうかなと思ってます。
最近このいろんなフロントエンドのウィークリのまとめのサイトってたくさんあるっていうのを
また新しいのを知ったんですよね。
よく見るのはJSRインフォと今日見たようなラウンドアップ
フロントエンドラウンドアップフロム東京さんとか
あとはいろんな個人の方がまとめているウィークリのフロントエンドのまとめとかあるんですけど
それに海外の方がやっているウィークリフロントエンドっていうまとめ記事もあって
ここは結構JavaScriptばっかりの記事だったりするんですけど
ただわかりやすかったりするし
普段僕らが私がですけど見なかったりする記事とか
JSRインフォとかでも見ない記事とか結構載ってたりするので
この辺からまたピックアップしてまた読んでいこうと思います。
ただ割とやっぱりソースコード出てくる
本当に具体的な書き方系のお話だったりするので
どこまで読むか悩ましいんですけど
見つけて読んでいきたいなと思いますので
ゆるりとご参加いただけたら幸いです。
では今日も多くの方にご参加いただきありがとうございました。
また明日もゆるーくやっていくのでご参加いただけたら嬉しいです。
では今日も一日頑張っていきましょう。お疲れ様でした。
