Jauhkan "kode" dari desainer?

Saya membangun sedikit proyek dengan teman saya, tetapi kami selalu datang ke perangkap yang sama berulang-ulang. Saya tahu cara menulis PHP, Javascript dan semua hal (saya juga tahu CSS dan HTML) sehingga saya bisa melakukan sebagian besar pekerjaan ketika datang untuk membangun fungsionalitas yang sebenarnya. Namun, dia tidak bisa, tetapi dia bisa melakukan sesuatu yang saya hampir tidak bisa: merancang situs.

Tetapi setiap kali, kami menemukan masalah, karena dia tidak tahu bagaimana menulis kode, itu biasanya memperlambat perkembangan kami sedikit. Saat ini adalah alur kerja kami:

1. Kami datang dengan fitur
2. Dia membangun desain front-end (di mana ia harus ditempatkan, bagaimana itu akan terlihat, dll.)
3. Dia mengirimkan templat lengkap kepada saya (ekspor HTML dari Pinegrow)
4. Saya mencari perubahan yang dibuatnya, lalu mengimplementasikannya di situs yang sebenarnya (sejak beberapa minggu, saya menggunakan CakePHP untuk itu).
5. ketika sesuatu tidak berjalan sebagaimana mestinya (seperti misalnya, itu tidak berhasil seperti yang kita rencanakan untuk beberapa alasan), saya memperbaiki masalah di sisi saya, kemudian mengirimnya kembali template
6. bilas & ulangi

Proses ini, seperti yang bisa dibayangkan lambat dan tidak efisien. Jadi pertanyaan saya adalah, bagaimana kita bisa membuat proses ini menjadi lebih lancar? Saya telah melihat banyak hal tentang itu kita harus menggunakan Bereaksi dan menggunakan RESTful dan apa yang tidak, tapi kami ingin menggunakan CakePHP untuk itu. Bisakah beberapa orang membimbing saya ke beberapa sumber daya bermanfaat tentang hal itu? Saya sudah mencari ini untuk sementara waktu sekarang tetapi tidak pernah sampai pada solusi yang layak untuk ini.

Pada dasarnya, yang bisa dilakukan pasangan saya adalah mendesain situs. Dia tidak dapat menggunakan Docker (saya menggunakan Docker sepanjang waktu), PHP, Javascript dan cukup banyak hal lain (dia tahu beberapa CSS, tetapi kebanyakan bekerja dengan WYSIWYGeditor) Saya bersedia mempelajarinya, tetapi dia adalah tidak tertarik (jadi saya menghormati itu). Saya harap seseorang di sini dapat membantu saya (dan mungkin orang lain yang datang dengan pertanyaan ini nanti) keluar dengan ini karena saya pikir itu hal yang cukup utama.

Ingin membebaskan Desainer Ujung Depan Anda dari kode? Ingin mempercepat integrasi? Ingin menggunakan teknik profesional yang digunakan oleh situs web paling licin? Sejauh ini, alat terbaik untuk ini adalah:

Cat.

Ya, Cat. Yah beberapa program menggambar. Biarkan dia mengambil tangkapan layar situs Anda, memindahkan barang-barang, dan menambahkan hal-hal yang ia temukan di tempat lain. Ini akan membuatnya bekerja dengan kecepatan ide-idenya dan membebaskan Anda untuk menekuk kode ke bentuk apa pun yang terbaik untuk Anda sambil memberikan apa yang dia butuhkan.

Jika itu masih terlalu lambat, katakanlah karena pelanggan berada di ruangan bersama Anda berdua, saya sarankan satu set alat yang jauh lebih maju:

Kertas, gunting, dan selotip.

Mungkin pulpen jika Anda merasa ambisius.

Saya telah menggunakan teknik ini untuk berhasil mendapatkan keputusan tentang tema, gaya, konten, dan fitur utama untuk sebuah situs di sebuah meja di Roti Panera dengan seorang pelanggan sebelum ada yang menyadari bahwa kami selesai makan.

Itu akan membuatnya cepat, itu akan membebaskan Anda dari "kode" -nya, dan itu sebenarnya cara paling ampuh untuk mengembangkan antarmuka pengguna. Dia dapat mulai melakukan tes kegunaan sebelum Anda menulis baris kode.

Anda mungkin berpikir "oh ini baik-baik saja ketika memulai tetapi Anda tidak menggunakan ini setelah situs dikembangkan". Tidak benar. Ini berfungsi dengan baik di situs stabil. Tetapi sekarang sebagian besar tangkapan layar berasal dari situs Anda sendiri.

Bagaimana jika Desainer Ujung Depan Anda ingin menggunakan beberapa alat penghasil kode untuk membuat tiruannya? Baik tapi jangan berpikir sejenak bahwa Anda harus menggunakan "kode" nya. Yang perlu Anda hormati adalah keputusannya tentang penampilan, aliran, dan presentasi. Apa yang terjadi di balik tirai untuk mewujudkannya bukanlah bidang keahliannya. Itu milikmu. Bertanggung jawab untuk itu.

