Najpierw mobilnie. Prosta, responsywna nawigacja mobilna

Tworzenie aplikacji mobilnych

O Mobile First napisano już sporo i istnieją dobre książki na ten temat. A jednak większość programistów i firm nie wykorzystuje go w swoich projektach lub w ogóle nie wie o takim podejściu.

Dlatego chcę Wam o tym krótko i na przykładach opowiedzieć, będzie to przydatna informacja dla tych, którzy nie słyszeli o tym podejściu.
Spróbuję odpowiedzieć na trzy główne pytania:

• Czym jest Mobile First i jakie są jego zalety
• Wdrożenie podejścia
• Statystyki wyników

Co to jest Mobile First? W tym roku liczba użytkowników korzystających z urządzeń mobilnych w celu uzyskania dostępu do Internetu sięgnęła 60%. Dlatego też ruch mobilny staje się coraz większy i właściciele stron internetowych muszą brać te statystyki pod uwagę. Jak pokazuje praktyka, użytkownicy telefonów komórkowych i tabletów spędzają mniej czasu w Internecie i preferują strony z pierwszych linii wyników wyszukiwania. Użytkownicy komputerów PC mogą natomiast spędzać więcej czasu na wyszukiwaniu informacji. Dlatego Twoja witryna musi być dobrze zoptymalizowana pod kątem wyszukiwarek (SEO) i spełniać wszystkie wymagania Mobile First, aby wizyta użytkownika na Twojej stronie była jak najbardziej wygodna i zrozumiała poprzez jego urządzenie mobilne.

Dlatego niektóre z najważniejszych wymagań w rozwoju Mobile First to:

• Najpierw pokaż najważniejsze treści
• Strona internetowa powinna być lekka i zoptymalizowana, ponieważ... Szybkość połączenia z siecią komórkową może być niska w zależności od lokalizacji użytkownika
• Strona internetowa nie powinna ładować więcej zasobów, niż potrzebuje użytkownik, aby uzyskać potrzebne mu informacje, ponieważ... Internet mobilny jest wciąż drogi. Dodatkowe informacje należy wczytać wyłącznie na żądanie użytkownika

Mobile First to więc metoda tworzenia zoptymalizowanej strony internetowej dla różnych urządzeń mobilnych, biorąc pod uwagę prędkość połączenia sieciowego. Oraz znaczenie wyświetlania podstawowej treści użytkownikowi końcowemu.

Gigant wyszukiwania Google napisał niedawno o znaczeniu tego podejścia:

„W naszym rankingu wyników zwiększymy wskaźnik przyjazności dla urządzeń mobilnych. Zmiany te wpłyną na wyszukiwanie mobilne we wszystkich językach świata i będą miały znaczący wpływ na wyniki wyszukiwania. Dlatego użytkownikom łatwiej będzie znaleźć wyniki zoptymalizowane pod kątem ich urządzeń.”
Film o znaczeniu Mobile First od Oliviera Rabenschlaga – szefa Agencji Rozwoju Kreatywnego Google.

Zalety podejścia Mobile First Przypomnę, że dziś liczba użytkowników korzystających z urządzeń mobilnych do surfowania po Internecie sięgnęła 60%. Dlatego też korzystanie z Mobile First podczas tworzenia witryny internetowej zapewnia przede wszystkim ogromne korzyści tym użytkownikom.

• Jedna witryna internetowa dla wszystkich urządzeń
• Użytkownicy w pierwszej kolejności otrzymają ważną treść strony
• Szybkie ładowanie strony przy niskich prędkościach połączenia
• Wygodny interfejs do nawigacji na ekranie mobilnym
• Minimalna ilość zasobów sieciowych wymagana do wyświetlenia głównej treści - oszczędność mobilnego ruchu internetowego
• Najwyższe pozycje w wynikach wyszukiwania Google

Implementacja Implementacja podejścia zostanie zademonstrowana przy użyciu frameworka Moff.js (Mobile First Framework). Jest to framework JavaScript dostosowany do programowania Mobile First.

Rozważymy to podejście na przykładzie strony ze szczegółowymi informacjami o samochodzie.

Określenie istotnej części treści Zazwyczaj na takiej stronie znajduje się bardzo dużo danych. I musimy zdecydować, które z nich są ważne przede wszystkim dla użytkownika.

Szczegółowy wykaz danych na stronie:

Wyobraźmy sobie, że najważniejszą rzeczą na tej liście jest główne zdjęcie, nazwa producenta, modele, wyposażenie, cena, lista cech i wyposażenia.

Pierwsza strona mobilna. Nazwa firmy Opis firmy Uwaga dotycząca Nissana Versy 2015

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Z wyjątkiem sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

• Model: Versa Uwaga
• Nadwozie: Hatchback 4D
• Silnik: 4-cylindrowy DOHC 1,6 l, 16 V
• Paliwo: benzyna

Standard

• Asystent hamulca
• Podwójne przednie boczne poduszki powietrzne
• Odmrażacz tylnej szyby
• Pojemnik w drzwiach pasażera
• Pojemnik w drzwiach kierowcy
• Poduszka powietrzna wykrywająca obecność pasażera
• Kontrola trakcji
• odtwarzacz CD
• Komputer podróży
• Elektroniczna kontrola stabilności
• Przedni stabilizator
• Wspomaganie kierownicy
• Wycieraczka tylnej szyby
• Przednie lampki do czytania
• Górna poduszka powietrzna
• Hamulce ABS

Stworzony przez Company.com

• Prawo autorskie
• Kontakt
• Mapa witryny

W idealnym przypadku jest to ilość ruchu, jaką użytkownik może przeznaczyć na uzyskanie tych danych. Postaramy się to osiągnąć przy minimalnej różnicy.

W pierwszej kolejności napiszemy style do wyświetlania stron na urządzeniach mobilnych. Dopiero potem style są dostosowywane do innych rozmiarów ekranu za pomocą zapytania o media.

@media (min. szerokość: 768 pikseli) ( /*Style tabletów i komputerów stacjonarnych*/ )

Dodanie dodatkowych informacji Teraz musimy dodać pozostałe dane w taki sposób, aby użytkownik o nich wiedział i mógł je uzyskać, żądając ich. Dodaj miniatury do głównego obrazu Musimy pokazać użytkownikowi, że nadal dostępne są dodatkowe obrazy do obejrzenia. Aby to zrobić musimy pod obrazem głównym dodać link prowadzący do miniatur.

Zobacz więcej zdjęć...
Używamy tutaj pomocników Data Events, które pomagają uzyskać informacje na żądanie. Po kliknięciu linku na adres podany w atrybucie href zostanie wysłane żądanie Ajax. Wynik żądania zostanie zapisany do elementu określonego w atrybucie data-load-target. Ważnym punktem jest to, że atrybut data-load-screen wskazuje przy jakich wartościach ekranu miniaturki będą ładowane automatycznie. Rozmiary ekranów pochodzą ze struktury CSS Twitter Bootstrap. Natomiast w atrybucie data-load-module podajemy identyfikator zarejestrowanego modułu, z którym zostanie nawiązane połączenie po wstawieniu wyniku żądania ajax.

Żądanie ajax jest wysyłane na adres URL podany w łączu, a wynik jest wstawiany na stronę

