Relume, mapa strony i szkielety z biblioteki

Relume, mapa strony i szkielety z biblioteki

Relume robi jedną rzecz i robi ją w miejscu, w którym projekty stron grzęzną najczęściej: zamienia opis firmy w mapę strony, a mapę w szkielety poszczególnych podstron, złożone z gotowych sekcji.

Warto od razu rozstrzygnąć, czym to nie jest. Nie jest narzędziem do projektowania wyglądu, bo szkielety są celowo surowe. Nie jest też generatorem kodu w potocznym rozumieniu, choć eksport istnieje. Jest narzędziem do fazy poprzedzającej projekt, czyli do ustalenia, ile stron ma powstać i co się na nich znajdzie.

Gdzie leży realna wartość

Warto to nazwać konkretnie, bo marketing sugeruje coś szerszego, niż narzędzie faktycznie robi.

Największym pochłaniaczem czasu przy stronie firmowej nie jest projektowanie ani kodowanie. Jest nim ustalenie, jakie strony w ogóle mają powstać i w jakiej kolejności czytelnik ma zobaczyć argumenty. Ta rozmowa potrafi ciągnąć się tygodniami, bo toczy się w abstrakcji: bez czegoś na ekranie każdy uczestnik ma w głowie inną stronę.

Narzędzie skraca tę fazę, bo daje coś konkretnego do skrytykowania w kilka minut. Mapa strony z dwudziestoma podstronami, wygenerowana z opisu działalności, jest niedoskonała i właśnie dlatego działa: dyskusja przestaje dotyczyć wyobrażeń, a zaczyna konkretnej listy.

To samo dotyczy szkieletów. Układ strony złożony z sekcji, które istnieją naprawdę, pokazuje proporcje i kolejność, a przy okazji unieważnia pomysły niemożliwe do zrealizowania w rozsądnym czasie.

Poza tą fazą wartość maleje. Do dopracowania wyglądu potrzebujesz narzędzia projektowego, a do zbudowania działającej strony czegoś zupełnie innego.

Biblioteka sekcji

Sedno narzędzia leży w bibliotece liczącej ponad tysiąc gotowych sekcji: nagłówków, siatek z cechami, cenników, opinii klientów, stopek. Sekcje istnieją w trzech postaciach: dla narzędzia projektowego, dla platformy budującej strony i dla Reacta.

To jest zarazem największa zaleta i największe ograniczenie tego podejścia.

Zaleta polega na spójności. Wszystkie sekcje pochodzą z jednego systemu, więc złożona z nich strona wygląda jak całość, a nie jak zbiór kawałków. Zmienne kolorów i skala odstępów są odwzorowane między postaciami, więc szkielet przeniesiony do narzędzia projektowego zachowuje proporcje.

Ograniczenie polega na tym, że dostajesz stronę zbudowaną z rozpoznawalnych elementów. Ktoś, kto widział kilka stron zrobionych tym narzędziem, rozpozna kolejną. Przy stronie firmowej, gdzie liczy się czytelność, to nie jest problem. Przy produkcie, który ma się odróżniać, jest.

Praktyczna droga wygląda tak: traktuj wynik jako szkielet do przerobienia, a nie jako projekt do wdrożenia. Zmiana typografii, kolorystyki i kilku układów wystarcza, żeby efekt przestał wyglądać jak katalog.

Eksport i co z niego wynika

Eksport istnieje do trzech miejsc i różni się jakością na tyle, że warto wiedzieć, po co sięgasz. Różni się też dostępnością zależnie od planu, co przy decyzji zakupowej bywa ważniejsze od samej jakości: próg darmowy daje wyłącznie eksport do narzędzia projektowego, a najniższy plan płatny odblokowuje od razu wszystkie trzy kierunki, z Reactem włącznie. Plany wyższe nie dokładają już kolejnych formatów, tylko znoszą limity projektów i podstron, więc eksport do kodu nie jest powodem, żeby wchodzić wyżej niż na pierwszy płatny próg.

Eksport do narzędzia projektowego jest tym, do czego to narzędzie zostało zaprojektowane. Dostajesz warstwy, komponenty i zmienne, więc dalsza praca odbywa się normalnie.

Eksport do platformy budującej strony daje działający kod z zachowaniem zachowań responsywnych. To jest droga, która ma sens, jeśli w tej platformie pracujesz, i żadnego znaczenia, jeśli nie.

Eksport do Reacta jest tym, o który pytają zespoły techniczne, i tu potrzebne jest doprecyzowanie. Komponenty korzystają z Tailwinda, więc wpasowują się w typowy stos, natomiast to nie jest system komponentów, który wpinasz jako zależność. To jest kod do skopiowania i przerobienia, podobnie jak przy shadcn/ui, z tą różnicą, że tam kod jest projektowany pod kopiowanie, a tu pod przeniesienie z projektu graficznego.