Cukup hormati pekerjaannya sehingga ketika Anda selesai Anda tunjukkan bagaimana hasilnya. Biarkan dia mengambil semua yang dialami pengguna. Bersiaplah untuk terkena ide-ide baru.

Ini adalah pengembangan berulang. Jangan melakukan banyak hal sebelum bertanya. Lakukan sesedikit mungkin. Tanyakan sesering mungkin. Letakkan mainan di meja Anda agar dia tetap terhibur saat Anda menerapkan ide terbarunya sehingga ia dapat memeriksanya segera setelah dimuat. Terus seperti ini sampai tiba waktunya untuk bertemu dengan pelanggan.

Jika kode yang dihasilkan oleh Desainer Ujung Depan Anda sebenarnya sepadan dengan masalahnya, maka Anda perlu belajar mengintegrasikan kode Anda dengan kode itu. Untuk ini, saya sangat menyarankan Anda untuk belajar kontrol sumber . Pelajari dengan sangat baik sehingga Anda bisa mengajari Desainer Ujung Depan cara menggunakannya.

Hanya setelah Anda berdua dapat andal menggunakan alat kontrol sumber, saya sarankan Anda mendasarkan rencana integrasi Anda pada penggabungan kode. Pada titik ini teman Anda akan berhak atas perubahan judul dari Front End Designer ke Front End Developer.

Sekarang bahkan jika Anda melakukan ini, itu tidak akan mengejutkan saya jika teknik mencoret-coret-di-layar masih tidak menjadi cara tercepat bagi Anda berdua untuk berkolaborasi.

Mungkin Anda tidak bisa mengambil kekacauan dari semua perubahan ini. Ini menciptakan terlalu banyak pekerjaan. Ya itu disebut perangkat lunak karena ia menerima perubahan. Kalau tidak, kita akan memiliki Insinyur Listrik melakukannya pada chip khusus. Mungkin Anda perlu menjangkau arsitek untuk memindahkan logika perilaku Anda dari antarmuka pengguna sehingga perubahan UI tidak akan memengaruhi aturan bisnis inti Anda. Jika Anda mempercepat Desainer Ujung Depan Anda, Anda harus siap untuk mengikuti mereka.

Satu-satunya alasan bagus untuk memaksa seorang Desainer Front End untuk menghasilkan kode adalah karena Anda lelah dan ingin memperlambatnya. Yah, kurasa itu bukan alasan yang "bagus".

Dalam hal alat, alur kerja optimal yang saya lihat menggunakan Sketch dan Zeplin. Sketsa adalah alat desain langsung. Setara dengan Photoshop atau InDesign, tetapi dioptimalkan untuk merancang aplikasi dan situs web. Zeplin adalah alat untuk berbagi dan menyetujui desain dalam Sketch (atau Photoshop). Ini dapat memberikan pengukuran piksel yang tepat dan bahkan potongan kode untuk CSS atau kode tata letak lainnya dan ekspor aset grafis. Setelah desain ditetapkan, itu diserahkan kepada pengembang. Pada titik ini, pengembang mengambilnya dan membangun UI. Kemudian dapat kembali ke perancang untuk QA visual. Apa pun yang menurutnya salah, harus dicatat sebagai bug untuk diprioritaskan dan diselesaikan oleh Anda.

ketika sesuatu tidak berjalan sebagaimana mestinya (seperti misalnya, itu tidak berhasil seperti yang kita rencanakan untuk beberapa alasan), saya memperbaiki masalah di sisi saya, kemudian mengirimnya kembali template

Itulah akar masalah Anda. Alur desain harus selalu dari Designer to Developerdan tidak pernah terbalik. Revisi dan perubahan seharusnya dilakukan oleh perancang, dan kemudian mendorong Anda untuk implementasi di situs web. Anda selalu dapat membuat perbaikan cepat sendiri, tetapi cobalah untuk menerima bahwa perbaikan cepat itu hanya sementara. Perancang perlu kembali ke desainnya dan mencari solusi yang tepat. Dia kemudian mendorong perubahan kepada Anda, dan jika kebetulan sama dengan perbaikan cepat Anda maka bagus, jika tidak, Anda memperbarui dari desainnya.

Dia mengirimkan templat lengkap kepada saya (ekspor HTML dari Pinegrow)

