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

Readability
Our main reason for limiting the width of the content is to improve the readability of all of the amazing content on our wikis. Reading text in an efficient manner is crucial to the large majority of all reading and editing use cases across our projects. While there are several factors that affect readability – e.g. font size, contrast, font, and line length – we have decided to focus on line length initially. Formative line length research on reading of printed texts recommends line lengths between 45 and 90 characters per line (cpl). Recent research on reading of website text focuses primarily within the range of 35 – 100 cpl, with most recommendations falling towards the smaller end of that range. However currently without any width limitation on article content readers might find themselves with line lengths far above the recommended range. A 2005 study summarizes the latest research well: "short line lengths are easier to read", and furthermore, regarding learning and information retention, "subjects reading the narrow paragraphs had better retention than those reading the wide paragraphs".

Lastly, while it’s always important for us to do our own research and form our own conclusions, we think it’s worth noting the overwhelming amount of major websites that have similar limitations on content width. For example: academic journals like Nature, news websites like The New York Times, government and intergovernmental websites like the UN, academic documents like LaTeX, and word processors like Google Docs and Etherpad. Those examples, combined with the extensive research, gives us confidence in this decision.

In short, limiting the width of the content allows for better readability, less eye strain, and better retention of the information itself.

Ale co z tą wolną przestrzenią?
We have heard from around 30 editors (particularly people with large screens) who are frustrated by all of the white space created on the sides of the page, though some of them agree that the width limitation is better for reading. Są dwa powody tej frustracji: Naszym celem jest stworzenie dobrych warunków do czytania, nie wypełnianie każdego piksela ekranu treścią. W tym przypadku mniej znaczy więcej - ludziom łatwiej czyta się tekst o krótkiej długości linii i są bardziej skupieni gdy nie rozpraszają ich menu boczne lub inne elementy. If the best layout is one that includes white space that is okay — there is nothing inherently wrong with white space.
 * 1) Wolne miejsce wygląda na marnowanie przestrzeni
 * 2) Wolne miejsce jest jasne i rozpraszające

Dodatkowo, w ramach dalszych prac nad tym projektem będziemy próbować wykorzystać część tej przestrzeni na inne elementy. Zaczęliśmy eksperymentować z umieszczeniem menu bocznego w postaci nie przewijającej się wraz z resztą treści (link do prototypu). W dalszym etapie chcemy spróbować umieścić spis treści i/lub inne narzędzia strony obok treści. Tak jak, zmniejszenie szerokości treści otworzy nam nowe możliwości projektowania układu, takie jak dodanie prawej kolumny przeznaczonej na umieszczanie infoboksów i ilustracji.

Dlaczego czytelnicy nie mogą po prostu zmniejszyć okna przeglądarki?
Niektórzy twierdzą: jeżeli czytelnicy chcą zwęzić obszar z treścią, czemu nie zmniejszą okna przeglądarki albo nie klikną linku do widoku mobilnego. Tak jak wspomniano wyżej: dopóki większość przychodzi aby czytać artykuły, powinniśmy zoptymalizować układ strony pod tym kątem. Mamy tylko jedną szansę na zrobienie pierwszego wrażenia i powinniśmy dążyć do zapewnienia ludziom dobrego wrażenia zaraz po przybyciu, bez zmuszania ich do zmieniania ustawień.

Tabele i szablony nie pasują do zwężonej treści. Czy to nie jest źle?
Otrzymaliśmy kilka zgłoszeń o tabelach z długimi poziomymi paskami przewijania lub szablonami rozciągającymi się za obszarem z treścią. Chcemy wskazać, że znaczna część naszych użytkowników nie mających dużych ekranów i wchodzących na Wikipedię z laptopów miało już wcześniej te problemy z tabelami i szablonami niż wprowadzono te zmiany. Powinniśmy tak działać, aby zapewnić, że wszystkie nasze treści są jak to tylko możliwie responsywne.

Czemu nie zrobimy tego jako ustawienie?
Najlepszą rzeczą w interfejsie MediaWiki jest to, jak bardzo da się go konfigurować. Pomimo tego, że możemy dodać możliwość ustawiania szerokości wyświetlania treści, wolimy zachęcać aby redaktorzy i czytelnicy korzystali z tego samego doświadczenia. 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). Teraz redaktor może edytować stronę o szerokości 1500px, tymczasem czytelnik przegląda ją mając ustawioną szerokość 1200px. Przez zaimplementowanie maksymalnej szerokości (max-width) nie usuwamy całkowicie tej rozbieżności (ponieważ nadal będzie zróżnicowanie w używanych szerokościach poniżej tej granicy u ludzi z węższymi ekranami), ale znacznie ograniczamy zakres tego zróżnicowania.

