Rozwój narzędzi dla programistów i inne zagadnienia

Doświadczenia programistów (DX) i doświadczenia użytkowników (UX) nie zawsze idą w parze. Często narzędzie zapewniające dobre DX może pogarszać UX użytkownika końcowego — i odwrotnie.

Niedawne badanie wykazało, że przeciętnie strony internetowe oparte na React działają gorzej niż renderowane po stronie serwera strony wykorzystujące jQuery. Czy to oznacza, że React jest złym narzędziem? Wcale nie. Korzystanie z frameworków wiąże się jednak z kosztami, które ostatecznie ponosi użytkownik.

Użytkownika nie obchodzą JSX, Web Components, CSS-in-JS ani inne bezsensowne dyskusje w społeczności programistów. Semantyczny HTML ma jednak dla niego pośrednie znaczenie, jeśli korzysta z czytnika ekranu. Liczy się dla niego także całkowity rozmiar strony, gdy łączy się przez 2G lub wolne 3G albo nie ma przystępnego cenowo pakietu danych.

W informatyce dobre rozwiązanie abstrakcyjne skutecznie rozwiązuje problemy, ukrywając szczegóły działania. Gdy korzystamy z narzędzia do rozwiązywania złożonego problemu, zakładamy, że stanowi ono dobrą abstrakcję. Narzędzia i frameworki powinny więc pełnić funkcję zabezpieczenia, które pomaga radzić sobie z typowymi problemami, takimi jak wydajność i dostępność. Wiele z nich zaspokaja jednak wyłącznie nasze własne potrzeby (DX), w dużej mierze ignorując potrzeby użytkowników (UX).

Dlatego dziś programiści muszą znać się na wydajności stron internetowych, optymalizacji obrazów, dostępności i bezpieczeństwie, jeśli chcą zapewnić użytkownikom przyzwoite wrażenia. To kolejne umiejętności na i tak coraz dłuższej liście, którą muszą opanować, zanim opublikują swój pierwszy „prawdziwy projekt”. W rezultacie zmagają się z frameworkami, które miały im służyć.

Na szczęście niektórzy twórcy frameworków już podejmują działania w tym kierunku. Szukają sposobów, by podział kodu na mniejsze części był dostępny od razu. Integrują też lintery, które pomagają zadbać o tak istotne kwestie jak dostępność i bezpieczeństwo. Przed nami jednak długa droga, a taki kierunek powinien stać się standardem w branży.

Zadaliśmy więc sobie pytanie:

• Kim są nasi użytkownicy?
• Czy są nimi programiści, projektanci i twórcy treści, którzy korzystają z narzędzia na co dzień?
• A może są nimi odbiorcy treści generowanych przez tę platformę?

Zrozumieliśmy, że zapewniamy naszym klientom bezpośrednie doświadczenie, a ich użytkownikom — odbiorcom treści — doświadczenie pośrednie. Głęboko wierzymy, że poprawianie doświadczeń odbiorców to sposób na lepszą obsługę naszych klientów. Nie przerzucimy na nich całej odpowiedzialności za tworzenie dostępnych, bezpiecznych i szybkich aplikacji internetowych.

Oto kilka działań, które pomogą wbudować tę siatkę bezpieczeństwa w nasz produkt:

1. Wbuduj najlepsze praktyki
2. Zapobiegaj szkodliwym działaniom
3. Zwiększaj świadomość i edukuj

Wbuduj najlepsze praktyki#

Z perspektywy UX w niektórych sytuacjach warto podejmować konkretne decyzje. Z czasem społeczność wypracowała najlepsze praktyki tworzenia aplikacji internetowych. Nie powinniśmy martwić się o nie przy każdym nowym projekcie.

Weźmy na przykład optymalizację obrazów. Obrazy stanowią 75% wagi stron internetowych

według httparchive.org. Jednak nie każdy ma umiejętności ani narzędzia, by tworzyć optymalnie przygotowane obrazy dla swoich użytkowników. Optymalizacja obrazów może szybko stać się skomplikowana ze względu na różne formaty, gęstości pikseli i rozmiary dostosowane do ekranów.

Niedawno dodaliśmy usługę, która zmienia rozmiar przesyłanych obrazów w zależności od kontenerów, w których są używane. Nie musisz się tym zajmować — zakładamy, że w gotowym produkcie chcesz używać najbardziej zoptymalizowanej wersji obrazu. W nadchodzących miesiącach będziemy pracować nad rozwiązaniem do generowania responsywnych obrazów oraz dostarczaniem formatów webp w przeglądarkach, które je obsługują.

Obraz jest dopasowywany do rozmiaru kontenera, w którym jest używany

Na tym poziomie platforma działa w Twoim imieniu i wykonuje „magiczną” pracę w tle, bez konieczności Twojego udziału.

Zapobiegaj szkodliwym działaniom#

Nie powinieneś musieć przeprowadzać audytów produkcyjnych, aby dowiedzieć się, że obraz nie ma tekstu alternatywnego albo że przypadkowo zagnieżdżono znaczniki kotwicy. Wszystkie te problemy można wykryć na etapie kompilacji.

Dzięki dostępowi do informacji o semantyce w czasie rzeczywistym możemy zapobiec nieprawidłowym stanom. Na przykład podczas projektowania strony możemy uniemożliwić zagnieżdżanie znaczników kotwicy lub stosowanie nieprawidłowej hierarchii nagłówków.

Uwaga: ta funkcja nie została jeszcze wdrożona i znajduje się na etapie projektowania.

W tym scenariuszu wiedza zgromadzona na platformie blokuje działania, które mogą negatywnie wpłynąć na komfort użytkownika.

Zwiększaj świadomość i edukuj#

Na koniec warto wspomnieć o zaleceniach dotyczących użyteczności, o których możesz potrzebować się dowiedzieć. Decyzja o ich wdrożeniu należy do Ciebie, ale powinna być świadoma.

Kontrast kolorów to dobry przykład. To Ty decydujesz, czy kontrast spełnia zalecenia poziomu AA czy AAA WCAG, w zależności od grupy docelowej. Możemy wskazać problematyczne obszary, przedstawić wskazówki i skierować Cię do materiałów edukacyjnych na ten temat.

Rozmiar czcionki to kolejny przykład. Możesz zdecydować, czy zachować zalecaną minimalną wartość 16 px, w zależności od przeznaczenia tworzonej aplikacji. Platforma wskaże jednak konsekwencje Twoich działań, aby umożliwić Ci podjęcie świadomej decyzji.

Narzędzie wyświetlające komunikat informacyjny o standardowym rozmiarze czcionki.

Dopiero stawiamy pierwsze kroki w tym kierunku, ale jesteśmy przekonani, że to właściwa droga dla naszego produktu. Uważamy, że Playground powinien być narzędziem deweloperskim wspierającym rozwój, co ma bezpośrednie znaczenie dla Ciebie jako klienta i pośrednio przynosi korzyści Twoim użytkownikom. Bo ostatecznie Twoi użytkownicy są również naszymi użytkownikami.