CodeGym /Corsi /ChatGPT Apps /Design visivo: temi, colori, tipografia, spaziature e lib...

Design visivo: temi, colori, tipografia, spaziature e librerie pronte all'uso

ChatGPT Apps

Livello 8 , Lezione 3

Disponibile

1. Contesto: la tua App — un ospite in casa ChatGPT

Prima di disegnare pulsanti e scegliere i font, è importante accettare la realtà: l’utente non apre «il tuo sito», è dentro ChatGPT. ChatGPT ha già i suoi:

schemi di colori,
font e dimensioni,
spaziature e layout dei componenti.

Il tuo widget viene mostrato all’interno di questo contesto, per lo più in un iframe. Da qui una conclusione importante: visivamente la App deve sembrare il naturale prolungamento dell’interfaccia di ChatGPT, non un banner arrivato dal 2008.

Le linee guida ufficiali di OpenAI dicono proprio questo: non rompere i colori e i font di sistema, aggiungere solo accenti di brand moderati e seguire la tipografia e la griglia di base della piattaforma.

In pratica questo significa tre cose.

Primo, lo sfondo, il colore base del testo, la tipografia standard — tutto dovrebbe essere ereditato da ChatGPT o da variabili di sistema, non «faccio come mi pare perché sono un artista».

Secondo, se vuoi «il tuo stile», deve concentrarsi sugli accenti: pulsanti principali, badge, stati evidenziati. Ma non uno sfondo arcobaleno e non il font personalizzato Comic Sans — anche se nel profondo lo desideri tanto.

Terzo, le modalità inline e fullscreen della stessa App devono sembrare parte dello stesso mondo: stessi colori per le CTA, stessi raggi e spaziature delle card, stessa tipografia. L’utente non deve percepire di essere passato a un altro prodotto nel passaggio da inline a fullscreen.

Poi andremo per livelli: colori e temi, tipografia, spaziature e griglia, quindi come Tailwind e shadcn/ui aiutano a mettere insieme il tutto.

Insight

La sandbox di ChatGPT non solo limita la funzionalità del tuo widget, ma gli aggiunge anche i propri stili.

Primo — questo è l’header HTML

Originale dal sito:

<html lang="ru">

Nella sandbox:

<html lang="en-US" data-theme="light" class="light" style="--safe-area-inset-top: 0px; --safe-area-inset-bottom: 0px; --safe-area-inset-left: 0px; --safe-area-inset-right: 0px;">

Secondo — questi sono gli stili CSS nativi, per far sembrare il tuo widget più simile a ChatGPT:

