Open Grid
Nie pozwólmy na utrwalenie praktyki tworzenia subdomeny m.*
Prefix m. jest tak samo kiepskim pomysłem jak niegdyś prefix www. Nie wiem, czy wynika to z faktu, że zwyczajnie wszyscy inni tak robią, czy może brakuje wiedzy jak publikować treści bez obaw o to na jakim ekranie będą wyświetlane?
Niepokoi mnie fakt, że stało się to pewnego rodzaju standardem i zaleceniem, aby każda witryna miała swój odpowiednik dla urządzeń mobilnych w postaci subdomeny m.*. Cieszy mnie ten fakt, że małe ekrany są już zauważane przez wydawców i chcą oni ułatwić dostęp do treści, ale czy na pewno nie uzyskują efektu wręcz odwrotnego?
Jakie wady ma stosowanie subdomeny „m”?
Wersje mobilne często są okrojone. Brak jest często niektórych funkcjonalności. W wielu serwisach informacyjnych zauważyłem, że nie są np. publikowane komentarze, do których można się tylko dobrać odwiedzając normalną wersję serwisu. Dochodzi nawet do absurdalnych sytuacji jak np. z serwisem mBanku, który nie pozwala zrobić przelewu potwierdzonego przez SMS.
Automatyczne przekierowanie na wersję mobilną po wykryciu typu urządzenia ma z założenia ułatwić życie, ale często uniemożliwia dotarcie do wersji standardowej i kółko się zamyka
Wymagają dodatkowego nakładu pracy ze strony wydawcy
Dzielenie się linkiem "mobilnym", który otworzył się w telefonie nie usatysfakcjonuje osoby, która otworzy taki link w przeglądarce typowego komputera.
Stąd już niedaleka droga do pułapki związanej z "duplicate content"
Kwalifikacja do przekierowania na wersję mobilną nie zawsze działa prawidłowo przez kolejny powód.
Wydawcy są niekonsekwentni w nazewnictwie. Niektórzy stosują subdomenę 'm', a inni 'lajt', jeszcze inni wybierają domenę .mobi
Jest tyle różnych urządzeń i typów ekranów (od małych tel. komórkowych przez smartfony z dużymi ekranami, czytniki typu Kindle po tablety, ekrany panoramiczne w laptopach i 48 calowych telewizorach), że ciężko tu mówić o przestrzeni zero-jedynkowej m. oraz !m.
Ktoś kto rozróżnia wszystkie te urządzenia pod względem mobilny / niemobilny równie dobrze może nadal twierdzić, że 500MB pamięci u Number 5 z Short Circuit wystarczy aby w połączeniu z piorunem wykształcić samoświadomość (może dalekie skojarzenie, ale pokazuje jak za kilka lat będziemy patrzeć z niedowierzaniem na takie koszmarki jak dzisiaj www, http:// czy port 80).
Jakie zatem powinno się stosować rozwiązanie?
Użytkownik końcowy nie powinien się nawet nad tym zastanawiać. Użytkownikowi powinna być serwowana strona, która automatycznie dostosuje się do jego urządzenia bez konieczności zbędnych przekierowań lub arbitralnego zapamiętywania i zastanawiania się nad adresem wersji mobilnej.
CSS oferuje odpowiednie reguły dotyczące viewportu, media queries itp.. Wdrożenie takiego rozwiązania jest o wiele łatwiejsze niż żonglowanie kilkoma szablonami. W praktyce z pomocą przychodzą tu gotowe frameworki CSS jak html5boilerplate.com lub skromniejszy cssgrid.net stosowany również na moim blogu automatycznie dostosowującego się do ekranu odwiedzającego bez jego wiedzy. Warstwy automatycznie się opływają, obrazki skalują itp.
Z pomocą reguł CSS można wyciąć elementy, które mogą być zbyt dużym obciążeniem dla mobilnych urządzeń.
Postuluje i proszę, aby społeczność developerska spróbowała się powstrzymać nawzajem przed kolejną ślepą uliczką, która doprowadzi do utrwalenia się fatalnej praktyki tworzenia subdomeny dla urządzeń mobilnych.
Update: Zadałem pytanie na stackowerflow w tej kwestii. Muszę przyznać rację, że w momencie kiedy nie zależy nam tylko na dostosowaniu wyglądu, ale również treści i funkcjonalności należałoby trzymać rzeczy osobno. Jednak nadal będę się upierał, że powinno to działać na zasadzie cloakingu w zależności od klienta.
Comments to "Nie pozwólmy na utrwalenie praktyki tworzenia subdomeny m.*":
2 | Tyfus
Przesyłanie danych nie będzie żadną przeszkodą - już niedługo LTE i inne cuda.
Jak z modemami 9600kb/s :)
3 | OpenGrid
@zx mam 2GB pakietu danych w abonamencie. Ledwo wykorzystuje 20%. Androidowy NetCounter pokazuje, że i tak najwięcej danych pobieram w sieciach wifi.
Gdy używałem Kindle z darmowym 3G na urlopie w Albanii i tak większość serwisów nie rozpoznawało czytnika jako urządzenia mobilnego (poza moim blogiem ;)), więc można sobie tylko wyobrazić poziom irytacji za każdym razem kiedy trzeba ładować Article mode lub wpisywać ręcznie prefix m. w adresie.
@Tyfus Dodam jeszcze http://www.spidersweb.pl/2011/07/gdzie-jest-najszybszy-mobilny-internet-na-swiecie-w-polsce.html
4 | zx
Ale to nie jest argument. Ja, przy projektowaniu strony, jeśli mogę zwiększyć jej szybkość w samym CSS o 0,1s, to robię to. Bo wiem, że o takie same 0,1s mogę zwiększyć szybkość ładowania na innych polach.
Robicie jak twórcy gier - skoro gracze mają coraz lepszy sprzęt, to na cholerę będziemy bawić się w optymalizację silnika.
5 | OpenGrid
@zx szybciej trwa rendering reguł css niż przekierowanie na wersję mobilną. Z doświadczenia również wiem, że wąskim gardłem jest ilość requestów http x RTT i ładowanie zewnętrznych bibliotek js (analytics, reklamy itp.), a nie wielkość samego dokumentu i reguł css. Myślę, że najlepszym rozwiązaniem jest zoptymalizowanie czasu ładowanie strony bez względu na to, czy to szablon mobilny czy nie.
6 | zx
Nikt nie każe robić redirecta na sztywno. Można sobie stworzyć 'wirtualną' subdomenę w której back-end zajmie się tym jaki CSS ma być podłączony itp. m.cośtam.pl nie musi od razu oznaczać, że trzeba ponawiać żądanie do serwera.
7 | rozie
Czym automatyczne dostosowanie różni się od wyboru przez użytkownika wersji serwisu? Po kolei argumenty:
1. Wersja po automatycznym dostosowaniu nadal będzie okrojona. Chyba, że chcesz próbować wyświetlić na komórce flasha/mpg.
2. W przypadku błędnego rozpoznania i dostosowania nadal nie będzie dostępu do części funkcjonalności.
3. Nadal potrzeba dodatkowego nakładu pracy ze strony wydawcy.
4. Wiele typów urządzeń to także różne metody wprowadzania danych. Co innego jest ergonomiczne w przypadku komputera z myszą, co innego w przypadku komórki starszego typu.
5. Serwisy m.* świetnie sprawdzają się na telefonach starszego typu, przy pakietach 25-100 MB.
6. Stawianie tego bloga jako przykładu to trochę nieporozumienie. Na 1024x768 mam większość ekranu niewykorzystaną (w części komentarzy). I uczucie, że piszę w pasku bocznym.
8 | pecet
IMHO dobry pomysł, sam mam pakiet 500 MB i wykorzystuje z niego max 10%, ale co z tego skoro, EDGE które mam dostępne pozwala zazwyczaj na prędkości poniżej 0.1 mbita, a 3G jest dostępne praktycznie tylko w centrach miast? Rozwiązanie świetne jest takie jak jest, a jak ktoś chce to zmieni sobie useragenta na zwykłego, sam korzystam z tego rozwiązania na iPhone (via Mercury Browser), bo ipBoard nie wyświetla w wersji mobilnej shoutboxa.
9 | zx
Źle napisana wersja mobilna (nawet przez CSS!) jest tak samo zła jak wersja mobilna podpięta pod subdomenę. W tym nie ma żadnej różnicy.
10 | bobiko
TO nie przejdzie. w historii mojego blogaska był taki motyw, ze wymuszałem wręcz wersje mobilną z poziomu samego telefonu - efekt był taki, ze wszystko naraz się ściągąło, a przecież po co mamy marnować transfer?
Inna sprawa, ze korzystając z telefonu, chcemy jak najszybciej dostać się do treści w postaci tekstu i/lub zdjec. Nie ma nić bardziej wkurwiającego jak długi czas oczekiwania na ściągniecie wszystkich zbędnych danych, zwłaszcza gdy tel leci po EDGE
12 | flegmatyk
@pecet: beznadziejny pomysł, wymaga zakupienia dodatkowej domeny, kompletnie szkoda kasy
Wymuszanie wersji - nie. Alternatywna wersja m.domena - głosuję za obiema rękami. @zx doskonale porównał obecnych projektantów do twórców silników gier. Naprawdę, zrobienie osobnej wersji serwisu, tylko do odczytu, bez żadnych bajerów to nie jest aż taki wielki nakład pracy, a będę dozgonnie wdzięczny. Na przykład stara (ale wciąż dostępna) mobilna wersja Reddita. Lista linków i w sumie tyle, dokładnie to, czego chcę na telefonie komórkowym. I o to chodzi.
13 | OpenGrid
Z komentarzy wnioskuję, że większość chciałaby oglądać strony mobilne, które wyglądają tak samo pod terminalowym lynx'em jak w graficznej przeglądarce ;)
15 | OpenGrid
@bobiko dokładnie o to cały czas chodziło. Do tego nie jest potrzeba sub-domena, w której będziemy serwować duplicate content. Obrazki, tła itp. można spokojnie okroić przy pomocy media queries.
16 | bobiko
@opengrid: owszem. wszystkim chodzi o mobile css ale przy totalnie zminimalizowanym transferze danych. Ja wiem, ze w erze coraz tańszych abo / pakietów z netem, sie to nie opłaca ale wciąż nie rozumiem w czym tkwi problem? duplicate content? raczej nie.
17 | OpenGrid
jeśli chodzi o duplicate content, daleko nie trzeba szukać http://searchengineland.com/mobile-friendly-websites-the-duplicate-content-trap-12197
inne problemy to np. dzielenie się takim linkiem z telefonu. Osoba, która otrzyma taki link na desktop-owej przeglądarce będzie się czuła co najmniej dziwnie vide http://m.wyborcza.pl/ Link do pełnej wersji strony ukryty na samym dole. Mało biegła osoba będzie kompletnie zdezorientowana i nawet nie będzie wiedziała, że artykuł ma komentarze itp.
Reasumując generuje to mnóstwo dziwnych problemów pod względem architektury sieci, treści i usability.
18 | OpenGrid
Pozwolę sobie zacytować:
"The mobile CSS file reformats the content for better usability on a mobile device, and can strip out elements in the site that are too large or download-intensive for the average mobile device. The resulting user experience is a fast-loading, simplified version of the same webpage at the same URL. When it’s time to redesign or update the site, it only has to be done once and—presto!—the mobile CSS file continues to render the new design in a mobile-friendly format."
19 | rozie
Czyli oba warianty (i m.*, i CSS) dobrze zaimplementowane działają... dobrze. Plus, naprawdę ciężko teraz projektantowi strony wypośrodkować parametry dla "average mobile device". Póki co, żyjemy w świecie, gdzie za transfer, szczególnie na urządzenia mobilne, się płaci, a prędkość łącz jest różna. Zresztą nawet laptop czy netbook z transferem w roamingu będzie czym innym, niż ten sam komputer wpięty w Polsce do kablówki. Ja jestem za pozostawieniem wyboru użytkownikowi, czy chce korzystać z wersji mobilnej AKA light, czy pełnej.
Okrojona treść - dopóki jest dostępna pełna wersja, niespecjalnie widzę problem. Poza tym, w tym przypadku (gazeta.pl) komentarze to kwiatek do kożucha. Sednem AKA mięsem są tu artykuły, nie komentarze i decyzją projektanta było, czy je wyświetlać. Jasne, mogłoby być (także w wersji pełnej) "pokaż komentarze".
Odnośnie zmiany CSS - jest lepiej, niż było. Wręcz akceptowalnie (ale nie mam wide screena). Jeśli chciałeś udowodnić, że rozciągnięcie na maksa też jest złe, to nie ma takiej potrzeby - wiem o tym. Dodaj jakieś marginesy po ok. 15% szerokości z każdej strony i będzie git.
20 | damnat
Brak możliwości potwierdzenie przelewu SMS wynika akurat z tego, że do potwierdzenia takiej operacji potrzebne jest potwierdzenie przez dwa kanały komunikacji. Używając komórki do zalogowania masz masz tylko jeden kanał. Nie wiem czy zasada dwóch kanałów zastosowana jest również tutaj, ale tak mi się wydaje- w BZ WBK jest tak samo.
21 | OpenGrid
@damnat tajemnicą poliszynela jest fakt, że otwierając stronę (zwykłą) mBanku w komórce taki przelew możesz wykonać bez problemu. To co zrobił mBank przypomina zachowanie 2 latka, który zasłania twarz rękoma i wydaje mu się wtedy, że go nie widać :)
@rozie wręcz przeciwnie. Właśnie w tym sęk, że można już łatwo uzyskać efekt kiedy to na każdym urządzeniu strona będzie wyglądać czytelnie używając css. Co do transferu, css również udostępnia odpowiednie reguły. Co do artykułów, to jeżeli nas jakiś interesuje to i tak pozostaje niedosyt lub rozwinięcie tematu, który zawsze jest w komentarzach (np. wasze komentarze pozwoliły mi szerzej spojrzeć na omawiany problem). W praktyce zawsze na komórce zmuszony byłem otwierać wersję pełną, co jest kompletnym absurdem.
22 | Paweł
Wersje mobilne często są okrojone to już nie wina samej subdomeny "m.*" tzw. wersja pełna może też być okrojona na urządzeniach mobilnych ponieważ może nie gwarantować wszystkich funkcjonalności na sprzętach charakteryzujących się różnym poziomem zaawansowania
Automatyczne przekierowanie na wersję mobilną po wykryciu typu urządzenia ma z założenia ułatwić życie ... użytkownik na urządzeniu przenośnym powinien mieć wybór: przełącz na wersję klasyczną/mobilną, ustawienie użytkownika powinno mieć priorytet nad autodetekcją.
Wymagają dodatkowego nakładu pracy ze strony wydawcy No, co kto lubi albo stworzenie nowych prostszych widoków albo, alternatywne CSSY :-)
Dzielenie się linkiem "mobilnym", który otworzył się w telefonie nie usatysfakcjonuje osoby, która otworzy taki link w przeglądarce typowego komputera W takim wypadku powinno nastąpić przekierowanie na standardowa wersję serwisu, lub link w stylu "przełącz na pełną wersję"
Stąd już niedaleka droga do pułapki związanej z "duplicate content" Nie martw się, Google doskonale sobie z tym poradzi :) sami zalecają umieszczenie mobilnej wersji na subdomenie
Kwalifikacja do przekierowania na wersję mobilną nie zawsze działa prawidłowo przez kolejny powód ... Dlatego powino się stosować wspomniany link Wersja klasyczna / Wersja moblina
23 | rozie
@OpenGrid: Dla jasności: ja lubię, gdy się strona skaluje sama. Tylko statyczne strony, gdzie funkcjonalność sprowadza się do wyświetlenia tekstu, obrazków i ew. video to mocno przeszłość. Dobrym przykładem serwisu, gdzie wersja mobilna ma sens jest Blip.pl. Spróbuj skorzystać z pełnej wersji na telefonie (weźmy Nokię 3110c) i Operze mini. Potem spróbuj skorzystać z okrojonej wersji. Faktem jest, że wiele ficzerów jest nieobecnych, ale... podstawowa funkcjonalność działa i korzysta się w sposób dość wygodny.
I nie ma takich reguł, które odgadną, czy użytkownik poczeka, choćby i parę minut, na załadowanie się obrazków (bo akurat zależy mu na detalach, chociaż ma tragiczne łącze). Automatyczne skalowanie ma sens, o ile można je wyłączyć. Choćby przez wejście na niemobilną wersję strony.
24 | SpeX
Akurat też wolę jeden standart, typu m., niż by każdy wymyślał swoje rozwiązania. W większości przypadków, z mobilnej wersji strony z łatwością można wyjść kasując m. z adresu via gazeta. Co daje łatwy wybór jaką wersję preferuje użytkownik.
Oczywiście, linki wersja mobilna/wersja pełna to fajna sprawa. Ale pod warunkiem iż ktoś pomyśli i wciśnie w to ciasteczko. By następnym razem, nie trzeba by zmieniać narzuconego rozwiązania.
"
A co bo swoich rozwiązań, kto zgadnie jaki jest mobilny adres do bankowości ING? "lajt."
Mnie za to bardziej denerwują specjalne strony do drukowania, które nie kiedy o wiele lepiej się indeksują niż orginały.
25 | Dz
Ogólnie brakuje jakiegoś ogólnego standardu, którego WSZYSCY mieliby się trzymać. Internet na telefonie to zazwyczaj droga rzecz (jesli się nie ma pakietu/damowego neta itp), więc strzelanie "a jaki może byc adres dla mobilnej wersji tej strony ?" tudzież pobieranie strony w wersji normalnej (i pobranie gigantycznej ilości danych które na wyświetlaczu telefonu i tak źle się wyświetlą) to horror dla kieszeni.
26 | OpenGrid
I okazuje się, że można spokojnie już rozdzielić to co będzie ładować się do odpowiednich urządzeń
Weźmy ciekawy framework 320 and up:
http://stuffandnonsense.co.uk/projects/320andup/
1 | zx
31 july 2011, 14:32:16
No tak, ale z drugiej strony user mobilny (o ironio) musi wtedy pobrać więcej danych niż user na dużym ekranie. Bo najczęściej robimy CSS dla głównej wersji, a potem zmieniamy na mobilnej dodatkowymi regułami.
Można to oczywiście zrobić odwrotnie, ale nikt tak nie robi. Może dlatego, że wydaje się to zbyt wymagające.