Jangan kecanduan menerima HTML yang bisa Anda kerjakan. Lebih baik jika Anda menerapkan teknologi situs web (Bootstrap, CSS, jQuery, React, PHP, dll. Dll. Dll.) Seperti yang Anda perlukan. Anda kemudian mereproduksi desainnya menggunakan alat-alat itu. Jika HTML yang dia berikan kepada Anda adalah awal yang cepat maka bagus, tetapi kemudian seiring perkembangan proyek itu tidak akan banyak berguna. Anda harus melakukan perubahan sendiri karena hanya Anda yang memahami mesin templating Anda (yaitu tampilan, templat, plugin, komponen, dll. CakePHP, dll. Dll.)

Proses ini, seperti yang bisa dibayangkan lambat dan tidak efisien.

Selalu seperti itu. Desainer bukan programmer. Mereka meluangkan waktu untuk mencari tahu apa yang terbaik untuk pengguna, dan kadang-kadang mereka membuat kesalahan. Mereka tidak memahami konsep seperti komponen, kerangka kerja dan semacamnya. Sebagai programmer Anda harus berbicara dengan desainer Anda dan membagikan bagaimana saya mengimplementasikan apa yang Anda desain .

Perancang itu terjebak di tengah. Di satu sisi mereka harus menyenangkan kebutuhan programmer, dan di sisi lain mereka harus menyenangkan kebutuhan pengguna.

Jadi pertanyaan saya adalah, bagaimana kita bisa membuat proses ini menjadi lebih lancar?

Saya menemukan bahwa secara fisik duduk di samping perancang dan pemrograman di sana sangat membantu dalam komunikasi. Jika Anda berdua bekerja dari jarak jauh, maka terus facetime berjalan selama beberapa hari. Ini sangat membantu mempercepat segalanya.

Saya telah melihat banyak hal tentang itu kita harus menggunakan Bereaksi dan menggunakan RESTful dan apa yang tidak, tapi kami ingin menggunakan CakePHP untuk itu.

CakePHP adalah salah satu kerangka kerja terbaik di planet ini (pengungkapan penuh, saya di tim inti CakePHP).

Cake adalah kerangka pengembangan kelinci di mana fitur dirancang untuk membangun situs web dengan cepat. Saya tahu itu terdengar seperti promosi dagang, tapi ini diklasifikasikan. Ada banyak kerangka kerja lain yang diklasifikasikan sebagai kelinci. Java akan menjadi contoh kerangka kerja yang lebih kuat daripada kelinci. Jika Anda menggunakan bahasa itu, maka saya akan membuat rekomendasi untuk berubah. Karena Anda menggunakan CakePHP. Saya berpendapat Anda harus tetap dengan itu.

CakePHP merupakan server back-end yang bagus jika Anda membutuhkan API yang tenang.

React / Angular / Vue adalah kerangka kerja front-end yang populer dan trending, tetapi mereka belum ada sejak lama. CakePHP di sisi lain telah ada selama 13+ tahun. Maksud saya bukanlah kritik. Itu fakta bahwa perpustakaan JavaScript ini memiliki umur simpan pendek. Dalam 5 tahun kita semua akan berbicara tentang sesuatu yang baru, tetapi saya curiga CakePHP akan tetap ada.

Jadi saya katakan. Gunakan React / Angular / Vue sekarang selagi masih panas, tetapi jangan sampai berkomitmen untuk mereka. Sesuatu yang baru dan lebih baik akan segera terjadi. Saya pikir kita hidup di dunia sekarang di mana Anda tidak dapat membangun situs web yang bagus tanpa mereka.

Bisakah beberapa orang membimbing saya ke beberapa sumber daya bermanfaat tentang hal itu?

Permintaan daftar di luar topik di sini. Maaf.

EDIT :

Saya melewatkan bagian tentang pelacakan perubahan desain.

Mintalah desainer Anda menyimpan output HTML-nya di BitBucket (mereka memiliki repositori pribadi gratis). Anda kemudian dapat melacak dan melakukan perbandingan menggunakan situs web BitBucket. Setiap kali perancang membuat perubahan besar, ia menambahkan cabang baru dengan nomor versi.

Seharusnya relatif mudah baginya untuk melakukan ini, dan ini akan memungkinkan Anda memiliki tempat untuk mengomentari perubahan tersebut. Sebagai contoh; dia dapat membuat permintaan tarik untuk memperbarui repositori tempat Anda melakukan tinjauan terhadap perubahan sebelum digabungkan.

Anda perlu memisahkan dua hal ini:

1. Desain UX & UI, aktivitas nonkode
2. Implementasi, jelas merupakan kegiatan pengkodean

Perancang harus menggunakan alat kreatif seperti Marvel yang hanya untuk mendesain. Seharusnya tidak menjadi perhatian desainer untuk melakukan apa pun dengan kode, HTML, CSS dll. Warna, dimensi, estetika, interaksi, animasi adalah semua hal yang harus ia fokuskan.

