.NET GUI

Bei reinen WPF-Anwendungen gibt es ja insgesamt zwei unterschiedliche Möglichkeiten:

a) Reine Windows Client-Anwendung
b) WPF Browseranwendung, also XBAP welches im Browser läuft

Ich persönlich tue mir durchaus etwas schwer, WPF Browseranwendungen zu empfehlen, zumal ich von der Sinnhaftigkeit nicht vollständig überzeugt bin. Welche Gründe für die Umsetzung eines Projektes als WPF Browseranwendung seht ihr? Wann würdet ihr euch dafür entscheiden und gegen eine reine WPF Anwendung?

Aufgrund der Möglichkeiten in der Gestaltung der Oberfläche fallen mir da einige Themen ein, bei denen es sich - rein optisch - anbieten würde eine WPF-Browseranwendung zu verwenden. Ich denke da beispielsweise an Spieleseiten, die eine oft grafisch aufwendige Seitengestaltung verwenden und auch jetzt schon häufig Flash einsetzen, oder bsp. die Website eines Vergnügungsparks. Also generell solche Websites, bei denen es nicht nur auf den Content ankommt sondern auch auf die Präsentation drumherum. Etwas grenzwertig sehe ich da Seiten wie YouTube. Auch diese kann ich mir sehr gut als reine WPF-Browserseite vorstellen, aber das brächte dann ganz andere Probleme mit sich. Allen voran natürlich das Hauptproblem der Indexierung durch Suchmaschinen oder aber auch die Direktverlinkung zu Unterseiten (geht das mit WPF überhaupt ohne unverhältnismäßigen Aufwand?). Bei einem Großteil der Websites fände ich eine Umsetzung als WPF-Browseranwendung jedoch völlig übertrieben und unnötig.

Aufgrund der letztgenannten Einschränkungen (Indexierung, Direktverlinkung) bleibt aber eine Kategorie von Websites übrig, für die es sich dennoch anbieten würde: Websites für einen geschlossenen Benutzerkreis. Das kann sowohl die administrative Verwaltung eines CMS sein als auch eine komplette Verwaltungssoftware einer Firma, welche als Webanwendung intern bereitgestellt wird. Solche Seiten sollen in der Regel nicht indexiert werden und durch den geschlossenen Benutzerkreis kann man sicherstellen, dass jeder das notwendige Framework auch installiert hat. Dafür aber profitiert der Benutzer dann von einer intuitiv zu bedienenden Oberfläche, die obwohl im Webbrowser ablaufend das gleiche Feeling wie eine Desktopanwendung hat. Vorteile der Webanwendung gegenüber einer reinen Desktop-Anwendung: Ohne vorherige Installation ist eine Anwendung sofort über eine URL (und Login) erreichbar und auch das Bereitstellen von Updates wird deutlich vereinfacht da das Rollout auf alle Clients entfällt.

Ich hab ja so das gefühl dass XBAP´s eher in kontrollierten (ev. sogar internen) Umgebungen ihren Platz finden. Da XBAP´s im gegensatz zu Silverlight den Vollständigen .NET 3.x Framework verlangt und (afaik) auch nur mit IE einsetzbar ist sind Anwendungen für die breite Massa á la YouTube & co wohl eher nicht so ganz erfolgreich. Ich glaube dass sich in Web-Szenarien Silverlight Applikationen eher durchsetzen werden als XBAP's. und für Fat Clients sehe ich auch mehr Anwendungen für normale WPF Apps mit ClickOnce deployment. Aber da hat wohl jeder so seine eigene Meinung ;)

Auch ich sehe es eher für interne Bereiche. Die von dir angesprochenen Spieleseiten, Gordon, finde ich nicht als relevant an, da diese auch für einen recht großen Nutzerbereich gedacht sind und somit eine WPF-Browseranwendung durchaus ausfallen dürfte. Hier könnte ich mir Silverlight für einige Teilbereiche vorstellen, das war es dann auch schon wieder.

Das Thema der internen Verwaltung von Intranets etc. sehe ich hingegen als ein gutes Beispiel an. Dadurch können einige Funktionalitäten wirklich vereinfacht angeboten werden und vieles kann vereinfacht werden. Lediglich schränkt man sich dann wieder auf einen Unternehmenskreis ein, was schlussendlich auch dagegen sprechen dürfte. Für Unternehmen mit einer Linux-basierenden Infrastruktur müsste ein eigenes Interface entwickelt werden. Sozusagen doppelter Aufwand, der sich dann wahrscheinlich nicht lohnen dürfte.