Praktyczna konsekwencja: zespół pracujący w Next.js dostaje z tego przede wszystkim strukturę i układ, a nie gotową warstwę komponentów. Wartość jest realna i węższa, niż sugeruje opis.

Sensowny sposób pracy z takim kodem polega na przerobieniu go raz, przy pierwszym użyciu, na komponent z właściwościami zamiast wklejania tej samej sekcji na czterech podstronach.

type SekcjaProps = {
  naglowek: string
  opis: string
  cta: { tekst: string; adres: string }
}

export function SekcjaOtwierajaca({ naglowek, opis, cta }: SekcjaProps) {
  return (
    <section className="flex flex-col gap-4 px-6 py-16 md:px-12">
      <h1 className="text-4xl font-semibold">{naglowek}</h1>
      <p className="max-w-prose">{opis}</p>
      <a href={cta.adres} className="w-fit rounded-md px-4 py-2">
        {cta.tekst}
      </a>
    </section>
  )
}

Ta jedna operacja decyduje o tym, czy po pół roku zmiana odstępu w sekcji otwierającej jest jedną poprawką, czy czterema. Eksport daje układ, a granice komponentów wyznaczasz sam, bo narzędzie nie wie, co w Twoim serwisie się powtarza.

Mapa strony jako dokument projektowy

Warto poświęcić chwilę temu, co powstaje jako pierwsze, bo bywa traktowane jako produkt uboczny, a jest najtrwalszym efektem pracy z tym narzędziem.

Mapa strony to nie jest lista adresów. To jest decyzja o tym, ile jest wątków, jak się dzielą i którędy przechodzi czytelnik. Dobra mapa odpowiada na pytanie, dlaczego dana podstrona istnieje, a nie tylko, że istnieje.

Narzędzie generuje ją szybko i zwykle z nadmiarem. To jest właściwe zachowanie, bo usuwanie jest łatwiejsze niż wymyślanie, a nadmiarowa lista pokazuje możliwości, o których nikt nie pomyślał. Praca zaczyna się przy skracaniu.

Trzy pytania warto zadać przy przeglądaniu wyniku. Czy ta podstrona ma własny powód istnienia, czy jest sekcją innej wyciągniętą osobno. Czy ktokolwiek będzie jej szukał, czy trafi tam tylko z menu. Oraz czy jej treść ma kto napisać, bo strona bez treści jest gorsza niż jej brak.

Ostatnie pytanie eliminuje najwięcej pozycji i jest zadawane najrzadziej. Mapa z dwudziestoma podstronami wygląda solidnie do momentu, w którym ktoś ma napisać dwadzieścia tekstów, a wtedy okazuje się, że powstanie sześć, a reszta zostanie pusta.

Warto ten dokument utrzymywać poza narzędziem, bo przeżyje projekt. Przy każdej późniejszej zmianie strony pytanie „co my tu właściwie mamy" ma wtedy gotową odpowiedź.

Wystarczy zwykły plik w repozytorium, w którym obok adresu stoi powód istnienia podstrony i osoba odpowiedzialna za treść.

strony:
  - adres: /
    cel: Wyjasnic w piec sekund, co robimy i dla kogo
    tresc: Anna
  - adres: /cennik
    cel: Odpowiedziec na pytanie o koszt bez kontaktu z handlowcem
    tresc: Anna
  - adres: /wdrozenia
    cel: Dowod, ze robilismy to juz w tej branzy
    tresc: Marek
  - adres: /o-nas
    cel: Wiarygodnosc przy wiekszych zamowieniach
    tresc: brak

Ostatni wiersz jest tu najważniejszy i pojawia się w każdej takiej liście. Podstrona bez przypisanej osoby zwykle nie powstanie, więc lepiej usunąć ją teraz niż zostawić pustą przez rok.

Ten sam plik ma potem drugie zastosowanie, o którym się zapomina. Lista, która przeszła przez skracanie, jest gotowym źródłem mapy witryny dla wyszukiwarek, więc nie trzeba jej wpisywać po raz drugi.

import type { MetadataRoute } from 'next'

export default function sitemap(): MetadataRoute.Sitemap {
  return [
    { url: 'https://firma.pl', changeFrequency: 'monthly', priority: 1 },
    { url: 'https://firma.pl/cennik', changeFrequency: 'monthly', priority: 0.8 },
    { url: 'https://firma.pl/wdrozenia', changeFrequency: 'yearly', priority: 0.6 },
  ]
}

Wartości pierwszeństwa i częstotliwości traktuj jako podpowiedź, a nie polecenie, bo wyszukiwarki nie muszą się do nich stosować. Realną wartością jest tu samo wyliczenie adresów, zwłaszcza tych, do których nie prowadzi żaden odnośnik z menu.

