
La scelta tra Light mode e Dark mode può influire sull'esperienza utente? Sì, eccome!  
La modalità scura può ridurre l'affaticamento degli occhi in ambienti con scarsa illuminazione, mentre la modalità chiara può essere più confortevole in ambienti luminosi. Inoltre, la modalità scura può migliorare la leggibilità per alcune persone con disabilità visive. Ecco perché in generale sia **importante fornire un'opzione per gli utenti e permettere loro di scegliere la modalità preferita**.

Questa affermazione è supportata da **diversi studi e ricerche** nel campo della progettazione dell'interfaccia utente e sulla relativa [accessibilità](/blog/posts/design-e-accessibilita).

### Sicurezza degli occhi
La modalità scura può aiutare a **ridurre l'affaticamento degli occhi** e ridurre la luce blu dannosa, poiché utilizza colori più scuri e meno brillanti, l'affaticamento cala in maniera significativa.

### Usabilità
La modalità chiara può essere più confortevole per gli utenti in ambienti luminosi, poiché utilizza colori più chiari e più brillanti.

### Accessibilità
La modalità scura può **migliorare la leggibilità** per alcune persone con disabilità visive, come il daltonismo. Appiattire la palette colori limitandone la luminosità è chiaramente a vantaggio di queste categorie di utenti.

<Image src='/images/posts/importanza-scelta-dark-light-mode/white-vs-dark.jpg' width={450} height={338} alt='ios13 introduce la scelta tra light mode e dark mode' className='postImage'/>


## Un po' di storia
Avrai già notato quindi come non esista in generale una modalità migliore dell'altra, queste **si adattano meglio a diversi contesti di utilizzo**.   
Facciamo però un piccolo passo indietro, ovvero a quando ha iniziato a imporsi la modalità scura. 

La modalità scura si è imposta come trend diventando popolare negli ultimi anni, in particolare con l'aumento dell'utilizzo di dispositivi mobili e la necessità di **risparmiare batteria** su questi dispositivi.

La prima volta che la modalità scura è stata introdotta come opzione per gli utenti è stata con il **sistema operativo iOS 13 di Apple**, rilasciato nel settembre 2019. Da allora, molti altri sistemi operativi e applicazioni hanno seguito l'esempio, offrendo un'opzione per gli utenti di passare alla modalità scura.

Inoltre, la modalità scura è diventata sempre più popolare come scelta di design per i siti web e le applicazioni, poiché fornisce un look elegante e moderno, migliora la leggibilità e aiuta a risparmiare batteria sui dispositivi mobili, da un lato percorrendo l'autostrada della moda, **il legame tra il dark mood e il cyberpunk**, dall'altro come si è detto, in risposta a prinicipi estremamente funzionali.

## Risposte a confronto

L'affermazione della dark mode però non si è tradotta in uno standard *de facto*, ovviamente abbiamo osservato reazioni diverse da parte dei principali brand che normalmente hanno la capacità di influenzare lo stato del design dei prodotti e servizi.

### Entusiasti
Alcuni esempi di brand che hanno adottato con entusiasmo la modalità scura nel design del proprio sito web sono:
- **Apple**: come menzionato, Apple ha introdotto la modalità scura con il loro sistema operativo iOS 13 e da allora l'ha integrata in molte delle proprie applicazioni, servizi e relative piattaforme
- **Google**: Google ha integrato la modalità scura in molti dei propri prodotti, tra cui Android 10, YouTube e Gmail, addirittura nella popolare finestra dei risultati di ricerca
- **Twitter**: Twitter ha introdotto la modalità scura come opzione per gli utenti già nel 2018, è stato forse la propulsione all'affermazione e popolarità nel mondo dei non-nerd, ora la offre come opzione predefinita per molti dei loro utenti
- **Instagram**: anche Instagram ha introdotto la modalità scura come opzione per gli utenti nel 2019 mentre il popolare Facebook ha preferito aspettare e testare i risultati, a un certo punto ha deciso di togliere l'opzione dark e scatenato parecchi malumori.

