Keputusan Pengembang Untuk Membangun Komponen Fleksibel

Di dunia nyata, konten sering kali sangat berbeda dari konten yang rapi dan pas yang disajikan dalam desain. Selain itu, di web modern, pengguna memiliki pilihan yang terus meningkat tentang cara mereka mengakses situs yang kami buat.

Dalam artikel ini, kita akan membahas proses mengambil desain yang tampaknya sederhana untuk komponen teks dan media dan memutuskan cara terbaik untuk menerjemahkannya ke dalam kode, dengan mengingat kebutuhan pengguna dan penulis konten. Kami tidak akan mempelajari cara mengkodekannya — melainkan, faktor-faktor yang akan menentukan keputusan pengembangan kami. Kami akan mempertimbangkan pertanyaan yang perlu kami ajukan (baik kami sendiri maupun pemangku kepentingan lainnya) di setiap langkah.

Mengubah Pola Pikir Pembangunan Kita

Kami tidak bisa lagi mendesain dan mengembangkan hanya untuk konten atau kondisi penelusuran yang "optimal". Sebaliknya, kita harus merangkul fleksibilitas yang melekat dan ketidakpastian web, dan membangun komponen yang tangguh. Maket statis tidak dapat memenuhi setiap skenario, sehingga banyak keputusan desain jatuh ke tangan pengembang pada waktu pembuatan. Suka atau tidak, jika Anda seorang pengembang UI, Anda adalah seorang desainer — bahkan jika Anda tidak menganggap diri Anda sendiri!

Dalam pekerjaan saya di agen web spesialis WordPress Atomic Smash , kami membangun situs web untuk klien yang membutuhkan fleksibilitas maksimum dari komponen yang kami sediakan, sambil memastikan situs tetap terlihat bagus, apa pun konten yang mereka berikan. Terkadang menafsirkan sebuah desain berarti meminta desainer untuk menguraikan lebih lanjut ide-ide mereka (atau bahkan mengevaluasinya kembali). Di lain waktu, itu berarti membuat keputusan desain dengan cepat atau membuat rekomendasi berdasarkan pengetahuan dan pengalaman kami. Kita akan melihat beberapa saat pendekatan ini mungkin tepat dalam studi kasus ini.

Desain

Kami mulai dengan desain sederhana untuk komponen teks dan media — sesuatu yang cukup umum terlihat di halaman arahan produk. Ini terdiri dari gambar atau video di sebelah kiri dan kolom di sebelah kanan yang berisi judul, paragraf teks, dan tautan ajakan bertindak. Desain ini untuk startup (fiksi) yang membantu orang yang ingin mempelajari keterampilan baru menemukan tutor.

Catatan: Jika Anda ingin langsung membuka kode dan melihat semua kemungkinan solusi yang kami temukan untuk komponen ini, Anda dapat menemukannya di demo Codepen ini.

Tata Letak dan Urutan

Perancang telah menetapkan bahwa setiap komponen lain harus memiliki tata letak yang dibalik sehingga gambar berada di sebelah kanan dan kolom teks di sebelah kiri.

Namun, dalam tata letak seluler, gambar ditumpuk di atas konten teks dalam semua kasus. Dengan asumsi kita membangun layout ini menggunakan Grid atau flexbox, kita bisa menggunakan flex-direction atau properti order untuk menyusun ulang layout untuk setiap komponen kedua:

 .text-and-media:nth-child(even) { flex-direction: row-reverse; }

Perlu diingat bahwa meskipun ini akan menyusun ulang konten secara visual, ini tidak mengubah urutan DOM. Ini berarti bahwa bagi orang yang rabun dekat yang menjelajahi situs menggunakan pembaca layar, urutan konten mungkin tidak tampak logis, melompat dari kiri ke kanan ke kanan ke kiri.

Berbicara secara pribadi, dalam kasus di mana satu-satunya konten di salah satu kolom adalah gambar, saya merasa bahwa menggunakan properti order kurang lebih oke. Tetapi jika kita memiliki dua kolom teks, misalnya, menyusun ulang dengan CSS mungkin membuat pengalaman yang membingungkan. Dalam kasus tersebut, kami memiliki beberapa opsi lain yang tersedia bagi kami. Kita bisa:

1. Kemukakan masalah aksesibilitas kami dan rekomendasikan bahwa untuk tata letak seluler, urutan visual diubah agar sesuai dengan urutan desktop.
2. Gunakan Javascript untuk menyusun ulang elemen di DOM.

