Gutenberg: Kontrol responsif khusus blok

Saya akan membagikan beberapa eksplorasi awal tentang topik ini.

Blok yang paling membutuhkan kontrol responsif pada saat ini adalah blok kolom. Saat ini, kolom menumpuk secara otomatis di layar kecil, tanpa indikasi apa pun yang akan terjadi. Blok Media & Teks juga dapat menumpuk di perangkat seluler, tetapi itu termasuk sakelar sakelar untuk mengaktifkan atau menonaktifkan perilaku itu. Ini adalah dasar yang bagus untuk kontrol responsif:

Bagi banyak pengguna, sakelar ini menawarkan lebih dari cukup kontrol: masuk akal untuk mengasumsikan bahwa pembuat situs web modern dapat menangani ini semua secara otomatis jika kami memintanya. Namun kami harus menawarkan beberapa tingkat kontrol yang disesuaikan untuk pengguna yang ingin menentukan berapa banyak kolom yang harus muncul di berbagai breakpoint.

Dengan pemikiran tersebut, saya membangun eksplorasi saya di sekitar beberapa ide inti:

1. Kontrol responsif harus ada di panel "Lanjutan". Panel ini saat ini sangat kurang dimanfaatkan, tetapi tampaknya seperti rumah yang masuk akal untuk pengaturan responsif. Kita harus menetapkan default yang baik, dan dalam banyak kasus pengguna bahkan tidak akan pernah mengunjungi panel ini.
2. Izinkan untuk 3 opsi berbeda :
   A. Default cerdas kami: Tumpuk kolom di perangkat seluler.
   B. Gunakan jumlah kolom yang sama di semua tempat.
   C. Tentukan jumlah kolom untuk ukuran layar seluler, tablet, dan desktop.

Dengan pemikiran tersebut, saya membuat beberapa prototipe:

Prototipe Desktop (Figma)
Prototipe Seluler (Figma)

_Screenshots untuk referensi: _

Seperti yang akan Anda lihat saat Anda mengeklik: saat Anda memilih opsi (C), satu-satunya opsi perangkat yang ditampilkan di panel "Perangkat" adalah perangkat yang _tidak_ gunakan. Jika Anda menggunakan telepon, penggeser default di bawah "Kolom" akan mengontrol jumlah kolom yang Anda lihat di perangkat seluler. Jika Anda tetap memilih opsi (C) dan mengakses blok ini dari mesin desktop, penggeser default akan mengontrol jumlah kolom yang Anda lihat pada tampilan desktop. Ini mencegah duplikasi kontrol yang melakukan hal yang sama, tetapi saya tidak sepenuhnya yakin apakah itu intuitif atau membingungkan. Alternatifnya adalah menampilkan semua perangkat di bawah sana, dan menonaktifkan penggeser default ketika opsi (C) dipilih, tetapi itu tampak aneh bagi saya.

Saya Tertarik dengan beberapa masukan! Saya juga penasaran bagaimana jenis kontrol ini dapat meluas ke jenis pengaturan lain: Blok lain apa yang akan mendapat manfaat untuk kontrol responsif seperti ini?

Saya telah membangun tema yang agak besar baru-baru ini untuk peluncuran proyek kerja dalam beberapa minggu ke depan. Saya pikir saya mungkin harus membagikan beberapa pemikiran saya. Panel berikut adalah apa yang telah saya terapkan untuk menangani kolom bertumpuk di berbagai perangkat. Setiap Perangkat dapat mengaturnya secara eksplisit dan urutannya juga terbalik. (Menggunakan flex untuk kolom css).

Bagian atas (margin / padding) juga tersedia di semua blok. Memungkinkan kami membuat beberapa tata letak yang cukup fantastis sepenuhnya dari editor.

Yang ingin saya lihat adalah tombol desktop / tablet / seluler yang tersedia di bagian atas editor untuk mengalihkan editor ke mode masing-masing tanpa mengubah ukuran jendela. Ini akan memungkinkan pembangunan yang sangat cepat untuk semua tingkat respons. Sementara ketiga mode tersebut berfungsi untuk tujuan saya, kemungkinan berbagai tingkat respons dapat dikonfigurasi dalam tema yang memungkinkan Anda untuk beralih di antara salah satunya.

Karena kami tidak lagi memiliki editor berbasis iframe, ini jelas akan membutuhkan sedikit lebih banyak tipuan untuk dilakukan. Setelah memikirkan sedikit tentang bagaimana saya bisa mencapai sesuatu yang serupa, saya membayangkan bahwa editor tidak dapat menggunakan kueri media, dan sebaliknya css perlu dikembangkan secara khusus untuk editor untuk setiap blok. Saat ini saya melakukan ini untuk tema saya sendiri. Jika div "editor-styles-wrapper" memiliki respons saat ini yang ditambahkan ke kelas, Anda dapat dengan mudah mengganti kueri media untuk respons berbasis kelas.
mis .: .editor-styles-wrapper - mobile {}

Yang ingin saya lihat adalah tombol desktop / tablet / seluler yang tersedia di bagian atas editor untuk mengalihkan editor ke mode masing-masing tanpa mengubah ukuran jendela. Ini akan memungkinkan pembangunan yang sangat cepat untuk semua tingkat respons. Sementara ketiga mode tersebut berfungsi untuk tujuan saya, kemungkinan berbagai tingkat respons dapat dikonfigurasi dalam tema yang memungkinkan Anda untuk beralih di antara salah satunya.

Terima kasih telah berbagi, @mattbolt. Jika Anda belum melihatnya, kami sedang mendiskusikan hal semacam itu di sini: # 13203

Adapun aturan margin / padding responsif: Saya _love_ untuk melihat kontrol yang lebih baik untuk margin + padding. Namun bagi sebagian besar pengguna, saya membayangkan itu akan lebih bermanfaat di tingkat global. Itulah mengapa saya meninggalkannya dari penjelajahan saya di atas. Saya pikir kita harus menyertakan kontrol margin / padding _somewhere_, tetapi per-blok tampaknya agak terlalu terperinci bagi saya (setidaknya untuk inti).

heya @mapk @kjellr - Saya meninggalkan komentar di # 13203, tapi menurut saya ada baiknya menyoroti sebagian darinya dalam edisi ini juga.

Ini adalah prototipe terbaru yang sedang kami kerjakan - Ini berdasarkan umpan balik yang kami dapatkan dari uji kegunaan baru-baru ini yang saya catat di # 13203.

Figma

Pemblokiran kami memiliki beberapa pengaturan berbeda, dan tidak semuanya dapat diedit per perangkat. Karena itu, menurut kami, menempatkan kontrol responsif dalam pengaturan individu masuk akal. Dalam contoh di atas, kontrol responsif untuk tata letak dapat disesuaikan, tetapi pemfilteran menurut kategori tidak bisa. (memfilter menurut kategori harus selalu berlaku untuk semua ukuran perangkat) Kami juga ingin menggunakan default cerdas, sehingga orang tidak perlu masuk dan menyesuaikan tata letak untuk setiap ukuran perangkat.

Bagian pertama dari pengujian kami dijalankan menggunakan blok langsung yang tidak menampilkan kontrol tata letak responsif. Banyak dari peserta kami mengajukan pertanyaan di sepanjang baris, "Bagaimana cara mengubah pengaturan tata letak ini untuk perangkat seluler?" Ini membuat saya percaya bahwa lebih banyak orang akan menginginkan jenis kontrol terperinci ini daripada yang kita pikirkan.

Menempatkan kontrol responsif dalam pengaturan lanjutan adalah opsi lain, namun, saya percaya itu akan membuatnya lebih sulit untuk menemukan ... mengingat itu sedikit masalah satu kali - begitu Anda menemukannya, Anda tahu di mana mencarinya selanjutnya waktu. Karena itu, saya juga berpikir ada sesuatu untuk menjaga kontrol responsif dalam konteks pengaturan yang juga disesuaikan oleh pengguna.

Kami belum sempat menguji versi terbaru ini, tetapi kami berharap dapat segera.

@kjell

Saya Tertarik dengan beberapa masukan! Saya juga penasaran bagaimana jenis kontrol ini dapat meluas ke jenis pengaturan lain: Blok lain apa yang akan mendapat manfaat untuk kontrol responsif seperti ini?

Saya sangat suka bagaimana Anda mengambil sesuatu yang begitu rumit dan menyederhanakannya dengan cara yang dapat digunakan untuk dimengerti oleh siapa saja. Blok lain yang bisa mendapatkan keuntungan adalah blok Galeri yang sudah memiliki beberapa pengaturan penyesuaian kolom yang belum sempurna.

@tokopedia

Bagian atas (margin / padding) juga tersedia di semua blok.

Terima kasih Matt! Penjelajahan Anda ke margin dan padding juga bagus untuk dibagikan di sini. # 11824

@Levinedia

Banyak dari peserta kami mengajukan pertanyaan di sepanjang baris, "Bagaimana cara mengubah pengaturan tata letak ini untuk perangkat seluler?"

Sangat menarik!

Karena itu, saya juga berpikir ada sesuatu untuk menjaga kontrol responsif dalam konteks pengaturan yang juga disesuaikan oleh pengguna.

Ini masuk akal dalam konteks blok Woo yang juga memungkinkan penyesuaian nomor produk. Apakah menurut Anda itu perlu bila hanya ada satu penyesuaian (mis. Kolom) seperti di maket @kjellr ?

