Magic UI, animowane komponenty do stron sprzedażowych

Magic UI, efekty wizualne bez pisania ich od zera

Strona sprzedażowa produktu ma jedno zadanie: zatrzymać uwagę na tyle długo, żeby ktoś przeczytał, o co chodzi. Animacje pomagają w tym zadaniu i jednocześnie są najbardziej czasochłonną częścią budowy takiej strony, bo każdy efekt trzeba dopracować osobno.

Magic UI to zbiór gotowych komponentów animowanych: napisy pojawiające się litera po literze, liczby odliczające w górę, siatki reagujące na kursor, świecące obramowania, przesuwające się paski z logotypami. Kopiujesz kod do projektu i od tej chwili jest Twój.

Model kopiowania zamiast zależności

To rozwiązanie działa tak samo jak shadcn/ui i warto rozumieć konsekwencje tego wyboru.

Nie instalujesz biblioteki komponentów. Wybierasz komponent, kopiujesz jego kod do swojego projektu i dalej pracujesz z nim jak z własnym plikiem. W zależnościach nie pojawia się pakiet z komponentami, nie ma aktualizacji przychodzących z zewnątrz i nie ma pytania, co się stanie, gdy autor porzuci projekt.

npx shadcn@latest add "https://magicui.design/r/typing-animation"

Jedno zastrzeżenie: brak zależności dotyczy samego zbioru, a nie wszystkiego, co komponent za sobą ciągnie. Powyższe polecenie dopisuje do package.json bibliotekę motion, bo w niej siedzi silnik animacji, a przy pojedynczych komponentach dochodzi jeszcze next-themes. Wyjątkiem są efekty zrobione samym CSS-em, jak przesuwający się pasek z logotypami albo świecące obramowanie, które nie deklarują żadnej zależności.

Warto też rozdzielić dwa produkty o tej samej nazwie. Zbiór komponentów jest otwarty na licencji MIT i nic nie kosztuje. Osobno sprzedawany jest Magic UI Pro: ponad pięćdziesiąt gotowych sekcji strony i co najmniej dziewięć szablonów całych witryn, licencja indywidualna za 199 USD jednorazowo, wieczysta, z prawem do użycia komercyjnego i zakazem odsprzedaży kodu. Zdanie „Magic UI ma gotowy szablon dla SaaS-a" dotyczy tej drugiej rzeczy, nie tej pierwszej.

Zaletą jest pełna kontrola. Komponent, który prawie pasuje, poprawiasz na miejscu zamiast szukać obejścia przez właściwości, których autor nie przewidział.

Wadą jest brak aktualizacji. Poprawka błędu w komponencie nie przyjdzie sama, więc jeśli po pół roku pojawi się lepsza wersja, trzeba skopiować ją ponownie i przenieść własne zmiany.

Przy komponentach wizualnych ta wada boli mniej niż przy bibliotekach z logiką. Animowany napis raz napisany działa dalej, a jego poprawianie sprowadza się do zmiany parametrów, nie do śledzenia zmian w interfejsie zewnętrznej biblioteki.

Na czym to stoi

Komponenty opierają się na trzech rzeczach, które prawdopodobnie już masz w projekcie.

Style pochodzą z Tailwind CSS, więc kolory i odstępy podlegają Twojej konfiguracji, a komponent wygląda spójnie z resztą bez dopasowywania.

Animacje korzystają z biblioteki opisanej w tekście o Motion, znanej wcześniej pod nazwą Framer Motion. To znaczy, że zasady wydajności obowiązujące tam obowiązują i tutaj.

Część komponentów rozszerza te z shadcn/ui, więc jeśli używasz już tamtego zestawu, dochodzą do niego bez konfliktów.

Praktyczna konsekwencja: jeśli Twój projekt nie używa Tailwinda, ten zbiór nie ma sensu, bo komponenty wymagałyby przepisania stylów. Jeśli używa, wpięcie jest kwestią jednego polecenia.

Gdzie to działa, a gdzie przeszkadza

Warto rozdzielić dwa rodzaje interfejsu, bo ten sam efekt sprawdza się w jednym i przeszkadza w drugim.

Strona odwiedzana raz, jak strona sprzedażowa, portfolio albo strona wydarzenia, zyskuje na efektach. Odwiedzający widzi je jeden raz, więc animacja jest wrażeniem, a nie kosztem. Tam te komponenty są dokładnie tym, czego trzeba.

