Gutenberg: Layar blokir widget di wp-admin

Tampilan widget saat ini pasti dirancang dengan mempertimbangkan sidebar, tetapi area widget (sekarang area blok) juga bisa berupa footer, header, dll. Menurut saya, itu adalah satu hal yang harus dipertimbangkan saat memperbarui halaman ini.

Memiliki semua widget / area blok yang dapat diedit pada satu halaman terasa aneh. Saya pikir layar ini harus bekerja lebih seperti editor area widget di Customizer. Khususnya, satu keuntungan dari halaman Widget wp-admin Widget saat ini adalah Anda dapat menarik dan melepas widget dari satu area widget ke area lainnya. Saya tidak yakin bagaimana Anda akan mereplikasi fungsi ini jika layar Widget menjadi lebih seperti Penyesuai. Mungkin area widget akan ditampilkan sebagai tab di bilah atas atau bilah sisi, dan menyeret blok ke tab ini akan mengalihkan tampilan ke area blok itu ... seperti bagaimana Anda dapat menyeret teks / gambar dari satu tab ke tab lainnya di browser web atau dari satu aplikasi ke aplikasi lainnya di sebagian besar OS.

Dan jangan lupa tentang area widget yang tidak aktif ... bagaimana bisa cocok dengan semua ini? Saya memahami tujuannya, tetapi rasanya seperti hal yang aneh untuk dimiliki dalam konteks layar Widget dengan Gutenberg.

Selain itu, pemilihan blok di sebelah kiri tampaknya agak aneh. Saya pikir itu harus berubah menjadi campuran penyisip blok di editor posting dan penyisip widget Customizer. Ngomong-ngomong, ini sepertinya peluang bagus untuk menambahkan penyisipan seret dan lepas ke penyisip blok. Editor area widget saat ini di wp-admin dan Customizer memiliki penyisipan drag-and-drop, tetapi penyisip blok di editor posting saat ini tidak. Lihat # 1511.

Juga, maket ini tampaknya tidak memperhitungkan pemeriksa blok. Itu mungkin akan muncul di sisi kanan layar seperti di editor posting.

Secara umum, halaman Widget di wp-admin terasa aneh, dan bahkan terasa lebih aneh di mockup saat ini.

Apakah kita akan mencampur widget dan blok atau apakah kita pada dasarnya menghentikan widget?

Saya pikir mereka ingin mengganti widget dengan "blok widget" - sesuatu antara blok dan widget.
Dan mungkin tema diganti dengan alat pembuat halaman gutenberg, waktu akan menjawab ...

@nicholasio Saya pikir rencana saat ini adalah bahwa area widget akan menjadi area blok, dan akan ada blok "Widget Lama

Jadi pada dasarnya, widget sudah tidak digunakan lagi, tetapi Anda masih dapat menggunakannya bersamaan dengan pencekalan.

Tampilan widget saat ini pasti dirancang dengan mempertimbangkan sidebar, tetapi area widget (sekarang area blok) juga bisa menjadi footer, header, dll.

Saya ingin tahu apakah kita bisa menjelajahi bagaimana "area" itu ditampilkan di halaman itu sendiri. yaitu. jika itu adalah area sidebar, itu ditampilkan seperti sekarang, tetapi jika itu adalah footer atau header, itu akan ditampilkan di mana header / footer akan berada. Jadi itu menjadi tata letak kasar dari halaman itu sendiri. Aku akan mengejek sesuatu.

Selain itu, pemilihan blok di sebelah kiri tampaknya agak aneh.

Sebagai akordeon, ini kemungkinan besar akan runtuh dan tidak akan terlalu berlebihan.

Juga, maket ini tampaknya tidak memperhitungkan pemeriksa blok. Itu mungkin akan muncul di sisi kanan layar seperti di editor posting.

Saya pikir Anda ada di sini. Saya akan mendapatkan beberapa mockup untuk memulai lebih banyak percakapan.

Selain itu, pemilihan blok di sebelah kiri tampaknya agak aneh.

Sebagai akordeon, ini kemungkinan besar akan runtuh dan tidak akan terlalu berlebihan.

Apa yang mengganggu saya adalah tidak terlihat seperti bagian dalam editor posting. Mengapa inserter menjadi sidebar yang selalu terlihat di halaman Widget tetapi menjadi pop-up di editor posting? Di sisi lain, mungkin editor posting harus dapat dipasang ke sisi seperti sidebar perpustakaan widget? Apapun masalahnya, saya pikir perlu ada konsistensi dengan bagaimana penyisip blok muncul dalam konteks yang berbeda.

Penting juga untuk dicatat bahwa desain pustaka widget / blok tidak bekerja dengan baik di seluler dibandingkan dengan gaya penyisip editor pos. Mungkin penyisipan sidebar yang dipasang ke dok harus berubah menjadi penyisipan pop-up di seluler?

Saya mencoba menggunakan Figma untuk beberapa pembuatan prototipe. Inilah konsep yang saya susun. Saya ingin melihat apakah ada cara lain agar kami dapat menampilkan "widget-area" secara kontekstual daripada menumpuknya di atas satu sama lain. Ini akan menggantikan /widgets.php di wp-admin.

Prototipe

https://www.figma.com/proto/O6SyONtxLjcUxsHq59EfStPs/integration-widgets?node-id=0%3A1&scaling=min-zoom

Video

Pikiran?

@mapk Saya tidak yakin bagaimana maket itu akan diterapkan dalam praktiknya. Area widget dapat muncul di lokasi yang berbeda tergantung pada template halaman, dan tentu saja beberapa area widget hanya akan muncul di template halaman tertentu. Mencoba menyesuaikan semua area widget ke satu layar dengan cara yang masuk akal akan sulit diterapkan, kecuali Anda hanya mencoba menampilkan tata letak satu template halaman dalam satu waktu (dengan kemampuan untuk beralih di antaranya).

Sepertinya akan lebih produktif untuk mengindahkan saran dari tombol "Kelola dengan Pratinjau Langsung" di layar widget. Tautan itu adalah langkah pertama dalam menghentikan layar admin demi versi penyesuai dengan pratinjau langsung. Layar admin widget memiliki keterputusan mendasar dengan cara area widget benar-benar bekerja - dengan area berbeda yang ditampilkan di berbagai bagian layar dan berpotensi di berbagai bagian situs.

Akan sangat sulit untuk secara jelas merefleksikan struktur halaman depan pada layar ini dengan cara yang dapat dipahami oleh pengguna. Bereksperimen dengan pendekatan kontekstual untuk pengalaman ini di penyesuai menawarkan banyak peluang agar masalah mendasar ini diselesaikan. Dimulai dengan pintasan edit yang sudah ada di inti, widget yang dirubah dapat diedit langsung di frontend (pratinjau kustomisasi) atau di hamparan yang lebih terkait langsung dengan tampilan di layar tertentu. Kemampuan untuk menavigasi ke berbagai bagian situs dalam pratinjau ubahsuaian memecahkan masalah yang tidak akan pernah bisa diatasi layar ini.

Saya sarankan untuk mengabaikan proposal ini dan menutup masalah ini demi # 13205.

Mencoba menyesuaikan semua area widget ke satu layar dengan cara yang masuk akal akan sulit diterapkan

Sepakat. Saya pikir prototipe itu, bagi saya, adalah cara untuk lebih menyaringnya.

Layar admin widget memiliki keterputusan mendasar dengan cara sebenarnya area widget bekerja

Ini benar, dan alasan eksplorasi di atas. Saya sangat setuju!

Saya sarankan untuk mengabaikan proposal ini dan menutup masalah ini demi # 13205.

Layar ini adalah area fokus dari Fase 2 , jadi menurut saya ini tidak akan terjadi. Saya yakin tujuan di balik mengubahnya menjadi "blok" adalah untuk membantu pengguna memahami perubahan paradigma dari segala sesuatu menjadi blok.

Meskipun layar ini pada akhirnya tidak akan digunakan lagi di masa mendatang, terutama karena semakin banyak situs yang dibangun di Gutenberg, "langkah kecil" yang diperlukan untuk menyatukan kita semua di sana. Mungkin yang terbaik adalah mempertahankan tata letak yang ada, tetapi hanya mengizinkan penggunaan semua blok dalam area konten akordeon? Ini akan menjaga sumber daya dan investasi kami minimal pada bagian khusus ini dengan hanya beberapa penyesuaian yang disarankan pada mockup di posting awal. Ini juga akan memungkinkan kami untuk pindah ke Penyesuai lebih cepat.

Saya sarankan untuk mengabaikan proposal ini dan menutup masalah ini demi # 13205.

Pertimbangan yang sama telah dibuat untuk layar Menu, lihat https://github.com/WordPress/gutenberg/issues/13206#issuecomment -455452477. Penyesuai tidak dapat diakses sepenuhnya. Layar widget admin adalah satu-satunya tempat di mana orang dengan kebutuhan aksesibilitas memiliki kesempatan untuk mengelola widget tanpa harus menghadapi hambatan aksesibilitas yang besar.

Saya juga ingin mengingatkan semua orang bahwa layar Widget memiliki "mode aksesibilitas" alternatif (cukup klik link di kanan atas). Saya benar-benar mendukung untuk menghapus mode aksesibilitas jika layar admin baru dibangun dengan mempertimbangkan aksesibilitas sejak awal. Artinya, sebagai permulaan: tidak ada hal-hal yang mewah, buat sesederhana mungkin.

Cara yang baik untuk mulai menangani aksesibilitas _sebelum maket visual apa pun_ adalah merancang arsitektur informasi terlebih dahulu. Pikirkan layar ini sebagai dokumen kosong di mana informasi perlu diatur dengan tajuk untuk mengidentifikasi bagian dan tugas utama, mengelompokkan kontrol yang terkait secara logis, dan memastikan informasi yang dirasakan masuk akal saat menavigasi konten dengan cara yang linier.

Re: pemilihan blok di sebelah kiri:

Sebagai akordeon, ini kemungkinan besar akan runtuh dan tidak akan terlalu berlebihan.

Apakah ada kebutuhan nyata untuk keseluruhan bagian kiri? Saya cenderung berpikir konsistensi dengan desain yang diusulkan di # 13206 untuk layar Menu itu penting. Mungkin saya melewatkan sesuatu tetapi hanya memiliki area Widget dengan penyisip akan sangat menyederhanakan antarmuka pengguna. Ini juga akan memungkinkan untuk menghilangkan drag and drop antara bagian kiri dan kanan, yang akan menjadi kemenangan aksesibilitas.