Das mit den Spieleseiten ist wohl ein guter Einwand, da hatte ich so nicht dran gedacht gehabt. Dennoch wäre es aber zumindest für das eigentliche Spiel (statt der ganzen Website drumherum) eine mögliche Alternative zu Flash - aber auch da kommt wohl eher Silverlight in Frage.

Das Beispiel mit firmeninternen Anwendungen war zum Teil aus meiner eigenen Erfahrung - ich kenne durchaus Systeme, bsp. eine CMS-Adminoberfläche, dieaufgrund der Verwendung von ActiveX oder aber speziell angepassten Javascripts den Internet Explorer voraussetzen. Auch wenn das, zugegebenermaßen, kein Idealzustand ist. Wenn man das ganze nun für Speziallösungen betrachtet, die in der Regel von großen Enterprise-Produkten nicht abgedeckt werden (können), dann hat man meistens auch vom Kunden eine entsprechende Akzeptanz was clientseitige Anforderungen betrifft. Dafür erhalten sie ein Produkt, dass genau ihren Anforderungen entspricht und evtl. firmenspezifische Funktionen vorhalten kann. Und zumindest mir ist bisher bei einigen größeren Unternehmen (deren Infrastruktur ich kenne) durchaus aufgefallen, dass in der Regel Windows und nicht Linux eingesetzt wird; alleine schon um den Schulungsaufwand der Mitarbeiter gering zu halten und gängige Anwendungen die "jeder" kennt (bsp. Office & co.) einsetzen zu können.

Da (bisher) Linux und Mac aber WPF nicht unterstützen hast du, Norbert, natürlich Recht: Anwendungen die für die breite Masse bereitgestellt werden sollen kann man (noch) nicht als WPF-Browseranwendungen bereitstellen, da es auf die Windows-Plattform beschränkt ist und der doppelte Aufwand für ein Alternativ-Interface in der Regel nicht gerechtfertigt sein wird. In einer kontrollierten / internen Umgebung sehe ich jedoch entsprechendes Potential.

Für kundenspezifische Implementierungen mag es durchaus sinnvoll sein, wobei sich mir hier die Frage stellt, warum dann nicht gleich eine vollständige WPF-Anwendung. Denn diese kann ebenfalls über ClickOnce deployed werden. Der einzige Unterschied besteht dann lediglich im Startmenü-Eintrag, was auch nicht wirklich tragisch ist. Zudem stehen mir in der WPF-Anwendung dann noch ein paar zusätzliche Möglichkeiten zur Verfügung.

Gut, im Falle eines CMS kann dies in den Browser integriert werden, was durchaus gewünscht sein wird. Grundsätzlich bin ich der Meinung, dass diese Entscheidung wirklich gut überlegt sein will.

Norbert Eder:

Gut, im Falle eines CMS kann dies in den Browser integriert werden, was durchaus gewünscht sein wird. Grundsätzlich bin ich der Meinung, dass diese Entscheidung wirklich gut überlegt sein will.

Da sagst du was wahres. Die Einschätzung des "kontrollierten" Umfelds teile ich auch. Die Anwendungsfälle sind dort sehr weit gestreut. Es betrifft alle Systeme, bei denen ein echtes "Deployment" nicht sinnvol ist. Typische Szenarien sind die Ablösung von sogenannten Terminals in Banken, bei der Flugabfertigung usw. also dort, wo die Gesetzgebung oder andere Richtlinien recht häufig von heute auf morgen erzwingen, dass alle mit einer neuen Version arbeiten und die Deploymentzeit auf NULL gesetzt werden muss.

Dann finde ich, dass du die Hürde zu installieren unterschätzt. Diese verdirbt im Bereich des Shoppings weitaus mehr die Umsatzzahlen als es die Browsertypen tun. Wenn man auf die Linux-Benutzer beim Einkauf von Waren verzichtet und dafür die Installationshürde streicht, hat man in der Summe mehr Nutzer auf der Shoppingsite. Wirtschaftlich ein Vorteil (außerdem sind Linux User bekanntlich geizig, sie geben ja keine echtes Geld für Software aus ).

Na hoffentlich verirrt sich kein Linux User in diesen Thread ;-)

Wie du richtig sagst, hängt die Deployment-Strategie natürlich von der Anzahl der Clients und von der Umgebung, als auch den rechtlichen Faktoren ab. In einem kleinen Unternehmen spielt dies keine oder nur eine geringe Rolle. Bei den von dir aufgeführten Szenarien sehr wohl. Ebenfalls werden dort die paar Prozente die bei den Funktionen abgestrichen werden müssen auch nicht wirklich gebraucht. Schnelle Dateneingabe, hohe Usability etc. sind da gefragt.