Aplikacja używana codziennie traci. Efekt, który przy pierwszym uruchomieniu robi wrażenie, przy pięćdziesiątym jest opóźnieniem między kliknięciem a wynikiem. Panel administracyjny z animowanymi liczbami przy każdym odświeżeniu męczy po tygodniu.

Prosty sprawdzian: policz, ile razy użytkownik zobaczy ten element. Raz albo dwa razy w życiu to argument za efektem. Dwadzieścia razy dziennie to argument przeciw.

Drugi sprawdzian dotyczy informacji. Animacja pokazująca, skąd wzięło się okno albo że element dołączył do listy, niesie informację. Animacja istniejąca dla ozdoby kosztuje czas użytkownika i nic nie daje.

Wydajność

Efekty wizualne mają realną cenę i warto ją znać przed wstawieniem trzech na jedną stronę.

Zasada podstawowa wynika z tego, jak działa przeglądarka. Animowanie przezroczystości i przekształceń jest tanie, bo dzieje się poza przeliczaniem układu. Animowanie szerokości, wysokości i pozycji jest drogie, bo wymusza przeliczenie w każdej klatce.

Druga sprawa to liczba elementów. Efekt działający na jednym elemencie jest niezauważalny, ten sam na siatce stu kafelków potrafi zaciąć nawet mocny sprzęt. Komponenty reagujące na ruch kursora są tu najbardziej kosztowne, bo przeliczają się przy każdym poruszeniu myszą.

Trzecia to urządzenia mobilne. Efekt płynny na komputerze potrafi zacinać na telefonie sprzed trzech lat, a to tam trafia zwykle większość ruchu na stronę sprzedażową. Sprawdzenie na słabszym urządzeniu jest tu obowiązkowe, a nie zalecane.

Czwarta to rozmiar. Każdy komponent ciągnie za sobą silnik animacji, więc strona z jednym efektem powinna ładować go dynamicznie zamiast dołączać do głównej paczki.

Dostępność

Część osób ma w systemie włączoną preferencję ograniczenia ruchu, i to nie jest kwestia gustu, tylko czasem zdrowia.

import { useReducedMotion } from 'motion/react'

const ograniczRuch = useReducedMotion()

<motion.div
  initial={{ opacity: 0, y: ograniczRuch ? 0 : 24 }}
  animate={{ opacity: 1, y: 0 }}
/>

Właściwe podejście nie polega na wyłączeniu wszystkiego, tylko na zastąpieniu ruchu zmianą przezroczystości. Element nadal pojawia się płynnie, ale nie przesuwa się po ekranie i nie miga.

Druga sprawa to treść pojawiająca się stopniowo. Napis wypisywany litera po literze wygląda efektownie i jest problemem dla czytnika ekranu, który odczytuje zmieniającą się treść wielokrotnie.

<>
  <span className="sr-only">{docelowyTekst}</span>
  <span aria-hidden="true">
    <AnimowanyNapis tekst={docelowyTekst} />
  </span>
</>

Docelowy tekst podany osobno i ukryty wizualnie trafia do czytnika raz, w całości. Animowana wersja oznaczona jako ozdobna zostaje pominięta, więc efekt widzi ten, kto patrzy, a treść słyszy ten, kto słucha.

Trzecia to kontrast. Efekty świetlne i gradienty potrafią obniżyć czytelność tekstu poniżej progu, przy którym da się go przeczytać na jasnym ekranie. Sprawdzenie kontrastu na tle animowanym jest trudniejsze niż na jednolitym, więc warto to zrobić, a nie zakładać.

Prostym sposobem jest zatrzymanie animacji w losowej klatce i zmierzenie kontrastu właśnie tam.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}

Ta reguła w arkuszu stylów jest zresztą warta dodania niezależnie od pomiaru, bo obejmuje również animacje z bibliotek, których nie kontrolujesz i które nie sprawdzają preferencji systemowej samodzielnie.

Które efekty faktycznie działają

Zbiór jest duży, a użyteczność poszczególnych efektów mocno się różni. Warto wiedzieć, które wracają w projektach, a które wyglądają dobrze w katalogu i źle na stronie.

Pierwsza grupa to elementy niosące treść. Liczby odliczające w górę przy statystykach, pasek z logotypami klientów, stopniowe pojawianie się sekcji przy przewijaniu. Wspólną cechą jest to, że animacja podkreśla informację, zamiast rywalizować z nią o uwagę.