Meskipun demikian, menurut pemahaman saya, semua widget inti akan diblokir. Namun, apa yang terjadi dengan widget khusus yang ditambahkan oleh plugin dan tema? Tidak semuanya akan segera diperbarui menjadi blok. Apakah ada kebutuhan akan mekanisme kompatibilitas mundur seperti dalam kasus kotak meta? / Cc @youknowriad

Meskipun demikian, menurut pemahaman saya, semua widget inti akan diblokir. Namun, apa yang terjadi dengan widget khusus yang ditambahkan oleh plugin dan tema?

Idenya adalah untuk membangun blok widget klasik yang mampu menampilkan edit dan pratinjau widget apa pun (seperti sekarang) https://github.com/WordPress/gutenberg/issues/4770

Ini juga akan memungkinkan untuk menghilangkan drag and drop antara bagian kiri dan kanan, yang akan menjadi kemenangan aksesibilitas.

Secara teknis, akan lebih mudah / cepat untuk tidak mendukung seret dan lepas karena saat ini, kami tidak dapat memiliki penyisip tunggal yang menargetkan beberapa editor.

Idenya adalah untuk membangun blok widget klasik yang mampu menampilkan edit dan pratinjau widget apa pun (seperti sekarang) # 4770

+100
Inilah yang kita butuhkan juga. Terima kasih sudah memikirkan hal ini!

Bagaimana dengan bereksperimen dengan cara menampilkan widget secara berbeda di berbagai bagian situs? Saya menyebutkan beberapa kasus penggunaan penelusuran di https://make.wordpress.org/core/2018/12/08/gutenberg-phase-2/#comment -35058

Posting ini juga menunjukkan beberapa kasus penggunaan di mana ada tata letak yang berbeda tergantung pada jenis halaman pengguna: halaman rumah, halaman tunggal, atau posting tunggal. Saya pikir halaman arsip, 404, dll juga merupakan kasus penting.

Memiliki semua widget / area blok yang dapat diedit pada satu halaman terasa aneh.

Ini adalah salah satu keunggulan terbesarnya dibandingkan Penyesuai. Anda dapat melihat semua widget yang ditetapkan ke semua area sekaligus. Bagi saya, Customizer sangat membatasi.

satu keuntungan dari halaman Widget wp-admin saat ini adalah Anda dapat menarik dan melepas widget dari satu area widget ke area lainnya.

Saya tidak ingin kehilangan kemampuan ini! Saya sering menggunakannya, dan tema yang saya tulis didasarkan pada kemudahan melakukan ini. Ini termasuk widget yang tidak aktif. Jika Anda menggunakan akordeon atau menyembunyikan beberapa area widget, Anda membatasi penyesuaian, seperti di Penyesuai.

Dan jangan lupa tentang area widget yang tidak aktif

Tolong jangan singkirkan ini. Ini penting untuk peralihan tema, yang mungkin terjadi secara terprogram. Tetapi juga penting untuk dapat mengambil info yang mungkin telah dimasukkan saat menggunakan tema yang berbeda. Tidak memiliki akses ke widget yang tidak aktif adalah masalah terbesar dalam menggunakan Penyesuai untuk widget.

Mengapa widget harus diubah menjadi blok? Bukankah mereka sudah menjadi sejenis blok, dan blok baru sekarang menyusul mereka? Mengapa menyingkirkan API yang sudah begitu mengakar? Mengapa beralih ke mendefinisikan "area konten" jika kita sudah memiliki area widget dan konten? Mengapa mengulang segalanya untuk "anak baru" ketika anak baru bisa dengan mudah menyesuaikan diri dengan yang ada?

Mengapa widget harus diubah menjadi blok? Bukankah mereka sudah menjadi sejenis blok, dan blok baru sekarang menyusul mereka?

Anda benar, @ dengan gembira. Widget sudah seperti balok. Namun mereka tidak dapat ditambahkan dengan mudah di manapun pada halaman, terutama di Gutenberg. Mengubahnya menjadi blok memecahkan masalah ini. Blok widget sekarang diperlakukan sama dengan blok lain dan dapat ditambahkan di mana saja di dalam Gutenberg. Layar widget di wp-admin berubah untuk mencerminkan ini dan membantu semua orang memahami paradigma blok.

Inilah prototipe dari apa layar ini bisa. Silakan bergabung dengan umpan balik.

1. Mengubah kata-kata dari "Widget" menjadi "Widget-blok" untuk membantu mengkomunikasikan perubahan tersebut.
2. Menjaga fungsionalitas layar widget saat ini.
3. Menggunakan block-inserter Gutenberg di panel yang meledak. Saya pertahankan warna putih ini sehingga itu merupakan perubahan yang jelas dan juga meniru block-inserter Gutenberg.
4. Area blok widget masih ditampilkan seperti biasa, tetapi mencerminkan _blocks_ mirip dengan editor Gutenberg. Faktanya, mereka seperti mini-Gutenberg. 😉
5. Saya kehilangan Inspektur (bilah samping Gutenberg) dari ini yang mungkin harus dipikirkan lebih lanjut. Jika layar widget akan menyertakan semua yang dilakukan Gutenberg untuk berinteraksi dengan blok (toolbar, penyisip, inspektur) daripada mungkin ini menjadi layar Gutenberg yang lebih besar yang memungkinkan untuk semua ini.

Prototipe:

https://wp.invisionapp.com/share/VYQ6PWPWTH3

Video prototipe:

Aksesibilitas

Saya ingin review a11y dari pemikiran ini. Apakah block-inserter Gutenberg memenuhi kebutuhan a11y? Jika demikian, apakah prototipe ini berfungsi sehubungan dengan a11y? Seorang pengguna harus dapat memasukkan sebuah blok langsung dari area widget yang baru sekarang.

Mengapa mencampur widget-blok dengan blok ?
Mereka harus dipisahkan saya pikir ...

Seperti Paragraf atau Heading - bukan widget-blok ...
Mengapa tidak membuat sebagai gantinya Editor Teks atau blok widget Editor Gutenberg yang akan memiliki semua blok ini di dalamnya ...?

Mengapa mencampur widget-blok dengan blok?

Itu hal yang hebat di sini! Karena semakin banyak WordPress yang dapat diedit dalam antarmuka Gutenberg, Anda akan dapat menambahkan blok di mana pun Anda mau. Saya menggunakan kata-kata "widget-blok" hanya untuk membantu melakukan transisi ke arah ini. Akhirnya, istilah "widget" tidak akan digunakan sama sekali karena semuanya akan menjadi blok. Itu masih jalan keluar.

Tapi mungkin kata-katanya seperti ini bisa menyebabkan lebih banyak kebingungan?

Mengapa tidak membuat sebagai gantinya Editor Teks atau blok widget Editor Gutenberg yang akan memiliki semua blok ini di dalamnya ...?

