Ide menarik @melchoyce.

Reaksi pertama saya adalah bagaimana dengan memindahkannya ke bawah membuat blok lebih 'kuning' - yang merupakan hal yang aneh untuk dikatakan tetapi sesuatu yang membuat saya merasa. Apakah batas muncul saat diklik atau di-hover? Saya rasa masalah saya saat diklik lebih sedikit daripada saat saya mengarahkan kursor. Visual menarik lainnya ini membuat setidaknya contoh Anda terlihat seperti gambar Polaroid, sangat menarik bagaimana otak saya pergi ke sana.

Itu adalah reaksi pertama saya, menggali lebih banyak lagi, saya pikir ada gunanya menjelajahi posisi berbeda untuk ikon interaksi pada sebuah blok. Saya pikir apa yang diperolehnya adalah cara yang bekerja lebih baik di semua layar, yang harus kita pegang sebagai panduan saat eksplorasi lebih lanjut terjadi.

Saya pikir kami kehilangan beberapa konteks dari interaksi. Misalnya, blok dengan placeholder yang lebih tinggi akan membuat interaksi tersebut tidak langsung terlihat. Saya merasa itu akan menjadi halangan yang bisa menambah kurang dapat ditemukannya.

Semua ini mengatakan, saya sama sekali tidak mengatakan apa yang kita miliki sekarang harus menjadi jalan ke depan. Apakah Anda siap untuk mengulang dan mungkin menjelajahi lebih banyak? Saya sangat berharap Anda.

Saya pikir secara visual ini bagus. Ini pada dasarnya adalah UI seluler, di breakpoint desktop, dan itu adalah sesuatu yang saya anggap sebagai rencana B jika UI samping tidak berfungsi, atau mungkin untuk konteks bersarang.

Sejak itu kami berdua membuat kemajuan dengan UI samping, yang terbaru di https://github.com/WordPress/gutenberg/pull/6141 , dan kami juga membuatnya berfungsi dengan baik dalam konteks bersarang, meskipun itu Aspek masih membutuhkan cinta.

Meskipun tidak secantik itu, manfaat utama memiliki UI ini adalah,

1. agar mereka dapat muncul saat mengarahkan kursor
2. mereka tidak memperluas jejak blok

1 sangat penting, karena sejak awal sudah menjadi tujuan eksplisit untuk memastikan seret dan lepas adalah _additive_, dan bukan bentuk interaksi utama dengan penempatan, penyusunan ulang, dan pengurutan blok. Jika kita menempatkannya di bawah blok, mungkin mereka akan muncul saat diklik, yang akan membuatnya menjadi yang kedua untuk drag and drop yang akan selalu berfungsi saat hover.

2 bisa jadi penting bergantung pada cara kita menangani UI samping dalam konteks bersarang. Saat ini kami menghadapi beberapa tantangan di https://github.com/WordPress/gutenberg/pull/5452#issuecomment -380721863, dan meskipun saya yakin kami akan dapat menyelesaikannya, fakta bahwa jejak tidak Perubahan tidak membantu.

Semua ini bukan untuk mengatakan "tidak bisa bekerja" - itu bisa berhasil dengan baik. Mockup lama waaaay memiliki UI ini sebagai overlay di sudut:

Jadi secara keseluruhan, ide-ide bagus, dan bagus untuk menyimpannya di mie sebagai jalan yang dapat dieksplorasi tergantung pada umpan balik yang kami terima rilis untuk dirilis!

Apakah batas muncul saat diklik atau di-hover?

Cukup di klik. Hover akan serupa dengan cara kerjanya sekarang.

Apakah Anda siap untuk mengulang dan mungkin menjelajahi lebih banyak? Saya sangat berharap Anda.

Selalu 👍

mereka tidak memperluas jejak blok

Ya, pasti ada masalah dengan ide ini. Bahkan dalam prototipe ini Anda dapat melihat beberapa orang melompat-lompat karena perubahan ukuran.

Jadi secara keseluruhan, ide-ide bagus, dan bagus untuk menyimpannya di mie sebagai jalan yang dapat dieksplorasi tergantung pada umpan balik yang kami terima rilis untuk dirilis!

👍 👍

Saya pikir kami kehilangan beberapa konteks dari interaksi. Misalnya, blok dengan placeholder yang lebih tinggi akan membuat interaksi tersebut tidak langsung terlihat. Saya merasa itu akan menjadi halangan yang bisa menambah kurang dapat ditemukannya.

Meskipun tidak secantik itu, manfaat utama memiliki UI ini adalah,

1. agar mereka dapat muncul saat mengarahkan kursor
2. mereka tidak memperluas jejak blok

Saya pikir salah satu cara untuk menyelesaikan masalah ini adalah dengan memiliki toolbar alat blok muncul di atas blok di bawah dan tidak menambah ruang yang sebenarnya digunakan blok di editor. Sedangkan untuk kemudahan ditemukan dengan blok tinggi, bilah alat dapat dibuat lengket sehingga jika Anda menggulir ke atas, bilah alat tidak keluar dari layar. (Ini masih menghilang saat tidak melayang di atas blok, tentu saja, dan mungkin hanya bisa muncul saat mengarahkan bagian bawah blok yang saat ini terlihat, mirip dengan cara kerja kontrol samping saat ini.) Itu juga bisa mengambil sebagai banyak ruang yang diperlukan untuk menampilkan semua tombol, dan tidak menggunakan seluruh baris ruang kosong di antara 2 set kontrol seperti yang terjadi di mockup di posting utama masalah ini.

+1 Hanya untuk dicatat bahwa ini juga dapat membantu meningkatkan urutan tab dari kontrol UI di sekitar blok. Seperti disebutkan di https://github.com/WordPress/gutenberg/issues/5694#issuecomment -386645531, UI seluler memiliki "kontrol samping" yang ditempatkan dengan cara yang lebih logis. Lihat animasi GIF yang menggambarkan urutan tab, Anda bisa membandingkan dengan GIF sebelumnya dengan urutan tab di tampilan desktop di komentar sebelumnya https://github.com/WordPress/gutenberg/issues/5694#issuecomment -384619052

Juga untuk dipertimbangkan:

3976 mengusulkan opsi ketiga untuk menempatkan toolbar blok (toolbar format) di bawah blok; akan sangat bagus untuk mempertimbangkan desain dengan kedua toolbar blok _dan_ kontrol samping ditempatkan di bawah blok untuk melihat apakah itu bisa bekerja.

1934 sebagai masalah umum tentang konsistensi urutan tab

Hal ini juga dapat berdampak pada penyelesaian beberapa masalah yang diangkat di # 6272.

Sedangkan untuk kemudahan ditemukan dengan blok tinggi, bilah alat dapat dibuat lengket sehingga jika Anda menggulir ke atas, bilah alat tidak keluar dari layar.

Ya, itulah yang terjadi dengan bilah alat pemformatan atas juga:

Membaca semua umpan balik yang luar biasa di sini tampaknya ini menyelesaikan sejumlah masalah ke depan dan hari ini dengan aksesibilitas. Dalam pikiran, saya pikir kita harus mengerjakan beberapa iterasi di sini dan kemudian pindah ke PR ke prototipe. Apakah Anda siap melakukan itu @melchoyce?

Ya, saya bisa melihat lagi.

+10 untuk mencoba ini.

Seperti inilah tampilan blok UI ketika saya mengecilkan lebar jendela browser saya. (Jika saya menyusutkannya lagi, bilah alat blok bergerak di bawah blok, tetapi itu tidak relevan dengan apa yang saya sarankan.)

