ASP.NET Webforms pengembang dan desainer web: bagaimana cara berinteraksi?


17

Saya seorang pengembang ASP.NET Webforms, dan saya menghadapi beberapa masalah ketika saya berurusan dengan desainer.

Desainer selalu mengeluh tentang asp.net server controls. Mereka lebih suka hanya memiliki file html dan membuat cssfile bersama dengan gambar yang diperlukan untuk pergi dengan itu. Kadang-kadang, jika fase desain dilakukan di muka, saya mendapatkan file html dengan file css terkait, tetapi kemudian kita menghadapi banyak masalah mengintegrasikan desain dengan aspxfile (memutuskan kontrol kontrol telerik ... dll).

Yang ingin saya tanyakan adalah:

  • Bagaimana cara mengatasi masalah ini? Para desainer lebih memilih pengembang php dan mvc karena masalah dengan kontrol server .net. Saya perlu tahu bagaimana berinteraksi dengan para desainer dengan cara yang benar.
  • Apakah ada alat atau aplikasi untuk memberikan kepada para desainer render (halaman html) dari halaman .aspx? Maksud saya halaman di runtime daripada aspx di Visual Studio. Mereka memang menggunakan Ekspresi Web tetapi mereka menginginkan halaman yang dirender dalam html juga.

5
Kelelawar Selangkangan Nerf.
Joel Etherton

3
Adakah alat untuk menyediakan halaman html runtime yang diberikan? Server web harus bekerja untuk itu.
psr

6
inilah sebabnya saya tidak akan pernah menggunakan kontrol server APT.NET, jika saya harus menggunakan ASP.NET, saya akan menggunakan APT.NET MVC.
ryanzec

3
@ryanzec tepatnya. Tampilan silet sangat bagus untuk ini juga, hanya arahan dinamis kecil dan sisanya adalah HTML lurus. Pengembang merasa mudah untuk berkembang melawan dan menggunakan, Desainer menyukainya karena itu hampir HTML murni
Earlz

3
@Ryathal - menunjukkan kepada mereka file Skin akan membuat mereka berjalan menuju pintu. Tema dan Skin sama sekali tidak berguna bagi sebagian besar desainer front-end. Mereka adalah .NET abstraksi gaya (kebanyakan) yang tidak alami bagi perancang web.
Graham

Jawaban:


29

Mantan Desainer di sini, berubah jadi Dev, dan saya juga sering mengencingi tentang Kontrol Web. Jujur saja, JAUH yang lebih murah bagi perancang untuk menyesuaikan praktik mereka daripada bagi Pengembang .NET untuk menyelidiki penerapan kustomisasi GridView karena perancang itu BERKATA bahwa setiap TD memiliki tag 'rel' (atau apa pun).

Seperti Arseni Mourzenko tunjukkan dengan sangat bijak, keputusan untuk menggunakan Webforms adalah pilihan perusahaan yang membatasi sebagian kendali atas HTML sambil memberikan beberapa efisiensi dalam pengkodean. Kecuali jika perusahaan mau mempertimbangkan kembali (yang seharusnya TIDAK mereka lakukan hanya untuk menyenangkan para desainer), maka para desainer perlu menerima kenyataan ini. Berikut beberapa hal yang dapat mereka lakukan:

1) Berhenti tergantung pada ID untuk apa pun . Meskipun ini terasa salah pada awalnya, saya menemukan bahwa hidup sebenarnya jauh lebih mudah ketika saya menata segala sesuatu dengan kelas (dan warisan, tentu saja). Pertama-tama, itu menyamakan semua bobot pemilih saya. Dalam pewarisan CSS, ID mengalahkan CLASS. Sebenarnya agak menyenangkan jika semuanya menjadi anak dan / atau pemilih kelas, dan membuat urutan spesifisitas menjadi sedikit lebih sederhana. Hal yang sama di lapisan JS, itu memberi saya NOL kesakitan untuk menukar pemilih berbasis ID saya untuk yang berbasis kelas.

