Mengapa beberapa programmer membenci bagian UI dari pengembangan? [Tutup]


54

Banyak programmer yang saya temui selalu mengatakan bahwa "Dia bukan orang UI." Faktanya adalah bahwa pengembangan saat ini, apakah web, Windows, Linux, OSX, atau jenis pengembangan lainnya sekarang terdiri dari perangkat lunak dengan UI yang cantik. Mengapa banyak pengembang yang tampaknya tidak suka kerja UI?


54
karena mereka bukan desainer :)
Mahmoud Hossam

17
Pengembangan tidak terdiri dari memiliki UI yang tampan, itu terdiri dari memiliki produk yang dapat dijual . Siapa pun dapat membuat sesuatu terlihat bagus, hanya sedikit yang bisa membuatnya bekerja.
Josh K

58
@JoshK - Poin utama Anda tepat, tetapi saya tidak setuju bahwa "Siapa pun dapat membuat sesuatu terlihat bagus". Kami pengembang jengkel pada orang-orang yang meremehkan profesi kami ("hanya mengetik, seberapa sulit bisa?"), Jadi jangan lakukan hal yang sama pada disiplin ilmu lain.
Steve S

20
Jangan lupa bahwa berpenampilan baik bukanlah hal terpenting tentang UI. Ada banyak UI tampan yang benar-benar canggung untuk digunakan. Saya lebih suka tidak memiliki desain grafis UI, kecuali jika desainer memiliki latar belakang faktor manusia.
David Thornley

17
@Josh K: Setelah membaca "Desain hal sehari-hari" Saya pikir itu sebaliknya. Membuat sesuatu berfungsi adalah bagian yang mudah. Membuatnya berfungsi dengan baik sehingga pengguna secara intuitif akan memahaminya, menyukainya dan ingin menggunakannya lagi jauh lebih sulit.
nikie

Jawaban:


102

Saya bukan orang UI juga. Yah, saya melakukan UI pada proyek saya sendiri, tetapi di tempat kerja saya tidak ada hubungannya dengan itu - pekerjaan saya ada di nyali aplikasi, bukan di ujung depan.

Di luar itu, saya pikir itu lebih dari kebosanan daripada kebencian. Merancang UI adalah bagian yang sulit dan menantang. Implementasi sebagian besar merupakan pekerjaan kasar. Ada sedikit sekali tantangan atau inovasi dalam bagaimana seseorang dapat mengimplementasikan antarmuka pengguna, dan hanya ada begitu banyak kali seseorang dapat menempatkan kotak centang di layar sebelum menjadi sedikit mental. Dan itu bahkan tidak menyentuh menghabiskan jam menyelaraskan piksel "hanya begitu".


63
+1 untuk "menyelaraskan piksel 'hanya begitu'", saya benci itu. Ini 99,99999% sempurna, tetapi pengguna ingin perbatasan di sekitar kotak, yang seharusnya tidak ada di tempat pertama, menjadi lebar 2 piksel, bukan 1, dan warna biru "lebih ringan", tetapi bukan warna cahaya yang Anda punya 2 revisi yang lalu, lebih gelap dari itu. Dan seterusnya, dan seterusnya ... Itulah yang saya alami sekarang. Aplikasi ini bekerja 100%, tapi saya mendapatkan permintaan yang membosankan untuk mengubah casing tooltip ini, dan menghapus periode ... inilah yang menjadi fokus "penguji" saya ... tidak berfungsi sama sekali.
CaffGeek

3
@Robert Harvey, ini adalah perjuangan sehari-hari. Saya berharap kami memiliki satu atau dua orang UI yang berdedikasi di sini ... itu juga akan membantu dalam menyelesaikan ketidakmampuan kami untuk menstandarkan UI kami di seluruh aplikasi utama kami.
CaffGeek

23
+1 untuk mencatat bahwa jauh lebih menarik untuk mendesain GUI daripada membuatnya.
jprete

5
Implementasi seharusnya tidak pernah menjadi pekerjaan kasar. Jika ya, Anda memiliki arsitektur dengan faktor buruk, atau proses yang tidak efisien. Kami adalah programmer, jika kami melakukan sesuatu yang dapat dilakukan mesin, kami harus mengotomatiskannya .
murah hati

