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) Khoảng trắng cảm giác như là khoảng trống bị bỏ phí
 * 2) Khoảng trắng quá sáng và gây phân tâm

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?
Chúng tôi đã nhận được một số báo cáo về việc bảng biểu có thanh cuộn dọc dài, hoặc bản mẫu mở rộng vượt quá chiều dài giới hạn. Chúng tôi muốn chỉ ra rằng một lượng lớn người dùng của chúng tôi không có màn hình lớn và truy cập Wikipedia từ laptop đã gặp phải vấn đề với bảng biểu và bản mẫu ngay cả trước khi thay đổi giao diện. Chúng tôi sẽ làm việc để đảm bảo rằng mọi nội dung của chúng tôi càng nhanh nhạy càng tốt để có thể thích ứng với mọi khách ghé thăm.

Sao không để nó là một cài đặt thôi?
Một trong những phần tuyệt nhất của giao diện MediaWiki là độ linh hoạt trong việc cấu hình nó thế nào. Và tuy chúng tôi có thể để chiều rộng nội dung là một cài đặt, nhưng đồng thời chúng tôi cũng tự hỏi liệu nó có ích lợi gì không trong việc thúc đẩy một trải nghiệm chung được chia sẻ giữa biên tập viên và người đọc. Điều này có thể có ích cho biên tập viên khi đưa ra quyết định về bố cục trang (lưu ý: 1024px được nhắc tới như là kích cỡ tối thiểu để cân nhắc trong Cẩm nang biên soạn Wikipedia tiếng Anh, mặc dù chúng cũng không tương tự nhau lắm). Hiện tại thì một biên tập viên có thể đang sửa đổi trang ở chiều rộng 1500px, trong khi đó một người đọc đọc nó ở chiều rộng 1200px. Bằng cách áp dụng một chiều rộng tối đa, chúng tôi không loại bỏ sự không nhất quán này một cách hoàn toàn (bởi vì vẫn sẽ có các biến số bên dưới chiều rộng tối đa cho những người có màn hình nhỏ hơn) nhưng lại giới hạn khoảng biến số này lại nhiều.

Nói thì nói vậy nhưng chúng tôi không phản đối tính có thể cấu hình được một cách cố hữu. Nếu bạn muốn tiếp tục sử dụng phiên bản mới của skin Vector mà không có chiều rộng giới hạn, bạn có thể sử dụng một script người dùng địa phương hoặc tiện ích. Chúng tôi khuyến nghị bạn sử dụng cái này.

Chúng tôi quyết định chiều rộng là 960px như thế nào?
Hãy xem trang này để tìm hiểu thêm về việc chúng tôi đã đưa ra quyết định này như thế nào:

Khi nào thì những thay đổi này có mặt trên những wiki lớn nhất?
Chúng tôi hy vọng có thể thấy các thay đổi được cài làm mặc định trên mọi wiki vào cuối năm nay. Mỗi cộng đồng đều được chào mừng trở thành wiki triển khai sớm.

Liệu những cải thiện có thể triển khai ở những dự án chị em và những wiki không sử dụng kí tự Latinh không?
Có. Chúng tôi đã xây dựng một danh sách các wiki "triển khai sớm" đại diện cho những kích cỡ và ngôn ngữ khác nhau. Chúng tôi cũng muốn đảm bảo rằng ít nhất một dự án không-phải-Wikipedia được chọn lựa.

Tại những wiki nào thì những thay đổi này sẽ được bật làm mặc định?
Hiện tại thì chúng bao gồm: Chúng tôi rất sẵn lòng thêm nhiều wiki hơn nữa vào danh sách này!

Ngoài ra:
 * Wiki Office
 * 
 * Wiki MediaWiki
 * Wiki Quản trị của Quỹ Wikimedia
 * Wiki Collab
 * Wiki Strategy

Làm thế nào để triển khai nó ở wiki Wikimedia nhà của tôi?
Nếu bạn quan tâm muốn xem các Cải thiện cho phiên bản máy tính được cài làm mặc định ở wiki của bạn, hãy
 * 1) hỏi cộng đồng mình và đạt đồng thuận,
 * 2) liên hệ SGrabarczuk (WMF), email: sgrabarczuk@wikimedia.org nếu bạn cần hỗ trợ.

Làm cách nào để sử dụng nó ở wiki (bên thứ ba) của riêng tôi?
Đầu tiên, hãy đảm bảo bạn đã tải. Nếu bạn chấp nhận rủi ro và vẫn muốn xem thay đổi của chúng tôi, thêm những dòng sau vào của bạn:

Chúng tôi rất vui khi biết được rằng bạn trân trọng những cải thiện của chúng tôi!

Monobook hay Timeless có bị ảnh hưởng không?
Không. Những thay đổi này sẽ chỉ được áp dụng giao diện Vector. [ Vector] đã là giao diện mặc định trên các wiki Wikimedia kể từ năm 2010. Các giao diện khác như [ Monobook], [ Timeless], [ Minerva] hay [ Modern] sẽ không bị ảnh hưởng.

Các bạn có cải thiện biểu đồ, bản đồ, hộp thông báo, hộp thông tin, hộp điều hướng, các bản mẫu khác?
Không. Chúng tôi sẽ không thay đổi bất cứ thứ gì ở bên trong khu vực nội dung bài viết màu xám nhạt (ngoại trừ mục lục):



Tôi có thể gợi ý các cải thiện như thế nào?
Thêm một mục vào [ trang thảo luận của trang chính của dự án] hoặc liên hệ SGrabarczuk (WMF), email: sgrabarczuk@wikimedia.org.

Các bạn làm việc với các cộng đồng như thế nào?

 * 1) Trước khi triển khai:
 * 2) Chúng tôi thực hiện nghiên cứu người dùng, và xem lại các tiện ích và script người dùng. Xem  để biết thêm chi tiết.
 * 3) Chúng tôi đã liên lạc với nhiều wiki khác nhau để đề nghị họ tham gia triển khai sớm.
 * 4) Chúng tôi đã có một cuộc thảo luận bàn tròn tại Wikimania năm 2019 (xem kết quả).
 * 5) Chúng tôi đã cho chạy hai vòng thử nghiệm nguyên mẫu. Các biên tập viên có thể hiểu thêm về ý tưởng của chúng tôi, và chia sẻ những điều họ trân trọng hoặc thấy khó hiểu.
 * 6) Không lâu sau khi triển khai mỗi cải thiện tính năng, chúng tôi sẽ thu thập dữ liệu sử dụng thông qua  cho mỗi wiki triển khai sớm.
 * 7) Chúng tôi cho chạy A/B tests cho các người dùng đăng nhập. Một nửa trong số họ có thể trải nghiệm giao diện đã thay đổi, và một nửa thì không. Tiếp theo, chúng tôi so sánh các số liệu. Trong trường hợp có kết quả tiêu cực, chúng tôi cải thiện nó hoặc lùi nó lại.
 * 8) Với những người dùng không đăng nhập, chúng tôi so sánh trước và sau. Không may là, chúng tôi không thể thực hiện thử nghiệm A/B đối với nhóm đối tượng này.
 * 9) Chúng tôi theo dõi trang thảo luận dự án. Chúng tôi cũng thường xuyên tham gia vào các cuộc thảo luận trên các wiki độc lập.
 * 10) Các  của chúng tôi cũng giúp chúng tôi làm việc với các cộng đồng dễ dàng và gần gũi hơn, có phản hồi nhanh và hiệu quả hơn.

Làm thế nào để tắt nó?
This is only available to authorized users. Có thể bật và tắt các cải thiện trong tùy chọn người dùng. Chúng tôi cũng cung cấp một nút tắt ở thanh bên bên tay trái (có thể tiếp cận ở mỗi trang): 

Các bạn sẽ bỏ liên kết cho phép không tham gia chứ?
Chúng tôi sẽ không loại bỏ liên kết tắt. Giao diện Vector cũ sẽ tiếp tục có sẵn thông qua liên kết đó, tương tự như các giao diện khác đã từng là mặc định trong quá khứ như Monobook.

Làm thế nào để báo cáo lỗi?
Hãy check trang sau để xem liệu lỗi của bạn có phải là một vấn đề đã biết rồi không.

Bạn có thể thêm một nhiệm vụ vào Phabricator và thêm tag dự án Desktop Improvements hoặc liên hệ SGrabarczuk (WMF), email: sgrabarczuk@wikimedia.org.

Sao không làm một skin mới? Điều gì sẽ xảy ra với Vector bản cũ?
Sẽ là ý tưởng hay để tạo ra một giao diện mới, nhưng trong trường hợp của giao diện Wikimedia thì sẽ dễ dàng hơn khi thay đổi một cái đã có sẵn so với việc tạo một cái mới từ đầu. Có nhiều lý do cho việc này:


 * sẽ quá phức tạp để khiến các mở rộng, tiện ích và script người dùng đang có sẵn tích hợp được với một giao diện nữa, và quá tốn kém để duy trì tính tích hợp của chúng,
 * sẽ quá thách thức khi xây dựng và duy trì một giao diện nữa (khi mà thay đổi hoàn toàn không phải một sự lựa chọn),
 * sẽ ít có khả năng các cộng đồng hợp tác một cách hiệu quả hơn trong quá trình xây dựng một giao diện mới.

Về mặt kỹ thuật, Các cải thiện cho phiên bản máy tính thì tương tự như các tính năng hoặc dự án trước đây ví dụ như hoặc. Sự khác biệt duy nhất chính là lần này sẽ có nhiều hơn. Các tài liệu Vector vẫn sẽ thích hợp.

Chúng tôi sẽ giữ và duy trì giao diện Vector cũ. Sẽ không có ý định loại bỏ nó.

Sao không chỉ dùng các tính năng beta?
Các tính năng beta chỉ có sẵn cho người dùng đã đăng ký, và các cải thiện thì nhằm mục đích phục vụ cho cả người đọc và người dùng không đăng ký. Vì vậy, sử dụng tính năng beta chỉ cung cấp cho chúng tôi phản hồi từ một loại người dùng cụ thể và không đại diện được toàn bộ nền tảng người dùng. Và hơn nữa, chúng tôi mong muốn nhận được phản hồi từ người đọc và người dùng không định danh từ những lần triển khai sớm nhất.

Các số liệu thành công của tính năng là gì?
Tăng tính hữu dụng với những người dùng có sẵn, được đại diện bởi:


 * Độ tương tác
 * Tăng 5% lượng tìm kiếm mỗi phiên trên toàn dự án
 * Tăng 5% lượng thay đổi ngôn ngữ mỗi dự án trên toàn dự án


 * Sự thu hút
 * Gia tăng cảm giác tích cực và được hoan nghênh với trang (thông qua khảo sát và thử nghiệm người dùng)
 * Gia tăng cảm giác tin tưởng và tín nhiệm (được tính toán thông qua khảo sát và thử nghiệm người dùng)

Chúng tôi sẽ mở rộng danh sách này khi quyết định các thay đổi mà chúng tôi muốn thực hiện một cách cụ thể hơn.