### Resistenti
Al contrario, altri invece hanno decisamente mostrato forza nel resistere a questa impostazion, tra questi ricodiamo:
- **Amazon**: ha introdotto un'opzione per la modalità scura ma solo in alcune funzionalità o applicazioni. Ancora non è stata implementata sulla piattaforma principale, e pertanto i risultati di ricerca sono sempre su sfondo bianco.
- **Netflix**: Netflix non offre un'opzione di scelta sulla propria piattaforma, la sola dark mode, come detto, in alcuni contesti non è propriamente indicata.

## La sfida di domani
Penso che l'aspetto più significativo sia **lasciare l'opzione di scelta all'utente** e far decidere come meglio fruire i nostri servizi.
Sebbene sia ancora in corso un dibattito su quale modalità sia migliore per la vista, questo può essere facilmente risolto quando si forniscono personalizzazioni con entrambe le modalità disponibili, ovvero quando si lascia la scelta all'utente: gli utenti che si sentono a proprio agio con la modalità chiara potranno restare in tale dimensione mentre i cyberpunk o semplicemnte chi ha disturbi visivi, come detto, potrà adottare questa nuova opportunità.


Scopri i vantaggi e gli svantaggi di Dark Mode e Light Mode per migliorare l'esperienza degli utenti sul tuo sito web. Leggi il mio articolo per trovare la soluzione migliore per la tua attività. Luca Santi è un UX Designer e UI Developer di Milano.

Dark Mode e Light Mode: cosa fare con il tuo sito web?

L'importanza della scelta tra Light mode e Dark mode


L'anno nuovo è iniziato da oltre un mese, piuttosto che partecipare al tipico esercizio di **anticipare trend** e ottimistiche / pessimistiche previsioni su quale sarà lo stato delle cose a seguito dell'impatto della diffusione di servizi di A.I., preferirei in questo post guardarmi invece alle spalle e ripensare a che cosa, in particolare, è stato il vero tormentone dell'anno: l'accessibilità.

## Design e accessibilità

Il design è l'aspetto funzionale, interattivo e visivo di un'interfaccia. Potremmo semplificare e considerare *buon design* ciò che sappia essere intuitivo, facile da usare e bello da vedere, che tenga conto dei principi di usabilità per garantire che gli utenti possano facilmente comprendere e interagire con l'interfaccia.

L'accessibilità si riferisce alla capacità di un'interfaccia di essere utilizzata da una vasta gamma di utenti, tra cui quelli con limitate capacità. Gli standard di accessibilità, come ad esempio i criteri di accessibilità del contenuto web (WCAG), forniscono linee guida per garantire che le interfacce siano accessibili a tutti gli utenti. 

## Conseguenze 

Chiunque abbia iniziato un percorso di progettazione e sviluppo di interfacce conosce queste linee guida e, più o meno consapevolmente e deliberatamente, sceglie di seguirle e adottarle oppure allontanarsi e trascuralre.   
Questi sono in generale i macroargomenti da tenere presente:
- Contrasto del colore
- Dimensioni del testo
- Navigazione
- Feedback visivo
- Descrizioni alternative
- Layout flessibile

### Contrasto del colore   
Gli standard di accessibilità richiedono che i testi abbiano un contrasto adeguato rispetto allo sfondo per essere facilmente leggibili per gli utenti con problemi visivi. Ciò può influire sulle scelte di design dei colori per garantire che i testi siano facilmente leggibili.

### Dimensioni del testo   
Gli standard di accessibilità richiedono che i testi siano di dimensioni adeguate per essere letti da persone con problemi visivi, quindi il design deve prevedere dimensioni adeguate del testo.

### Navigazione   
Gli standard di accessibilità richiedono che le interfacce siano facilmente navigabili da parte degli utenti con disabilità motorie o visive, quindi il design deve prevedere una navigazione semplice e intuitiva.

### Feedback visivo   
Gli standard di accessibilità richiedono che gli utenti con disabilità possano comprendere l'interfaccia attraverso i feedback visivi, quindi il design deve prevedere una serie di feedback visivi per indicare lo stato attuale dell'interfaccia.

### Descrizioni alternative   
Gli standard di accessibilità richiedono che le immagini e i video abbiano descrizioni alternative per gli utenti non vedenti o ipovedenti, quindi il design deve prevedere la fornitura di descrizioni alternative per questi elementi.