10
@ luar biasa Saya pikir otomatisasi adalah tujuan yang hebat, tapi saya belum melihat tata letak UI otomatis yang tidak perlu penyesuaian untuk beradaptasi dengan visi perancang atau preferensi pelanggan. Dan kemudian ada batasan teknis yang sederhana - jika Anda menggunakan WinForms, misalnya, opsi tata-letak otomatis Anda akan terbatas. Aplikasi web lebih baik daripada aplikasi desktop, saya pikir, tetapi kecuali kita secara telepati dapat membuat tata letak UI dan memasang kabelnya, saya pikir masih akan ada cukup banyak pekerjaan membosankan yang terlibat. Saya berharap untuk terbukti salah pada titik ini di masa depan. :)
Adam Lear

55

Membuat UI yang baik melibatkan banyak keterampilan berbeda dari menulis beberapa kode backend.

Persyaratan back-end biasanya dapat ditentukan seperti kotak hitam, x masuk dan diharapkan bahwa Anda harus keluar. Membuatnya berfungsi melibatkan penerapan logika dan Anda dapat menguji secara programatik apakah itu berfungsi atau tidak.

Untuk membuat UI yang baik, Anda perlu mempertimbangkan kegunaan, desain visual, tata letak, dan hal-hal seperti skema warna. Memiliki beberapa kreativitas artistik adalah bonus di sini, dan banyak programmer tidak merasa bahwa mereka memilikinya. Bagi otak logis, solusi untuk masalah UI mungkin tampak subyektif karena tidak ada satu jawaban yang benar atau tidak ada cara mudah untuk memvalidasi bahwa itu dilakukan 'dengan benar'.

Saya pikir banyak programmer yang tidak memiliki banyak pengalaman UI atau belum melakukan banyak penelitian ke dalamnya tidak menyadari bahwa ada aturan dan ilmu di balik kedua desain UI baik dari perspektif kegunaan dan desain (misalnya warna). teori).

Tentu saja, beberapa programmer tidak memiliki masalah dengan aspek ini tetapi membencinya karena banyak UI hanya membosankan untuk kode. Mereka mungkin terdiri dari banyak pekerjaan berulang seperti halaman formulir untuk halaman admin di mana mereka hanya perlu berfungsi dan tidak ada tantangan desain.


3
Menulis kode backend melibatkan banyak keterampilan yang berbeda juga (tidak seperti apa komentar pertama Anda tampaknya menyiratkan), itu hanya serangkaian keterampilan yang berbeda.
Matthieu M.

2
@ Matthieu tidak, dan saya tidak pernah mengatakan tidak. Yang saya maksudkan adalah pengkodean UI melibatkan banyak keterampilan berbeda dari pengkodean back-end. Tolong jangan berpikir saya meremehkan pengkodean back-end, itu yang paling sering saya lakukan untuk hidup :)
Alb

+1: Ini sulit, dan pendekatan normal untuk desain perangkat lunak tidak berfungsi untuk grafik. Jika jelek, tetap jelek.

18

Orang hanya punya minat berbeda. Beberapa programmer lebih tertarik pada struktur data dan algoritma, beberapa dalam arsitektur, beberapa dalam kegunaan dan desain UI - atau kombinasi dari mereka dan niche lainnya. Mereka masing-masing membutuhkan keterampilan dan cara berpikir yang berbeda tentang suatu masalah. Jika Anda suka mur dan baut pemrograman tingkat rendah, mungkin Anda tidak terlalu peduli tentang apa yang dipikirkan pengguna, atau sebaliknya.

Secara pribadi, saya jatuh ke dalam kamp yang terakhir - saya lebih suka merancang UI daripada algoritma yang kompleks. Hanya hal yang menurut saya menarik.


15

Apakah desain UI yang diberikan baik atau buruk cukup subyektif , yang menurut saya programmer secara umum tidak menarik. Upaya beberapa dekade untuk mengkuantifikasi dan mengkualifikasi teknik UI yang baik telah membantu menciptakan beberapa aturan luas yang bisa diterapkan, tetapi lebih sering untuk tidak benar-benar menentukan apakah UI yang baik memerlukan banyak pengujian A / B dan pengamatan pengguna lainnya. teknik.