Przy pasku z logotypami wąskim gardłem nie jest sam efekt, tylko pliki. SVGL zbiera ponad sześćset znaków technologicznych w wektorze, z wariantami na jasne i ciemne tło, i udostępnia je przez API bez klucza, więc odpada szukanie każdego logo osobno. Licencja MIT obejmuje tam jednak kod katalogu, a nie same znaki, więc prawo do pokazania cudzego logo sprawdzasz u jego właściciela niezależnie od tego, skąd pobrałeś plik.

Druga grupa to akcenty na jednym elemencie. Świecące obramowanie przy głównym przycisku albo delikatny efekt przy nagłówku. Sprawdzają się, dopóki jest ich jeden albo dwa na stronę, bo wtedy prowadzą wzrok tam, gdzie chcesz.

Trzecia grupa to tła i efekty pełnoekranowe. Wyglądają najbardziej efektownie w katalogu i najczęściej przeszkadzają w praktyce, bo obniżają czytelność tekstu i najbardziej obciążają słabsze urządzenia. Jeśli po nie sięgasz, sprawdź kontrast i wydajność, zanim uznasz sprawę za zamkniętą.

Czwarta to efekty reagujące na kursor. Robią wrażenie na komputerze i nie istnieją na telefonie, gdzie kursora nie ma.

@media (hover: hover) and (pointer: fine) {
  .karta:hover .poswiata { opacity: 1; }
}

Zapytanie o rodzaj wskaźnika jest tu właściwym narzędziem, a nie sprawdzanie szerokości ekranu. Tablet z rysikiem i laptop z ekranem dotykowym mają szeroki ekran i zachowują się inaczej niż mysz, a próg szerokości tego nie odróżni. Warto zaplanować, jak taki element wygląda bez interakcji, bo dla części odwiedzających to jedyna wersja, którą zobaczą.

Praktyczna zasada brzmi: jeden efekt główny na stronę i kilka drobnych akcentów. Strona z pięcioma równorzędnymi efektami wygląda jak pokaz możliwości, a nie jak produkt.

Magic UI kontra alternatywy

Ostatni wiersz to inna kategoria i warto ją rozdzielić. Biblioteki komponentów dają przyciski, formularze i okna z rozsądną animacją. Ten zbiór daje efekty wizualne, których w bibliotece komponentów nie ma i nie powinno być.

W praktyce często używa się obu naraz: biblioteka komponentów do interfejsu aplikacji, ten zbiór do strony sprzedażowej. Warto natomiast uważać, żeby nie nakładać animacji z dwóch źródeł na te same elementy, bo kończy się to podwójnym przejściem, którego nikt nie zaplanował.

W tabeli brakuje wiersza dla zbiorów z tej samej półki, bo różnice między nimi są innego rodzaju. Aceternity UI stoi na tym samym fundamencie, czyli Tailwindzie i Motion, i kopiuje się je tak samo, a rozchodzi się w dwóch miejscach. Efekty są tam cięższe, oparte o duże rozmycia i przeliczanie pozycji kursora, więc łatwiej nimi zdławić przewijanie na telefonie. Do tego dochodzi warstwa płatna z gotowymi szablonami całych stron, której tutaj nie ma. Mieszanie obu zbiorów w jednym projekcie jest technicznie możliwe, ale kończy się dwiema estetykami na jednej stronie.

Drugi wiersz warto rozważyć poważniej, niż podpowiada wygoda. Efekt napisany samodzielnie zajmuje wieczór i daje dokładnie to, czego chcesz, w tempie zgodnym z resztą projektu. Gotowy komponent oszczędza ten wieczór i przynosi wygląd, który widać na wielu innych stronach, bo korzysta z niego wiele zespołów. Przy produkcie, w którym wygląd jest wyróżnikiem, ta różnica bywa istotna.

Wpływ na wyniki strony

Strona sprzedażowa jest oceniana przez wyszukiwarki i przez użytkowników według tego, jak szybko się pokazuje i jak stabilnie zachowuje. Efekty wizualne dotykają obu tych rzeczy.

Pierwsza to czas do pierwszego sensownego widoku. Strona ładująca silnik animacji przed pokazaniem treści każe czekać na coś, co nie jest treścią. Rozwiązaniem jest ładowanie dynamiczne efektów spoza pierwszego ekranu i pozostawienie w głównej paczce tylko tego, co widać od razu.

Druga to stabilność układu. Element pojawiający się z animacją i przesuwający resztę strony powoduje, że użytkownik klika w coś innego, niż zamierzał. Rezerwacja miejsca z góry, przez ustaloną wysokość kontenera, usuwa ten problem.

Trzecia to zachowanie przy wolnym łączu. Efekt zależny od skryptu, który jeszcze się nie wczytał, zostawia pusty obszar zamiast treści. Warto sprawdzić, jak strona wygląda, zanim skrypty zadziałają, bo część odwiedzających zobaczy właśnie ten stan.

Praktyczna kolejność prac wygląda tak: najpierw strona działająca bez animacji, potem efekty dokładane warstwowo. Odwrotna kolejność daje stronę, która wygląda dobrze na szybkim łączu i źle wszędzie indziej.

Utrzymanie w projekcie

Skopiowany komponent staje się częścią kodu, więc podlega tym samym zasadom co reszta, i warto to od razu uporządkować.

Pierwsza rzecz to miejsce. Warto trzymać te komponenty w osobnym katalogu, oddzielonym od własnych, żeby było wiadomo, co pochodzi z zewnątrz i czego nie należy dopracowywać bez potrzeby.

Druga to parametry. Komponent skopiowany z domyślnymi wartościami czasu i opóźnień warto od razu dostosować do reszty projektu, bo inaczej każdy efekt ma inne tempo i strona wydaje się niespójna.

Trzecia to usuwanie. Efekt, który nie przeszedł prób i nie jest używany, powinien zniknąć z repozytorium, a nie zostać na wypadek gdyby. Nieużywany kod komplikuje wyszukiwanie i przy okazji trafia do paczki, jeśli ktoś przypadkiem go zaimportuje.

Czwarta to zapis decyzji. Krótka notatka o tym, które efekty przyjęliście i dlaczego, oszczędza dyskusji przy kolejnej stronie i chroni przed dokładaniem trzeciego efektu na tę samą sekcję.

Typowe błędy

Pierwszy to używanie efektów w aplikacji używanej codziennie. To, co przy pierwszym uruchomieniu robi wrażenie, po tygodniu jest opóźnieniem.

Drugi to trzy efekty na jednej stronie. Uwaga jest zasobem ograniczonym, więc trzy rzeczy walczące o nią naraz sprawiają, że użytkownik nie patrzy na żadną.

Trzeci to brak obsługi preferencji ograniczenia ruchu. To ustawienie systemowe wybierane świadomie i warto je uszanować.

Czwarty to sprawdzanie wyłącznie na komputerze. Większość ruchu na stronie sprzedażowej przychodzi z telefonów, a tam efekty zachowują się inaczej.

Piąty to animowanie wymiarów zamiast przekształceń. Wynik wygląda tak samo, a koszt jest wielokrotnie wyższy.

Szósty to napis wypisywany litera po literze bez wersji dla czytników ekranu. Wygląda dobrze i jest niedostępny dla części użytkowników.

FAQ

Czy Magic UI to biblioteka?

Nie w klasycznym sensie. Kopiujesz kod komponentu do swojego projektu i od tej chwili jest Twój, bez zależności w konfiguracji pakietów. To ten sam model co w shadcn/ui, z tą samą zaletą kontroli i tą samą wadą braku aktualizacji.

Czy wymaga Tailwinda?

Tak, komponenty korzystają z klas tego frameworka i z Twojej konfiguracji kolorów. W projekcie bez niego wymagałyby przepisania stylów, co przekreśla główną zaletę, czyli szybkość wpięcia.

Czy nadaje się do aplikacji, a nie tylko do strony?

Rzadko. Efekty wizualne sprawdzają się tam, gdzie użytkownik widzi je raz, a nie dwadzieścia razy dziennie. Do interfejsu aplikacji lepsze są biblioteki komponentów użytkowych z animacją dopasowaną do częstego użycia.

Jak to wpływa na wydajność?

Zależy od efektu i liczby elementów. Animacja przezroczystości i przekształceń jest tania, animacja wymiarów droga. Komponenty reagujące na ruch kursora przeliczają się bardzo często, więc na słabszym urządzeniu potrafią zacinać.

Czy da się to pogodzić z dostępnością?

Tak, pod dwoma warunkami. Trzeba obsłużyć preferencję ograniczenia ruchu, zastępując przesunięcia zmianą przezroczystości, oraz zadbać o to, żeby treść pojawiająca się stopniowo miała wersję dostępną dla czytników ekranu.

Komponenty i przykłady stoją na stronie projektu, a kod źródłowy w repozytorium na GitHubie.