Kita juga perlu mempertimbangkan apakah akan menerapkan perintah melalui pemilih :nth-child atau mengizinkan klien untuk mengontrol pesanan (dengan menambahkan kelas ke komponen, katakanlah). Kesesuaian setiap opsi kemungkinan akan tergantung pada proyek.

Berurusan Dengan Panjang Konten yang Berbeda

Dalam desain, proporsi konten teks dibandingkan dengan gambar cukup menyenangkan. Hal ini memungkinkan gambar untuk mempertahankan rasio aspek yang ideal. Tapi apa yang harus terjadi jika teks lebih panjang atau lebih pendek dari apa yang disajikan? Mari kita berurusan dengan yang pertama dulu.

Konten yang Lebih Panjang

Kita dapat menetapkan batas karakter pada bidang teks dalam CMS pilihan kita (jika kita menginginkannya), tetapi kita harus mengizinkan setidaknya beberapa variasi dalam komponen kita. Jika kita menambahkan paragraf yang lebih panjang, kolom media yang berlawanan dapat berperilaku dalam salah satu dari beberapa cara berikut:

1. Gambar atau video tetap di atas, sementara spasi ditambahkan di bawah (gbr. 1).
2. Gambar atau video berada di tengah, menambahkan ruang di bagian atas atau bawah (gbr. 2).
3. Proporsi gambar atau video diskalakan agar sesuai dengan tinggi, menggunakan object-fit: cover untuk mencegah distorsi dan memastikan gambar memenuhi ruang yang tersedia. Ini berarti beberapa bagian gambar mungkin terpotong (gbr. 3).

Kami memutuskan bahwa opsi 3 adalah yang paling menyenangkan secara visual, dan sebagian besar penulis konten akan dapat mengambil gambar yang sesuai di mana sejumlah kecil kliping dapat diterima. Tapi itu menghadirkan lebih banyak tantangan untuk konten video, di mana ada lebih banyak risiko bahwa bagian-bagian penting dapat terpotong. Kami beralih ke opsi lain, yaitu membuat variasi desain yang berbeda di mana video akan mempertahankan rasio aspek aslinya, dan dimuat dalam lebar maksimum alih-alih sejajar dengan tepi halaman.

Penulis konten dapat memilih opsi ini jika lebih sesuai dengan kebutuhan mereka.

Selain itu, kami memilih untuk memperluas pilihan ini ke contoh di mana gambar digunakan, bukan video. Ini memberi klien lebih banyak variasi pilihan tata letak tanpa berdampak buruk pada desain. Dilihat dalam konteks halaman yang lebih luas bahkan dapat dianggap sebagai peningkatan, memungkinkan halaman yang lebih menarik ketika beberapa blok ini digunakan pada halaman.

Konten yang Lebih Singkat

Berurusan dengan lebih sedikit konten sedikit lebih sederhana, tetapi masih memberi kami beberapa masalah. Bagaimana seharusnya gambar berperilaku ketika konten teks lebih pendek? Haruskah itu menjadi lebih dangkal, sehingga tinggi keseluruhan komponen ditentukan oleh konten teks (gbr. 4)? Atau haruskah kita menetapkan rasio aspek minimum, sehingga gambar tidak menjadi kotak surat, atau membiarkan gambar mengambil ketinggian intrinsik alaminya? Dalam hal ini, kami juga memiliki pertimbangan apakah akan menyelaraskan teks ke tengah atau ke atas (gbr. 5 dan 5a).

Panjang judul

Jangan lupa kita juga perlu menguji judul dengan panjang yang berbeda. Dalam desain, judulnya pendek dan tajam, jarang membungkus ke baris kedua. Namun bagaimana jika heading memiliki panjang beberapa baris, atau kontennya menggunakan banyak kata yang panjang, sehingga menghasilkan pembungkusan teks yang berbeda? Ini mungkin terutama menjadi masalah dalam bahasa seperti Jerman, di mana kata-kata cenderung lebih panjang daripada bahasa Inggris, misalnya. Apakah ukuran font heading dalam desain memungkinkan panjang garis yang sesuai saat digunakan dalam tata letak ini? Haruskah kata-kata yang panjang diberi tanda penghubung ketika mereka membungkus? Artikel oleh Ahmad Shadeed ini membahas masalah panjang konten dan menyertakan beberapa tip praktis tentang cara menanganinya di CSS.