Walaupun pasti ada subjektivitas dalam pemrograman, umumnya Anda dapat menunjuk ke beberapa bentuk alasan obyektif mengapa satu pilihan lebih baik daripada yang lain: kecepatan eksekusi, persyaratan memori, fleksibilitas untuk memenuhi kemungkinan kebutuhan di masa depan, praktik yang telah terbukti terbukti lebih efektif dalam masa lalu, dll. Mempertahankan pilihan UI yang diberikan - dan karenanya bahkan membuat pilihan itu sendiri - umumnya menurunkan ke "I like it," yang merupakan argumen yang sepenuhnya berbeda untuk didukung.


2
tepat, "subyektif" itu mengganggu. Bawa dua orang ke sana dan mereka memiliki pendapat yang sangat berbeda tentang apa itu UI yang baik. Anda tidak dapat menguji unit aspek GUI (tidak juga). dll ...
Matthieu M.

13

Saya pribadi tidak menikmati pengembangan UI karena saya tidak pandai dalam hal itu. Ada elemen besar psikologi pengguna yang saya tidak pahami dengan baik. Saya pikir masalah terbesar saya adalah bahwa saya tidak bisa menempatkan diri pada posisi pengguna. Saya tidak tahu cara membuat tata letak intuitif sebagian besar karena saya tidak tahu apa yang intuitif bagi pengguna, saya juga tidak tahu cara membuat segala sesuatu terlihat cantik.

Saya tidak perlu berpikir beberapa programmer benci mendesain UI sebanyak mereka benci melakukan hal-hal yang tidak mereka kuasai. Kebetulan ada banyak pengembang yang tidak pandai pengembangan UI.


+1 - "Programer benci melakukan hal-hal yang tidak mereka kuasai." Benar sekali. Ketika Anda melakukannya pada proyek pribadi, itu adalah latihan dan bisa menyenangkan, tetapi ketika Anda melakukannya untuk pekerjaan Anda - itu adalah kinerja, dan jika Anda tidak memiliki keterampilan, itu hanya membuat stres.
lunchmeat317

11

Masalah dengan desain UI adalah setiap orang memiliki pendapat ... Dan tidak ada jawaban benar atau salah. Pengembang di sisi lain suka hitam & putih dan logika. Dalam perusahaan ukuran apa pun, semua orang akan setuju 1+1=2, tetapi tanyakan font mana yang membuatnya paling mudah dibaca (Comic Sans Obviously)... bersiap-siaplah menghadapi banjir. Sepuluh ribu jawaban berbeda dan setiap orang benar, karena setiap orang berbeda.


6
Ya Tuhan, Komik Sans ...
Maks.

+1 untuk logika hitam putih. Saya benar-benar benci membuat keputusan tentang hal-hal yang tidak memiliki jawaban benar atau salah (merancang UI, memutuskan tempat tinggal, makan apa untuk makan malam, dll. Lol).
Dan

7

Sebagai seorang pengembang yang benar-benar menikmati bekerja di UI (khususnya, saya telah melakukan bagian yang adil dari desain web), saya menghargai ketika seseorang yang tidak memiliki keahlian tetap tidak menggunakannya.

Berkembang membutuhkan kemampuan untuk menyimpan banyak data dalam pikiran Anda, dan menangani banyak sekaligus. Desain UI membutuhkan kemampuan untuk mendidihkannya seminimal mungkin, tanpa mengorbankan integritasnya. Saya suka tantangan itu; dan saya merasa ngeri ketika saya melihat seseorang membuat UI yang merupakan data dinding yang tidak dapat dikelola di layar. (Saya juga geek total dalam hal tata letak, teori warna, dll.)

Di sisi lain, aku benci barang level rendah. Saya tidak akan pernah menyentuh kode untuk driver, kernel, atau hal lain seperti itu: shudder: Saya akan menyerahkannya kepada "orang-orang non-UI", dan saya senang orang lain senang melakukannya, atau itu tidak akan pernah selesai.


6

Saya pikir itu tergantung sebagian besar programmer menggunakan bagian kiri otak mereka.