Saya memperhatikan bahwa sebagian besar mockup sejauh ini menggunakan kontrol ikon saja. Idealnya, untuk aksesibilitas (dan kegunaan umum), akan lebih baik jika kontrol responsif memiliki label yang terlihat. Saya tidak yakin seberapa layak hal ini, tetapi saya hanya ingin menunjukkannya, karena Gutenberg telah berjuang dengan aksesibilitas di berbagai area, dan itu akan menjadi ide yang baik untuk mencoba dan menghindari menambahkan UI hanya ikon.

Hal lain yang perlu kita pertimbangkan adalah opsi bilah alat yang mungkin memerlukan pengaturan responsif. Misalnya fitur lebar blok yang terdapat pada blok Cover. Anda mungkin ingin lebar sempit di desktop dan lebar penuh di seluler.

Heya @mapk

Apakah menurut Anda itu perlu bila hanya ada satu penyesuaian (mis. Kolom) seperti di maket @kjellr ?

Saya lakukan. Kemudahan dapat ditemukan adalah bagian besar dari alasan itu bagi saya. Ini menempatkan pengaturan responsif langsung dalam konteks pengaturan yang sedang dimanipulasi.

Saya pikir akan ada banyak kasus di mana blok memiliki beberapa pengaturan responsif, dan tidak semuanya akan cocok dengan rapi dalam satu wadah seperti, tata letak.

Misalnya, pertanyaan kedua Anda di atas.

Apakah perlu menyembunyikan / menampilkan blok berdasarkan lebar perangkat?

Dalam penggunaan pembuat halaman saya sebelumnya, jawaban untuk pertanyaan itu adalah ya. Menambahkan pengaturan "Visibilitas" dengan kontrol responsifnya sendiri akan memungkinkan untuk itu.

Kalau dipikir-pikir - Visibilitas mungkin bukan contoh terbaik dalam kasus ini, karena sesuatu seperti itu mungkin akan lebih cocok sebagai daftar matikan sederhana.

[toggle] Tampilkan di desktop
[beralih] Tampilkan di tablet
[toggle] Tampilkan di ponsel

Banyak dari peserta kami mengajukan pertanyaan di sepanjang baris, "Bagaimana cara mengubah pengaturan tata letak ini untuk perangkat seluler?"

@LevinMedia Saya ingin

Saya pikir pertimbangan utama di sini adalah harapan kami untuk seberapa besar dampak manipulasi responsif terhadap pengalaman penulisan secara keseluruhan. Tidak hanya sekarang tapi juga di masa depan.

Mana yang seharusnya menjadi pengaturan default untuk blok? Desktop, seluler, tablet?

Pertanyaan itu ada di pikiran saya saat ini. Saya sangat menyukai desain @kjellr karena alasan @mapk yang disebutkan di atas, tetapi saya tidak yakin seberapa baik transisi ke pengalaman "yang

Seperti yang dikatakan @LevinMedia , sebagian besar peserta dalam uji kegunaan kami baru-baru ini menunjukkan minat yang besar terhadap pengaturan seluler dan menyatakannya sebagai "sangat penting" bagi mereka. Tentu saja harus dikatakan bahwa ada beberapa bias di sana karena setiap peserta adalah pengguna WooCommerce dan mungkin lebih "paham teknologi" daripada pengguna lain.

Kecenderungan saya saat ini adalah setuju dengan @LevinMedia - konteks akan menjadi sangat penting di sini. Saya rasa akan sangat mudah bagi pengguna untuk menemukan pengaturan ini dan memahami apa yang mereka lakukan.

Pada catatan terkait, saya pribadi tidak menyukai bagian "Lanjutan" dari panel pengaturan - untuk hampir semua kasus penggunaan. Rasanya sewenang-wenang bagi saya dan saya benar-benar tidak berharap pengaturan apa yang mungkin saya temukan di sana ketika pertama kali berinteraksi dengan blok.

Pertanyaan itu ada di pikiran saya saat ini. Saya sangat menyukai desain @kjellr karena alasan @mapk yang disebutkan di atas, tetapi saya tidak yakin seberapa baik transisi ke pengalaman "yang

Sejalan dengan ini, salah satu pertimbangan dalam pendekatan saya di atas adalah menyadari dari layar mana Anda mengedit. Dengan kata lain, perangkat yang Anda gunakan adalah yang Anda rancang untuk "pertama". Jika Anda berkunjung dari ponsel, satu-satunya penggeser yang Anda lihat di area utama adalah penggeser seluler. Sisanya ada di Advanced. Atau, jika Anda mengunjungi dari tablet: tablet akan ditampilkan sebagai kontrol default, dan yang lainnya ada di bawah. Ini bisa jadi sangat membingungkan: membagi kontrol antara panel sidebar biasa dan Advanced terasa agak aneh bagi saya, seperti yang saya sebutkan awalnya dalam catatan saya di atas.

Tapi secara umum, saya menyukai gagasan umum tentang perangkat-sadar. Dalam mockup yang diposting

Menghabiskan sedikit waktu untuk memikirkan arah yang sedikit berbeda untuk ini. Satu hal yang kurang sesuai dengan saya dari iterasi saya sebelumnya adalah bagaimana saya memisahkan kontrol kolom antara panel "Kolom" sidebar utama dan panel "Advanced".

Penjelajahan ini sedikit menyederhanakan opsi dan memindahkan semuanya kembali ke area "Kolom" utama:

🖥 Prototipe Desktop

📱 Prototipe Seluler

Bingkai pertama hanya menambahkan tombol "Tumpukan di ponsel" yang saat ini kami miliki di blok Media & Teks. Secara default, ini diaktifkan, dan semuanya ditangani secara otomatis. Ini adalah pengaturan terbaik untuk pengguna yang tidak ingin mengelola pengaturan ini. Tidak seperti hari ini, jika pengguna menonaktifkannya, mereka akan disajikan dengan kontrol yang lebih baik di sana. Dari sini, mereka dapat membiarkannya sendiri (secara default memiliki ukuran yang sama untuk masing-masing), atau menyesuaikan untuk mengatur jumlah kolom yang berbeda untuk setiap jenis perangkat.

Beberapa pertimbangan:

• Umumnya, ini membutuhkan pelabelan + deskripsi yang lebih baik.
• Ini berfungsi dengan baik untuk satu opsi, tetapi tidak akan diskalakan dengan baik jika ada beberapa pengaturan per breakpoint.
• Kami biasanya tidak menampilkan / menyembunyikan kontrol berdasarkan sakelar sakelar yang dimatikan. Tidak yakin apakah itu masuk akal di sini.
• Terkait dengan hal di atas: dari segi hierarki, tampaknya aneh jika sakelar sakelar memengaruhi bidang di atasnya. Mungkin akan lebih alami untuk memimpin dengan sakelar dalam kasus ini. _Also_ itu juga tidak terasa benar, karena hal utama yang ingin dilakukan orang di sini adalah menyesuaikan jumlah kolom, bukan mengaktifkan kontrol responsif.

Satu pertanyaan yang terus saya kembalikan saat saya menjelajahi dan membaca pemikiran di sini: seberapa sederhana atau rumit seharusnya ini _in inti? _ Beberapa blok khusus akan menyertakan banyak pengaturan individual untuk setiap breakpoint: margin, padding, menampilkan + menyembunyikan blok, dll. Itu mungkin yang membuat basis penggunanya nyaman. Tapi kami tidak ingin memasukkan level kontrol itu ke dalam blok default karena ini bisa membuat pengguna pemula kewalahan. Yang mengatakan ... mungkin bermanfaat bagi kami untuk menetapkan pola desain yang dapat meningkatkan skenario super rumit tersebut, sehingga kami dapat membantu menunjukkan bagaimana hal ini harus ditangani dalam semua kasus. Bagaimana kita dapat mendefinisikan pola sederhana yang berskala antara orang yang _tidak_ ingin mengelola setelan responsif dan mereka yang ingin benar-benar spesifik tentang hal ini?

Maket yang bagus, @kjellr!

Umumnya, ini membutuhkan pelabelan + deskripsi yang lebih baik.

Paling tidak, ikon perangkat harus dipindahkan ke label untuk setiap slider, misalnya "🖵 Desktop".

Ini berfungsi dengan baik untuk satu opsi, tetapi tidak akan diskalakan dengan baik jika ada beberapa pengaturan per breakpoint.

Saya pikir jawabannya terletak pada sakelar. Bagaimana jika setiap kontrol responsif memiliki tombol untuk mengaktifkan / menonaktifkan penyesuaian responsivitas pengaturan? Divi Builder memiliki sesuatu yang sangat mirip dengan ini.

Terkait dengan hal di atas: dari segi hierarki, tampaknya aneh jika sakelar sakelar memengaruhi bidang di atasnya. Mungkin akan lebih alami untuk memimpin dengan sakelar dalam kasus ini. Itu juga tidak terasa benar, karena hal utama yang ingin dilakukan orang di sini adalah menyesuaikan jumlah kolom agar tidak mengaktifkan kontrol responsif.

Saya pikir saya lebih suka memiliki toggle di atas slider, karena toggle itu mempengaruhi slider.

Tapi kami tidak ingin memasukkan level kontrol itu ke dalam blok default karena ini bisa membuat pengguna pemula kewalahan.

Saya pikir banyak hal yang dapat disembunyikan di balik matikan seperti yang ada di mockup Anda secara default, atau hanya dengan menyimpannya dalam akordeon tertutup secara default. Margin dan padding keduanya bisa berada dalam akordeon yang sama, dan Anda dapat mengaktifkan respons untuk kontrol tersebut dengan matikan seperti di mockup Anda. Saya tidak berpikir ini akan membebani pengguna dengan opsi jika akordeon ini ditempatkan di bawah semua opsi yang lebih umum dan ditutup secara default.

