Reading/Web/Desktop Improvements/Frequently asked questions/id

Keterbacaan
Alasan utama kami membatasi lebar konten adalah untuk meningkatkan keterbacaan dari semua konten hebat di wiki kami. Membaca teks dengan cara yang efisien merupakan hal penting bagi mayoritas kasus penggunaan membaca dan menyunting di proyek-proyek kami. Meskipun ada beberapa faktor yang mempengaruhi keterbacaan – di antaranya ukuran fon, kontras, fon, dan panjang baris – kami memutuskan untuk memulai dengan berfokus pada panjang baris. Penelitian panjang baris formatif mengenai membaca teks cetak menyarankan panjang baris di antara 45 dan 90 karakter per baris (cpl). Penelitian terkini mengenai membaca teks situs web berfokus utamanya di dalam jangkauan 35 – 100 cpl, dengan kebanyakan saran berada lebih dekat ke ujung kecil dari jangkauan tersebut. Akan tetapi untuk saat ini tanpa batasan lebar konten artikel, pembaca mungkin menemukan panjang baris yang jauh di atas jangkauan yang disarankan. Penelitian tahun 2005 menyimpulkan penelitian-penelitian terakhir dengan baik: "panjang baris yang pendek lebih mudah dibaca:, dan lebih lagi, mengenai belajar dan retensi informasi, "subjek yang membaca paragraf sempit lebih bagus retensinya daripada yang membaca paragraf lebar".

Terakhir, walaupun penting bagi kami untuk melakukan penelitian kami sendiri dan membentuk kesimpulan kami sendiri, kami rasa perlu disebutkan bahwa banyak situs web besar yang juga memiliki pembatasan lebar konten yang serupa. Contohnya: jurnal akademik seperti Nature, situs web berita seperti The New York Times, situs web pemerintahan dan interpemerintahan seperti UN, dokumen akademik seperti LaTeX, dan prosesor kata seperti Google Docs dan Etherpad. Contoh-contoh tersebut, digabungkan dengan penelitian secara ekstensif, membuat kami percaya diri dengan keputusan ini.

Singkatnya, membatasi lebar konten memperbaiki keterbacaan, mengurangi kelelahan mata, dan meningkatkan retensi informasi.

Tapi bagaimana dengan semua ruang kosong itu!?
Kami telah mendengar dari sekitar 30 penyunting (khususnya orang-orang dengan layar yang besar) yang kesal dengan semua ruang putih yang dihasilkan di sisi halaman, meskipun beberapa dari mereka setuju bahwa pembatasan lebar itu bagus untuk membaca. Kelihatannya ada dua penyebab utama dari kekesalan ini: Tujuan kami adalah untuk memberikan pengalaman membaca sebaik yang kami bisa, bukan untuk mengisi setiap piksel di layar dengan konten. Dan dalam kasus ini kurang sebenarnya adalah lebih — orang-orang bisa membaca dengan lebih mudah dengan panjang baris yang lebih pendek, dan lebih mudah berfokus tanpa dialihkan oleh bilah sisi atau elemen lain. Jika tata letak yang terbaik adalah yang mengandung ruang putih, maka itu tidak masalah — tidak ada yang salah secara bawaan dengan ruang putih.
 * 1) The white space feels like wasted space
 * 2) The white space is bright and distracting

Selain itu, seiring berjalannya proyek, kami berharap akan mulai menggunakan sebagian dari ruang ini untuk fungsionalitas lain. Kami telah mulai bereksperimen dengan membuat bilah sisi menempel di sisi kiri halaman (pranala ke prototipe). Semakin jauh proyek berjalan, kami berencana akan bereksperimen dengan meletakkan daftar isi dan/atau perkakas halaman di sebelah konten. Juga, seperti yang, membatasi lebar konten memberikan kita pilihan baru untuk tata letak konten, seperti kolom di sisi kanan khusus untuk kotak info dan gambar.

Bukankah pembaca dapat mengecilkan jendela peramban mereka saja?
Beberapa orang membalas: jika orang-orang ingin kontennya lebih sempit, maka mereka bisa membuat jendela peramban mereka lebih kecil, atau menekan pranala "Tampilan seluler" di bawah halaman. Seperti yang disebutkan di atas: karena kami tahu mayoritas orang datang untuk membaca artikel, maka kami sebaiknya mengoptimalkan tata letak berdasarkan kasus penggunaan itu. Kami hanya punya satu kesempatan untuk memberikan kesan pertama dan kami sebaiknya memberikan orang-orang pengalaman yang bagus begitu mereka datang, tanpa mengharuskan mereka melakukan penyesuaian.