Sumber yang bagus untuk membaca lebih lanjut tentang hal ini.

masukkan deskripsi gambar di sini


6
Anda mungkin menikmati buku, Pragmatis Berpikir dan Belajar: Refactor Your Wetware , ini memberikan cara baru untuk berpikir tentang perbedaan otak kiri / kanan. Bahkan, itu menamai mereka Linear-mode dan Rich-mode, dan benar-benar hebat dibaca.
CaffGeek

@Chad, terima kasih, Chad! Saya akan mempertimbangkannya!
Amir Rezaei

+1 untuk mengangkat ini. Dev aplikasi Backend sangat analitis sedangkan pekerjaan frontend jauh lebih kreatif. Beberapa orang menyukai keduanya, tetapi banyak yang suka menempel pada ceruk masing-masing.
bunglestink

Hanya sedikit info tambahan bagi mereka yang mungkin tertarik: sebenarnya tidak 100% jelas belahan mana yang memainkan peran lebih besar dalam menentukan kemampuan matematika .
Dan Tao

Saya tidak setuju bahwa "musik" berada di bawah fungsi otak kanan, terutama karena itu dikelompokkan dengan "seni". Musik sangat matematis dan logis, sedangkan seni adalah kebalikan total (mungkin dengan pengecualian seni pixel, di mana keterbatasan teknis memperkenalkan kembali logika untuk "seni").
Dan

6

Pengembangan UI menjadi kompleks karena Anda mendapatkan terlalu banyak masukan dari orang yang salah. Mereka semua ahli desain grafis. Mereka tidak ada tempat untuk ditemukan ketika Anda ingin tahu formula untuk sesuatu.

Mereka tidak tahu apa yang mereka inginkan tetapi mengetahuinya ketika mereka melihatnya, tidak memiliki selera, dan mereka yang memiliki kekuatan keputusan tidak akan menggunakan aplikasi itu tetapi yakin itu harus berwarna hijau. Anda mengikuti panduan untuk UI yang bagus seperti membatasi jumlah bidang pada formulir dan Anda mendapatkan permintaan untuk menambahkan 50 bidang lainnya karena mereka 'membutuhkan' semuanya dan menempatkannya di tab terpisah terlalu sulit. Anda tahu, sama seperti Excel. Petani!

Anda tidak bisa mengada-ada. Saya duduk dalam sebuah pertemuan di mana dua orang teratas di departemen akuntansi (gaji sekitar 500 ribu / tahun) untuk sebuah firma hukum besar menghabiskan setengah jam berdebat tentang label pada halaman situs web penagihan yang digunakan oleh para pengacara. Ini seharusnya memudahkan para pengacara untuk memahaminya. Mengapa tidak bertanya kepada pengacara saja? Terlalu mudah. Jadi departemen TI dapat menjawab 50 panggilan telepon dari pengacara yang ingin tahu WTF "Jumlah Tagihan Net Residual" dan mengapa itu ada pada formulir entri waktu mereka.


5

Beberapa orang menyukai brokoli, beberapa tidak. Kita mungkin harus memakannya, tetapi kita tidak harus menyukainya dan kita tidak akan menikmatinya ketika kita memakannya. Tidak hanya itu, kita akan menghindari makan sebanyak yang kita bisa.

Ada BANYAK hal lain untuk dikodekan dari sekedar UI. Layanan Web, Layanan Windows, tertanam (tidak banyak UI pada microwave), hanya untuk menyebutkan beberapa contoh.


9
UI biasanya mendapat sedikit perhatian pada microwave, itulah sebabnya kebanyakan dari mereka menghisap.
Robert Harvey

4
Masalah dengan microwave adalah, ketika Anda memiliki yang bagus, dengan UI yang bagus, di mana Anda tidak memerlukan urutan yang sangat spesifik untuk tombol-tombol untuk menyelesaikan tugas, Anda bahkan tidak memikirkannya. Tetapi ketika Anda membeli microwave murah untuk ruang bawah tanah, atau apa pun, Anda segera melihat betapa mengerikan UI di atasnya. Anda harus mengingat perintah menekan tombol dengan tepat. Apakah saya memilih level daya sebelum waktu? Atau setelah? Apakah saya harus menekan waktu memasak terlebih dahulu? dll, dll ... Dan ketika Anda perlu membaca instruksi yang tersembunyi di dalam ?! UGH! UI yang baik harus "tidak terlihat" oleh pengguna.
CaffGeek

