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
lubflexbox
. - 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 jakarticle-table
.
- Do pozycjonowania elementów/tworzenia układu strony możesz zamiast tabeli skorzystać z
- 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
icite
) 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
Vanguardauż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