一部のプログラマーが開発のUI部分を嫌うのはなぜですか？
私が出会った多くのプログラマーはいつも「彼はUIの男ではない」と言っています。実際のところ、最近の開発は、Web、Windows、Linux、OSX、またはその他の種類の開発にかかわらず、見栄えの良いUIを備えたソフトウェアで構成されています。なぜ多くの開発者がUIの動作を好まないように見えるのですか？
私もUIの人ではありません。ええと、私は自分のプロジェクトでUIを行っていますが、仕事ではそれとは何の関係もありません。私の仕事は、フロントエンドではなく、アプリの根本にあります。
それを超えて、私はそれが憎むよりも退屈だと思います。 UIの設計は、困難でやりがいのある部分です。実装はほとんどが面倒な作業です。ユーザーインターフェイスを実装する方法については、課題や革新はほとんどなく、わずかにメンタルになる前に画面にチェックボックスを配置できるのは、ほんのわずかです。そしてそれは、ピクセルを「ちょうど」整列するのに何時間も費やすことにも触れていません。
優れたUIを作成するには、いくつかのバックエンドコードを作成するよりも多くの異なるスキルが必要です。
バックエンド要件は、通常、ブラックボックスのように指定できます。xが入力され、yが出力されるはずです。機能させるにはロジックを実装する必要があり、機能するかどうかをプログラムでテストできます。
優れたUIを作成するには、ユーザビリティ、ビジュアルデザイン、レイアウト、配色などを考慮する必要があります。芸術的な創造性を持っていることはここでのボーナスであり、多くのプログラマーはこれを持っているとは感じていません。論理的に考えると、UIの問題の解決策は主観的に思えるかもしれません。正解が1つも、それが「正しく」行われたことを検証する簡単な方法もないためです。
UIの経験があまりないか、調査をあまり行っていないプログラマーの多くは、使いやすさの観点とデザインの観点（たとえば、色）の両方から優れたUIデザインの背後にルールと科学があることに気付かないと思います理論）。
もちろん、一部のプログラマーはこの側面に問題はありませんが、多くのUIがコードに飽きるだけなので嫌いです。それらは、管理ページ用のフォームのページのような多くの反復的な作業で構成されている場合があり、機能する必要があり、設計上の課題はありません。
人々は単に異なる興味を持っています。一部のプログラマーは、データ構造とアルゴリズム、アーキテクチャー、使いやすさ、UIデザイン、またはこれらと他のニッチの組み合わせに関心があります。それぞれに異なるスキルと問題についての異なる考え方が必要です。低レベルのプログラミングの基本が好きなら、おそらくユーザーの考えをあまり気にしない、またはその逆です。
個人的には、私は後者のキャンプに陥ります-複雑なアルゴリズムよりもむしろUIを設計したいです。それは私が面白いと思うようなものです。
与えられたUIデザインが良いか悪いかはかなり主観的であり、プログラマーは一般的に魅力的ではないと思います。優れたUI手法を定量化および認定するための数十年の努力は、適用できるいくつかの広範なルールを作成するのに役立ちましたが、UIが優れているかどうかを実際に決定するには、多くの場合、多くのA/Bテストおよびその他のユーザー監視が必要ですテクニック。
プログラミングには主観があることは確かですが、一般に、ある選択が別の選択よりも優れている理由について、何らかの形の客観的な理由を指摘できます。実行速度、メモリ要件、起こりそうな将来のニーズを満たす柔軟性、明らかにより効果的であることが証明されているプラクティス過去など。特定のUI選択を擁護し、そのために選択自体を行うことも、一般的には「私はそれが好き」に低下します。
私は個人的にUI開発が苦手です。UI開発が苦手です。ユーザー心理学には、私が理解するのが苦手な要素があります。私の最大の問題は、ユーザーの立場に身を置くことができないことです。ユーザーにとって直感的なものがわからないため、直感的なレイアウトを作成する方法もわかりません。見栄えをよくする方法もわかりません。
一部のプログラマーは、UIの設計が得意ではないことを嫌うのと同じくらい嫌いだとは限りません。 UI開発が苦手な開発者がたくさんいることは、たまたま起こります。
UIデザインの問題は、誰もが意見を持っていることです...そして正解も不正解もありません。一方、開発者は白黒とロジックが大好きです。どんな規模の企業でも、誰もがそれに同意するでしょう1+1=2、ただしどのフォントが最も読みやすいかを尋ねる(Comic Sans Obviously)...洪水の準備をしなさい。万人は異なるので、1万通りの答えと誰もが正しいです。
UIでの作業を実際に楽しんでいる開発者（具体的には、私はWebデザインのかなりの部分を担当しました）として、スキルセットを持っていない人がそれを避けてくれることを感謝しています。
開発には、多くのデータを頭に入れておき、一度に多くのことを処理できる能力が必要です。 UIの設計には、整合性を犠牲にすることなく、可能な限り最小限に抑える機能が必要です。私愛その挑戦;誰かが画面上で管理できないwall-o-dataであるUIを作成するのを見ると、私はうんざりします。 （私はまた、レイアウトや色彩理論などに関しては完全にマニアです。）
一方、私はhate低レベルのものです。ドライバーやカーネルなどのコードには触れません。：shudder：「UI以外の人」に任せます。他の誰かが楽しんでくれて嬉しいです。
間違った人からの入力が多すぎるため、UI開発は複雑になります。彼らはすべてグラフィカルデザインのエキスパートです。何かの公式を知りたいときに、どこにあるかわかりません。
彼らは自分が何を望んでいるのかは分からないが、見たときはそれを知っており、味もない。そして、決定力を持つ人々は、とにかくアプリケーションを使用しないが、緑色であるべきだと確信している。フォームのフィールド数を制限するなどの適切なUIのガイドラインに従い、すべてのフィールドを「必要」とし、別のタブに配置するのは非常に手間がかかるため、さらに50のフィールドを追加するように要求されます。 Excelと同じです。農民！
これを補うことはできません。大規模な法律事務所の経理部門の上位2名（年収約50万人）が、弁護士が使用する請求Webサイトのページのラベルをめぐって30分費やしたミーティングに参加しました。これは、弁護士が理解しやすくするためだと思います。弁護士に聞いてみませんか？簡単すぎる。したがって、IT部門は、WTFの「残余純請求額」について知りたい弁護士からの電話で50件の電話をかけることになり、それが彼らの時間入力フォームに記載されている理由を説明します。
ブロッコリーが好きな人もいれば、そうでない人もいます。食べる必要があるかもしれませんが、好きである必要はなく、食べるときに楽しむこともありません。それだけでなく、可能な限り食べないようにするつもりです。
UI以外にも、コーディングするべきものがたくさんあります。いくつかの例を挙げると、Webサービス、Windowsサービス、組み込み（電子レンジのUIはそれほど多くありません）。
それは、場合によっては、UIを描画するのに役立つと明確に考案されたツールが、代わりにストローで死んだ赤ちゃん猿を吸うことが原因である可能性があります。
UI開発には、正しく理解することが難しい特定の事項があります。
レイアウトはその1つです。私は15年以上UIを構築してきましたが、まだレイアウト管理に対する適切なソリューションをまだ持っていません。
もう1つはイベントルーティングです。MVPアーキテクチャやフレームワークで義務付けられているものを使用しても、ほとんどの複雑なUIにはイベントルーティングの問題があると私は主張します。
私はUI開発を嫌いでした。私はそれが非常に退屈で遅く、特にフォームやウィンドウ内に配置するレイアウトコードを書くのが嫌だったのを知っていました。 Visual StudioのフォームデザイナなどのUIデザイナツールを使用すると、ほぼenjoyになります。私が他の人から聞いたそれを嫌う他の理由には、「それは愚かだ」、「常に変化しすぎる」、「それは十分に挑戦的でない」、「それは退屈で退屈な」などです。
なぜすべてのチェスプレーヤーがチェス盤と一緒に遊ぶ駒のデザインを好まないのですか？
一部の人々がそれを嫌うのは奇妙ではありません...あなたが私たちがそうすべきだと期待するのは奇妙です。
以下の理由により、私はUI開発の大ファンではありません。
開発者は、作成する自由が少なくなります。顧客は、UIのすべての小さな側面を確認して意見を得ることができます。次のようなリクエストを受け取ります。これの色を変更します。そのボタンをそこに移動します。気にしないで、元に戻します。バックエンドコードが目に見えることはほとんどありません。
UIは厄介ですが、バックエンドはより「プラトニック」です。バックエンドコードの醜い混乱を見てきましたが、UIコードよりも（コードの観点から）クリーンである方が一般的だと思います。 UIは本当にすっきりした見た目でユーザー向けに適切に設計できますが、私は開発者であり、使用するよりもコードに多くの時間を費やしているため、コードをすっきりさせたいと思っています。
UIはバックエンドよりも「配管」のようなものだと思います。つまり、巧妙なアルゴリズムを使用する機会が減り、脳を限界まで押しやることができます。
一部のUIフレームワークが嫌いなほど、UIの動作が嫌いではありません。例えば。 .NETを10年以上プログラミングしています。 Webアプリケーションを作成するためのフレームワークは優れています（ASP.NET WebFormsおよびASP.NET MVC）。しかし、デスクトップアプリケーションを作成するためのフレームワークは、よくありません（WinFormsとWPF）。
したがって、この点で、GUIアプリケーションを書くことは、私が好きではないフレームワークを使用することのより多くの側面です。
別の側面があります。私はよく「エンタープライズ」スタイルのアプリケーション、つまりデスクトップアプリケーションがサーバーからデータを受信する必要があるアプリケーションを扱います。この場合、ある形式から別の形式へのデータ変換のレイヤーが非常に多いため、非常に退屈です。
例えば。アプリケーションは、一連のDTOオブジェクトを通じて情報を受け取ります。次に、アプリケーションはデータの独自のモデル表現を作成します（サーバーで作成されたものと同じドメインクラスを再利用しません）。モデルクラスは、モデルのプロパティを公開する（WPF MVVMパターンの）ビューモデルによって使用されます。
同じデータが異なるクラスで表現されることはよくあります。そして、それは退屈になります。しかし、これはこのタイプのデスクトップアプリケーションに固有の問題です。
このタイプのアプリケーションには、あるクライアントから変更を取得して別のクライアントですぐに更新する方法など、興味深い課題もあります。
UIの作業が好きです。それはいつも私に当てはまるわけではありませんでしたが、UIの仕事の楽しみは、ここ数年で上達してきたために高まっています。私は一部の開発者がスタイルシートやカラーパレットの近くで許可されるべきではないことを知っています。それは間違いなく別のスキルセットであり、誰もがそれを持っているわけではありません。
正直なところ、最高のGUIツールキットを見つけて実際にその内外を学ぶことは、ちょっとしたPITAだと思います...言うまでもなく、大学でUIに関することをあまり学びませんし、初心者でもないので...... ..
すでに述べられていることを超えて（コード化するのは面倒で退屈で面倒な作業であり、通常、設計は、自分のアイデアがそれらを実装しようとする人にどのような問題を引き起こすかについて何の手掛かりもない人によって前もって行われます）、重要な要素はバックエンドの場合よりもはるかに多く、あなたが何をすべきかについての考えを常に変えている人々と協力しなければなりません。その結果、動くスペックに対してさらに撮影することになり、これらの人々もちらほらする傾向があります。文字通り、ユーザーインターフェイスがテストに失敗しました。テストする人がいるはずの場所からコンポーネントが1ピクセル離れていたためです。うまくいきましたか？はい。よさそうでしたか？はい。しかし、彼はピクセルのカウントを開始し、何かが残りのピクセルと一致しない単一のピクセルだったので、再加工のために送り返しました。
コインの両面、つまりUIデザインとバックエンドコードに取り組んだ結果、コインの両面は基本的に同じものであることがわかりました。
日々の業務とは異なる要件が常に発生するわけではなく、すべてのサービスがCRUDを中心に展開する時代では、退屈になってしまいます。
とにかく、フロントエンドをコーディングすることで、より良い相互作用とクレイジーなダイナミズムが可能になり、基本的にはフロントエンドの設計に未経験の手をねじ込むことになります。私は個人的にフロントエンドで難しい方法を学びました、そしてフロントエンドのデザインははるかに面白くて挑戦的であると楽に言うことができます。
さらにいくつかのポイント：
1）UIデザインはテストが難しくなる可能性があります。そのボタンが本来の目的を果たしているかどうかを確認できますが、使いやすいかどうかをテストすることは困難です。障害のある人でも使えるかどうかテストしてみませんか？
2）多くのプログラマーは訓練を受けておらず、それについてあまり知らない。
実際のところ、多くのUIツール/フレームワーク/ APIは、直感的に理解するには、遠く離れており、複雑で複雑です。 C/C++のWin32 APIで、javax.swing、CSSなどを使って開発しました。それ以来、UI開発をしなければならないのは嫌です... Qtフレームワークまで！
CSの学生として、データ構造、データベース、C++などを教えられます。UIは除きます。それで、あなたは最初からそれが苦手ですになります。苦手な人は嫌いです。
UI（デスクトップではなく、ウェブ）と内部の根性の両方を行います。
私が好きか嫌いかは、ドメイン固有言語（DSL）のようなものを使ってどれだけできるかによって異なります。
UIドメインでは、ユーザーに提示する内容、およびユーザーから取得する情報の複雑さは、フォームデザイナー、多数のイベントハンドラー、MVCなどの典型的なツールを使用しなければならない場合に夢中になります。 、すべての「最先端の」もの。ありがたいことに、何十年も前に、DSLを作成して作業するという、より良い方法だと私が考えたものを発見しました。現在、私はそれを動的ダイアログと呼んでおり、それは Differential Execution と呼ぶ制御構造に基づいています。良いニュースは、特定の機能について、ソースコードがおよそ1桁少ないため、UIに多くの機能を追加できることです。悪い知らせは、私がそれを教えようとしたのと同じくらい、私はテクノロジーを転送する運があまりなかったということです。
UI以外のドメインでは、コマンドラインから使用できるDSLとして始まり、その後UIが移植された多くの製品から教訓を得ました。これにより、エキスパートユーザーはUIをバイパスできるようになり、カジュアルユーザーはカジュアルに使えるようになります。 （例：R、SPlus、Matlab、SAS、WinBugs。）したがって、 当社の製品 には、専門家向けのコマンドライン言語があります。パーサー、コードジェネレーター、プリコンパイラー、ランタイムモデリングエンジンを使用して、そのようなものを開発するのが大好きです。そのために費やされた労力は、UIに費やされた労力よりも少なくとも10のパワーです。
UIの取り組みの理由の1つは、DSLで実行できない「接着剤」がまだたくさんあることです。データグリッドの管理、データの並べ替えのあらゆる種類の方法、あくびの「クラック」に該当するすべてのもの純粋なUIと基礎となる言語の間。
それであなたの質問は「なぜ一部のプログラマーは開発のUI部分を嫌うのですか？」ということでした。私はそれが嫌いなのは、DSLを持っていないその「接着剤」のためです。