Zarejestrowany moduł (galeria pojazdów) jest podłączony

Zależności są uwzględnione (jQuery i Slick-karuzela)

Ładowanie głównego pliku modułu

Inicjalizacja modułu

Następnie przyjrzyjmy się rejestracji tego modułu. Deklaracja klasy modułu Framework Moff posiada system modułowości, za pomocą którego implementujemy klasę modułów pojazdów-galerii.

Moduły w Moff są niezależnymi elementami aplikacji, które posiadają własną logikę biznesową i mogą posiadać zależności od bibliotek zewnętrznych.

Moff.modules.create("VehicleGallery", funkcja() ( var _module = this; var _mainImage; funkcja setMainImage() ( _mainImage = _module.find(.vehicle_images_main img"); ) funkcja zainicjowaćSlickJs() ( $(_module. find(.vehicle_images_thumbs-list")).slick((nieskończony: prawda, slidesToShow: 5, slidesToScroll: 1 )) ) funkcja handleMainImage() ( $(_module.scope).on("kliknij", ".vehicle_images_thumbs- item img",changePreview); ) funkcja zmianyPreview() ( var indeks = this.src.match(/thumb(\d+)/); _mainImage.src = "obrazy/podgląd" + indeks + ".jpg"; ) to .scopeSelector = ".vehicle_images"; this.init = funkcja() ( setMainImage(); zainicjowaćSlickJs(); handleMainImage(); ); ));
Podczas inicjalizacji klasy uruchamiamy funkcję slick-carousel, aby utworzyć karuzelę naszych miniatur i skonfigurować moduł obsługi do ich przeglądania.

Rejestracja modułu Rejestracja modułu odbywa się przy użyciu obiektu, który zawiera unikalny identyfikator i może zawierać zależności modułu oraz główny plik klasy modułu.

Moff.amd.register(( id: "galeria-pojazdów", zależy: ( js: ["/bower_components/jquery/dist/jquery.min.js", "/bower_components/slick-carousel/slick/slick.min. js"], css: ["/bower_components/slick-carousel/slick/slick.css"] ), plik: ( js: ["js/vehicle-gallery.js"] ), afterInclude:function() ( Moff. moduł.initClass("Galeria pojazdów"); ) ));
W naszym przykładzie jako zależności określiliśmy jQuery i jego wtyczkę typu Slick-Carousel, która tworzy karuzelę z miniatur. Zależności są ładowane synchronicznie, w określonej kolejności. A po zależnościach ładowana jest klasa modułu Vehicle-gallery.js. Następnie po wczytaniu pliku modułu i jego zależności inicjujemy moduł za pomocą zdarzenia afterInclude.

Statystyki wyników. Podsumujmy efekty tworzenia strony Mobile First.

Dolny wykres pokazuje, że niezoptymalizowana strona jest o 73% cięższa niż strona Mobile First. W ten sposób możemy zaoszczędzić 186,94 KB, których użytkownik może nie potrzebować przeglądając Twoją stronę.

Wniosek W ten sposób pozbywamy się ładowania dużej liczby zasobów wtórnych, które jednak będą dostępne na żądanie użytkownika.

W tym artykule omówiono tylko jeden przykład załadowania dodatkowych informacji. Pełny przykład można obejrzeć na stronie internetowej frameworka.

Jeśli chodzi o rozpowszechnienie urządzeń z Androidem w 2013 roku, staje się oczywiste, że obecnie mamy tysiące różnych urządzeń z dostępem do sieci i ekranami o różnej wielkości. Nie da się stworzyć osobnego układu strony dla każdego z nich. Dlatego dziś istnieje potrzeba stosowania bardziej elastycznego podejścia do projektowania.

Jeśli chcemy, aby nasza strona internetowa była łatwa w obsłudze na wszystkich urządzeniach, niezależnie od zachowań użytkowników, orientacji czy rozdzielczości ekranu, powinniśmy pomyśleć o zaimplementowaniu w naszych projektach rozwiązań responsywnych.

Pierwsze podejście mobilne

Ostatnio popularne stało się określenie „mobile First”. Oznacza to, że musisz zacząć od stworzenia układu na telefon komórkowy, ale zoptymalizowanego pod kątem ekranów o wysokiej rozdzielczości. W ten sposób układ telefonu komórkowego stanie się uniwersalny i ostateczny, eliminując potrzebę stosowania innych oddzielnych układów. To takie proste!

Używając natywnie elastycznych, ale prostych układów, możesz zapewnić lepszą obsługę różnych przeglądarek, zarówno dużych, jak i małych, które nie są w stanie wyświetlić w pełni responsywnych układów. Jeśli więc chodzi o układy, termin „najpierw mobilny” w rzeczywistości oznacza „stopniowe ulepszenia”.
- Ethana Marcotte'a

Minimalna szerokość Zapytania o media

Wprowadzaj określone zasady dotyczące układów tylko wtedy, gdy naprawdę ich potrzebujesz. Skorzystaj z nieruchomości minimalna szerokość aby utworzyć układ warstwowy obejmujący całą szerokość rzutni. Łatwiej jest przechowywać wszystkie zapytania o media razem niż na końcu arkusza stylów lub rozproszone w oddzielnych fragmentach kodu.

/* Małe ekrany (domyślnie) */ html ( rozmiar czcionki; 100%; ) /* Średnie ekrany (640px) */ @media (min-width: 40rem) ( html ( rozmiar czcionki: 112%; ) ) / * Duże ekrany (1024px) */ @media (min-width: 64rem) ( html ( rozmiar czcionki: 120%; ) )

1. Nie wszystkie przeglądarki są sobie równe

Różne przeglądarki inaczej wyświetlają kod CSS. Aby tego uniknąć, warto zastosować specjalne skrypty resetujące wartości do jednego widoku, np. Normalize.css, który pozwala na niemal identyczne wyświetlanie elementów w dowolnej przeglądarce. Należy o tym pamiętać przed utworzeniem własnego pliku stylów.

2. Dodaj Rzutnia Metatag

Umieść go w bloku Twój kod HTML. Umożliwi zapytania o media w układach dla różnych urządzeń.

Model pudełkowy CSS

Jest to ważne, aby zrozumieć podstawy, podobnie jak generowanie i zachowanie elementów w przeglądarce, zanim nauczysz się projektowania responsywnego. Model pudełkowy CSS składa się z czterech różnych części.

Możliwość czyszczenia obszaru wokół zawartości.

Rama Ramka wokół wyściółki.

Obszar do oczyszczenia znajduje się wokół ramy.

3. Użyj box-size: border-box

Zapisz ten kod na początku pliku CSS. * - zaznaczy wszystkie elementy na Twojej stronie.

*, *:before, *:after ( -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box; )

Wybór należy do Ciebie .clearfix:before, .clearfix:after ( treść: " "; display: table; ) .clearfix:after ( clear: oba; ) .clearfix ( *zoom: 1; )

Przepływ naprzeciw

Dodaj klasę .przepływ przeciwny do kolumn, które powinny wyświetlać się jako pierwsze na urządzeniach mobilnych, a po prawej stronie na dużych ekranach.

@media (min-width: 40rem) ( .column.flow-przeciwny ( float: prawo; ) )