@kjellr - Menindaklanjuti komentar Jay. Kami memiliki ukuran sampel kecil (delapan peserta) jadi seperti yang saya sebutkan sebelumnya, lebih banyak pengujian / penelitian pasti diperlukan.

Semua peserta berasal dari Grup Umpan Balik Desain WooCommerce - Seperti yang disebutkan jay, peserta kami, dan kelompok peserta ini khususnya sangat condong ke arah profil builder / Store Assembler yang lebih berpengalaman, daripada pemilik toko DIY.

Sebuah tindak lanjut kecil untuk mockup yang saya posting kemarin :

🖥 Prototipe Desktop

📱 Prototipe Seluler

Setelah melakukannya dengan @jasmussen dan beberapa orang lain, saya mencoba menggunakan ButtonGroup alih-alih Toggle , di samping beberapa (semoga) salinan yang lebih jelas. Mengubah pemformatan dan penyalinan dengan cara ini memungkinkan kita menempatkan kontrol secara lebih alami di atas kontrol kolom. Itu terasa jauh lebih diharapkan secara hierarkis.

Satu hal yang sangat saya suka tentang pendekatan ini adalah bahwa ia menetapkan preseden bahwa, kontrol ini harus ditangani oleh blok secara default. Perancang blok akan memiliki kontrol yang jauh lebih banyak daripada yang dimiliki pengguna, karena mereka akan dapat menentukan titik putus mereka sendiri. Perancang blok juga akan memiliki lebih banyak pengalaman dengan desain responsif daripada banyak pengguna, dan harus dapat menerapkan praktik terbaik di sini.

Juga, jika pengguna beralih ke manual, membuat banyak penyesuaian ke pengaturan breakpoint, dan mengacaukan segalanya, opsi "Otomatis" adalah jalan keluar cepat bagi mereka.

Masih ada beberapa hal aneh yang harus diselesaikan di sini (misalnya, siapa yang memilih breakpoint yang tepat ini?). Tapi ini sepertinya jenis pengaturan yang mungkin dapat meningkatkan pengaturan yang lebih rumit , dan saya pikir kita semakin dekat.

Senang, Kjell. Ini memungkinkan default yang terbaik dalam banyak kasus, namun perincian bagi mereka yang menginginkannya. Ini juga terasa seperti pola yang dapat diskalakan dari blok kolom, ke blok lain, bahkan ke blok pihak ketiga. Sudah selesai dilakukan dengan baik.

Bagus sekali, @kjellr!

Saya masih berpikir bahwa masing-masing slider harus memiliki label tekstual yang terlihat untuk alasan aksesibilitas dan kejelasan, tetapi selain itu, saya pikir kita hampir bisa benar-benar mengimplementasikan fungsi ini!

Selain itu, dalam hal aksesibilitas, apakah kami yakin grup tombol lebih sesuai daripada toggle dalam konteks ini?

Saya suka konsep ini dan mereka bekerja dengan baik untuk kolom tetapi saya melihat beberapa masalah kecil dengan keduanya.

Konsep dengan sakelar adalah favorit saya dari keduanya, tetapi tidak akan konsisten di seluruh pengaturan karena label akan berbeda setiap kali. Jadi tidak akan langsung terlihat jelas bahwa pengaturan tersebut memiliki opsi seluler. Saya khawatir tentang skalabilitas.

Konsep dengan kontrol tersegmentasi terasa sedikit aneh bagi saya karena Anda meminta penulis untuk membuat pilihan otomatis vs manual sebelum benar-benar berinteraksi dengan pengaturan kolom. Bukan itu yang saya harapkan saat membuka bagian "kolom" di setelan. Labelnya juga tidak terlalu jelas bagi saya.

Saya ingin mendengar lebih banyak pemikiran seputar konsep @LevinMedia yang dibagikan sebelumnya. Kami menemukan solusi itu setelah putaran pengujian kegunaan dan tampaknya cukup konsisten dengan apa yang dilakukan penulis blok lain. Apakah ada alasan kami mengabaikan pendekatan itu?

Saya ingin mendengar lebih banyak pemikiran seputar konsep @LevinMedia yang dibagikan sebelumnya. Kami menemukan solusi itu setelah putaran pengujian kegunaan dan tampaknya cukup konsisten dengan apa yang dilakukan penulis blok lain. Apakah ada alasan kami mengabaikan pendekatan itu?

Tentu! Saya tidak bermaksud mengabaikan solusi itu. Hal utama yang saya lihat hilang dari arah itu adalah penyajian opsi "mari kita tangani". Sementara pengguna yang lebih mahir akan langsung masuk dan mengedit semuanya di bawah masing-masing ikon perangkat tersebut, itu akan menjadi _lot_ pekerjaan untuk pengguna pemberitahuan. Apalagi kalau kita bisa langsung menanganinya untuk mereka.

Selain itu, inti dari arah tersebut adalah kontrol tersegmentasi untuk perangkat:

Saya pikir bekerja dengan cukup baik dan bisa menjadi pola untuk digunakan di sini, meskipun jika kita memasukkan kontrol tersegmentasi di atasnya, itu bisa menjadi aneh.

Hal utama yang saya lihat hilang dari arah itu adalah penyajian opsi "mari kita tangani".

Kena kau. Jadi kekhawatirannya adalah bahwa matikan tablet / seluler tidak terasa opsional? Itu masuk akal. Namun saya merasa kontrol perangkat yang tersegmentasi akan memberikan pola yang lebih konsisten di berbagai jenis pengaturan dan oleh karena itu menskalakan lebih baik. Kemudahan penggunaan vs. Konsistensi dan skalabilitas adalah hal yang sulit!

Untuk lebih menekankan pada konsep-konsep ini, saya sarankan untuk menambahkan opsi lain di bawah kolom, yang juga akan memiliki komponen responsif: Baris.

Untuk lebih menekankan pada konsep-konsep ini, saya sarankan untuk menambahkan opsi lain di bawah kolom, yang juga akan memiliki komponen responsif: Baris.

Ya, saya mengejek sesuatu seperti ini dengan cepat untuk mencobanya. Ini secara teknis berfungsi, meskipun itu sedikit berulang + longwinded:

Membuat konsep lain yang saya dan

Prototipe figma

Hal yang saya suka:

1. Artinya penulis hanya perlu menyesuaikan satu pengaturan, dengan asumsi mereka ingin segala sesuatunya ditangani secara otomatis.
2. Bahkan dalam "mode otomatis", mereka masih dapat melihat berapa banyak kolom yang akan mereka dapatkan di seluler, tidak ada misteri.
3. Membatalkan tautan pengaturan untuk kontrol penuh hanya dengan satu klik.

Hal-hal yang tidak saya sukai:

1. Ini membutuhkan sedikit ruang secara visual
2. Tidak ada opsi "tumpukan kolom di seluler" yang sederhana. Jujur tidak yakin apakah itu masalah besar atau tidak…

Saya rasa saya lebih suka toggle standar daripada tombol ikon rantai-link, karena lebih mudah memberi label. Ingat bahwa UI harus dirancang dengan mempertimbangkan aksesibilitas.

Saya membayangkan UI bisa terlihat seperti ini:

Jumlah kolom
(ON⚫) Secara otomatis menyesuaikan kolom untuk perangkat seluler.
――――― o― [__4]

Jumlah kolom
(⚫OFF) Secara otomatis menyesuaikan kolom untuk perangkat seluler.

🖥️Desktop
――――― o― [__4]
⬛Tablet
――― o ――― [__3]
📱Telepon
―O ――――― [__2]

Visibilitas
(ON⚫) 🖥️Tampilkan di desktop
(ON⚫) ⬛Tampilkan di tablet
(ON⚫) 📱Tampilkan di ponsel

Secara teknis konsep "link" adalah hal yang sama, toggle hanya berada di lokasi yang berbeda secara visual. Itu masih dapat diungkapkan kepada pembaca layar dengan cara yang hampir sama dan tooltip dapat ditambahkan sebagai label (saya tidak yakin seberapa dapat diaksesnya mereka). Ada juga keuntungan tambahan dengan memberi tahu penulis berapa banyak kolom yang akan digunakan pada layar kecil, bahkan dalam mode "otomatis", tanpa memaksanya masuk ke pratinjau. Mungkin itu tidak terlalu berguna - sulit untuk mengetahui tanpa pengujian.

Saya setuju bahwa format ini tidak akan berfungsi dengan baik untuk pengaturan visibilitas. Menghubungkan opsi-opsi itu bersama-sama tampaknya tidak ada gunanya. Tetapi bagi saya, pengaturan itu juga tidak membutuhkan sakelar otomatis / manual. Tombol visibilitas tunggal per perangkat paling masuk akal.

Secara teknis konsep "link" adalah hal yang sama, toggle hanya berada di lokasi yang berbeda secara visual. Itu masih dapat diungkapkan kepada pembaca layar dengan cara yang hampir sama dan tooltip dapat ditambahkan sebagai label (saya tidak yakin seberapa dapat diaksesnya mereka).

Label yang terlihat selalu lebih mudah diakses. Juga harus diingat bahwa urutan visual dari kontrol harus sesuai dengan urutan tabnya, dan urutan tabnya harus mengikuti arsitektur informasi ... artinya kontrol yang akan Anda gunakan secara logis pertama kali muncul sebelum yang akan Anda gunakan setelahnya, dan berbagai hal. seperti judul sebelum paragraf yang mereka tuju. Ping @afercia , karena dia tahu lebih banyak tentang ini daripada saya.