Saya perhatikan bahwa penyisip blok muncul di sebelah kontrol gerakan atas / bawah. Jika jenis UI ini digunakan untuk semua ukuran layar seperti yang diusulkan oleh masalah ini, mungkin appender blok saat ini dapat dihapus dari konteks blok bersarang, membuat editor terlihat lebih seperti front-end dengan menghapus ruang ekstra yang selalu ada yang ditambahkan oleh setiap penambah blok untuk setiap tingkat bersarang. (Saya juga menyarankan solusi alternatif untuk masalah appender-makan-ruang-ruang di # 6834.)

Juga, ini hanya catatan tambahan, tetapi apakah tombol Hapus seharusnya berada di sebelah kanan tombol Opsi Lainnya , atau haruskah di sebelah kiri? Di sebagian besar desain UI, menu elipsis ditempatkan di paling kanan.

Ide lain:

Tunjukkan kontrol blok ini di bagian bawah saat mengarahkan kursor, tetapi dalam keadaan ini, kontrol tersebut tidak mengambil ruang apa pun di halaman, dan malah muncul di atas apa pun yang ada di bawah blok yang di-hover (seperti yang dilakukan toolbar blok untuk blok di atas arus satu) atau mungkin di atas blok yang di-hover. Kontrol blok di bagian bawah juga tidak boleh berupa bilah putih tanpa gangguan saat melayang, tetapi 2 bilah yang lebih kecil di setiap sisi, mirip dengan bilah alat blok, agar kontrol mengambil lebih sedikit ruang dan tidak menutupi sebanyak mungkin.

Saat Anda memilih sebuah blok, kontrol blok di bagian bawah akan mengambil ruang, meningkatkan jejak visual dari blok dan mendorong blok di bawahnya keluar dari jalan, seperti bagaimana ketika Anda memilih sebuah blok gambar, placeholder teks muncul. Ini akan membuatnya lebih mudah untuk memilih blok di bawah ini jika itu adalah blok pendek vertikal seperti blok Paragraf satu baris.

Pendekatan ini akan memungkinkan Anda untuk mempertahankan manfaat dari kontrol on-hover saat ini yang memungkinkan Anda untuk dengan mudah memindahkan / menghapus blok tanpa terlebih dahulu memilihnya, sementara juga memastikan bahwa kontrol tidak menutupi apa pun saat blok sedang diedit, membuatnya lebih mudah untuk kemudian memilih blok yang berbeda.

Satu gagasan lagi:

Izinkan seluruh bilah kontrol blok (dan bilah alat blok) untuk berfungsi ganda sebagai pegangan seret (termasuk tombol, seperti cara kerja bilah tajuk GTK). Saya pikir ini akan cukup banyak menyelesaikan masalah drag-and-drop yang dapat ditemukan, terutama dalam konteks blok yang dipilih, di mana bilah kontrol bawah terlihat seperti itu adalah bagian dari blok di mockup di posting awal, dan oleh karena itu pengguna mungkin akan lebih cenderung berpikir untuk mencoba menggunakannya sebagai tuas seret.

Kontras dengan situasi saat ini di mana sisi blok tidak terlihat seperti bagian dari blok, dan oleh karena itu tidak terlalu jelas bahwa mereka dapat bertindak sebagai pegangan seret, dan ada juga masalah di mana blok Paragraf baris tunggal hampir tidak memiliki ruang kosong di sisinya untuk diseret. (Dan karena tombol kontrol samping saat ini tidak dapat digunakan sebagai pegangan seret kecuali jika dinonaktifkan, masalahnya menjadi lebih buruk.)

Banyak sekali diskusi luar biasa seputar ini, mari kita lihat apakah saya dapat memberikan umpan balik ringkasan untuk semoga memberi Anda sesuatu untuk beralih ke iterasi dengan @melchoyce.

Secara keseluruhan saya pikir saya perlu merasakan ini dalam sebuah prototipe dan banyak pemikiran saya yang saya pikir bisa dimudahkan dengan itu. Namun ada beberapa pertimbangan yang ingin saya buat menjadi tiruan:

• Solusi untuk balok tinggi.
• Perasaan yang kurang 'kuning': ini mungkin hanya menampilkan status placeholder dalam tiruan, saya membacanya sebagai lebih jelas dengan perubahan ini.
• Menunjukkan cara kerjanya dengan bersarang.

Saya ingin melihat bagaimana ini juga beradaptasi dengan perangkat yang berbeda, menurut saya variasi yang ada lebih sedikit dan itu bisa menjadi hal yang hebat.

@SuperGeniusZeb beberapa pemikiran menarik yang Anda miliki di sana. Saya ingin melihat di mana Mel mendapatkan iterasi di atas. Saya pikir menggandakan UI untuk menyeret pegangan adalah sesuatu yang harus dihindari untuk saat ini, ada perubahan bersarang yang sedang dikerjakan, saya ingin masuk ke sana. Saya tidak mengatakan kami tidak akan mengulang, tetapi UI ini tidak khusus untuk itu. Saya juga berpikir Anda dapat menyimpulkan rasa memiliki tanpa menjadi eksplisit secara visual dan di mana itu menjadi terlalu eksplisit di mana perasaan negatif dari blok masuk - terasa dekat dan terlalu membatasi.

Saya mencari-cari di # 7211 dan dalam konteks pekerjaan itu saya menemukan # 7646, dan itu membawa saya kembali ke gagasan ini, yang benar-benar terasa seperti solusi terbaik untuk sekumpulan masalah.

Tiket ini akan, secara langsung atau tidak langsung, memperbaiki banyak hal:

• # 7646 → dengan kontrol yang ditempatkan di atas / bawah, Anda tidak perlu khawatir tentang mengakomodasi UI samping
• # 7182 → kontrol seperti yang ada di mockup pada tiket ini terhubung langsung ke blok dan akan memiliki UI yang konsisten terlepas dari level bersarang
• # 6451 → jika bilah alat atas / bawah memiliki latar belakang yang kuat, Anda tidak perlu khawatir tentang cara membuat kontrol terlihat pada latar belakang gelap
• # 7114 / # 6265 → Jika Anda menggunakan toolbar lebar penuh seperti pada beberapa maket di atas, Anda dapat menggunakan area kosong untuk menyeret / menjatuhkan

Semua ini untuk mengatakan bahwa, jika masih ada peluang perubahan sebesar ini bisa mendarat di Gutenberg, saya pikir itu bisa menyelesaikan banyak masalah dan membuat banyak hal lebih mudah :) Saya akan bergabung dalam kesenangan dan bekerja beberapa maket / konsep semoga akhir pekan ini.

@chrisvanpatten hanya untuk menambah perspektif masalah ini adalah tentang kontrol bukan toolbar yang dipindahkan ke bawah. Itu akan menyebabkan lebih banyak masalah kegunaan. Hanya memeriksa karena beberapa masalah yang Anda tautkan tampaknya berada di sekitar bilah alat.

Saya akan sangat mendukung untuk mencoba ini, karena ini meningkatkan banyak urutan tab. Pembaruan cepat: tombol hapus "sampah" telah dipindahkan dalam menu elipsis. Saya juga menyarankan untuk mencoba memenuhi prinsip kedekatan kontrol dan menempatkan tombol elipsis segera di sebelah kanan penggerak. Tidak yakin mengapa harus berada jauh ke kanan:

@afercia karena mereka adalah kontrol yang berbeda Saya pikir memiliki elipsis di sebelah kanan masuk akal. Mari kita telusuri itu sebagai langkah pertama. Kita perlu fokus untuk mengeksplorasi hal-hal berikut:

Solusi untuk balok tinggi.
Perasaan yang kurang 'kuning': ini mungkin hanya menampilkan status placeholder dalam tiruan, saya membacanya sebagai lebih jelas dengan perubahan ini.
Menunjukkan cara kerjanya dengan bersarang.

Titik-titik ini perlu dijelajahi untuk menentukan rute dari titik yang menjanjikan ini.

@Karmatosed Saya menggunakan istilah yang membingungkan - maksud saya kontrol, bukan toolbar. Bilah alat sudah di atas - tidak ada yang perlu diubah di sana :)

Saya baru saja membuat beberapa mockup dari apa yang saya bayangkan akan terlihat seperti alat blok jika diletakkan di bawah blok. Perhatikan bahwa dalam maket ini, alat blok tidak pernah memakan ruang apa pun, hanya bertindak sebagai hamparan seperti bilah alat blok di desktop. Blok juga dipilih di maket ini. Jika hanya melayang di atas satu blok, bilah alat blok di atas tidak akan ditampilkan. Juga perlu diingat bahwa kontrol bawah masih hanya dapat muncul saat melayang di dekatnya seperti kontrol samping saat ini.

Normal:

Saat bagian bawah blok di luar layar:

(Catatan tambahan: bilah alat blok Gambar tidak cocok dengan yang ada di maket ini karena memiliki opsi berbeda di bilah alat bloknya.)

Mengingat masalah dengan alat blok yang berada di samping dan beberapa manfaat memiliki alat blok di bagian bawah, saya sekarang yakin bahwa memiliki alat blok di bagian bawah adalah cara yang harus dilakukan.

@SuperGeniusZeb Pada dasarnya itulah yang saya pikirkan kecuali saya akan memposisikan lebih banyak tombol opsi dengan panah atas / bawah daripada ke kanan, sebagai bilah alat gabungan.

@chrisvanpatten Ya, saya tidak akan keberatan jika kontrol dipisahkan atau tidak.

Berikut beberapa maket lainnya:

Arahkan kursor:

Dipilih dengan bilah lebar penuh yang memakan ruang (bukan hanya menjadi hamparan) seperti di seluler dan dapat berfungsi ganda sebagai pegangan seret:

Saya harus mengatakan saya pikir kami berada dalam bahaya kecil karena ini menjadi terlalu kuning ... itu cara yang aneh untuk menggambarkan ini, tetapi melakukannya dengan itu :) Misalnya, hover yang ditunjukkan pada tiruan terakhir cukup intens. Saya pikir kita harus melihat ini lebih untuk apa yang ditunjukkan Mel pada gambar pertama yang memiliki satu batas lebih sedikit dan itu benar-benar membantu jika tidak memilikinya.

Saya mengambil ejekan pertama dan membuang tempat sampah untuk mendapatkan apa yang menurut saya terbaik untuk kemajuan:

Kami tidak membutuhkan batas ekstra dan kami tidak perlu menambahkan bobot. Dengan cara ini memungkinkan penyeretan yang mudah tanpa garis luar melayang yang tidak biasa.

@karmatosed Saya memodifikasi mockup Anda untuk menunjukkan seperti apa tampilannya saat Anda

Dan ini dia dengan blok yang dipilih dan toolbar blok ditampilkan:

(Saya juga memperbarui placeholder blok Gambar agar sesuai dengan yang saat ini di Gutenberg.)

Sesuatu yang agak membingungkan saya karena tidak memiliki batas atas pada kontrol: apakah kontrol masih pada latar belakang putih? Apakah ini berarti seluruh blok memiliki latar belakang putih di belakangnya? Kedengarannya hal itu akan menyebabkan masalah dalam konteks bersarang di mana sebuah blok bersarang dalam wadah dengan latar belakang gelap, karena memilih (dan / atau melayang) akan menyebabkan latar belakang blok berubah, yang akan terlihat cukup menggelegar.

Sesuatu yang agak membingungkan saya karena tidak memiliki batas atas pada kontrol: apakah kontrol masih pada latar belakang putih? Apakah ini berarti seluruh blok memiliki latar belakang putih di belakangnya?

Ia melakukannya tetapi kontrolnya memiliki target. Saya pikir itu layak ditampilkan dan menghindari masalah visual blok tanpa. Hal ini tentunya membutuhkan penjelajahan dalam nesting, namun tanpa background akan semakin parah jika dilakukan nesting secara visual.

Ia melakukannya tetapi kontrolnya memiliki target. Saya pikir itu layak ditampilkan dan menghindari masalah visual blok tanpa. Hal ini tentunya membutuhkan penjelajahan dalam nesting, namun tanpa background akan semakin parah jika dilakukan nesting secara visual.

Setuju, dan memiliki latar belakang juga menyelesaikan # 6451.

Saya tidak suka bilah kosong besar itu ditampilkan saat melayang di mockup terakhir itu. Idealnya, Anda ingin menutupi sesedikit mungkin blok di sekitarnya saat melayang, tetapi ini menutupi cukup banyak blok di bawah. Bagaimana dengan sesuatu yang seperti ini?