Programmer harus menerima aset dan mock-up (dengan interaksi dan animasi) dan harus mewujudkannya dengan memprogram perangkat lunak. Ini termasuk HTML dan CSS juga. Programmer dapat menggunakan alat generator di sisinya juga.

Untuk mempercepat alur tugas, saya sarankan untuk menggunakan alat minimal seperti Trello dan menghubungkan / mendokumentasikan semuanya untuk setiap unit kerja.

bagaimana kita bisa membuat proses ini menjadi lebih lancar?

Bersikeras kontrol versi

Perangkat Lunak Bercabang dan Alam Semesta Paralel

• Bekerja pada kode yang tidak ada dalam kontrol versi. titik. Dan maksud saya mogok sampai proyek semuanya dalam VCS.
• Cabang secara formal, liberal, lokal
  • Secara formal: percabangan untuk rilis dan sub-bagian dari rilis, perbaikan pengujian formal, dll. Membuat rencana kontrol versi formal, yaitu menuliskannya.
  • Secara bebas: Melampaui penomoran rilis formal 4-bagian, percabangkan jika usus Anda memberi tahu Anda bahwa itu mungkin ide yang bagus.
  • Lokal: Saya menyimpan repo pribadi dengan cabang yang tidak pernah dimaksudkan untuk konsumsi tim karena sebagai tim kami tidak bercabang pada awalnya, dan saya sering melakukan eksperimen, eksplorasi, berjaga-jaga, dll.

Insinyur keluar dari API middleware Anda

Manfaat:

• Stabilitas - bahkan ketika kode yang mendasarinya berkembang.
• Kode yang dapat diuji
• Penggunaan kembali
• Alat komunikasi tim
• Itu kontrak. Janji layanan yang diberikan (pun intended)
• Pengkodean dalam ranah SOLID == programmer pemeliharaan bahagia

Itu adalah permintaan, jangan katakan prinsip yang diterapkan dalam cara obsesif kompulsif seharusnya. Jika UI memanipulasi properti lapisan bisnis tunggal, itu salah.

Segala sesuatu dan segala sesuatu tentang objek bisnis harus dalam kata BO. Bahkan hal-hal sepele yang mungkin tampak paling baik dilakukan di UI - bahkan satu LOC. Minuita suka menambahkan 2 nilai yang disediakan pengguna - semua logika yang terkait termasuk validasi harus dalam API lapisan bisnis. Redundansi IMO terkadang baik-baik saja. Untuk mengurangi redundansi, mungkin ada objek lapisan bisnis kecil dan terfokus yang diizinkan akses penuh oleh UI.

Segala sesuatu dan apa pun yang dibutuhkan UI dari objek bisnis harus API'ed. Misalnya memiliki metode eksplisit yang mengirimkan argumennya ke penangan acara.

Waspadalah terhadap kerangka kerja sebagai penopang

Di tangan yang tidak trampil, kerangka kerja dan IDE bukanlah penghalang bagi monster B-film yang mereka buat.

Dengan kerangka kerja seperti Bereaksi Anda bisa mengatakan itu semua sisi klien, tidak ada lapisan logika bisnis ujung belakang. Gagasan utama di sini adalah memisahkan apa yang dilihat pengguna dari apa yang dilakukan oleh program. Itu bisa dilakukan. Ini bukan hanya server fisik vs peramban pengguna.

Saya pikir itu adalah indikator yang baik tentang ketidakdewasaan dari profesi dan praktik yang kita terima bahwa orang yang merancang, tidak bisa melakukannya.

Ini tidak akan diterima di hampir semua profesi lain.

Masuk akal untuk mengharapkan desainer yang berspesialisasi dalam desain situs / aplikasi web untuk mengetahui CSS dan HTML dengan cukup baik untuk memberi Anda file yang dapat digunakan dan digunakan dari jenis itu.

Desainer yang menyediakan editor grafis WYSIWYG adalah desainer visual atau grafis. Ada banyak jenis desainer.

Namun ada juga berbagai jenis tingkat keterampilan, kemampuan, dan pengalaman. Seseorang yang mendesain furnitur dapat melakukannya hanya pada komputer dengan alat desain 3D, dalam hal ini pengetahuan mereka tentang cara mengubah mesin bubut atau mengoperasikan router CNC mungkin sepenuhnya teoretis. Mereka melakukan desain mereka dan kemudian mengirimkannya untuk dibuat oleh orang lain.

Sebaliknya beberapa desainer ahli mungkin memiliki kontrol atas seluruh proses dan memiliki kemampuan dan pengetahuan untuk membangun furnitur mereka dengan memperhatikan setiap detail, bahkan mungkin kerajinan tangan.

Anda tidak akan dapat meyakinkan teman Anda untuk mengubah cara mereka bekerja. Jika Anda lebih suka memiliki perancang web dengan keterampilan HTML dan CSS untuk membangun desain mereka sendiri, Anda harus menemukannya.