2) Ajari mereka bagaimana RadioButtonLists dan CheckboxLists dikonversi , bersama dengan Label = span, Panel = div dan hal-hal kontrol-ke-html lainnya yang tidak jelas. Cara .NET merender ini ke HTML sedikit lebih aneh dari yang saya harapkan, dan itu jauh lebih mudah bagi saya untuk membuat layar ketika saya tahu bagaimana HTML akan keluar dari kontrol itu.

3) Minta mereka mengerjakan desainer mereka DI ASPX LANGSUNG , bukan HTML mentah ( ! Penting ). Ajari para desainer dasar-dasar GridViews, ListViews, dll. Berikan mereka beberapa cuplikan kode untuk mendorong koleksi objek anonim ke dalam kontrol Grid / ListView. Jika mereka dapat belajar CSS maka mereka dapat belajar menyalin-tempelkan kode ini. Mereka dapat menggunakan versi gratis VS Web Express, yang cukup bagus untuk pekerjaan CSS & JS sekarang. Proyek web tiruan ini akan memberi para desainer kesempatan untuk memasukkan beberapa kontrol, lalu Lihat Sumber untuk melihat bagaimana mereka ditampilkan.

4) Jelaskan bagaimana tag FORM digunakan dalam .NET . Lupa tentang ini sebelumnya, tetapi hal lain yang harus terbiasa oleh perancang adalah bahwa biasanya, satu tag FORMULIR membungkus seluruh halaman. Ini mengubah cara kontrol bentuk berperilaku, dan Anda tidak dapat membuat tag FORMULIR tanpa efek samping yang benar-benar aneh. Pastikan para desainer memahami hal ini atau bentuk HTML mereka akan menjadi mimpi buruk untuk dibuat menjadi WebForms.

5) Tinggal jauh dari Tema dan Kulit . Meskipun .NET framework memiliki alat-alat ini untuk membantu kontrol gaya di seluruh aplikasi, mereka kikuk dan aneh bagi Desainer Web biasa, dan saya tidak pernah menganggapnya sepadan dengan waktu saya. Mereka tampak seperti alat yang bagus untuk pengembang yang tidak berpengalaman dalam CSS, tetapi hanya akan memperlambat desainer. Biarkan para desainer bekerja di lingkungan alami mereka (file html & css) dan mereka akan lebih bahagia dan lebih produktif.

6) Simpan proyek "prototipe" di solusi situs Anda . Untuk memastikan para pengembang selalu memiliki target untuk dikodekan, mintalah desainer membuat proyek web palsu dalam solusi nyata Anda untuk menjaga halaman ASPX-only mereka tetap dan tidak tersentuh oleh pengembang nyata. Ini berarti para desainer dapat melihat kembali prototipe mereka dalam solusi yang sama dengan proyek nyata untuk memeriksa bagaimana pengembang melakukannya, dan para pengembang dapat menjalankan prototipe kapan saja untuk memastikan pekerjaan mereka sesuai dengan maksud desainer.

Terakhir, tahan segala keluhan untuk dikonversi ke MVC, kecuali jika Anda siap untuk melatih kembali Devs Anda. Saya suka MVC secara pribadi, tetapi jika Anda memiliki tim dengan banyak pengetahuan WebForms, jangan membuangnya tanpa alasan. Jika aplikasi Anda mengalami masalah kondisi tampilan, masalah SEO, atau masalah aksesibilitas, maka benar-benar memberikan MVC tampilan yang sulit. Tetapi akan membutuhkan BANYAK lebih banyak waktu untuk melatih para pengembang WebForms di MVC daripada melatih para Desainer bagaimana menggunakan Kontrol Web.

Pada akhir hari, tidak ada DESAIN I CAME ACROSS, yang secara pribadi saya tidak bisa bekerja di WebForms, bahkan jika saya akhirnya bersumpah di GridView sialan itu selama satu jam sebelum mengetahuinya.

Apakah ada alat atau aplikasi untuk memberikan kepada para desainer render (halaman html) dari halaman .aspx?

