Vantaggi delle applicazioni HTML in una intranet di Windows

5

Sto preparando una presentazione per il mio team che elenca le varie tecnologie che potremmo utilizzare oggi per le nostre applicazioni aziendali.

Abbiamo storicamente sviluppato applicazioni HTML (ASP e ASP.net) nell'ultimo decennio e, come parte dell'introduzione, volevo spiegare perché siamo passati da applicazioni Windows a HTML.

Il nostro ambiente è:

  • Applicazioni aziendali (OLTP principalmente)
  • Intranet
  • Solo client Windows
  • Controllo completo sulla configurazione dei client (versione del sistema operativo / versione del browser / distribuzione dei plug-in ...)

L'unica ragione per cui ho trovato è che alla fine degli anni '90, la distribuzione di un'applicazione client Windows poteva finire in un pasticcio (molte versioni differenti implementate, dll hell ...). I server Web hanno consentito di distribuire l'applicazione una volta e di avere tutti i client aggiornati contemporaneamente. Il prezzo da pagare era una grande perdita di facilità d'uso, reattività e complessità aggiunte al lavoro di sviluppo.

Oggi ci sono alternative (ClickOnce, Silverlight ...) ma molti dei miei colleghi sono ora totalmente impegnati nell'HTML e nelle tecnologie che vengono (Javascript / Ajax / Jquery / Css ...).

Sono assolutamente convinto che l'HTML sia ottimo per le applicazioni Internet. La mia domanda è: in quel momento (alla fine degli anni '90), c'erano altri motivi per passare all'HTML in un ambiente intranet di Windows piuttosto che correggere i problemi di distribuzione? (perché era trendy non è una risposta valida ...)

Grazie in anticipo

    
posta vc 74 18.01.2011 - 13:51
fonte

4 risposte

6

Spero che da un decennio tu abbia una litania delle tue stesse ragioni. In genere, un sito intranet sostituisce meglio una classe di applicazioni nota come client / server. Ci sono alcune applicazioni che non fanno la transizione. Le seguenti sono le mie ragioni per promuovere una intranet su un'applicazione desktop:

  • La storia della distribuzione. L'inferno della DLL è solo la punta dell'iceberg. Quando si hanno migliaia di client su più fusi orari e persino confini nazionali, coordinare una versione client / server è molto scoraggiante. L'aggiornamento di un cluster di server elimina tutti questi problemi.
  • Le app client / server sono molto più complicate di una soluzione di tutti i server. Devi gestire la compatibilità del client con versioni non corrispondenti. Se si sta risolvendo un bug grave, non si può fare per lavorare con i client precedenti, è necessario fornire un messaggio di errore che l'utente medio possa capire. Anche i problemi di sincronizzazione dei dati diventano più complessi, in particolare quando non si ha il controllo su tutti gli orologi di sistema.
  • Il Web è più malevole e gli utenti tendono ad essere più aperti a modi innovativi di interagire con un sito Web rispetto a quelli presenti nelle applicazioni desktop. In un certo senso, le aspettative sono meno rigide per un'applicazione web che per un'applicazione desktop. (le aspettative degli utenti esistono ancora, attenzione).
risposta data 18.01.2011 - 14:05
fonte
2

Ok, penso che tu stia chiedendo una cosa, ma vuoi sapere la risposta a un'altra. Quindi per favore correggimi se sto fraintendendo le tue intenzioni.

Ti stai chiedendo perché l'HTML sia stato scelto come piattaforma di sviluppo preferita dieci anni fa, ma sembra che tu stia chiedendo se HTML sia ancora una piattaforma utile per la distribuzione delle applicazioni ora.

Un decennio fa si parlava molto di tutto ciò che si muoveva verso il cloud. Le ASP erano la proprietà hot (che è Application Service Provider, non ActiveServer Pages) e potrebbe essere semplice come qualcuno della tua azienda che vuole essere esposto alla prossima cosa bollente. Le risposte di Berin sopra sono anche buone ragioni;) Il problema è che, se non lo sai, non lo sai, quindi non importa.

