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. We have started experimenting with making the sidebar sticky to the left side of the page (link to prototype). Further along in the project we plan to experiment with putting a table of contents and/or page tools next to the content. Also, as, limiting the content width gives us new options for content layout, such as a right-hand column dedicated to infoboxes and images.

Bukankah pembaca dapat mengecilkan jendela peramban mereka saja?
Several people have pushed back saying: if people want the content to be more narrow they can make their browser window smaller, or click the “Mobile view” link at the bottom of the page. As mentioned above: since we know that the majority of people come to read articles we should optimise the layout around that use case. We only have one chance to make a first impression and we should aim to give people a great experience as soon as they arrive, without them having to make adjustments.

Tabel dan templat lainnya tidak akan muat, bukankah itu hal yang buruk?
We have received several reports of tables with long horizontal scroll bars, or templates that expand past the limited width. We’d like to point out that a large percentage of our users, who don’t have large screens and are accessing Wikipedia from their laptops, already had issues with tables and templates even before the change. We should work to make sure that all of our content is as responsive as possible to accommodate all visitors.

Mengapa kita tidak membuatnya sebagai pengaturan saja?
One of the best parts of the MediaWiki interface is how configurable it is. And while we could make a setting for content width we wonder if it might be beneficial to encourage a common experience that is shared between editors and readers. This could potentially be helpful to editors when making decisions about page layouts (note: 1024px is mentioned as a minimum size to consider in the English Wikipedia Manual of Style, though that’s not quite the same thing). Currently an editor might be editing a page at a width of 1500px, while a reader reads it at a width of 1200px. By implementing a max-width we don’t remove this discrepancy completely (because there would still be variation below the max-width, for people with narrower screens), however we would be greatly limiting the range of variation.

That said, we are not inherently against configurability. If you would like to continue using the new version of the Vector skin without the limited width, you can use a local user script or gadget to do so. We can recommend this one.

Mengapa kita memutuskan 960px sebagai lebarnya?
Please review this page to learn more about how we made this decision:

Kapan perubahan-perubahan ini tersedia di wiki besar?
Not in 2020, unless a community volunteers to join our testing. Currently, we are focusing on the development of our first features based on data we have already collected, and on the tests on the early adopter wikis. We do hope to see the changes set as default on all wikis in 2021.

Akankah ini diimplementasikan di proyek saudari dan wiki beraksara non-Latin?
Yes. We have already made a list of early adopter wikis which represents various sizes and scripts. We also wanted to ensure that at least one non-Wikipedia project is selected.

Di wiki mana saja perubahan ini kini tersedia?
Saat ini, terdapat:


 * proyek saudari:
 * 
 * 


 * wiki beraksara non-Latin:
 * he:
 * fa:


 * Wikipedia beraksara Latin:
 * eu:
 * fr:


 * dan sebagai tambahan:
 * Wiki Office

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

Bagaimana ini dapat diedarkan pada wiki 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-ctr@wikimedia.org jika Anda memerlukan dukungan.

Akankah Monobook atau Timeless terpengaruh?
No. These changes will be applied to Vector only. [ Vector] has been the default interface on Wikimedia wikis since 2010. No other skins will be affected, including [ Monobook], [  Timeless], [  Minerva] or [  Modern].

Akankan kalian meningkatkan bagan, peta, kotak info dan navigasi, serta templat lain?
No. We will not change anything that's within the light gray article content area (except for the table of contents):

Bagaimana saya dapat menyarankan peningkatan?
Add a section on the [ talk page of the main page of the project] or contact SGrabarczuk (WMF), email: sgrabarczuk-ctr@wikimedia.org.

Bagaimana saya dapat menonaktifkannya?
It's possible to turn the improvements on and off within user preferences. We have also provided an opt-out button in the left sidebar (accessible on each page):.

Bagaimana saya dapat melaporkan kekutu?
Check the following page to see if your bug is a know issue.

You can add a task on Phabricator and add Desktop Improvements project tag or contact SGrabarczuk (WMF), email: sgrabarczuk-ctr@wikimedia.org.

Mengapa tak buat kulit baru saja? Apa yang akan terjadi pada Vektor Warisan?
It would be an excellent idea to make a new skin, but in the case of Wikimedia skins, it's easier to change an existing one than to create a new one from scratch. There are various reasons:


 * it would be too complex to make the existing extensions, gadgets, and user scripts compatible with yet another skin, and too costly to maintain their compatibility,
 * it would be too challenging to build and maintain yet another skin (as a total replacement is not an option),
 * it would be less likely for the communities to collaborate effectively in the process of building a new skin.

Technically, Desktop Improvements are similar to previous features or projects such as or. The only difference is that this time, there will be more of them. Vector documentation should remain relevant.

We will keep and maintain the Legacy Vector. There is no intention of its removal.

Mengapa tidak menggunakan fitur beta saja?
Beta features are available for registered users only, and the improvements are intended to serve our readers and unregistered users as well. Therefore, using beta features only would give us feedback from a very specific type of user that is not representative of our entire base of users. And moreover, we wish to receive the readers' and anonymous users' feedback from the earliest deployments.

Apa saja metriks keberhasilan fitur ini?
Increase utility among our existing audiences, proxied by:


 * Interactions
 * Increase searches per session by 5% over the course of the project
 * Increase language switching per project by 5% over the course of the project


 * Affinity
 * Increase in positive and welcoming sentiments towards the site (via surveys and user testing)
 * Increase in sentiments of trust and credibility (measured via surveys and user testing)

As we define the changes we want to make with more specificity, we will expand and iterate on this list.