Lupa Ekspresi (saya tidak pernah menyukainya). Dapatkan mereka versi gratis Visual Studio (Web Developer Express). Itu dapat menghubungkan ke solusi kontrol sumber apa pun yang Anda miliki, dan itu akan membiarkan para desainer menjalankan halaman ASPX mereka dan melihat HTML yang diberikan di browser. Tooling CSS dan JS jauh lebih baik daripada sebelumnya, dan ada beberapa alat yang luar biasa yang dimasukkan ke dalam perluasan seperti Web Essentials. Transformasi aturan CSS 1-klik menjadi semua penyimpangan khusus vendor, pemilih warna, dan palet tepat di antarmuka VS, penyisipan gambar 1-klik ke file css, transformasi CSS 'KURANG' (Anda dapat 'kode' dalam CSS), F12 'Navigasi Ke' di JavaScript, plus kecerdasan nyata, dan banyak lagi. Ini adalah harta karun bagi para desainer sekarang, FYI,


3
Baris terakhir Anda ... Jadi solusi jangka panjang adalah hanya menderita dan beradaptasi, daripada menyelesaikan akar permasalahan? (di mana akar penyebabnya memperlakukan aplikasi web seperti itu adalah aplikasi desktop)
Earlz

3
@Earlz - Masuk akal jika Anda memiliki staf karyawan pengembangan yang tidak memiliki bandwidth untuk mengambil paradigma baru (MVC) hanya karena 1-2 karyawan desainer lainnya tidak ingin beradaptasi dengan WebForms. Saya bilang, BUKAN itu sulit bagi seorang desainer untuk beradaptasi dengan WebForms, jika mereka mau melepaskan beberapa hal (ID vs semantik kelas, kontrol yang tepat atas label label, dll). Lihat, saya sendiri adalah desainer yang mengeluh tentang .NET markup terus-menerus sampai saya menyadari bahwa (kecuali Anda berada dalam permainan SEO) sumber html BENAR-BENAR TIDAK MASALAH. Maaf, tapi itu benar.
Graham

1
@ Elarlz: penyebab utamanya adalah desainer tidak bisa benar-benar bekerja di media. Melengkapi mereka untuk bekerja dalam medium mungkin merupakan solusi paling sukses di luar sana dalam jangka panjang.
Wyatt Barnett

3
Belum lagi fakta bahwa Desainer kadang-kadang biaya kurang per jam dari pengembang sehingga Desainer di $ 30ph akan lebih baik mengubah sesuatu daripada pengembang di $ 60ph mengubah sesuatu karena desainer adalah pusing tentang hal itu.
TheMonkeyMan

Hadiah 1 saya menang, woot!
Graham

8

Ada solusi untuk masalah Anda tetapi melibatkan perubahan pola desain ke MVP . Ini adalah investasi waktu di muka yang perlu pertimbangan serius sebelum memulai.

Pada dasarnya, masalah yang Anda alami bukanlah hal baru. Singkatnya, Anda perlu memperkenalkan abstraksi tampilan melalui antarmuka yang mengidentifikasi model data yang didukung tampilan.

Ini adalah topik yang sangat komprehensif yang masuk akal untuk melihat pola sebagai contoh kehidupan. Anda akan menemukan contoh ini cukup informatif untuk kasus Anda - Formulir Web yang Lebih Baik dengan Pola MVP .

Sunting: Jika saran di atas terlalu mahal (dalam hal waktu dan sumber daya) untuk diikuti, saya pasti akan menyarankan untuk bekerja dengan desainer Anda lebih dekat . Saya percaya bahwa mengomunikasikan masalah Anda dalam tim harus sangat membantu untuk menyelesaikan hambatan dalam pekerjaan (perancang dan pengembang) Anda. Ini adalah kerja tim dan kolaborasi masalah yang baik untuk menghilangkan semua hambatan untuk melakukan pekerjaan adalah cara untuk berhasil dalam proyek sebagai tim ! Ini adalah sesuatu yang kami lakukan dalam proyek kami.