Ada juga keuntungan tambahan dengan memberi tahu penulis berapa banyak kolom yang akan digunakan pada layar kecil, bahkan dalam mode "otomatis", tanpa memaksanya masuk ke pratinjau. Mungkin itu tidak terlalu berguna - sulit untuk mengetahui tanpa pengujian.

Ini jelas merupakan manfaat yang bagus, meskipun saya tidak yakin apakah menampilkan banyak kontrol yang dinonaktifkan secara default cocok dengan mencoba mencegah UI merasa luar biasa. Secara pribadi saya tidak akan terganggu olehnya, tetapi beberapa orang mungkin.

Suka ide dan diskusi ini!

Sepertinya sejauh ini fokus pembahasannya adalah admin UX, sebagaimana mestinya.
Namun, saya ingin menawarkan beberapa bahan pemikiran di front-end, konten pertama, dan web modern.

Anda benar-benar tidak bisa mengalahkan paradigma 3 perangkat dalam hal membuat pengguna biasa memahami "desain responsif". Masalahnya, 3 desain untuk 3 perangkat sebenarnya bukan desain responsif. Ini desain Adaptif. Ini adalah impian pipa tentang pixel perfect, yang tidak ada dengan web modern. Ini kaku, rapuh, bukan bukti masa depan dan tidak selalu menghasilkan apa yang diharapkan pengguna.

Fitur CSS baru dirilis setiap saat untuk menjauhkan kita dari desain adaptif dan menuju responsif. rem , vw , flex , grid .

Desain responsif adalah tentang membiarkan konten menginformasikan desain daripada membiarkan desain mendikte dan mengkompromikan konten.

Berikut tampilan kolom dari TwentyNineteen

Jika desain situs saya meminta 6 kolom teks, saya lebih suka desain itu dikompromikan sedikit sebelum lebar paragraf kurang dari 150 piksel.

Flexbox dapat membuat ini cukup otomatis. Cobalah.

.wp-block-columns {
    display: flex;
    flex-wrap: wrap;
}

.wp-block-column {
    flex: auto;
    width: 100%;
    margin: 0 1rem 1rem;
}

.has-4-columns .wp-block-column {
    width: calc(100% / 4 - 2rem);
}

.has-6-columns .wp-block-column {
    width: calc(100% / 6 - 2rem);
}

.wp-block-column {
    min-width: 100px
}

Sementara apa yang telah dibahas sejauh ini bagus dari perspektif UX:

Izinkan untuk 3 opsi berbeda:
A. Default cerdas kami: Tumpuk kolom di perangkat seluler.
B. Gunakan jumlah kolom yang sama di semua tempat.
C. Tentukan jumlah kolom untuk ukuran layar seluler, tablet, dan desktop.

Saya ingin membuang ini dari sudut pandang pertama konten:

Mungkin 3 opsi ini?
A. Default cerdas: lebar kolom minimum 200px (ish).
B. Tentukan jumlah kolom.
C. Sesuaikan lebar kolom minimum di mana kolom akan didorong ke baris berikutnya.

Terima kasih telah mengungkit hal ini, @meh. Anda benar tentang banyak hal - itu pasti ada di pikiran saya juga.

Bagian terpenting bagi saya adalah bagian ini: tidak ada yang mengalahkan paradigma perangkat untuk membuat orang memahami desain responsif. Mereka melihat ikon-ikon tersebut, dan mereka segera mendapatkannya. Pengaturan seperti "sesuaikan lebar kolom minimum di mana kolom akan didorong ke baris berikutnya" masuk akal bagi kami, tetapi mereka jauh lebih abstrak, dan akan membutuhkan lebih banyak daya otak pengguna untuk mengetahuinya. Banyak profesional kesulitan memahami desain responsif yang sebenarnya, jadi kami perlu mencari cara termudah untuk mengkomunikasikannya kepada pengguna.

Desain responsif sejati sangat bergantung pada konteks dan konten. Meskipun 3 opsi seperti yang Anda usulkan mungkin bekerja dengan baik untuk blok kolom, pengaturan untuk blok bio produk atau penulis mungkin sama sekali berbeda. Salah satu tujuan utama tiket adalah menemukan solusi yang dapat bekerja di banyak konteks yang berbeda, dan membuat pola umum untuk diikuti oleh perancang / pengembang blok. Itu sebenarnya alasan utama saya menjauh dari 3 opsi itu di comp pertama yang saya posting di atas .

Seperti yang Anda catat, desainer + pengembang sebagian besar telah beralih ke pengaturan breakpoint di tempat-tempat di mana konten memerlukan tata letak untuk dipecah, bukan pada pengukuran perangkat yang sewenang-wenang. Kami pandai melakukan itu (kebanyakan 😄). Saya membayangkan setiap "default pintar" blok menjadi tempat terbaik bagi kita untuk mengatasinya. Perancang / pengembang blok (umumnya) mengetahui jenis konten yang kemungkinan besar akan dikandung oleh blok mereka, dan idealnya mereka tidak perlu mematuhi breakpoint perangkat ini untuk status default. Jika pengguna memutuskan ingin mengelolanya sendiri, kami dapat membatalkan aturan responsif super spesifik apa pun yang telah dibuat oleh pengembang, dan memberikan alternatif yang lebih terstandardisasi dan mudah dipahami untuk diedit pengguna.

Itu semua benar-benar untuk diperdebatkan, tapi setidaknya itulah yang menjadi pemikiran saya tentang topik ini. 🙂

Ya, saya mengerti dan setuju 💯 dengan alasan untuk menjelajahi solusi berbasis perangkat. Hanya ingin menempelkan serangga ini ke telinga saat sedang direncanakan.

Saya pikir mungkin ada kompromi. Sebagian besar bagaimana CSS menangani pilihan dan nilai yang diteruskan kepadanya.

Hanya membagikan beberapa pembaruan kecil tentang arah ini dari minggu lalu .

Pertama, saya memikirkan beberapa label alternatif untuk opsi sakelar:

Saya condong ke salah satu dari yang di kanan: Saya pikir mereka lebih jelas daripada apa yang saya masukkan di sana pada awalnya dan dari tes cepat di tempat dengan teman non-teknisi, dia sepertinya mengerti apa itu lebih jelas dari yang lain. Untuk label ButtonGroup yang sebenarnya, menurut saya menukar "Kustom" untuk "Manual" mungkin sedikit masuk akal? Meskipun saya tidak memiliki preferensi yang kuat.

Saya juga berpikir akan sangat membantu untuk menyertakan baris teks sekunder opsional sehingga blok dapat memberikan sedikit konteks tambahan untuk perilaku default. Dalam kasus blok kolom, ini mungkin seperti ini:

Saya juga menghabiskan sedikit waktu mengevaluasi ulang eksplorasi di sekitar pengaturan yang lebih rumit. Saya ingin tahu apakah mengizinkan plugin untuk mengelompokkan beberapa kontrol di bawah satu jenis perangkat akan membantu atau tidak:

Hal lain yang muncul saat mengobrol tentang masalah ini dengan orang lain adalah hubungan antara membuat pengaturan untuk perangkat lain, dan melihat pratinjau perubahan itu. Mungkin ada tempat di mana kami dapat menyertakan tautan ke pratinjau khusus perangkat di area ini (dengan nada # 13203).

Catatan tentang proses: masalah yang membahas pengenalan kontrol UI baru harus memiliki label "Aksesibilitas" jika kami benar-benar bertujuan untuk meningkatkan kolaborasi di seluruh tim dan membangun produk yang lebih baik. Memberi label yang benar dan mendorong partisipasi akan sangat dihargai 🙂

Re: prototipe terbaru dengan opsi "Auto" dan "Custom": apa elemen HTML asli yang mendasari kontrol ini harus didasarkan?

• tombol: teks "Otomatis" dan "Kustom" yang dibacakan di luar konteks oleh teknologi bantuan tidak masuk akal
• tombol radio: teks "Tata letak khusus perangkat" di atas dapat digunakan untuk legenda kumpulan bidang yang akan memberikan konteks ke tombol radio.

Pada titik ini: apa argumen untuk tidak menggunakan tombol radio asli, yang merupakan elemen yang tepat untuk digunakan untuk opsi pilihan tunggal?

@kjellr @afercia
Saya tidak melihat alasan untuk tidak hanya menggunakan sakelar berlabel "Gunakan tata letak khusus perangkat khusus" atau sesuatu seperti itu yang dinonaktifkan secara default. Teks tambahan yang menjelaskan keadaan saat ini dapat ditampilkan di bawah tombol, mirip dengan beberapa kontrol tombol yang ada di Gutenberg. Tetapi jika tombol radio digunakan, saya setuju bahwa "Kustom" berfungsi lebih baik daripada "Manual".

Saya tidak melihat alasan untuk tidak hanya menggunakan sakelar berlabel "Gunakan tata letak khusus perangkat khusus" atau sesuatu seperti itu yang dinonaktifkan secara default. Teks tambahan yang menjelaskan keadaan saat ini dapat ditampilkan di bawah tombol, mirip dengan beberapa kontrol tombol yang ada di Gutenberg.

Saya akan memberi ini +1.

Keluhan utama saya dengan Segmented Control adalah tampilannya seperti dua opsi, yang meningkatkan kompleksitas yang dirasakan 100% vs satu toggle. Penulis harus memahami pengaturan _dua_ daripada _one_.

Karena sakelar dapat memiliki label yang lebih detail yang membuatnya lebih mudah untuk dipahami. Sepertinya kasus satu pengaturan dengan penjelasan yang sangat jelas vs dua pengaturan dengan penjelasan yang lebih ambigu. Ada pemenang yang jelas di sana.

Namun, saya akan menganggap bahwa sakelar menjadi _on_ secara default dan menyetel label ke sesuatu seperti "Konfigurasi tata letak secara otomatis untuk ukuran layar lain". Alasan saya adalah bahwa ini adalah sesuatu yang kami hadirkan sebagai "default pintar" yang _enabled_ secara default. Bagi saya itu terasa seperti sesuatu yang Anda pilih. Seperti melepas roda latihan atau menonaktifkan ABS.

Saya sangat terkesan dengan proses Anda, di sini, Kjell - Anda positif dan berpikiran terbuka tentang hal ini, model kontributor produktif ❤️, dan Anda memanfaatkan pola dan kontrol UI yang ada.

Saya ingat melihat Anda (saya tidak ingat di mana, DM pribadi?) Membuat versi toggle ini juga, dan bahwa Anda menjelajahi menggunakan ButtonGroup untuk benar-benar meningkatkan kegunaan dan aksesibilitas. Mungkinkah ada baiknya memposting mockup itu di sini juga?

Saya pribadi tidak memiliki preferensi untuk versi mana yang mungkin kami tetapkan ke lautan ulasan yang kacau, tetapi mengingat penyebutan matikan baru-baru ini, sepertinya itu mungkin layak untuk ditampilkan sebagai opsi juga.

Buttongroup berfungsi dengan baik untuk dimensi Gambar terutama karena setiap item dalam grup terkait secara jelas:

Terima kasih atas umpan baliknya. 👏

@ercia

Memberi label yang benar dan mendorong partisipasi akan sangat dihargai

Tentu saja! Utas ini sangat aktif, saya belum menggulir ke atas untuk melihat labelnya selama berminggu-minggu sekarang. Terima kasih telah menambahkan label Aksesibilitas, dan selamat datang di diskusi.

Pada titik ini: apa argumen untuk tidak menggunakan tombol radio asli, yang merupakan elemen yang tepat untuk digunakan untuk opsi pilihan tunggal?

Saya mencobanya sebelumnya, tetapi tidak berbagi eksplorasi:

Inilah mengapa saya melewatkannya secara pribadi:

1. Kontrol radionya memakan banyak ruang, dan menurut saya tidak jauh lebih jelas. Tujuannya di sini adalah untuk membuatnya tampak sederhana - kebanyakan orang seharusnya dapat mengabaikan pengaturan ini dan membiarkan kami menanganinya.
2. Panduan kami
3. Saya telah mencari Material untuk pola yang akan digunakan di sini. Saya tidak dapat menemukan contoh tombol radio yang memicu kemunculan / persembunyian kontrol tambahan. Namun, saya telah menemukan beberapa contoh matikan yang melakukan itu .

@jasmussen

Saya ingat melihat Anda (saya tidak ingat di mana, DM pribadi?) Membuat versi toggle ini juga, dan bahwa Anda menjelajahi menggunakan ButtonGroup untuk benar-benar meningkatkan kegunaan dan aksesibilitas. Mungkinkah ada baiknya memposting mockup itu di sini juga?

Ya, saya membagikannya dengan Anda di DM saat membicarakan hal ini. Ini dia:

Saya juga menyiapkan prototipe desktop untuk pendekatan ini.

Saya bingung antara dua solusi ini. Mengikuti pedoman kami sendiri, ButtonGroup digunakan untuk "mengelompokkan tombol terkait bersama", dan FormToggle standar kami "mengaktifkan atau menonaktifkan satu pengaturan".

Hanya berdasarkan deskripsi singkat itu, saya pikir FormToggle lebih masuk akal. Tapi itu kurang lebih ada di antara dua pendekatan.

Hal utama yang harus dilakukan ButtonGroup adalah fakta bahwa itu memungkinkan kami untuk lebih jelas memberi label pada kedua status (Otomatis, Manual). Kata-kata untuk ini sangat membingungkan, jadi sepertinya itu adalah nilai tambah. Saya benar-benar bisa diyakinkan sebaliknya, dan keduanya layak untuk diuji.

Oh juga, menanggapi diriku sendiri dari atas sini :

Hal lain yang muncul saat mengobrol tentang masalah ini dengan orang lain adalah hubungan antara membuat pengaturan untuk perangkat lain, dan melihat pratinjau perubahan itu. Mungkin ada tempat di mana kami dapat menyertakan tautan ke pratinjau khusus perangkat di area ini (dengan nada # 13203).

Saya melakukan eksplorasi cepat tentang bagaimana ini mungkin terlihat, memikirkan pratinjau di dalam modal:

Ini sepertinya menyenangkan, tetapi mungkin juga berada di luar cakupan masalah ini.

Saya juga tidak terlalu menyukai perlakuan "hanya saat mengarahkan kursor" terhadap ikon pratinjau. Saya mengubahnya sedikit ketika mencoba ini di ponsel:

Benar-benar gali pratinjau responsif itu. Saya telah mencorat-coret di sepanjang baris yang sama di waktu luang, hanya dengan mengganti tombol pratinjau dengan itu:

👆 tapi itu membutuhkan lebih banyak waktu dalam oven, tolong jangan menganggapnya sebagai proposal. Hanya benih ide untuk digabungkan, untuk tumbuh menjadi sesuatu yang _aktual_.

Saya mengubah salah satu mockup @kjellr agar lebih ramah aksesibilitas dengan menambahkan label ke ikon perangkat dan label "Jumlah kolom" ke grup slider. (Apakah itu yang terakhir diperlukan, @afercia?)

Satu hal yang saya tidak yakin adalah bagaimana lebar breakpoint didefinisikan. Apakah mereka disediakan oleh tema atau blok? Bisakah sebuah blok memilih hanya memiliki 2 breakpoint, bukan 3? Bagaimana dengan 4? Bagaimana dengan lebar breakpoint kustom? Apapun masalahnya, menurut saya editor tidak harus menyediakannya.

Ikatan semacam ini dengan apa yang dibicarakan @meh dalam komentar ini . Saya mulai condong ke sesuatu yang mirip dengan apa yang dia sarankan di akhir komentar itu. Saya membayangkan bahwa kontrol responsif untuk kolom dapat diterapkan hanya dengan 2 slider:

Lebar kolom minimum
――――― o ―――― [300] px
Kolom maksimum per baris
――― o ―――――――― [__3]

Ini tampaknya jauh lebih sederhana dan jauh lebih "responsif" bagi saya, tanpa harus menggunakan titik putus yang sulit berdasarkan lebar layar perangkat rata-rata.

Tujuannya di sini adalah membuatnya tampak sederhana

@kjellr yakin dan terima kasih atas klarifikasinya. Namun, kontrol tidak hanya _appear_ sederhana. Mereka juga harus benar secara semantik untuk mendukung teknologi pendukung. Misalnya, iklan perlu diumumkan dengan cara yang berarti oleh pembaca layar. Bayangkan pengguna pembaca layar melakukan tab melalui kontrol yang dapat difokuskan: pada titik tertentu pembaca layar akan mengumumkan:
"Mobil"
"Manual"
tanpa konteks apa pun: apa yang dimaksud dengan "Otomatis" dan "Manual"?

Sebaliknya, tombol radio yang dikelompokkan dalam fieldset dengan legenda memberikan konteks karena legenda diumumkan.

Sebagai aturan umum, kontrol bentuk asli sudah menyediakan apa yang dibutuhkan untuk semantik dan aksesibilitas. Sebaliknya, kontrol kustom sering kali merusak semantik dan interaksi yang diharapkan.

Sangat penting bagi perancang dan pengembang untuk memahami bahwa saat menerapkan kontrol khusus, sangat berhati-hati untuk membangun kembali semua fitur dari kontrol asli yang setara.

Dalam hal ini, ini adalah satu pilihan di antara dua opsi. Tombol tidak sesuai. Tombol radio yang dikelompokkan dalam fieldset dengan legenda akan ideal. Sakelar bisa menjadi trade-off yang dapat diterima jika kita mengubah _ arti_ kontrol ini dari satu pilihan antara dua opsi menjadi tombol "on / off", yang sebanding dengan satu kotak centang (dengan semua peringatan yang dibahas panjang lebar tentang toggle dalam edisi sebelumnya).

Perihal: Desain material: Saya tidak yakin itu perlu menjadi sumber inspirasi untuk proyek seperti WordPress yang bertujuan agar dapat diakses semaksimal mungkin 🙂 Banyak pola Material sebagian besar terinspirasi oleh antarmuka pengguna seluler dan masih ada jalan panjang untuk mencari pola tersebut agar dapat diakses sepenuhnya.

Selain Kolom, saya menemukan kebutuhan akan opsi "stack-on-mobile" untuk blok Gambar. Situs web lawas tempat saya bermigrasi ke Wordpress Twenty Nineteen memiliki banyak gambar yang dibungkus teks dan mengambang di kiri dan kanan dengan lebar (dan harus tetap) 300px atau lebih. Dijatuhkan ke dalam blok Paragraf, blok Gambar ini berfungsi dengan baik di desktop, tetapi di sebagian besar layar seluler, blok ini menekan teks di sebelahnya hingga tidak terbaca. Untuk setiap gambar, saya harus menggunakan panel Lanjutan pada blok Gambar untuk menambahkan kelas CSS .isom (lebih cepat daripada mengetik "is-stacked-on-mobile"!) Yang memperluas gambar hingga 100% lebar untuk breakpoint Dua puluh Sembilan belas penggunaan. Saya pikir ini mungkin masalah umum bagi banyak pengguna, dan bukan hanya para migran (jika itu sebuah kata).

Sekadar saran, karena saya belum cukup paham dengan Gutenberg untuk menawarkan solusi.

Terima kasih atas umpan baliknya yang berkelanjutan, semuanya!

Satu hal yang saya tidak yakin adalah bagaimana lebar breakpoint didefinisikan. Apakah mereka disediakan oleh tema atau blok? Bisakah sebuah blok memilih hanya memiliki 2 breakpoint, bukan 3? Bagaimana dengan 4? Bagaimana dengan lebar breakpoint kustom? Apapun masalahnya, menurut saya editor tidak harus menyediakannya.

Secara umum, breakpoint akan ditentukan oleh pembuat blok. Saya mengobrol dengan @jasmussen tentang hal ini baru-baru ini, dan kami setuju bahwa masuk akal bagi Gutenberg untuk memberikan beberapa default untuk memulai (mungkin ini dipetakan ke breakpoint default yang digunakan Gutenberg ), tetapi kami harus memberikan opsi kepada penulis blok untuk memilih masuk atau keluar dari mereka, serta untuk menambahkan lebih banyak jika blok tertentu membutuhkannya.

Sepertinya orang-orang berkumpul di sekitar menggunakan kontrol toggle standar dalam kasus ini.

Saya telah melakukan sedikit pembersihan ringan pada comp @ZebulanStanphill di atas, menyesuaikan jarak dan hierarki tipe. Karena kami sudah menggunakan bobot teks untuk membedakan judul panel dari masing-masing label bidang, saya telah melakukan penyesuaian warna untuk masing-masing label perangkat. Abu-abu untuk itu adalah $dark-gray-300 , yang melewati AA.

Berikut mockup dan prototipe yang diperbarui:

🖥 Prototipe Desktop

📱 Prototipe Seluler

Saya juga telah maju dan mengejek beberapa kasus alternatif:

• Blok Galeri
• Contoh yang lebih rumit (saya pikir beberapa pelabelan di bagian paling bawah di sini dapat dikonsolidasikan.)

Untuk kepentingan memindahkan barang, inilah yang saya pikirkan:

1. Dapatkan umpan balik lain dari semua orang di utas. Saya ingin mendengar secara spesifik dari sudut pandang a11y: apakah ini tampak seperti solusi yang solid atau tidak.
2. Kumpulkan beberapa label alternatif . Label untuk bidang sakelar masih agak membingungkan. Kita harus menghasilkan beberapa opsi lagi dan kemudian:
3. Lakukan beberapa pengujian pelabelan oleh pengguna ringan untuk melihat mana yang menetapkan ekspektasi dengan benar untuk fungsi ini.

Tolong beri tahu saya pendapat apa pun tentang arah ini, dan tentang langkah-langkah selanjutnya!

@kjell

Karena kami sudah menggunakan bobot teks untuk membedakan judul panel dari masing-masing label bidang, saya telah melakukan penyesuaian warna untuk masing-masing label perangkat. Abu-abu untuk itu adalah $dark-gray-300 , yang melewati AA.

Secara pribadi, saya lebih suka abu-abu yang lebih gelap, agar aman. Labelnya tampak agak aneh karena berwarna terang.

Contoh yang lebih rumit (saya pikir beberapa pelabelan di bagian paling bawah di sini dapat dikonsolidasikan.)

Ya, tidak ada alasan untuk label di atas setiap sakelar. Ikon bisa saja diletakkan di sebelah tombol matikan sebelum label sakelar.

Juga, ini hanya sebuah nitpick, tetapi bukankah slider tersebut harus meregang jauh ke kiri, daripada terlihat menjorok dari label breakpoint?

Secara pribadi, saya lebih suka abu-abu yang lebih gelap, agar aman. Labelnya tampak agak aneh karena berwarna terang.

Menjadi sedikit lebih gelap tidak masalah. Saya tidak akan menjadi lebih gelap dari $dark-gray-500 meskipun (digambarkan di bawah), jika tidak abu-abu akhirnya terlihat sangat mirip dengan sisa teks.

Juga, ini hanya sebuah nitpick, tetapi bukankah slider tersebut harus meregang jauh ke kiri, daripada terlihat menjorok dari label breakpoint?

Saya menjorokkannya untuk menambahkan lebih banyak hierarki ke bidang. Jika setiap bidang memiliki lebar penuh, akan kurang jelas bahwa ini adalah bagian bawah label "Jumlah kolom".

@kjell

Saya menjorokkannya untuk menambahkan lebih banyak hierarki ke bidang. Jika setiap bidang memiliki lebar penuh, akan kurang jelas bahwa ini adalah bagian bawah label "Jumlah kolom".

Jika demikian, bukankah masuk akal untuk membuat indentasi label breakpoint juga?

Jika demikian, bukankah masuk akal untuk membuat indentasi label breakpoint juga?

Semacam itu, tapi kami biasanya tidak memasukkan sesuatu. Melakukannya di sini terlihat tidak disengaja / rusak bagi saya:

Berikut adalah comp dengan bidang lebar penuh juga, untuk perbandingan:

Seperti yang saya sebutkan di atas, hal itu menghilangkan beberapa hierarki visual dan tampaknya kurang dapat dipindai sekilas bagi saya. Mengindentasi bidang saja sepertinya merupakan kompromi yang baik:

Saya sangat suka tata letaknya dengan indentasi hanya pada bidang. Tampaknya ini untuk mengatasi masalah a11y, dan setuju untuk mendapatkan umpan balik di sana.

Perhatian saya satu-satunya adalah pada "contoh rumit" yang dibagikan. Di sinilah saya merasa desainnya tidak berfungsi dengan baik. Setelah ada dua hal yang membutuhkan kontrol responsif (mis. Kolom & jumlah produk), semua ikon dan label itu menjadi banyak bagi saya untuk diurai. Sisi baiknya, ini terstruktur dengan cukup baik sehingga saya masih bisa menguraikannya. 😉

Perhatian saya satu-satunya adalah pada "contoh rumit" yang dibagikan. Di sinilah saya merasa desainnya tidak berfungsi dengan baik. Setelah ada dua hal yang membutuhkan kontrol responsif (mis. Kolom & jumlah produk), semua ikon dan label itu menjadi banyak bagi saya untuk diurai.

Saya setuju sepenuhnya di sana. Pada ekspirasi sebelumnya yang tidak memiliki label, saya merasa ini sebagian besar masih dapat dicerna:

... tetapi versi baru cukup sulit dipindai ketika menjadi rumit. Salah satu cara yang mungkin untuk memperbaikinya adalah dengan mengadopsi ide-ide berikut:

• Rekomendasikan untuk menggabungkan beberapa kontrol di bawah bagian perangkat yang sama (seperti yang ditunjukkan di bagian Tata Letak di bawah).
• Hilangkan label perangkat jika label kontrol dapat menyatakan nama perangkat (seperti yang ditunjukkan di bagian Visibilitas di bawah).

Yang pertama membuat saya merasa nyaman. Tidak begitu yakin tentang yang kedua, karena saya pikir akan sulit untuk menerapkan praktik terbaik di sekitarnya.

Saya akan merekomendasikan untuk berpikir dalam istilah semantik terlebih dahulu, dan kemudian merancang semantik yang diperlukan.

Setiap masukan perlu diberi label dengan cara yang bermakna dan _unique_. Label teks tersebut akan menjadi <label> elemen yang terkait dengan slider dan bidang angka. Sebagai pengguna teknologi bantuan, bagaimana cara membedakan beberapa bidang yang semuanya berlabel teks yang sama?

Sebagai contoh:

• sebagai pengguna pembaca layar, mengarahkan tab ke berbagai bidang angka, saya akan mendengar "Jumlah kolom" untuk beberapa bidang tanpa petunjuk apa yang mereka maksud (desktop, seluler?)
• sebagai pengguna masukan ucapan, menyuarakan perintah "Klik Jumlah kolom" akan membingungkan perangkat lunak pengenalan suara yang saya gunakan, karena tidak dapat membedakan antara bidang dengan nama yang sama

Ada beberapa solusi yang dapat digunakan pengguna tetapi memaksa mereka untuk menjelajahi apa yang ada di sekitar bidang atau menggunakan metode alternatif untuk menavigasi konten kurang dari ideal.

Semua label ini perlu memberikan konteks yang lebih baik dan harus unik untuk setiap bidang.

Antarmuka ini rumit, saya sarankan untuk mencari cara untuk menyederhanakannya secara radikal. Sebagai contoh:

• Saya tidak yakin apa nilai yang ditambahkan oleh slider, selain "kecantikan": sulit digunakan bahkan dengan mouse, memakan banyak ruang, dan sudah ada kolom masukan
• tidak yakin ikon perangkat benar-benar diperlukan: menghapusnya dapat menghemat ruang

Senang melihat tombol "Otomatis" dan "Manual" hilang di prototipe terakhir dan telah diganti dengan sakelar (meskipun sakelar memiliki masalah sendiri). Terima kasih.

Jadi pengaturan Visibilitas adalah menyembunyikan seluruh blok untuk perangkat tertentu? Apakah ini akan ditambahkan sebagai opsi untuk setiap blok? Tombol, Paragraf, Pemisah, dll?

Secara pribadi saya bukan penggemar latihan, tetapi saya kira masih ada kasus penggunaan yang tidak dapat menyiasatinya.
Apakah ada cukup kasus penggunaan? Atau apakah kita berasumsi bahwa pembuat halaman lain melakukannya sehingga harus dibutuhkan?

Jadi pengaturan Visibilitas adalah menyembunyikan seluruh blok untuk perangkat tertentu? Apakah ini akan ditambahkan sebagai opsi untuk setiap blok? Tombol, Paragraf, Pemisah, dll?

Oh, maaf atas kebingungannya: Itu hanya contoh uji stres pola ini untuk keadaan yang berbeda (ini diangkat dalam konteks pencekalan Produk pihak ketiga di atas ). Kami tidak akan menambahkannya ke blok inti apa pun.

Terima kasih atas masukannya, @afercia! Saya menghargai tanggapan Anda di sini.

Sebagai pengguna teknologi bantuan, bagaimana cara membedakan beberapa bidang yang semuanya berlabel teks yang sama?

Pikir saya adalah bahwa header induk untuk masing-masing bagian tersebut (Desktop, Tablet, Seluler, dll) akan menjadi kunci untuk membedakannya, tetapi saya telah mengantisipasi hal itu dari perspektif seseorang yang melihat melalui kontrol. Jika seseorang menggunakan sulih suara (misalnya) dan mengetuk langsung ke salah satu kontrol anak, saya dapat melihat bagaimana itu akan membingungkan.

Kedengarannya kami akan mendapatkan pelayanan terbaik dengan membuat setiap label berbeda dan jelas. Saya tidak tahu bahwa ini adalah solusi yang tepat, tetapi untuk tujuan ilustrasi, apakah sesuatu seperti ini yang Anda sarankan dari perspektif label?

• Saya tidak yakin apa nilai yang ditambahkan oleh slider, selain "kecantikan": sulit digunakan bahkan dengan mouse, memakan banyak ruang, dan sudah ada kolom masukan

Dalam hal ini, kami hanya menggunakan kembali kontrol slider yang digunakan pada status default blok. Jika kita akan menghapus slider, saya membayangkan kita ingin melakukannya untuk pengaturan responsif "Otomatis" dan untuk pengaturan manual per perangkat. Tapi sepertinya ini adalah awal dari diskusi yang lebih besar seputar kegunaan slider secara umum, dan saya tidak yakin tiket ini adalah tempat yang tepat untuk membahasnya.

Bagaimanapun - ini dimaksudkan untuk mulai menentukan pola yang dapat digunakan kembali untuk pengaturan blok responsif, jadi meskipun menghapus slider dapat membantu kami dalam kasus ini, ada kemungkinan situasi lain di mana slider masih akan digunakan.

• tidak yakin ikon perangkat benar-benar diperlukan: menghapusnya dapat menghemat ruang

Saya lebih suka menyimpan ikon, karena menurut saya itu adalah titik referensi visual yang berguna. Terutama dengan bidang indentasi di comps terbaru saya, ikon menonjol sebagai penanda visual cepat di lautan teks dan kontrol. Manfaat ini akan semakin diperkuat jika kita akhirnya menambahkan lebih banyak teks ke label.

@ercia

Saya akan merekomendasikan untuk berpikir dalam istilah semantik terlebih dahulu, dan kemudian merancang semantik yang diperlukan.

Jika HTML ditulis sesuai menggunakan fieldset , legend dan seterusnya, apakah tata letak @kjell akan berfungsi dengan

Kedengarannya kami akan mendapatkan pelayanan terbaik dengan membuat setiap label berbeda dan jelas.

@kjellr yes :) Saya akan mempertimbangkan untuk memiliki setiap label yang memberikan konteks seperti pada contoh Anda. Itu lebih sederhana dan lebih bisa dimengerti. Mungkin kata-kata yang sedikit lebih pendek bisa membantu. Misalnya, apakah "Jumlah" benar-benar dibutuhkan? Saya akan mengatakan juga secara visual ada banyak yang harus diproses dan mungkin menyederhanakan hal-hal mungkin sedikit membantu.

@mapk ya, saya sudah mempertimbangkan itu. fieldset dan legend adalah cara yang tepat untuk mengelompokkan satu set kontrol dan memberi nama untuk grup tersebut. Ini masalah dukungan yang sebenarnya, dan perlu diuji. Ini bekerja cukup baik dengan grup tombol radio atau kotak centang. Saya tidak tahu apakah ini berfungsi dengan baik dengan input range dan number .

Komponen RangeControl memiliki satu masalah lagi: nilai label yang sama digunakan untuk input range dan nomor. Dengan demikian, rentang dan masukan angka memiliki nama yang dapat diakses yang sama. Tidak ideal. Akan mengusulkan untuk berdiskusi nanti hari ini selama pertemuan tim aksesibilitas (semua orang dipersilakan untuk bergabung).

nilai label yang sama digunakan untuk rentang dan masukan nomor

Saya berharap untuk mengubahnya dengan https://github.com/WordPress/gutenberg/pull/13863 @afercia

Terima kasih @meh! Saya segera berkomentar di sana.

@kjellr yes :) Saya akan mempertimbangkan untuk memiliki setiap label yang memberikan konteks seperti pada contoh Anda. Itu lebih sederhana dan lebih bisa dimengerti. Mungkin kata-kata yang sedikit lebih pendek bisa membantu. Misalnya, apakah "Jumlah" benar-benar dibutuhkan? Saya akan mengatakan juga secara visual ada banyak yang harus diproses dan mungkin menyederhanakan hal-hal mungkin sedikit membantu.

Terima kasih, @afercia. Inilah mockupnya:

Bagian "Kolom di" pada label bidang tampak sedikit berulang setelah label "Jumlah Kolom" bagi saya. Tapi saya pikir itu bisa diterapkan.

ya, saya sudah mempertimbangkan itu. fieldset dan legend adalah cara yang tepat untuk mengelompokkan satu set kontrol dan memberi nama untuk grup tersebut. Ini masalah dukungan yang sebenarnya, dan perlu diuji. Ini bekerja cukup baik dengan grup tombol radio atau kotak centang. Saya tidak tahu apakah ini berfungsi dengan baik dengan input range dan number .

Bagaimana kita bisa memverifikasi apakah itu bekerja dengan input range dan number ? Jika masalah pelabelan ini sudah dibahas dengan cara ini, saya lebih suka menjaga label bidang individual lebih ringkas.

Saya pikir bagian "Kolom", "Item", dll. Berguna dengan jenis perangkat di setiap label kolom, seperti yang Anda miliki di mock-up terbaru.
Selain skenario sulih suara yang Anda sebutkan sebelumnya, saya dapat membayangkan akan lebih mudah jika, misalnya, saya menggunakan ponsel lanskap dan judul induk tidak terlihat.

Selain itu, nama jenis perangkat akan menjadi tunggal atau semua jamak. Aku tahu itu tiruan. Just sayin: smiley:

Selain itu, nama jenis perangkat akan menjadi tunggal atau semua jamak. Aku tahu itu tiruan. Katakan saja 😃

Diperbarui di atas.

Bagaimana dengan back-end dari ide yang sangat menarik ini? Adakah yang punya pendekatan untuk mengatasinya? Akankah ada sesuatu seperti objek atau bahkan beberapa properti individu yang menyimpan semua nilai yang dibutuhkan?

Sehubungan dengan maket terakhir, @kjellr , judul akordeon "Kolom" tampaknya berlebihan dengan judul "Jumlah kolom" dan pembacaan lanjutan "kolom di desktop" atau "kolom di tablet" dll. Kata "kolom" banyak muncul.

Apakah kebutuhan a11y masih akan terpenuhi jika heading "Jumlah kolom" adalah legend dalam fieldset ? Maka itu seharusnya menunjukkan bahwa item yang dikelompokkan dalam fieldset itu semuanya berhubungan kembali dengan "Jumlah kolom" kan? Jadi label masukan bisa saja berupa "Desktop", "Tablet", dan "Seluler".

Fieldset dan legenda: seperti yang dikomentari sebelumnya, itu perlu diuji:

@mapk ya, saya sudah mempertimbangkan itu. fieldset dan legenda adalah cara yang tepat untuk mengelompokkan sekumpulan kontrol dan memberi nama untuk grup tersebut. Ini masalah dukungan yang sebenarnya, dan perlu diuji. Ini bekerja cukup baik dengan grup tombol radio atau kotak centang. Saya tidak tahu apakah ini berfungsi dengan baik dengan input jangkauan dan angka.

Berdasarkan komentar saya di atas, mungkin seperti di bawah ini? Saya juga menyertakan markup. @kjellr , bagaimana menurut anda?

@mapk Slider mungkin harus dihilangkan karena mereka tidak terlalu berguna dalam konteks kontrol kasar seperti jumlah kolom.

Aku juga memikirkan hal yang sama seperti @ZebulanStanphill

Input rentang berfungsi dengan baik untuk hal-hal seperti kontrol volume atau dalam opasitas hamparan gambar kami tempat Anda mendapatkan gambaran tentang hasilnya hanya dengan melihat penggeser. _25%, 50%, 100% _

Dari dokumen MDN

Karena jenis widget ini tidak tepat, biasanya widget ini tidak boleh digunakan kecuali nilai pasti dari kontrol tersebut tidak penting.

Saya kira tanda centang mungkin membuatnya lebih berguna tetapi tetap saja, mengapa menawarkan 2 metode untuk menyesuaikan kolom?

Jika hanya menggunakan input angka, Anda akan mengosongkan beberapa ruang untuk menggunakan input dan label dalam konteks.

[4] columns on desktops
[2] columns on tablets
[1] column on mobile devices