<style>
  html,body,#root{-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale;margin:0;padding:0}
  html,body{font-family:-apple-system,BlinkMacSystemFont,Segoe UI,Roboto,Oxygen,Ubuntu,Cantarell,Helvetica Neue,Arial,sans-serif!important}
  button,input,textarea,select{font-family:inherit}
  html{background-color:#fff}
  html.dark{background-color:#212121}
  html.mobileSkybridge.dark{background-color:#000}
  @supports (font: -apple-system-body){html.mobileSkybridge{font:-apple-system-body}}
</style>

Meglio tenerlo a mente — avrai meno sorprese.

2. Temi e colori: vivere nelle versioni chiara e scura

Tema chiaro e tema scuro

L’interfaccia di ChatGPT supporta già il tema chiaro e quello scuro. Il tuo widget viene mostrato dentro uno di essi e l’utente può passare dall’uno all’altro in qualsiasi momento. Quindi, sfondi bianchi o neri codificati in modo rigido sono potenziali mine.

Immagina un widget che disegna sfondo bianco e testo nero. Nel tema chiaro è accettabile. Nel tema scuro — un faro puntato negli occhi. L’opposto con lo sfondo nero nel tema chiaro non è meglio. Per questo le raccomandazioni ufficiali sconsigliano hardcodare i colori e invitano ad appoggiarsi al tema/alle variabili dell’host.

Nell’Apps SDK l’ambiente di solito fornisce API o variabili CSS per il tema corrente. Nella documentazione compaiono varianti come window.openai.theme e l’uso delle variabili CSS standard di ChatGPT. Inoltre, esiste sempre prefers-color-scheme e le utility dark: in Tailwind.

L’idea è più o meno questa: il tuo widget deve adattare automaticamente al tema dell’host cose come:

lo sfondo delle card (leggermente più chiaro/più scuro dello sfondo base),
il colore del testo (contrasto sufficiente),
bordo, ombre e stati hover.

Esempio di wrapper minimale per il tema con Tailwind:

// components/AppShell.tsx
export function AppShell({ children }: { children: React.ReactNode }) {
  return (
    <div className="bg-background text-foreground">
      {/* bg-background/text-foreground sono ridefiniti dal tema */}
      {children}
    </div>
  );
}

Dove bg-background e text-foreground non sono classi standard di Tailwind, ma alias di variabili CSS della tua design system (per esempio da shadcn/ui), che a loro volta sono collegate al tema chiaro/scuro di ChatGPT.

Colori di sistema vs accenti di brand

OpenAI è piuttosto chiara: i colori di sistema di ChatGPT non si toccano. Testo base, pannelli standard della chat, sfondo — tutto deve restare nei colori comuni della piattaforma. Il tuo campo d’azione sono gli accenti dentro il widget: pulsanti CTA (call to action), badge, piccoli elementi.

Nella pratica di GiftGenius questo significa che:

lo sfondo della card del regalo è vicino a quello di sistema,
il testo usa il colore di sistema, come quello della chat,
il colore del brand GiftGenius si usa per il pulsante principale «Scegli un regalo» e, forse, per il badge dello sconto.

Si può immaginare una tabella:

Elemento	Cosa fare	Cosa evitare
Sfondo del widget	Ereditare da ChatGPT	Impostare un gradiente di brand vistoso
Testo principale	Ereditare il colore di sistema	Renderlo colorato/grigio fino a perdere leggibilità
Pulsante CTA principale	Usare il colore accento del brand	Metterci «l’arcobaleno» e 5 colori
Pulsanti/link secondari	Vicini ai link di sistema	Renderli brillanti quanto la CTA
Ombre/bordi	Delicati, minimalisti	Bordi al neon spessi

Mini‑esempio con Tailwind per il colore principale:

// styles/globals.css (frammento)
:root {
  --gift-accent: 222 84% 56%; /* hsl */
}

.dark {
  --gift-accent: 222 84% 64%; /* un po' più chiaro per il tema dark */
}

// components/GiftButton.tsx
export function GiftButton({ children }: { children: React.ReactNode }) {
  return (
    <button className="rounded-md bg-[hsl(var(--gift-accent))] px-4 py-2 text-sm font-medium text-white hover:opacity-90">
      {children}
    </button>
  );
}

Non tocchi lo sfondo dell’intero widget, ma applichi con cura il tuo colore al pulsante CTA principale.

Contrasto e WCAG senza fanatismo

Anche se non stai per dare un esame su WCAG, c’è un riferimento semplice: il testo deve essere leggibile. Più piccolo è il font, maggiore deve essere il contrasto. Nei corsi di accessibilità si consiglia di mantenere il contrasto testo/sfondo non inferiore a ~4.5:1 per il corpo del testo. Non entriamo qui nei dettagli dello standard: ci basta un riferimento pratico — contrasto sufficiente tra testo e sfondo.

In pratica:

non usare testo grigio chiaro su sfondo grigio chiaro per «eleganza»;
evita testo grigio scuro su sfondo quasi nero nel tema scuro;
verifica almeno a occhio: se strizzi gli occhi, anche l’utente farà fatica.

Mettiti d’accordo con te stesso: qualsiasi testo secondario (etichette, suggerimenti) resta leggibile, solo un po’ meno accentato per colore e dimensione, ma non «completamente evanescente».

3. Tipografia: font di sistema, gerarchia e un po’ di buon senso

Font di sistema invece del «tuo» webfont

Le linee guida ufficiali invitano a usare i font di sistema della piattaforma, come SF Pro, Roboto e analoghi, e a non introdurre un webfont tuo. La ragione non è solo la performance, ma anche il fatto che la tua App deve sembrare un elemento nativo dell’interfaccia.

In un’app Next.js è più semplice fare in modo che tutto dentro il widget erediti lo stack di sistema. In Tailwind questo è spesso già configurato come font-sans. Se vuoi essere più esplicito:

// app/layout.tsx (frammento)
export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body className="font-sans antialiased">
        {children}
      </body>
    </html>
  );
}

Non serve collegare 3 famiglie tramite Google Fonts. Per il progetto didattico GiftGenius un rigoroso font di sistema apparirà più curato del fantasioso Lobster.

Gerarchia delle dimensioni

Bastano pochi livelli di tipografia: titolo del blocco, sottotitolo/parametro chiave, testo principale e didascalia.

Per una card inline di GiftGenius, ad esempio, può essere comodo concordare questi livelli:

Ruolo	Classe Tailwind	Esempio
Titolo della card	`text-base font-semibold`	Nome del regalo
Parametro chiave	`text-sm font-medium`	Prezzo o categoria
Descrizione	`text-sm text-muted-foreground`	Breve descrizione
Didascalia/dettagli	`text-xs text-muted-foreground`	Consegna, negozio

Mini‑componente card:

// components/GiftCard.tsx
type GiftCardProps = {
  title: string;
  price: string;
  description: string;
};

export function GiftCard({ title, price, description }: GiftCardProps) {
  return (
    <div className="rounded-lg border bg-card p-4">
      <h3 className="text-base font-semibold">{title}</h3>
      <p className="mt-1 text-sm font-medium text-emerald-600">{price}</p>
      <p className="mt-2 text-sm text-muted-foreground">{description}</p>
    </div>
  );
}

Qui:

niente H1 enorme;
tutte le informazioni sono compatte;
la gerarchia si legge da dimensione e peso del font.

Allineamento e lunghezza delle righe

L’interfaccia a chat è in genere stretta, soprattutto inline. Quindi non serve scaldarsi con tipografie complesse: il classico allineamento a sinistra e una lunghezza riga di 40–60 caratteri sono confortevoli.

Abitudini utili:

non centrare testi lunghi nella card — sono più difficili da leggere;
non SCRIVERE TUTTO IN MAIUSCOLO;
non scendere sotto 14 px per il testo base (in Tailwind è text-sm) senza motivi molto seri.

Nel dubbio ricorda: leggerà una persona stanca su un telefono in metro, non tu con un monitor perfetto da 27".

4. Spaziature, densità e griglia

Se colori e font sono le «vernici», le spaziature sono l’aria. Senza di esse anche le card più curate diventano un pasticcio.

OpenAI sottolinea nelle sue raccomandazioni: gli elementi non devono essere «incollati», spaziature e raggi è meglio prenderli dalla design system o dal framework UI (Tailwind, shadcn/ui ecc.), e lo scroll orizzontale va minimizzato.

Il principio del «respiro»

Il pattern più semplice: usare una scala unica di spaziature (ad esempio step da 4 px o 8 px) e non inventare ogni volta una dimensione «propria». In Tailwind è già tutto pronto: p-2, p-3, p-4, gap-3 ecc.

Esempio di piccola griglia per l’elenco regali in inline:

// components/GiftListInline.tsx
export function GiftListInline({ children }: { children: React.ReactNode }) {
  return (
    <div className="flex flex-col gap-3">
      {children}
    </div>
  );
}

Ogni card è separata da gap-3, ha i propri p-4 interni, e già questo basta perché l’elenco non sembri un muro compatto.

Colonne: inline vs fullscreen

Nei documenti UX per l’Apps SDK si consiglia, per il widget inline, di restare su 1–2 colonne di card, mentre in fullscreen ci si può permettere 2–3 colonne se la larghezza lo consente.

La ragione è semplice: nella chat la larghezza è limitata, soprattutto su mobile, e due colonne sono già al limite della leggibilità. In fullscreen hai quasi tutto lo schermo e puoi disporre i contenuti in modo più denso.

Schema indicativo:

flowchart LR
  subgraph Inline
    A[1 colonna
schermo stretto]
    B[2 colonne
su desktop]
  end

  subgraph Fullscreen
    C[2 colonne
scenario principale]
    D[3 colonne
per griglie/cataloghi]
  end

Implementazione in Tailwind per GiftGenius:

// components/GiftGrid.tsx
export function GiftGrid({ fullscreen, children }: { fullscreen?: boolean; children: React.ReactNode }) {
  const base = fullscreen ? "grid-cols-2 md:grid-cols-3" : "grid-cols-1 sm:grid-cols-2";

  return (
    <div className={`grid gap-4 ${base}`}>
      {children}
    </div>
  );
}

In modalità inline fornisci una colonna su mobile e due su schermi più larghi. In fullscreen parti da 2–3 colonne in base alla larghezza.

Evitare lo scroll orizzontale

Per natura la chat è verticale. L’utente è abituato a scorrere in basso, non di lato. Quindi:

cerca di fare in modo che tabelle e card rientrino nella larghezza del contenitore;
non impostare larghezze fisse come width: 600px; per un elemento che vive in un contenitore flessibile;
usa max-w-full, overflow-x-auto solo come «ultima spiaggia», non di default.

Per le card di GiftGenius è comodo impostare w-full e lasciare alla griglia decidere quante ne entrano per riga.

5. Reattività dentro il contenitore di ChatGPT

Nel frontend «classico» hai il pieno controllo del viewport. In ChatGPT questo controllo è limitato: il tuo widget è inserito nel contenitore della chat, con dimensioni e regole proprie. L’Apps SDK offre alcuni ponti utili: altezza massima, safe area per i notch, tipo di dispositivo ecc.

maxHeight e vincoli verticali

In modalità inline ChatGPT può limitare l’altezza del widget per evitare che «si mangi» tutto lo schermo. Hook come useMaxHeight() permettono di sapere quanto spazio puoi occupare onestamente e di mettere scroll interni dove serve.

Pseudocodice:

// Pseudocodice, non un'API reale:
const maxHeight = useMaxHeight();

return (
  <div style={{ maxHeight, overflowY: "auto" }}>
    <GiftGrid>{/* ... */}</GiftGrid>
  </div>
);

Così eviti che il widget si incastri contro il bordo inferiore dello schermo e che i messaggi della chat «scivolino» nel passato remoto.

safeArea e dispositivi mobili

Su dispositivi mobili in alto e in basso possono esserci notch, status bar, pannelli di sistema. L’Apps SDK consente di ottenere la safeArea e regolare le spaziature per non nascondere contenuti sotto la «frangia» del telefono.

A livello CSS puoi aggiungere padding extra:

// Pseudocodice
const { top, bottom } = useSafeArea(); // poniamo che restituisca { top: 8, bottom: 16 }

return (
  <div style={{ paddingTop: top, paddingBottom: bottom }}>
    {/* contenuto */}
  </div>
);

Nel contesto della lezione ci interessa il principio: il widget deve rispettare il limite di altezza e la safe area, altrimenti l’UX diventa subito «fai altri tre scroll per vedere il pulsante».

6. Tailwind e shadcn/ui: non reinventare i pulsanti da zero

Scrivere tutto l’UI a mano in puro CSS oggi è quasi sport hardcore. Nel contesto delle ChatGPT App è molto più semplice prendere una libreria collaudata e adattarla ai requisiti della piattaforma. Nel corso ci basiamo su Tailwind e shadcn/ui come stack di base.

Tailwind come dizionario di spaziature e colori

Tailwind offre un set di utility comode:

spaziature (p-4, gap-3),
dimensioni (text-sm, text-base),
colori (text-muted-foreground, bg-card), che in shadcn/ui e sistemi simili sono già collegati alle variabili CSS del tema.

Questo si sposa perfettamente con i requisiti di ChatGPT:

non inventi spaziature arbitrarie,
imposti dimensioni del testo in modo coerente,
non rompi i colori di sistema, ma usi token già concordati.

shadcn/ui come set di componenti curati

shadcn/ui (e librerie simili) forniscono Card, Button, Input, Tabs ecc. già pronti, configurati sulla tema Tailwind. Questo accelera molto l’assemblaggio di un’interfaccia pulita e minimalista, specialmente per le card di GiftGenius.

Esempio GiftCard con shadcn/ui:

// components/GiftCardShadcn.tsx
import { Card, CardContent, CardHeader, CardTitle } from "@/components/ui/card";
import { Button } from "@/components/ui/button";

type GiftCardProps = {
  title: string;
  price: string;
  description: string;
};

export function GiftCardShadcn(props: GiftCardProps) {
  return (
    <Card>
      <CardHeader>
        <CardTitle className="text-base">{props.title}</CardTitle>
      </CardHeader>
      <CardContent className="space-y-2">
        <p className="text-sm font-medium text-emerald-600">{props.price}</p>
        <p className="text-sm text-muted-foreground">{props.description}</p>
        <Button className="mt-2">Scegli un regalo</Button>
      </CardContent>
    </Card>
  );
}

Il punto non è tanto shadcn, quanto i principi:

il titolo non è gigantesco;
la descrizione è leggibile;
il pulsante è stilizzato secondo la design system comune, non «a modo suo».

Adattamento a ChatGPT

In un progetto reale puoi adattare la palette allo stile minimalista di ChatGPT: sfondo chiaro, ombre morbide, raggi curati. Il piano del modulo suggerisce esplicitamente di appoggiarsi a una design system esistente, non di creare un universo a parte.

Approccio semplice:

partire dalla base di shadcn/ui;
mantenere il font di sistema;
configurare uno‑due colori di brand nei token primary / accent;
assicurarsi che sia inline sia fullscreen usino gli stessi token.

Così ottieni un nucleo visivo coerente senza sforzi inutili.

7. Linguaggio visivo di GiftGenius: mettere tutto insieme

Ricapitoliamo cosa possiamo già considerare «linguaggio visivo» per il nostro GiftGenius.

Primo, lo schema dei colori. Sfondo e testo ereditati da ChatGPT; colore accento — sobrio ma visibile, applicato ai pulsanti CTA e magari ai badge di sconto. Nel tema scuro questo accento è un po’ più chiaro, per mantenere il contrasto.

Secondo, tipografia. Font di sistema di base, dimensioni text-sm per il corpo e text-base per i titoli delle card. Corsivo e maiuscole usati raramente e solo se necessario. I titoli nel wizard fullscreen un gradino più in alto, ma ancora lontani dai text-4xl «urlanti».

Terzo, spaziature e griglia. In modalità inline l’elenco dei regali — una o due colonne con gap-3/gap-4, ogni card con p-4. In fullscreen — 2–3 colonne, step del wizard con sufficienti spazi tra form e pulsanti. Niente scroll orizzontale per gli scenari principali.

Piccolo schema per le schermate di GiftGenius:

graph TD
  A[Inline: elenco regali] --> B[GiftCard
colori/tipografia/CTA]
  A --> C[GiftGrid 1–2 colonne]

  D[Fullscreen: wizard di selezione] --> E[Passo 1
form]
  D --> F[Passo 2
filtri/intervalli]
  D --> G[Passo 3
conferma]
  
  B --> H[GiftButton
accento di brand]

Quarto, compatibilità con il contesto host. Tutti gli elementi si comportano bene al cambio tra tema chiaro/scuro, rispettano maxHeight e non si nascondono sotto la safe area. I colori non litigano con quelli di ChatGPT, e i pulsanti CTA hanno lo stesso aspetto ovunque, così l’utente sa «di riflesso» dove cliccare.

Questo set di decisioni rende già la tua app presentabile non solo agli sviluppatori, ma anche a utenti reali o product manager: ci sarà di che discutere oltre a «qui abbiamo MCP, e qui l’Agents SDK».

8. Accessibilità (Accessibility Guidelines, WCAG AA)

Abbiamo già menzionato WCAG parlando del contrasto tra testo e sfondo nella sezione 2.3. Lì ci interessava un riferimento pratico — non uccidere la leggibilità. Ora guardiamo l’accessibilità un po’ più in largo: come lo stesso UI appare a chi non lo vede con gli occhi e alla stessa ChatGPT in modalità vocale.

WCAG AA è un livello dello standard di accessibilità della raccolta internazionale WCAG (Web Content Accessibility Guidelines), che descrive come rendere siti e interfacce accessibili a persone con limiti diversi di vista, motricità, aspetti cognitivi, ecc.

L’idea principale di WCAG AA è trasformare l’interfaccia da semplicemente «teoricamente accessibile» a davvero usabile. Questo livello include decine di requisiti che influiscono direttamente sulla qualità dell’interazione. Tra questi — la soglia di contrasto testo/sfondo attorno a 4.5:1, di cui abbiamo già parlato, e i requisiti per dimensioni delle aree cliccabili, stati di focus, errori nei form, ecc.

Strato a parte — supporto delle tecnologie assistive, inclusi gli screen reader. Il livello AA richiede semantica corretta: i titoli devono essere titoli, gli elenchi — elenchi, i pulsanti — pulsanti, e gli elementi interattivi devono avere ruoli e alternative testuali appropriati. Questo permette agli utenti che usano VoiceOver, TalkBack o NVDA di comprendere pienamente struttura e significato dell’interfaccia.

Screen reader (lettore di schermo)

Screen reader (lettore di schermo) è un programma che vocalizza e/o struttura i contenuti a schermo, permettendo a persone con disabilità visive di usare computer, smartphone o web app.

Ma uno screen reader non è solo «un programma che legge il testo ad alta voce». È un sistema completo di interazione con l’interfaccia che trasforma la rappresentazione visiva di un sito o di un’app in una navigazione sonora e strutturata percepibile.

ChatGPT, screen reader e WCAG AA

Se il tuo widget è marcato secondo i principi WCAG AA (ruoli corretti, titoli, etichette per i pulsanti), diventa comprensibile non solo per gli screen reader, ma anche per ChatGPT in modalità vocale. L’utente parla con ChatGPT a voce, e il modello, basandosi sulla stessa struttura semantica, può «virtualmente» fare ciò che fa una persona: trovare gli elementi giusti, premere pulsanti, seguire link, ecc.

Secondo i requisiti del ChatGPT Store, il supporto dello standard WCAG AA è obbligatorio per ogni applicazione. Ogni widget e ogni tool devono avere descrizioni massimamente chiare e dettagliate, e il markup deve essere eseguito in accordo allo standard WCAG AA: semantica corretta, etichette leggibili, stati prevedibili.

Quindi il requisito WCAG AA non è una «feature per persone con esigenze speciali», ma un principio di design di base affinché ChatGPT Apps possa lavorare appieno con la tua applicazione, anche quando l’utente interagisce in modalità vocale.

Torneremo a scenari di voice‑UX, differenze tra dialogo vocale e testuale e ai requisiti del ChatGPT Store in altre lezioni di questo modulo e in quello sulla pubblicazione delle App. Ma tutto poggia sul fondamento che hai appena visto: modalità vocale = multimodalità + accessibilità (WCAG AA + screen reader).

9. Errori tipici di visual design per le ChatGPT App

Errore n. 1: background e colori del testo codificati in modo rigido (bianco/nero).
Lo sviluppatore disegna sfondo bianco e testo nero senza pensare al tema scuro. Nel tema chiaro può anche andare, nel tema scuro diventa un faro e rovina l’UX. È più corretto usare i colori di sistema e il tema dell’host (variabili CSS, prefers-color-scheme o API dell’Apps SDK) e riservare i propri colori solo per gli accenti.

Errore n. 2: branding troppo aggressivo.
Appaiono sfondi a gradiente vistosi, font personalizzati, bordi sgargianti. Il widget inizia a sembrare un promo‑banner, non parte dell’interfaccia di ChatGPT. Le linee guida richiedono l’opposto: aspetto minimalista e «nativo», con uso misurato del colore del brand solo negli elementi chiave, ad esempio i pulsanti principali.

Errore n. 3: assenza di gerarchia tipografica.
Tutti i testi hanno la stessa dimensione e peso, oppure — al contrario — tre livelli di titoli su una card piccola, magari pure in maiuscolo. L’utente non capisce cosa sia importante: nome, prezzo o descrizione. È meglio concordare in anticipo 3–4 livelli e mantenerli ovunque: titolo, parametro chiave, testo principale, didascalia.

Errore n. 4: elementi appiccicati senza spaziature.
Le card sono attaccate una all’altra, il testo è a filo del bordo, i pulsanti incollati al testo. Su desktop può ancora passare, su mobile diventa rumore visivo. Si raccomanda di usare una scala unica di spaziature (ad esempio le classi Tailwind p-4, gap-3) e di non lesinare sull’aria.

Errore n. 5: tentare di infilare 4–5 colonne in modalità inline.
Lo sviluppatore mentalmente è ancora su una pagina e‑commerce e fa una griglia di quattro card strette nella chat. Su schermi larghi è discutibile, su mobile è illeggibile, e si aggiunge lo scroll orizzontale. Nel widget inline in genere bastano una‑due colonne; la terza lasciatela alla modalità fullscreen.

Errore n. 6: ignorare i limiti di altezza e la safe area.
Il widget disegna un elenco enorme senza scroll interno e senza considerare maxHeight, così i pulsanti finiscono «sotto il bordo dello schermo». Oppure gli elementi si nascondono sotto il notch su mobile. Usa i dati su altezza massima e safe area per distribuire correttamente altezze e padding interni.

Errore n. 7: aspetto incoerente di pulsanti e card tra inline e fullscreen.
In inline il pulsante è verde e arrotondato, in fullscreen è blu e squadrato. L’utente perde la sensazione di un prodotto unico. Bisogna estrarre gli stili base di pulsanti e card in componenti/tema comuni e usarli in tutte le modalità.

Errore n. 8: font «d’autore» e ornamenti decorativi.
Collegare un webfont pesante «perché è bello» rompe la coerenza visiva con ChatGPT e a volte danneggia la performance. Le raccomandazioni della piattaforma dicono di usare i font di sistema e una tipografia curata. Se vuoi esprimerti come designer — meglio lavorare su icone e microcopy, non su una rivoluzione tipografica.

Precedente Lezione precedente

Prossima Prossima lezione

Commenti

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION