Il web deve fare ciò che Minecraft fa male
Nel client di gioco è facile scegliere una modalità o ricevere un avviso breve. È molto meno comodo leggere una guida lunga, confrontare uno storico di modifiche, discutere una proposta o cercare un comando amministrativo con variabili. Per questo il sito non dovrebbe duplicare la lobby: dovrebbe completarla.
Abbiamo diviso il portale in tre funzioni. La prima è pubblica ed editoriale: guide, regolamento, progetto e articoli. La seconda è community: forum, profili, eventi e roadmap. La terza è operativa e riservata: strumenti per lo staff. Questa separazione aiuta sia l’utente sia il motore di ricerca a capire quali pagine rappresentano contenuto e quali sono interfacce applicative.
Quando troppi link diventano un problema di architettura
Man mano che il sito cresce, l’header tende ad accumulare voci. Aggiungere un altro link sembra economico, ma ogni scelta compete con le altre e su schermi piccoli il costo diventa evidente. Abbiamo quindi raggruppato la navigazione per intenzione: giocare, partecipare alla community e scoprire il progetto.
La stessa logica vale per l’area account. Login, profilo, utenti, strumenti staff e logout non devono occupare tutti lo stesso livello visivo. Un menu account deve diventare più ricco dopo l’accesso senza trasformare l’header in una dashboard.
La regola che usiamo è: la navigazione principale serve a scegliere una destinazione; la pagina di destinazione serve a scegliere un’azione. Mescolare i due livelli produce menu enormi e percorsi difficili da mantenere.
Se una pagina perde lo stile su mobile, non è un dettaglio
Un problema emerso durante lo sviluppo riguardava una pagina operativa che su desktop caricava correttamente lo stile mentre su mobile risultava incompleta. Questi bug sono facili da classificare come “solo CSS”, ma spesso coinvolgono percorsi relativi, media query, ordine degli asset o componenti che assumono una larghezza minima non disponibile.
La correzione deve quindi verificare più di un breakpoint. Controlliamo caricamento degli asset, overflow orizzontale, dropdown, modali, tabelle, pulsanti e aree cliccabili. Una pagina staff è comunque un prodotto: il fatto che sia usata da poche persone non giustifica un’esperienza fragile.
Il principio più utile è testare la funzione, non la schermata. Se un kanban è responsive ma non consente di spostare una card con touch, la pagina non è davvero mobile.
Autenticazione non significa mostrare tutto a chiunque abbia fatto login
Il sistema di utenze distingue identità e autorizzazione. Essere autenticati permette di avere un profilo; non implica automaticamente poter modificare roadmap, gestire utenti o aprire strumenti operativi. Ogni azione sensibile deve avere un controllo server-side, non soltanto un pulsante nascosto nel frontend.
Dal 26 agosto il profilo non è più soltanto username e ruolo: supporta avatar e banner, con animazioni riservate lato server a staff e abbonamenti, email verificata per login e recupero password e collegamenti esterni Google/Microsoft tramite OAuth/OIDC. Chi nasce da un provider può impostare anche una password locale; un provider non può essere scollegato se sarebbe l’unico metodo di accesso rimasto.
Questa distinzione è particolarmente importante quando il sito cresce da semplice vetrina a strumento di lavoro. Le pagine pubbliche devono restare accessibili senza account quando non esiste una ragione reale per chiuderle; le funzioni staff devono invece fallire in modo sicuro anche se qualcuno prova a richiamare direttamente l’endpoint.
Un forum non è una lista di card: è una sequenza di stati
Visualizzare categorie e discussioni è la parte più semplice. Un forum completo deve gestire creazione, risposta, modifica, lock, pin, segnalazioni, voti, permessi, stato risolto e collegamenti tra profilo e attività. Ogni azione deve poi aggiornare la vista senza lasciare dati locali divergenti rispetto al server.
Per questo il forum EclipsMC viene trattato come applicazione e non come contenuto editoriale. Le discussioni della community possono essere utili ai giocatori, ma non vengono usate come sostituto delle guide ufficiali: una risposta di un utente può essere corretta oggi e superata domani. Le pagine editoriali hanno invece responsabilità, data di aggiornamento e revisione.
Una roadmap deve poter cambiare davvero
Una board in stile kanban è utile soltanto se le card possono essere spostate, modificate e persistite. Quando il drag & drop smette di funzionare, non basta che la grafica continui a sembrare una board: la funzione centrale è rotta.
Abbiamo quindi separato la presentazione dallo stato: colonne e card vengono renderizzate a partire da dati salvati, mentre le operazioni passano da API con controlli di permesso. Questo rende possibile diagnosticare se il problema è nel gesto di trascinamento, nella richiesta HTTP, nella validazione o nel salvataggio.
La roadmap pubblica ha anche un compito comunicativo: distinguere idee, pianificazione, sviluppo, test e completamento. “In sviluppo” non deve essere interpretato come una promessa di rilascio immediato.
Il Command Center trasforma memoria individuale in conoscenza condivisa
I comandi di amministrazione tendono a vivere in messaggi Discord, note personali e cronologie del terminale. Con il tempo compaiono duplicati, vecchi nomi di progetto e varianti che fanno quasi la stessa cosa. Il Command Center nasce per risolvere questo problema: un catalogo privato, ricercabile e componibile in cui il comando è accompagnato da descrizione, categoria, variabili e contesto d’uso.
Un comando come una protezione globale WorldGuard non è utile soltanto come blocco di testo. Deve spiegare quale mondo stai modificando, quali categorie di interazione vengono negate e quali restano permesse. Allo stesso modo, un comando per consegnare una key o cambiare un ruolo deve rendere evidente il parametro che verrà sostituito prima della copia.
Il valore non è “avere tanti comandi”, ma ridurre errori di amministrazione e dipendenza dalla memoria di una singola persona.
Indicizzare il contenuto, non ogni schermata
Login, account, pannelli staff, pagine dinamiche temporanee e strumenti di gestione non descrivono il progetto meglio di una guida o di un caso di studio. Per questo usiamo noindex sulle superfici applicative che non hanno senso come risultato di ricerca e una sitemap dedicata alle pagine editoriali.
Canonical, robots.txt, sitemap e metadati sono fondamenta, ma non trasformano automaticamente una pagina in contenuto utile. Il lavoro tecnico serve a far capire ai crawler cosa vogliamo rendere pubblico; il valore della pagina dipende da ciò che il lettore impara una volta arrivato.
Il sito deve meritarsi ogni nuova pagina
Ogni nuova route aggiunge manutenzione, link, metadati, test responsive e rischio di duplicazione. Prima di crearla chiediamo quale problema risolve. Se la risposta è soltanto “fa sembrare il sito più grande”, la pagina non serve. Se invece permette di documentare un processo, aiutare un giocatore, raccogliere feedback o svolgere un’operazione in modo più sicuro, allora ha una funzione chiara.
Eclips Lab nasce proprio da questa regola: non aggiungere pagine per quantità, ma pubblicare materiale che deriva dal lavoro reale sul network e che resta utile anche fuori dall’annuncio del giorno.