Ankündigung

Einklappen
Keine Ankündigung bisher.

Geschäftsbrowser als Alternative zum Webbrowser

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Geschäftsbrowser als Alternative zum Webbrowser

    TL;DR: Romantische Vorstellung eines alternativen Browserkonzepts für die einfache aber dezidierte Umsetzung mächtiger Geschäftsanwendung; aktuell ohne bedienbaren Prototypen.

    Bei diesem Thread schwebt mir vor allem vor, eure Meinung zu diesem Thema zu hören. Positive und negative Rückmeldung sind sehr willkommen.

    Mich zwickt dieses Thema eigentlich schon seit Jahren. Ich entwickle aktuell vor allem Backoffice-Applikationen, die möglichst effizient in der Nutzung und gleichzeitig leicht aktualisierbar sein sollen. Bislang stellt der Webbrowser das Fundament solcher Applikationen dar. Ich hoffe, ich muss hier keinem erst erklären, warum ich keine Desktopanwendungen auf Basis von Swing, WinForms/WPF oder Qt/Gkt schreibe.

    Was ist eine Backoffice-Anwendung?

    Unter diesem Begriff fasse ich alles zusammen, was einem eingeschränkten Nutzerkreis zur Verfügung gestellt werden soll, damit hier Daten erstellt, gepflegt und überwacht werden können. In der Regel benötigt ein User einen Account mit Zugangsdaten und gff. einem Set von Rechten. Beispiele für solche Anwendungen sind SugarCRM, Magento (Admin), Piwik, Horde, Plesk und die vielen Apps, die Unternehmen intern einsetzen, um vom Standard abweichende Aufgaben zu erledigen. Auch zu nennen sind die Händlerbezogenen-Verwaltungsseiten von PayPal, Ebay, Amazon etc.

    Man könnte hier sicher noch viel mehr Anwendungen aufzählen, jedoch sind die Möglichkeiten von HTML(5)-basierten WebApps beschränkt, weswegen es noch einen sehr aktiven Markt für normale Desktop-Anwendungen gibt. Da wird meiner Ansicht nach HTML5 auch nicht viel dran ändern, schaut man auf:
    • SAP/GUI (hier gibt es jetzt auch einen Webclient, der ist aber mies)
    • MS-Access
    • beinahe sämtliche Warenwirtschaftssysteme
    • beliebige Konfigurationstools
    • etc


    Der traditionelle Webbrowser (aktuell auf Basis von HTML5) ist für diesen Einsatzzweck nicht ausgelegt und wird sich auch in absehbarer Zeit nie richtig für diese Art von Tools anfühlen. Die Probleme liegen dabei auf der Hand:
    Javascript ist keine geeignete Plattform, um ernsthafte Applikationen zu bauen. Sicher gibt es genug Beispiele, die beweisen, dass es geht. Aber im Ernst: Es ist leicht sich hier etwas besseres vorzustellen.

    Auch wenn es hier Tools wie TypeScript, Coffeescript und Haxe gibt, wird Javascript nie als Basis für Webapplikationen jedes erdenkliche Problem lösen können. Zumal der Webbrowser auf Grund von z.B. ständig präsenten Gefahren nie so viele Möglichkeiten zulassen kann, wie ein Entwickler bei traditionellen Desktopanwendungen hat:
    • Zugriff auf Systemfunktionen
    • Fenster mit vielen Optionen (Modal, Toolbox)
    • Layouting (Anchor-Layout, XY-Layout)
    • Reiche Komponenten (Grids, Inputs für fast jegliche Art von Datentyp, viel Kontrolle)
    • Aufbau und Laufzeit der Anwendung belasten einen Server theoretisch nur minimal


    Desktopanwendungen geraten aber immer mehr ins Abseits. Die einfache Verfügbarmachung einer WebApp und den niedrigen Kosten für den Betrieb des Servers und der (theoretisch nur noch mit einem Browser ausgestatteten Clients), sowie die sehr leichte Einführung von Updates, sind für Unternehmen sehr interessante Argumente.

    Sicher ist jetzt jedem klar, worauf das jetzt hinausläuft. Ich bin auch nicht der erste, der sich mal mit dem Gedanken befasst hat, wie hier eine Alternative aussehen könnte. Und zugegeben: Dieses Vorhaben ist sehr Umfangreich – wenn auch bei Weitem nicht so umfangreich wie einen weiteren HTML5-Kompatiblem Webbrowser zu schreiben.

    Die Idee ist eigentlich simpel. Auf Basis von einer Beschreibungssprache wie XML und einer neuen, die den Einsatzzweck besser ausgelegten Sprache als Ersatz für JavaScript, soll ein Browser entstehen, der Ideal ist, um damit Geschäftsanwendungen umzusetzen. Dabei soll diese Anwendung jedoch nicht ausschliesslich auf einem Client-Device ausgeführt werden, sondern soll vor allem eine mehrbenutzer-fähige Server-Komponente bekommen, die den eigentlichen Betrieb der jeweiligen Anwendung übernimmt. Man kann sich das so vorstellen, dass man einen Client hat, der fast nur Befehle bekommt, wie und was angezeigt werden soll (für die, die das Prinzip kennen: X-Window-System). Startet man eine Anwendung, muss man zunächst eine Adresse angeben, auf der die gegenseitige Serverkomponente des Browsers auf eine Verbindung wartet. Dort geschieht dann das, was heute im Allgemeinen im HTML-Browser des Clients passiert: Eine dynamische Sprache wie Javascript treibt eine Anwendung an, die analog im HTML-Browser durch HTML und CSS dargestellt werden würde. Die Anwendung läuft serverseitig ständig und überlebt auch ansichtsändernde Vorgänge auf Client-Seite. Wird der Client geschlossen (zum Beispiel weil das anzeigende Device ausgeschaltet wird, oder Strom verliert), dann läuft die gestartete Anwendung auf dem Server solange weiter, wie noch ausstehende Aufgaben laufen. Danach (oder nach Ablauf einer Frist) wird die Anwendung beendet.



    Das primäre Ziel ist es, mit so wenig Aufwand wie möglich das zu tun, was am naheliegendsten ist und sich mit Mitteln eines HTML-basierten Webbrowsers nur schwerlich umsetzen lässt: Anwendungen, die Entwicklern nahezu den gleichen Möglichkeiten bieten, wie herkömmliche Desktop-Anwendungen und Anwendern (bzw. Sachbearbeitern) eine sehr zugängliche GUI zum schnellen Abarbeiten von Aufgaben zur Verfügung stellen. Folgende Features sind meiner Ansicht nach dafür sinnvoll:
    • Ein Teil der Business-Logik wird in den serverseitigen Part des Geschäftsbrowsers verlagert. Das entspricht dem Vorgehen vieler SinglePage-Anwendungen im JS/HTML-Bereich (ExtJS, AngularJS, EmberJS, Backbone etc), wobei die Anwendung hier Clientseitig läuft. Dieses Prinzip ist entfernt vergleichbar mit dem von Vaadin.
    • Dinge, die man in der Geschäftswelt oft benötigt, werden schon mitgeliefert:
      • Grid (mit Filtermöglichkeiten, Sortierung und ggf. Pivotfunktionalität)
      • eine reiche Palette an Input-Feldern für beliebige Datentypen (Verhalten und Darstellung anpassbar)
      • Layouts
      • Value-Binding mit Live-Updatefunktionalität (vgl. AngularJS)
      • Möglichkeit, Elemente für den Verlauf einer Hintergrundaktion leicht zu blockieren.
      • etc
    • Mächtige Möglichkeiten, eigene Eingabeelemente zu erstellen.
    • Wörterbücher mit gebräuchlichen, multilingualen Phrasen, die häufig immer wieder so zum Einsatz kommen (vgl. Iconfonts für sprachunabhängige Symbolik)
    • Einbindung in die Geschäftsumgebung: LDAP/SSO, Drucker, (eingeschränkter) Zugriff auf das lokale Dateisystem, Zugriff auf das Intranet
    • Zwischenspeicher: SQL-Ähnliche Puffer-Datenbank, die sich bei Bedarf automatisch neue Daten vom Server zieht. Der Geschäftsbrowser kommuniziert so vornehmlich mit dieser Pufferdatenbank, um Daten auszutauschen.
    • Keine URLs, kein Zurückbutton: Da man die Möglichkeit hat, Entitäten in einem Fenster zu öffnen, statt auf einer neuen Seite, kann man sich in fast allen Fällen den Zurück-Button sparen. Die Arbeit mit Tabs stellt sich zwar zum Teil als sehr komfortabel dar, aber die jetzt sehr andere Herangehensweise durch die neuen Möglichkeiten macht ein grundsätzliches Umdenken in dieser Hinsicht erforderlich. Trotz des Hash-Parts der URL haben SPA’s in der Regel auch mit dem Zurückbutton und der Möglichkeit, Bookmarks anzulegen, zu kämpfen.


    Viele der aufgezählten Features sind auch mit normalen Webbrowsern möglich - das ist mir bewusst. Es geht vor allem um die effektive Bereitstellung neuer Geschäftsanwendungen. Als Faustregel soll gelten: Es soll so einfach sein mit dem Businessbrowser datengetriebene Businessapplikationen zu erstellen, wie es mit HTML möglich ist, eine einfache Webseite zu erstellen. Eine komplexe ansprechende Webseite mit dem Businessbrowser zu erstellen ist so umständlich, wie eine flexible datengetriebene Businessapplikation mit HTML und Javascript umzusetzen.

    Ich könnte dazu jetzt noch ewig viel schreiben, aber ich denke, das wäre hier jetzt kontraproduktiv. Könnt ihr euch vorstellen, dass so eine Entwicklung Sinn macht?
    Standards - Best Practices - AwesomePHP - Guideline für WebApps


  • #2
    Die Idee, einen spezialisierten Browser für Geschäftsanwendungen, finde ich gar nicht schlecht. Was mir sofort in den Sinn kam Datensicherheit. Gut wäre wenn der Brwoser nur über SSL oder andere sichere Verbindungen mit der "Webapp" kommunizieren kann. Eventuell könnte der Browser auch eine Art Single-Sign-On unterstützen. Bei der Installation des Brwoser auf dem Desktop wird mittels Hardware-Analyse eine ID erzeugt. Beim starten des Browsers muss sich der Nutzer anmelden, so das die Browser-Konfiguration ausschließlich für diesen User zur Verfügung steht. Dann kann er im Browser einen Request an eine Webanwendung senden. Wird diese bestätigt steht dem Nutzer diese Webanwendung nur in diesem Browser zur Verfügung (dauerhaft). Der Administrator der Webanwednung kann mittels Hardwarecode entscheiden auf wievielen Geräten (oder zB nur betriebseigene Geräte) der Nutzer diese Anwendungen aufrufen darf. Das in Verbindung mit deutschem Datenschutz könnte ich mir sehr gut vorstellen.

    Kommentar


    • #3
      ich versteh das mit dem browser nicht; es wird mehr und mehr üblich arbeit unterwegs zu erledigen, tablet/smartphone/smartwatch(?) /etc.; dein angedachter browser ist also multiplatformfähig?

      du willst js nicht, weil es nicht geignet sei, aber eine eigene besser dafür geignete sprache selbst bauen?

      der browser soll nur noch actionen anstossen, welche auf dem serverdurchgeführt werden; der server nun unterrichtet den browser über erfolg und misserfolg; darauf muss der browser irgendwie reagieren, unabhängig vom dem im browswer dargestellten?

      trotz alle dem willst du das http(s) protokoll nutzen?
      //OT:
      man kann viel für und wieder finden; das schien mir, soweit ich mitgekommen bin, doch die drängensten fragen; und was TL;DR: heisst.

      Kommentar


      • #4
        Zitat von moma Beitrag anzeigen
        ich versteh das mit dem browser nicht; es wird mehr und mehr üblich arbeit unterwegs zu erledigen, tablet/smartphone/smartwatch(?) /etc.; dein angedachter browser ist also multiplatformfähig?
        Wie gesagt: Es geht nicht um einfache Webanwendungen. Es geht um Anwendungen, die heute noch eher selten via HTML abgebildet werden, weil sie dafür viel zu komplex sind. Natürlich kann man das ganze So angehen, dass alles im besten Fall responsive ist und somit auch fuer unterschiedliche Displaygrößen außerhalb der Desktopgrößen nutzbar ist. Aber ich denke, dass die Zielgruppe das (erst mal) gar nicht verlangt.

        Zitat von moma Beitrag anzeigen
        du willst js nicht, weil es nicht geignet sei, aber eine eigene besser dafür geignete sprache selbst bauen?
        Ich habe so ziemlich alle auf dem Markt bestehenden Scriptsprachen durch. Es geht vor allem um die effiziente Arbeit mit Daten. Die ideale Scriptsprache vereint funktionale Elemente und Denkweisen aus (beispielsweise) SQL mit klassischer Objektorientierung auf Basis eines imperativen Programmiermodells.

        Zitat von moma Beitrag anzeigen
        der browser soll nur noch actionen anstossen, welche auf dem serverdurchgeführt werden; der server nun unterrichtet den browser über erfolg und misserfolg; darauf muss der browser irgendwie reagieren, unabhängig vom dem im browswer dargestellten?
        Das würde das traditionelle Vorgehen in einem HTML-basierten Webbrowser beschreiben. Bei mir gibt es zwei Komponenten (siehe Grafik). Die serverseitige Komponente bildet das Verhalten ab, dass du von SinglePageAnwendungen her kennst. Die Client-Komponente stellt nur die UI dar, die durch zahlreiche Roundtrips durch den Server aktuell gehalten wird. Fuer die Anwendung selbst ist das so aber nicht sichtbar. Sie schreibt etwas in ein DOM-ähnliches Konstrukt, der Rest passiert dann einfach.

        Zitat von moma Beitrag anzeigen
        trotz alle dem willst du das http(s) protokoll nutzen?
        Die Server-Komponente zieht sich beim Start via http(s) das Bootstrap-Script von einem beliebigen Webservice. Dieses Bootstrap-Script erstellt dann die UI und macht die eigentlichen Aufgaben. Die Kommunikation zwischen Client und Server basiert auf einem eigenen Protokol. Die Kommunikation zwischen Server und API (die möglicherweise PHP-basierte Anwendung) passiert dann via HTTP(S) auf Rest-Basis.
        Standards - Best Practices - AwesomePHP - Guideline für WebApps

        Kommentar


        • #5
          Das würde das traditionelle Vorgehen in einem HTML-basierten Webbrowser beschreiben. Bei mir gibt es zwei Komponenten (siehe Grafik)
          nein. das ist nur der fall, wenn ich in der seite bleibe. die "seiten" passieren bei dir ja auf dem server.
          Natürlich kann man das ganze So angehen, dass alles im besten Fall responsive ist und somit auch fuer unterschiedliche Displaygrößen außerhalb der Desktopgrößen nutzbar ist.
          davon sprach ich nicht. das ist mir auch egal.
          ich wage mir nur vorzustellen, wie andere arbeiten, allein deine beipiele "SugarCRM, Magento (Admin), Piwik, Horde" sugerrieren mir ich muss da auch in der bahmn dran arbeiten können, auf meinem IPAD, da muss dein browser wie ne eins laufen, ist der also in C oder eher in java geschrieben.

          zu den scriptsprachen sag ich mal nichts mehr, hast ja alle durch, ich nicht.

          Kommentar


          • #6
            Zitat von moma Beitrag anzeigen
            nein. das ist nur der fall, wenn ich in der seite bleibe. die "seiten" passieren bei dir ja auf dem server.
            Es gibt hier keine "Seiten". Wenn du eine Analogie möchtest, dann nimm die SinglePageApp. Alles passiert ohne Seitenwechsel auf der gleichen Seite.

            Zitat von moma Beitrag anzeigen
            davon sprach ich nicht. das ist mir auch egal.
            ich wage mir nur vorzustellen, wie andere arbeiten, allein deine beipiele "SugarCRM, Magento (Admin), Piwik, Horde" sugerrieren mir ich muss da auch in der bahmn dran arbeiten können, auf meinem IPAD, da muss dein browser wie ne eins laufen, ist der also in C oder eher in java geschrieben.
            Denk vielleicht mehr an solche Apps 1 2 3 4 5
            Standards - Best Practices - AwesomePHP - Guideline für WebApps

            Kommentar


            • #7
              Abgesehen davon das ich auch kein Freund der JS-Entwicklung bin, sehe ich kaum Vorteile für Benutzer oder Entwickler. Wenn ich raten müsste warum komplexe Anwendungen keine Weboberflächen haben:
              a) Performance
              b) Kosten für die (Neu-)Entwicklung. Welches (große) Projekt wechselt schon Programmiersprache bzw. den Unterbau? Kannst dir ja mal Opera vor und nach dem Wechsel auf Chromium als Rendering-Engine anschauen.

              Die meisten andere Dinge von deiner Liste (weiterlaufen der Prozesse im Hintergrund) kann man ja mit Terminalservern ja auch machen. Abgesehen davon, das HTTP(S) als zustandsloses Protokoll bestimmt auch noch eine Menge Probleme machen wird, sehe ich nicht klar die Vorteile dieser Lösung.

              Kommentar

              Lädt...
              X