🎨 uxowy.dev #55: Nowa strona Next.js & rage taps
Dziś będzie króciutko. Bo majówka wzywa 😎 Także przechodząc od razu do konkretów, dzisiaj będzie o:
- Nowej stronie Next.js - co jest pod jej maską?
- Co zrobić, żeby user nie robił tzw. rage taps?
3️⃣ 2️⃣ 1️⃣ 0️⃣
Zaczynamy 👇 👇 👇
Co jest pod maską nowej strony Next.js?
![](https://uxowy.dev/content/images/2023/04/Next.js-by-Vercel---The-React-Framework-for-the-Web-2023-04-28-10-28-09.png)
Next.js ostatnio zaktualizowało swoją stronę główną.
A poniżej mamy artykuł od osoby, która zajmowała się wdrożeniem tej strony - rauno.
Dowiemy się z niego, jak zrobiono m.in.:
![](https://uxowy.dev/content/images/2023/04/Crafting-the-Next.js-Website-2023-04-28-10-30-54.png)
![](https://uxowy.dev/content/images/2023/04/Crafting-the-Next.js-Website-2023-04-28-10-31-08.png)
![](https://uxowy.dev/content/images/2023/04/Crafting-the-Next.js-Website-2023-04-28-10-34-05.png)
![](https://uxowy.dev/content/images/2023/04/image-11.png)
![](https://uxowy.dev/content/images/2023/04/Crafting-the-Next.js-Website-2023-04-28-10-35-22.png)
...i jeszcze parę innych, ciekawych rozwiązań.
Sprawdź tutaj:
https://rauno.me/craft/nextjs
![](https://rauno.me/static/craft/og-nextjs.png)
Ogólnie polecam też obczajenie innych prac rauno na jego stronie:
https://rauno.me/
☝️ bardzo inspirujące!
Co zrobić, żeby user nie robił tzw. rage taps?
![](https://uxowy.dev/content/images/2023/04/image-12.png)
O rage taps możemy mówić podczas przypadkowego kliknięcia w inny element albo wielokrotnego klikania bez widocznego efektu. Może prowadzić do frustracji i błędów użytkowników.
Rage taps najczęściej spowodowane są:
- elementami interfejsu, które są zbyt małe i trudno je kliknąć/tapnąć lub znajdują się zbyt blisko siebie.
- jeśli nie dodaliśmy np. stanu loading na buttonie i user klika go kilka razy, bo nie wie, że coś tam dzieje się w tle
- mamy stan aplikacji, w którym nie możemy nic zrobić - nie możemy przerwać procesu, nie ma akcji wstecz albo np. aplikacja się zmuliła i nie reaguje na polecenia użytkownika
- kliknięciem w element, który wypier*** naszą aplikację 🐛 i wszystko przestało działać (to bardziej dla śmiechu 😂)
Jak możemy temu zapobiec?
- odpowiednia wielkość elementu klikalnego - jest kluczowe dla zapewnienia dostępności i użyteczności aplikacji:
![](https://uxowy.dev/content/images/2023/04/image-13.png)
- postarajmy się, aby było łatwo dosięgnąć element klikalny, możemy użyć np. bottom sheeta:
![](https://uxowy.dev/content/images/2023/04/image-14.png)
- jeśli dajemy bottom menu to przycisk powinien mieć min. 44-46px wielkości
- unikaj pokazywania możliwych akcji na hover, np w tabelach:
![](https://uxowy.dev/content/images/2023/04/image-15.png)
- jeśli klikalne elementy muszą z jakiegoś powodu być małe, rozważ dodatkowy krok, aby użytkownik pewnie mógł kliknąć w pożądany element (czasami dodatkowe kliknięcie nie jest takie złe):
![](https://uxowy.dev/content/images/2023/04/Accessible-Target-Sizes-Cheatsheet---Smashing-Magazine-2023-04-28-11-09-58.png)
- maksymalizuj klikalny element:
![](https://uxowy.dev/content/images/2023/04/image-16.png)
![](https://uxowy.dev/content/images/2023/04/image-17.png)
![](https://uxowy.dev/content/images/2023/04/image-22.png)
![](https://uxowy.dev/content/images/2023/04/image-21.png)
Więcej tutaj:
- Smashing Magazine: Accessible Target Sizes Cheatsheet
- Enhancing The Clickable Area Size
- WCAG Target Size (AAA)
Jeśli Ci się podobało...
To wszystko na dziś!
Udanej majóweczki!!!
🎉 ☀️ 🏖️
Mikołaj Waśkowski
uxowy.dev
Poprzednie wydania:
Jeśli jeszcze nie ma Cię na liście 🤔
Wysyłamy jeden email tygodniowo, w każdy piątek, o godz. 12:00.
Wartościowa wiedza o UI/UX dla developera może wylądować do Twojej skrzynki.