Saya tidak yakin saya mengikutinya, tetapi ada blok Widget Klasik yang sedang dikembangkan (# 4770) yang akan bertindak seperti blok (dapat ditambahkan di mana saja dalam antarmuka Gutenberg), tetapi berisi widget yang belum diubah menjadi blok.

Apa konteks mockup Anda? (Karena tidak ada pratinjau, saya anggap itu adalah halaman admin.) Pada halaman admin saat ini, widget yang tidak memerlukan konfigurasi langsung dapat dilihat di front end. Apakah itu yang terjadi di mockup Anda? Jika tidak, di manakah tombol Simpan? Saat ini, terdapat tombol Simpan untuk setiap widget.

Di manakah Widget Tidak Aktif? Bisakah Anda memindahkan widget dari satu area ke area lain?

Di manakah deskripsi yang dapat ditentukan untuk widget?

Mengapa pemblokiran menuju ke area widget pertama saat Anda mengkliknya di kolom kiri? Ada dua area widget yang terbuka, bagaimana Anda tahu kemana perginya? Apakah + hanya untuk blok GB? Atau untuk semua yang Anda miliki di sebelah kiri?

di mana tombol Simpan? Saat ini, terdapat tombol Simpan untuk setiap widget.

Ini akan otomatis menyimpan seperti Gutenberg. Saya menyadari widget memiliki tombol simpan, tetapi perlu diingat ini bukan widget lagi, mereka diblokir dan akan berfungsi sama seperti blok sekarang di Gutenberg.

Di manakah Widget Tidak Aktif? Bisakah Anda memindahkan widget dari satu area ke area lain?

Tangkapan yang bagus. Widget tidak aktif adalah sesuatu yang masih perlu dipikirkan. Bagaimana kami ingin menampilkan widget ini, dan widget lain yang belum diubah menjadi blok? Mungkin ada bagian yang memasukkan ini?

Di manakah deskripsi yang dapat ditentukan untuk widget?

Meskipun ini adalah blok, bukan widget, deskripsi mungkin akan ditentukan di inspektur seperti sekarang di Gutenberg. Saya menyebutkan inspektur di # 5 di sini .

Mengapa pemblokiran menuju ke area widget pertama saat Anda mengkliknya di kolom kiri? Ada dua area widget yang terbuka, bagaimana Anda tahu kemana perginya?

Saya tidak tahu cara membuat antarmuka drag n drop di dalam perangkat lunak prototipe. Jadi saya hanya menggunakan referensi "klik" untuk mencoba dan mengkomunikasikan tindakan tersebut. Ini tidak sempurna, tetapi saya benar-benar berharap semua orang dapat menemui saya di tengah jalan ketika saya menyebutkan "Menjaga fungsionalitas layar widget saat ini." dan memahami bahwa itu akan menjadi tindakan seret dan lepas.

Apakah + hanya untuk blok GB? Atau untuk semua yang Anda miliki di sebelah kiri?

Segala sesuatu di sebelah kiri adalah satu blok. Seperti disebutkan, salah satu fokus untuk Tahap 2 adalah mengubah widget menjadi blok.

Saya harap penjelasan itu membantu.

Saya sangat ingin menyeret dan melepas ketika menonton GIF itu, selain itu, tidak jelas bilah sisi mana yang akan ditambahkan blok ketika diklik. Saya suka bagaimana sisi kiri setinggi penuh

Deskripsi awal adalah:

Langkah pertama untuk fase 2 akan melibatkan peningkatan UI widget untuk memasukkan editor blok modern yang konsisten dengan cara Anda mengedit halaman dan posting di Gutenberg

Saya pikir ini salah arah. Pertama, membingungkan jika semuanya terlihat sama ketika tugasnya sangat berbeda. Dan widget tidak sama dengan mengedit posting atau halaman. Seharusnya terlihat berbeda, lebih seperti sebelumnya.
Kedua, Anda belum membahas arsitektur yang mendasari. Jika Anda ingin mengubah cara widget selesai, apakah Anda mengubah cara penyimpanannya? Apakah Anda mengubah cara penulisannya? Apakah Anda mengubah cara tema mengeluarkannya?
Widget inti telah menjadi blok. Blok tidak harus menjadi widget.
Apa tujuan sebenarnya di sini? Jika Anda hanya ingin membuat halaman widget terlihat seperti halaman editor, menurut saya itu ide yang buruk. Jika Anda ingin mengatur ulang hal-hal hanya untuk membuatnya berbeda, menurut saya itu bukan penggunaan sumber daya yang baik. Jika Tahap 2 benar-benar lebih banyak tentang Penyesuai, maka mungkin halaman widget ini harus dibiarkan saja, dan desain antarmuka baru di Penyesuai harus menjadi tujuan ... tetapi ini menimbulkan pertanyaan yang sama.

Apakah block-inserter Gutenberg memenuhi kebutuhan a11y?

Semacam. UI Gutenberg adalah hasil dari banyak pertukaran yang tidak mengarah pada aksesibilitas yang bagus.

Jika area widget akan menggunakan penyisip, saya tidak yakin saya mengerti mengapa seluruh kolom kiri harus tetap ada. Bagi saya, ini sepertinya UI duplikat.

Saya juga menyarankan untuk mempertimbangkan untuk tidak secara membabi buta menggunakan kembali beberapa pola yang digunakan di Gutenberg, karena mereka tidak terlalu baik untuk aksesibilitas. Di Gutenberg ada banyak pertukaran, terutama karena ruang yang sangat terbatas di beberapa bagian UI.

Sebaliknya, di layar ini tidak ada batasan karena minimnya space. Secara spesifik, sebagai pertimbangan awal:

• tombol yang hanya menggunakan ikon bermasalah: tidak ada alasan untuk menggunakan tombol "+" di layar ini, ada cukup ruang untuk menggunakan tombol dengan teks
• jika kolom kiri tetap ada: di bidang pencarian, placeholder tidak boleh digunakan sebagai pengganti label yang terlihat, ini adalah pola yang sangat kontroversial dan perancang harus menyadari bahwa hal itu menciptakan hambatan aksesibilitas

Selain itu: "Kelola dengan Pratinjau Langsung" di bagian atas selalu menyakiti perasaan saya 🙂 mungkin ini adalah kesempatan yang baik untuk memikirkannya kembali.

Menghabiskan beberapa menit pagi ini memikirkan hal ini, dan saya ingin membagikan mockup hybrid lain untuk diskusi lebih lanjut:

Prototipe
https://www.figma.com/proto/WdbvnvIHDFbgVDWwkyNCqFA7/Gutenberg-Widgets-Admin-Screen?node-id=14%3A297&viewport=-818%2C1575%2C0.5&scaling=min-zoom

GIF

_Ini tautan Figma jika ada yang ingin memperluas ide ini._

• Itu membuat Gutenberg tetap ada di bilah alat dan bilah sisi atas, jadi menambahkan dan mengedit blok sudah biasa. Kami juga dapat menyertakan indikasi penyimpanan otomatis Gutenberg, dll.
• Sementara bingkai pengeditan sangat Gutenberg-ey, Anda mengedit dalam wadah widget kecil seperti yang biasa dilakukan semua orang.
• Daripada menggunakan tombol penyisip blok kecil standar, saya telah menyertakan tombol [ + Add block ] lebih besar dan lebih jelas di dalam setiap wadah (terinspirasi oleh tombol Tambah di galeri gambar).
• Ini mencakup area widget yang tidak aktif juga.

@kjellr Menurut saya mockup itu cukup bagus. Berikut beberapa hal yang ingin saya tambahkan / ubah:

Untuk apa tepatnya bagian "Widget Area" dari inspektur digunakan? Jika ada, saya mungkin mengharapkan tab "Area Widget", daripada tab untuk semua area widget sekaligus.

Mengikat apa yang baru saja saya tunjukkan, saya lebih suka jika setiap area widget / blok diedit secara terpisah. Dengan begitu, lebar konten dapat disesuaikan agar sesuai dengan setiap area blok, sehingga memberikan pengalaman WYSIWYG yang lebih banyak. Arah aliran blok (vertikal untuk sidebar vs. horizontal untuk header dan footer) juga dapat disesuaikan.

Blok tidak aktif masih bisa ditampilkan di bagian bawah, mirip dengan bagaimana metabox ditampilkan di bagian bawah editor posting. Saya mempertanyakan kegunaan fitur widget / blok yang tidak aktif dalam konteks Gutenberg. Sistem Blok yang Dapat Digunakan Kembali sudah dapat bertindak sebagai semacam penyimpanan untuk blok yang telah dikonfigurasi sebelumnya, jadi mungkin seluruh gagasan widget yang tidak aktif harus dievaluasi ulang.

Saya pikir akan lebih rapi jika Anda dapat memasang penyisip ke samping di desktop sebagai bilah sisi dengan tinggi penuh, dan menggunakannya mirip dengan pustaka widget di layar Widget saat ini. (Kemampuan docking ini juga harus ada di editor posting, tentu saja.)

Selain itu, seperti yang disebutkan @afercia , bilah pencarian di bagian dalam (terlepas dari apakah dapat

Placeholder / button-thingy "Tambahkan blok" terlalu besar menurut saya. "Tambahkan blok" dapat disingkat menjadi "Tambahkan blok" dan dipindahkan ke kanan ikon. Sebenarnya, menurut saya, non-Paragraph block appender di editor postingan harus berbagi desain yang sama dengan desain appender yang akhirnya digunakan di UI Widget baru.

Di bilah atas, ikon penyisip (tidak ditampilkan di mockup tetapi mungkin ada di sana) harus memiliki label di sebelahnya. Faktanya, semua tombol di sana harus memiliki label, dengan opsi di modal Opsi untuk menampilkan / menyembunyikan label. (Ini juga harus ada untuk editor posting, tentu saja.)

Selain itu, seperti yang disebutkan @afercia , bilah pencarian di bagian dalam (terlepas dari apakah dapat

Apakah ada masalah untuk ini? Kedengarannya seperti sesuatu yang perlu kita tangani di tingkat global, bukan di sini.

Di bilah atas, ikon penyisip (tidak ditampilkan di mockup tetapi mungkin ada di sana) harus memiliki label di sebelahnya. Faktanya, semua tombol di sana harus memiliki label, dengan opsi di modal Opsi untuk menampilkan / menyembunyikan label. (Ini juga harus ada untuk editor posting, tentu saja.)

Pertanyaan yang sama.

Untuk apa tepatnya bagian "Widget Area" dari inspektur digunakan? Jika ada, saya mungkin mengharapkan tab "Area Widget", daripada tab untuk semua area widget sekaligus.

Saya tidak sepenuhnya yakin! Mungkin hanya daftar yang dapat diklik dari semua area widget (jika tidak muat di layar). Alasan utama saya memasukkannya pada saat ini adalah untuk mencerminkan hierarki yang kita gunakan di editor posting / halaman: Dokumen / Blok.

Placeholder / button-thingy "Tambahkan blok" terlalu besar menurut saya. "Tambahkan blok" dapat disingkat menjadi "Tambahkan blok" dan dipindahkan ke kanan ikon. Sebenarnya, menurut saya, non-Paragraph block appender di editor postingan harus berbagi desain yang sama dengan desain appender yang akhirnya digunakan di UI Widget baru.

Ini pasti akan diulangi. Ide umumnya hanya untuk memiliki penyisip berbasis non-teks, karena (saya menyimpulkan) bahwa orang akan lebih cenderung menambahkan berbagai jenis konten di sini.

Bagaimanapun, jika kami menggunakan jenis penyisip yang berbeda di sini, kami harus memiliki alasan yang kuat, dan kami harus memberikan pedoman yang jelas untuk menggunakan salah satu atau yang lain untuk mencegah penyalahgunaan.

Mungkin label dapat diberi gaya agar terlihat seperti placeholder pada awalnya, tetapi ketika bilah pencarian difokuskan, ia bergerak ke atas area masukan, seperti cara kerja bidang masukan di UI login Google?

Saya akan merekomendasikan untuk tidak melakukannya. Animasi "label mengambang" membingungkan dan tidak terduga, terutama bagi pengguna dengan kebutuhan aksesibilitas. Selain itu, pola ini tidak menghemat ruang vertikal: masih perlu menyisihkan beberapa ruang di atas bidang. Itu pada dasarnya mengalahkan tujuan utamanya.

Beberapa sumber daya (untuk dan melawan):

• https://medium.com/simple-human/floating-labels-are-a-bad-idea-82edb64220f6
• https://medium.com/@mds/are -float-labels-benar-benar-bermasalah-setelah-semua-da7ffe7d5417
• https://joshuawinn.com/ux-input-placeholder-are-not-labels/
• https://feedbackguru.com/articles/form-without-labels-dont-use-placeholder-text/

Sesuai penggunaan elemen nyata, terlihat, <label> alih-alih placeholder, lihat sumber daya yang ditautkan pada tiket Trac terkait https://core.trac.wordpress.org/ticket/40331

Bisakah kita membuat diskusi tetap fokus pada tujuan masalah ini? @kjellr sepertinya langkah yang baik ke arah yang benar.

Benar-benar mencintai maket , @kjellr! Terima kasih telah memikirkan hal ini.

1. Saya suka antarmuka Gutenberg dan saya bersedia melakukan lompatan ini di layar ini karena menyertakan Inspektur (bilah sisi) secara kohesif. Ini langkah yang perlu.
2. Menjaga agar area widget tetap bertumpuk serupa dengan yang digunakan saat ini mempertahankan tingkat keakraban yang menurut saya juga diperlukan untuk pengguna yang ada saat ini.
3. Mari kita hilangkan kata "widget" dari bilah atas, dan mungkin untuk saat ini, Inspektur hanyalah inspektur "blok". Jadi kami melepaskan "area widget" dari sana. Pada titik ini kami membuat transisi yang solid ke blok dengan cara visual.
4. Apakah navigasi wp-admin masih mempertahankan konvensi penamaan "Widget"? Saya condong ke arah, "ya" sekarang.
5. Saya suka penyisip blok. Satu-satunya saran saya adalah bahwa penyisip di blok galeri menggunakan kasus Kalimat, bukan kasus Judul. Mungkin, yang ini harus menirunya? "Tambahkan blok"

@map

Mari kita hilangkan kata "widget" dari bilah atas, dan mungkin untuk saat ini, Inspektur hanyalah inspektur "blok". Jadi kami melepaskan "area widget" dari sana. Pada titik ini kami membuat transisi yang solid ke blok dengan cara visual.

Sepakat.

Apakah navigasi wp-admin masih mempertahankan konvensi penamaan "Widget"? Saya condong ke arah, "ya" sekarang.

Saya kira dalam jangka panjang halaman ini harus diganti namanya menjadi "Block Area" atau semacamnya? Bahkan mungkin menyebutnya "Blokir Area (Widget)" di navigasi pada awalnya.

Mari kita hilangkan kata "widget" dari bilah atas, dan mungkin untuk saat ini, Inspektur hanyalah inspektur "blok". Jadi kami melepaskan "area widget" dari sana. Pada titik ini kami membuat transisi yang solid ke blok dengan cara visual.

Alasan utama saya menambahkan label itu di bagian atas adalah untuk memasukkan semacam judul halaman atau H1 di sini. Saya kira kita bisa menempatkannya di tempat lain. Mungkin di atas "Area widget", atau di sidebar.

Saya suka penyisip blok. Satu-satunya saran saya adalah bahwa penyisip di blok galeri menggunakan kasus Kalimat, bukan kasus Judul. Mungkin, yang ini harus menirunya? "Tambahkan blok"

Ya. Memperbarui ini dalam file / prototipe Figma. 👍

Itu membuat Gutenberg tetap menjadi bilah alat dan bilah sisi atas

Seperti yang ditunjukkan dalam laporan tim aksesibilitas di Gutenberg , tata letak dengan 1) bilah atas 2) area konten 3) bilah sisi adalah salah satu penghalang aksesibilitas utama karena membuat navigasi keyboard menjadi sangat sulit.

