Approccio dall'alto verso il basso o dal basso verso l'alto?

Question

Approccio dall'alto verso il basso o dal basso verso l'alto?

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

1

Sono un designer di interfacce e ora sto lavorando con un team di programmatori per sviluppare un nuovo CMS per un sito di supporti pesanti.

Come ho iniziato a sviluppare un elenco di specifiche per un prototipo, ne è uscito uno molto grande. Mi rendo conto ora che il lato client sarà pesante per JS, con tanto di DnD e altri "fantastici progetti di designer". Il CMS includerà anche un piccolo sistema di gestione dei progetti per i suoi utenti, niente di grosso come Basecamp, ma con un feed dal vivo di commenti, ecc.

Il problema è che la squadra ora si è separata. Qualcuno sta proponendo la soluzione di back-end esistente utilizzata in altri CMS, qualcuno sta proponendo di riscrivere tutto da zero. Il punto per mantenere il codice è che è più veloce, il punto da riscrivere è quello di renderlo migliore per il design proposto (includi Node.js e altre cose che in realtà non ottengo).

La domanda è: le specifiche dell'interfaccia utente possono influenzare il back-end? I ragazzi che propongono di utilizzare la soluzione esistente hanno fatto tutto con il framework Yii (per quanto ne so), e dicono che tutto ciò che si trova sul server non è influenzato da questa "freddezza dell'interfaccia". Altri dicono che lo fa, che anche il salvataggio automatico non può funzionare senza carico del server.

websites

posta george_zakharov 13.12.2012 - 00:13

fonte

3 risposte

Leggi altre domande sui tag websites

API DB per lo scripting di shell (qualsiasi shell) Estensione dell'interfaccia

score 2 · Answer 1

Hai menzionato 2 diversi casi d'uso, ognuno con una risposta diversa

Per prima cosa, voglio sottolineare che il framework lato server è irrilevante se i dati vengono esposti tramite un'API REST perché i dati verranno probabilmente prelevati tramite richieste AJAX comunque.

Top-Down se si progettano nuove interfacce:

Le API sono generalmente definite sulla base di casi d'uso reali. Dovrebbero solo esporre un numero limitato di percorsi per accedere ai dati e quelli diretti dovrebbero essere definiti in base a come verranno utilizzati. In caso di aggiunta di nuove funzionalità, sarebbe probabilmente più semplice prendere in mano il layout generale per avere un'idea migliore di come verrà utilizzato.

Bottom-Up per interfacce esistenti:

Non penso di aver bisogno di entrare nei dettagli su quanto sarebbe stupido progettare tutte le funzionalità esistenti se hai già un'implementazione funzionante. Ci sono un sacco di articoli online e esempi reali che dimostrano che l'investimento tempo / energia se una piena riscrittura di solito non vale la pena (ex PERL 6).

Anche se gli sviluppatori di back-end decidono di utilizzare un framework diverso, è molto più semplice adattare le implementazioni esistenti a una nuova piattaforma / framework / linguaggio piuttosto che a draftarne di nuove. Non dimenticare di considerare il significativo investimento nel tempo che è andato in battaglia per testare le implementazioni esistenti.

La chiave per adattare il codice esistente è identificare e rimuovere le parti non necessarie. Fatto ciò, in che modo l'interfaccia utente può essere progettata per incorporare la funzionalità esistente.

score 1 · Answer 2

Dall'alto al basso di sicuro.

L'interfaccia utente o UX è molto più vicina all'utente e ciò che l'utente si aspetta dell'applicazione. Come l'utente lavora con l'applicazione dovrebbe determinare cosa è richiesto dal back-end.

In un modo potresti vedere un design UX come una sfida di back-end, è compito dei backend comunicare se possono o non possono consegnare.

Con i loro vincoli imposti, il design UX potrebbe dover fare concessioni e adattarsi. Cerca sempre la soluzione migliore e abbassa la barra solo quando è necessario. Non speculare su ciò che il backend potrebbe trovare troppo difficile o no. Lascia che ti dica.

Se hanno già un codice esistente significativo sul ripiano, basta parlare con i tuoi disegni e vedere cosa possono sostenere. Tornate sempre ai vostri clienti / stakeholder per le decisioni, anche se qualche compromesso sull'usabilità può risparmiare un po 'di lavoro potrebbe non essere quello che vogliono. Potrebbero insistere sul percorso più costoso se vedono un valore in esso.

score 0 · Answer 3

Il design ideale sarebbe quello in cui frontend e backend sono così completamente strutturalmente indipendenti che ogni squadra può concentrarsi sui propri punti di forza senza necessariamente piegarsi per placare l'altro. Questo è l'obiettivo, ma in genere non è realistico.

Per il resto di noi nel mondo reale, ecco la tua regola empirica per aiutarti a stabilire le priorità in modo appropriato: inizia con ciò che conta di più . Se la prestazione è la tua caratteristica chiave di guida, inizia con le prestazioni. Se l'efficacia dell'interfaccia utente è la caratteristica più importante, inizia con l'interfaccia utente.

Le decisioni che contano di più dovrebbero essere prese con tutte le opzioni possibili a te aperte. Tutte le altre decisioni saranno quindi prese nel contesto di queste "importanti" decisioni.