Seperti yang disarankan sebelumnya, penggerak panah dan elipsis bisa berfungsi ganda sebagai pegangan seret, dan / atau judul hover bisa menjadi pegangan seret. (Lihat # 7114.)

@SuperGeniusZeb sementara saya memahami poin Anda dalam hal ini memiliki blok yang diuraikan sebenarnya tidak bagus secara visual. Mari kita tetap berpegang pada tiruan yang saya buat berdasarkan karya luar biasa Mel untuk melihatnya menjadi prototipe.

Sesuatu yang baru saya sadari tentang memiliki latar belakang putih muncul di belakang blok yang dipilih: bagaimana dengan blok dengan warna teks putih (atau sebaliknya berwarna terang) yang dimaksudkan untuk dilihat di area berwarna gelap (disediakan oleh sesuatu seperti blok Kontainer)? Memiliki latar belakang putih untuk seluruh blok tidak akan berfungsi dalam hal ini.

Latar belakang berada di sekitar toolbar yang akan selalu memiliki kontrol tersebut.

@SuperGeniusZeb Ya, saya tidak melihat latar belakang putih memengaruhi blok itu sendiri, hanya kontrolnya. Praktisnya bisa seperti ini:

Atau padding berpotensi dihapus (Saya sangat suka pendekatan ini, tetapi jelas ini adalah pertanyaan yang lebih besar yang memiliki implikasi dengan drag and drop. Masih berpikir itu layak dipertimbangkan):

@chrisvanpatten Saya suka mockup terakhir itu. Saya tidak berpikir drag-and-drop akan menjadi masalah karena bilah bawah bisa sebagai pegangan seret (dan kemungkinan tombol di bilah akan berfungsi sebagai satu juga). Anda bahkan dapat menambahkan ikon pegangan seret ke bilah bawah saat mengarahkan kursor atau selalu memilikinya di sana untuk menunjukkan bahwa Anda dapat menyeret blok dengan menggunakannya.

Dengan pendekatan ini, saya tidak melihat alasan untuk menjaga area yang dapat diseret di dekat perbatasan blok. Menghapus padding itu juga dapat membantu membuat blok hover / garis yang dipilih lebih dekat dengan batas sebenarnya dari blok, karena mereka tidak lagi harus memperhitungkan ruang seret itu dan hanya perlu menyesuaikan agar lebih besar dari blok yang sebenarnya di kasus bersarang untuk mempermudah pemilihan blok induk. (Memilih blok induk tidak akan menjadi masalah jika hal-hal seperti maket dalam komentar ini di # 6459 diterapkan.)

@Tokopedia

Anda bahkan dapat menambahkan ikon pegangan seret ke bilah bawah saat mengarahkan kursor atau selalu memilikinya di sana untuk menunjukkan bahwa Anda dapat menyeret blok dengan menggunakannya.

Ide bagus 💡

Saya pikir mari kita tinggalkan area draggable ke satu sisi dan terapkan ini. Penting untuk fokus untuk menyelesaikan masalah ini terlebih dahulu. Saya harus mengatakan saya tidak yakin ikon adalah pendekatan yang tepat, yang mengatakan mari kita kunjungi kembali setelah ini diterapkan tanpa itu.

@tokopedia

Saya pikir mari kita tinggalkan area draggable ke satu sisi dan terapkan ini.

Saya tidak begitu yakin apa artinya ini? Sisi mana?

Senang melihat ini akan terjadi. Hanya pengingat cepat bahwa ini bukan hanya tentang penempatan visual. Untuk a11y, urutan visual dan urutan tab (urutan DOM) harus cocok sehingga "alat blok" ini harus benar-benar dipindahkan setelah area yang dapat diedit blok di markup.

Satu manfaat bagus dari beralih ke kontrol di bawah blok adalah bahwa itu membuka ruang samping untuk memungkinkan penyisip saudara untuk didesain ulang menjadi sesuatu seperti yang ada di Squarespace jika desain saat ini mengalami masalah. Kontrol samping saat ini akan tumpang tindih dengan penyisip semacam ini dan akan terlihat berantakan, tetapi dengan kontrol dipindahkan ke bawah, ini tidak lagi menjadi masalah.

https://support.squarespace.com/hc/en-us/articles/206991377-Adding-blocks#toc -insert-points

Baru saja berkomentar tentang ini di # 7500. Saya bertanya-tanya bagaimana paragraf yang berurutan akan terlihat dengan desain ini? Saya pikir memiliki bilah di bagian bawah akan menghasilkan celah yang cukup besar di antara paragraf.

@talldan Mengutip diriku dari # 7500:

Kontrol blok tidak akan mengambil ruang saat hover (seperti mereka dan toolbar blok tidak mengambil ruang sekarang), dan sejauh yang saya tahu itu bahkan belum diputuskan apakah mereka akan mengambil ruang pada blok yang dipilih. Dan tentu saja, kontrol hanya akan ditampilkan untuk blok yang dipilih atau diarahkan. Jarak standar antar blok harus tidak terpengaruh oleh perubahan; hanya blok yang dipilih yang mungkin terpengaruh.

Ini terlihat sangat bagus, saya setuju.

Satu hal yang perlu diperhatikan dalam hal ini yang belum pernah kami lakukan sebelumnya. Bagaimana dengan balok yang panjang? Apa yang terjadi pada itu dan bagian bawah layar editor dengan blok?

Maksud Anda, ketika blok itu begitu panjang sehingga tidak terlihat? Saya akan mengatakan sebelum itu terjadi orang akan melihat cara kerjanya dan tahu di mana menemukannya. Kami hanya perlu menguji apakah itu mengganggu jika Anda menulis banyak paragraf panjang di layar kecil. Tapi saya suka itu mencerminkan pengalaman seluler dengan lebih baik. Kekhawatiran apa yang Anda miliki untuk blok terakhir dalam sebuah pos?

Bagaimana mereka melihat jika balok pertama mereka adalah balok yang sangat panjang?

Kami setidaknya harus menambahkan tip NUX tentang itu;) tetapi yang Anda khawatirkan adalah kasus seseorang membuka posting yang ada yang mungkin merupakan satu paragraf panjang atau belum dikonversi menjadi blok dengan benar? Itu mungkin ... Jika mereka memulai posting baru, mereka hampir pasti akan melihatnya di blok placeholder pertama, bukan?

Berpikir tentang ini, saya tidak melihat eksplorasi di sini untuk meletakkan kontrol di bagian atas blok, yang bisa menjadi opsi. Melakukan mockup cepat untuk itu. ( Menggabungkan bar juga disebutkan di sini )

Jika blok terlalu tinggi, bukankah kontrol bawah akan macet di bagian bawah layar, seperti bagaimana kontrol atas terjebak di atas atau cara kerjanya di seluler?

@hedgefield Saya sangat menyukainya tetapi tidak berfungsi dengan baik dalam konteks sempit (seperti blok kolom), atau dengan toolbar yang panjang.

@hedgefield @chrisvanpatten Mungkin kontrol panah / elipsis bisa bergerak di bawah (atau di atas) kontrol format dalam kasus lebar yang lebih tipis?

@karmatosed Saya akan mengatakan kontrolnya bisa lengket dan tetap terlihat di bagian bawah layar. Namun, ini menyebabkan masalah kontrol ini menutupi baris yang Anda coba tulis dalam Paragraf setiap kali Anda mulai menulis (mungkin mereka akan disembunyikan saat mengetik seperti cara kerjanya sekarang). Tapi bagaimanapun solusi itu tampaknya dipertanyakan.

Kembali ke mockup oleh @hedgefield , bagaimanapun, itu dapat memungkinkan kontrol menjadi lengket seperti alat pemformatan tanpa menghalangi. Tentu saja, bilah alat harus responsif dan penggerak panah serta elipsis idealnya harus bergerak ke bawah / atas / suatu tempat untuk balok tipis.

Ada juga masalah aksesibilitas. Maket oleh

dan saya tidak tahu apakah ketidakkonsistenan antara tampilan visual dan urutan sumber harus terjadi

Tidak diinginkan pada titik ada Kriteria Sukses WCAG khusus untuk itu:
https://www.w3.org/TR/WCAG21/#focus -order

Saya akan mengatakan kontrolnya bisa lengket dan tetap terlihat di bagian bawah layar. Namun, ini menyebabkan masalah kontrol ini menutupi baris yang Anda coba tulis dalam Paragraf setiap kali Anda mulai menulis (mungkin mereka akan disembunyikan saat mengetik seperti cara kerjanya sekarang). Tapi bagaimanapun solusi itu tampaknya dipertanyakan.

Sebenarnya, jika dipikir-pikir lagi, kontrol sebenarnya tidak akan menutupi baris terakhir dalam Paragraf kecuali jika Paragraf berada tepat di sebelah bawah layar, jadi # 353 dapat menjadikan ini bukan masalah. Dan bahkan tanpa # 353, Anda masih dapat menggulir ke bawah (yang memang dilakukan kebanyakan orang), dan seperti yang disebutkan sebelumnya, kontrol juga hanya akan ditampilkan saat Anda menggerakkan mouse. Saya telah berubah pikiran. Ini bisa berhasil!

Bagaimana tampilannya untuk balok lebar:

Bagaimana tampilannya untuk balok tipis:

Blok yang lebih tipis (pikirkan 8 kolom atau sesuatu):

Saya rasa saya benar-benar mulai menyukai desain ini. Untuk blok yang lebih luas, saya tidak yakin apakah kontrol penggerak panah harus berada di sebelah kiri kontrol pemformatan atau ke kanan.

Terima kasih atas penjelajahannya, namun menggabungkan semuanya dalam satu baris akan menggabungkan berbagai tindakan ke satu tempat. Saya tidak yakin itu masuk akal. Kami juga memiliki pertimbangan tentang apa yang terjadi ketika seseorang menempelkan toolbar ke atas - mereka memilih untuk tidak memiliki sesuatu 'pada tempatnya' dan sekarang kontrolnya. Itu terasa seperti pengalaman yang kurang karena kami tidak dapat memiliki kontrol blokir di bilah alat - itu akan sangat aneh untuk dialami.

namun menggabungkan semuanya dalam satu baris berarti menggabungkan tindakan yang berbeda ke dalam satu tempat.

Untuk bermain sebagai pendukung iblis, bukankah itu, menurut definisi, tujuan dari bilah alat?

Untuk menambahkan lebih jauh, sementara saya dapat memahami gagasan di balik pemisahan kontrol tertentu, saya tidak yakin ada argumen yang cukup kuat untuk itu dalam kasus ini. Toolbar adalah toolbar; Menempatkan semua kontrol untuk blok tertentu di satu tempat masuk akal, daripada memberikan alasan kabur mengapa alat tertentu berada di tempat tertentu sementara alat lain berada di tempat lain yang pasti akan diabaikan oleh plugin.

@karmatosed Bagaimana dengan memisahkan kontrol melalui warna?

@SuperGeniusZeb sayangnya itu tidak menyelesaikan poin saya yang lain tidak dan saya tidak yakin itu berhasil.

Saya benar-benar berpikir dalam kasus ini adalah kasus mencoba menyesuaikan desain yang dianggap berhasil mendapatkan yang akan berhasil. Bagaimana kalau mundur dan mempertimbangkan poin lain yang saya angkat?

@chrisvanpatten, menurut definisi, toolbar bukanlah tempat untuk meletakkan segalanya, agar berguna toolbar harus memiliki konteks dan keteraturan. Anda harus sebagai pengguna mengharapkan apa yang ada menjadi pilihan yang tepat. Sementara kita dapat memperdebatkan apa arti kata tunggal untuk sementara waktu - menyenangkan untuk melakukan itu - kita tidak dapat melupakan fakta bahwa ini menggabungkan terlalu banyak hal sekaligus dan akan menjadi masalah bagi lebih banyak orang.

@ditutup Oke. Mari kembali ke toolbar pengeditan di atas:

(Tidak yakin apakah garis biru di atas bilah harus ada atau tidak.)

Apakah ada yang salah dengan desain ini? Bilah alat pengeditan dapat dibuat agar muncul setelah blok dalam urutan sumber untuk aksesibilitas; ini tidak ideal, tetapi karena meletakkan bilah alat pengeditan di bawah blok tampaknya bukan pilihan yang layak, tampaknya itu satu-satunya hal yang dapat kita lakukan.

Selain itu, saya baru saja mendapat ide: bagaimana jika bilah di bagian bawah sebagian transparan saat mengarahkan kursor? Apakah itu akan membuatnya terasa lebih ringan?

@SuperGeniusZeb hanya untuk mendapatkan tampilan, bisakah saya menyarankan agar kita memiliki

Hanya untuk mendapatkan tiruan langkah berikutnya. @SuperGeniusZeb seperti apa tampilan di atas dalam konteks layar (ukuran desktop normal) dan blok yang sangat panjang? Apa yang juga terlihat dengan balok tepat di bagian bawah? Idealnya, mari parkir sedikit transparansi dan pertimbangkan komentar saya tentang fokus pada UI bukan warna kali ini, ini akan membantu kita semua mengukur.

Beberapa mockup:

Dengan batas di atas bilah kontrol

Tanpa batas di atas bilah kontrol

Perhatikan bahwa toolbar tidak mengambil ruang apa pun saat hover, tetapi ia melakukannya saat blok dipilih.

Saat membuat maket ini, saya memperhatikan sesuatu: apa yang harus dilakukan dalam situasi seperti ini?

Ada konflik di sini antara menampilkan toolbar pemformatan dari blok yang dipilih dan kontrol bawah dari blok yang di-hover. Jika bilah alat pemformatan berada di bagian bawah (atau jika semua kontrol blok di atas), ini tidak akan menjadi masalah, tetapi di sini kombinasi kontrol yang ditunjukkan di bawah dan kontrol yang ditunjukkan di atas blok menciptakan masalah.

Solusi terbaik yang dapat saya pikirkan adalah membuat blok yang di-hover dan bilah alatnya memiliki indeks-z yang lebih tinggi dan muncul di atas blok di bawah dan bilah alat pemformatannya. Saya tidak yakin ini adalah pendekatan yang tepat. Berikut ini mockup dari tampilannya:

Dan lagi, tanpa batas antara bilah bawah dan konten blok:

Saya tidak terlalu menyukai gagasan blok yang melayang tumpang tindih dengan yang dipilih, tetapi jika tidak, saya tidak melihat cara untuk menggunakan batang bawah dari blok yang melayang langsung di atas yang dipilih. Apakah Anda yakin tidak lebih baik jika semua kontrol dalam satu bilah di bagian atas atau bawah, setidaknya di desktop? Ini pasti akan mencegah masalah seperti ini.

@SuperGeniusZeb Entah bagaimana aku melewatkan

Itu adalah poin yang sangat bagus yang tidak saya pikirkan (mengarahkan blok di atas blok yang dipilih). Itu pasti masalah. Sebagai ahli pembuat halaman residen, apakah ada pola serupa lainnya di pembuat halaman lain, dengan bilah alat berlapis seperti ini?

Juga, untuk apa nilainya, saya pikir toolbar harus selalu di-hover, dipilih atau tidak. Membuatnya _kadang-kadang_ memakan tempat akan menyebabkan konten yang tidak stabil yang secara keseluruhan memberikan pengalaman yang lebih canggung.

@chrisvanpatten Semua pembuat halaman yang saya lihat hanya memiliki kontrol (kecuali mungkin penyisip saudara) yang ditampilkan di bagian atas modul / widget. Divi adalah salah satu contoh terbaik, menurut saya:

https://supergeniuszeb.com/wp-content/uploads/2018/06/Divi-Visual-Builder-add-button-responsiveness-demonstration.webm

Tidak ditampilkan dalam video, bilah alat pemformatan di Divi muncul saat Anda mengklik teks dalam modul, dan muncul di pop-up kecil di atas baris yang Anda tulis.

Elementor melakukan hal yang hampir sama.

Di Beaver Builder, mengklik teks di widget akan menyebabkan toolbar kontrol blok diganti dengan toolbar format sampai mouse Anda bergerak ke luar batas widget, yang akan menyebabkan kontrol blok standar muncul saat Anda mengarahkan kursor ke widget berikutnya. , meski Anda masih bisa mengetik di widget. Mengklik teks lagi akan membuat toolbar format menggantikan toolbar standar lagi.

Juga, untuk apa nilainya, saya pikir toolbar harus selalu di-hover, dipilih atau tidak. Kadang-kadang memakan tempat akan menyebabkan konten gelisah yang merupakan pengalaman yang lebih canggung secara keseluruhan.

Benar, tapi saya khawatir tentang implikasi ini untuk memiliki UI yang bersih. Jika Anda memiliki bilah alat pemformatan yang tumpang tindih dengan beberapa konten di atas, tidak apa-apa. Tetapi kemudian jika Anda menambahkan bilah lebar penuh ke bagian bawah blok, sekarang Anda tumpang tindih dengan banyak konten lainnya.

Idealnya, Anda ingin semua kontrol berada di atas atau bawah blok. Itu akan mencegah bilah alat saling tumpang tindih dalam banyak kasus. Demi aksesibilitas, meletakkan kontrol di bagian bawah akan ideal. Namun, Anda mungkin mengalami masalah di mana bilah alat tumpang tindih dengan konten yang Anda tulis dalam sesuatu seperti blok Paragraf. Perlu dicatat, bagaimanapun, bahwa hanya bilah alat pemformatan yang benar-benar diperlukan untuk selalu terlihat, karena penggerak panah dan elipsis bukanlah sesuatu yang akan digunakan hampir sesering itu. Selain itu, jika bagian konten blok yang saat ini sedang diedit disimpan cukup jauh dari bagian bawah layar, maka bilah alat pemformatan tidak perlu tumpang tindih.

Jika meletakkan kontrol di bagian bawah terasa terlalu canggung, maka sepertinya pilihan terbaik berikutnya adalah meletakkan semuanya di atas. Tentu saja, ada potensi masalah kontrol yang tampak canggung untuk blok tipis.

Dalam kasus desktop versus seluler, Anda biasanya dapat lolos dengan menggeser posisi bilah alat. Saat ini bilah alat pemformatan dan kontrol lainnya semuanya ditampilkan di bawah blok yang saat ini dipilih dan menggunakan ruang di perangkat seluler.

Dalam kasus blok lebar versus blok tipis, bagaimanapun, memindahkan kontrol untuk blok yang lebih tipis mungkin terasa canggung. Tampilan yang paling konsisten mungkin memiliki bilah alat pemformatan di bagian atas dan kontrol lain di bagian bawah. Tapi itu membawa kita kembali ke masalah bilah alat yang tumpang tindih dan peningkatan jumlah konten yang tumpang tindih.

Gutenberg dirancang berdasarkan gagasan bahwa tampilan blok yang dipilih dioptimalkan untuk pengeditan, jadi menurut saya memiliki bilah alat yang memakan ruang fisik tidak terlalu buruk, selama Anda memilih blok hanya memindahkan barang di sekitar blok, dan tidak bergerak blok yang dipilih itu sendiri.

Pada akhirnya, saya merasa maket ini masih merupakan pilihan yang cukup bagus. Ini tidak sempurna, tetapi masuk akal dari sudut pandang aksesibilitas, tidak terlihat terlalu canggung, konsisten dengan seluler, dan jarang mengakibatkan bilah alat yang tumpang tindih.

Beberapa catatan tentang bagaimana ini akan bekerja:

Kontrol tidak memakan tempat saat mengarahkan kursor, tetapi memakan tempat saat blok dipilih. Saat mengarahkan sebuah blok, hanya penggerak panah dan elipsis yang ditampilkan, tetapi memilih blok akan membuat toolbar pemformatan muncul, yang mendorong kontrol lain ke bawah. Ini mungkin masalah terbesar dengan desain ini. Saya pikir untuk membuat ini bekerja paling baik, Anda ingin konten blok didorong ke atas saat memilih blok dengan mengklik toolbar penggerak / elipsis, tetapi Anda ingin toolbar bergerak jika Anda memilih blok dengan mengklik area konten.

Saat blok membentang di bawah area konten, penggerak panah dan elipsis akan berada di luar layar, tetapi toolbar pemformatan akan tetap terlihat, melekat ke bagian bawah layar (atau area editor konten).

Jika ini bukan solusi terbaik, maka pada dasarnya saya akan melakukan hal yang sama, tetapi dengan semua kontrol di atas, dengan penggerak / elipsis muncul di atas bilah alat pemformatan untuk blok tipis, dan mungkin di sebelah kiri kontrol pemformatan untuk blok lebar. Seluler masih bisa terlihat seperti sekarang.

Pemikiran lain: Anda dapat menyingkirkan masalah kontrol pengalihan dan bilah alat yang saling tumpang tindih jika Anda tidak menunjukkan kontrol apa pun saat mengarahkan kursor. Itu akan membuat menampilkan bilah alat di bagian atas dan bawah blok jauh dari masalah. Namun tentu saja, Anda kehilangan manfaat memiliki kontrol yang ditampilkan saat mengarahkan kursor. Saya tidak begitu yakin apakah itu arah yang ingin dituju seseorang, tetapi saya mulai bertanya-tanya apakah itu perlu.

Saya harus mengatakan gagasan tentang blok yang melayang tumpang tindih bukanlah yang saya suka juga. Saya pikir ini perlu lebih banyak pemikiran. Gagasan tentang kontrol yang mengambil ruang berbeda yang berpotensi saat melayang terasa sedikit canggung.

Kontrol tidak memakan tempat saat mengarahkan kursor, tetapi memakan tempat saat blok dipilih. Saat mengarahkan sebuah blok, hanya penggerak panah dan elipsis yang ditampilkan, tetapi memilih blok akan membuat toolbar pemformatan muncul, yang mendorong kontrol lain ke bawah. Ini mungkin masalah terbesar dengan desain ini.

Saya pikir ini adalah masalah besar dengan ejekan. Apa lagi yang bisa terjadi?

Sementara melihat pembuat halaman adalah satu aspek, bagaimana dengan aplikasi dan produk lain? Apakah ini diselesaikan di tempat lain?

@tokopedia

Sementara melihat pembuat halaman adalah satu aspek, bagaimana dengan aplikasi dan produk lain? Apakah ini diselesaikan di tempat lain?

Sulit untuk mencoba menemukan contoh UI analog yang dapat digunakan Gutenberg, karena hampir tidak ada yang harus memperhitungkan semua hal yang dilakukan Gutenberg.

Banyak plugin pembuat halaman yang lebih sederhana / lama tidak perlu khawatir menutupi konten yang setara dengan blok, karena semua pengeditan konten dilakukan dalam modal atau sidebar. Ini membebaskan mereka untuk memungkinkan kontrol modul mereka tumpang tindih dengan konten.

Bahkan dalam kasus seperti Divi atau Beaver Builder, di mana Anda dapat mengedit teks tanpa membuka modal / sidebar, modal / sidebar masih menjadi cara utama untuk mengedit. Divi dan Beaver Builder, keduanya menunjukkan replika front-end yang sempurna, tanpa harus khawatir harus mengoptimalkan hal-hal seperti menggunakannya sebagai editor teks atau memastikan bahwa sebagian besar konten blok utama dapat diedit secara inline di blok.

Selain itu, baik di pembuat halaman dan UI builder-ish lainnya, penumpukan cenderung tidak terlalu menjadi masalah karena pembatasan pada apa yang dapat disarangkan. Divi memiliki Bagian yang ketat → Baris (dengan kolom built-in) → Pengaturan modul (meskipun dengan beberapa Bagian Khusus yang dirancang untuk beberapa situasi kolom bersarang yang umum). Beaver Builder hanya mengizinkan kolom untuk disarangkan di kolom, seperti halnya Elementor. Mereka mengontrol satu-satunya jenis objek yang dapat memiliki banyak lapisan bersarang. Semuanya ada di Bagian dengan satu baris secara default. Tidak ada lapisan blok bersarang yang tidak terbatas dengan potensi kombinasi blok khusus apa pun yang menggunakan penyarangan untuk berbagai tujuan dan berbagai gaya seperti yang diizinkan Gutenberg.

Divi dapat memberi kode warna pada kontrolnya untuk bagian, baris, dan modul karena memiliki struktur yang ketat dan tidak ada modul kustom yang berfungsi sebagai bagian atau baris. (Ini juga memungkinkannya untuk menampilkan beberapa tombol penyisip pada baris yang sama, tetapi dengan warna berbeda untuk membedakan apa yang akan dilakukan masing-masing.) Pada sebagian besar pembuat, modul terpisah dari elemen tata letak. Beaver Builder dapat melakukan hal serupa karena pemisahan modul dan elemen tata letak.

Jika Anda melihat hal-hal yang bukan pembuat halaman, seperti editor teks, Anda dapat melihat bahwa mereka tidak perlu khawatir tentang semua hal yang harus dihadapi oleh pembuat halaman. Jika Anda melihat sebagian besar pembuat halaman, mereka tidak menangani hal-hal editor teks melalui kontrol WYSIWYG sebaris langsung.

Apa yang coba dilakukan Gutenberg unik. Ini mencoba menjadi pembuat halaman WYSIWYG-kecuali-untuk-yang-dipilih-yang-dioptimalkan-untuk-pengeditan yang juga merupakan editor tekstual lengkap, dan semuanya dari bagian ke kolom hingga widget semuanya jenis yang sama objek: blok.

Pada dasarnya, ini adalah masalah yang rumit karena Gutenberg mencoba melakukan beberapa hal berbeda pada waktu yang sama yang tampaknya tidak dilakukan oleh orang lain. : stuck_out_tongue:

Bagaimanapun, berikut adalah daftar hal-hal yang dapat dilihat untuk melihat bagaimana mereka menangani UI blok / modul / widget:

Plugin / tema WordPress

• Avada (Pembuat Fusion)
• BeTheme (Pembuat Muffin)
• Beaver Builder
• Divi (Pembangun Divi)
• Elementor
• Oksigen
• SiteOrigin Page Builder
• Arsitek Berkembang
• Komposer Visual
• X & Pro oleh Themeco

Pembuat situs web di luar WordPress

• Drupal
• Squarespace
• Weebly
• Wix

Hal-hal yang bukan pembuat halaman tetapi sejenisnya

• MailChimp
• Gagasan

Itu saja yang saya tahu sekarang.

Ada masalah dengan penyisip saudara: itu selalu tumpang tindih dengan konten dari blok yang dipilih. Masalah ini menjadi lebih buruk ketika Anda mencoba menyingkirkan hal-hal seperti margin otomatis di setiap blok untuk membuat Gutenberg lebih WYSIWYG.

Solusinya? Nah, jika kita akan menambahkan palang ke bagian bawah blok, mengapa tidak memasukkan saja sibling inserter ke palang itu juga?

Selain itu, saya baru saja menemukan cara untuk membuat border pada varian yang di-hover terlihat sedikit tidak terlalu mencolok. Ubah saja warna perbatasan yang membagi konten blok dari bilah bawah!

Manfaatnya meliputi:

• Penyisip saudara tidak pernah tumpang tindih dengan konten blok yang dipilih. Ini berarti seharusnya tidak ada UI yang pernah tumpang tindih dengan konten dari blok yang dipilih kecuali untuk toolbar pemformatan lengket, yang tidak menutupi konten jika Anda hanya menggulir ke atas atau hanya mengetik dan tidak menggerakkan mouse.
• Penyisip saudara sekarang muncul dalam urutan yang sama dengan urutan tab HTML, yang bagus untuk aksesibilitas.
• Penyisip saudara sekarang muncul di bawah blok, bukan di atas. Ini lebih masuk akal, menurut saya.
• Penyisip saudara selalu terlihat untuk blok yang dipilih (kecuali mungkin saat mengetik jika kontrol masih dibuat tidak terlihat seperti sekarang)
• Konsistensi dengan UI seluler.
• Semua margin dan bantalan bagian dalam blok dapat dihapus, dan batas blok dapat diubah kembali menjadi ukuran blok yang sebenarnya, semua tanpa UI blok menghalangi konten blok.

Poin bonus jika penyisip saudara diubah untuk membuka menu penyisip secara langsung (seperti yang dibahas di # 7271) daripada memasukkan blok Paragraf kosong.

Tentu saja, pertanyaan tentang apa yang terjadi ketika Anda mengarahkan kursor ke blok yang dipilih masih menjadi masalah. Namun, saya rasa ini tidak terlalu mengganggu saya. Yang harus Anda lakukan adalah mengklik blok untuk memilihnya dan melihat kontrol, dan jika kontrol hover ditampilkan di bawah blok yang saat ini dipilih, itu tidak masalah karena blok yang dipilih seharusnya menjadi fokus.

Saya pikir ini adalah desain yang bagus untuk maju. Saya pikir semua hal positif lebih banyak daripada yang negatif, dan saya pikir itu pasti lebih baik daripada yang ada saat ini. Bagaimana menurut kalian?

Saya mengejek bagaimana tampilannya jika bilah alat atas dan bawah tumpang tindih, dan bagaimana tampilannya jika blok yang di-hover selalu mengambil indeks-z tertinggi di atas blok yang dipilih.

Saya sangat menyukai ini, tetapi ada satu masalah kecil… blok baris tunggal kurang beruntung, karena mereka hampir seluruhnya tersembunyi di bawah bilah kontrol bawah.

@chrisvanpatten Saya berpikir bahwa bilah paling bawah akan benar-benar mengambil ruang ketika blok dipilih. Saya pikir itu akan memperbaiki masalah blok baris tunggal. Bisakah Anda membuat mockup untuk menunjukkan seperti apa tampilannya? Juga, bagaimana rasanya jika blok yang di-hover tidak tumpang tindih dengan blok yang dipilih?

Juga, mungkin harus ada bayangan di bawah bilah bawah saat itu tumpang tindih dengan sesuatu.

@SuperGeniusZeb Saya sangat menentang jika bilah bawah mengambil ruang - yang mengarah ke UI melompat. Blok yang dapat digunakan kembali melakukannya sekarang saat Anda memilihnya dan itu membuat saya gila.

(EDIT: Untuk menguraikan, itu membuat segalanya menjadi sangat sulit bagi pengguna mouse karena Anda tidak dapat benar-benar mengandalkan hal-hal yang berada di tempat yang sama dari satu momen ke momen lainnya. Itu menyebabkan banyak kecanggungan.)

@pengen

Saya terutama berpikir bahwa dalam konteks menulis posting, Anda mungkin tidak ingin menutupi paragraf di bawah yang Anda ketik. Saat ini sepertinya blok Paragraf di bawah yang dipilih kehilangan baris pertamanya. Saya rasa saya lebih suka blok di sekitarnya melompat sedikit ketika Anda memilih salah satu daripada tidak dapat melihat bagian atas blok setelah yang sedang saya edit. Secara pribadi, melompat-lompat tidak terlalu mengganggu saya.

Cukup umum di Gutenberg untuk sesuatu berubah ukuran saat Anda memilihnya: Image caption placeholder, Quote citation placeholder, placeholder / inserter di Galeri, dan blok Reusable, seperti yang Anda sebutkan. Gutenberg umumnya dirancang dengan gagasan bahwa tampilan blok harus dioptimalkan untuk pengeditan saat dipilih. Saya akan mengatakan itu membuat tidak masalah untuk membuat tinggi blok menjadi lebih tinggi karena bilah bawah mengambil ruang.

Atau, mungkinkah bilah bawah dapat dibuat semi-transparan agar sedikit lebih jelas bahwa ada blok di bawahnya? Bagaimana kedengarannya? Saya pikir saya bisa baik-baik saja dengan itu.

Satu-satunya masalah adalah transparansi tidak digunakan di tempat lain di UI Gutenberg. Itu tidak berarti bahwa itu tidak boleh digunakan ... hanya saja tidak ada contoh yang ada, jadi kami dapat memperkenalkan ketidakkonsistenan desain UI.

Ada juga ide untuk menghilangkan ruang kosong antara kontrol di kiri dan kanan, tapi itu ditolak sebelumnya di tiket karena membuat UI terlihat terlalu "kotak".

@chrisvanpatten Semua yang dikatakan, saya pikir saya masih lebih memilih mockup Anda daripada apa yang ada saat ini . Masalah baris pertama-dari-mengikuti-blok-tampaknya-menghilang kecil dibandingkan dengan semua hal yang akan diperbaiki oleh salah satu maket kami.

@SuperGeniusZeb Menurut saya yang membuatnya sangat canggung dalam hal ini adalah kontrolnya ada saat Anda mengarahkan kursor. Dengan semua contoh kontrol melompat lainnya, setidaknya mereka tidak ada saat Anda mengarahkan kursor, mereka hanya ada di pilih.

Saya tidak berpikir ini layak ditinggalkan karena masalah paragraf hover / select / jump / single-line, tetapi pasti perlu sedikit lebih banyak pemikiran.

Saya masih yakin ada solusi di sini di suatu tempat… hanya harus terus mengulang!

@pengen

Saya pikir yang membuatnya sangat canggung dalam hal ini adalah kontrolnya ada saat Anda mengarahkan kursor. Dengan semua contoh kontrol melompat lainnya, setidaknya mereka tidak ada saat Anda mengarahkan kursor, mereka hanya ada di pilih.

Ya ... Anda _dapat_tidak menampilkan kontrol apa pun saat mengarahkan kursor, tetapi menurut saya aman untuk berasumsi bahwa tidak ada yang benar-benar menginginkannya. Saya tahu saya sangat menyukai kontrol yang tersedia pada hover.

Bagaimana dengan transparansi?

Dan jika Anda ingin sedikit bermimpi dan berharap backdrop-filter diterapkan di semua browser utama, Anda dapat menambahkan beberapa blur:

Omong-omong, ini adalah 60% opacity.

Opacity pasti membantu, tapi saya tidak yakin tentang memperkenalkan opacity ke dalam persamaan. Rasanya seperti curang.

@chrisvanpatten Memang terasa seperti curang ... tapi pilihan lain apa yang kita punya?

Kami tidak dapat menempatkan kontrol di samping, oleh karena itu masalah ini ada sejak awal.

Kami tidak dapat menempatkan kontrol di dalam blok, karena itu akan menutupi konten.

Kami tidak dapat menempatkan kontrol di atas karena bilah pemformatan sudah ada di sana dan masalah yang akan disebabkan oleh blok tipis.

Menempatkan kontrol di bagian bawah adalah hal yang paling masuk akal karena berfungsi lebih baik untuk aksesibilitas, menyediakan tempat yang nyaman untuk dimasukkan ke dalam saudara kandung inserter dan seret pegangan dan menyelesaikan masalah yang terkait dengan itu, lebih konsisten dengan seluler, dan berfungsi paling baik untuk thin blok.

Untuk mengurangi ruang yang digunakan oleh bilah bawah, hanya ada beberapa hal yang dapat kami lakukan:

• Kurangi ketinggian bilah.
• Hapus ruang kosong antara inserter / penggerak / drag handle dan elipsis.
• Dorong elipsis ke kiri dan hapus ruang ekstra di kanan.
• Buat itu memakan tempat saat dipilih. (Tapi Anda tidak menginginkan ini.)

Selain itu, yang bisa dilakukan hanyalah membuatnya semi transparan agar secara visual terasa lebih ringan dan lebih mudah melihat apa yang ada di bawahnya.

Pemikiran lain: mungkin transparansi tidak akan terasa curang jika _both_ toolbar transparan daripada hanya yang paling bawah.

Membuat beberapa maket lagi untuk mencoba beberapa hal yang disebutkan di atas.

Toolbar transparan:

Tidak ada transparansi:

Saya pikir saya sebenarnya lebih suka tanpa transparansi. Bagaimana menurut anda? Saya pikir mengecilkan lebar bilah bawah telah menyelesaikan masalah tumpang tindih-mulai-blok-berikutnya. Tentu saja, ini masih akan terjadi pada lebar yang lebih kecil ... tapi itu sudah terjadi dengan toolbar pemformatan, jadi menurut saya ini tidak benar-benar menjadi masalah.

Juga perhatikan bahwa saya meninggalkan sedikit ruang untuk pegangan drag. Ini bisa memiliki titik-titik kecil berwarna abu-abu yang sering digunakan dalam aplikasi untuk merepresentasikan pegangan drag, atau bisa juga memiliki ikon drag yang ditampilkan saat melayang atau sepanjang waktu. Atau bisa juga tetap kosong. Secara teknis, ini juga bisa sedikit lebih tipis, tetapi saya membiarkannya selebar tombol untuk kenyamanan.

Mungkinkah ini? Mungkinkah ini iterasi yang cukup baik untuk menggantikan yang sekarang? _ (Harap ucapkan "ya".: Stuck_out_tongue:) _

Terima kasih semuanya untuk semua eksplorasi yang dilakukan di sini. Langsung menambahkan satu lagi alasan semi-transparansi tidak ideal: rasio kontras ikon dengan latar belakang harus 4,5: 1. Menggunakan semi-transparansi akan membuat itu tidak mungkin, pikirkan saja gambar dengan warna-warna gelap yang umum, atau paragraf dengan latar belakang gelap, atau tema dengan latar belakang gelap:

Terima kasih atas diskusi yang bagus di sini. Sangat menggembirakan dan menyenangkan melihat semangat yang dihadapi tantangan ini.

Saya telah mengamati sedikit dari jauh, setelah merancang konfigurasi awal blok - dengan toolbar berlabuh, panah atas / bawah di samping, dan akhirnya elipsis di sebelah kanan. Saya menambahkan bahan-bahannya jadi karena saya merasa sangat bermanfaat untuk memberikan real estate utama kepada para mover sebagai alternatif drag and drop yang seringkali fiddly dan rawan error, padahal perilakunya selalu bisa ditebak oleh para mover.

Saya benar-benar mengenali tantangan yang ditimbulkan ini untuk blok bersarang, dan saya sudah lama memikirkan solusi terbaik apa. Apa yang ada di master - menghamparkan ke kiri dan kanan bahkan jika bersarang - berfungsi, tetapi tidak bagus juga, saya akui itu. Opsi lainnya adalah menggunakan UI seluler - menampilkan UI di bawah blok ketika dipilih, yang diejek dalam berbagai varian di sini, berfungsi, terutama untuk seluler. Namun di desktop, ini bisa menjadi sangat mengganggu dan gelisah saat Anda hanya ingin memilih paragraf untuk mengedit kecil dan semuanya melompat-lompat. Demikian pula jika bilah alat dihamparkan seperti pada versi terbaru, rasanya seperti condong terlalu jauh dari pengalaman menulis, ke dalam pengalaman tata letak. Ini adalah keseimbangan konstan yang kami coba capai.

Pilihan kedua adalah kembali ke mockup lama yang saya miliki, yang ini:

Mungkin dengan beberapa penyesuaian, bisa jadi ini:

Tapi saya tidak suka itu. Dan _either_ ini akan membuat penggerak hanya terlihat saat blok di-hover, atau kami ingin sedikit mengubah perlakuannya. Itu juga membuat area yang terkena tombol beberapa piksel lebih kecil, yang tidak bagus untuk kegunaan.

Karena itu, varian-varian tersebut sejauh ini belum dipertimbangkan karena tidak terasa superior dari yang kami miliki. Namun posting di sini apakah mereka dapat menginspirasi perawatan untuk membuatnya bekerja.

Masalah terbesar yang saya lihat dengan menggabungkan alat blok dengan label hover adalah hal itu menciptakan ketidakkonsistenan antara blok yang dipilih dan blok yang di-hover, kecuali jika Anda ingin mulai menampilkan label untuk blok yang dipilih juga. Dan jika Anda melakukan itu, maka label tidak boleh berada di dalam batas blok, melainkan di luarnya.

Tetapi bahkan jika Anda melakukannya, Anda hanya mengalami masalah karena memiliki terlalu banyak kontrol di bagian atas blok dan harus memikirkan cara membuatnya konsisten untuk blok lebar dan tipis.

Saya yakin bahwa, dengan pengecualian bilah alat lengket yang tetap di layar, tidak ada UI blok standar yang dipilih harus menutupi bagian mana pun dari blok itu.

Memiliki alat blokir di bagian bawah memberikan tempat yang bagus untuk menempatkan penyisip saudara, yang keduanya membantu mencapai tujuan tanpa tumpang tindih di atas, sekaligus membuat penyisip saudara lebih terlihat dan memecahkan masalah tumpang tindihnya sendiri. (Saya pikir pembaruan blok bersarang ke blok Kutipan belum terjadi karena penyisipan saudara yang tumpang tindih.)

Karena adanya manfaat sibling inserter dan aksesibilitas, menurut saya berada di bawah blok adalah tempat terbaik untuk meletakkan alat blok.

Sekarang, saya tidak berpikir bahwa membuat kontrol yang jauh lebih kecil ada di atas meja, karena membuatnya lebih kecil dapat membuatnya lebih sulit untuk digunakan, tentu saja. Namun, karena Anda tampaknya tidak menentangnya, mengapa tidak mencobanya?

Bagaimana ini?

Tombol-tombol di bilah bawah (tetapi bukan ikon) telah dikurangi ukurannya dari 38px menjadi 32px, dan saya memperbaiki ketidakkonsistenan dalam jarak antara kontrol penggerak dari maket sebelumnya. Perhatikan bahwa Anda dapat membuatnya sedikit lebih kecil secara horizontal jika tombol elipsis lebih tipis dari yang lain (seperti yang ada di bilah atas editor).

Anda juga dapat mengurangi ukuran area gagang seret yang kosong untuk membuat bilah memakan lebih sedikit ruang. Ini akan menjadi lebih dapat dijalankan jika semua kontrol di bilah digandakan sebagai pegangan seret, seperti cara kerja bilah atas jendela di GNOME.

Perhatikan bahwa di perangkat seluler, kontrolnya mungkin akan terlihat hampir persis seperti yang ada di master , di mana bilah mengambil ruang dan membuatnya lebih besar tidak menjadi masalah. Pengurangan ukuran ini seharusnya hanya memengaruhi pengguna desktop, dan kontrolnya masih dapat digunakan dengan sentuhan pada ukuran ini.

Saya juga melakukan eksplorasi kecil dengan memindahkan kontrol ke toolbar atas, yang memecahkan satu set masalah ... tetapi ketika Anda memilih blok, Anda kembali memiliki Semua Toolbar yang tidak berfungsi dalam konteks sempit, yang merupakan alasan penting untuk eksplorasi ini di tempat pertama.

Saya masih mencoba mencari tahu bagaimana perasaan saya tentang mockup terakhir itu. Kontrol yang menggantung di bagian bawah terasa agak canggung bagi saya. Saya tidak yakin saya punya ide yang lebih baik, hanya saja itu membuat kita kembali ke perasaan kuning / terfragmentasi yang ingin dihindari @karmatosed .

Terima kasih semuanya untuk semua pekerjaan di sini. Saya akan mencoba dan memberikan beberapa umpan balik tetapi saya harus mengatakan sekarang saya tidak merasa ini siap untuk beralih ke prototipe. Saya masih berpikir ada masalah dengan bersarang dan juga perangkat yang berbeda untuk dipecahkan tetapi seperti yang saya sebutkan di komentar sebelumnya, saya rasa trek saat ini tidak benar. Saya merasa kami juga ya menuju kembali ke wilayah yang sudah saya sarankan untuk kami hindari dalam hal ini.

Saya tidak ingin mengecilkan hati menjelajah tetapi sekarang saya akan menyarankan untuk mempertimbangkan memikirkan saran alternatif. Masalah besarnya adalah menambahkan setengah tab ke bawah meningkatkan kepadatan visual tanpa penguatan. Mari pikirkan tentang apa yang kita coba selesaikan di sini:

• Apa yang terjadi di perangkat berbeda.
• Penyisipan saudara kandung (meskipun ini bisa diperbaiki di masalah lain) atau setidaknya bagaimana interaksi itu.
• Visibilitas bersarang dan kemudahan berinteraksi.

Drive utama dalam semua ini adalah cara merespons dan bersarang.

Mari pertimbangkan apa yang kita buat jika kita meningkatkan atau menurunkan kegunaan. Misalnya, menggunakan hal-hal seperti transparansi dan lapisan meskipun tidak masalah bagi seseorang dengan penglihatan normal, namun tidak bagi banyak orang lain membuatnya lebih baik. Pikirkan tata letak yang kompleks, dengan video dan banyak gambar. Dalam struktur informasi yang padat ini, apa yang disarankan tidak berlaku.

Pikirkan tata letak yang kompleks, dengan video dan banyak gambar. Dalam struktur informasi yang padat ini, apa yang disarankan tidak berlaku.

Ya, saya pikir ini adalah poin terbesar, dan saya akan menambahkan kepadatan itu benar-benar _compounds_ di ruang yang lebih kecil yang merupakan bagian lain dari tantangannya. Blok bersarang umumnya membutuhkan semua kontrol yang sama dengan yang dibutuhkan blok yang tidak bersarang, tetapi mereka perlu melakukannya dengan sebagian kecil dari ruang, dan idealnya dengan cara yang tidak unik (misalnya blok bersarang umumnya harus menyerupai blok yang tidak bersarang; konsistensi begets kegunaan).

Kembali ke papan gambar… 🙂

Mengapa menurut saya mockup saya lebih baik daripada UI saat ini

Saya memahami keinginan untuk menghindari tampilan kuning, tetapi saya belum menemukan apa pun yang tidak tampak kuning, namun tetap berfungsi sama. Masalahnya adalah Anda perlu mengetahui tepi blok tempat Anda bekerja, dan Anda ingin kontrol tidak menutupi konten di blok, serta menutupi sedikit di luar blok. Itu cukup menjamin tampilan yang agak kuning.

Hanya dengan melihat tangkapan layar di bagian atas masalah ini, Anda dapat melihat bagaimana Gutenberg pada satu titik memiliki UI yang sangat tidak blokir. Tetapi masalah dengan UI itu adalah sulit untuk mengatakan di mana tepi blok berada. Itulah mengapa kami memiliki UI yang kami miliki sekarang.

Dan saat Anda memasukkan masalah dengan penyisip saudara kandung, Anda menyadari bahwa Anda perlu membuat tombol penyisip saudara berada di luar batas konten blok. Gabungkan itu dengan titik di mana Anda biasanya ingin memasukkan blok setelah yang sekarang (daripada sebelumnya) dan juga keinginan untuk meningkatkan aksesibilitas, dan Anda akhirnya harus memiliki sesuatu seperti mockup terbaru saya.

Secara pribadi, saya lebih suka UI kotak-kotak ini daripada sesuatu yang terlihat seperti mockup pertama. Maket pertama itu terlihat membingungkan karena kurangnya batas antara konten dan kontrol, dan bilah memakan banyak ruang yang tidak perlu. Karena kami tidak ingin melompat UI, bilah bawah harus berupa hamparan di atas konten di luar blok yang dipilih, dan karenanya harus sekecil mungkin.

Selain itu, saya pikir mockup saya pasti lebih baik dalam konteks bersarang daripada yang sekarang. Seperti yang akan saya jelaskan di bawah ini, bilah alat / situasi konten yang tumpang tindih lebih baik dengan UI ini daripada yang sebelumnya. Dan dalam konteks bertingkat, Anda perlu mengetahui lebih jauh tentang batas-batas blok, jadi tampilan yang agak kotak-kotak sebenarnya membantu dalam situasi ini.

Toolbar yang tumpang tindih jauh lebih tidak membingungkan dan cenderung tidak menjadi masalah, karena blok jauh lebih kecil kemungkinannya untuk menjadi kecil secara vertikal pada layar kecil , dibandingkan dengan kemungkinan mereka menjadi kecil secara horizontal pada layar kecil, yang menyebabkan masalah dengan hal-hal seperti blok Kolom . Saat blok teks semakin tipis, teksnya membungkus dan menjadi lebih tinggi.

Dalam konteks bersarang, mengarahkan kursor ke blok di atas blok saat ini hampir tidak akan pernah menutupi semua konten blok di bawah, karena blok akan cukup lebar untuk bilah bawah untuk tidak menutupi semuanya, atau blok akan adil tinggi sehingga masih ada ruang untuk memilihnya.

Selain itu, bilah bawah blok seharusnya hanya muncul saat Anda mengarahkan kursor ke blok, dan tidak hanya saat mouse Anda berada di dekatnya. Karena gagang seret yang aneh dan tidak terlihat di sisi blok, tidak demikian dengan UI saat ini.

Untuk menambah poin di atas, hanya blok di atas yang sekarang yang dapat menutupi apa pun di blok yang dipilih. 3 sisi lainnya benar-benar baik-baik saja, karena mengarahkan blok yang berdekatan secara horizontal tidak akan menutupi apa pun di blok saat ini, dan blok yang di-hover tidak memiliki UI di atasnya, jadi mengarahkan blok di bawah yang dipilih juga baik-baik saja.

Selain itu, Anda dapat dengan mudah memilih untuk tidak membuat blok yang di-hover tidak pernah menutupi blok yang saat ini dipilih, dan itu akan menghasilkan nol masalah yang tumpang tindih dengan blok yang dipilih dalam konteks bersarang. Karena blok yang di-hover hanya memiliki bar di bagian bawah, yang di bawah blok yang sekarang tidak akan pernah tumpang tindih dengan yang dipilih. Satu-satunya hal yang Anda menyerah dalam situasi ini adalah kemampuan untuk mengakses alat blokir untuk blok di atas yang sekarang kecuali Anda memilihnya.

Ide lain: bilah bawah dapat disembunyikan secara otomatis saat Anda mengarahkan kursor ke blok lain. Itu tidak akan kembali sampai kursor Anda pindah ke perbatasan blok lagi. Ini dapat membantu lebih banyak lagi dalam konteks bersarang.

Di atas semua itu, jika Anda masih ingin lebih sedikit masalah tumpang tindih dalam konteks bersarang, Anda dapat memasang toolbar pemformatan ke bilah atas editor. (Ini tidak berpengaruh pada perangkat seluler, tetapi pada perangkat seluler, bilah-bilah tersebut tidak memakan tempat dan tidak tumpang tindih, sehingga tidak ada masalah yang tumpang tindih.)

Secara keseluruhan, saya pikir ada lebih banyak situasi yang diperbaiki oleh mockup terbaru saya daripada situasi yang menjadi lebih buruk.

Karena itu, saya pikir sesuatu seperti mockup saya (atau yang mirip dengannya) memecahkan lebih banyak masalah daripada yang dibuatnya. Selain yang di atas, manfaatnya meliputi:

• Bekerja untuk semua lebar blok.
• Aksesibilitas yang lebih baik untuk saudara kandung inserter, kontrol gerakan, dan elipsis.
• Visibilitas dan visibilitas yang lebih baik untuk penyisip dan tuas seret saudara kandung.
• Area seret di sisi blok dapat dihilangkan, dan label hover tidak harus menjadi pegangan seret (bagaimanapun juga ini agak kecil).
• Penyisip saudara berada di bawah blok, di mana Anda biasanya ingin menggunakannya (sebagai lawan di atas).
• Tidak perlu UI inserter saudara yang terpisah, sehingga mengurangi kerumitan.
• Penyisip saudara tidak lagi memiliki masalah yang tumpang tindih dalam konteks bertingkat. (Saya pikir itulah alasan # 6520 belum terjadi.)
• UI blok yang mengelilingi sebuah blok tidak pernah tumpang tindih dengan konten dari blok itu.
• Margin otomatis dari blok dapat dihapus, dan blok tidak dapat memiliki bantalan bagian dalam apa pun, dan batas UI blok dapat diubah kembali ke batas konten sebenarnya, namun tidak ada konten blok yang akan tumpang tindih oleh kontrol apa pun. Kasus tepi semacam ini akan terjadi dengan blok khusus, jadi ada baiknya untuk memperhitungkannya.
• Semua alat blok cukup berdekatan, membuatnya lebih mudah untuk menjangkau semuanya dan menemukan semuanya, dibandingkan dengan situasi sebelumnya dari penggerak elipsis dan panah berada di sisi berlawanan dari blok.
• Sangat jelas terlihat blok kontrol yang dilampirkan, dibandingkan dengan kebingungan yang sering Anda dapatkan dengan kontrol saat ini dalam konteks bersarang.
• Kontrolnya lebih konsisten dengan perangkat seluler.

Jadi ya, saya pikir mockup saya benar-benar berfungsi lebih baik dalam konteks bersarang, dan menurut saya UI kotak-kotak hampir tidak penting dibandingkan dengan apa yang Anda peroleh. Bagaimana menurut anda? Jika Anda tidak setuju, dapatkah Anda menunjukkan situasi di mana mockup akan jauh lebih buruk daripada UI saat ini dan tidak ada saran yang disebutkan sebelumnya yang akan menyelesaikannya?

Ada ... ide ... ~ Skywalker ~ lainnya

Jika semuanya gagal, saya punya satu ide yang secara teknis akan memperbaiki semua masalah utama. Bagaimana jika bilah alat pemformatan selalu digalangkan ke atas seperti pada Gutenberg 1.6, tetapi kali ini kontrol gerakan dan elipsis akan ditampilkan di atas blok, bukan ke samping? (Sebagai alternatif, Anda masih bisa memilikinya di bagian bawah seperti mockup saya.)

Dalam konsep ini, penyisip saudara tidak akan ada, karena penyisip di bilah atas editor akan melayani fungsi yang sama, dan dalam konteks ini akan lebih dekat dalam jangkauan karena bilah alat pemformatan akan berada di area yang sama.

UI seluler akan sama persis seperti saat ini. Perubahan ini hanya akan memengaruhi pengguna desktop (dan mungkin tablet).

Tapi tunggu, masih ada lagi!

Sebenarnya, jika Anda memikirkannya, apa perbedaan antara ide ini dan hanya memiliki mockup saya dan mengaktifkan Perbaiki Toolbar ke Atas ? Satu-satunya hal yang Anda peroleh dengan menghapus sepenuhnya bilah alat pemformatan sebaris dari seluler adalah kemampuan untuk memiliki kontrol gerakan dan elipsis yang ditampilkan di atas blok, bukan di bawah. Dan secara teknis, itu hanya bisa menjadi bagian dari opsi Perbaiki Toolbar ke Atas .

Bandingkan dengan UI saat ini di mana Perbaiki Toolbar ke Atas tidak menyingkirkan semua masalah kontrol yang tumpang tindih karena UI samping masih terbagi antara dua sisi dan gagang seret tak terlihat yang membingungkan masih ada, dan penyisipan yang bersaudara masih tumpang tindih dalam konteks bertingkat, dan sebagainya.

Apakah sudah pasti di masa depan bahwa setiap paragraf teks adalah blok yang terpisah? Jika demikian, tampilan alat blok harus memperhitungkan beberapa pilihan blok teks (yang saya yakin akan datang pada tahap tertentu).

@ Padraigobeirn Itu poin bagus yang telah saya lupakan.

Khususnya, kontrol di UI saat ini tidak memperhitungkan pilihan panjang. Kontrol gerakan dan elipsis tetap berada di kiri dan kanan atas blok pertama dalam pemilihan. Bahkan bilah alat pemformatan hanya melekat untuk blok pertama dalam pemilihan. Lihat # 7962.

Untuk bilah bawah di mockup saya, Anda secara teoritis dapat membuatnya berfungsi dengan banyak pilihan dengan membuatnya tetap menempel di bagian bawah layar saat Anda menggulir ke atas. Namun, perilaku lengket ini mungkin hanya diinginkan untuk blok yang dipilih.

Anda tahu, saya benar-benar mulai berpikir bahwa Perbaiki Toolbar ke Atas harus aktif secara default.

Karena itu, sebenarnya hanya ada begitu banyak yang dapat Anda lakukan untuk menyesuaikan begitu banyak kontrol di sekitar satu blok, dan bahkan dengan mockup terbaru saya, masih ada kasus di mana UI bisa terasa ramai. Ada juga kekhawatiran tentang UI yang terasa terlalu kuning.

Untuk mengatasi masalah ini, saya pikir memasang toolbar pemformatan ke atas harus menjadi default. Ini menghemat ruang di sekitar banyak blok, dan secara drastis mengurangi kemungkinan tumpang tindih kontrol.

Saya rasa saya masih lebih suka kontrol gerakan dan elipsis berada di bagian bawah, tetapi mereka juga bisa dipindahkan ke atas saat toolbar format dipasang. Tidak memiliki bilah alat pemformatan yang terpasang ke blok akan memungkinkan bilah alat blok ditempatkan di kanan bawah atau kanan atas juga, tanpa terlihat canggung atau memakan terlalu banyak ruang.

Saya pikir saya lebih suka kiri bawah atau kanan bawah. Dengan begitu, kontrol muncul setelah pemblokiran baik secara visual maupun dalam urutan tab, yang paling masuk akal bagi saya. Melempar penyisipkan saudara di sana setelah satu blok lebih masuk akal daripada membuatnya muncul sebelum blok.

Catatan tambahan: Baru-baru ini saya melihat bahwa pembuat email di Infusionsoft sebenarnya memiliki konsep "blok" sendiri, dan memiliki alat blokir (duplikat dan hapus) yang ditunjukkan di atas blok di kanan atas. Kontrol pemformatan muncul di bilah di bagian atas editor saat kursor Anda memasuki area teks.

Saya baru-baru ini memperhatikan bahwa pembuat email di Infusionsoft sebenarnya memiliki konsep "blokir" sendiri, dan memiliki alat blokir (duplikat dan hapus) yang ditunjukkan di atas blok di kanan atas. Kontrol pemformatan muncul di bilah di bagian atas editor saat kursor Anda memasuki area teks.

Bisakah Anda memotong beberapa tangkapan layar dari antarmuka itu @SuperGeniusZeb?

Ketika saya pertama kali mulai menggunakan Gutenberg, saya benar-benar orang yang "memperbaiki toolbar", tetapi setelah menggunakannya untuk beberapa waktu saya tidak yakin ingin kembali. Saya benar-benar menyadari bahwa bilah alat dalam banyak hal adalah penyebab semua masalah ini - kemungkinan besar memiliki banyak hal yang terpotong dalam konteks bersarang, dan memakan ruang yang dapat Anda gunakan untuk kontrol samping - tetapi memilikinya dipasangkan dengan blok itu sangat bagus. Itu menyimpan semua yang Anda butuhkan di satu tempat, menghindari banyak gerakan mata dan gerakan mouse, dll. Saya terkejut untuk mengatakannya sekarang, tetapi saya pikir itu adalah sesuatu yang saya tidak akan bisa hidup tanpanya.

Bisakah Anda memotong beberapa tangkapan layar dari antarmuka itu @SuperGeniusZeb?

@chrisvanpatten Tidak, saya hanya memiliki akses sementara saat membantu seseorang.

Saya tidak benar-benar merasa sangat baik pada bilah alat pemformatan tetap / tidak tetap, tetapi saya akan condong ke arah tetap karena itu akan membantu mengurangi kekacauan visual di sekitar blok. Berdasarkan umpan balik pengguna, apa yang disukai orang lain dan mengapa?

@chrisvanpatten Menemukan artikel tentang seseorang yang berbicara tentang pembuat email di Infusionsoft dan memiliki videonya:

https://www.monkeypodmarketing.com/the-new-email-builder/

@chrisvanpatten Argh, Saya baru saja memeriksa dan sepertinya video itu sudah ketinggalan zaman ... sepertinya saat itu bilah alat pemformatan dilampirkan ke blok, seperti yang dilakukan Gutenberg sekarang. Menarik bahwa mereka mengubahnya.

Beberapa pemikiran:

Jika Anda akan memasukkan blok di tengah posting, Anda biasanya ingin melakukannya _setelah_ yang telah Anda pilih, bukan? Anda biasanya tidak ingin memasukkan _before_ blok yang dipilih. Memasukkan setelah pemblokiran juga masuk akal dari perspektif aksesibilitas. Apakah ada yang tidak setuju dengan ini? Bagi saya, ini sepertinya argumen kuat yang mendukung adanya penyisipan saudara kandung yang muncul di suatu tempat di dekat bagian bawah blok.

Penyisipan saudara tidak boleh tumpang tindih dengan konten blok yang dipilih. Tidak ada yang boleh secara permanen tumpang tindih dengan konten dari blok yang dipilih. Apakah ada yang tidak setuju dengan ini? Hal ini membuat saya percaya bahwa penyisipan saudara harus diposisikan di luar konten blok yang dipilih.

Saya menunjukkan hal ini karena saya pikir di mana pun kontrol gerakan dan elipsis harus pergi, penyisip saudara tampaknya harus muncul di semacam bilah alat di bawah blok yang dipilih, bahkan jika itu semua dengan sendirinya dan / atau bilah alat memiliki tanpa batas / latar belakang. Saya kira itu bisa terlihat hampir persis seperti sekarang, tetapi bergeser ke bawah dan berubah untuk muncul di bawah blok, bukan di atasnya.

Pemikiran lain: apakah lebih baik daripada master untuk meletakkan elipsis di sisi yang sama dengan panah pergerakan atau sebaliknya? Itu bisa menyelesaikan banyak masalah dengan kontrol yang tumpang tindih dalam konteks bersarang, dengan biaya memiliki jumlah UI blok yang lebih tinggi di sisi kiri (atau kanan) blok.

Saya baru saja mencoba # 8836. Saya pikir jika digabungkan, ini dapat membantu mengurangi masalah UI yang berat / kuning yang tampaknya dimiliki oleh banyak desain UI di tiket ini.

Di tiket # 9074 dan # 9075, saya menyarankan dua langkah kecil, terinspirasi oleh diskusi ini, untuk mengurangi dan memperbaiki situasi. Yang pertama sarannya adalah kita memindahkan tombol Ellipsis / More ke toolbar, jadi kita hanya memiliki satu sisi-UI (penggerak), dan di sisi lain ada proposal untuk membiarkan blok toolbar menciutkan setions agar lebih pas konteks tipis.

Hanya untuk menjaganya tetap mutakhir, saya memperbarui maket saya untuk memperhitungkan perubahan yang diusulkan oleh tiket @jasmussen dan perubahan UI terbaru di 3.6:

Sebenarnya, memindahkan penggerak panah ke bawah blok bahkan mungkin tidak diperlukan lagi jika # 9074 dan # 9075 diterapkan. Mungkin baik-baik saja jika mereka tetap berada di sisi blok, karena elipsis dari blok yang berdekatan tidak akan lagi tumpang tindih dalam hal-hal seperti kolom. Jika solusi untuk # 8880, # 8881, dan # 8883 terjadi, dan jika # 8836 dan # 8920 diterapkan, mungkin UI sudah baik-baik saja untuk konteks bersarang. Saya mulai condong ke arah itu, tidak masalah jika panah atas / bawah tetap berada di sisi kiri blok.

Meskipun demikian, saya masih berpikir bahwa saudara kandung yang masuk pasti berada di bawah blok , meskipun Anda pasti bisa membuat saudara kandung itu muncul sendirian di bawah blok. Mungkin itu bisa dipusatkan seperti penyisip saudara saat ini, tetapi bertindak dan terlihat seperti kontrol gerakan naik / turun, muncul sebagai tombol mengambang di bawah blok saat Anda mengarahkan kursor ke bagian bawah blok.

Mari fokus untuk mendapatkan iterasi di @jasmussen yang sedang dikerjakan di # 9074 dan # 9075, kemudian kita dapat mempertimbangkan langkah selanjutnya. Saya benar-benar ingin mengubah banyak hal tetapi mari kita seimbangkan.

Berkat # 9074 dan # 9075 yang disebutkan di atas, serta masalah dan PR lain seperti # 8920 dan # 9197, saya telah memutuskan bahwa memindahkan penggerak panah ke bawah blok tidak lagi memiliki banyak manfaat.

Sebagai gantinya, saya sekarang mengusulkan agar hanya penyisip saudara yang dipindahkan ke bawah blok, bertindak dan tampil sebagai kontrol mengambang yang mirip dengan penggerak naik / turun. Lihat # 9202.

Mari kita tutup yang ini untuk saat ini karena banyak perbaikan telah muncul dari diskusi ini dan lainnya. Beberapa perbaikan terakhir yang harus dilakukan ada di sekitar bagian dalam yang tertinggal.