Ćwicz i doskonal swoje umiejętności

Stosując się do tych prostych zasad, możesz stać się prawdziwym mistrzem responsywnego projektowania. Ćwicz i pomóż uczynić Internet lepszym i wygodniejszym.

Nawiasem mówiąc, przykładem najbardziej udanego projektu responsywnego jest framework

Inwestor i partner funduszu venture Andreessen Horowitz Benedict Evans napisał artykuł o tym, dlaczego coraz więcej programistów odchodzi od paradygmatu Mobile First na rzecz Mobile Native, jaka jest między nimi różnica i o czym powinni pamiętać twórcy aplikacji mobilnych. .

„Kilka lat temu firmy IT przeszły na strategię Mobile First. Wcześniej organizacje miały osobne działy rozwoju platform mobilnych i pracowników, którzy byli zaangażowani w rozwój obszaru mobilnego. Teraz nowa funkcjonalność pojawia się natychmiast na smartfonach, ale czasami nie przenosi się na komputery PC” – pisze Evans.

Zdaniem inwestora, w 2016 roku coraz więcej firm przejdzie na paradygmat Mobile Native. „To ewolucja zasady Mobile First. Co się stanie, jeśli po prostu zapomnisz o komputerach stacjonarnych i tanich telefonach komórkowych? Jeśli skupisz się całkowicie na 2,5 miliarda smartfonów i całkowicie pominiesz rynek urządzeń z niższej półki. Czy można zbudować dużą firmę?

Według Evansa programiści wybierający strategię Mobile Native powinni najpierw rozważyć kilka kluczowych punktów:

„Ostatnią kwestią, którą chciałbym poruszyć, jest zastanowienie się, ile różnych technologii jest wykorzystywanych w takich aplikacjach i dlaczego takie usługi nie były możliwe na komputerze PC” – zauważa Evans.

To niesamowite, jak smartfony są zarówno bardziej złożone, jak i łatwiejsze w obsłudze niż komputery PC - szczególnie dotyczy to mobilnego Internetu.

Inwestor twierdzi, że za pomocą telefonu komórkowego użytkownicy mogą zrobić wiele rzeczy, na które nie pozwalał im system, na który składał się sam komputer, klawiatura i mysz. Otwiera to nowe możliwości zarówno dla samych posiadaczy smartfonów, jak i dla programistów. „Całe pokolenie już dorosło i jest gotowe na paradygmat Mobile Native. A aplikacje, które byłyby ekscytujące w 2007 roku, teraz wydają się zupełnie proste.”

„Programiści mogą w końcu wyjść poza paradygmat Mobile First i wykorzystać swoje umiejętności, aby w pełni wykorzystać możliwości dwóch miliardów smartfonów na świecie. Przypomina mi to przejście na Web 2.0 jakieś dziewięć lat temu. Następnie wszyscy programiści powiedzieli: "Wiesz, nie musimy myśleć o Lynxie, skryptach CGI i połączeniach dial-up. Minęliśmy punkt, w którym używanie tagu IMG wydawało się kontrowersyjne i możemy pomyśleć o tym, jak stworzyć interfejsy i zapewnić użytkownikom nowe usługi” – podsumowuje Evans.

Przy zmianie rozmiaru do 720 pikseli lub mniej, nagłówek staje się większy z wygodnymi przyciskami o wielkości 60 pikseli.
Wymiary, ustawienie, ilość pozycji menu i przycisków dopasowują się do szerokości urządzenia.
Jeśli znasz swoje proporcje, możesz znaleźć złoty środek, w którym wymiary pasują zarówno do urządzeń mobilnych, jak i komputerów stacjonarnych. Na przykład nagłówki sekcji. Wymiary i proporcje typografii

W pewnym sensie większe jest lepsze. Ale co ważniejsze, proporcje harmonizują z treścią. Jeśli tekst główny ma rozmiar 24 piks, upewnij się, że dobrze pasuje do reszty witryny. Nie ma tutaj sztywnych zasad, ale wysokość linii powinna mieścić się pomiędzy 1,2x zanim 1,4x rozmiar czcionki. Ustaw rozmiary, gęstości i odmiany kolorów w oparciu o priorytety. Wiele tutaj wynika z instynktu i wyszkolonego oka.

Długość linii musi wynosić od 45 do 90 znaków. Ogólne zasady typografii opisano bardziej szczegółowo w tym poradniku.

Praca z SVGU przy użyciu WebKit do animacji

Wydajność jest ważna: wpływa bezpośrednio na komfort użytkownika. Jeśli wszystko działa wolno, ludzie nie będą przejmować się podtytułami w twoim projekcie, ponieważ będą myśleć tylko o tym, jak wolno to wszystko działa.

Poniżej, gdy samochód się uruchamia, użyłem transformacji webkit zamiast animacji jQuery. Dzięki tej implementacji wydajność znacznie się poprawia. Dodatkowo działa świetnie na mobilnym Safari i Chrome.

Dla paralaksy ustawiłem różne prędkości dla 3 różnych elementów. Użyłem transformacji webkit zamiast najwyższej pozycji CSS. Dzięki temu przewijanie stało się znacznie płynniejsze. Konfigurowanie rzutni

Musimy zadbać o to, aby urządzenia iOS i Android skalowały projekt o 0,5, aby wszystko działało pięknie na ekranie o szerokości 640px. W przypadku iPada skalujemy do 1.

Inteligentny baner na iOS

Jeśli masz iPhone'a, możesz dodać fragment kodu, który połączy górę witryny z Twoją aplikacją.

Kiedy ludzie uzyskują dostęp do witryny za pośrednictwem swojego iPhone'a lub iPada, widzą piękny baner przenoszący ich do App Store. Korzystanie z symulatora iOS
Sprawdzanie w Chrome na Androidzie

Połowa użytkowników telefonów komórkowych korzysta z Androida. Aby przetestować elementy w przeglądarce Chrome na Androidzie, postępuj zgodnie z poniższymi instrukcjami.

Zajęło mi trochę czasu opanowanie opcji w menu hamburgera Narzędzia > Sprawdź urządzenia. Wnioski

Stworzenie naprawdę responsywnej strony internetowej, działającej we wszystkich przeglądarkach i na wszystkich urządzeniach, nie jest łatwym zadaniem. Dlatego musisz pracować tak efektywnie, jak to możliwe, aby nie spędzać większości czasu na drobiazgach, które doprowadzają programistę do szaleństwa. Podobnie jak zrezygnowaliśmy ze wsparcia dla IE6, usunęliśmy także niektóre starsze urządzenia i niższe rozdzielczości.

Data publikacji: 29.03.2013

Komentarz autora: Na początku tego roku byłem na początkowym etapie przebudowy strony internetowej naszej firmy. Planowaliśmy już zastosować podejście do projektowania stron internetowych, które są bezpośrednio responsywne, co jest preferowanym rozwiązaniem w przypadku obsługi wielu urządzeń. Po tym, jak podczas szczerych dyskusji w An Event Apart w Bostonie dowiedziałem się o ograniczeniach i wyzwaniach związanych z responsywnym projektowaniem stron internetowych, zdałem sobie sprawę, że nasze rozwiązanie wymaga drobnych poprawek.