Metafora yang mengerikan. Saya suka brokoli tapi benci mendesain UI. ;)
Dan

4

Itu mungkin karena - dalam beberapa kasus - alat yang secara jelas dirancang untuk membantu Anda menggambar UI mengisap monyet bayi mati melalui sedotan sebagai gantinya.


4

Ada hal-hal tertentu dalam pengembangan UI yang sulit untuk diperbaiki.

Layout adalah salah satunya. Saya telah membangun UI selama lebih dari 15 tahun dan masih belum merupakan solusi yang layak untuk manajemen tata letak.

Lain adalah acara routing - bahkan dengan arsitektur MVP dan hal-hal yang diamanatkan oleh kerangka kerja, saya berpendapat bahwa sebagian besar UI yang kompleks memiliki masalah routing acara - yang mungkin ditemukan jika ada kerangka kerja pengujian yang bisa mengatasinya dengan baik.


3

Saya tahu bahwa bagi saya, saya dulu benci UI dev karena saya merasa sangat membosankan dan lambat, terutama menulis kode tata letak untuk memposisikan sesuatu dalam bentuk atau winow. Sekarang dengan alat perancang UI seperti Forms Designer di Visual Studio, saya hampir menikmatinya . Alasan lain untuk membencinya Saya pernah mendengar dari orang lain termasuk "itu bodoh", "selalu berubah terlalu banyak", "itu tidak cukup menantang", "itu membosankan / membosankan".


4
Bagaimana Anda menjawab kuadrat dengan nama pengguna Anda? :)
Robert Harvey

@Robert Harvey: Cukup adil! Forms Designer bagus, tetapi ketika Anda mulai menyukai wadah UI generik, ia mulai tersedak. Atau setidaknya VS2008 melakukannya. Belum mencoba 2010, tapi saya curiga mungkin ada masalah serupa? Apa pun masalahnya, akhirnya diselesaikan (Lihat posting pertama saya di SO). Ada hal-hal lain yang juga mencekiknya, tetapi itu menghilangkan cukup dari kebosanan yang biasanya saya sekarang nikmati desain / pengembangan UI.
FrustratedWithFormsDesigner

3

Mengapa tidak semua pemain catur suka merancang papan catur dan potongan-potongan yang mereka mainkan?

Itu tidak aneh bahwa beberapa orang tidak suka itu ... itu aneh kamu mengharapkan kita harus.


1
pemain catur tidak mendesain papan catur dan barang-barang karena desain tersebut telah lebih dari seabad telah distandarisasi oleh federasi catur internasional (FIDE) dan standar-standar tersebut telah diadopsi secara universal.
jwenting

2

Saya suka bekerja di UI. Itu tidak selalu benar bagi saya, tetapi kesenangan saya pada pekerjaan UI telah meningkat karena saya menjadi lebih baik dalam beberapa tahun terakhir. Saya tahu beberapa pengembang tidak boleh berada di dekat stylesheet, atau palet warna. Ini jelas merupakan keahlian berbeda, dan tidak semua orang memilikinya.


2

Saya tidak terlalu membenci pekerjaan UI seperti saya membenci beberapa kerangka kerja UI. Misalnya saya sudah memprogram .NET selama> 10 tahun. Kerangka kerja untuk membuat aplikasi web sangat bagus (ASP.NET WebForms dan ASP.NET MVC). Tetapi kerangka kerja untuk menulis aplikasi desktop, baik, saya tidak menyukai mereka (WinForms dan WPF).

Jadi dalam hal ini, menulis aplikasi GUI lebih merupakan aspek menggunakan kerangka kerja yang saya tidak suka.

Ada aspek lain. Saya sering bekerja dengan aplikasi "enterprise" -style, yaitu aplikasi yang membutuhkan aplikasi desktop untuk menerima data dari server. Dalam hal ini, ada begitu banyak lapisan konversi data dari satu format ke format lainnya sehingga menjadi sangat membosankan.

