Mantenere il "codice" lontano dai progettisti?

Vuoi liberare il tuo Front End Designer dal codice? Vuoi velocizzare l'integrazione? Vuoi utilizzare le tecniche professionali utilizzate dai siti web più intelligenti? Di gran lunga, lo strumento migliore per questo è:

Colore.

Sì, dipingi. Bene, qualche programma di disegno comunque. Lascialo prendere schermate del tuo sito, spostare oggetti e aggiungere cose che trova altrove. Questo gli permetterà di lavorare alla velocità delle sue idee e ti permetterà di piegare il codice in qualsiasi forma che funzioni meglio per te, dandogli ciò di cui ha bisogno.

Se è ancora troppo lento, dì perché il cliente è nella stanza con entrambi, ti consiglio un set di strumenti molto più avanzato:

Carta, forbici e nastro.

Forse una penna se ti senti ambizioso.

Ho usato questa tecnica per prendere decisioni con successo sul tema, lo stile, i contenuti e le principali caratteristiche di un sito a un tavolo in un Panera Bread con un cliente prima che qualcuno si rendesse conto di aver finito di mangiare.

Questo lo renderà veloce, ti libererà dal suo "codice", ed è in realtà il modo più potente per sviluppare un'interfaccia utente. Può iniziare a fare test di usabilità prima di aver scritto una riga di codice.

Potresti pensare "oh questo va bene quando si inizia, ma non lo usi una volta che il sito è stato sviluppato". Non vero. Funziona altrettanto bene su siti stabili. Ma ora la maggior parte delle schermate proviene dal tuo sito.

Che cosa succede se il tuo Front End Designer desidera utilizzare alcuni strumenti per la generazione del codice per realizzare il suo mock up? Bene, ma non pensare per un secondo che devi usare il suo "codice". Quello che devi rispettare sono le sue decisioni su aspetto, flusso e presentazione. Quello che succede dietro il sipario perché ciò accada non è la sua area di competenza. È tuo. Assumiti la responsabilità per questo.

Rispetta solo il suo lavoro abbastanza che quando hai finito gli mostri come è andata a finire. Lascialo nitpick tutto ciò che l'utente potrebbe provare. Preparati ad essere colpito da nuove idee.

Questo è uno sviluppo iterativo. Non fare molto prima di chiedere. Fai il meno possibile Chiedi più spesso che puoi. Metti i giocattoli sulla tua scrivania per tenerlo divertito mentre implementi la sua ultima idea in modo che possa rivederlo non appena si carica. Continua così fino a quando è il momento di incontrare il cliente.

Se il codice prodotto dal Front End Designer vale la pena, devi imparare a integrare il tuo codice con il suo. Per questo ti consiglio vivamente di imparare il controllo del codice sorgente . Impara così bene che puoi insegnare al tuo Front End Designer come usarlo.

Solo una volta che entrambi puoi usare in modo affidabile uno strumento di controllo del codice sorgente, ti consiglio di basare il tuo piano di integrazione sulla fusione del codice. A questo punto il tuo amico meriterebbe un cambio di titolo da Front End Designer a Front End Developer.

Ora, anche se lo fai, non mi sorprenderebbe se la tecnica dei dickling sullo schermo non risultasse ancora il modo più veloce per voi due di collaborare.

Forse non puoi prendere il caos di tutti questi cambiamenti. Sta creando troppo lavoro. Beh, si chiama software perché accetta il cambiamento. Altrimenti avremmo un ingegnere elettrico farlo su un chip specializzato. Potrebbe essere necessario reachitect per spostare la logica di comportamento fuori dall'interfaccia utente in modo che le modifiche dell'interfaccia utente non influiscano le tue regole di base. Se acceleri il tuo Front End Designer, devi essere pronto a seguirli.

L'unica buona ragione per forzare un Front End Designer a produrre codice è perché sei stanco e vuoi rallentarlo. Beh, immagino che non sia davvero una "buona" ragione.

In termini di strumenti, il flusso di lavoro ottimale che vedo è l'utilizzo di Sketch e Zeplin. Sketch è uno strumento di progettazione diretto. Equivalente a Photoshop o InDesign, ma ottimizzata per la progettazione di app e siti Web. Zeplin è uno strumento per condividere e approvare i disegni in Sketch (o Photoshop). Può dare precise misurazioni di pixel e persino frammenti di codice per CSS o altro codice di layout ed esportare risorse grafiche. Una volta che un disegno è impostato, viene consegnato allo sviluppatore. A questo punto, lo sviluppatore lo preleva e costruisce l'interfaccia utente. Quindi può tornare al progettista per il QA visivo. Tutto ciò che trova sbagliato in esso, dovrebbe essere registrato come un bug da stabilire come prioritario e risolto da te.