1
+1: Ini adalah solusi yang layak mengingat kendala masalah (ASP.NET Webforms), tetapi seperti yang Anda tunjukkan, ini bisa sangat mahal karena membutuhkan banyak disiplin dan waktu (yang menyiratkan uang). Saya berpendapat bahwa jika OP tertarik pada solusi all-inclusive, maka ia harus mempertimbangkan beralih ke ASP.NET MVC (bukan Webforms MVP). OP akan menuai banyak manfaat lain seperti TTM dan retensi pengembang selain komunikasi yang lebih baik dengan perancang.
Jim G.

6

ASP.NET adalah suatu kerangka kerja, yang abstrak dari kode HTML yang dihasilkan. Ini artinya Anda tidak dapat diminta untuk mereproduksi kode HTML yang diberikan dalam aplikasi ASP.NET, kecuali Anda memiliki cukup anggaran untuk menulis ulang apa pun yang dihasilkan oleh kontrol ASP.NET .

Terserah pemangku kepentingan untuk memutuskan: apakah Anda menggunakan kontrol ASP.NET dengan kelebihan dan kekurangan mereka, atau Anda beralih ke HTML manual (atau ke ASP.NET MVC), meningkatkan biaya proyek saat ini dengan ribuan dolar .

Ketidakmampuan untuk mengkustomisasi HTML dalam konteks ini merupakan kendala seperti yang lain. Desainer harus mempertimbangkan kendala teknis ini dalam pekerjaan mereka. Kasingnya sangat mirip dengan jika perancang akan memberi tahu Anda bahwa teks harus ditampilkan dalam font yang tepat dengan ukuran yang tepat: itu adalah dukungan web, bukan cetak, yang berarti bahwa ukuran teks akan bervariasi.

Adapun alat-alatnya, saya tidak mengetahui alat-alat yang akan mengubah HTML biasa menjadi templat ASP.NET. Bagaimana mungkin menebak bahwa tabel tertentu harus dikonversi ke kontrol ASP.NET tertentu?


1
+1 untuk menunjukkan itu tergantung pada pemangku kepentingan untuk memutuskan. Setelah penandatangan cek gaji mengambil keputusan, semua orang harus sejalan dengannya.

Saya tidak akan mengatakan ini terlalu keras, tapi saya pikir kerangka kerja lain lebih fleksibel. Menurut pendapat saya ketidakmampuan untuk (dengan mudah) menyesuaikan HTML adalah alasan yang cukup untuk mulai berpikir tentang pindah ke kerangka kerja lain (seperti rel).
ostroon

6

Pada pekerjaan terakhir saya, para devs akan membangun aplikasi dan kemudian akan memberikannya kepada para desainer sehingga mereka dapat membuatnya tampak seperti sekelompok programmer perangkat lunak tidak membuatnya. :)

Ketika kami pertama kali memulai proses ini, ada banyak bolak-balik antara devs dan desainer. Mereka tidak mengerti halaman yang diberikan kepada mereka. Surga melarang jika kita membangun halaman secara dinamis! Itu hampir sama dengan situasi yang Anda gambarkan di sini.

Saya duduk dengan masing-masing desainer dan mengajari mereka cara menginstal aplikasi web pada kotak lokal mereka. Saya menunjukkan kepada mereka bagaimana menjalankannya dan segalanya. Saya menjelaskan bagaimana kontrol asp ditampilkan di layar. Dan kemudian kami membukanya di browser dan menggunakan pembakar untuk melihat tautan antara kontrol asp dan apa yang dirender.

Ini sangat membantu mereka. Begitu mereka bisa melihatnya dan menjalankannya di kotak mereka dan menggunakan alat desain mereka untuk mengubah dan bermain dengan gaya, itu membuat hidup mereka lebih mudah.

