Decyzje programistów dotyczące tworzenia elastycznych komponentów

W realnym świecie treści często znacznie odbiegają od zgrabnych, idealnie dopasowanych treści prezentowanych w projektach. Co więcej, w nowoczesnej sieci użytkownicy mają coraz więcej opcji dostępu do tworzonych przez nas witryn.

W tym artykule omówimy proces wybierania pozornie prostego projektu komponentu tekstowo-medialnego i podejmowania decyzji, jak najlepiej przetłumaczyć go na kod, mając na uwadze potrzeby zarówno użytkowników, jak i autorów treści. Nie będziemy zagłębiać się w kodowanie — raczej czynniki, które będą determinować nasze decyzje dotyczące rozwoju. Na każdym kroku rozważymy pytania, które musimy zadać (zarówno sobie, jak i innym interesariuszom).

Zmiana naszego nastawienia na rozwój

Po prostu nie możemy już projektować i rozwijać tylko pod kątem „optymalnych” treści lub warunków przeglądania. Zamiast tego musimy przyjąć nieodłączną elastyczność i nieprzewidywalność sieci oraz zbudować odporne komponenty. Makiety statyczne nie są w stanie obsłużyć każdego scenariusza, dlatego wiele decyzji projektowych spada na deweloperów w czasie kompilacji. Czy ci się to podoba, czy nie, jeśli jesteś programistą UI, jesteś projektantem — nawet jeśli nie uważasz się za takiego!

W mojej pracy w agencji internetowej Atomic Smash specjalizującej się w WordPress, budujemy strony internetowe dla klientów, którzy potrzebują maksymalnej elastyczności z dostarczanych przez nas komponentów, jednocześnie dbając o to, by strona nadal wyglądała świetnie, bez względu na to, jakie treści na nią wrzucają. Czasami interpretacja projektu oznacza poproszenie projektanta o dalsze rozwinięcie swoich pomysłów (lub nawet ich ponowną ocenę). Innym razem oznacza to podejmowanie decyzji projektowych na bieżąco lub przedstawianie rekomendacji w oparciu o naszą wiedzę i doświadczenie. Przyjrzymy się, w jakich sytuacjach te podejścia mogą być odpowiednie w tym studium przypadku.

Projektowanie

Zaczynamy od prostego projektu komponentu tekstowo-medialnego — czegoś, co jest dość często spotykane na stronach docelowych produktów. Składa się z obrazu lub wideo po lewej stronie oraz kolumny po prawej zawierającej nagłówek, akapit tekstu i link wezwania do działania. Ten projekt jest przeznaczony dla (fikcyjnego) startupu, który pomaga osobom, które chcą nauczyć się nowej umiejętności, znaleźć korepetytora.

Uwaga: Jeśli chcesz przejść bezpośrednio do kodu i zobaczyć wszystkie możliwe rozwiązania, które znaleźliśmy dla tego komponentu, możesz je znaleźć w tym demo Codepen.

Układ i porządek

Projektant przewidział, że każdy inny komponent powinien mieć odwrócony układ, tak aby obraz znajdował się po prawej stronie, a kolumna tekstu po lewej.

Jednak w układzie mobilnym obraz jest we wszystkich przypadkach umieszczany nad treścią tekstową. Zakładając, że zbudujemy ten układ za pomocą Grid lub flexbox, możemy użyć flex-direction lub właściwości order , aby zmienić kolejność układu dla co drugiego komponentu:

 .text-and-media:nth-child(even) { flex-direction: row-reverse; }

Warto pamiętać, że chociaż zmienią one wizualnie kolejność zawartości, nie zmienią one kolejności DOM. Oznacza to, że dla osoby niedowidzącej przeglądającej witrynę za pomocą czytnika ekranu kolejność treści może nie wydawać się logiczna, przeskakując od lewej do prawej strony na drugą.

Mówiąc osobiście, w przypadku, gdy jedyną treścią w jednej z kolumn jest obraz, uważam, że użycie właściwości order jest mniej więcej w porządku. Ale gdybyśmy mieli na przykład dwie kolumny tekstu, zmiana kolejności za pomocą CSS może być myląca. W takich przypadkach mamy do dyspozycji kilka innych opcji. Moglibyśmy:

1. Przedstaw nasze obawy dotyczące ułatwień dostępu i zarekomenduj, aby w przypadku układów mobilnych kolejność wizualna została zmieniona tak, aby odpowiadała kolejności na komputerach stacjonarnych.
2. Użyj JavaScript, aby zmienić kolejność elementów w DOM.

Musimy również rozważyć, czy wymusić kolejność za pomocą selektora :nth-child , czy też pozwolić klientowi kontrolować kolejność (np. przez dodanie klasy do komponentu). Przydatność każdej opcji będzie prawdopodobnie zależeć od projektu.

Radzenie sobie z różnymi długościami treści

W projekcie stosunek treści tekstowej do obrazu jest dość przyjemny. Pozwala to na zachowanie idealnego współczynnika proporcji obrazu. Ale co powinno się stać, jeśli tekst jest dłuższy lub krótszy niż prezentowany? Najpierw zajmijmy się tym pierwszym.

Dłuższa treść

Możemy ustawić limit znaków w polu tekstowym w wybranym przez nas CMS (jeśli mamy taką ochotę), ale powinniśmy pozwolić na przynajmniej pewną wariację w naszym komponencie. Jeśli dodamy dłuższy akapit, kolumna mediów przeciwnych może zachowywać się na jeden z kilku sposobów:

1. Obraz lub film pozostaje na górze, a spacja jest dodawana poniżej (rys. 1).
2. Obraz lub film jest wyśrodkowany, dodając miejsce u góry lub u dołu (rys. 2).
3. Proporcje obrazu lub wideo są skalowane w celu dopasowania do wysokości za pomocą funkcji object-fit: cover , aby zapobiec zniekształceniom i zapewnić, że obraz wypełni dostępną przestrzeń. Oznaczałoby to, że niektóre części obrazu mogą zostać przycięte (rys. 3).

Zdecydowaliśmy, że opcja 3 jest najbardziej przyjemna wizualnie i że w większości autorzy treści byliby w stanie pozyskać odpowiednie obrazy, w których dopuszczalna byłaby niewielka ilość przycinania. Stanowiło to jednak większe wyzwanie w przypadku treści wideo, gdzie istnieje większe ryzyko, że ważne części mogą zostać przycięte. Znaleźliśmy inną opcję, która polegała na stworzeniu innej odmiany projektu, w której wideo zachowa oryginalne proporcje i będzie zawierało się w maksymalnej szerokości, zamiast wyrównać do krawędzi strony.

Autorzy treści mogli wybrać tę opcję, gdy lepiej odpowiadała ich potrzebom.

Dodatkowo zdecydowaliśmy się rozszerzyć ten wybór na przypadki, w których zamiast filmu użyto obrazu. Daje klientowi szerszą gamę opcji układu bez negatywnego wpływu na projekt. W szerszym kontekście strony można to nawet uznać za ulepszenie, umożliwiające tworzenie bardziej interesujących stron, gdy kilka z tych bloków jest używanych na stronie.

Krótsza treść

Radzenie sobie z mniejszą ilością treści jest nieco prostsze, ale nadal stwarza nam pewne problemy. Jak powinien zachowywać się obraz, gdy treść tekstu jest krótsza? Czy powinien stać się płytszy, aby całkowita wysokość elementu była determinowana treścią tekstu (rys. 4)? A może powinniśmy ustawić minimalny współczynnik proporcji, aby obraz nie był w formacie letterbox, lub pozwolić obrazowi zająć swoją naturalną, wewnętrzną wysokość? W takim przypadku również zastanawiamy się, czy wyrównać tekst centralnie, czy do góry (rys. 5 i 5a).

Długość nagłówka

Nie zapominajmy, że będziemy musieli również przetestować nagłówki o różnych długościach. W projekcie nagłówki są krótkie i żwawe, rzadko zawijają się w drugą linię. Ale co, jeśli nagłówek ma kilka wierszy lub treść zawiera wiele długich słów, co powoduje inne zawijanie tekstu? Może to stanowić problem zwłaszcza w językach takich jak niemiecki, w których słowa są zwykle znacznie dłuższe niż na przykład w języku angielskim. Czy rozmiar czcionki nagłówka w projekcie pozwala na odpowiednią długość linii w tym układzie? Czy długie słowa powinny być dzielone łącznikami podczas zawijania? Ten artykuł autorstwa Ahmada Shadeeda porusza kwestię długości treści i zawiera kilka przydatnych wskazówek, jak sobie z tym poradzić w CSS.