Szkielety a projekt graficzny

Rozdzielenie tych dwóch rzeczy jest sednem procesu, w którym to narzędzie ma sens, i warto je opisać, bo bywa mylone.

Szkielet odpowiada na pytanie, co jest na stronie i w jakiej kolejności. Projekt graficzny odpowiada na pytanie, jak to wygląda. Mieszanie tych pytań sprawia, że rozmowa o strukturze zamienia się w dyskusję o kolorze przycisku, zanim ktokolwiek ustalił, czy ten przycisk jest potrzebny.

Surowość szkieletów jest tu zaletą projektową, a nie brakiem. Układ pozbawiony kolorów i zdjęć zmusza do patrzenia na proporcje i hierarchię, czyli na rzeczy, które decydują o skuteczności strony bardziej niż estetyka.

Praktyczna konsekwencja dotyczy prezentacji klientowi. Pokazanie szkieletu wymaga uprzedzenia, czym on jest, inaczej pierwsza reakcja dotyczy tego, że jest szary. Zdanie wyjaśniające, że rozmawiamy o zawartości, a wygląd powstanie później, oszczędza całą tę rundę.

Ostatnia rzecz: szkielet warto zamrozić przed przejściem do projektu. Zmiany struktury wprowadzane w trakcie pracy nad wyglądem kosztują wielokrotnie więcej, bo każda pociąga za sobą przerobienie tego, co już wygląda skończenie.

Relume kontra alternatywy

Te narzędzia rzadko konkurują, bo obsługują różne momenty. Sensowny układ przy stronie firmowej wygląda tak: struktura i szkielety tutaj, wygląd w narzędziu projektowym albo od razu w narzędziu publikującym, kod w tym, czego używa zespół.

Ostatni wiersz warto rozważyć uczciwie. Jeśli strona ma być wyróżnikiem, a nie tylko informacją, gotowe sekcje pracują przeciwko Tobie. Szybciej to nie znaczy lepiej, gdy celem jest odróżnienie się.

Warto też zauważyć, że sama mapa strony nie wymaga żadnego narzędzia. Lista podstron w dokumencie robi to samo, tylko gorzej się ogląda. Wartość pojawia się dopiero przy szkieletach, gdzie widać proporcje i kolejność.

Cennik i próg wejścia

Narzędzie działa w modelu abonamentowym i rozlicza się od osoby, nie od zespołu. Stawki są dwie na każdym planie, bo rozliczenie roczne jest o trzydzieści procent tańsze od miesięcznego, i to właśnie ta różnica bywa mylona w zestawieniach z drugiej ręki.

Próg darmowy jest zawężony do jednego projektu, jednej podstrony i trzydziestu komponentów w wersji dla Reacta oraz dla platformy budującej strony, więc służy obejrzeniu narzędzia, a nie pracy. Biblioteka dla narzędzia projektowego jest tu wyjątkiem, bo pozostaje pełna także na planie darmowym.

Ważniejsze od stawki jest to, jak liczyć zwrot. Narzędzie oszczędza czas w jednej fazie projektu, więc opłaca się przy kilku projektach rocznie, a nie przy jednym. Agencja robiąca dziesięć stron w roku odzyskuje abonament na pierwszym projekcie. Firma budująca własną stronę raz na trzy lata prawdopodobnie nie.

Druga rzecz to zależność od roli. Osoba projektująca zyskuje najwięcej, bo dostaje punkt wyjścia i bibliotekę. Programista zyskuje mniej, bo eksport do kodu jest wtórny wobec głównego przeznaczenia.

Rozliczenie od osoby jest tu pozycją, która przy kilku uczestnikach zmienia rachunek bardziej niż sama stawka. Plan zespołowy zaczyna się od trzech miejsc, więc dwuosobowa pracownia albo płaci za miejsce, którego nie użyje, albo zostaje przy osobnych kontach.

Jak to wpiąć w proces

Kilka rzeczy sprawia, że narzędzie daje więcej niż samo wygenerowanie mapy.

Zacznij od opisu, który zawiera konkrety. Opis mówiący, czym firma się zajmuje, do kogo mówi i co ma się wydarzyć po wejściu na stronę, daje wynik znacznie lepszy niż nazwa branży. To ta sama zasada, co przy pracy z modelami: konkret w wejściu zamienia się w konkret w wyjściu.

Przejrzyj mapę przed generowaniem szkieletów. Poprawienie listy podstron zajmuje minuty, a generowanie układów dla stron, które i tak wypadną, jest stratą czasu.