Se stai chiedendo se si tratta ancora di una piattaforma valida e appropriata, beh, dipende interamente da ciò che stai tentando di offrire. Se chiaramente fallisce da qualche parte nella tua organizzazione, o se puoi vedere un bisogno o beneficio che qualche altra tecnologia può riempire, dovresti essere in grado di formulare un caso tecnico, anche se non puoi renderne uno finanziario.

Quindi, ragioni per usare qualcosa come WPF, ti dà un'esperienza utente davvero ricca, rende facile cooptare le risorse locali, e un'applicazione WPF continuerà ad essere eseguita su un laptop mentre l'utente è su un treno che va attraverso un tunnel.

Ian

    
risposta data 18.01.2011 - 14:22
fonte
1

Dovresti ricordare che, alla fine degli anni '90, il mondo di Windows era un po 'frammentato. Avevi le versioni basate su DOS 95 e 98, prive di stabilità e sicurezza, e avevi NT, con alcuni problemi di compatibilità (driver, software basato su DOS che vuole possedere la macchina, ecc.). La grande unificazione, cioè Windows XP, doveva ancora venire.

In quella situazione, non era irragionevole piazzare le tue scommesse su una tecnologia che non si sarebbe rotta con le nuove versioni di Windows.

    
risposta data 18.01.2011 - 14:13
fonte
1

Il supporto dell'applicazione è molto più semplice quando è basato sul web:

  • È impossibile per gli utenti utilizzare ancora una vecchia versione del software;
  • Le installazioni software danneggiate sono impossibili;
  • I problemi software sono raramente causati da problemi del sistema operativo.

Il primo punto è ovviamente un problema di distribuzione. Il secondo potrebbe essere un problema di distribuzione (ad esempio, il pacchetto danneggiato viene inviato). Tuttavia, potrebbe anche essere causato dagli utenti ("A corto di spazio ... lo so, eliminerò alcuni file!") O dal sistema operativo ("Cambierò le autorizzazioni a caso su un mucchio di file perché io" m Windows XP, ed è proprio quello che faccio ").

Quest'ultimo esempio ci porta al terzo punto: i problemi del sistema operativo. Potrebbero includere:

  • Le autorizzazioni per parti dell'applicazione vengono manchiate;
  • Il registro viene danneggiato e l'app smette di funzionare;
  • Le impostazioni utente vengono eliminate / danneggiate e l'app smette di funzionare come previsto;
  • I collegamenti vengono cancellati / spostati e l'utente non può più trovare l'applicazione;
  • Problemi di rete. Contrasto "Il programma carica ma non mostra i miei dati" con "Non riesco ad aprire il sito web, o anche Google" dal punto di vista dell'assistenza: uno è ovviamente un problema di rete, mentre l'altro potrebbe essere qualsiasi cosa; / li>
  • DLL di sistema essenziali richieste dall'applicazione scompaiono;
  • L'utente installa Super Malware 3 Turbo che assorbe il 100% del tempo e della memoria della CPU, facendo rallentare l'applicazione in modo casuale e casualmente.

Ci sono dozzine di cose che possono andare storte con Windows che possono influire sulle prestazioni e sulla stabilità della tua applicazione. Gli utenti di solito si lamentano del tuo software se si blocca tutto il tempo, anche se è colpa loro installare junk sui loro PC. D'altra parte, se il loro browser web non funziona correttamente, il tuo sito web è chiaramente non la causa del problema.

Anche il software Web può essere più economico. Il software desktop ha requisiti hardware / software più ampi: "Deve avere 2 GB di RAM, deve funzionare con Windows 7. Deve avere una CPU da 2 GHz. Deve avere la scheda grafica Whizzy XY." Il software Web ha un solo requisito: "Deve avere un browser web". (Oppure, se non lo hai fatto correttamente: "Must have IE6.")

Un altro vantaggio è la migrazione degli utenti tra computer. Supponiamo che un computer si rompa e che le impostazioni dell'utente siano state memorizzate nel registro. Come si trasferiscono queste impostazioni sul nuovo computer? Confrontalo con l'esperienza web - accedi allo stesso programma da qualsiasi computer dell'azienda e le tue impostazioni magicamente riappaiono (sono memorizzate nel database).

    
risposta data 18.01.2011 - 14:43
fonte

Leggi altre domande sui tag