Controllo WebBrowser come interfaccia utente

Question

Prima alcune definizioni per mantenere le cose chiare.

utente: una persona dal vivo, utilizzando il software

Cliente: Una società che sta pagando per una versione personalizzata del nostro software per i loro utenti.

Attualmente sono disponibili alcune applicazioni che richiedono modifiche significative nell'interfaccia utente in base al client a cui appartiene l'utente. Al momento disponiamo di una build separata per ogni cliente, ma con l'aumento del numero di clienti, è sempre più difficile gestire tutte le versioni separate.

Il mio obiettivo è passare a un singolo client generico che può essere personalizzato dinamicamente in base a chi effettua l'accesso. Poiché il nostro software richiede comunque una connessione Internet (utilizza ampiamente i servizi Web) stavo pensando di utilizzare solo un controllo WebBrowser in .NET. e permettendogli di interagire (tramite ObjectForScripting) con l'hardware richiesto sul computer.

Quindi l'intera interfaccia utente è scritta in HTML/JavaScript e memorizzata sul server rendendo banale la distribuzione e la manutenzione di nuove interfacce utente. Il client generico è poco più di un browser Web personalizzato che sa come parlare con i nostri dispositivi hardware e può essere detto di farlo tramite javascript.

Vedo molti vantaggi a questo approccio e non troppi svantaggi. Cosa mi manca? Perché non dovrei andare in questa direzione?

Answer 1

Ci sono alcune applicazioni commerciali là fuori che utilizzano questo approccio con successo. Di seguito sono riportate alcune considerazioni da tenere a mente. Questi non dovrebbero impedirti comunque di tentare l'approccio. Una domanda chiave da porsi, tuttavia, è se l'app potrebbe essere invece un'app web nativa.

• Il controllo del browser Web "mangia schede". Puoi utilizzare il tasto Tab per spostare lo stato attivo nel controllo browser dall'applicazione di hosting, ma non puoi escluderlo (a meno che non lo specifichi esplicitamente)

• Le app HTML/Javascript sono a thread singolo. Se è necessaria un'elaborazione in background, potrebbe essere necessario delegare tale attività all'app di hosting.

• Se si verificano condizioni di errore all'interno del controllo del browser Web, vengono trattate come errori di script e contenute nel controllo. Il contenimento è una buona cosa. Ma potresti anche non realizzare che si è verificata una condizione di errore durante la creazione/debug.

• Se non c'è connettività di rete, gli utenti visualizzano la pagina di errore del browser. Non puoi prevederlo e mostrare il tuo messaggio.

• A seconda dell'applicazione e del modo in cui viene implementata, la navigazione può sembrare più lenta di quanto non sia comune nelle app desktop. La pagina si ricarica in particolare. L'attento utilizzo dell'AJAX asincrono può contribuire ad alleviare alcuni o tutti.

• Gli utenti sapranno che stanno lavorando con una pagina web. Il design dell'interfaccia utente da solo non sarà in grado di nascondere questo fatto. La reattività e l'insuccesso occasionale riveleranno questo fatto. Questo potrebbe o non potrebbe essere un problema per te.

• L'applicazione dovrà supportare diverse versioni del browser. Il controllo del browser Web .NET è un wrapper per l'implementazione di Internet Explorer sul computer dell'utente. Sarebbe IE6, 7, 8, ecc. A seconda di cosa è installato lì.

Answer 2

Se non si perdono funzionalità dell'interfaccia utente significative passando all'interfaccia Web, non vedo perché questa non sia una soluzione eccezionale.

Answer 3

Sembra davvero un'ottima soluzione. Una cosa viene in mente, però:

Perché non passare semplicemente a un'applicazione Web completa? Ci sono alcune cose che puoi fare solo lato client al di fuori di un browser? Perché se così non fosse, probabilmente otterrete i vostri scenari di distribuzione molto semplificati semplicemente rendendo l'intera applicazione web.

Answer 4

Dipende dal tipo di applicazione, ma non vedo perché non potrebbe funzionare. Possibili svantaggi: devi lavorare in HTML e JavaScript, il componente WebBrowser dipende dalla versione di Internet Explorer installata (non sempre la stessa), l'interfaccia utente non è propriamente nativa e probabilmente si sentirà come un'applicazione web (non è necessario essere uno svantaggio). Se ho ragione, penso che l'interfaccia utente di Microsoft Money sia interamente basata su un controllo WebBrowser.

Answer 5

Non è consigliabile utilizzare il controllo WebBrowser, se è necessario implementare qualsiasi funzionalità complessa. Gli svantaggi sono:

• Il suo comportamento dipende dalla versione di IE installata, e le impostazioni di IE, ma non è identico a quello 'reale' IE. Ho visto alcuni casi, quando la funzionalità JS funzionava in un IE stand-alone, ma non funzionava in un controllo WebBrowser senza alcuna ragione ovvia (e quindi senza alcuna possibilità di risolverlo).

• È difficile personalizzare l'interfaccia utente (modificare il menu di scelta rapida, creare alcuni gestori di eventi complessi), poiché il controllo non espone molto di sé. Quindi, potrebbe essere irragionevolmente difficile farlo interagire con l'ambiente nel modo in cui è necessario.

Si potrebbe considerare l'utilizzo di una soluzione completamente web-based, che lavora in un browser stand-alone - almeno si sono molto meno probabilità di trovare un bug raro lì. È possibile utilizzare un'applet o un controllo ActiveX per interagire con l'hardware.

Un'altra opzione è sviluppare un thin client come un'applicazione Windows, che in qualche modo si configurerebbe a seconda dell'utente. Se hai ancora bisogno di incorporare un browser, puoi utilizzare Gecko (motore di Mozilla) o WebKit (il motore di Chrome) - Non ho esperienza pratica con loro, ma probabilmente hanno più coerenza tra versioni incorporate e stand-alone .

Answer 6

WPF non offre i vantaggi di skinning facilmente per utenti diversi pur mantenendo i ricchi vantaggi dell'interfaccia utente?