Added ja (Japanese) for "The Elements of UI Engineering"

src/pages/the-elements-of-ui-engineering/index.ja.md

@@ -0,0 +1,63 @@
+---
+title: 'UI開発の要素'
+date: '2018-12-30'
+langs: ['en', 'ko', 'ja']
+spoiler: UI開発を難しくするものは何ですか?
+---
+
+[前の記事で](/things-i-dont-know-as-of-2018/)、知識のギャップについて認めるということについて話しました。
+あなたは私が平凡な提案をすると結論づけるかもしれませんが、違います！この記事は広い分野を扱います。
+
+私はあなたが「どこからでも始める」ことができ、特定の順序で技術を学ぶ必要はないと強く信じます。しかし私は専門知識を得ることにも大きな価値を置いています。個人的には、主にユーザーインターフェイスの作成に興味を持っていました。
+
+**私は、自分の知る価値のある物を熟考し続けています。** 確かに、私はいくつかのテクノロジ(JavaScriptやReactなど)に精通していますが、経験から得られるもっと重要な教訓はとらえどころがありません。私はそれらを言葉にしようとはしませんでしたが、初めてそれらを一覧にして述べます。
+
+---
+
+テクノロジとライブラリに関する「学習ロードマップ」はたくさんあります。2019年にどのライブラリが流行するのでしょうか？ 2020年はどうですか？ あなたはVueかReactを学ぶべきですか？ Angularですか？ReduxやRxはどうですか？ Apolloを学ぶ必要がありますか？ RESTまたはGraphQL？ 迷子になるのは簡単です。 作者が間違っているとどうなりますか？
+
+**私の最大の画期的な学びは特定のテクノロジに関するものではありませんでした。** むしろ、特定のUIの問題を解決するのに苦労したときに最も多くを学びました。助けてくれたライブラリやパターンを後から発見するでしょう。 他には、自分自身で解決策(良いものも悪いものも)を考え出すでしょう。
+
+それは*問題*を理解すること、*解決策*を試すこと、そして私の人生で最もやりがいのある学びをもたらした異なる*戦略*を適用することの組み合わせです。 **この記事は問題だけに焦点を当てています**
+
+---
+
+ユーザーインターフェースを加工したら直接もしくはライブラリを用いてこれらの課題にいくつか対処したことがあると思います。どちらの場合もライブラリを使用しない小さなアプリを作成し、これらの問題を再現して解決することをお勧めします。それらのどれに対しても正解はありません。学習は問題の領域を探り、さまざまな可能性のあるトレードオフを試すことから始まります。
+
+---
+
+* **整合性** 「いいね」ボタンをクリックすると、「あなたと他の3人の友人がこの投稿を気に入っています」というテキストに更新されます。もう一度クリックすると、テキストは反転します。 簡単そうですね。 しかし、おそらくこのようなラベルが画面上のいくつかの場所に存在します。 変更する必要がある他の視覚的な表示(ボタンの背景など)があるかもしれません。 以前にサーバーから取得され、ホバーに表示されていた「いいねした人」のリストに、クリックした今、あなたの名前が含まれているはずです。 別の画面に移動して戻ってきた場合、投稿はいいねしたことを「忘れて」はいけません。 ローカルの整合性だけでも、一連の課題が発生しますが、他のユーザーも私たちが表示するデータを変更する可能性があります(たとえば、私たちが閲覧している投稿を「いいね」することによって)。 画面の異なる部分で同じデータをどのように同期し、ローカルデータをサーバーとどのようにしていつ整合性を持たせさせますか？
+
+* **応答性** 人は限られた瞬間だけ行動に対する視覚的なフィードバックの欠如を容認することができます。ジェスチャーやスクロールのような*連続*のアクションの場合、この制限は低くなりますが(16msのフレームを1つスキップしても「がらくただ」と感じます。)クリックのような*単発*のアクションでは、100ms未満の遅延を*連続*のアクションと同じくらいの速さに感じるという研究があります。 アクションに時間がかかる場合は、視覚的なインジケータを表示する必要があります。 しかし、直感に反する問題がいくつかあります。 ページレイアウトを「ジャンプ」させる、またはいくつかの「ステージ」をロードするインジケーターは、アクションを以前よりも*長く*感じさせます。 同様に、アニメーションのフレームレートを落として20ms以内にインタラクションを処理すると、フレームレートを落とさず、30ms以内に処理した場合よりも遅く感じることがあります。 脳はベンチマーカーではありません。 アプリをさまざまな種類の入力にどのように対応させますか？
+
+* **待ち時間** 計算とネットワークアクセスの両方に時間がかかります。デバイスで応答性を損なわない場合、計算コストを無視できることがあります。(ローエンドのデバイスでアプリケーションを確認してみてください) しかし、ネットワークの待ち時間を処理することは避けられません - それは数秒かかることもあります！私たちのアプリはデータやコードがロードされるのを待つだけでフリーズすることはできません。 これは、新しいデータ、コード、またはアセットに依存するすべてのアクションが潜在的に非同期であり、「ロード」を処理する必要があることを意味します。 しかし、それはほとんどすべての画面で起こります。 スピナーやローダーを表示せずに、どのようにして遅延を適切に処理するのでしょうか。 どのように我々は「飛び跳ねる」レイアウトを避けますか？ コードを毎回「再配線」せずに非同期依存関係を変更するにはどうすればよいでしょうか？
+
+* **ナビゲーション** UIは操作しても「状態が固定されている」ことが期待されます。 いきなり物が消えてはいけません。 アプリ内で発生したか(例:リンクをクリックする)、外部イベントが原因であるか(例:「戻る」ボタンをクリックする)でもナビゲーションもこの原則を守る必要があります。たとえば、プロフィール画面で `/profile/likes`と`/profile/follow`のタブを切り替えても、外側の検索入力を消去することはできません。*別の*画面に遷移するのは、部屋に入っていくようなものです。 人々は後で戻って残した物を見つけることを期待しています。(おそらく、いくつかの新しいアイテムがあります) フィードの途中にいる場合、プロフィールをクリックしてから戻ると、フィードでの自分の位置が失われたり、再度読み込みを待つとイライラします。重要なコンテキストを失うことなく任意のナビゲーションを処理するようにアプリをどのように設計しますか？
+
+* **古さ** ローカルキャッシュを導入することで「戻る」ボタンのナビゲーションを即座にすることができます。 そのキャッシュでは、理論的に再フェッチできたとしても、すばやくアクセスできるデータを「思い出す」ことができます。 しかし、キャッシュが古くなることがあり、問題をもたらします。 私がアバターを変更した場合、キャッシュも更新されるべきです。 私が新しい投稿をする場合、それは直ちにキャッシュするか、今のキャッシュを無効する必要があります。 これはプログラムの難易度を上げ、エラーを発生しやすくします。 また、投稿が失敗した場合はどうなりますか？ キャッシュはどのくらいの期間メモリ内に留まりますか？ フィードを再取得したとき、新しく取得したフィードをキャッシュされたフィードと統合しますか？それともキャッシュを破棄しますか？ ページネーションまたはソートはキャッシュでどのように表されますか？
+
+* **乱雑さ** 熱力学の第二法則は、「時間が経てば物事は混乱する」というようなことを言います。(まあ、正確ではありませんが) これはユーザーインターフェイスにも当てはまります。 正確なユーザー操作とその順序を予測することはできません。どの時点でも、私たちのアプリは驚くべき数の状態のうちの1つにあるかもしれません。 私達は結果を予測可能にし、設計によって制限されるように最善を尽くします。 私たちはバグのスクリーンショットを見て、「どうしてこうなったのだろう」と思ってはいけません。 *N*個の状態がある場合、それらの間に *N×(N – 1)*個の遷移が可能です。たとえば、ボタンが5つの異なる状態(通常、アクティブ、ホバー、危険、無効)のいずれかになる可能性がある場合、ボタンを更新するコードは5×4=20の遷移に対して正しいものでなければなりません。どのようにして可能性のある状態の組み合わせ的爆発を抑え、視覚的出力を予測可能にするのでしょうか。
+
+* **優先度** あるものは他のものより重要です。 ダイアログは、それを生み出したボタンの物理的に「上」に表示し、コンテナの境界から「抜け出す」必要があります。 新しくスケジュールされたタスク(たとえばクリックに応答する)は、すでに開始されている長時間実行されるタスク(たとえば、画面の下の次の投稿を表示する)よりも重要な場合があります。私たちのアプリが成長するにつれて、さまざまな人々やチームによって書かれたそのコードの一部は、プロセッサ、ネットワーク、スクリーンエステート、そしてバンドルサイズの予算のような限られたリソースを取り合います。 CSSの `z-index`プロパティのように、「重要度」という共通の尺度でライバルをランク付けすることもできます。 [しかしそれがうまくいくことはめったにありません。](https://blogs.msdn.microsoft.com/oldnewthing/20050607-00/?p=35413) 開発者は自分のコードが重要であると考える傾向があります。 そして、すべてが重要であれば、何も重要ではありません。リソースを取り合うのではなく、独立したウィジェットをどのようにして他と*協力*させればいいのでしょうか？
+
+* **アクセシビリティ** アクセシビリティの確保できていないWebサイトの問題はニッチな問題ではありません。 例えば、英国では、障害は5人に1人に影響を与えます。 [(これは素晴らしいインフォグラフィックです。)](https://www.abrightclearweb.com/web-accessibility-in-the-uk/)私もこれを個人的に感じました。私は26歳ですが、細いフォントと低いコントラストでウェブサイトを読むのに苦労しています。私はトラックパッドの使用頻度を少なくしていますが、実装が不十分なWebサイトをキーボードで操作しなければならない日を恐れています。私たちは自分のアプリを高齢者や障害者の方にとって恐ろしいものにしないようにする必要があります - そして良いニュースは、少ない努力でそれを改善できることです。 それは教育と道具の段取りから始まります しかし、製品開発者が正しいことを簡単に行えるようにする必要もあります。 アクセシビリティを後付けではなく*デフォルト*にするにはどうすればよいでしょうか?
+
+* **国際化** 私たちのアプリは世界中で動作する必要があります。 人々が異なる言語を話すだけでなく、製品エンジニアの最小限の労力で右から左へのレイアウトをサポートする必要もあります。 待ち時間と応答性を犠牲にすることなく、どのようにして異なる言語をサポートしますか？
+
+* **デリバリー** 私たちは自分のアプリケーションコードをユーザーのコンピュータに渡す必要があります。 どのトランスポートとフォーマットを使用しますか？ これは簡単に思えるかもしれませんが、ここには多くのトレードオフがあります。 たとえば、ネイティブアプリは、巨大なアプリサイズの代わりにすべてのコードを事前にロードする傾向があります。 Webアプリケーションは、使用時の待ち時間が長くなる代わりに、初期ペイロードが小さくなる傾向があります。どの時点でレイテンシを導入するかをどのように選択しますか？ どのように使用パターンに基づいて配信を最適化しますか？ 最適なソリューションのためにはどのようなデータが必要ですか？
+
+* **障害許容力** あなたが昆虫学者であるならば、あなたはバグが好きかもしれません、しかし、プログラムの中でそれらを見るのをおそらく楽しんでいないでしょう。 しかし、あなたのバグのいくつかは、やむを得ずプロダクションに行きます。 その後どうなりますか？ いくつかのバグは間違っているが明確に定義された動作を引き起こします。 たとえば、ある条件下でコードが誤った視覚的出力を表示することがあります。しかし、レンダリングコードが*クラッシュ*した場合はどうなりますか？ それでは、視覚的な出力が矛盾するため、意味のあるように続けることはできません。 1つの投稿をレンダリングしてクラッシュしても、フィード全体を「停止」したり、さらにクラッシュする原因となる半破損の状態にしたりするべきではありません。 どのようにレンダリングとフェッチの失敗を分離し、残りのアプリを実行し続けるようにコードを記述しますか？ 耐障害性はユーザーインターフェイスにとって何を意味しますか？
+
+* **抽象化** 小さなアプリでは、上記で説明した問題の多くの特別なケースをハードコードすることができます。 しかし、アプリは成長する傾向があります。 私たちは自分のコードの一部を[再利用、フォーク、そして結合して](/optimized-for-change/) それをまとめて作業できるようにしたいと思っています。 私たちは、さまざまな人々になじみのある部分の間に明確な境界を定義し、頻繁に変更されるロジックが硬直することを避けたいと考えています。 特定のUIパーツの実装詳細を隠す抽象概念をどのように作成しますか？ アプリが大きくなったときに解決した問題が再び発生しないようにするにはどうすればよいですか?
+
+---
+
+もちろん、私が言及していない多くの問題があります。 このリストは決して網羅的なものではありません。 たとえば、デザイナーとエンジニアリングのコラボレーション、またはデバッグとテストについては話しませんでした。 またの機会にしましょう。
+
+解決策として、特定のビューライブラリやデータフェッチライブラリを考慮して、これらの問題について読むのは魅力的です。 しかし、私はあなたにこれらのライブラリーが存在しないとしてその観点からもう一度読むことを勧めます。 *あなたは*どのようにこれらの問題を解決するためにアプローチしますか？ 小さなアプリで試してみましょう! (GitHubでの実験を見てみたいのですが、気軽に私にツイートしてください。)
+
+これらの問題について興味深いのは、それらのほとんどがあらゆる規模で現れることです。 typeaheadやツールチップなどの小さなウィジェットとTwitterやFacebookのような巨大なアプリの両方でそれらを見ることができます。
+
+**あなたが楽しんで使っているアプリの重要なUI要素のことを考えて、このリストを通過してください。 開発者が選んだいくつかのトレードオフについて説明できますか？ 同様の動作をスクラッチで作り直してみてください！**
+
+私は、ライブラリを使わずに小さなアプリケーションでこれらの問題を実験することによって、UIエンジニアリングについて多くを学びました。 私は、UIエンジニアリングのトレードオフをもっと深く理解したい人にも同じことをお勧めします。

src/pages/the-elements-of-ui-engineering/index.ko.md

@@ -1,7 +1,7 @@
 ---
 title: UI 엔지니어링의 요소들
 date: '2018-12-30'
-langs: ['en', 'ko']
+langs: ['en', 'ko', 'ja']
 spoiler: 무엇이 UI 엔지니어링을 어렵게 할까요?
 ---
 

src/pages/the-elements-of-ui-engineering/index.md

@@ -1,7 +1,7 @@
 ---
 title: 'The Elements of UI Engineering'
 date: '2018-12-30'
-langs: ['en', 'ko']
+langs: ['en', 'ko', 'ja']
 spoiler: What makes UI engineering difficult?
 ---