Czy autorzy treści mogą całkowicie pominąć nagłówek tam, gdzie im odpowiada? To prowadzi nas do następnego rozważania.

Pomijanie treści

Budowanie tego komponentu tak elastycznie, jak to możliwe, oznacza upewnienie się, że autorzy treści mogą pominąć pewne pola i nadal mieć wygląd i działanie projektu poprawnie. Wydaje się rozsądne, że klient może chcieć pominąć treść, link, a nawet nagłówek, gdy używa tego komponentu w środowisku naturalnym. Musimy zadbać o testowanie z każdą możliwą kombinacją treści, aby mieć pewność, że nasz komponent nie zepsuje się pod wpływem stresu. Dobrą praktyką jest upewnienie się, że nie renderujemy pustych tagów HTML, gdy nie ma zawartości pola. Pomoże nam to uniknąć nieprzewidzianych błędów układu.

Możemy ograniczyć autorów treści za pomocą „wymaganych” pól w CMS, ale być może moglibyśmy również rozważyć scenariusze, w których klient może zdecydować się na pominięcie obrazu lub odwrotnie, bez treści tekstowej? Pomocne może być udostępnienie im tych opcji. Oto przykład, jak możemy zdecydować się na renderowanie komponentu w takich przypadkach:

Dzięki nieznacznemu wcięciu tekstu i zwiększeniu szerokości tekstu podstawowego możemy zachować równowagę, nawet jeśli nie ma obrazu.

Wiele linków

Pominięcie treści to jeden ze scenariuszy. Jednak w Atomic Smash stwierdziliśmy, że klienci częściej chcieli mieć możliwość dodania więcej niż jednego łącza do komponentu. To daje nam inny wybór: jak rozmieścić wiele linków? Czy układamy je obok siebie (rys. 8) czy układamy je pionowo (rys. 8a)?

Jak radzimy sobie z tytułami linków o szalenie różnej długości? Fajną sztuczką jest ustawienie szerokości obu ogniw na maksymalną szerokość najdłuższego (rys. 9). (Ten artykuł dotyczy właśnie tego.) Działa to dobrze w przypadku przycisków ułożonych pionowo, podczas gdy układanie ich w poziomie daje nam jeszcze więcej możliwości (rys. 9a).

Czy potrzebujemy stylu łącza drugorzędnego, aby je odróżnić? To są wszystkie pytania do rozważenia.

Możemy również zastanowić się (w przypadku pojedynczego linku), czy w rzeczywistości klikalny obszar linku powinien obejmować cały komponent — aby użytkownicy mogli kliknąć w dowolnym miejscu, aby aktywować link. Ten wybór może być może zależeć od szerszego kontekstu. Jest to z pewnością powszechne w interfejsach użytkownika opartych na kartach.

Wideo

Gdy komponent jest używany do wideo, a nie do statycznego obrazu, możemy zauważyć, że projekt pomija niektóre kluczowe informacje. Jak sterowane jest odtwarzanie wideo? Po najechaniu? Czy odtwarza się automatycznie podczas przewijania? Czy kontrolki powinny być widoczne dla użytkownika?

Jeśli film jest odtwarzany po najechaniu myszą, musimy zastanowić się, w jaki sposób użytkownik urządzenia bez możliwości najechania kursorem uzyskuje dostęp do treści wideo. Alternatywnie, jeśli wideo odtwarza się automatycznie, powinniśmy rozważyć uniemożliwienie tego użytkownikom preferującym ograniczony ruch, którzy mogą cierpieć na zaburzenia przedsionkowe (lub po prostu chcieć uniknąć wstrząsających animacji). Powinniśmy również zapewnić wszystkim użytkownikom możliwość zatrzymania wideo, kiedy chcą.

Umieszczanie tego w kontekście