Tabel dan templat lainnya tidak akan muat, bukankah itu hal yang buruk?
Kami telah menerima beberapa laporan bahwa tabel dengan bilah geser horizontal panjang, atau templat yang dikembangkan melebihi batas lebar. Kami ingin mengingatkan bahwa kebanyakan pengguna kami, yang tidak bisa mengakses layar lebar dan mengakses Wikipedia dari laptop mereka, sudah punya masalah dengan tabel dan templat sebelum perubahan ini. Kami sebaiknya mengusahakan semua konten kami seresponsif mungkin untuk mengakomodasi semua pengunjung.

Mengapa kita tidak membuatnya sebagai pengaturan saja?
Salah satu bagian terbaik dari antarmuka MediaWiki adalah antarmukanya sangat mudah dikonfigurasi. Dan meskipun kita bisa membuat pengaturan untuk lebar konten, kami berpikir apakah lebih baik untuk mendorong pengalaman umum yang sama-sama dirasakan oleh penyunting ataupun pembaca. Ini bisa jadi berguna bagi penyunting ketika membuat keputusan mengenai tata letak halaman (catatan: 1024px disebutkan sebagai ukuran minimum yang dipertimbangkan di Pedoman Gaya Wikipedia bahasa Inggris, walaupun itu bukan hal yang sama). Untuk saat ini, penyunting bisa menyunting halaman dengan lebar 1500px, sedangkan pembaca membacanya dengan lebar 1200px. Dengan mengimplementasikan lebar maksimum, kami tidak menghapus perbedaan ini secara sepenuhnya (karena akan tetap ada variasi di bawah lebar maksimum, untuk orang-orang dengan layar yang lebih sempit), tetapi kami akan membatasi jangkauan variasinya.

Walaupun begitu, kami tidak secara inheren menentang konfigurabilitas. Jika Anda ingin terus menggunakan versi baru dari kulit Vector tanpa batasan lebar, Anda bisa menggunakan skrip pengguna atau perkakas lokal untuk melakukannya. Kami bisa menyarankan yang ini.

Mengapa kita memutuskan 960px sebagai lebarnya?
Tolong baca halaman ini untuk mempelajari lebih lanjut tentang bagaimana kami mengambil keputusan ini:

Kapan perubahan-perubahan ini tersedia di wiki besar?
Bukan pada paruh pertama tahun 2021, kecuali sukarelawan komunitas mengikuti uji coba kami. Untuk saat ini, kami memfokuskan pengembangan fitur pertama kami berdasarkan data yang telah kami kumpulkan, dan di uji di wiki pengadopsi awal. Kami berharap perubahannya ditetapkan sebagai pengaturan baku di semua wiki nantinya pada tahun ini. Each community is welcome to join the early adopters.

Akankah ini diimplementasikan di proyek saudari dan wiki beraksara non-Latin?
Ya. Kami telah membuat daftar wiki pengadopsi awal yang merepresentasikan berbagai ukuran dan skrip. Kami juga ingin memastikan paling tidak satu proyek non-Wikipedia dipilih.

Di wiki mana saja perubahan ini diaktifkan secara baku?
Saat ini, terdapat:


 * proyek saudari:
 * 
 * 
 * 


 * wiki beraksara non-Latin:
 * bn:
 * he:
 * fa:
 * ko:
 * sr:


 * Wikipedia beraksara Latin:
 * eu:
 * fr:
 * pt:
 * sr:
 * tr:
 * vec:


 * dan sebagai tambahan:
 * Wiki Office
 * 

Kami terbuka untuk menambahkan lebih banyak wiki ke dalam daftar tersebut!

Bagaimana ini dapat diedarkan pada wiki Wikimedia utama saya?
Jika Anda tertarik untuk melihat Peningkatan Desktop sebagai pengaturan baku di wiki Anda,
 * 1) tanyakan komunitas Anda dan capailah konsensus,
 * 2) hubungi SGrabarczuk (WMF), surel: sgrabarczuk@wikimedia.org jika Anda memerlukan dukungan.

Bagaimana cara untuk mengaktifkannya di wiki (pihak ketiga) saya sendiri?
Pertama, pastikan Anda telah mengunduh. Perhatikan bahwa versi stabil baru akan dirilis pertengahan 2021. Jika kamu menyetujui risikonya dan ingin untuk melihat semua perubahan kami, tambahkan baris berikut pada Anda:

Kami senang untuk mempelajari bahwa Anda mengapresiasi peningkatan dari kami.

Akankah Monobook atau Timeless terpengaruh?
Tidak. Perubahan ini hanya akan diterapkan di Vector. [ Vector] telah menjadi antarmuka baku di wiki-wiki Wikimedia sejak 2010. Kulit lain tidak akan terpengaruh, termasuk [ Monobook], [ Timeless], [ Minerva] atau [ Modern].