Misalnya aplikasi menerima informasi melalui serangkaian objek DTO. Aplikasi kemudian membuat model representasi data sendiri (tidak menggunakan kembali kelas domain yang sama yang dibuat di server). Kelas model dikonsumsi oleh model tampilan (dalam pola WPF MVVM), yang memaparkan properti pada model.

Itu adalah banyak kali bahwa data yang sama diwakili oleh kelas yang berbeda. Dan itu membosankan. Tapi ini masalah khusus untuk jenis aplikasi desktop ini.

Ada juga tantangan menarik dalam jenis aplikasi ini, seperti bagaimana kita mendapatkan perubahan dari satu klien untuk segera memperbarui pada klien lain.


++ Saya tahu apa yang Anda maksud. Untuk poin terakhir tentang menyebarkan pembaruan antar klien, saya menggunakan polling (biasanya 1 detik), tetapi itu mungkin hanya berfungsi untuk DB yang cukup kecil dan sejumlah kecil klien.
Mike Dunlavey

2

Saya bukan penggemar berat pengembangan UI karena alasan ini:

  1. Sebagai pengembang, Anda memiliki lebih sedikit kebebasan untuk membuat: Pelanggan dapat melihat dan memiliki pendapat tentang setiap segi kecil dari UI, yang harus Anda bereaksi. Anda akan mendapatkan permintaan seperti: ubah warna ini; pindahkan tombol itu ke sana; Sudahlah, pindahkan kembali. Kode back-end jarang terlihat.

  2. UI berantakan, sedangkan bagian belakang lebih "platonis." Sementara saya telah melihat kekacauan kode back-end yang jelek, saya pikir itu lebih umum untuk itu menjadi bersih (dari perspektif kode) daripada kode UI. UI dapat benar-benar terlihat bersih dan dirancang dengan baik untuk pengguna, tetapi karena saya seorang pengembang dan menghabiskan lebih banyak waktu dalam kode daripada menggunakannya, saya lebih suka membersihkan kode.

  3. Saya merasa bahwa UI lebih merupakan "plumbing" daripada back-end, yaitu ada lebih sedikit peluang untuk algoritma pintar dan benar-benar mendorong otak Anda hingga batasnya.


1

Saya melakukan UI (desktop, bukan web) dan nyali internal.

Jumlah yang saya suka atau tidak suka tergantung pada seberapa banyak saya bisa selesai menggunakan sesuatu seperti domain-specific-language (DSL).

Dalam domain UI, apa yang saya sajikan kepada pengguna, dan kompleksitas informasi yang saya dapatkan dari mereka, sedemikian rupa sehingga saya akan menjadi gila jika saya harus menggunakan alat khas, seperti desainer formulir, banyak penangan acara, MVC , semua yang "canggih". Untungnya, beberapa dekade yang lalu saya menemukan apa yang saya pikir merupakan cara yang lebih baik, yaitu membuat DSL untuk itu, dan bekerja di sana. Saat ini saya menyebutnya Dialog Dinamis, dan didasarkan pada struktur kontrol yang saya sebut Eksekusi Diferensial . Berita baiknya adalah, untuk fungsionalitas yang diberikan, kode sumber kira-kira kurang lebih besar, memungkinkan saya untuk menempatkan lebih banyak fungsionalitas ke dalam UI. Berita buruknya adalah, sebanyak yang saya coba ajarkan, saya belum beruntung mentransfer teknologi.

Dalam domain non-UI, saya mengambil pelajaran dari sejumlah produk yang dimulai sebagai DSL yang dapat digunakan dari baris perintah, di mana UI kemudian dicangkokkan. Itu memberi pengguna ahli sesuatu di mana mereka dapat memotong UI, sementara memberikan pengguna biasa sesuatu yang bisa mereka gunakan dengan santai. (Contoh: R, SPlus, Matlab, SAS, WinBugs.) Jadi produk kami memiliki bahasa baris perintah untuk para ahli. Saya suka mengembangkan hal-hal seperti itu, dengan parser, generator kode, precompiler, dan mesin pemodelan run-time. Upaya yang dihabiskan untuk itu setidaknya kekuatan 10 kurang dari upaya yang dihabiskan di UI.