### Layout flessibile   
Gli standard di accessibilità richiedono che l'interfaccia sia flessibile per essere utilizzata con una varietà di dispositivi e tecnologie assistive, quindi il design deve prevedere un layout flessibile per garantire che l'interfaccia sia accessibile da qualsiasi dispositivo.


## In coclusione

In generale, il rispetto degli standard di accessibilità può influire sulle scelte di design in termini di contrasto di colore, dimensioni del testo, navigazione, feedback visivo, descrizioni alternative e layout flessibile (in questo caso inserisco anche il concetto di [dark mode](/blog/posts/importanza-scelta-dark-light-mode), sul quale tornerò in seguito).

Se anche tu hai annusato nell'aria la medesima tendenza a porre sempre più attenzione in materia di **design e accessibilità delle interfacce**, forse sarai d'accordo con me che presto o tardi assisteremo a un'ulteriore "stretta" in materia, arriveremo presto o tardi alla definizone di un framework comune, un vero e proprio regolamento, obblighi non più limitati alla sola nicchia della pubblica amministrazione.   
Ma prima ancora di aspettare che siano i giuristi a occuparsene, non dovremmo forse noi tecnici cercare di limitare i "creativi"nella loro ossessiva ricerca dell'**effetto wow** e intercettare questo bisogno, aiutare e supportare a contrastare il generale appiattimento che comporterebbe un obbligato adattamento al vincolo normativo? 



Scopri come creare esperienze coinvolgenti e accessibili per tutti gli utenti con il mio articolo sul design accessibile. Migliora l'esperienza degli utenti e rendi il tuo sito web più inclusivo con i consigli di Luca Santi, UX Designer e UI Developer di Milano.

Design e accessibilità: come creare esperienze coinvolgenti per tutti gli utenti

Design e accessibilità


Una delle funzionalità più simpatiche che ho scoperto usando React e me lo ha fatto apprezzare è il rendedring condizionale di elementi, ovvero quel pattern per cui, per esempio, a seconda se ci sia o meno una certa condizione (o stato, senza voler introdurre troppa complessità), permette di ritornare (oppure no) un componente o blocco di codice.

Prima di questa scoperta, per ottenere lo stesso scopo mi toccava perdere neuroni e diotrie nei meandri di cicli e verificare le condizioni; questo pattern risulta estremamente comodo, veloce ed elegante e a mio avviso semplifica non poco la vita allo sviluppatore.

## Come lo ho usato fino oggi: &&

Il classico esempio:

```js
function MyComponent({ condition }) {
  return (
    <div>
      <h1>Title</h1>
      {condition && <ConditionalComponent />}
    </div>
  );
}
```
Che potremmo riassumere come: se "condition" è vera allora ritorna "ConditionalComponent" se è falsa no.  
Questo non è tipicamente un aspetto relativo a React ma un **"comportamento" di JavaScript** che ho scoperto venga definito ***Short-circuit Evaluation***, un'espressione con operatori logici che si valuta da sinistra a destra.

## Problemi con uso di &&

La condizione è che sia valutata come vero o falso, ma se invece lo valutassimo come non booleano?  
Se per esempio la condizione fosse "0" o "undefinied"? La faccio breve, potremmo avere errori o il mio preferito "null".

## Il modo giusto, ovvero come lo scriveremo da oggi in poi

Tornare alla grande catena dei Loop? Ma per carità!  
Resterei sempre nell'ambito del **oneliner**, diciamo, ma il modo giusto ora è quello della **Ternary Expression**:

```javascript
function MyComponent({ condition }) {
  return (
    <div>
      <h1>Title</h1>
      {condition ? <ConditionalComponent /> : null}
    </div>
  );
```

## Conclusione
Cosa pensi di questa soluzione per evitare bug (🐛) che si generano con l'uso dell'operatore &&?   
Personalmente penso sia molto elegante e funzionale, previene errori e mi costringe anche a ragionare su come ritornare eventuali eccezioni.


Scopri il modo corretto per eseguire il conditional rendering in React. Leggi il mio articolo per capire come utilizzare al meglio questa tecnica e migliorare le prestazioni del tuo sito web. Luca Santi è un UX Designer e UI Developer di Milano specializzato in sviluppo web.