Mengapa ada kebutuhan akan bilah atas di tempat pertama? Apa yang harus ada disana?

Pada fase awal pengembangan Gutenberg, ada diskusi panjang tentang penempatan tombol Simpan / Publikasikan. Menempatkannya di atas tidak ideal untuk aksesibilitas. Tidak ada konsensus tentang itu tetapi, sayangnya, itu berlalu. Saya tidak yakin mengulangi di halaman ini pola yang kurang dari ideal adalah cara terbaik untuk maju.

Linearisasi konten adalah prinsip dasar untuk arsitektur informasi yang baik.

Banyak pengguna melihat konten dengan cara yang dilinierisasi, mengikuti urutan di DOM. Itu benar untuk semua pengguna keyboard dan pengguna pembaca layar. Mengatur informasi dengan cara yang masuk akal ketika dilinierisasi adalah yang terpenting untuk aksesibilitas yang baik.

Alur yang wajar, paling jelas, dan logis biasanya:

• melakukan sesuatu, mengisi kolom dan sebagainya, mengatur pengaturan, dll.
• dan _then_ simpan

Bahkan tidak yakin bahwa tombol "Simpan" diperlukan, tetapi jika ada, tombol dan kontrol "global" lainnya harus berada di akhir pengalaman navigasi linier: di bagian bawah halaman.

Perlu diperhatikan bahwa linierisasi konten juga merupakan prinsip yang mengatur UI seluler, di mana tangan pengguna berada di bagian bawah perangkat 🙂

Sidebar: tidak yakin ada kebutuhan untuk itu.

Kontrol atau pengaturan apa yang harus ada di tab "Area Widget"?

Kontrol apa di tab "Blokir"? Telah ada diskusi sebelumnya tentang pengaturan blok di sidebar: sangat sulit untuk menyimpan blok dalam status "dipilih" dan kemudian melompat ke sidebar untuk mengoperasikan pengaturan blok yang ditempatkan di sana. Ini harus dihindari dengan segala cara.

Terakhir: heading. Mereka masih mekanisme utama yang digunakan untuk menemukan informasi di halaman. Judul memungkinkan pengguna teknologi bantuan untuk melompat ke bagian berbeda dalam halaman. Bergantung pada desain akhir, tajuk perlu digunakan untuk mengidentifikasi bagian utama halaman.

Saya pikir semua eksplorasi ini telah memperjelas bahwa editor posting perlu direvisi. Sebagian besar masalah dengan mengubah halaman Widget menjadi seperti editor posting adalah masalah dengan editor Gutenberg dalam konteks apa pun ... bukan hanya area widget / blokir.

Saya pikir kita harus mengambil kesempatan ini untuk membunuh dua burung dengan satu batu dan merevisi editor Gutenberg saat ini sehingga dapat dengan benar menggantikan layar Widget saat ini dan juga lebih cocok untuk pengeditan posting / halaman dengan menjadi lebih berguna / dapat diakses secara umum.

Apapun masalahnya, saya dengan @afercia karena saya tidak ingin melihat masalah yang sama dengan editor posting diduplikasi ke halaman Widget.

Dalam pikiran saya, semua saran baru saja merusak halaman yang dapat digunakan dengan sempurna, tanpa manfaat.

Beberapa pengeditan kecil untuk arah di atas . Sebagian besar hanya mengganti nama item dan membuktikan sedikit lebih detail.

Prototipe:

https://www.figma.com/proto/WdbvnvIHDFbgVDWwkyNCqFA7/Gutenberg-Widgets-Admin-Screen-Exploration?node-id=14%3A297&viewport=2639%2C1532%2C0.5&scaling=min-zoom

GIF:

• Mengganti nama "Area Widget" menjadi "Area Blok" sesuai catatan @mapk .
• Saya memindahkan judul halaman ke dalam area konten.
• Saya menyimpan sidebar global untuk "Block Area" untuk menjelaskan apa itu, dan juga menyediakan tautan cepat untuk mengedit masing-masing (jika mereka menggulir dari layar, seperti yang ditunjukkan nanti dalam prototipe).
• Mengadopsi pengobatan pelengkap blok alternatif

^ Selain itu, saya bisa melihat ini diterjemahkan ke nav-menus.php dengan cukup mudah.

Maket yang bagus, @kjellr; Saya pikir itu terlihat cukup dekat dengan apa yang mungkin terlihat seperti halaman Block Area baru jika itu didasarkan pada UI editor posting saat ini. Namun, seperti yang dinyatakan sebelumnya, menurut saya editor Gutenberg harus dibuat lebih mudah diakses sebelum mengganti halaman Widget saat ini.

Secara khusus, saya pikir hal berikut harus ditangani sebelum perbaikan halaman Widget:

• # 3976
• # 10519
• # 10524
• # 11581
• # 12254
• # 13309

Selain itu, deskripsi di bagian "Block Area" dari sidebar mungkin harus terbaca

(sebelumnya "Area Widget")

untuk memperjelas bahwa area tersebut tidak lagi disebut area widget.

Juga ... mungkin kita harus menyebutnya "Area Blok Global" daripada hanya "Area Blok"? Secara teknis setiap kemunculan post_content adalah "area blok", jadi istilah "global" dapat membantu memperjelas apa yang dimaksud.

Sebenarnya, sekarang setelah saya memikirkannya ... bukankah area blok global hampir sama dengan blok yang dapat digunakan kembali? Bayangkan ini: di masa depan Anda dapat membuat templat halaman di Gutenberg menggunakan blok yang dapat digunakan kembali untuk header, footer, dan sidebar.

Ini sebenarnya terkait dengan # 13519, bukan? Di masa depan, area blok (global) bisa menjadi tidak lebih dari blok yang dapat digunakan kembali, dan tidak akan ada halaman "Area Blok" sama sekali, tetapi hanya halaman yang berisi daftar blok yang dapat digunakan kembali, serta halaman yang berisi daftar templat halaman ... semuanya dapat diedit dengan Gutenberg.

Untuk jangka panjang, saya rasa halaman "(Global) Block Area" akan ada, tapi maket @kjellr mungkin mendekati apa yang akan terjadi dalam waktu dekat, karena pembuatan / pengeditan template halaman masih jauh di masa depan.

Saya setuju dengan @ZebulanStanphill. Saya ingin melihat masalah lain dipertimbangkan terlebih dahulu dari semua mockup visual, terutama rencana aksesibilitas keyboard yang diuraikan di # 11581. Saran-saran tersebut dibuat dengan berpikir di Gutenberg tetapi beberapa poin juga berlaku di sini.

Namun, sebelum pintasan keyboard khusus atau mekanisme khusus, harap pertimbangkan untuk membuatnya sesederhana mungkin. Harap pertimbangkan linierisasi konten seperti yang dijelaskan dalam komentar sebelumnya.

Saya sangat menghargai upaya dan eksplorasi yang dilakukan di sini, tetapi saya masih belum yakin tentang bilah atas dan bilah samping yang merupakan perhatian aksesibilitas utama. Saya ingin mengingatkan semua orang bahwa halaman ini akan menjadi satu-satunya tempat di mana _semua pengguna_ dapat mengelola widget, karena Penyesuai tidak dapat diakses sepenuhnya.

Karena halaman ini akan menjadi satu-satunya kesempatan untuk mengelola widget untuk pengguna dengan kebutuhan aksesibilitas, seharusnya tidak ada regresi aksesibilitas dibandingkan halaman saat ini. Sebaliknya, kita harus berusaha membuatnya lebih baik 🙂

Judul
h1 harus menjadi hal pertama di konten utama, sebelum hal lain di halaman. Saya tidak melihat ini pada prototipe di atas.

Penghematan
Masih belum jelas bagi saya apakah widget blok baru akan disimpan secara otomatis atau tidak. Widget saat ini perlu disimpan satu per satu, yang menyiratkan beberapa tombol Simpan harus ditempatkan di suatu tempat dan untuk alasan aksesibilitas itu harus _setelah_ blok. Sebaliknya, jika akan ada mekanisme penyimpanan otomatis, tidak perlu tombol Simpan apa pun dan saya rasa bahkan tidak untuk bilah atas.

Ke samping
Adakah yang mempertimbangkan konten panel Bantuan saat ini di halaman ini? Ada beberapa informasi penting di sana. Layak untuk mengevaluasi bagian mana yang perlu disimpan alih-alih menghapus semuanya.

Jika saya dapat menyarankan sesuatu dari perspektif desain: jangan takut untuk meletakkan beberapa teks di halaman 🙂 Tipografi itu indah jika dibuat dengan baik dan beberapa informasi tekstual di dalam halaman bisa sangat membantu.

@ercia

Saya masih belum yakin tentang bilah atas dan bilah sisi yang merupakan perhatian aksesibilitas utama.

Bilah atas dapat diletakkan di bagian bawah dan diberi label tombol secara default, tetapi bagaimana Anda menangani pengaturan inspektur untuk blok tanpa bilah sisi? Apakah Anda punya ide untuk UI alternatif untuk pengaturan pemeriksa blok?

Saya ingin mengingatkan semua orang bahwa halaman ini akan menjadi satu-satunya tempat di mana semua pengguna dapat mengelola widget, karena Penyesuai tidak dapat diakses sepenuhnya.

Saya penasaran: bagian mana dari Customizer yang tidak dapat diakses dengan benar?

Karena halaman ini akan menjadi satu-satunya kesempatan untuk mengelola widget untuk pengguna dengan kebutuhan aksesibilitas, seharusnya tidak ada regresi aksesibilitas dibandingkan halaman saat ini. Sebaliknya, kita harus berusaha untuk membuatnya sedikit lebih baik dengan tampilan_senyum_senyum

Ini seratus kali. Masalah terbesar saya dengan bagaimana WordPress 5.0 ditangani adalah bahwa beberapa hal yang berfungsi dengan baik di editor klasik mengalami kemunduran di Gutenberg ketika mereka tidak perlu melakukannya. Saya benar-benar tidak ingin melihat kesalahan yang sama terjadi lagi.

Masih belum jelas bagi saya apakah widget blok baru akan disimpan secara otomatis atau tidak. Widget saat ini perlu disimpan satu per satu, yang menyiratkan beberapa tombol Simpan harus ditempatkan di suatu tempat dan untuk alasan aksesibilitas itu harus setelah pemblokiran. Sebaliknya, jika akan ada mekanisme penyimpanan otomatis, tidak perlu tombol Simpan apa pun dan saya rasa bahkan tidak untuk bilah atas.

Saya pikir akan sangat baik jika area blok dapat membatalkan / mengulang seperti posting dan halaman. Tetapi jika itu di luar cakupan untuk saat ini, maka menurut saya tombol Simpan tidak diperlukan. Sebenarnya, apakah tombol simpan diperlukan ketika Anda telah membatalkan / mengulang? Mengapa editor posting memiliki tombol "Simpan Draf"?

Salah satu masalah dengan maket saat ini adalah editor posting dirancang untuk mengedit satu posting pada satu waktu ... bukan beberapa. Tombol urungkan / ulangi ada di bilah, tetapi dalam konteks maket saat ini, tombol tersebut harus melacak setiap perubahan yang dilakukan pada area blok mana pun di halaman, bukan hanya satu area blok. Ini adalah salah satu alasan mengapa saya lebih suka jika setiap area blok diedit secara terpisah seperti (atau secara harfiah sebagai) blok yang dapat digunakan kembali yang diakses dari halaman daftar blok yang dapat digunakan kembali.

Jika kita pergi dengan semua area blok pada satu halaman untuk saat ini, maka saya pikir akan paling masuk akal untuk tombol simpan dan / atau batalkan / ulangi untuk pergi ke bagian bawah setiap akordeon area blok.

Adakah yang mempertimbangkan konten panel Bantuan saat ini di halaman ini? Ada beberapa informasi penting di sana. Layak untuk mengevaluasi bagian mana yang perlu disimpan alih-alih menghapus semuanya.

Saya setuju. Aku bertanya-tanya kemana tepatnya itu harus pergi. Apakah ini akan diakses dari tombol "Bantuan" di bilah atas-kecuali-itu-harus-ada-di-bawah? Atau akankah ada tombol "Bantuan" di samping atau di bawah judul halaman? Apakah informasi akan ditampilkan di sidebar-thing atau pop-up?

Saya minta maaf utas ini akan menjadi sangat panjang dan hampir tidak dapat diatur. Mungkin kita harus mencoba untuk tetap lebih pendek tetapi pada titik ini saya cenderung berpikir pertemuan khusus tentang proses desain akan sangat berharga, untuk mencoba menghindari kesalahan yang sama yang dibuat selama fase 1.

Beberapa hal (misalnya arsitektur informasi, linierisasi konten) perlu ditangani sebelum prototipe visual apa pun, jika tidak, saya khawatir tidak akan banyak kemajuan dibandingkan dengan hasil fase 1.

@youknowriad et all: beri tahu saya pendapat Anda, bila ada kesempatan.

Yang mengatakan:

Toolbar atas
Apa seharusnya isi dari toolbar Top? Saya melihat prototipe terakhir menempatkan beberapa tombol yang belum ditentukan di sana. Membandingkan dengan halaman edit posting:

• tombol "Tambahkan blok" tidak masuk akal karena ada kebutuhan untuk memilih area widget terlebih dahulu
• "Urungkan" dan "Ulangi" tidak boleh "global" seperti di postingan edit, keduanya harus per widget. Seperti yang dikatakan @ZebulanStanphill : "editor posting dirancang untuk mengedit satu posting pada satu waktu ... bukan beberapa"
• apakah "Struktur konten" dan "Blokir navigasi" masuk akal di halaman ini? saya rasa tidak
• Simpan / Publikasikan: masih belum jelas (lihat komentar sebelumnya)
• Saya kira tidak perlu tombol "Pengaturan" untuk mengaktifkan Sidebar
• elipsis tombol "lainnya": tidak yakin apakah akan ada "alat dan opsi" untuk laman ini

Prototipe terakhir melewatkan judul h1 di bagian atas halaman, ditambah judul lain di halaman. Beberapa prototipe sebelumnya lebih baik dalam hal ini.

Sidebar:

bagaimana Anda menangani pengaturan inspektur untuk blok tanpa sidebar

Saya akan mengatakan itu harus diperjelas widget mana yang perlu pengaturan terlebih dahulu, dan apa pengaturan ini nantinya.
Jika itu akan menjadi seperti untuk blok-widget di editor, lihat misalnya # 1464, # 1792, # 7941,
lalu kami mengulangi kesalahan yang sama yang dibuat selama fase 1. Pengaturan penting tidak boleh ditempatkan di bilah sisi, karena alasan yang dijelaskan dalam komentar sebelumnya dan dalam laporan tim aksesibilitas .

Saya penasaran: bagian mana dari Customizer yang tidak dapat diakses dengan benar?

Mereka semua? :) Dimulai dengan struktur dokumen, di UI Penyesuai semuanya ada dalam daftar, semua judulnya adalah h3 . Panel geser adalah pengalaman buruk bagi pengguna pembaca layar. Interaksi keyboard sering kali tidak terduga dan memaksa untuk mundur ke tab. Kelimpahan kontrol ikon saja. Banyak hal lainnya.
Penyesuai tidak benar-benar dirancang dengan mempertimbangkan aksesibilitas. Seiring waktu, kami (tim aksesibilitas) telah mencoba untuk menambal penghalang aksesibilitas yang paling penting tetapi masih ada jalan panjang untuk membuat Penyesuai dapat diakses. Ini jelas di luar cakupan masalah ini.

Penghematan:
Saya cenderung menggunakan widget untuk menyimpan otomatis karena itu akan membuat UI dan interaksi lebih sederhana. Tapi itu harus dibuat sangat jelas dengan umpan balik yang terlihat dan terdengar. Salah satu ketidakkonsistenan di seluruh admin WordPress adalah Anda tidak pernah yakin apa yang sudah disimpan dan apa yang memerlukan tindakan penyimpanan manual.

Pikiran bagus di utas ini.

Mari kita mundur sejenak dan melihat gambaran besarnya. Saat meninjau fitur secara terpisah, itu cenderung mengabaikan _destination_. Baik langkah ke tujuan, dan tujuan itu sendiri adalah penting, tetapi yang terakhir harus menginformasikan yang pertama.

Dalam kasus ini, salah satu tujuan fase 2 adalah memperluas di mana blok dapat digunakan . Prinsip pemersatu dari fase 1 tetap: semakin sedikit antarmuka yang harus Anda pelajari, semakin baik, dan blokir dapat menyatukan beberapa antarmuka menjadi satu. Ini juga berlaku untuk editor. Karena editor terus berkembang, blok dapat memasukkan peran yang telah dimainkan widget; area widget dapat memetakan ke area blok, dan widget dapat memetakan ke blok.

Dalam hal itu, menggunakan editor untuk layar Widget (seperti yang telah dieksplorasi Kjell), akan memungkinkan kami untuk meningkatkan satu antarmuka, daripada membagi upaya kami untuk mendukung dua layar dengan tata letak yang sama sekali berbeda.

Apa pun masalah yang ada dengan editor, mari kita perbaiki masalah itu untuk editor dan tingkatkan dua layar alih-alih membuat diri kita tipis. Selain itu, saat kami terus mengeksplorasi menampilkan area blok tambahan langsung di editor, kedua antarmuka ini kemungkinan akan bertemu lebih jauh, memungkinkan seseorang yang nyaman di editor merasa betah di keduanya.

@jasmussen terima kasih, saya sangat menghargai saran Anda untuk melihat gambaran besarnya.

Apa pun masalah yang ada dengan editor, mari perbaiki masalah tersebut untuk editor dan tingkatkan dua layar

Namun, tampaknya Anda tidak menyadari bahwa tata letak umum editor memiliki masalah aksesibilitas mendasar yang memerlukan pemikiran ulang yang baik untuk diselesaikan. Ini telah dijelaskan dengan baik dalam laporan tim aksesibilitas di _October_. Tidak ada trik, tidak ada pintasan keyboard khusus atau alat lain yang dapat menggantikan struktur dokumen dan arsitektur informasi yang baik.

Saya khawatir regresi aksesibilitas di halaman Widget tidak dapat diterima karena alasan yang dijelaskan di atas. Jika halaman ini akan mengadopsi tata letak editor seperti sekarang, akan ada regresi.