That said, we are not inherently against configurability. Jeżeli nie chcesz aby w nowej wersji skórki Wektor mieć ograniczanej szerokości wyświetlanej treści, możesz użyć lokalnego skryptu. Zalecamy użycie tego.

Dlaczego postanowiliśmy, że szerokość będzie wynosić 960px?
Ta strona opisze, jak podejmowaliśmy te decycję:

Kiedy te zmiany będą dostępne na największych wiki?
Mamy nadzieję, że zmiany będzie można ustawić jako domyślne na wszystkich wiki pod koniec tego roku. Każda wiki może dołączyć do wcześniejszych testerów.

Czy te ulepszenia będą implementowane w projektach siostrzanych albo na wiki z pismami niełacińskimi?
Tak. Mamy już listę pierwszych wiki, które reprezentują różne rozmiary wiki i sposoby wprowadzania tekstu. Zapewniliśmy też wybór co najmniej jednego projektu innego niż Wikipedia.

Na których wiki te funkcje są już domyślnie widoczne?
Obecnie są to:


 * projekty siostrzane:
 * 
 * 
 * 


 * wiki z pismem niełacińskim:
 * bn:
 * he:
 * fa:
 * ko:
 * sr:


 * Wikipedie w językach z pismem łacińskim:
 * eu:
 * fr:
 * pt:
 * sr:
 * tr:
 * vec:


 * dodatkowo:
 * Office Wiki
 * 

Jesteśmy otwarci na dodanie kolejnych wiki na te listę!

Jak mogę sprawić, żeby to było wdrożone na wiki Wikimedia w której uczestniczę?
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.

Jak mogę włączyć to na mojej wiki (spoza Wikimedia)?
Upewnij się, że pobrałeś wersję. Miej świadomość, że stabilna wersja zostanie wydana w połowie 2021. Jeżeli akceptujesz ryzyko i chcesz mimo to zobaczyć te zmiany, dodaj poniższe linie do pliku :

We are glad to learn that you appreciate our improvements!

Czy wpłynie to na skórkę Monobook lub Timeless?
Nie. Te zmiany mają zastosowanie tylko do skórki Wektor. [ Wektor] jest domyślnym interfejsem wiki Wikimedia od roku 2010. Nie zostaną zmienione pozostałe skórki, takie jak [ Monobook], [ Timeless], [ Minerva] czy [ Modern].

Czy zostanie zmienione coś przy wykresach, mapach, a-/f-/o-/tmboksach, infoboksach, szablonach nawigacyjnych i innych szablonach?
Nie. Nie zmienimy nic w obszarze z treścią artykułu zaznaczonym na rysunku obok szarym kolorem (z wyjątkiem spisu treści):



Jak mogę zaproponować ulepszenia?
Dodaj sekcję na [ stronie dyskusji głównej strony tego projektu] lub skontaktuj się bezpośrednio z użytkownikiem SGrabarczuk (WMF), e-mail: sgrabarczuk@wikimedia.org.

Jak pracujemy ze społecznościami?

 * 1) Przed wdrażaniem:
 * 2) Prowadziliśmy badania z udziałem użytkowników, przeglądaliśmy gadżety i skrypty użytkowników. Więcej znajdziesz na stronie.
 * 3) Komunikowaliśmy się z różnymi wiki przekazując prośby o zgłaszanie się jako early adopters.
 * 4) Przeprowadziliśmy dyskusję na Wikimanii 2019 (zobacz wnioski).
 * 5) Przeprowadziliśmy dwie rundy testów z użyciem prototypów. Edytorzy mogli poznać nasze pomysły i podzielić się przemyśleniami, co lubią lub uznają za dziwne.
 * 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.

Jak mogę to wyłączyć?
Można włączać i wyłączać nowe ulepszenia w preferencjach użytkownika. Dodaliśmy także przycisk do wyłączania w menu po lewej (dostępny na każdej stronie): 

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.

Jak mogę zgłosić błąd?
Check the following page to see if your bug is a know issue.

Załóż zgłoszenie w Phabricatorze dodając do niego tag projektu Desktop Improvements albo skontaktuj się bezpośrednio z SGrabarczuk (WMF), e-mail: sgrabarczuk@wikimedia.org.

Dlaczego nie zrobić tego jako oddzielna skórka? Co stanie się ze starszym Wektorem?
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.

Jakie są oczekiwane kryteria sukcesu?
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.