Na szczęście stojący przed nami projekt okazał się doskonałą okazją do eksperymentowania i rzucania sobie wyzwań w celu ulepszenia naszego adaptacyjnego przepływu pracy. W tym artykule szczegółowo opiszę kroki, które podjęliśmy, łącznie z pewnymi zmianami, które poczyniliśmy w trakcie pracy nad stworzeniem lepiej responsywnej witryny internetowej.

Ustalać cele

Pierwszym krokiem, jaki zrobiliśmy w naszym projekcie, było stworzenie listy korzyści i barier naszego adaptacyjnego podejścia. Nasza lista wyglądała następująco:

ZALETY

1. Budowa, wsparcie i promocja jednej strony internetowej.

2. Obsługuje wiele rozmiarów ekranów, nie tylko bardzo duże monitory stacjonarne i małe urządzenia przenośne.

3. Przyszłościowy, ponieważ układ będzie się zmieniać w zależności od rozmiaru ekranu, a nie tylko rozmiaru popularnych obecnie urządzeń.

PRZESZKODY

1. Treści przeznaczone wyłącznie dla urządzeń z dużym ekranem są często przesyłane strumieniowo na małe ekrany i po prostu „wycinane” za pomocą zapytań o media CSS, co powoduje niepotrzebne pobieranie.

2. Ze względu na układ „no size” nie jesteśmy w stanie zmienić pierwotnej kolejności takiego układu (lub całkowicie wyeliminować z niego elementów nieistotnych) w zależności od urządzenia lub rozmiaru ekranu.

Prawdopodobnie zauważysz, że zidentyfikowane przez nas wady podejścia adaptacyjnego to te obszary, w których najlepsze jest jedynie mobilne rozwiązanie problemu. W przypadku naszej nowej strony internetowej chcieliśmy tego, co najlepsze z obu światów – korzyści, jakie może zaoferować podejście responsywne i dedykowane rozwiązanie mobilne.

Zaczynając od treści

Jedną z typowych różnic między projektami responsywnymi i dostosowanymi do urządzeń mobilnych lub tylko do urządzeń mobilnych jest treść lub właściwości przekazywane do przeglądarki. Dedykowana witryna mobilna często odzwierciedla tylko podzbiór treści znajdujących się w „normalnej” wersji witryny. Jest to jedna z toczących się debat pomiędzy tymi dwoma podejściami, w której zwolennicy witryn internetowych dostępnych wyłącznie na urządzeniach mobilnych często argumentują, że użytkownicy mobilni chcą mieć dostęp wyłącznie do treści, które są dla nich „ważne”.

Problem z tym sposobem myślenia polega na tym, że to, co jest „ważne” dla użytkownika – dowolnego użytkownika – zmienia się w zależności od sytuacji. Ograniczanie dostępu do treści tylko ze względu na urządzenie, z którego korzystasz, to niezawodny sposób na złość i rozczarowanie tych, którzy nie pasują do idealnego scenariusza, jaki sobie wyobrażałeś, podejmując decyzję, co zachować, a co usunąć ze swojej witryny mobilnej.

Zawsze wierzyliśmy, że wszyscy użytkownicy powinni mieć dostęp do całej zawartości witryny internetowej, ale chcieliśmy mieć pewność, że jest to faktycznie odpowiednie dla naszej witryny i naszych użytkowników. Aby określić właściwe podejście, zwróciliśmy się do naszych analityków i nie znaleźliśmy zauważalnej różnicy między rodzajem treści żądanych przez gości mobilnych i odwiedzających z urządzeń innych niż mobilne. Treści popularne wśród użytkowników komputerów stacjonarnych były równie popularne wśród użytkowników mobilnych.

Ponadto usiedliśmy i rozmawialiśmy z niektórymi naszymi obecnymi klientami, którzy stanowią większość odbiorców naszej witryny, i zadaliśmy im kilka pytań, w tym: „Po jakie treści przychodzisz na naszą witrynę, kiedy siedzisz na monitor stacjonarny?” i: „A co z tabletem lub telefonem?” Wywiady były oczywiście bardziej szczegółowe, ale już widać, co nas zainteresowało. Ponownie stwierdzono, że wyszukiwana treść była taka sama niezależnie od używanego urządzenia.

Dane wyznaczają kierunek

Fakty, które odkryliśmy podczas naszych badań, utwierdziły nas w przekonaniu, że podejście responsywne, zapewniające dostęp do tych samych treści na każdym urządzeniu, było właściwym wyborem dla naszej witryny. Badanie to pozwoliło nam również określić, jakie treści na naszej stronie internetowej w ogóle nie były odwiedzane. Kiedy znaleźliśmy strony, które nie były używane przez naszych odbiorców, wycinaliśmy je z mapy witryny. To samo zrobiono z najmniej popularnymi treściami w hierarchii treści i naszymi planami przeprojektowania.

Rozpoczynając projekt od sprawdzenia treści i zbierając dane na temat tego, co jest ważne dla naszych odbiorców, a co nie, mogliśmy przejść do etapu projektowania z rozsądnym planem dotyczącym treści, które projekt naszej witryny powinien obsługiwać.

Tworzenie projektu punktów skrajnych

Słyszałem argumenty przemawiające za projektowaniem w przeglądarce i doceniam korzyści, jakie zapewnia to podejście. Po kilku próbach tworzenia projektów w przeglądarce odkryłem, że najłatwiej i najwygodniej jest zacząć od własnego projektu w Photoshopie. Absolutnie nie wierzę, że jest to właściwa decyzja dla wszystkich, ale w moim przypadku jest to prawda i dlatego rozpocząłem ten projekt.

Do projektowania responsywnego stosuję metodę, którą nazywam „projektowaniem krawędzi”. Zaczynam od stworzenia desktopowej wersji strony. Opracowuję w nim układ typograficzny tekstów projektu, styl i ogólny kierunek wizualny - a także układ panoramicznego widoku strony internetowej. Kiedy już jestem zadowolony z tej wersji strony, pracuję na małym ekranie lub w wersji „mobilnej”, obierając ten sam kierunek wizualny, ale dostosowując układ do mniejszego ekranu. Na koniec tego procesu mam już wizualne przykłady dwóch bardzo różnych układów stron internetowych – wersje tego projektu dla największego i najmniejszego ekranu. Te dwa przykłady będą moim przewodnikiem podczas tworzenia front-endu strony internetowej.

Najpierw mobilność

Podejście „” do projektowania adaptacyjnego nie jest pomysłem nowym. Ta metoda, w której najpierw tworzysz mobilny układ witryny, a następnie używasz zapytań o media w celu dopasowania i dodawania elementów do tego układu w miarę zwiększania się rozmiaru ekranu, jest od pewnego czasu uważana za najlepszą praktykę w projektowaniu responsywnych stron internetowych. Podejście to nie jest nowe, jest nadal bardzo ważne, a w połączeniu z naszym planem „zacznij od treści” pomogło nam skupić energię na jednym z niedociągnięć zidentyfikowanych w projektach adaptacyjnych – problemie przekazywania nieistotnych treści.