Salah satu tujuan fase 2, seperti yang diumumkan di State of the Word, juga untuk membuat berbagai tim di WordPress bekerja sama lebih baik. Desain, aksesibilitas, dll. Adalah semua elemen yang harus diintegrasikan sejak hari pertama.

Dalam hal ini, saya ingin melihat rekomendasi tim aksesibilitas dipertimbangkan sejak awal proses desain fitur baru. Ada hal-hal yang perlu dirancang sebelum desain apa pun 🙂

Saya pasti setuju untuk meningkatkan kedua layar. Ini akan membutuhkan setiap orang untuk menjaga pikiran mereka tetap terbuka dan tidak menganggap apa yang kita miliki sekarang tidak dapat diubah. _Destination_, seperti yang Anda katakan, mencakup juga proses desain yang mampu menangani aksesibilitas sejak awal.

Saya tidak yakin melanjutkan diskusi umum ini di sini adalah tempat yang paling tepat, itulah mengapa saya mengusulkan pertemuan khusus.

Pertanyaan: anggap saja pengaturan widget akan ada di Sidebar seperti yang dilakukan di Editor (catatan: IMHO bukan ide yang baik seperti yang dijelaskan di atas), misalnya:

tangkapan layar dari blok Posting Terbaru dari # 1594 (banyak pengaturan di sana ...)

tangkapan layar dari blok Komentar Terbaru saat ini:

lalu: di mana semua pengaturan ini akan ditempatkan di Customizer? Tidak ada sidebar pengaturan di sana, dan saya sangat berharap tidak melihat tambahan "sidebar geser". Tangkapan layar dari masalah terkait # 13205

Saya sangat menyarankan untuk mempertimbangkan untuk membuat blok-widget memiliki sejumlah pengaturan "di tempat" yang terbatas: di dalam widget.

Saya minta maaf utas ini akan menjadi sangat panjang dan hampir tidak dapat diatur. Mungkin kita harus mencoba untuk lebih pendek

Saya setuju dengan sepenuh hati di sini. Salah satu hal yang dapat membantu adalah menyimpan semua komentar yang terkait langsung dengan masalah tersebut.

Saya masih belum yakin tentang bilah atas dan bilah sisi yang merupakan perhatian aksesibilitas utama.

Mungkin solusinya di sini adalah melepaskan bilah atas sepenuhnya dari layar ini? Apakah bilah atas diperlukan untuk tujuan layar ini? Alasan utama saya melihat tujuannya adalah untuk penyimpanan otomatis. Bisakah itu ditangani di Inspektur? Dan mungkin sekarang untuk satu blok per blok? Saya tidak yakin ini adalah pola yang ingin kami perkenalkan, tetapi perlu ditelusuri terutama untuk membantu a11y.

Saya akan mengatakan itu harus diperjelas widget mana yang perlu pengaturan terlebih dahulu, dan apa pengaturan ini nantinya.

Saya tidak setuju di sini. Layar ini tentang mengintegrasikan blok ke dalam area konten widget sebelumnya. SEMUA blok akan diakses melalui antarmuka ini, jadi pengaturan secara alami merupakan bagian darinya.

Pengaturan penting tidak boleh ditempatkan di bar samping, karena alasan yang dijelaskan di komentar sebelumnya dan dalam laporan tim aksesibilitas.

Ini adalah komentar terkait blok tertentu dan harus benar-benar didelegasikan ke masalah khusus blok tersebut.

Penyesuai tidak benar-benar dirancang dengan mempertimbangkan aksesibilitas.

Setiap komentar Penyesuai yang terkait dengan widget / blok juga harus didelegasikan ke masalah khusus tersebut [# 13205].

@afercia Saya tidak bermaksud untuk menargetkan komentar Anda, dan saya sangat menghargai keprihatinan yang Anda sampaikan dan akan melakukan segala upaya untuk menemukan solusi yang masuk akal yang A) memenuhi standar a11y atau setidaknya membawa kami ke jalan itu, dan B) tetap sejalan dengan pola desain Gutenberg. Mari lakukan yang terbaik untuk menjaga agar masalah ini dapat dikelola semaksimal mungkin dengan komentar yang secara khusus menangani masalah tersebut.

Mengacak prototipe @kjellr , saya membuat beberapa pengeditan.
Membersihkan bilah atas sehingga hanya ada H1 seperti yang diinginkan oleh a11y dan tombol Save yang menyimpan semua area widget ... dan menunjukkan simpan otomatis juga.

Ini adalah pola batang atas yang baru, saya yakin, jadi saya ingin mendengar beberapa pemikiran. Ini masih familiar dengan Gutenberg, tapi saya rasa karena ini adalah langkah menengah menuju pengalaman pengeditan situs lengkap, tidak apa-apa.

Prototipe Figma

https://www.figma.com/proto/R0KYBQGGpdCsqgW2EWFDtK/Gutenberg-Widgets-Admin-Screen-Exploration-v2?node-id=14%3A297&scaling=min-zoom

Saya memutuskan untuk membuat beberapa mockup cepat untuk menjelajahi 2 cara saya melihat pemblokiran halaman Widget menjadi ...

Yang pertama adalah menampilkan semua area blok pada satu halaman:

Saya telah memindahkan bilah atas ke bawah untuk meningkatkan aksesibilitas. Ini sebagian besar kosong, karena sebagian besar tombol biasanya hanya masuk akal dalam konteks mengedit satu area blok ... bukan beberapa.

Saya juga menambahkan label ke tombol di bilah untuk aksesibilitas yang lebih baik. Agaknya, label ini hanya akan muncul di layar lebar, dan akan ada opsi untuk beralih menampilkannya sama sekali, sesuai # 10524.

Maket ini juga mengasumsikan penyimpanan otomatis untuk semua area blok, oleh karena itu tidak ada tombol "Publikasikan" (yang juga kurang masuk akal bila diterapkan ke lebih dari satu area blok).

Agaknya, opsi seperti Mode Spotlight dan Mode Layar Penuh akan ditempatkan di menu Opsi Lainnya, seperti di editor posting.

Maket kedua ini adalah preferensi saya: setiap area blok diedit secara individual seperti posting / halaman. Ini akan kurang familiar bagi pengguna layar Widget yang ada, tetapi akan lebih familiar bagi pengguna editor posting:

Area blok yang berbeda dapat diakses dari halaman daftar area blok (pada dasarnya /wp-admin/edit.php?post_type=block_area ). Seperti biasa, tema akan mengontrol lebar konten, sehingga header / footer dapat terlihat lebar sementara sidebar tampak pendek.

Saya telah menghilangkan Garis Besar Dokumen dari maket ini karena menurut saya tidak masuk akal dalam konteks area blok global, dan juga harus diterapkan sebagai plugin sidebar / modal (dan karena itu dapat disembunyikan di "Opsi Lainnya" menu).

Saya tidak sepenuhnya yakin apa yang akan dilakukan tombol "Bantuan" di kedua mockup. Saya akan menebak bahwa modal pop-up akan muncul, menunjukkan informasi yang sama seperti tombol "Bantuan" di halaman Widget saat ini.

Tombol "Bantuan" mungkin juga ada pada bilah di bagian bawah (sama dengan tombol "Kelola dengan Pratinjau Langsung") ... Saya tidak yakin di mana keduanya.

Saya melihat beberapa masalah dengan hanya menampilkan satu area widget pada satu waktu.

• Sulit untuk memindahkan barang dari satu area ke area lain.
• Sulit untuk memahami apa yang sudah ada di situs jika Anda hanya dapat melihatnya satu per satu.
• Sepertinya terlalu banyak mengedit halaman (kebingungan pengguna).

Apakah ada kebutuhan untuk merender konten? Saya pikir itu bagus untuk memiliki konfigurasi situs seperti yang saat ini ada di halaman widget. Saya dapat dengan mudah melihat semua widget dan mengaturnya ulang. Saya tidak perlu diganggu oleh konten aktual mereka yang menghalangi tampilan konfigurasi. Jika saya ingin melihat bagaimana mereka merender, saya dapat menggunakan Custimzer, di mana perubahan saya tidak dipublikasikan sampai saya siap, dan saya terbatas pada satu area widget pada satu waktu, dan tidak dapat memindahkan widget antar area.

Saya melihat beberapa masalah dengan hanya menampilkan satu area widget pada satu waktu.

• Sulit untuk memindahkan barang dari satu area ke area lain.
• Sulit untuk memahami apa yang sudah ada di situs jika Anda hanya dapat melihatnya satu per satu.
• Sepertinya terlalu banyak mengedit halaman (kebingungan pengguna).

Poin bagus, @ dengan senang hati. Saya kira cara terbaik untuk bergerak maju dalam jangka pendek adalah dengan mengedit semua area blok dari satu halaman.

Di masa depan, saya pikir hal yang sama masih mungkin terjadi, tetapi tidak dengan cara yang sama. Anda harus dapat mengedit beberapa area blok yang semuanya ditampilkan pada template halaman yang sama melalui pengeditan template halaman ... area blok akan menjadi blok yang dapat digunakan kembali yang dapat diedit di sana (atau dalam contoh editor yang berdiri sendiri jika diinginkan) , seperti cara kerja blok yang dapat digunakan kembali. Ini akan menyelesaikan semua masalah yang disebutkan di atas, sekaligus mempertahankan manfaat WYSIWYG dari editor Gutenberg. Pada titik ini, tidak diperlukan halaman seperti halaman Widget saat ini. Tapi yang jelas, kita masih jauh dari itu.

Apakah ada kebutuhan untuk merender konten? Saya pikir itu bagus untuk memiliki konfigurasi situs seperti yang saat ini ada di halaman widget. Saya dapat dengan mudah melihat semua widget dan mengaturnya ulang. Saya tidak perlu diganggu oleh konten aktual mereka yang menghalangi tampilan konfigurasi.

Salah satu prinsip desain Gutenberg adalah bahwa blok yang tidak dipilih menampilkan pratinjau yang seharusnya terlihat seperti front-end, dan blok yang dipilih harus dioptimalkan untuk pengeditan. Jadi idealnya, konten tidak boleh menghalangi konfigurasi. Sayangnya, blok yang setara dari widget yang ada adalah contoh yang hampir sempurna tentang apa yang _not_ harus lakukan.

Berbeda dengan blok Paragraf atau Heading, Anda tidak mengedit konten sesuatu seperti blok Kiriman Terbaru secara langsung. Sayangnya, hal ini mengakibatkan sebagian besar kontrol penting dimasukkan ke inspektur, yang dirancang untuk opsi sekunder / lanjutan. Saya pikir blok seperti itu harus direvisi untuk menunjukkan kontrol penting dalam overlay di atas pratinjau konten saat dipilih, atau pratinjau akan hilang seluruhnya saat blok dipilih. Secara teknis, tidak ada yang menghentikan bentuk blok yang dipilih dan dapat diedit agar tidak terlihat sangat berbeda dari formulir yang tidak dipilih.

Selain itu, untuk mempermudah pemesanan ulang blok, saya pikir menu Block Navigation harus diimplementasikan kembali sebagai sidebar plugin dan memungkinkan penyusunan ulang drag-and-drop (plus mungkin bahkan penghapusan) blok dari UI-nya. Lihat # 11408.

Mungkin solusinya di sini adalah melepaskan bilah atas sepenuhnya dari layar ini?

Saya dapat membayangkan masa depan di mana widget dikelola terutama dari editor itu sendiri. Dengan mempertahankan bilah atas, kami berdua tetap dapat dikenali dari editor - Anda mempelajari satu antarmuka - dan ini memaksa kami untuk melihat masalah aksesibilitas apa pun di root dan memperbaikinya _ secara holistik_ alih-alih memperbaikinya per layar, memecah arsitektur antarmuka.

Saya sangat menghargai Anda menambahkan mockup itu, @ZebulanStanphill! Benar-benar membantu saya memvisualisasikan.

Satu hal yang saya perhatikan adalah yang kami temukan dalam pengujian pengguna sebelumnya (hal 23) adalah bahwa orang tidak memperhatikan bilah publikasi jika berada di bagian bawah layar. Bahkan ketika diingatkan tentang itu, orang-orang lupa itu ada di sana. Beberapa orang mengira itu tampak seperti browser chrome. Saya dapat melihat masalah itu semakin intensif di web seluler, tempat iklan yang dipasang di dok bawah sangat produktif.

kami telah menemukan dalam pengujian pengguna sebelumnya (hal 23)

Maaf, tidak mau berdebat tetapi faktanya pengujian pengguna tidak menyertakan orang dengan kebutuhan aksesibilitas, misalnya pengguna keyboard, pengguna pembaca layar, dan pengguna dengan bidang penglihatan terbatas.

Posisi tombol Simpan di Gutenberg sudah dibahas beberapa bulan lalu, tanpa konsensus. Saya menyadari bahwa _visually_ beberapa pengguna lebih memilih tombol di bagian atas. Namun, dalam pengalaman navigasi linier, posisi tombol saat ini kurang dari ideal karena memaksa pengguna untuk melakukan tab mundur melalui seluruh antarmuka.

Ini masalah yang diketahui, bahkan sebelum Gutenberg karena pola yang sama digunakan di Penyesuai.

Dalam alur logis, dalam aplikasi web apa pun, tindakan penyelamatan berada di akhir alur. Saya tidak mengatakan bilah publikasi di bagian bawah adalah solusi, tetapi ini masih masalah yang membutuhkan solusi yang baik untuk semua pengguna.

Dengan mempertahankan bilah atas, kami berdua tetap dapat dikenali editor - Anda mempelajari satu antarmuka - dan ini memaksa kami untuk melihat masalah aksesibilitas apa pun di root dan memperbaikinya secara holistik alih-alih memperbaikinya pada basis per layar, memecah arsitektur antarmuka.

@jasmussen Ini adil dan saya setuju dengan pendekatan holistik terhadap a11y. Harapan saya adalah bahwa kita tidak menginvestasikan banyak waktu pada layar ini yang kemungkinan akan usang di masa mendatang. Dan a11y di sekitar bilah atas pasti memiliki masalah yang ditetapkan.

Saya akhirnya memasukkan bilah atas dalam prototipe saya, tetapi hanya menghilangkan banyak fungsi yang mungkin tidak berfungsi di layar ini. Apakah menurut Anda ini adalah solusi yang baik, atau apakah Anda merasa bagian lain yang dihilangkan berguna di sini?

Saya akhirnya memasukkan bilah atas dalam prototipe saya, tetapi hanya menghilangkan banyak fungsi yang mungkin tidak berfungsi di layar ini. Apakah menurut Anda ini adalah solusi yang baik, atau apakah Anda merasa bagian lain yang dihilangkan berguna di sini?

Kami benar-benar harus menghapus tombol apa pun di sana yang tidak masuk akal untuk layar widget, pasti.

@bayu_joo
Selain apa yang dikatakan @afercia , saya akan mengatakan bahwa bagian dari masalah dengan bilah bawah di Demo Crazyhorse adalah _really memang_ terlihat seperti pop-up atau browser chrome:

Itu menggunakan warna latar belakang yang bentrok dengan editor lainnya, dan bahkan melapisi navigasi di sebelah kiri. Keduanya menyiratkan bahwa itu sama sekali bukan bagian dari editor, dan karenanya tidak relevan. Itu juga pasti terlalu tinggi. Bandingkan ini dengan bilah atas saat ini di Gutenberg, yang pasti terasa terhubung dengan editor lainnya.

Saya dapat melihat masalah itu semakin intensif di web seluler, tempat iklan yang dipasang di dok bawah sangat produktif.

Saya benar-benar tidak melihat ini menjadi masalah. Banyak aplikasi yang meletakkan kontrol di bilah di bagian bawah layar, misalnya Spotify, Twitter, dan Instagram. Bahkan Gutenberg Mobile sudah menempatkan beberapa kontrolnya di bawah:

Mengingat perbedaan besar antara Crazyhorse Demo dan Gutenberg, menurut saya keduanya hampir tidak bisa dibandingkan. Tapi terima kasih telah menunjukkan pengujian pengguna lama itu; Saya tidak menyadari keberadaannya sebelumnya.

@map

... Saya setuju dengan pendekatan holistik menuju a11y. Harapan saya adalah bahwa kita tidak menginvestasikan banyak waktu pada layar ini yang kemungkinan akan usang di masa mendatang.

Ini masalah besarnya. Kami tidak dapat memasukkan blok ke dalam desain halaman Widget yang ada. Kita seharusnya tidak membuat desain UI terpisah hanya untuk halaman Area Blok baru. Tetapi karena editor pos masih memiliki beberapa kekurangan utama, kami juga tidak dapat menggunakannya kembali. Jadi pada akhirnya, perombakan halaman Widget diblokir oleh editor pos yang perlu ditingkatkan.

Dan a11y di sekitar bilah atas pasti memiliki masalah yang ditetapkan.

Saya setuju.

@jasmussen

Kami benar-benar harus menghapus tombol apa pun di sana yang tidak masuk akal untuk layar widget, pasti.

Untuk halaman yang menampilkan beberapa area blok sekaligus, sebagian besar kontrol di bilah atas tidak lagi masuk akal. Hanya bilah sisi Pengaturan dan menu Opsi Lainnya yang masih masuk akal. Selain itu, plugin seperti Yoast SEO mungkin tidak lagi berfungsi saat diterapkan ke layar dengan beberapa area blok, jadi mungkin plugin harus ikut serta untuk mendukung halaman Area Blok?

Jika kami memperbarui area blok untuk mendukung draf, pembaruan terjadwal, dan urung / ulangi, maka tombol "Urungkan", "Ulangi", "Simpan sebagai Draf", dan "Perbarui" dapat muncul di bawah setiap area blok. Tetapi mengingat bahwa dalam jangka panjang, halaman Area Blok mungkin akan berhenti sama sekali saat templat halaman muncul, saya tidak yakin perlu menerapkan fungsionalitas tambahan itu.

Selain itu, saya pikir kemampuan untuk mengedit area blok secara individual harus ditambahkan, untuk memungkinkan cara mundur untuk mengedit area blok, di mana plugin seperti Yoast SEO yang hanya masuk akal dalam satu editor area blok dapat digunakan jika diinginkan .

Ini masalah besarnya. Kami tidak dapat memasukkan blok ke dalam desain halaman Widget yang ada. Kita seharusnya tidak membuat desain UI terpisah hanya untuk halaman Area Blok baru. Tetapi karena editor pos masih memiliki beberapa kekurangan utama, kami juga tidak dapat menggunakannya kembali. Jadi pada akhirnya, perombakan halaman Widget diblokir oleh editor pos yang perlu ditingkatkan.

Saya memahami perhatian dan setuju dengan hampir semua hal di sini. Namun, saat kami bekerja lebih jauh untuk meningkatkan a11y di bilah atas dan Inspektur, saya yakin kami masih dapat melanjutkan dengan prototipe yang ditata dalam komentar ini secara bersamaan:

https://github.com/WordPress/gutenberg/issues/13204#issuecomment -459175233

@youknowriad , apakah menurut Anda kita bisa mulai

Belum cukup, PR # 13088 ini adalah persyaratan di sini dan kami akan memulai eksplorasi segera setelah mendarat.

Juga ingin diperhatikan bahwa masalah telah dibuat [# 13663] untuk menangani masalah a11y yang dibahas di sini.

Satu perhatian utama yang saya miliki adalah tombol simpan tunggal dan fungsi draf / publikasikan tunggal. Area widget tersebar di seluruh situs pada banyak halaman berbeda, dan memiliki banyak masalah berbeda. Tampaknya jauh lebih logis untuk dapat menerapkan perubahan pada mereka secara individual.

Bayangan ulang area widget ini akan menjadi waktu yang tepat untuk mengisolasinya dengan benar sehingga pengguna dapat menjadwalkan perubahan pada setiap area widget secara terpisah.

Saya baru saja menjawab pertanyaan di forum dukungan tentang cara memindahkan widget tidak aktif ke sidebar dengan lebih baik setelah peralihan tema (menggunakan iPad), dan saya menyadari bahwa halaman Widget ini memiliki Opsi Layar dari mode aksesibilitas. Dengan menggunakan itu, ini hanya menampilkan satu widget pada satu waktu, tetapi memberikan pilihan sidebar mana yang akan dimasukkan, mirip dengan apa yang Anda dapatkan ketika Anda mengklik widget baru tanpa mode aksesibilitas.
Saya ingin memastikan orang lain mengetahui hal ini, sehingga tidak tersesat dalam desain ulang.

Bagaimana cara membuka pengaturan blokir di kotak modal, kode modal yang sama yang digunakan di Gutenberg?
Apakah itu akan mempersulit aksesibilitas.

Personaly Saya pikir Anda akan membuat kesalahan besar jika Anda mencoba meniru desain dan tampilan layar edit Post murni, untuk widget. Anda akan membuat banyak masalah untuk diri sendiri di masa depan.

Sebagai referensi, apakah ini UI yang harus saya geser ke Frontenberg selama fase 2? :)

Ya, @tomjn , ini UI-nya: https://github.com/WordPress/gutenberg/issues/13204#issuecomment -459175233 tetapi saya sangat mengharapkan bit-bit berubah saat kita memasuki pengembangan, terutama dalam kaitannya dengan penyelamatan individu widget-blok.

tidak apa-apa, pastikan saja bahwa halaman admin itu sendiri bagus dan modular sehingga bukan mimpi buruk untuk berjalan di frontend, dengan cara itu Anda dapat melakukan sesuka Anda tanpa harus menulis ulang setiap versi

Menambahkan catatan di sini bahwa tiket trac dimunculkan yang menunjukkan masalah saat pengguna yang berbeda secara bersamaan mengedit widget, mengusulkan sistem penguncian:
https://core.trac.wordpress.org/ticket/12722

Mungkin lebih baik untuk memastikan layar widget baru mendukung solusi penguncian.

Menambahkan catatan di sini bahwa tiket trac dimunculkan yang menunjukkan masalah saat pengguna yang berbeda secara bersamaan mengedit widget, mengusulkan sistem penguncian:

Perlu dicatat bahwa meskipun tiket berikut adalah tentang pengeditan kolaboratif menggunakan WebRTC, banyak ide dan desain telah masuk ke dalam proses, dan konsepnya sama: mengunci blok untuk pengguna yang mengeditnya. Oleh karena itu, mungkin layak melihat UI itu untuk ide referensi:
https://github.com/WordPress/gutenberg/issues/1930#issuecomment -333455412

Saya membagikan komentar sederhana yang merangkum PR dari tugas utama yang tersisa untuk mendapatkan editor blok untuk area widget:

• PR prioritas tertinggi: Implementasi titik akhir istirahat yang mengabstraksikan area widget sebagai blok. https://github.com/WordPress/gutenberg/pull/15015
  - (dalam proses) Beberapa pembaruan untuk tinjauan terbaru sedang menunggu, tetapi Humas masih bisa mendapatkan keuntungan dari tinjauan.
• PR kedua dengan prioritas tertinggi: Hubungkan titik akhir widget ke editor blok di layar widget.
  https://github.com/WordPress/gutenberg/pull/15074
  - Tergantung pada https://github.com/WordPress/gutenberg/pull/15015.
  - (dalam proses) Peninjauan menunggu keputusan.
• Render area widget yang mereferensikan post_id di frontend situs web.
  - https://github.com/WordPress/gutenberg/pull/15074.
  - (dalam proses) Peninjauan menunggu keputusan.

Menggabungkan 3 PR yang mereferensikan satu sama lain dalam satu rantai memungkinkan kita memiliki demo editor blok dari ujung ke ujung untuk layar widget.

Secara Paralel, kami memerlukan peningkatan lain untuk membuat blok berfungsi seperti yang diharapkan di layar widget.

Hapus penggunaan wordpress / editor dari blok inti (wordpress / editor tidak tersedia di layar widget).

• https://github.com/WordPress/gutenberg/pull/15635
• https://github.com/WordPress/gutenberg/pull/15572
• https://github.com/WordPress/gutenberg/pull/15521

Perbaiki masalah UI yang membuat layar tidak berfungsi seperti yang diharapkan atau yang membuat layar memiliki pengalaman yang kurang optimal.

• https://github.com/WordPress/gutenberg/pull/15472
• https://github.com/WordPress/gutenberg/pull/15470

Masalah UI lainnya memengaruhi layar widget, yang solusinya belum diterapkan. Masalah utamanya adalah:

• popover blok tidak muncul di posisi yang benar.
• Pemeriksa blok masih belum tersedia.
• Kami tidak memiliki sesuatu yang setara dengan penyisip global, kami hanya dapat menyisipkan blok menggunakan penyisip saudara, dan penyisip pelengkapan otomatis "/". Mungkin kita harus memiliki penyisip global per area widget?

Mengingat bahwa beberapa waktu berlalu sejak pembaruan kerja widget terakhir, saya akan membagikan yang baru yang berisi perkembangan sejak pembaruan terakhir.
PR yang menghubungkan titik akhir widget dengan layar widget digabungkan dan PR yang membuat blok di area widget depan situs web juga digabungkan.
Layar masih memberikan pengalaman yang kurang optimal dan banyak peningkatan sedang berlangsung.

PR yang digabungkan (terkait dengan pekerjaan layar utama): https://github.com/WordPress/gutenberg/pull/15015 , https://github.com/WordPress/gutenberg/pull/15074 , https://github.com / WordPress / gutenberg / pull / 15651

Sebuah PR yang memungkinkan blok widget lama untuk mereferensikan widget yang ada diusulkan https://github.com/WordPress/gutenberg/pull/15801.

Widget lawas masih tidak berfungsi seperti yang diharapkan di layar widget untuk itu kami perlu memastikan kami dapat menempatkan komponen render sisi server pengguna di layar itu https://github.com/WordPress/gutenberg/pull/15635 dan kami membutuhkan PR sebelumnya direferensikan https://github.com/WordPress/gutenberg/pull/15801. Kedua PR sedang menunggu tinjauan / tinjauan ulang.

Mengenai pekerjaan untuk menghapus penggunaan wordpress / editor dari blok inti:
https://github.com/WordPress/gutenberg/pull/15572 digabung. https://github.com/WordPress/gutenberg/pull/15635 menunggu tinjauan ulang dan saya akan segera memperbarui https://github.com/WordPress/gutenberg/pull/15521 untuk membahas tinjauan.

Mengenai pekerjaan untuk Memperbaiki masalah UI yang membuat layar tidak berfungsi seperti yang diharapkan atau yang membuat layar memiliki pengalaman yang kurang optimal: https://github.com/WordPress/gutenberg/pull/15472 ditutup karena kami memperbarui kode di PR lain yang memperbaiki akar penyebab masalah.
https://github.com/WordPress/gutenberg/pull/15470 sedang dalam diskusi dan menunggu keputusan.

Satu perhatian utama yang saya miliki adalah tombol simpan tunggal dan fungsi draf / publikasikan tunggal.

Ini jelas merupakan kekhawatiran yang meningkat. Saya akan menjelajahi ini lebih lanjut dan melihat memindahkan tombol ini menjadi spesifik Area Blok (maket segera datang). Saya rasa tidak perlu pindah ke blok yang sebenarnya.

Pembaruan lainnya.
Papan proyek jangka pendek tersedia di https://github.com/WordPress/gutenberg/projects/27.

Kami menggabungkan dua PR penting lainnya https://github.com/WordPress/gutenberg/pull/15521 , https://github.com/WordPress/gutenberg/pull/15396

Humas yang perlu ditinjau

PR berikutnya dengan Prioritas lebih tinggi adalah
https://github.com/WordPress/gutenberg/pull/15801 yang bila digabungkan akan memungkinkan widget lama untuk digunakan di layar widget.

https://github.com/WordPress/gutenberg/pull/15548 praktis siap dan membutuhkan persetujuan akhir.

https://github.com/WordPress/gutenberg/pull/15948 telah diperbarui dan membutuhkan persetujuan akhir juga.

Beberapa masalah / peningkatan potensial ditemukan dalam kode PHP, dan dua PR telah diserahkan. Ini akan menjadi perhatian tambahan pada mereka:
https://github.com/WordPress/gutenberg/pull/15981
https://github.com/WordPress/gutenberg/pull/15983

Properti untuk @TimothyBJacobs karena melakukan tinjauan awal ke salah satu PR ini.

Pembaruan / diskusi menunggu keputusan

https://github.com/WordPress/gutenberg/pull/15635 telah didiskusikan, dan tampaknya kami sampai pada solusi yang memungkinkan. Saya menyukai saran yang diberikan oleh @gziolo untuk memiliki ServerSideRenderProvider; Saya akan menerapkannya dalam beberapa jam ke depan.

https://github.com/WordPress/gutenberg/pull/15470 @aduth memberikan ide alternatif yang mengekspos komponen baru yang menyertakan BlockEditorProvider tetapi juga beberapa artefak yang diharapkan dari editor blok, misalnya, alur penulisan. Saya kira jika tidak ada yang peduli tentang pendekatan itu, jalur terbaik adalah mengimplementasikan komponen itu dan memperbarui https://github.com/WordPress/gutenberg/pull/15470 untuk menggunakannya.

Pembaruan lainnya

https://github.com/WordPress/gutenberg/pull/15988 diusulkan oleh @aduth akan membuka blokir masalah posisi popover di layar widget. Saya akan memeriksanya dalam beberapa jam ke depan.

Masalah ini belum aktif dalam setahun. Apakah ada masalah ikhtisar lain untuk layar widget?

Sepertinya tidak, @ellatrix. Jika Anda ingin menutup ini, kami memiliki Papan Proyek yang memiliki daftar masalah juga.

Akan menyenangkan jika masalah lama ini tetap terbuka karena juga tertaut ke Project Board. Ini juga dapat diperbarui ketika seseorang memiliki waktu untuk kembali ke masalah ini lagi.

Oke, karena tidak ada gerakan di papan proyek dan tidak ada gerakan pada masalah ini, saya akan menghapusnya dari papan WP 5.5.

@ellatrix Saya tidak jelas tentang status fitur ini. Apakah masih ada rencana untuk mengonversi barang-barang bilah sisi widget untuk menggunakan blok Gutenberg?

Semua PR yang disebutkan Jorge di sini: https://github.com/WordPress/gutenberg/issues/13204#issuecomment -499078467
Telah digabungkan.

Hei Aslan. @tokopedia

Status fitur ini adalah tidak ada yang bekerja pada layar Widget di wp-admin untuk waktu yang lama, sehingga dihapus dari papan proyek WP 5.5. Bukan berarti tidak akan dikerjakan, hanya saja tidak menjadi prioritas untuk 5.5.

Saya akan menutup masalah besar ini karena hari ini hanya merupakan dokumentasi bersejarah.