Setelah saya melakukan ini, saya mengadakan pertemuan dengan para pengembang dan memberi tahu mereka bahwa mereka harus menggunakan tag CssClass dan memastikan bahwa gaya telah ditentukan. Dan apa pun yang diletakkan di layar secara dinamis perlu memiliki kelas css yang melekat padanya, tetapi para desainer tidak akan dapat menambahkannya.

Itu adalah sebuah proses. Butuh waktu bagi kedua belah pihak untuk terbiasa dengan pengaturan. Tapi itu membuka jalur komunikasi. Alih-alih mengeluh tentang kontrol yang digunakan, para desainer dapat meminta gaya ditambahkan ke berbagai elemen.

Jadi saran saya adalah untuk duduk bersama para desainer dan menunjukkan kepada mereka bagaimana halaman dibuat. Gunakan pembakar untuk membedah halaman dan memeriksa bagaimana halaman jika terbentuk.


4

Berikut adalah beberapa pendekatan berguna yang telah saya ambil di masa lalu dengan desainer ketika mereka harus bekerja pada proyek ASP.NET WebForms yang sedang dikembangkan.

  1. Menyebarkan Secara Lokal: Pengembang menyediakan versi menengah dari proyek yang digunakan secara lokal. Ini menghemat waktu untuk keduanya. Perancang meminta .aspx tetapi berinteraksi dengan HTML yang diberikan alih-alih dengan kode server. Pendekatan ini mengabstraksi kode server dari perancang. Dia tidak perlu tahu bagaimana HTML dihasilkan atau bagaimana javscript dan cssfile dikirimkan ke klien. Ini tentu saja mengasumsikan bahwa para desainer terampil dengan browser debugger / inspektur DOM. Perancang dapat menerapkan semua cssperubahannya di dalam browser dan kemudian menerapkannya padacss file.
  2. Menyediakan Model: Agar lebih masuk akal bagi desainer untuk bekerja dengan HTML, berikan mereka model HTML yang diberikan oleh kontrol server. Mereka dapat mengubah HTML itu ke titik di mana mereka menyukainya dan mengusulkan perubahan yang akan diterapkan dalam implementasi sisi server. Ini perlu dilakukan lebih awal dan sering , karena Anda tidak ingin berakhir dengan struktur HTML yang bergantung pada implementasi sisi klien dan kemudian bagi perancang untuk mengusulkan perubahan pada struktur itu.

Para desainer pada umumnya harus memiliki titik sentuh sesedikit mungkin dengan kode sisi server, jadi abaikan saja sebanyak mungkin dari mereka.


2

Sebagai pengembang hibrida, saya sendiri (telah melakukan banyak pekerjaan baik di peran back-end dan front-end, sering bersama-sama), saya memiliki ketidaksukaan lama terhadap model ASP.NET WebForms juga ... sementara awalnya dorongan desain adalah untuk menyediakan alat desain drag-and-drop yang mudah untuk mendemokratisasikan pengembangan web (cara yang sama seperti Visual Basic membuat pemrograman aplikasi dapat diakses oleh non-CS-mayor), metode yang digunakannya untuk mencoba memaksa negara pada suatu lingkungan tanpa kewarganegaraan (web) adalah ham-tangan dan dipaksakan (oh ViewState, betapa aku benci kamu!)

Mereka juga melanggar beberapa prinsip utama pengembangan markup dan gaya, hanya dengan fakta bahwa, secara default, ASP.NET mengambil alih atribut ID, memaksa desainer CSS untuk menggunakan kelas dengan cara yang sama seperti ID dimaksudkan untuk digunakan, elemen pelapis dalam tumpukan div dan tag bersarang yang dapat membuat penataan kontrol menjadi mimpi buruk di semua kecuali sistem yang paling sederhana.

Mengingat hal-hal ini, jalan Anda tidak mudah, karena saya berasumsi penulisan ulang untuk MVC akan memakan biaya atau waktu.