Jednym z problemów związanych z tak dużym skupieniem się na komponentach, jeśli chodzi o projektowanie stron internetowych, jest to, że czasami zapominamy zastanowić się, jak budowane przez nas komponenty będą wyglądać w kontekście całej strony internetowej. Musimy wziąć pod uwagę odstępy, zarówno między komponentami tego samego typu, jak iw układzie strony, w którym inne komponenty są przeplatane.

Te elementy tekstowo-medialne zostały zaprojektowane tak, aby można było ich używać oszczędnie, tworząc przyciągający wzrok kolor i zrywając z liniowym układem. Ale korzystając z WordPressa, autor treści może z łatwością zdecydować się na zbudowanie całej strony składającej się wyłącznie z tych komponentów. Może to wyglądać raczej nudno i wcale nie taki efekt, na jaki liczyliśmy!

Podczas procesu budowania zdecydowaliśmy się dodać opcję pominięcia koloru tła. To pozwala nam podzielić stronę i uczynić ją bardziej interesującą:

Moglibyśmy wymusić wzorzec za pomocą :nth-child lub dodać pole w CMS, aby dać klientowi większą kreatywną kontrolę.

Chociaż nie było to częścią oryginalnego projektu, pokazuje, że otwarta linia komunikacji między projektantem a deweloperem może pomóc w tworzeniu lepszych wyników pod względem bardziej elastycznych i solidnych projektów.

Style tekstu WYSIWYG

Rozważając treść, musimy brać pod uwagę nie tylko długość tekstu, ale także rzeczywiste elementy HTML, które mogą być dozwolone w polu tekstowym treści. Autorzy treści mogą chcieć dodać do kopii treści wiele akapitów, linków do kotwic, list i nie tylko. W Atomic Smash lubimy dostarczać WYSIWYG (To, co widzisz, jest tym, co dostajesz) lub pole tekstu sformatowanego dla tych obszarów, które mogą uwzględniać wiele różnych elementów. Ważne jest, aby testować z różnymi rodzajami treści i odpowiednim stylem — w tym testować wystarczający kontrast kolorów na wszystkich używanych kolorach tła.

Zawijanie

Dotykaliśmy wielu różnych decyzji związanych z budowaniem tego pozornie prostego komponentu. Możesz nawet pomyśleć o kilku innych, których tutaj nie omówiliśmy! Rozważając każdy aspekt projektu i sposób, w jaki można go wykorzystać w kontekście, otrzymaliśmy coś znacznie bardziej wszechstronnego, co, miejmy nadzieję, powinno zaowocować szczęśliwszymi klientami!

Czasami im więcej tego pominięto w projekcie, tym więcej czasu i uwagi będzie wymagać od dewelopera. Poniżej zestawiłem listę kontrolną rzeczy do przetestowania i zakwestionowania podczas tworzenia komponentu, które mogą okazać się przydatne. Może być również dostosowany do różnych komponentów.

Możliwość spojrzenia poza pozorną prostotę, rozbicie komponentu na części składowe, zadawanie kluczowych pytań (nawet zanim nastąpi rozwój), a nawet rozważenie przyszłych zastosowań, to umiejętności, które przydadzą się każdemu programiście podczas tworzenia stron internetowych — i pomoże Ci w zapewnieniu znacznie dokładniejszych szacunków w razie potrzeby. Dobra komunikacja w zespole i silny proces współpracy są nieocenione w budowaniu odpornych witryn, ale efekt końcowy sprawia, że ​​warto zainwestować w pielęgnowanie tej kultury. Wprowadźmy elastyczność do naszych procesów projektowania i budowania.

Lista kontrolna

Rzeczy do przetestowania:

1. Dostępność układu (mobilny i stacjonarny).
2. Obrazy o różnych wewnętrznych proporcjach — czy są odpowiednio przycięte?
3. Dłuższy i krótszy tekst główny (w tym wiele akapitów).
4. Dłuższy i krótszy nagłówek (w tym różne długości słów).
5. Pomijając (różne) nagłówek, treść, linki i obraz.
6. Wiele linków (w tym różne długości tekstu linku).
7. Dostępność treści wideo.
8. Treść tekstowa WYSIWYG (w tym linki, listy itp. w tekście głównym).
9. Testuj w kontekście — uwzględnij wiele komponentów (z różnymi opcjami treści), a także inne komponenty wmieszane w układ strony.