Rendering Condizionale in React, nel modo corretto

Rendering Condizionale in React, il modo corretto


Siamo abituati ad assistere a cambiamenti repentini in tecnologia, quello di cui vorrei parlare oggi però è qualcosa di più: un cambiamento strutturale, **un cambiamento di architettura del software che ci porta a ripensare completamente a come organizzare il nostro lavoro**.  
Nel tentativo, come spesso avviene nell'ambito delle innovazioni tecnologiche, di evitare il wipeout ed esserne travolto, si propone una nuova ed esaltante sfida, quella lanciata dai microservizi. 

## Che cosa sono i microservizi

I microservizi sono un apporccio che organizza la struttura di un prodotto (o servizio, perdona la ripetizione) in modo che questo sia **composto da servizi indipendenti che comunicano tramite interfacce di programmazione (API)**.


Facciamo subito esempi pratici, in modo da limitare il linguaggio assertivo e andare nel dettaglio delle questioni.

## Architettura Monolitica
Si definisce Architettura Monolitica quella in cui **tutti i processi collegati tra loro sono eseguiti come un unico processo, o servizio**.  
Non sempre è un male, diciamo però che a svantaggio, esempi tipici di criticità sono quello del ritardo di un particolare proccesso che ritarda in evitabilmente il totale; oppure il caso di picchi, oppure ancora quello di un errori.

In questa architettura, come suggerisce il nome, la parola chiave è **unicità**, una rete di elaborazione unica e di grandi dimensioni con una base di codice che raggruppa tutti gli obiettivi di business.

## Architettura di microservizi
La grande novità che introduce l'Architettura dei microservizi è legata al concetto di atomizzazione, l'introduzione di componenti che si occupano in maniera specifica di un processo (o servizio).  
In questo modo **ogni servizio ha una funzione e risulta di facile manutenzione**, indipendente dalle altre, l'eventuale interruzione di un servizio, con le dovute e necessarie precisazioni del caso, non comprometteranno il funzionamento dell'applicativo in generale.  

Questo intendiamo quando parliamo di **sistema distribuito** che si origina dalla comunicazione tramite **API** di tali componenti, che possono essere modificati in modo indipendente, magari da team di lavoro differenti in perfetta modalità *Agile*

## Sviluppi

Ecco come spiegare in breve la popolarità dei moderni framework JavaScript, **React**, (e **Next.js**), Vue, Angular (ecc...); in cui i concetti chiave sono l'atomizzazione, l'essere strutturati in componenti, la gestione della comunicazione tra di loro...

Torneremo ancora sull'argomento con esempi di applicazioni tipiche dell'Architettura a Microservizi.  Spero ti sia piaciuto questo articolo, fammi sapere cosa ne pensi!



Scopri le differenze tra l'architettura monolitica e quella dei microservizi e come scegliere quella giusta per la tua applicazione. Luca Santi è un UX Designer e UI Developer di Milano specializzato in sviluppo web.

Architettura monolitica vs architettura dei microservizi 

Architettura Monolitica e Architettura dei Microservizi


# Single Sign-On di Shibboleth e Applicazioni React 

Come autocritica, avrai notato, parlo di click-baiting e non per nulla.  

## Premessa
Mi sono trovato a dover risolvere questo problema:  
integrare l'autenticazione **Single Sign On di Shibboleth** di un applicativo che volevo, per mio esercizio personale (per forza), sviluppare in React. Anche qui esagero volutamente.  

In realtà, l'unica necessità era determinata dalla scelta (obbligata) di deploy su **Amplify di AWS**, per cui limitato nella scelta di sviluppo in **JavaScript** o ES o React / React-Native.


Come ho agito? Come chiunque al mio posto

![immagine della ricerca in google per risolvere il problema](feel-lucky.jpg)


## Che cos'è Shibboleth?
È un sistema di **autentcazione Single Sign-On (SSO)** che permette di autenticarsi su sistemi differenti, ovvero di effettuare il login su reti di organizzazioni o istituzioni diverse, utilizzando **una sola identità**.

L'infrastruttura è basata sullo standard aperto **Security Assertion Markup Language (SAML)** e consente identity management e autenticazione con identità federata.

Gli elementi fondamentali sono gli **Identity Provider (IdP)**, che hanno il compito di fornire informazioni sugli utenti, i **Service Provider (SP)**, che utilizzano le informazioni e forniscono accesso a contenuti protetti.

![flusso di autenticazione](shibboleth-flow.jpg)

## Prima risposta: il problema non è React

Dato che React agisce lato client, avrai già capito che con React possiamo fare ben poco.  
Si limiterà a interrogare un'API e comunicare con un servizio che lato server si preoccuperà dell'autenticazione.

## Node.js, Express, Passport e Passport-SAML

Lavorando con React e JavaScript in generale, quale migliore occasione per mettere in campo Express in Node.js! Rendiamo quindi il nostro progetto diviso in due cartelle principali:

```bash
- backend
- frontend
```

Onomastica funzionale, nel folder backend metteremo (rullo di tamburi) tutto il contenuto del nostro applicativo Node, nel folder frontend l'applicativo react. Concentriamoci come anticipato sul backend.
Ognuno ha il proprio cocktail di packages preferito, fondamentale per quanto stiamo cercando di fare, aggiungere i due packages seguenti:
```bash
npm install --save passport passport-saml
```

Contrariamente alle best-practises, in questo post configureremo un unico documento, app.js senza complicare il tutto separando in util, router ecc...  
Mantengo tutto in un unico file per rendere più semplice seguire passo-passo, sentiti naturalmente libero di gestire l'app Node come meglio credi da questo punto di vista.


### Key-concepts di partenza

A questo punto, gli elementi necessari per configurare il Service Provider sono:  
- Cert keys, da generare
- Identity Provider meta data
- Identity Provider entry point 

Dobbiamo comunicare al Identity Provider:
- pagina metadata, lo vediamo in seguito
- indirizzo callback, ci arriviamo

### Creiamo Cert Keys

Apri il tuo terminale preferito, creiamo le cert keys necessarie per far funzionare il giro:

```bash
mkdir certs
openssl req -x509 -newkey rsa:4096 -keyout certs/privatekey.pem -out certs/certificate.pem -nodes -days 900
```

Nello stesso folder, salvo anche i dati relativi all'Identity Provider, si trovano analizzando il suo metadata.xml nel tag **X509Certificate**, in un documento che chiamo idp_key.pem per coerenza.

### Configuriamo la Passport Strategy

Ora ci dobbiamo concntrare sulla generazione del Metadata.xml, un insieme di tag da consegnare all'Identity Provider che, in genere, aggiunge al suo elenco di servizi in whitelist permettendoci l'autenticazione.  
Prima di fare ciò, nel file app.js dobbiamo anzitutto configurare la **strategy** di passport.

```js
const https_cert = fs.readFileSync('./certs/certificate.pem', 'utf-8');
const https_pvk = fs.readFileSync('./certs/privatekey.pem', 'utf-8');
const idp_key = fs.readFileSync('./certs/idp_key.pem', 'utf-8');

//  from idp's metadata
const idp_cert_1 = process.env.idp_cert1;
const idp_cert_2 = process.env.idp_cert2;

const shib_strategy = new saml.Strategy(
    {
        'callbackUrl': process.env.callbackUrl,
        'entryPoint': process.env.entryPoint,
        'issuer': process.env.appUrl,
        'cert': [idp_cert_1, idp_cert_2],
        'decryptionPvk': https_pvk,
        'privateKey': https_pvk,
        'privateCert': https_pvk,
        'validateInResponseTo': false,
        'disableRequestedAuthnContext': true,
        'identifierFormat': 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient', 
        'authnContext': ['urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified'],
        'authnRequestBinding': 'HTTP-REDIRECT',
        'protocol': 'https://',
        'signatureAlgorithm': 'sha256',
        'acceptedClockSkewMs': -1
    }, 
    function (profile, done) 
    {
        console.log('passport.use() profile: %s \n', JSON.stringify(profile));
        return done(
            null, profile
            // potrebbe essere utile isolare parametri nell'oggetto profilo, quindi andiamo così:
            // { 
            //     'nameIDFormat': profile.nameIDFormat, 
            //     'nameID': profile.nameID,
            //     'id': profile.uid,
            //     'displayName': profile.cn,
            //     'firstName': profile.givenName,
            //     'lastName': profile.sn
            // }

        );
    }
);

passport.serializeUser(function (user, done) {
    console.log('passport.serializeUser() user: %s \n', JSON.stringify(user));
    done(null, user);
});

passport.deserializeUser(function (user, done) {
    console.log('passport.deserializeUser() user: %s \n', JSON.stringify(user));
    done(null, user);
});

passport.use(shib_strategy);

```