Halo semua! Berkenaan dengan visibilitas responsif, saya memiliki fitur ini di plugin EditorsKit saya (sebelumnya Block Options). Berikut cara kerja fitur:

https://www.youtube.com/watch?v=1VuBXAUqTjA

Semoga Anda menyukainya! Bersulang!

Terima kasih @phpbits! Saya menghargai penjelajahan Anda di sana, namun menurut saya status "aktif / nonaktif" terlalu sulit untuk dilihat dalam kasus ini. Sesuatu seperti kontrol sakelar atau kotak centang dalam kasus itu mungkin bekerja lebih baik?

Penggeser mungkin harus dihapus karena tidak terlalu berguna dalam konteks kontrol kasar seperti jumlah kolom.

Terima kasih @ZebulanStanphill. @afercia juga menyebutkan hal ini di atas. Saya terbuka untuk iterasi desain lain yang mengeksplorasi ini. @kjellr ada pemikiran?

Juga mari kita dapatkan desain masa lalu ini dan mulai dengan PR untuk itu. Saya pikir kami dapat menguji plugin lebih baik dengan pengguna sebenarnya.

Terima kasih @phpbits! Saya menghargai penjelajahan Anda di sana, namun menurut saya status "aktif / nonaktif" terlalu sulit untuk dilihat dalam kasus ini. Sesuatu seperti kontrol sakelar atau kotak centang dalam kasus itu mungkin bekerja lebih baik?

@mapk Saya memikirkannya juga, tetapi itu membutuhkan banyak ruang dan memiliki kotak centang ini di bawah blok dengan banyak opsi tidak terasa begitu baik. Saya memiliki kotak centang itu pada versi sebelumnya. Tapi saya pikir Anda akan melakukannya lebih baik daripada yang saya lakukan, meminta tim desain dan pemeriksaan aksesibilitas. Saya hanya akan berkontribusi pada apa pun yang saya bisa :) Terima kasih!

Saya pikir input jangkauannya bagus karena memberikan indikasi visual yang jelas (er) dari nilai min / max.

Penggeser mungkin harus dihapus karena tidak terlalu berguna dalam konteks kontrol kasar seperti jumlah kolom.

Terima kasih @ZebulanStanphill. @afercia juga menyebutkan hal ini di atas. Saya terbuka untuk iterasi desain lain yang mengeksplorasi ini. @kjellr ada pemikiran?

Ini pasti bisa diubah, tapi saya tidak yakin itu juga perlu dilakukan di sini di tiket ini, karena slider itu ada apakah kontrol responsif menjadi kenyataan atau tidak. Ada tiket lain yang fokus pada eksplorasi / audit slider . Sementara itu, menurut saya masuk akal untuk hanya memfokuskan utas ini untuk mendapatkan solusi kontrol responsif yang bekerja dengan slider dan tanpa, sehingga dapat meluas lebih dari sekadar blok kolom.

Saya membaca hampir semua komentar di sini, tetapi ada yang berpikir tentang menggunakan visibilitas perangkat sebagai fungsi untuk tidak memuat konten di front-end dan tidak hanya menggunakan display:none , karena saya selalu mendapatkan beberapa desainer gila yang menginginkan untuk menyembunyikan banyak gambar di ponsel depan tetapi tidak masalah jika gambar masih dimuat ... jadi saya membuat barang-barang ACF untuk mencegahnya ...

Dalam konteks menyesuaikan kolom, saya pribadi menemukan slider yang bagus untuk digunakan, karena mereka memungkinkan saya untuk mengklik / menyeret dan dengan cepat melihat semua hasil dari semua nilai untuk pengaturan itu. Ini didasarkan pada pengalaman sebelumnya dengan kontrol serupa - jelas yang ini belum dibuat. Jika pengaturannya hanya bidang masukan, akan membosankan bagi saya untuk mengedit dan mengevaluasi setiap nilai yang mungkin. Untuk setiap nilai, saya harus mengklik input, backspace , ketik angka, lihat hasil di editor, dan ulangi.

Manfaat lain adalah bahwa dengan slider, jika dirancang dengan baik (ibu jari besar, tanda centang, dll.), Mereka dapat secara visual mengkomunikasikan nilai min / maks relatif.

Saya memahami bahwa saya adalah pengguna mouse, dan untuk pengguna lain, penggeser mungkin juga tidak ideal. Saya berharap kami dapat menemukan keseimbangan yang berfungsi untuk sebanyak mungkin pengguna.

Saya sekarang telah menggabungkan:

• ResponsiveBlockControl komponen
• DimensionControl komponen

Ini meletakkan dasar untuk mengaktifkan kontrol khusus area pandang untuk atribut Blok tertentu seperti padding .

Pada # 19909 saya menggunakan pendekatan alternatif untuk pengeditan responsif, yang berfokus pada kemungkinan membuat setiap blok yang ada dapat membuat perubahan responsif, tanpa kode tambahan.

Hand-in-glove dengan penyesuaian lebar kolom di ponsel akan menjadi urutan kolom di ponsel.

Misalnya, pada layar penuh saya menetapkan kolom 1-2-3-4-5. Saat ini mengonversi secara responsif, saya mungkin ingin mereka muncul 5, 4, 3, 2, 1.
atau 5-3, 1 (* jangan tampilkan 2, 4).

Kontrol kolom individual _on Responsive_:

1. Alihkan tampilkan / sembunyikan
2. Kontrol lebar
3. Kotak drop-down untuk mengatur ulang

Untuk apa nilainya - ini adalah iterasi terbaru dari kontrol gaya kustom, pertama untuk satu blok dan kemudian untuk blok kolom kustom

SUKA!!!!!!!!!!!!!!

Kapan? KAPAN?!

Terima kasih telah membagikannya! Saya dipompa !!!!!

Inilah yang saya kembangkan untuk kontrol responsif blok kustom saya sendiri:

@mattbolt adalah iterasi tata letak apakah sebenarnya sedang dikembangkan saat ini? Jika yang terakhir, saya ingin tahu bagaimana Anda menyortir hambatan kueri media.

Ini adalah iterasi visual kedua kami untuk alat ini. Asli yang kami kembangkan di rumah tepat setelah Wordpress 5 dirilis akhir 2018 dan telah digunakan produksi sejak Januari 2019 di beberapa situs, tetapi terutama www.minderoo.org .

Adapun untuk kueri media, semua blok kami didukung oleh komponen render sisi server. Sebelum kita memanggil $content = apply_filters('the_content', $post->post_content); kita menghapus semua gaya terdaftar saat ini. Kemudian selama proses render, setiap blok mendaftarkan gaya yang diterapkan secara unik dan menerima id unik yang disertakan dalam kelas css blok.

Setelah memanggil the_content , kita "membuat" gaya unik ke variabel. Ini adalah panggilan fungsi yang menghasilkan css 'media queried' dan memasukkannya ke dalam file

Itu tadi penjelasan yang sangat lengkap, @mattbolt Terima kasih telah meluangkan waktu untuk menjelaskannya kepada saya :) Kedengarannya sedikit di luar kemampuan saya, tetapi akan menarik untuk melihatnya lebih dekat dan melihat apa yang ada di balik terpal.

Sekali lagi terima kasih, Matt :)

Ini adalah blok tombol. Lihat semua ruang kosong di sekitarnya - terutama di atas dan di bawah.

Margin auto / 0 untuk elemen blok akan diterjemahkan ke dalam keselarasan.
Misalnya ´margin-left: auto; margin-right: 0; `akan mendorong elemen blok ke sisi kanan.
Bagaimana opsi perataan blok (sebagai kiri / kanan) direkonsiliasi dengan perataan khusus margin?

Mengambil langkah mundur, 2c saya:
Saya menemukan perbedaan keseluruhan Desktop / Tablet / Seluler agak sewenang-wenang dan tidak terbukti di masa depan ... Jika sejarah telah mengajari kita apa pun adalah bahwa perangkat berubah dengan cepat, dan apa yang kita anggap hari ini sebagai norma, paling cepat berlalu.

Mengapa tidak smartwatch, smart-TV, kacamata, atau perangkat lain apa pun yang memiliki akses ke web? Apa yang dimaksud dengan desktop? Apa yang membedakan laptop 12 inci dari tablet 13 inci? Karena jika kita berbicara tentang resolusi layar, ponsel 7 inci bisa memiliki resolusi yang lebih besar daripada TV 50 inci.
Dan mengapa 2 breakpoint (seluler / tablet, tablet / desktop) dan bukan hanya 1 (kecil / besar)?

Alih-alih membangun sesuatu yang berusaha untuk menjadi pixel-perfect, haruskah kita mungkin sedikit mengubah perspektif dan mencoba membangun sesuatu yang pixel-agnostic?

Alih-alih memiliki breakpoint yang berubah-ubah, haruskah kita mencoba mendeteksi ketika konten di dalam kolom misalnya berhenti dapat dibaca, dan menciutkannya menjadi sesuatu yang masuk akal?

Meskipun maket yang ditampilkan di # 19909 sudah sangat usang, tujuan utama tiket tersebut adalah menjelajahi antarmuka _global dan extensible_ untuk pengeditan breakpoint responsif. Yang, jika dilakukan dengan benar, memungkinkan kami menghindari situasi di mana Anda mengedit properti seluler dari blok kolom di editor yang terlihat seperti breakpoint desktop. Sebaliknya, dengan membuat koneksi antara mode tampilan editor dan properti responsif, kita dapat melakukan invers, memungkinkan pengeditan breakpoint desktop bahkan saat menggunakan perangkat seluler, sambil menampilkan representasi visual yang lebih baik dari setiap breakpoint responsif.