Traktuj wynik jako materiał do rozmowy, nie jako propozycję do zaakceptowania. Największa wartość powstaje wtedy, gdy klient albo zespół patrzy na coś konkretnego i mówi, czego brakuje.

Przenieś do narzędzia projektowego wcześnie. Szkielety mają pokazywać strukturę, więc dopracowywanie ich w tym narzędziu jest pracą w niewłaściwym miejscu.

Ostatnia rzecz: zapisz mapę strony poza narzędziem. Lista podstron z opisem przeznaczenia każdej jest dokumentem przydatnym przez cały projekt, także dla osób, które w tym narzędziu nie pracują.

Przełożenie tej listy na strukturę katalogów zajmuje minutę i od razu pokazuje, czy mapa się trzyma kupy.

app/
├── page.tsx              # /
├── cennik/page.tsx       # /cennik
├── wdrozenia/
│   ├── page.tsx          # lista wdrozen
│   └── [slug]/page.tsx   # pojedyncze wdrozenie
└── o-nas/page.tsx        # /o-nas

Jeśli przy przepisywaniu okazuje się, że dwie podstrony trafiają do tego samego katalogu albo że któraś nie ma sensownego miejsca w drzewie, to sygnał do poprawienia mapy, a nie do naginania struktury. Ten test jest niepozorny, a wychwytuje podziały wymyślone przy generowaniu i nieprzemyślane później.

Typowe błędy

Pierwszy to oczekiwanie gotowego projektu. Szkielety są celowo surowe, a ich dopracowanie jest osobną pracą w innym narzędziu.

Drugi to traktowanie eksportu do Reacta jako biblioteki komponentów. To jest kod do skopiowania i przerobienia, a nie zależność, którą się instaluje i aktualizuje.

Trzeci to opis wejściowy ograniczony do nazwy branży. Wynik jest wtedy ogólny, bo narzędzie nie ma z czego wyciągnąć specyfiki.

Czwarty to generowanie szkieletów przed poprawieniem mapy. Układy dla stron, które wypadną z zakresu, powstają na darmo.

Piąty to wypuszczenie strony bez zmiany typografii i kolorystyki. Efekt jest rozpoznawalny i przy produkcie mającym się wyróżniać działa przeciwko celowi.

Szósty to zakup abonamentu przy jednym projekcie na kilka lat. Narzędzie zwraca się przy powtarzalności, a nie przy pojedynczym użyciu.

Siódmy to pokazanie klientowi szkieletu bez uprzedzenia, czym on jest. Pierwsza reakcja dotyczy wtedy tego, że wszystko jest szare, a nie tego, czy struktura ma sens, i cała runda idzie na wyjaśnianie zamiast na rozmowę o zawartości.

Ósmy to zostawianie w mapie podstron, których nikt nie napisze. Strona bez treści szkodzi bardziej niż jej brak, a lista dwudziestu pozycji wygląda solidnie dokładnie do momentu podziału pracy nad tekstami.

FAQ

Czy Relume generuje gotową stronę?

Nie. Generuje mapę strony i szkielety złożone z gotowych sekcji, czyli materiał do fazy poprzedzającej projekt. Dopracowanie wyglądu odbywa się w narzędziu projektowym, a budowa działającej strony gdzie indziej.

Czy da się z tego wyeksportować kod do Reacta?

Tak, komponenty korzystają z Tailwinda i wpasowują się w typowy stos. To jest jednak kod do skopiowania i przerobienia, a nie biblioteka instalowana jako zależność, więc dla zespołu technicznego głównym zyskiem pozostaje struktura, nie kod.

Ile to kosztuje?

Plan Starter kosztuje 26 USD miesięcznie albo 18 USD przy rozliczeniu rocznym, plan Pro odpowiednio 58 i 40 USD, a plan zespołowy 52 i 36 USD za osobę przy minimum trzech osobach. Próg darmowy istnieje, ale przy jednym projekcie i jednej podstronie służy obejrzeniu narzędzia. Zwrot pojawia się przy kilku projektach rocznie, a nie przy jednym.

Czy strony zrobione tym narzędziem wyglądają podobnie?

Tak, jeśli zostawi się ustawienia domyślne, bo sekcje pochodzą z jednej biblioteki. Zmiana typografii, kolorystyki i kilku układów wystarcza, żeby efekt przestał być rozpoznawalny, i przy produkcie mającym się wyróżniać jest to konieczne.

Kiedy lepiej pracować bez tego narzędzia?

Gdy wygląd ma być wyróżnikiem produktu, gdy robisz jedną stronę raz na kilka lat oraz gdy struktura jest oczywista i nie wymaga uzgadniania. W tych przypadkach gotowe sekcje nie oszczędzają czasu, tylko ograniczają.

Opis możliwości stoi na stronie produktu, a warunki planów w cenniku.