when something doesn't work out as intended (like for example, it didn't work out as we planned for some reason), I fix the issue on my side, then send him the template back

Questa è la radice dei tuoi problemi. Il flusso del design dovrebbe sempre essere da Designer to Developer e mai invertito. Revisioni e modifiche avrebbero dovuto essere apportate dal progettista e quindi inviate all'utente per l'implementazione nel sito Web. Puoi sempre apportare velocemente le correzioni, ma cerca di accettare che quelle correzioni rapide siano solo temporanee. Il progettista deve tornare ai suoi progetti e capire la soluzione adeguata. Poi ti spinge il cambiamento, e se è lo stesso della tua soluzione rapida allora è grandioso, altrimenti ti aggiorni dai suoi disegni.

He sends the complete template to me (the HTML export from Pinegrow)

Non diventare dipendente dalla ricezione di HTML con cui puoi lavorare. È meglio implementare la tecnologia del sito Web (Bootstrap, CSS, jQuery, React, PHP, ecc. Ecc. Ecc.) Nel modo in cui ne hai bisogno. Quindi riproduci i suoi disegni usando quegli strumenti. Se l'HTML che ti dà è un avvio rapido quindi ottimo, ma più tardi man mano che il progetto cresce, non sarà molto utile. Dovrai apportare tu stesso le modifiche perché solo tu comprendi il tuo motore dei modelli (ad esempio viste CakePHP, modelli, plug-in, componenti, ecc. Ecc.)

This process, as one could imagine is painstakingly slow and inefficient.

È sempre stato così. I designer non sono programmatori. Si prendono il loro tempo per capire cosa funziona meglio per l'utente, ea volte commettono errori. Non capiscono concetti come componenti, strutture e così via. Come programmatore devi parlare con il tuo designer e condividere il come implemento ciò che disegni .

Il designer è bloccato nel mezzo. Da un lato devono soddisfare le esigenze del programmatore e dall'altro devono soddisfare le esigenze dell'utente.

So my question is, how can we make this process go smoother?

Ho scoperto che sedere fisicamente accanto al designer e programmare ci aiuta molto nella comunicazione. Se voi due state lavorando in remoto, quindi mantenere in esecuzione facetime per alcuni giorni. Aiuta davvero a velocizzare le cose.

I've seen a lot of stuff about that we should use React and use RESTful and what not, but we want to use CakePHP for it.

CakePHP è uno dei migliori framework del pianeta (completa divulgazione, sono nel core team di CakePHP).

Cake è un framework di sviluppo per conigli in cui le funzionalità sono progettate per creare rapidamente siti Web. So che suona come un passo di vendite, ma questo è ciò che è classificato come. Ci sono molti altri quadri classificati come conigli. Java sarebbe un esempio di un framework che è più un'impresa che un coniglio. Se tu stavi usando quella lingua, allora avrei fatto una raccomandazione per cambiare. Dal momento che stai usando CakePHP. Direi che dovresti stare con esso.

CakePHP è un buon server di back-end se hai bisogno di API RESTful.

React / Angular / Vue sono tutti i framework front-end popolari e di tendenza, ma non sono mai esistiti da molto tempo. CakePHP d'altra parte è in giro da 13 anni. Il mio punto non è una critica. È il fatto che queste librerie JavaScript hanno una breve durata. Tra 5 anni parleremo di qualcosa di nuovo, ma sospetto che CakePHP sarà ancora in circolazione.

Quindi dico. Usa React / Angular / Vue ora mentre sono caldi, ma non ti impegnare. Qualcosa di nuovo e migliore sarà a breve. Penso che viviamo in un mondo in cui non puoi costruire buoni siti web senza di loro.

Could some people guide me to some helpful resources about it?

Le richieste di liste sono fuori tema qui. Siamo spiacenti.

Modifica :

Ho perso la parte relativa al monitoraggio delle modifiche al design.

Chiedi al tuo designer di salvare il suo output HTML in BitBucket (hanno repository privati gratuiti). Puoi quindi tracciare e fare confronti usando il sito web di BitBucket. Ogni volta che il progettista apporta un grosso cambiamento, aggiunge un nuovo ramo con un numero di versione.

Dovrebbe essere relativamente facile per lui farlo, e questo ti permetterà di avere un posto dove commentare le suddette modifiche. Per esempio; può fare una richiesta di pull per aggiornare il repository in cui si esegue una revisione delle modifiche prima che vengano unite.

Devi separare queste due cose:

1. UX e amp; Progettazione dell'interfaccia utente, un'attività non codificante
2. Implementazione, sicuramente un'attività di codifica

Il designer deve utilizzare strumenti creativi come Marvel che sono solo per la progettazione. Non dovrebbe essere la preoccupazione del designer di fare qualsiasi cosa con codice, HTML, CSS ecc. I colori, le dimensioni, l'estetica, le interazioni, le animazioni sono tutte le cose su cui dovrebbe concentrarsi.

Il programmatore dovrebbe ricevere le risorse e il modello (con interazioni e animazioni) e dovrebbe farlo avvenire programmando il software. Questo includeva anche HTML e CSS. Il programmatore può anche usare gli strumenti di generatore dalla sua parte.

Per accelerare il flusso di attività, ti consiglio di utilizzare uno strumento minimo come Trello e collegare / documentare tutto per ogni unità di lavoro.

how can we make this process go smoother?

Esegui il controllo della versione

Software Branching and Parallel Universes

• Lavora senza codice non nel controllo di versione. punto. E intendo andare in sciopero finché il progetto non è tutto in un VCS.
• Branch formalmente, liberamente, localmente
  • Formalmente: ramificazioni per rilasci e sotto-parti di rilasci, correzioni di test formali, ecc. Evolvere un piano di controllo di versione formale, ad esempio scriverlo.
  • Liberamente: oltre la numerazione delle versioni formali in 4 parti, diramata se il tuo istinto ti dice che potrebbe essere una buona idea.
  • Localmente: ho mantenuto un repository personale con rami mai intesi per il consumo della squadra perché in una squadra non ci siamo schierati all'inizio, e spesso ho esperimenti, esplorazione, per ogni evenienza, ecc.

Ingegnere delle API middleware

I vantaggi:

• Stabilità - anche quando il codice sottostante si sta evolvendo.
• Codice verificabile
• Riutilizzo
• Uno strumento di comunicazione del team
• È un contratto. Una promessa di servizi resi (gioco di parole)
• Coding nel regno di SOLID == programma di manutenzione felice

È chiedere, non dire principio applicato in modo ossessivo e compulsivo come dovrebbe essere. Se l'interfaccia utente sta manipolando una singola proprietà del livello aziendale, è sbagliato.

Tutto e qualsiasi sugli oggetti di business devono essere contenuti in detti BO. Anche cose banali che potrebbero sembrare migliori nell'interfaccia utente - anche una singola LOC. Minuita come l'aggiunta di 2 valori forniti dall'utente - tutte le logiche associate compresa la convalida devono essere nell'API del livello aziendale. La ridondanza IMO a volte è OK. Per mitigare la ridondanza, è possibile che gli oggetti del livello aziendale siano piccoli e mirati a cui è consentito l'accesso completo all'interfaccia utente.

Tutto e qualsiasi le esigenze dell'interfaccia utente dagli oggetti business devono essere API. Ad esempio, sono disponibili metodi espliciti che collegano i relativi argomenti ai gestori di eventi.

Attenzione ai framework come stampella

Nelle mani dei non specializzati, i framework e gli IDE non sono barriere per i mostri dei film B che creano.

Con framework come React si potrebbe dire che è tutto lato client, non esiste un livello di business logic back-end. L'idea chiave qui è di disaccoppiare ciò che l'utente vede da ciò che fa il programma. È fattibile.

Penso che sia un buon indicatore dell'immaturità per professione e pratica che accettiamo che le persone che progettano, non possono fare.

Questo non sarebbe accettabile in quasi tutte le altre professioni.

È ragionevole aspettarsi che un designer specializzato nel design di siti Web / app conosca CSS e HTML abbastanza bene da fornire file funzionanti e utilizzabili di quel tipo.

Designer che fornisce gli editor grafici WYSIWYG sono designer visivi o grafici. Ci sono molti diversi tipi di designer.

Tuttavia ci sono anche molti diversi tipi di livelli di abilità, abilità ed esperienze. Chi progetta mobili può farlo solo su un computer con strumenti di progettazione 3D, nel qual caso la loro conoscenza di come girare un tornio o utilizzare un router CNC potrebbe essere del tutto teorica. Fanno i loro disegni e poi li spediscono per essere fatti da altri.

Al contrario, alcuni progettisti esperti possono avere il controllo dell'intero processo e avere l'abilità e le conoscenze per costruire i loro mobili con un occhio per ogni dettaglio, magari anche a mano.

Non sarai in grado di convincere il tuo amico a cambiare il modo di lavorare. Se preferisci avere un web designer con le competenze HTML e CSS per creare i propri progetti, dovrai trovarne uno.