Zaczynając od treści, zadbaliśmy o to, aby cała zawartość naszej witryny była istotna i odpowiednia dla wszystkich użytkowników, zarówno mobilnych, jak i nie tylko. Oznaczało to, że nie musieliśmy się martwić o przekazywanie dużej ilości treści w znacznikach, a raczej po prostu wizualnie ukryliśmy je za pomocą CSS. Podejście zorientowane na urządzenia mobilne oznaczało, że obrazy te będą udostępniane wyłącznie urządzeniom, dla których były przeznaczone. Na przykład nasz nowy projekt wymagał grafiki tła o fakturze akwareli.

Obraz, dość duży, miał stać się częścią projektu tylko na dużych ekranach (od 660 px i większych). Ponieważ nasz CSS zaczyna się od projektu mobilnego, te duże grafiki nigdy nie są wysyłane na urządzenia z małymi ekranami, ponieważ zapytanie o media ładujące ten obraz jest wywoływane tylko przez duże ekrany. Zapytanie o media, które stosuje tło do elementu HTML, wygląda następująco:

Tylko ekran @media i (min. szerokość: 660 pikseli) ( html ( tło: url(/images/bg-watercolor.jpg) bez powtarzania, stałe na środku u góry; ) )

Tylko ekran @media i (min. szerokość: 660 pikseli) ( HTML ( tło: url (/images/bg - akwarela. jpg) nie - powtórz stałe na środku u góry;

Oprócz zastosowania tego obrazu tła zapytanie o media działające w rozdzielczości 660 pikseli oznacza także szereg innych zmian w układzie witryny internetowej, począwszy od układu uznawanego za układ małego ekranu do różnych wersji szerokoekranowych.

Tworzenie dla projektu, a nie dla urządzeń

Kiedy zaczęliśmy stosować projektowanie responsywne w naszych projektach internetowych, skupiliśmy się na znanych urządzeniach i rozmiarach ekranów, a nasze zapytania o media często je odzwierciedlały (iPhone'y, iPady - zarówno w orientacji pionowej, jak i poziomej - laptopy, komputery stacjonarne z panoramicznym ekranem itp. .d). Z biegiem czasu odkryto, że nie było to najlepsze podejście, ponieważ dotyczyło tylko tych urządzeń i rozmiarów ekranów, które są obecnie popularne, a nie tych, które mogą pojawić się w przyszłości. Jedną z największych zalet responsywnego projektowania stron internetowych jest jego przyszłościowy charakter. Aby w pełni wykorzystać tę zaletę, odeszliśmy od budowania dla urządzeń, zamiast pozwolić, aby projekt dyktował punkty przerwania zapytań o media.

Metoda mobilna była podstawą CSS naszej witryny. Mając to na uwadze, uruchomiliśmy stronę w przeglądarce i przeskalowaliśmy ją do najmniejszego rozmiaru naszego układu (ustawiliśmy CSS na minimalną szerokość 320px). Stopniowo zwiększano rozmiar okna przeglądarki, aby zobaczyć reakcję znaczników. W miarę powiększania się okna zauważyliśmy, że oznaczenia zaczęły się deformować. To właśnie w tych momentach musieliśmy ustawić nowe zapytania o media, aby dostosować znaczniki.

Aby zrozumieć tę metodę, stworzyliśmy grafikę i ustawiliśmy ją jako tło pulpitu. Pionowe linie miały szerokość 320 pikseli (nasz najmniejszy rozmiar), następnie były rozmieszczone co sto pikseli, zaczynając od 400, i służyły jako linie pomocnicze podczas skalowania okna przeglądarki w celu określenia, gdzie projekt zaczynał się psuć, a następnie użyliśmy tych przybliżone wartości pikseli w końcowych zapytaniach o media, które zostały dodane do CSS.

Podejście polegające na dodawaniu zapytań o media w oparciu o wymagania projektowe, a nie znane rozmiary urządzeń, pozwala witrynie lepiej reagować na szeroki zakres rozmiarów ekranów. Jednak w rezultacie wypełnia plik CSS większą liczbą zapytań o media, niż w przypadku zastosowania punktów przerwania specyficznych dla urządzenia. Mimo że liczba zapytań o media jest większa, same zapytania są zwykle bardzo małe, ponieważ w każdym z nich wprowadza się bardzo niewiele zmian, zamiast tworzyć drastyczne zmiany, których normalnie wymagałyby zapytania o media oparte na urządzeniu.

Jednym z obszarów naszej witryny, w którym nastąpił wyraźny wzrost zapytań mediów, jest nawigacja.

Nawigacja adaptacyjna

Nawigacja to jeden z najtrudniejszych aspektów projektowania responsywnego. Nasza strona internetowa składa się zasadniczo z czterech głównych obszarów nawigacji.

1. Nawigacja główna;

2. To, co nazywamy „nawigacją pomocniczą”, która łączy się z różnymi portalami i usługami, z których korzystają nasi klienci;

3. Nawigacja stopką;

4. Nawigacja po poszczególnych sekcjach prezentowana jest na podstronach serwisu (dla układów wielkoekranowych) w lewej kolumnie.

Ponieważ nasz CSS jest dostosowany przede wszystkim do urządzeń mobilnych, jednym z pierwszych problemów było skonfigurowanie nawigacji dla układu małego ekranu. Oznacza to wyłączenie wyświetlania wszystkich sekcji nawigacyjnych z wyjątkiem nawigacji głównej.

#helpNav, .subNav, nawigacja w stopce (wyświetlanie: brak; )

#helpNav, .subNav, nawigacja stopki ( Nie wyświetla się;

Co więcej, wspomniałem już, że naszym celem nie jest dostarczanie treści na urządzenia, a dopiero potem „wyłączanie”. Właściwie taki był cel, ale w naszej nawigacji musieliśmy się pogodzić z tym, jak to zrobić. Nie udało nam się znaleźć innego, prostego, ale obsługiwanego rozwiązania. Na szczęście treści, które dostarczamy i których nie udostępniamy, to tylko kilka wpisów, więc ich wpływ na pobieranie przez użytkowników jest minimalny.

Nawigacja pomocnicza to jedyny obszar witryny, który według nas nie był odpowiedni dla większości użytkowników, ponieważ te linki i portale były przeznaczone wyłącznie dla użytkowników komputerów stacjonarnych. To mocne założenie i odważne stwierdzenie. Główną przyczyną tego był fakt, że same portale były aplikacjami stron trzecich, na które nie mieliśmy wpływu, niezoptymalizowanymi pod kątem urządzeń mobilnych z małymi ekranami, a oferowane przez nie usługi były dostosowane do obsługi klientów korporacyjnych posiadających duże ekrany komputerów stacjonarnych.

Ta sytuacja zainspirowała nas do podjęcia decyzji o usunięciu tej sekcji z wersji na małym ekranie i przez miesiące funkcjonowania witryny nie otrzymaliśmy od naszych użytkowników żadnych komentarzy ani skarg dotyczących tej decyzji. Jeśli chodzi o pozostałe dwa obszary nawigacyjne, sekcję nawigacji podstron oraz sekcję stopki, treść ta prezentowana jest w ramach głównej nawigacji na urządzeniach z małym ekranem. Dlatego domyślnie wyłączamy te trzy obszary.

Później, gdy rozmiar ekranu wzrośnie i przekroczymy punkt 660 pikseli, w którym zaczyna się pojawiać projekt szerszego ekranu, nadamy tym obszarom nawigacyjnym wymagane style.

Oto kod CSS naszej dodatkowej nawigacji:

#helpNav ( wyświetlacz: blok; pozycja: bezwzględna; góra: 1 piks.; prawo: 0 pikseli; szerokość: 100%; wyrównanie tekstu: prawo; ) #helpNav ul ( padding-left: 10px; ) #helpNav li ( display: inline; dopełnienie-w prawo: 6px; dopełnienie-w lewo: 6px; kolor tła: #2f6a98; ) #helpNav a (rozmiar czcionki: 12px; dopełnienie: 0 6px; kolor: #FFF; promień obramowania: 20px; ) #helpNav a :hover (kolor tła: #f66606; )

#helpNav ( Blok wyświetlacza; pozycja: absolutna; góra: 1px; po prawej: 0 pikseli; szerokość: 100%; tekst - wyrównaj: do prawej; #helpNavul ( dopełnienie - po lewej: 10px; #helpNavli ( wyświetlacz: wbudowany; dopełnienie - po prawej: 6px; dopełnienie - po lewej: 6px; tło - kolor: #2f6a98; #helpNav a ( rozmiar czcionki: 12px; dopełnienie: 0 6px; kolor: #FFF; obramowanie - promień: 20px; #helpNav a:hover (

Oraz obszary nawigacji podstron:

SubNav (wyświetlanie: blok; szerokość: 25%; pływak: lewy; ) .subNav h4 ( dopełnienie-dół: 8px ) .subNav ul ( styl listy: dysk; kolor: #c65204; dopełnienie: 0 0 20px 20px; ). subNav li ( dopełnienie-dół: 14px; ) .subNav a ( kolor: #186483; rozmiar czcionki: 21px; rodzina czcionek: "RokkittRegular", Times, "Times New Roman", serif; wysokość linii: 1; )

SubNav( Blok wyświetlacza; szerokość: 25%; pływak: w lewo; SubNav h4 ( dopełnienie - dół: 8px SubNavul ( styl listy: dysk; kolor: #c65204; dopełnienie: 0 0 20px 20px; SubNavli ( dopełnienie - dół: 14px; SubNav a ( kolor: #186483; rozmiar czcionki: 21px; wysokość linii: 1;

Na koniec nawigacja w stopce:

stopka nav ( display: block; margines-góra: 40px; ) stopka nav ul ( styl listy: brak; ) stopka nav li ( padding-bottom: 24px; szerokość: 19%; padding: 0 5% 20px 0; float: left; ) .innerNav li ( szerokość: 100%; float: brak; dopełnienie-dolne: 4px; ) stopka nav a ( kolor: #575454; rozmiar czcionki: 12px; ) .innerNav a ( waga czcionki: normalna; )

nawigacja stopki ( Blok wyświetlacza; margines - górny: 40px; stopka nawigacyjna ul ( styl listy: brak; navli stopki ( dopełnienie - dół: 24px; szerokość: 19%; dopełnienie: 0 5% 20px 0; pływak: w lewo; Wewnętrzna Navli ( szerokość: 100%; pływak: brak; dopełnienie - dół: 4px; nawigacja stopki a ( kolor: #575454; rozmiar czcionki: 12px; Wewnętrzna nawigacja a ( waga czcionki: normalna;

Piksele lub ems

Zauważysz, że w naszych zapytaniach o media używaliśmy wartości pikseli. Dzięki pikselowym zapytaniom o media, podobnie jak inni programiści front-end, zaczęliśmy projektować responsywnie i przyjęliśmy tę praktykę jako część naszego przepływu pracy. Jednak w duchu „budowania lepiej responsywnej witryny internetowej” zwrócę uwagę na artykuł na temat zapytań o media wymiarowe przy użyciu emów, na który zwrócono nam uwagę podczas redagowania tej sekcji. W rzeczywistości, aby poprawić wygląd witryny podczas powiększania, zdecydowanie zaleca się konwersję zapytań o media px na zapytania o media em, dzieląc wszystkie wartości pikseli przez rozmiar czcionki.

Ten wspaniały artykuł zainspirował nas do ponownego przemyślenia naszego myślenia o zapytaniach o media opartych na pikselach i jest kolejnym przykładem tego, jak stale udoskonalamy podejście responsywne. Chociaż w tym konkretnym projekcie nie używaliśmy em w zapytaniach o media, obecnie z nimi eksperymentujemy i warto wspomnieć o tym podejściu.

Główna nawigacja

Nasza główna nawigacja jest prezentowana na szerokich ekranach jako poziomy rząd u góry układu. Na małych ekranach struktura głównej nawigacji zmienia się tak, że u góry każdej strony znajduje się duży przycisk Menu prowadzący do nawigacji u dołu strony. Aby to osiągnąć, do nagłówka dodaliśmy link z identyfikatorem menuLink i klasą tabButtonr, co stanowi niemal początek znacznika. Następnie na samym końcu znacznika umieściliśmy sekcję z identyfikatorem mainNav. Wewnątrz tej sekcji znajduje się nasza główna nawigacja, która jest po prostu nieuporządkowaną listą, w której znajduje się kilka innych nieuporządkowanych list dla menu sekcji podstrony. Posiadamy również kotwicę o identyfikatorze toTop, która pełni funkcję linku na górę strony.

Kontynuując zasadę „najpierw mobilny”, stylizowaliśmy łącze menu u góry układu małego ekranu tak, aby wyglądało jak przycisk.

#menuLink a ( float: prawy; margines: -56px 8px 0 0; ) .tabButton a ( kolor: #FFF; rodzina czcionek: "RokkittRegular", Times, "Times New Roman", serif; rozmiar czcionki: 20px; kolor tła: #45829b; dopełnienie: 10px 12px; promień obramowania: 10px; ) .tabButton a:hover ( kolor tła: #f66606; )

#menuLink a ( pływak: prawo; margines: - 56px 8px 0 0; Przycisk Tab a ( kolor: #FFF; czcionka - rodzina: "RokkittRegular" , Times , "Times New Roman" , serif ; rozmiar czcionki: 20px; tło - kolor: #45829b; dopełnienie: 10px 12px; obramowanie - promień: 10px; TabButton a: najedź ( tło - kolor: #f66606;

Nasze główne menu nawigacyjne jest ustawione na wyświetlanie na małym ekranie:

#mainNav ( margines na górze: 30px; szerokość: 100%; ) #mainNav #toTop a ( float: prawo; margines: 0 8px 0 0; rozmiar czcionki: 20px; ) #mainNav nav ( góra dopełnienia: 80px; ) #mainNav ul (styl listy: brak; ) #mainNav li ( tło: #45829b; obramowanie-dół: 1px solid #abc7d2; dopełnienie: 4px 10px 4px 15px; ) #mainNav li:hover ( kolor tła: #f66606; ) #mainNav a (rozmiar czcionki: 24px; kolor: #FFF; rodzina czcionek: „RokkittRegular”, Times, „Times New Roman”, serif; )

#mainNav ( margines - górny: 30px; szerokość: 100%; #mainNav #toTop a ( pływak: prawo; margines: 0 8px 0 0; rozmiar czcionki: 20px; #mainNav nawigacja ( dopełnienie - góra: 80px; #mainNavul ( styl listy: brak; #mainNavli ( tło: #45829b; obramowanie - dół: 1px bryła #abc7d2; dopełnienie: 4px 10px 4px 15px; #mainNav li:hover ( tło - kolor: #f66606; #mainNav a ( rozmiar czcionki: 24px; kolor: #FFF; czcionka - rodzina: "RokkittRegular" , Times , "Times New Roman" , serif ;

Nasze podmenu, które nie są wyświetlane w pierwotnej pozycji, można teraz wyświetlać zgodnie z wymaganiami strony. Każde z tych podmenu ma unikalny identyfikator, taki jak ServicesTab, a każda sekcja witryny internetowej ma klasę przypisaną do znacznika treści. Klasa sekcji „Firma” to CompanyPage. Używamy tej klasy do stylizacji całej sekcji witryny. Aby włączyć podmenu, używamy klasy sekcji podmenu zgodnie z wymaganiami, gdy sekcja jest aktywowana.

CompanyPage #companyTab ul, .newsPage #newsTab ul, .contactPage #contactTab ul, .servicesPage #servicesTab ul (wyświetl: blok; )

Strona firmowa #firmaTab ul, AktualnościPage #newsTab ul, Strona kontaktowa #contactTab ul, UsługiStrona #usługiTab ul ( Blok wyświetlacza;

Zwiększamy się

W miarę pojawiania się większych układów ekranów – ponownie z zapytaniami o media o rozdzielczości 660 pikseli i większej – radykalnie zmieniamy układ głównej nawigacji. W pierwszej kolejności wyłączamy wyświetlanie przycisków menuLink i toTop, gdyż nie są już potrzebne:

#menuLink a, #toTop a (wyświetlanie: brak; )

#menuLink a, #toTop a ( Nie wyświetla się;

#mainNav ( pozycja: bezwzględna; góra: 92 piksele; margines: 18 pikseli 2% 0 2%; szerokość: 96%; wyrównanie tekstu: środek; ) #mainNav nav ( dopełnienie: 5 pikseli 0; górna granica: 1 pikseli bryła #bacfd7; border-bottom: 1px solid #bacfd7; ) #mainNav li ( tło: brak; display: inline; border-bottom: 0; border-right: 1px solid #bebebe; padding: 0 6px 0 8px; margines: 4px 0; ) #mainNav a (rozmiar czcionki: 16 pikseli; kolor: #45829b; ) #mainNav a:hover ( kolor: #f66606; )

#mainNav ( pozycja: absolutna; góra: 92px; margines: 18px 2% 0 2%; szerokość: 96%; tekst - wyrównaj: do środka; } #mainNav nawigacja ( dopełnienie: 5px 0; obramowanie - góra: 1px solidna #bacfd7; obramowanie - dół: 1px solid #bacfd7; } #mainNavli ( tło: brak; wyświetlacz: wbudowany; obramowanie-dół: 0; rozmiar: 16 pikseli; kolor: #45829b; } #mainNav a:hover ( kolor: #f66606; }

Style te określają wygląd głównej nawigacji. Aby jednak dopasować go do projektu, a nie do urządzenia, będziemy musieli wprowadzić drobne poprawki w miarę zwiększania się rozmiaru ekranu. W sumie nasza główna czcionka nawigacyjna ma osiem różnych rozmiarów układu panoramicznego, zmieniających się w miarę poszerzania ekranu i zwiększania obszaru roboczego. Ustalenie, jak najlepiej wyświetlić tę nawigację w sposób, który sprawi, że będzie łatwa w użyciu i atrakcyjna wizualnie, było jedną z przeszkód, jakie napotkaliśmy podczas pracy nad responsywnym projektem.

Postępujemy według tego schematu kilkukrotnie, ostatecznie zwiększając rozmiar czcionki do 27px, gdy witryna osiągnie swój największy rozmiar. Dzięki temu nawigacja witryny jest dopasowana do projektu i ekranu używanego, aby jak najlepiej ją przeglądać.

Uzyskanie pomocy z CMS

Naszym preferowanym CMS jest ExpressionEngine i specyfika następnej części artykułu jest specyficzna dla tej platformy, ale podstawową ideę tego, co osiągnęliśmy dzięki ExpressionEngine, z pewnością można zastosować na innych popularnych platformach CMS.

Jedną z największych przeszkód w podejściu responsywnym jest to, że nie można zapewnić różnych znaczników lub innego kodu źródłowego dla różnych urządzeń. To jest przeszkoda, którą chcieliśmy pokonać przy pomocy naszego CMS-a. Eksperymentując i badając, natknęliśmy się na artykuł zatytułowany Going True Adaptive with ExpressionEngine. Korzystając z metodologii opisanej szczegółowo w tym artykule, mogliśmy użyć skryptu wykrywania urządzenia do ustawienia zmiennej w systemie mobilnym lub stacjonarnym. Następnie mogliśmy załadować znaczniki do naszej witryny w oparciu o to, które z tych zmiennych napotkaliśmy.

Idąc dalej i stosując wykrywanie urządzeń, byliśmy w stanie wprowadzić inne bardzo drobne zmiany, aby jeszcze bardziej poprawić komfort korzystania z urządzeń mobilnych. Dla nas było to coś w rodzaju stopniowego ulepszania, podczas którego zbudowaliśmy wysokiej jakości rozwiązanie, a następnie staraliśmy się je popchnąć do przodu, aby zapewnić nieco zoptymalizowane wrażenia. Koniecznie przeczytajcie podobną opinię Chrisa Coyiera na temat łączenia szablonów RWD i mobilnych, gdzie argumentuje on za mieszaniem i dopasowywaniem różnych technik w swojej strategii mobilnej.

Zacznijmy od małych rzeczy

Można oczywiście użyć tych zmiennych, aby dostarczyć zupełnie różne znaczniki i kod źródłowy na różne urządzenia, ale nasze początkowe podejście było nieco mniej ekstremalne. Ponieważ już zdecydowano, że dowolna wersja naszej witryny będzie miała dostęp do wszystkich treści, początkowo zastosowaliśmy tę zmienną metodę, aby nieznacznie regulować ilość dostarczanych treści. Na przykład na stronie głównej naszej witryny internetowej wyświetlamy zwiastuny wielu treści znajdujących się w witrynie. W sekcjach „Kultura” i „Wyróżnienie projektu” każdemu postowi towarzyszy zdjęcie.

Obrazy są miłym dodatkiem, ale zdecydowanie nie kluczowym, dlatego w ogóle nie pokazujemy ich użytkownikom mobilnym. Powtarzam, nie mam na myśli tego, że używamy CSS do ich wyłączania, co i tak załaduje dane do przeglądarki; zamiast tego używamy ustawionych zmiennych, aby wykluczyć obrazy ze znaczników, jeśli nie powinny być wyświetlane.

Składnia jest dość prosta. Kiedy już ustawisz zmienne – a powyższy artykuł wyjaśnia, jak łatwo to zrobić poprzez dodanie małego skryptu do systemowego pliku config.php – możesz użyć tych zmiennych jako instrukcji if.

img src = "(obrazek zwiastuna)" alt = "(tytuł)" / > { / if } { if global : site_version == "mobile" } { title } { / if } !}

To jest składnia ExpressionEngine, ale możesz ją przeczytać i łatwo zobaczyć, co się dzieje. W przypadku napotkania pełnej zmiennej dostarczamy obraz zwiastuna z wpisu artykułu w bazie danych. Jeśli zamiast tego napotkamy zmienną mobile, wówczas podajemy tytuł tytułu artykułu.

To samo podejście zastosowano do sekcji „Aktualności” i „Blog” na stronie głównej, wyświetlając trzy krótkie zwiastuny, jeśli napotkana została pełna zmienna, i tylko jeden, jeśli na urządzeniu mobilnym. Składnia wygląda następująco:( exp : kanał : wpisy kanał = „wiadomości” ( jeśli globalne : wersja_strony == „pełna” ) limit = „3” ( / if ) ( jeśli globalne : wersja_strony == „mobile”) limit = „1” ( / jeśli ) )

Tutaj możesz zobaczyć, że uzyskujemy dostęp do kanału ExpressionEngine o nazwie news. Naszą zmienną wykorzystujemy do określenia, ile bieżących elementów będzie wyświetlanych z tego kanału za pomocą parametru limit.

Pójdźmy o krok dalej

W dziale Kultura serwisu publikujemy artykuły, którym często towarzyszy wiele zdjęć. W przeciwieństwie do obrazów zwiastunów na stronie głównej witryny, obrazy w artykułach same w sobie są niezbędne dla tej treści, ponieważ pomagają utrzymać lub zwiększyć atrakcyjność artykułu. Chociaż te obrazy są ważne, są również dość duże – każdy o szerokości 650 pikseli, a większość artykułów zawiera co najmniej trzy obrazy, czasem nawet dziesięć. Ponieważ urządzenia mobilne będą wyświetlać obrazy w mniej więcej połowie ich pierwotnego rozmiaru, ładowanie obrazów w pełnym rozmiarze stanie się dość ważne. Aby sobie z tym poradzić, spójrzmy jeszcze raz na definicję urządzenia i zmienne.

Dla każdego artykułu tworzymy dwa zestawy obrazów: jeden pełnowymiarowy o szerokości 650 pikseli i drugi o prawie połowę mniejszej wielkości. Następnie używamy zmiennych w naszym artykule (ale najpierw musimy włączyć kod ExpressionEngine w szablonie naszej strony) i dodajemy znaczniki dla obu zestawów obrazów - ale tylko jeden z nich jest dostarczany do przeglądarki. Urządzenia mobilne odbierają małe obrazy, podczas gdy wszystkie inne otrzymują obrazy w pełnym rozmiarze.
To samo podejście dotyczy dużej powierzchni reklamowej strony głównej. Te obracające się banery i obrazy reklamują ważne rzeczy, takie jak nadchodzące wydarzenia, nowe usługi i ogłoszenia, lepiej niż reszta strony głównej. Billboard to kolejny miły element, który jest przeznaczony wyłącznie do dużych wyświetlaczy. Po raz kolejny za pomocą zmiennych dostarczamy główną sekcję billboardu wraz z obsługującym ją JavaScriptem na odpowiednie urządzenie - co pozwala nam skutecznie wysyłać różne znaczniki na różne urządzenia i eliminować kolejną przeszkodę, którą zidentyfikowaliśmy na początku projektu.

Stosując podejście mobile-first i nasz CMS, jesteśmy w stanie dostarczyć naszą stronę główną użytkownikom komputerów stacjonarnych o rozmiarze 738,3 KB i znacznie zmniejszyć ją do zaledwie 174,4 KB dla użytkowników mobilnych.

Alternatywne plany

Jedno z pytań, które zawsze mnie niepokoiło w związku z podejściem wyłącznie mobilnym i wykrywaniem urządzeń, brzmi: „Co się stanie, jeśli wykrywanie się nie powiedzie? Czy „normalna” wersja strony internetowej jest wyświetlana na urządzeniu mobilnym, co unieważnia starannie przygotowany projekt mobilny? Ta funkcja jest jednym z głównych powodów, dla których unikałem stosowanego w przeszłości rozwiązania przeznaczonego wyłącznie do urządzeń mobilnych do wykrywania urządzeń.

W naszym adaptacyjnym przepływie pracy używamy wykrywania urządzeń, co daje nam świetne alternatywy na wypadek, gdyby z jakiegoś powodu wykrywanie urządzeń nie działało. Ponieważ stosujemy podejście responsywne, nawet jeśli pełna wersja zostanie dostarczona do przeglądarki mobilnej, znaczniki zmieszczą się na tym urządzeniu, ponieważ nasz CSS odpowiednio go dostosuje.

Ponadto, ponieważ wszystko jest dostosowane przede wszystkim do urządzeń mobilnych, elementy nieprzeznaczone dla małych ekranów, takie jak wspomniana wcześniej ogromna grafika w tle, w ogóle nie są odzwierciedlane. Jedyną rzeczą, która nas zawiedzie, będzie to, co zrobiliśmy ze zmiennymi wygenerowanymi w celu zdefiniowania urządzenia. Jeśli spełni się najgorszy scenariusz i nie uda się wykryć urządzenia, wersja mobilna otrzyma po prostu kilka dodatkowych obrazów, mały znacznik lub JavaScript. Ogólne wrażenie będzie nadal odpowiednie dla urządzenia mobilnego. Całkiem nieźle jak na „najgorszy scenariusz”.

Postęp, nie idealny

Kilka lat temu klient powiedział mi coś, co pamiętam do dziś. Mówiąc o swojej stronie internetowej powiedział:

« Nie martw się o to, aby moja witryna była idealna. Po prostu pracuj nad jego udoskonaleniem. Jej ciągłe doskonalenie będzie krokiem we właściwym kierunku».

Ten pomysł inspiruje mnie od lat i przypomina mi, żeby nie odrzucać najlepszego tylko dlatego, że nie jest idealne.

Wiem, że to rozwiązanie nie jest idealne i nie ma w tym nic złego, ponieważ stanowi ulepszenie naszego poprzedniego adaptacyjnego przepływu pracy. Pomogło nam to pokonać niektóre zidentyfikowane przeszkody i teraz możemy wprowadzić te ulepszenia do projektów, nad którymi pracujemy. Tak, nadal istnieje wiele zawiłości, na które nie możemy jeszcze skutecznie wpłynąć, takich jak dostarczanie wysokiej jakości obrazów na wyświetlacze HD, a także korzystanie z zapytań o media opartych na technologii em, o czym pisaliśmy wcześniej, ale w odniesieniu do tego i innych projektów idą we właściwym kierunku.

Kto wie… Może pewnego dnia ktoś zbuduje „idealną stronę internetową”. W tej chwili skupiamy się na postępie, a nie na perfekcji, wprowadzając po drodze drobne ulepszenia i pracując nad zbudowaniem bardziej responsywnej strony internetowej.

Jak myślisz?

Jak budować responsywne strony internetowe? Czy używasz definicji charakterystyki czy definicji urządzenia? Kiedy zalecasz użycie jednego lub drugiego? Czekamy na Twoje komentarze!