Sviluppo di siti Web che imitano le app desktop. Come combattere questo paradigma? [chiuso]

Sembra che il problema di fondo sia un errore di adattamento. Sarà difficile convincerli che dovrebbero anche loro. Penso che la tua migliore scommessa sarebbe una combinazione di cose:

1. Indica le applicazioni web di grandi aziende (Google, Microsoft, ecc.)
2. Fai un buon elenco di punti sulla differenza tra le app desktop e le app Web e perché non dovrebbero provare ad agire allo stesso modo
3. Se tutto il resto fallisce, fai un piccolo esempio di programma. Dimmi, una sostituzione del blocco note. Rendi lo stile "desktop sul Web" e rendilo nel tipico stile di web-app. Mostra ai tuoi capi perché le persone hanno maggiori probabilità di utilizzare lo stile dell'app Web.
4. Infine mostra loro che le app web sono come sono per un motivo. È più economico in più modi. Richiede meno tempo per lo sviluppo (fingere che HTTP sia un protocollo di stato è una tale perdita di tempo), meno risorse da eseguire e i tuoi clienti sono più propensi a pagare per qualsiasi cosa tu stia vendendo.

Alcuni punti di partenza per # 2:

• È fisicamente impossibile sapere con certezza che un cliente abbia lasciato la tua app web. HTTP è senza stato. Puoi fare sondaggi, ma non è grandioso.
• Le app Web non richiedono installazione. Questo è uno dei loro più grandi punti di vendita. Non muck questo richiedendo un login per cose che non lo richiedono.
• È fisicamente impossibile sapere con certezza quale dimensione della finestra del browser ha l'utente. Ecco perché i layout fluidi sono così buoni, si adattano dinamicamente a qualsiasi dimensione della finestra sia automaticamente. In confronto, l'approccio desktop-style è di solito un layout fisso in cui si è praticamente privi di spazio sullo schermo sprecato senza una buona ragione.
• Con le app Web, è molto probabile che qualcuno stia utilizzando un sistema operativo diverso da Windows per accedere al tuo sito web. Dovresti sforzarti di usare font comuni e non fare affidamento su font proprietari a meno che tu non abbia un font di failback che sembri decente.
• HTTP è senza stato. Più fai finta che non lo sia, più risorse hai bisogno per renderlo "vero". Nella parte più alta, significa fondamentalmente per ogni richiesta al tuo sito web, dovrai inviare tutti i dati da ogni richiesta al tuo sito web dall'ultima visita. Internet sta diventando sempre più veloce ei server più potenti, ma perché comprare un guzzler di gas da 5 miglia al gallone per 80.000 dollari quando una macchina da 40 miglia al gallone più bella fa la stessa cosa con meno.
• Gli utenti odiano essere disturbati. Se il tuo sito web è di stato e stanno per comprare qualcosa e premere accidentalmente il pulsante Indietro del browser invece del pulsante di proprietà dell'utente, ciò potrebbe farli ricominciare. È probabile che porteranno altrove i loro affari piuttosto che occuparsi di trovare nuovamente il prodotto, inserire le informazioni e effettivamente acquistare il prodotto
• Dovrebbero assolutamente facilitare la capacità degli utenti di condividere URL per i loro contenuti! Questo è probabilmente il punto più importante. Che cosa è più facile "ehi vai a questo URL e guarda questo" o "ehi vai a questo URL e poi fai clic su cerca, quindi digita" super bacon cooker "e poi fai clic sul terzo risultato, il super bacon cooker XL e prendi un guarda ".... Puoi indovinare quale di questi processi un utente mai fare? Vuoi pubblicità gratuita o no?

Da nessuna parte nella tua domanda menzioni l'utente finale. Tutte le domande come "dovremmo usare il design A o il design B?" dovrebbe iniziare con le esigenze degli utenti. Sono felici e produttivi con i progetti attuali, o sono quelli che chiedono questi cambiamenti?

Molto di ciò che hai citato può essere usato sia in app di successo che in quelle non riuscite. Prima di provare a cambiare le cose, assicurati che le modifiche migliorino l'esperienza dell'utente. Se lo schema attuale funziona per loro, perché cambiare? Se stai pensando "I think questo migliorerebbe l'esperienza dei miei utenti", questa è la risposta sbagliata. Devi fare solo un piccolo studio sull'usabilità di pochi utenti reali, quindi puoi tranquillamente dire "I sapere questo migliorerebbe l'esperienza dei miei utenti".

Se vuoi cambiare la mentalità della tua squadra, fagli capire che a) riguarda esclusivamente gli utenti, e b) gli utenti non vengono serviti dai progetti attuali. Se non sono d'accordo con uno di questi punti, sarà difficile convincere qualcuno.

C'è un cambiamento di paradigma nell'industria del web. Il termine SPA (applicazione a pagina singola) sta diventando sempre più di trazione ogni giorno, poiché grandi progetti / startup continuano a produrre incredibili app web ogni giorno che passa.

Dato che il web sta cambiando costantemente e velocemente, abbracciare il web è un termine impreciso IMO. La vecchia sincronizzazione. richiesta-risposta con carichi a pagina intera utilizzando HTML viene sostituito da json su async. richieste.

Ora ci sono due tipi di "cose" sul web: siti web e app web. Ognuno di loro ha i suoi pro / contro.

programmers.SE è un sito web. Non è necessaria la funzionalità "app", poiché il concetto di "sito web" è già utile per una rete di controllo qualità.

D'altra parte, Basecamp (software di gestione progetti online) è un'app web. Il modo tradizionale dei siti Web, che include pagine separate per tutto, carichi di pagine complete, ecc. Non si adatta veramente a un software di gestione dei progetti. Invece, utilizzando il modello SPA, si dispone di un software che può essere utilizzato con un browser Web, con la potenza di un'applicazione desktop. Il meglio di entrambi i mondi.

Il problema è, come sempre, dovresti scegliere il tipo, il sito web o l'app web adatta al tuo prodotto. Porta l'esperienza dell'utente finale al fronte quando prendi decisioni.

Li indirizzerei verso le app Web di successo delle grandi aziende che hanno sfruttato il formato web invece di attenersi a quello desktop. Wordpress mi viene in mente. Anche le app aziendali di Google.

Ovviamente vogliono che le loro applicazioni web si comportino proprio come le app desktop. Vuoi convincerli a rinunciare a tutto questo, anche se sono disposti a pagare qualcuno per farlo funzionare.

Ora se si aspettano che tu sviluppi questo con la stessa quantità di tempo e la stessa quantità di prestazioni allo stesso prezzo, hai una discussione. Finché sono a conoscenza di ciò che ottengono per quello che pagano, dovresti consegnare. Se pagassi il software e i miei impiegati volevano tutte queste campane e fischietti extra a mie spese, sarei quello che si lamentava e non i programmatori.

Hai sicurezza sul lavoro amico mio. Nessuno ha detto che sarebbe stato facile.