Ovviamente ho messo tutto in un bel .env per mantenere pulita la lettura, presta come sempre attenzione a questa fase e ricorda che qualsiasi modifica a tale file necessità il riavvio dell'applicativo.


### Creiamo il nostro metadata.xml
Se tutto procede come desiderato, adesso dobbiamo poter generare un Metadata.xml, il cui contenuto servirà all'Idp per aggiungere la nostra fantastica applicazione alla sua whitelist.  
Altro non è che una route da configurare, in modo da poterla visitare al suo indirizzo:

```js
app.get(
    '/Shibboleth.sso/Metadata',
    function(req, res) {
        res.type('application/xml');
        res.send((shib_strategy.generateServiceProviderMetadata( https_cert, https_cert )));
    }
);
```

### Routing
Siamo finalmente in grado di consegnare all'idp il nostro metadata.xml, la nostra app sta cominciando a prendere forma.
Adesso dobbiamo configurare tutte le altre routes e, soprattutto, definire i comportamenti della callback una volta effettuata l'autenticazione, che ne so, redirect alla pagina Profile o il redirect alla risorsa protetta in generale... Sbizzarrisciti! Ahimè io invece ho poca fantasia e mi limiterò a reindirizzare su una generica pagina Profile, non è in realtà tanto differente da quanto accade autenticandoti con Spid. 

```js
app.get(
    '/', 
    (req, res) => {
        if (req.isAuthenticated()) {
            console.log('GET [/] user authenticated! req.user: %s \n', JSON.stringify(req.user));
            res.render('home', { user: req.user });
        } else {
            console.log('GET [/] user not authenticated! \n');
            res.render('home', { user: null });
        }
    }

);

app.get(
    '/login', 
    passport.authenticate('saml', { 'successRedirect': '/', 'failureRedirect': '/login' })
);


app.post(
    '/login/callback',
    passport.authenticate('saml', { 'failureRedirect': '/', 'failureFlash': true }),
    function(req, res) {
        console.log('POST [/login] \n');
        res.redirect('/profile');
    }
);

app.get(
    '/profile',
    function(req, res){
        if (req.isAuthenticated()) {
            console.log('GET [/profile] user authenticated! req.user: %s \n', JSON.stringify(req.user));
            res.render('profile', { user: req.user });
        } else {
            console.log('GET [/profile] user not authenticated! \n');
            res.redirect('/login');
        }
    }
);

app.get(
    '/logout',
    function(req, res) {
        console.log('GET [/logout] \n');
        passport._strategy('saml').logout(
            req, 
            function(err, requestUrl) {
                req.logout();
                res.redirect('/');
            }
        );
    }
);
```

## Conclusione

Il backend funziona come ci aspettavamo, non resta che divertirsi con il frontend e **mappare ogni route con react-router**.

Spero sia riuscito a trovare le risposte che stavi cercando e che tu sia riuscito ad **autenticare la tua app in Shibboleth** con l'utilizzo di **Node.js**, **Passport** e **Passport-SAML**, in caso di problemi non esitare a contattarmi o guarda pure la repository in github. 

Grazie per essere arrivato a leggere fino qui e alla prossima.


Scopri come implementare l'autenticazione in Shibboleth con React e Node. Leggi il mio articolo per capire come migliorare la sicurezza della tua applicazione web. Luca Santi è un UX Designer e UI Developer di Milano specializzato in sviluppo web.

Le ultime dal blog

Benvenuto nel Blog! Potrai trovare appunti e riflessioni su argomenti inerenti al design e allo sviluppo di prodottti e servizi per il web.
pagina: 1

L'importanza della scelta tra Light mode e Dark mode

Design e accessibilità

Rendering Condizionale in React, il modo corretto