La nuova risoluzione di #Iphone6 e i tipici break-point nei progetti #responsive #apple

Avevo già aperto una discussione sulla reale robustezza di media-queries impostate sui 4 break-point tipici usati dai dispositivi Apple.
Il lancio del nuovo Iphone6 e Iphone6 Plus dimostano che non possiamo basarci sulla dimensione dei device Apple per dei progetti responsive duraturi nel tempo.
Seguiamo l'esempio degli sviluppatori Android che si sforzano nell'ottimizzare le loro interfacce su moltissimi device, per non incappare in questi errori.

Chi ha impostato una perfetta visualizzazione basandosi su Iphone4 ha dovuto cambiare le cose con Iphone5 e ora si trova nello stesso impaccio. Cercate invece di testare la vostra interfaccia rendendola fluida e ottimizzando il design sulle reali aspettative del cliente, non pensando solo a far bella figura testanto il vs sito web su Iphone o Ipad.

Il risultato sarà un progetto responsive robusto è più duraturo nel tempo perchè non soggetto a risoluzioni schermo preimpostate.

Consigli sull'uso delle #mediaquery nei progetti #responsive #firebug

Come tutti sapete una delle chiavi vincenti della diffusione della tecnica responsive è l'uso delle media-query. Niente di tecnicamente nuovo, nessuna strana invenzione, ma solo un modo intelligente di usare diversti stili css in base alla risoluzione del device che visualizza le nostre pagine.

I 2 modi più usati per dire al browser che stile usare in quel determinato momento e a quella risoluzione, sono 2:

- inserire le media-query nel file css globale. In questo caso nel tag <head> della nostra pagina richiamiamo solamente il file generale style.css Questo file si occuperà poi al suo interno di andare a discriminare i cambiamenti di stile in base alla risoluzione, in base a questa sintassi di esempio:

@media only screen and (max-width: 1300px) {
nuove regole css da utlizzare
}

- la seconda strada (che preferisco) è quella di generale tanti file css per quanti sono i nostri break-point. Come già datto in uno scorso articolo non pensate che il vostro design sia adatto ai 4 canonici break-point ma pensate e confrontate la robustezza del vostro design per moltissime dimensioni dello schermo. Io quindi agisco in modo diverso per ogni progetto e creo dei miei file css che racchiudono dei break-point personalizzati fino al punto di "rottura" del design in corso. Nel tag <head> vengono quindi richiamati tanti file css al cui interno vengono dichiarate le regole da utilizzare per quella risoluzione. La sintassi di esempio da utilizzare in <head> è molto simile alla precedente:

<link href="css/screen_1024.css" media="only screen and (max-width: 1024px)" rel="stylesheet">

L'unica pecca di questa tecnica è che se create delle pagine statiche senza include o altre tecniche dovrete per ogni pagina ricopiare tutte le chiamate ai file css che utilizzano le media-query.

Le 2 tecniche producono lo stesso effetto, ma c'è un vantaggio nell'utilizzare la seconda soprattutto in fase di debug e test (e soprattutto se come me utilizzate Firebug).

Nella prima tecnica infatti per capire se la regola che vi aspettate stà funzionando dovete aprire il file css generale e andare nella riga che Firebug vi indica (se la regola è attiva) nella finestra di ispezione.

 

Come vedete in questo caso nel file css viene richiamata una regola diversa per il logo a risoluzioni più basse di 1024px, ma la cosa non è evidente perchè Firebug ci indica solo che la regola è cambiata alla riga 194 del file css "navigation.css".

Nel secondo caso invece Firebug ci aiuta a capire se la regola che ci aspettiamo stà funzionando come deve:

Anche in questo caso il logo ha un comportamento diverso dichiarato però del file "screen_925.css" alla riga 8. Questo ci permette velocemente di capire se la media-query stà funzionando alla risoluzione impostata e se la regola è scritta correttamente producendo l'effetto desiderato.

Aperta la discussione sul reale vantaggio di usare #Photoshop nella progettazione web #responsivedesign #webdesigner @baloss @sketchin

Leggendo questo articolo sul ruolo del web designer e di Photoshop mi trovo solo in parte d'accordo. E' vero (l'ho sempre sostenuto e anche io mi sento così) un web designer non è un grafico o meglio non è solo un grafico o creativo. Il web designer è un tecnico frontend che fà parte di un team di progettazione ben più ampio. E' normale che in piccole società o parlando di freelance il grafico faccia anche la parte di progettazione e coding html/css ma è giusto puntualizzare il fatto che un bravo web designer deve saper progettare e conoscere bene come funziona una pagina web, prima di conoscere la grafica e i virtuosismi di Photoshop.

Il secondo punto dell'articolo torna a parlare (sono tante ormai le opinioni al riguardo) sulla vera utilità di Photosphop nel normale processo di design. Anche in questo articolo si predilige lo sviluppo della pagina web partendo dal codice, dalla tipografica per poi migliorare man mano la parte grafica.

A mio avviso questo approccio, nell'intero processo creativo e in generale nel processo di vita di un progetto web non è corretto.
Innanzi tutto la progettazione con un software di grafica permette da subito all'account di discutere con il cliente quale sarà l'aspetto del suo nuovo sito web. La parte di design è fondamentale per offrire agli utenti un primo approccio con la realtà che l'azienda vuole comunicare. Questo concetto è spiegato benissimo nell'articolo di Alessandro Galetto componente di Sketchin http://www.sketchin.ch/it/blog/design/il-valore-strategico-del-design.html

La question responsive non rende vana la progettazione in Photoshop anzi offre la possibilità di testare la robustezza del design e delle soluzioni adottate. Pensare di poter ottimizzare le proprie pagine ai numerosi design è una sfida dura ma possibile da superare e il design ci offre la strada.

Inoltre i software grafici ci aiutano nello sviluppo di piccole parti di design e di progettare gli elementi con precisione al px oltre ad ottimizzare in termini di peso e dimensioni ogni immagini utilizzata.

Voi che ne pensate?

Il simbolo del #responsivedesign sono le tre linee del menù #rwd

Mi piacciono molto le convenzioni e gli standard soprattutto quando aiutano la progettazione e il riconoscimento degli elementi. E' il caso delle tre linee orizzontali che sempre più caratterizzano i menù generali di pagine responsive. La convenzione è diventata talmente elevata che oramai si può decidere di eliminare la parolina "menù" che accompagna l'icona.

A questo possiamo aggiungere che quest'icona sia talmente riconoscibile che i menù cambiano posizione occupando degli spazi sulla pagina non proprio classici. Il menù molte volte non è più esploso e viene mostrato in dropdown proprio al click sull'icona.
Ecco un esempio: http://www.jr-associee.com

 

Una nutrita gallery e ottimo articolo lo trovate qui: http://www.smashingmagazine.com/2012/10/08/the-semantic-responsive-design-navicon/

Una sola domanda: L'utente medio che grado di conoscenza e riconoscibilità ha di questa icona?

Il #responsive design non deve essere un trucco per guadagnare di più #webdesign #rwd #agency

A meno che non dobbiate progettare una intranet (e anche su questo dopo approfondiamo il discorso) il vostro prossimo progetto web dovrà essere visto da tanti device diversi.
Qualche anno fà si discuteva su design liquidi o fissi e il proliferare di monitor di varie risoluzioni. Ora il discorso và oltre il desktop e i computer portatili e si estende ai tablet e smartphone. Non possiamo assolutamente pensare sia come professionisti, ma anche come clienti che il nostro sito web sarà visto solo da pc fisso o portatile. Oramai le percentuali di visite si equivalgono se non addirittura sono sbilanciate verso il mondo mobile.

Rendere visibile le pagine web della nostra azienda o attività a tutti i dispositivi possibili non è una scelta, un plus o una chicca. E' assolutamente indispensabile! Non ottimizzare le pagine per smartphone vuol dire eliminare o non considerare importante almeno il 50% del nostro bacino d'utenza.

Ecco perchè come professionista del web pongo al cliente la questione in termini di tempo e non di costi.
Farmi pagare di più per rendere il sito visibile al 100% dei device non è una cosa giusta verso il cliente e verso la mia professione.
Qualche anno fà farsi pagare qualche giornata in più per rendere visibile il sito sugli smartphone e tablet aveva un senso, ma oggi non più. Non rendendo fruibile il mio lavoro a tutti è come se lo facessi a metà e quindi dovrei essere pagato la metà.

Molti clienti invece si ritrovano preventivi gonfiati con la voce "adattamento responsive". Cavalcando anche la moda la voce "responsive" fà breccia nei cuori dei clienti aprendo magicamente il rubinetto dei liquidi per saldare fatture più salate.
Pretendere più soldi per una tecnica "obbligatoria" mi ricorda l'assurda pretesa di aumentare i prezzi per rendere visibili le pagine web ai browser più comuni. Anche questo aspetto è stato abusato negli anni con voci tipo "cross-browsing".

E' giusto anche ricordare nei preventivi e al cliente tutte le tecniche e gli accorgimenti indispensabili ad un progetto web moderno, ma questo non deve far salire i costi.

Il responsive design è una tecnica che dà molte opportunità, ma anche tanti rischi. Non voglio parlare in questo articolo dei rischi tecnici e concettuali, ma voglio solo sottolineare come il responsive design facilita la vita ai professionisti e permette con lo stesso budget al cliente di avere la massima visibilità del proprio sito web su tutti i dispositivi.

Il discorso cambia se il cliente ci chiede uno studio particolare per una web-application o un'applicazione nativa. In questo caso si richiede uno sviluppo separato, professionalità aggiuntive e tempi di sviluppo maggiori. Ma molti dei nostri progetti e clienti ci chiederanno solamente che le pagine web siano visibili ovunque in modalità classica, senza studio particolare sulla UX o cambi di interazione.

Ritornando al discorso intranet una riflessione sulle opportunità del responsive design. Questa tecnica ci permette di poter realizzare pagine web correttamente visualizzate su qualsiasi tipo di risoluzione. Ma questo non vuol dire per forza smartphone e tablet. Il responsive design deve andare oltre i classici "breackpoint", ma può essere applicato a siti che normalmente sono visualizzati solo da pc o portatili (come le intranet).
Il responsive design quindi deve aiutarci in ogni occasione a rendere le nostre pagine web visibili in modo ottimale per tutte le risoluzioni.

Il nuovo sito di Cyber Duck e il suo ottimo case study @Cyberduck_uk #responsive @DuckyMatt #rwd

Non si trovano spesso degli esempi ragionati su approcci innovativi, molte volte la sperimentazione prende il sopravvento sulla necessità, e a me questo non piace.
Mi preve invece segnalarvi questo ottimo step-by-step che prende in considerazione gli aspetti più importanti dell’approccio responsivo e ne analizza tutti i risvolti, con risultati incredibili.

http://mobile.smashingmagazine.com/2013/06/18/adapting-to-a-responsive-design-case-study/

Non è un tutorial e non è adatto ad ogni caso (ad esempio l’agenzia elimina il Cms per gestire le pagine e lo tiene solo per il blog), ma la cosa interessante è l’approccio oggettivo, freddo e calmo ai problemi.
Anche le soluzioni sono fantastiche, ma se ci guardate dentro sono semplici e immediate. Ma soprattutto alla portata di tutti.

A voi la parola!

Come può cambiare il ruolo delle immagini nell’approccio #responsive #rwd

Sembra che il problema maggiore nell’approccio responsive sia gestire le immagini e il loro peso. Soprattutto nei moderni design diamo molto spazio ad immagini grandi e con buona risoluzione. Questo ovviamente è un problema quando le nostre pagine web vengono visualizzate in modalità responive su un device mobile con connessione 3G.

Ci sono vari metodi per servire immagini con risoluzione e peso inferiori rispetto alla versione originale per desktop ma ancora nessuna risolve il problema in modo definitivo anche perchè alcune richiedeno codice server side, quindi non di immediato approccio.

Una tecnica che mi ha fatto molto riflettere però è stata quella che prevee di gestire le immagini tramite Css. E non parlo solo di dimensioni e posizionamento, ma anche di sorgente.

Nell’articolo seguente http://mobile.smashingmagazine.com/2013/07/22/simple-responsive-images-with-css-backgrounds/ vengono illustrate delle ottime tecniche per indicare via css quale immagine caricare in base alle media-query. La tecnica funziona, ma ha un problema fondamentale: le immagini vengono eliminate dal contenuto (quindi dal markup) ed inserite via css quindi lato presentation.
Nell’articolo si fà proprio riferimento a questo limite e si parla di come per anni la comunità web abbia lottato per dividere contenuto da presentazione.
La discussione è corretta, ma mi chiedo (stimolato da questo articolo): quando le immagini sono davvero un contenuto e quando possiamo considerarle pura presentazione?

Immagino che per un portfolio di un fotografo o per un ecommerce le immagini siano fondamentali e devono essere inserite nel flusso del markup quindi visualizzate anche senza Css. Ma per un sito corporate molte volte inseriamo delle immagini (in header o nel corpo testo) per dare dinamismo alle pagine e renderle meno statiche e monotone.

Allora perchè questo tipo di immagini non considerle alla stessa stregua di un’icona o un background di pagina? Quindi perchè non considerarle solamente presentation?

Bel lavoro per il sito #Coin @coinstore #webdesign #responsive #rwd

Segnalo con piacere l’ottimo lavoro fatto sul sito Coin:

http://www.coin.it/

Design originale, colori calzanti e layout moderno. A questo si aggiunge una buona tecnica responsive e altri accorgimenti js come la preloading bar per ogni pagina, in stile youtube. Per chi non la conoscesse, nè ho già parlato tempo fà in due post:

http://tmblr.co/Z_qdaywPRRJu

http://tmblr.co/Z_qdayomDmK1