Akankan kalian meningkatkan bagan, peta, kotak info dan navigasi, serta templat lain?
Tidak. Kami tidak akan mengubah semua yang berada di dalam daerah konten artikel abu-abu muda (kecuali daftar isi):



Bagaimana saya dapat menyarankan peningkatan?
Tambahkan bagian di [ halaman pembicaraan dari halaman utama proyek ini] atau hubungi SGrabarczuk (WMF), surel: sgrabarczuk@wikimedia.org.

How do you work with the communities?

 * 1) Prior to the deployments:
 * 2) We performed user research, and reviewed gadgets and user scripts. See the  for more details.
 * 3) We have been reaching out to various wikis asking to join the early adopters.
 * 4) We had a roundtable discussion at Wikimania in 2019 (see the outcomes).
 * 5) We have run two prototype testing rounds. Editors could gain an understanding of our ideas, and share what they appreciate or find confusing.
 * 6) Shortly after the deployment of each feature improvement, we collect usage data via  for each early adopter wiki.
 * 7) We run A/B tests for logged-in users. A half of them can experience the changed interface, and a half does not see any difference. Next, we compare the statistics. In the case of negative results, we improve the change or roll it back.
 * 8) For logged-out, we compare before and after. Unfortunately, we are not able to perform A/B tests on logged-out users.
 * 9) We watch the project talk page. We also engage in discussions on individual wikis regularly.
 * 10) Our  make it easier for us to work with a few communities more closely, react more quickly and effectively.

Bagaimana saya dapat menonaktifkannya?
Perubahan ini bisa dinyalakan dan dimatikan di preferensi pengguna. Kami juga telah menyediakan tombol untuk berhenti di bilah sisi kiri (bisa diakses di setiap halaman):.

Apakah Anda ingin menghapus tautan yang memperbolehkan untuk tidak ikut serta?
Kami tidak akan menghapus tautan untuk tidak ikut serta. Vektor Warisan akan tetap tersedia dalam tautan tersebut, sama seperti kulit lain yang baku pada masa lalu, seperti Monobook.

Bagaimana saya dapat melaporkan kekutu?
Periksa halaman berikut untuk memeriksa apakah kekutu Anda merupakan masalah yang sudah dikenal.

Anda bisa menambahkan pekerjaan di Phabricator dan menambahkan tag proyek Desktop Improvements atau hubungi SGrabarczuk (WMF), surel: sgrabarczuk-ctr@wikimedia.org.

Mengapa tak buat kulit baru saja? Apa yang akan terjadi pada Vektor Warisan?
Membuat kulit baru adalah gagasan yang bagus, tetapi untuk kulit Wikimedia, lebih mudah untuk mengubah kulit yang sudah ada daripada membuat kulit baru dari nol. Ada beberapa alasan:


 * akan terlalu kompleks untuk membuat ekstensi, perkakas, dan skrip yang sudah ada menjadi kompatibel dengan kulit baru, dan terlalu mahal untuk menjaga kompatibilitas mereka,
 * akan terlalu menantang untuk membangun dan memelihara kulit baru (jadi pengganti bukanlah pilihan),
 * akan lebih sulit bagi komunitas untuk berkolaborasi secara efektif dalam membangun kulit baru.

Secara teknis, Peningkatan Desktop mirip dengan fitur atau proyek terdahulu seperti atau. Satu-satunya perbedaan adalah bahwa kali ini, akan ada lebih banyak mereka. Dokumentasi Vector seharusnya tetap relevan.

Kami akan mempertahankan dan memelihara Vector Warisan. Tidak ada niat untuk menghapusnya.

Mengapa tidak menggunakan fitur beta saja?
Fitur beta hanya tersedia bagi pengguna terdaftar saja, dan peningkatan ini dimaksudkan untuk pembaca dan pengguna tidak terdaftar juga. Oleh karena itu, menggunakan fitur beta saja akan memberikan kami umpan balik dari jenis pengguna yang sangat spesifik dan tidak mewakili seluruh basis pengguna kami. Dan lebih lagi, kami ingin menerima umpan balik dari pembaca dan pengguna anonim sejak peredaran awal.

Apa saja metrik keberhasilan fitur ini?
Meningkatnya kegunaan bagi pengguna yang ada, diukur dari:


 * Interaksi
 * Pencarian per sesi naik 5% selama proyek berlangsung
 * Pergantian bahasa per proyek naik 5% selama proyek berlangsung


 * Afinitas
 * Kenaikan sentimen positif dan menerima terhadap situs (melalui survei dan uji coba pengguna)
 * Kenaikan sentimen kepercayaan dan kredibilitas (diukur melalui survei dan uji coba pengguna)

Begitu kami menetapkan perubahan yang kami inginkan secara lebih spesifik, kami akan memperluas daftar ini.