Apakah ada cara untuk memberikan perancang lingkungan tempat menjalankan aplikasi web, sehingga mereka dapat melihat perubahan CSS mereka secara waktu nyata? Ketika saya melakukan pekerjaan desain di ASP.NET WebForms, saya merasa sangat berharga untuk dapat menjalankan aplikasi web di mesin saya sendiri, membuat tweak ke CSS, dan menjalankannya secara lokal untuk melihat bagaimana hal itu mempengaruhi aplikasi.

Salah satu opsi mungkin untuk membuat mesin virtual yang dirancang khusus untuk pengembangan ASP.NET yang dapat dijalankan oleh perancang dari workstation mereka, sehingga mereka tidak perlu mencampur dua toolet mereka, dan jika mereka mengacaukan sesuatu di perangkat. ruang, selalu dapat dimuat ulang dari gambar yang berfungsi.

Ya, ini berarti bahwa perancang harus belajar cara menekan F5 untuk menjalankan aplikasi. (Atau cukup beri mereka akses ke FTP ke direktori tempat CSS, JS dan gambar berada, bahkan, pada lingkungan pengujian!) Ini juga berarti bahwa mereka akan melihat banyak kode back-end, meskipun jika Anda memberi tahu mereka untuk abaikan saja file .cs atau .vb Anda, itu akan membuat Anda tidak panik ... Tentu saja, itu berarti Anda harus memastikan Anda tidak melakukan hal-hal seperti mengatur gaya dari file codebehind Anda .. (tetapi Anda tidak akan melakukan itu, bukan, karena itu mengikat data dan melihat terlalu dekat, bukan?).

Jika situs Anda terstruktur dengan baik, dengan file CSS dan JS yang berbeda, dan tidak banyak gaya inline yang dipaksakan pada markup, mungkin mereka dapat menyelesaikan sebagian besar pekerjaan mereka hanya dengan meminta mereka menghindari area <%%>. Di sisi lain, mungkin juga memberi desainer sedikit lebih banyak penghargaan untuk apa yang harus Anda lalui, ketika mencoba menerjemahkan HTML / CSS statis mereka menjadi sesuatu yang berfungsi untuk aplikasi yang dinamis.


Untuk melihat perubahan CSS secara real-time, saya hanya menggunakan Firebug. Ini berfungsi di mana-mana ... Anda mungkin juga dapat menggunakan Spidermonkey karena Firebug cenderung tidak mengingat perubahan Anda di berbagai halaman
Earlz

Saya agak berasumsi bahwa setiap pengembang web sepadan dengan garam mereka (bahkan yang hanya bekerja dengan HTML dan CSS statis) akan menggunakan sesuatu seperti Firebug, tapi itu hal yang baik untuk dipertimbangkan ... menggabungkan Firebug (atau bahkan jendela Pengembang Chrome) dengan akses ke server uji, atau menjalankannya secara lokal dan menggunakan Firebug di atas itu, menciptakan hal yang paling dekat dengan lingkungan "ideal" untuk membuat seorang desainer terbiasa dengan penyesuaian yang harus mereka buat untuk situs dinamis.
Jason M. Batchelor

1

Anda perlu membuat mereka berbicara bersama, memahami kebutuhan dan preferensi satu sama lain. Ini adalah "masalah" yang tidak dapat diselesaikan oleh perangkat lunak dan alat. Jangan mencoba untuk menyenangkan kedua belah pihak, itu tidak akan berhasil. Mereka perlu berkompromi - itu seperti pernikahan.

Salah satu caranya adalah dengan mengatur f.ex. lokakarya di mana masing-masing pihak mendapatkan kesempatan untuk menjelaskan mengapa mereka memilih apa yang mereka inginkan. Komunikasi yang baik selalu menjadi kunci dalam situasi seperti ini. Mengumpulkan seperti ini bisa dilihat sebagai investasi.

Atau sekadar mengatakan, masalahnya berorientasi pada organisasi, bukan teknis dan di situlah Anda perlu memberikan solusi.

Pilihan lainnya adalah menaikkan gaji dan menyuruh mereka tutup mulut (biasanya solusi jangka pendek ...).


Baris terakhir = lelucon
epistemex
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.