Apakah penulis konten diizinkan untuk menghilangkan judul sama sekali jika cocok untuk mereka? Itu membawa kita ke pertimbangan berikutnya.

Menghilangkan Konten

Membangun komponen ini sefleksibel mungkin berarti memastikan bahwa pembuat konten dapat menghilangkan bidang tertentu dan tetap memiliki tampilan dan fungsi desain dengan baik. Tampaknya masuk akal bahwa klien mungkin ingin menghilangkan teks isi, tautan, atau bahkan judul saat menggunakan komponen ini di alam liar. Kita perlu berhati-hati untuk menguji dengan setiap kombinasi konten yang mungkin, sehingga kita dapat yakin bahwa komponen kita tidak akan rusak karena tekanan. Ini praktik yang baik untuk memastikan kami tidak merender tag HTML kosong saat konten bidang tidak ada. Ini akan membantu kami menghindari bug tata letak yang tidak terduga.

Kami dapat membatasi pembuat konten dengan bidang "wajib" di CMS, tetapi mungkin kami juga ingin mempertimbangkan skenario di mana klien mungkin memilih untuk menghilangkan gambar, atau, sebaliknya, tanpa konten teks? Mungkin bermanfaat untuk memberi mereka opsi ini. Berikut adalah contoh bagaimana kami dapat memilih untuk merender komponen dalam kasus tersebut:

Dengan mengindentasi teks sedikit lebih banyak dan menambah lebar teks isi, kita dapat membuatnya tetap seimbang, bahkan saat tidak ada gambar.

Banyak Tautan

Menghilangkan konten adalah salah satu skenario. Namun di Atomic Smash, kami menemukan bahwa lebih sering, klien menginginkan opsi untuk menambahkan lebih dari satu tautan ke komponen. Itu memberi kami pilihan lain: bagaimana cara mengatur banyak tautan? Apakah kita meletakkannya berdampingan (gbr. 8), atau menumpuknya secara vertikal (gbr. 8a)?

Bagaimana kita menangani judul tautan dengan panjang yang sangat berbeda? Trik yang bagus adalah mengatur lebar kedua tautan ke lebar maksimum terpanjang (gbr. 9). (Artikel ini hanya membahas itu.) Itu bekerja dengan baik untuk tombol yang ditumpuk secara vertikal, sedangkan meletakkannya secara horizontal memberi kita lebih banyak pilihan (gbr. 9a).

Apakah kita memerlukan gaya tautan sekunder, untuk membedakannya? Ini semua adalah pertanyaan untuk dipertimbangkan.

Kami mungkin juga perlu mempertimbangkan (dalam kasus satu tautan) apakah, pada kenyataannya, area tautan yang dapat diklik harus mencakup seluruh komponen — sehingga pengguna dapat mengeklik di mana saja untuk mengaktifkan tautan. Pilihan itu mungkin tergantung pada konteks yang lebih luas. Ini tentu umum di UI berbasis kartu.

Video

Saat komponen digunakan untuk video daripada gambar statis, kami mungkin memperhatikan bahwa desain menghilangkan beberapa informasi penting. Bagaimana pemutaran video dikendalikan? melayang-layang? Apakah itu diputar otomatis saat digulir? Haruskah ada kontrol yang terlihat oleh pengguna?

Jika video diputar saat mengarahkan kursor, kita harus mempertimbangkan cara pengguna perangkat tanpa kemampuan mengarahkan kursor mengakses konten video. Atau, jika video diputar otomatis, kami harus mempertimbangkan untuk mencegah hal ini bagi pengguna dengan preferensi untuk mengurangi gerakan, yang mungkin menderita gangguan vestibular (atau mungkin hanya ingin menghindari animasi yang menggelegar). Kami juga harus menyediakan cara bagi semua pengguna untuk menghentikan video kapan pun mereka mau.

Menempatkannya Dalam Konteks

Salah satu masalah dengan fokus begitu dekat pada komponen ketika datang ke desain web, kadang-kadang kita lupa untuk mempertimbangkan bagaimana komponen yang kita bangun akan muncul dalam konteks halaman web secara keseluruhan. Kita harus mempertimbangkan jarak, baik antara komponen dengan jenis yang sama dan dalam tata letak halaman di mana komponen lain diselingi.