Salah satu alasan upaya UI begitu banyak adalah masih ada banyak "lem" yang tidak dapat dilakukan dengan DSL - mengelola data grid, semua jenis cara menyortir data, semua hal yang termasuk dalam "celah" menguap antara UI murni dan bahasa yang mendasarinya.

Jadi pertanyaan Anda adalah "Mengapa beberapa programmer membenci bagian pengembangan UI?". Saya hanya membencinya karena "lem" yang saya tidak punya DSL.


1

Jujur saya menemukan bahwa menemukan toolkit GUI terbaik kemudian benar-benar mempelajari seluk beluk yang agak PITA ... belum lagi Anda tidak belajar banyak hal UI di perguruan tinggi dan saya seorang pemula jadi ...... ya ..


1

Di luar apa yang telah dinyatakan (pekerjaan yang membosankan, membosankan, membuat frustasi untuk mengodekannya dan desain biasanya dilakukan di depan oleh seseorang yang tidak memiliki petunjuk tentang masalah apa yang ditimbulkan oleh ide-idenya bagi mereka yang mencoba mengimplementasikannya), faktor penting adalah Anda Harus bekerja dengan orang-orang yang ide-idenya tentang apa yang harus Anda lakukan membuat perubahan terus-menerus, jauh lebih daripada yang mereka lakukan untuk backend. Sebagai hasilnya, Anda menembak lebih dari spec bergerak, dan orang-orang ini cenderung menjadi nitpicker juga. Saya sudah benar-benar memiliki antarmuka pengguna gagal tes karena komponen 1 pixel dari lokasi orang yang mengira itu seharusnya. Apa itu bekerja? Iya. Apakah itu terlihat bagus? Iya. Tetapi dia mulai menghitung piksel dan ada sesuatu piksel yang tidak sesuai dengan yang lainnya, jadi dia mengirimnya kembali untuk pengerjaan ulang.


1

Beberapa poin lagi:

1) Desain UI bisa lebih sulit untuk diuji, pasti Anda dapat memeriksa apakah tombol itu melakukan apa yang seharusnya, tetapi menguji apakah mudah digunakan yang lebih sulit. Bagaimana dengan pengujian apakah itu akan dapat digunakan dengan seseorang dengan disabilitas?

2) Banyak programmer tidak terlatih tentang hal itu, dan tidak tahu banyak tentang hal itu.


1

Faktanya adalah banyak alat / kerangka / API UI yang buruk, kompleks, jauh untuk menjadi intuitif. Saya mengembangkan dengan Win32 API di C / C ++, dengan javax.swing, CSS, dll. Karena itu, saya benci harus berurusan dengan pengembangan UI ... Sampai kerangka Qt!


1
Maksud Anda, Anda kehabisan alat yang tidak lagi umum digunakan (kebanyakan orang tidak akan menggunakan Win32 untuk pemrograman UI hari ini)? Maaf, saya hanya menganggap ini bukan poin yang valid.
user16764

1

Sebagai siswa CS Anda akan diajarkan struktur data, database, C ++ ... kecuali UI. Jadi Anda tidak akan pandai sejak awal . Jika Anda tidak pandai, Anda akan membencinya.


Banyak universitas dan perguruan tinggi menawarkan kursus desain UX. Seringkali sebagai bagian dari kurikulum CS mereka.
user16764

1

Setelah bekerja di kedua sisi koin yaitu desain UI dan kode backend, saya menemukan bahwa kedua sisi koin pada dasarnya adalah hal yang sama.

Persyaratan yang berbeda dari apa yang Anda lakukan sehari-hari tidak datang sepanjang waktu dan sekarang di era di mana semua layanan berputar di sekitar CRUD maka itu menjadi membosankan.

Bagaimanapun, pengkodean frontend memungkinkan interaksi yang lebih baik dan dinamika gila yang pada dasarnya mengacaukan desain frontend yang tidak berpengalaman. Saya pribadi belajar cara yang sulit di frontend dan dapat dengan nyaman mengatakan bahwa mendesain frontend jauh lebih menarik dan menantang.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.