Przenośni.mmo.rpg

Na temat Mercury'ego (skórki mobilnej FANDOMU) krąży wiele opinii, niestety większość niecenzuralnych. Szkoda, bo prawie zawsze powodem są nie najlepsze pierwsze wrażenia lub brzydko wyglądającą wiki, ale z winy edytora, a nie skórki.

Niestety, czy tego chcemy, czy nie urządzenia mobilne stanowią większość ruchu na wikia.com, a niewątpliwa większość użytkowników urządzeń mobilnych skorzysta właśnie z Mercury'ego. Obecnie **aż 62%** globalnego ruchu na FANDOMIE pochodzi z urządzeń mobilnych.

## Dobry, zły i brzydki

Niezależnie od tego z jakiej skórki korzystamy może ona wyglądać źle lub dobrze. Mercury nie jest tu wyjątkiem. Jeżeli tworzymy szablon/artykuł sprawdzamy, czy wygląda dobrze na skórce z której korzystamy. Niestety często tylko na niej. W drugiej kolejności zazwyczaj zaglądamy na Monobooka i o ile dbanie o tę skórkę nie jest czymś złym, nie można zaprzeczyć, że Monobook umiera. Mniej niż 0.01% ruchu pochodzi z Monobooka, czyli około 6200 razy mniej niż z Mercury'ego.

Właśnie dlatego nasze szablony i artykuły powinniśmy tworzyć z myślą o naszej *ukochanej* skórce mobilnej. Poniżej zamieszczam kilka zrzutów ekranu artykułów sprzed optymalizacji pod względem urządzeń mobilnych i po niej:

## Podgląd skórki mobilnej

Jest kilka sposobów na podejrzenie skórki mobilnej, zacznę od – moim zdaniem – gorszych:

* Dopisanie `?useskin=mercury` na końcu adresu wiki, np. spolecznosc.wikia.com/wiki/Centrum\_Społeczności?useskin=mercury.
* Podgląd mobilny podczas edycji artykułu.

Teraz pora na dwa najlepsze – moim zdaniem – sposoby podglądu skórki mobilnej:

* Zobaczenie strony na urządzeniu mobilnym.
	+ Jest to jeden z prostszych sposobów, ale działa świetnie. W końcu z myślą o tym został stworzony Mercury.
* Symulacja urządzenia mobilnego za pomocą narzędzi deweloperskich.
	+ Moim zdaniem najlepszy sposób na sprawdzenie artykułu na Mercurym, jest w stanie symulować różne smartfony, automatycznie włącza skórkę mobilną, stronę przeglądamy swipe'ując myszką, niczym palcem na urządzeniu mobilnym. Pozwala na łatwe wykonywanie zrzutów ekranu danej części strony, oraz całej strony.
	+ Ta funkcja znajduje się na pewno w Chrome'ie oraz Firefoxie, przy czym testowałem tylko na tym pierwszym.

## Porady

Ok, to był dość długi wstęp, teraz pora na główną część:

* **Przenośne infoboksy** – nie spotkałem się jeszcze z przypadkiem infoboksu, którego skonwertowanie nie byłoby wskazane. Przenośne infoboksy są *przenośne* (tak, wiem, zadziwiające), co znaczy, że wyglądają i działają dobrze na wszystkich skórkach. Wprowadzają kilka funkcji ciężkich do zaimplementowania w starych infoboksach (np. zwijanie grup, galerie obrazów, motywy). Po prostu są świetne. Praktycznie wszystkie infoboksy powinny zostać zamienione na przenośne infoboksy, można poszukać na swoją rękę informacji o migracji (chociażby pod wstawionym wyżej linkiem lub w źródłach na dole) i zająć się tym lub poprosić o pomoc kogoś doświadczonego. A może najlepszym rozwiązaniem dla Ciebie będzie skorzystanie z Infobox Buildera?
	+ Czasami przenośne infoboksy mogą być użyte... nie tylko do robienia infoboksów, przykładem jest przenośna nawigacja lub nagłówek.
* **Rodzaje szablonów** – na Oasisie rodzaje szablonów nie zmieniają niczego oprócz klasyfikacji (z wyjątkiem infoboksu, który pozwala używać Infobox Buildera). Natomiast na Mercurym sprawa wygląda lekko inaczej: klasyfikacja szablonu zmienia sposób jego wyświetlania na stronie. Wymienię **tylko najważniejsze zmiany**:
	+ **Komunikat**, **Navboks** i **Nawigacja** – celowo schowane na skórce mobilnej.
	+ **Link kontekstowy** – wyświetla się z paddingiem i kursywą.
	+ **Cytat** – wyświetla jako `blockquote`.
	+ **Infoboks** – patrz na sekcję *Przenośne infoboksy*.
* **Tabele** – tabele są dobre... jeżeli są wykorzystywane tak jak powinny, czyli do wyświetlania informacji, a **nie pozycjonowania elementów** na stronie.
	+ Do pozycjonowania elementów/tworzenia układu strony możesz zamiast tabeli skorzystać z `float`, `columns` lub `flexbox`.
	+ Unikaj zagnieżdżonych tabeli (tzn. tabeli w tabelach), sprawiają wiele problemów.
	+ Staraj się nie zmieniać niczego oprócz wyglądu tabeli za pomocą niestandardowych klas lub atrybutu `style`. Natomiast możesz bezpiecznie korzystać z standardowych klas, takich jak `article-table`.
* **Mobilna strona główna** – edytor strony głównej jest na tyle łatwy w obsłudze, że nie ma się nad czym rozpisywać, zaprojektowanie strony głównej nie wymaga dużego wysiłku, a przynosi sporo korzyści.
* Używaj **wikitekstu i semantycznych elementów** zamiast stylu – wikitekst i semantyczne elementy (w szczególności `blockquote` i `cite`) są zrozumiane przez Mercury'ego, CSS – niekoniecznie.

## Podsumowanie

Nie taki Mercury straszny, jak go malują. Śpieszmy się kochać skórki, bo tak szybko odchodzą.

### Podziękowania

Specjalne podziękowania dla:

* Luqgrega za pomoc z Mercury'owymi zagwozdkami (polecam tego ~~Vanguarda~~ użytkownika).
* Nanakiego za genialne przykłady optymalizacji szablonów pod urządzenia mobilne na LoL Wiki.

### Zobacz więcej

* quantcast.com – wikia.com
* Portability Checklist
* How to fix portability issues
* How to tell if your content is portable
* Why you should avoid inline styles
* Structuring for the Future
* Infobox Builder
* Converting Infoboxes
* Portable Infoboxes/Benefits
* Portable Infoboxes/Tips and tricks
* Portable Infoboxes/Best practices
* Help:Infoboxes
* Help:Infoboxes/Tags
* Help:Infoboxes/CSS
* Help:Infobox migration
* Help:Infobox preview
* Help:Template Types
* Help:Curated Main Page
* Table
* Help:Avoiding nested tables
* Help:Wikitext best practices
* Differences between desktop and mobile
* Steven Universe: a portability case study
* Wookieepedia: a portability case study
* Mercury
* "Mercury: a Community Connect Town Hall"
* Keeping your source simple
* Navigation & Mercury
* An Introduction: Mercury – Skin & Engine
* "Portability: a Community Connect Town Hall"
* Portability, Elements and Articles
* Best Practices with Images
* Looking Forward Portability and Mobile