Komponen teks dan media ini dirancang untuk digunakan dengan hemat, menciptakan percikan warna yang menarik dan jeda dari tata letak linier. Tetapi menggunakan WordPress, seorang penulis konten dapat dengan mudah memutuskan untuk membangun seluruh halaman yang hanya terdiri dari komponen-komponen ini. Itu bisa terlihat agak membosankan, dan sama sekali bukan efek yang kami harapkan!

Selama proses pembuatan, kami memutuskan untuk menambahkan opsi untuk menghilangkan warna latar belakang. Itu memungkinkan kita untuk memecah halaman dan membuatnya lebih menarik:

Kami dapat menerapkan pola menggunakan :nth-child atau menambahkan bidang di CMS untuk memberikan kontrol yang lebih kreatif kepada klien.

Meskipun ini bukan bagian dari desain asli, ini menunjukkan bahwa jalur komunikasi terbuka antara desainer dan pengembang dapat membantu menciptakan hasil yang lebih baik dalam hal desain yang lebih fleksibel dan kuat.

Gaya Teks WYSIWYG

Saat mempertimbangkan konten, kita perlu mempertimbangkan tidak hanya panjang teks, tetapi elemen HTML sebenarnya yang mungkin diizinkan di bidang teks isi. Penulis konten mungkin ingin menambahkan beberapa paragraf, tautan jangkar, daftar, dan lainnya ke salinan isi. Di Atomic Smash kami ingin menyediakan WYSIWYG (Apa yang Anda Lihat Adalah Apa yang Anda Dapatkan) atau bidang teks kaya untuk area ini, yang memungkinkan banyak elemen berbeda. Sangat penting untuk menguji dengan berbagai jenis konten, dan gaya yang tepat — termasuk pengujian untuk kontras warna yang cukup pada semua warna latar belakang yang digunakan.

Membungkus

Kami telah menyentuh banyak keputusan berbeda yang terlibat dalam membangun komponen yang tampaknya sederhana ini. Anda bahkan mungkin dapat memikirkan beberapa hal lain yang belum kami bahas di sini! Dengan mempertimbangkan setiap aspek desain dan bagaimana hal itu dapat digunakan dalam konteks, kami telah berakhir dengan sesuatu yang jauh lebih fleksibel, yang diharapkan akan menghasilkan klien yang lebih bahagia!

Terkadang, semakin banyak yang dihilangkan dari sebuah desain, semakin banyak waktu dan perhatian yang dibutuhkan dari seorang pengembang. Saya telah menyusun daftar periksa di bawah ini tentang hal-hal untuk diuji dan dipertanyakan saat membuat komponen, yang mungkin berguna bagi Anda. Ini dapat disesuaikan untuk komponen yang berbeda juga.

Mampu melihat melewati kesederhanaan yang tampak, memecah komponen menjadi bagian-bagian penyusunnya, mengajukan pertanyaan kunci (bahkan sebelum pengembangan apa pun terjadi), dan bahkan mempertimbangkan penggunaan di masa mendatang, adalah semua keterampilan yang akan berguna bagi pengembang mana pun saat membangun situs web — dan akan membantu Anda memberikan perkiraan yang jauh lebih akurat bila diperlukan. Komunikasi tim yang baik dan proses kolaboratif yang kuat sangat berharga untuk membangun situs yang tangguh, tetapi hasil akhirnya membuatnya layak untuk diinvestasikan dalam memelihara budaya ini. Mari masukkan fleksibilitas ke dalam proses desain dan pembuatan kami.

Daftar Periksa

Hal-hal untuk diuji:

1. Aksesibilitas tata letak (seluler dan desktop).
2. Gambar dengan rasio aspek intrinsik yang berbeda — apakah gambar dipangkas dengan tepat?
3. Teks isi yang lebih panjang dan lebih pendek (termasuk beberapa paragraf).
4. Judul yang lebih panjang dan lebih pendek (termasuk berbagai panjang kata).
5. Menghilangkan (berbagai macam) judul, teks isi, tautan, dan gambar.
6. Beberapa tautan (termasuk panjang teks tautan yang berbeda).
7. Aksesibilitas konten video.
8. Konten teks WYSIWYG (termasuk tautan, daftar, dll. dalam teks isi).
9. Uji dalam konteks — sertakan beberapa komponen (dengan opsi konten berbeda), serta komponen lain yang digabungkan ke dalam tata letak halaman.