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

Khả năng đọc
Lý do chính của việc giới hạn chiều rộng nội dung là để cải thiện khả năng đọc tất cả những nội dung đặc sắc trên wiki của chúng ta. Đọc chữ một cách có hiệu quả đóng vai trò hết sức trọng yếu đối với phần lớn các trường hợp đọc và sử dụng sửa đổi xuyên suốt các dự án của chúng ta. Tuy có một số các yếu tố khác nhau ảnh hưởng đến khả năng đọc như kích cỡ font, độ tương phản, font, và chiều dài dòng, chúng tôi đã quyết định trước hết sẽ tập trung vào chiều dài dòng. Nghiên cứu độ dài dòng hình thành về việc đọc trên chữ in khuyến nghị rằng độ dài dòng nên nằm trong khoảng 45 đến 90 từ mỗi dòng (tmd). Nghiên cứu gần đây về việc đọc chữ trên website tập trung chủ yếu trong khoảng 35 - 100 tmd, với hầu hết các khuyến nghị rơi về phía nhỏ hơn của khoảng trên. Tuy nhiên hiện tại, với việc không có bất kỳ giới hạn chiều rộng nào đối với nội dung bài viết, người đọc có thể thấy chiều dài dòng vượt xa so với khoảng được khuyến nghị. Một nghiên cứu vào năm 2005 tóm lược các nghiên cứu gần đây một cách ngắn gọn như sau: "chiều dài dòng ngắn sẽ dễ đọc hơn", và hơn nữa, đối với việc học hỏi và lưu giữ thông tin thì, "chủ thể đọc các đoạn văn hẹp có khả năng lưu giữ thông tin tốt hơn những người đọc đoạn văn rộng".

Sau cùng, tuy việc tự mình nghiên cứu và đưa ra kết luận luôn là quan trọng nhưng chúng tôi nghĩ cũng nên lưu ý rằng có một lượng lớn các trang web cũng có giới hạn chiều rộng nội dung tương tự. Ví dụ: các tạp chí học thuật như Nature, các trang web tin tức như The New York Times, các trang web chính phủ và liên chính phủ như UN, các văn bản học thuật như LaTeX, và các trình xử lý từ như Google Docs và Etherpad. Những ví dụ trên, kết hợp với các nghiên cứu chuyên sâu, đã cho chúng tôi sự tự tin khi đưa ra quyết định này.

Nói ngắn gọn, giới hạn độ rộng của nội dung cho phép khả năng đọc tốt hơn, ít căng thẳng mắt hơn, và lưu giữ bản thân thông tin tốt hơn.

Nhưng thế còn tất cả những khoảng trắng kia thì sao?!
Chúng tôi đã lắng nghe từ khoảng 30 biên tập viên (cụ thể là những người có màn hình lớn) cảm thấy bực tức bởi tất cả những khoảng trắng được tạo ra ở hai bên trang, dù một vài trong số họ đồng tình rằng giới hạn chiều rộng sẽ giúp đọc tốt hơn. Có vẻ như có hai nguyên nhân chính gây ra sự bực bội này: Mục tiêu của chúng tôi là tạo ra trải nghiệm đọc tốt nhất có thể, chứ không phải lấp đầy từng pixel trên màn hình bằng nội dung. Và trong trường hợp này thì thực ra ít lại là nhiều - mọi người có thể đọc dễ dàng hơn với chiều dài dòng ngắn hơn, và tập trung dễ dàng hơn mà không bị phân tâm bởi thanh bên hoặc các yếu tố khác. Nếu như layout hoàn hảo nhất là cái có các khoảng trắng thì cũng không sao cả - chẳng có gì sai với các khoảng trắng.
 * 1) The white space feels like wasted space
 * 2) The white space is bright and distracting

Thêm nữa, khi dự án tiến triển, chúng tôi hy vọng sẽ bắt đầu tận dụng một số khoảng trống này cho các chức năng khác. Chúng tôi đã bắt đầu thí nghiệm với việc làm thanh bên dính vào bên trái của trang (liên kết đến nguyên mẫu). Sau này chúng tôi dự định thử nghiệm việc đặt mục lục hoặc/và công cụ trang cạnh nội dung. Đồng thời, như, giới hạn độ rộng nội dung cũng cho chúng ta những lựa chọn mới đối với bố cục nội dung, ví dụ như cột bên tay phải dành riêng cho hộp thông tin và hình ảnh.

Sao người đọc không làm nhỏ cửa sổ trình duyệt của họ lại đi?
Một số người đã phản biện lại: nếu mọi người muốn nội dung hẹp hơn thì họ có thể làm nhỏ cửa sổ trình duyệt lại, hoặc click vào liên kết "chế độ xem di động" ở cuối trang. Như đã đề cập ở trên: vì chúng tôi biết phần lớn mọi người tới để đọc bài viết nên chúng tôi cần tối ưu hóa bố cục trang xung quanh mục đích sử dụng đó. Chúng tôi chỉ có một cơ hội để tạo ấn tượng ban đầu và chúng tôi nên nhắm tới việc cho mọi người một trải nghiệm tuyệt vời ngay khi họ tới mà không bắt họ phải điều chỉnh gì thêm.

Bảng và các bản mẫu khác không vừa với chiều rộng giới hạn, chẳng phải rất tệ sao?
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.

Why don’t we just make it a setting?
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.

How did we decide on 960px for the width?
Please review this page to learn more about how we made this decision:

When will these changes be available on the largest wikis?
Not in the first half of 2021, unless a community volunteers to join our testing. Currently, we are focusing on the development of our 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 later in the year.

Are the improvements to be implemented on sister projects and on non-Latin script wikis?
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.

Which wikis these changes are default turned on?
Currently, these are:


 * sister projects:
 * 
 * 
 * 


 * non-Latin script wikis:
 * bn:
 * he:
 * fa:
 * ko:
 * sr:


 * Latin script Wikipedias:
 * eu:
 * fr:
 * pt:
 * sr:
 * tr:
 * vec:


 * additionally:
 * Office Wiki
 * 

We are open to add more wikis to this list!

How can this be deployed on my home Wikimedia wiki?
If you are interested to see the Desktop Improvements as default on your wiki,
 * 1) ask your community and reach the consensus,
 * 2) contact SGrabarczuk (WMF), email: sgrabarczuk@wikimedia.org if you need support.

How can I enable it on my own (third-party) wiki?
First, make sure you have downloaded. Be mindful that the stable version will be released in mid 2021. If you accept the risk and would like to see our changes anyway, add following lines in your :

We are glad to learn that you appreciate our improvements!

Will Monobook or Timeless be affected?
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].

Will you improve charts, maps, a-/f-/o-/tmboxes, infoboxes, navboxes, other templates?
No. We will not change anything that's within the light gray article content area (except for the table of contents):



How can I suggest improvements?
Add a section on the [ talk page of the main page of the project] or contact SGrabarczuk (WMF), email: sgrabarczuk@wikimedia.org.

How can I disable it?
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):.

Will you remove the link that allows to opt-out?
We will not remove the opt-out link. Legacy Vector will continue to be available through that link, similar to other skins that have been default in the past, such as Monobook.

How can I report a bug?
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.

Why not make a new skin? What will happen to Legacy Vector?
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.

Why not use beta features only?
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.

What are the feature's success metrics?
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.