OrgaMon-next: Unterschied zwischen den Versionen

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
 
(388 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
== OrgaMon-Sprach-Basis ==
* Dies ist die Konzept-Sammlung für die nächste Version des OrgaMon 9, "OrgaMon [[Polyzalos]]"
* OrgaMon setzt wo immer möglich die Programmiersprache "Object-Pascal", auch bei Dingen die in Wirklichkeit als "JavaScript" im Browser des Anwenders laufen (CrossCompile).
* Als Compiler wird nur noch Free-Pascal eingesetzt, Wegfall von "Delphi"
* Es werden nur noch Open-Source Komponenten eingesetzt
* Die mit der Delphi-IDE erstellte UI entfällt, der cOrgaMon übernimmt die Funktion eines WebServers und führt Funktionen des eCommerce-Kernel aus
* dazu ist das [[HTTP2]]-Projekt ein wesentlicher Anteil von OrgaMon 9 [[Polyzalos]]
* cOrgaMon wird vorrangig auf Linux Maschinen installiert, unter systemd als (Type=notify) mit "READY=1" nach lesen der ini
* der eCommerce-Kernel soll Schritt für Schritt Kopplungspunkte bekommen wobei Kunden dann Anpassungen machen können. Das Customizing sollte aber auch wieder Open-Source sein und auch Test-Cases beinhalten so dass es für andere Kunden Regeressionsfrei bleibt.
* Die Lazarus-IDE soll auch für Kunden eine Möglichkeit sein, auf den Code Einfluss zu nehmen. Dabei soll die neue Paket-Verwaltung von Lazarus den cOrgaMon mit wenigen Klicks "installieren" können


* OrgaMon setzt wo immer möglich die Programmiersprache Object-Pascal ein.
== OrgaMon UI ==
* Als Compiler werden Free Pascal (Open Source), Delphi (Kommerziell)
* Für Remote-Codeausführung wird Pascal Script (RemObjects) verwendet (Open Source)
* der eCommerce Kernel soll schritt für Schritt Kopplungspunkte bekommen wobei Kunden dann Anpassungen machen können. Das Customizing sollte aber auch wieder Open Source sein und auch Test Cases beinhalten dass es Release Fest bleibt. Eine IDE wäre schön ist aber nicht in Sicht.


== OrgaMon-Map ==
=== User Interface (UI) Ideen ===


* OpenStreetview
ein Projekt, das zum Ziel hat den OrgaMon mit einer Plattform-übergreifenden GUI anzubieten
** Im ersten Schritt soll der /tile/ Dienst vom Web genutzt werden
** Später soll mit mapnik ein eigener Renderer auf Linux Basis eingesetzt werden


* Google-Mpas
[[Bild:OrgaMon-8-GUI.png]]
** Im ersten Schritt soll ein Google-Map Api eingesetzt werden um gerenderte Karten zu laden
** Nachdem OpenStreetview stark genug ist soll dies wieder sterben


* Geolokalisierung
==== farbige Tabs ====
** Soll weiterhin mit dem xServer betrieben werden


=== Quellen ===
* Tab sind erst mal nicht da, können aber aus einem Suchbegriff oder einem Befehl frisch erzeugt werden. Wird z.B. ein Vertrag angewendet entstehen ev. ganz viele neue Beleg, ein Beleg wir als ein einzelner Tab angezeigt.
* Standard-Aktionen sind auf Tabs anwendbar und können als transaktion auf Gruppen von TAbs angewendet werden.
* Eine aktuell eingerichtete Tab-Gruppe (3 Personen und 2 Beleg und 1 Vertrag) kann in einer Tab-Historie gespeichert werden.
* Tab-Favoriten gibt es auch, auf die "Umgeschaltet" werden kann aber auch "dazugeladen" werden kann.
* man kann mehrere Belege öffnen und gleichzeitig bearbeiten. Dazu "Zieht" man sich einen neuen Tab. Tabs aus der selben Gruppe haben die gleiche Farbe und sind immer zusammen angeordnet (Gruppe schliessen).
* Es gibt einen Neu Tab.
* Ein Langer gehaltener Klick auf einen Tab erzeugt einen "Drag"-Event


[1] http://delphimaps.googlecode.com/svn/trunk/<br>
==== Tab-Funktionen ====
[2] <br>
[3] mapnik<br>
[4] http://weait.com/content/build-your-own-openstreetmap-server<br>
[] http://DelphiFeeds.com<br>
[] http://www.delphifeeds.com/go/f/70742?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+delphifeeds+%28DelphiFeeds.com%29<br>


== OrgaMon-Appliance ==
* Anklicken: Der Tab-Inhalt kommt nach vorne, jetzt erst wenn der TabInhalt sichtbar ist wird das kleine "close" sichtbar.
* Schliesst man den Browser mit offenen Tabs muss am nächsten Tag ein reconnect erfolgen mit allen Inhalten parat!!!


=== Begriffsdefinition ===
==== Tabellen ====


* '''OrgaMon-Appliance''' ist Gesamtheit der WAN-Mandant Infrastruktur
* Spaltenbreiten sollen gezogen werden können oder "auto"
* '''Mandant''' ist die Datensumme aus Datenbank-Inhalt und Dateisysteminhalt
* <code>Titel ^v</code> wenn Hoch + Runter zu sehen ist, dann ist KEINE Sortierung aktiv
** '''lokaler Mandant''' OrgaMon + lokales Dateisystem + embedded firebird (Einzelplatz)
* <code>Titel v</code> aufsteigende Sortierung
** '''LAN Mandant''' OrgaMon + Verzeichnis im NAS + firebird Server
* <code>Titel ^</code> absteigende Sortiertung
** '''WAN Mandant''' OrgaMon + Sync auf das NAS + OrgaMon-Ghost
* Spaltenlayout soll auf "default" zurückgesetzt werden können
* '''Client''' ist ein vollständiger (mit GUI) laufender OrgaMon.exe
* Spaltenlayout, wie es im Moment ist, soll gespeichert werden können
* '''Ghost''' ist ein cOrgaMon.exe ohne GUI
* 1. Rang, 2. Rang: Idee : Ev. durch den vertikalen Abstand zur Tabelle den Rang symbolisieren, also je höher desto hochrangiger
* Markieren sollte immer gleich funktionieren, "M" dann wird es blau ...


=== Vorteile ===
==== Progressbereich ====


die OrgaMon-Appliance ermöglich das Arbeiten mit einem WAN - Mandanten. Dabei wird lokal die OrgaMon-Anwendung verwendet. Über das Internet wird Kontakt zu einer OrgaMon-Appliance hergestellt. Die Datenbank und das Dateisystem liegt dabei in der Appliance.
* zeigt zentral aktuelle Wartezeiten an, im Hilfehinweis oberhalb laufen Log meldungen
Die Dienste eMail, Tagwache, Tagesabschluss, FTP-Bereich, liegen dabei auf dem Appliance-Host.
* ich bin unsicher, ob dies durchführbar ist, aber ich will eine Unstoppable GUI die einfach nur Anforderungen an eine Exekutive weitergibt. In dem Progressbereich stapeln sich einfach Aufgaben, die im Moment am laufen sind und noch nicht abgeschlossen (Beispiele Dafür: Tagwache auf einem Server, Tagesabschluss auf einem Server, Anwendung von Verträgen usw.)
Die Datenbank-Operationen werden 100% auf einem Server durchgeführt, die Dateioperationen müssen teilweise per "save" and "send" (Lokales speichern auf dem Server UND senden an den Client) oder "save" und "replicate" (lokales speichern und replizieren wenn es die Bandbreite zu lässt).


=== Kopplung "Applikationsservers" und "Client" ===
==== Suchbereich ====


der Client ist immer grundsätzlich vollständig, das bedeutet er "könnte" auch alle Funktionen lokal mit einer eigenen Datenbank und auf dem eigenen Dateisystem ausführen. Intern im OrgaMon sind je nach Mandant (lokal oder Remote) die Ausführungswege jedoch anders gesteuert.  
* OrgaMon ist (wieder) über Hotkeys steuerbar: <ctrl>PN macht "Person" "neu" der Focus steht beim Vornamen usw.
Bei einem remote-Mandanten deligiert der Client die Aufgaben an den Server. Dazu erzeugt der Client eine Anforderung als kleines Pascal-Script und sendet es zur Ausführung dem Server.
* Kann man die oft in Anleitungen oder Bugreports verwendeten Bedienungsketten, also Eingaben benutzten?
Im Rahmen der Ausführung kann nun auch der Server seinerseits Rückfragen (inquire) oder Feedback senden. Dies erfolgt analog eben so in Form von Pascal-Script.
* Baustelle &#129046; Reiter "Verfügbar" &#129046; Haken bei [v] Senden &#129046; Button OK


=== OrgaMon Gate ===
==== SVG woimmer es geht ====


soll eingehende Anfragen beantworten. Dabei muss das Gate als Router funktionieren um die Requests auf den passenden OrgaMon-Ghost weiterzugeben.
* wegen DPI Awareness und Size Awareness sollten immer SVG eingesetzt werden, die der Browser zoomt
* http://www.material-ui.com/#/components/svg-icon


==== blauer Aqua-Button ====


==== Mögliche Implementierung ====
der Start-knopf des OrgaMon, hier kommen die ganzen früheren Menü Möglichkeiten


* Apache2, https!
==== ARIA Keyboard Support ====
* mod_asis geht ev. Hand in Hand mit dem etag Caching System
* Proxy VOR den einzelnen mandanten http://httpd.apache.org/docs/2.0/mod/mod_proxy.html
* Kompression mit Hilfe von zlib und Standard HTTP Techniken


=== OrgaMon Ghosts ===
* die Bedienung sollte rein via Keyboard möglich sein, dazu stehen Accessabilty Regeln vor Gutem Aussehen
** https://www.w3.org/TR/wai-aria-1.2/


(1:1 instanzierung des Applikationsserver)
==== Datenbank Edits ====


Mit einem OrgaMon-Client kann man auch eine extra gestartete Ghost Instanz (1:1 Beziehung) des OrgaMon über eine TCP/IP Verbindung konnektieren. Ein Dispatcher hilft dabei bei der Konnektierung zwischen Client und Ghost, ev. auch mal bei einem Re-Connect.
Textfeldfarben


Buisiness-Logik Funktionen werden auf dem Migrationsweg zunehmend über "Interfaceable" Datenmodule abgewickelt. Im OrgaMon müssen nun Datenmodule entweder ...
weiss: kam so vom server
rosa: ist auf dem Server inzwischen anders
gelb: wurde hier local verändert


* lokal konnektieren, dann läuft die Funktion über die lokale CPU ab, sie operiert dabei mit der angegebenen Datenbank und dem angegebenen Dateisystem.
es soll so sein, dass eine edit gruppe einen ID bekommt, wenn der DB-Server eine Änderung der Dateninhalte erkannt hat, soll die Ungültigkeit dieser ID durch einen Farbwechsel in GUI angezeigt werden. Die dazugehörige Notification sollte per PUSH Technologie von HTTP/2 erfolgen. Dies ist aber unmöglich, da PUSH von Chrome gar nicht unterstützt wird, es ist auch so, dass es im "Service Worker" hier sicher andere Möglichkeiten gibt.
* remote konnektieren, die Funktionsaufrufe werden sequenzialisiert und zum remote übertragen. Dieser führt den Code unter veränderung der dortigen Datenbank und des dortigen Dateisystems aus. Der Rückgabewert wird wiederum über TCP versendet.  


==== File Sync ====
=== UI Implementierung ===


Es ist möglich dass im Rahmen der Codeausführung auf dem Server Dateien im lokalen Dateisystem des Servers auf den Client synchronisiert werden müssen. Der Server Code muss diese Dateinamen einem SynDienst melden: Dieser wird sofort eine Synchronisation durchführen. Entsprechende Anfragen muss die entsprechende Routine dem Interface mitteilen, da VOR Zurückkehren der Routine auch das Dateisystem sychronisiert sein muss! (Es sei denn auf dem Client gibt es eine ensure(FName) Funktion die Signalisiert, dass diese datei JETZT wieder gebraucht wird, ensure würde in diesem Fall warten bis die Datei da ist!) Ansonsten kann diese Aktion asynchron ablaufen.
* 22.12.2016: Das Konzept des OrgaMon 9 steht:
Entstehen nun auf dem Remote neue Dateien, so wir als Funktionsergebnis das initiieren eines FTP Downloades gefordert, der Client holt sich also die Ergebnisse über FTP ab, und spiegelt sie auf der lokalen Platte nun wieder.
* GUI ist ...
* immer ein Chrome-Client ab Rev. 119+
* immer https:// (HTTP/2)
** immer window.isSecureContext
* immer html5 und JavaScript, immer generiert aus eigenen Quellen, nach Möglichkeit keine Meta-Ebene auf dem Client, alles direkt und "nativ"
* kein HTTPS Server dazwischen (z.B. Apache oder nxing)
* eigene Session Verwaltung über die Datenbank
* Die Bedienelemente sollen ganz einfach beginnen und dann Schritt für Schritt mächtiger werden
* Als Icons sollen immer SVG Symbole verwendet werden
** https://github.com/ionic-team/ionicons
* Ein erster Start könnte https://github.com/xtermjs/xterm.js sein
* ag-grid könnte für data Grids eine gute Ersparniss sein
* dabei soll mit Hilfe des Codes von Michael Van Canneyt JavaScript für den Client aus Pascal Programmierung erstellt werden, die JavaScript Tatsache soll versteckt bleiben
** der Document - DOM soll versteckt werden das ist Sache des JavaScripts
** also es gibt keine HTML Templates, das wird alles auf dem Client erzeugt
** https://vuejs.org/
** https://reactjs.org/
** https://angularjs.org/
** https://quasar.dev/
** https://getbootstrap.com/
** https://www.w3schools.com/


==== break ====
* INfo-Link:
** https://www.freepascal.org/~michael/articles/extjs1/extjs1.pdf
** https://www.freepascal.org/~michael/articles/extpascal/extpascal.pdf
** https://www.mediawiki.org/wiki/OOUI oder https://doc.wikimedia.org/oojs-ui/master/php/
** https://entwickler.de/online/web/web-app-tutorial-ionic-579898855.html


der Server hat zu jeder Zeit die Möglichkeit eine Aktion abzubrechen. Dies sieht technisch nicht anders aus, als eine normale vollständige Ausführung. Der Client muss aber auch die Möglichkeit haben einen "Break" zur aktuellen Aktion zu senden.
==== automatisierte Tests ====


während der Laufzeit muss eigentlich das Interface nahtlos austauschbar sein.
* Eine Programmierung die mit Hilfe eines eigenen Browser Fenster bestimmte Aktionen auf dem Server auslösen soll
* https://github.com/dliw/fpCEF3


=== lokale Aktionen ===
==== Asynchrone UI ====
=== Datenbank-Caching ===


Die Systeme sollen aber auch umfassendes Verständnis von Caching haben. Wie bereits an anderer Stelle angedeutet spielt hier der eTag eine ganz besondere Rolle. Der Client stellt unwissend eine Frage (eTag noch "null") er bekommt die Antwort UND den eTag.
* Die UI darf durch Kommunikation mit dem Server nicht geblockt werden
Das nächste Mal stellt der die völlig identische Frage nochmals (diesmal mit dem erhaltenen eTag im Header). Nun ist es am Server zu sagen "unchanged" oder neuer eTag und Content.
** https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Message_manager_overview
** https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise
** https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function


Da Datenbankabfragen mit teilweise sehr grossen Antworten "select * from" einhergehen in Verbindungs damit dass ofmals ein "Refresh" notwendig ist. Ist das Caching von Datenbank-Werten erlaubt und wird durch eine besondere Technik unterstützt.
[[Datei:Button-Wait.png]]


Client->Server: SQL-Anfrage
* Also ein gedrückter Knopf bedeutet
Server->Client: Cache_ID & Antwort-Paket
** sofortige Deaktivierung, das ist das Feedback für die Annahme des Auftrags des UI
später
** die UI darf nicht blockieren, weitere Knöpfe sind weiterhin aktiv
Client->Server: SQL-Anfrage (identisch)
** folgender Status Feedback, dass der Request in die Datenbank eingetragen ist
Server: Cache_ID
** folgender Status Feedback, dass der Request zum Server übertragen werden konnte (mit Offline-Zeiten ist hier zu rechnen, das darf kein Problem sein)
** folgender Status Feedback, dass eine Antwort des Servers da ist mit neuem Status für diesen Button (Ein Erfolg, Ein Misserfolg, ein Fortschritt)
oder auch
Client->Server: Cache_ID?
Server: "valid"


=== Asynchrones Arbeiten ===
==== erste Schritte ====


Wichtige Fragen müssen beantwortet werden
* ein Fenster mit einer Schaltfläche:
* ein Text-Editfeld das mit einer Datenbank verbunden ist


# Wie verteile ich Arbeit auf viele Cores ohne den Determinismus zu verlieren
==== offene Fragen: ====
# Wie schaffe ich eine Infrastruktur die Nativ Parallel ist aber stur sequenziell beschrieben und designed ist


Ziel ist die Steigerung der Latenz von Verarbeitungsschritten, die Latenz hat in der IT eine viel Grössere Bedeutung als die Performance. Das Grundkonzept ist, Verarbeitungsschritte, die gemacht werden müssen "auf später" zu verschieben, und dem rufenden Prozess "Scheinergebnisse" zu liefern.
* Unter Linux hätte ich gerne eine "ordentlichen" systemd Integration also
Eine automatische Parallelisierung von "Schritt 1" und "Schritt 2" ist möglich wenn
** Running-Notfification, Ini-Read Successfully oder "Die"
** Watchdog-Notification, alive or being killed
** Info about a HANDLE, also accept() soll systemd machen, wir bekomme einfach im Programms


* die beiden Schritte keine W-Zugriffe auf fremdgenutzte R-Elemente machen, also wenn ein Schritt keine Datengrundlage des anderen Modifiziert
HTML5-
* die beiden Schritte nicht von W-Werten des anderen abhängig sind. Also wenn "Schritt 2" eine R-Zugriff auf einen Wert macht, den "Schritt 1" beschreibt. In so einem Fall muss "Schritt 1" zumindest bis zum letzten W auf diesen Wert VORHER ausgeführt werden (Context-Block!).
Client  <--https/2--> systemd Socket Activation <---sd_listen_fds()---> hOrgaMon Web Server    <--fbclient----> FirebirdSQL
                                                                        (links libsystemd.so)  +--file I/O---> .\OrgaMon\


==== Context-Freeze ====
=== Das User-Interface-Grundgesetz ===


Merke Dir den HB im Eingangsmoment zu "Schritt 1". Sollten nachfolgende Schritte massiv die R-Basis von "Schritt 1" beschreiben kann immer noch ein korrektes Ergebnis erzielt werden wenn
Im Zentrum einer GUI müssen unverhandelbare Grundrechte des Benutzers / Bedieners stehen. Die Optik des UI muss klare Signale an den Benutzer senden so dass dieser sich 100% auf Funktionen des Interface verlassen kann. Auswüchse die es im Moment gibt (Wir sind immer noch in der IT-Steinzeit) müssen verhindert werden. Ich will für die Tatsache sensibilisieren das heute Webinhalte den User im Unklaren lassen was er auf einem Screen machen kann. Grafisch möglicherweise perfekt muss er erst mal mit der Maus rumsuchen was anklickbar ist. Wenn er dann anklickt kommt kein Feedback. Er muss nun hoffen dass sich was tut in den nächsten 5 Sekunden.


* nachfolgende Schritte nach R Zugriffe auf das W des ersten Schrittes machen
==== Negativ-Beispiele die vermieden werden sollen ====
* der erste Schritte alle R Zugriffe im Context des gespeicherten HBs machen


* Beispiel: Edge: Während man in der Adresszeile des Browsers ist wechselt der Eingabefokus in ein anderes Control
* Beispiel: Bevormundung: Verschiedene Programme: Eine Eingabehilfe ergänzt die Eingaben "i" zu "intelligent". "i" <ENTER> ergibt also den Eingabewert "intelligent". Man muss "i" <BLANK> <BS> <ENTER> eingeben um einfach nur "i" zu erhalten, das darf nicht sein!
* Beispiel: Delphi: Suchbegriffe werden immer vervollständigt, will man nur nach "S" suchen, ist die Eingabe nicht möglich. "S" <Enter> sucht nach "String", da "S" nach "String" vervollständigt wird.
* Beispiel: Man Klickt auf ein Button, jedoch wenige ms zuvor überdeckt ein unmotiviert eingeblendetes Fenster den Button, nunmehr verarbeitet dieses neue Fenster den Click auf einen zufällig deckungsgleichen Button. Und das obwohl eine gewolltes Anklicken gar nicht möglich ist.
* Beispiel: App "VR Networld Banking": Ist die App lange unbenutzt läuft die Session im Hintergrund ab, es ist keine Verbindung mehr vorhanden. Beendet man jetzt die App kommt die Frage "Abmelden"
* Beispiel: App "VR Networld Banking": Besteht eine Session, diese hat aber keine Fokus, und es kommt eine Pushj nachricht wird man in einen neuen Anmeldeschirm geleitet obwohl eine gültige Session da ist. Es wird eine weitere Instanz der App gestartet anstelle den Eingabefokus auf die laufende aktuelle Session zu lenken
* Beipsile: App "VR Networld Banking": geht der Anmeldevorgang sehr lange und das Handy schaltet das Display ab wird der anmeldevorgang nicht im Hintergrund zuende geführt, es gibt einen "technischen" Fehler. Ich muss immer aufs Display tippen um die App am Leben zu halten solange sie sich anmeldet.
* Beispiel: App "VR Secure Go": Wird eine TAN erhalten verdeckt ein Fenster "aktualisiere Push Daten" diese TAN
* Beispiel: Unwetterzentrale: man sieht eine karte, oben ist die Werbung am Laden, man klickt auf die Karte just in dem Moment rattert die Karten nach unten, man triff einen Bereich mit dem Klick, den man nicht wollte
* Beispiel: Cookie-Warnungen: Wichtige Teile der Seite werden einfach überblendet, es ist keine echte Position für die Meldung vorgesehen
* Beispiel: interne App-Makros: Apps werden intern teilweise durch Klicks gesteuert. Beispiel tunein Radio-App, mann wählt seinen Sender und sieht das "Play" Symbol. Eine Sekunde lang passiert nichts. Dann per Geisterhand dreht sich plötzlich das Rad. Der Playknopf wurde intern gedrückt, jetzt spielt das Radio los. Besser wäre es gewesen den Screen mit dem "Rad" zu beginnen, ev. mit dem Pause Symbol.


==== §1 Klickbarkeit ====


==== Sofortiger Rücksprung ====
Ist ein Text oder ein Bild oder ein Icon anklickbar, so muss es in einer deutlich sichtbaren Weise grafisch <i>anders</i> ausgeprägt werden, dass dies deutlich wird. Bei einem MoveOver muss sich auch der Zeiger ändern. Ein Button muss von einem immer gleichen Rahmen umfasst sein, innerhalb des Textes muss "["Begriff"]" stehen oder #Begriff. <u>Unterstreichen</u> ist keine erlaubte Link-Symbolisierung. Einfärben (es wird gerne "Blau" genommen) ist keine erlaubte Link-Symbolisierung.


Bei einer Read-Only Operation ohne Rückgabewert kann sofort zurückgesprungen werden. Anstelle des Rückgabewertes kann ein "Call Back Token" zurückgegeben werden, das sicherstellt dass wenn etwas auf das Ergebnis zurückgreift dass er erst Einblick erhält wenn die Verarbeitung abgeschlossen ist.
==== §2 Bewegungsmelder ====
Der Zugriff auf R-Objekte muss im aktuellen Heartbeat-Kontext erfolgen, also alle Objekte müssen im Moment des Verarbeitungsbeginnes eingefrohren werden.
Ev. kann die Funktion selbst ein "R-Lock" auf Objekte setzen, die es braucht. Wenn andere Prozesse auf diese Objekte nun schreiben wollen muss die Verarbeitung vorrangig abgeschlossen werden.
Vor Rücksprung sollten immer Vorbedingungen der Operation geprüft werden, ist also die Durchführung der Aktion möglich und es kann eine Exception ausgeschlossen werden kann dem rufenden der Erfolg gemeldet werden, was er nicht weis ist, dass die Aktion noch gar nicht "wirklich" durchgeführt ist.


=== Paralleles Arbeiten ===
Die beobachtete Fläche muss klar ausgewiesen werden. Bei MouseEntry / Leaf muss optisch die Fläche aufleuchten (ON/OFF). Bei ON darf die Fläche nicht verschoben werden, die GUI muss fixiert werden. Bei ON dürfen umliegende Bereiche verändert werden, bei OFF muss der "Originalzustand" wieder herstellt werden.


* Intel Parallel Building Blocks (PBB)
==== §3 Fokus ====
* OpenMP


=== Interface-Ablauf ===
Der Eingabefokus darf niemals programmgesteuert dem aktuell sichbaren Eingabefeld entzogen werden, während die GUI Benutzereingaben erwartet. Das Einblenden eines Meldungsfensters während der Benutzer eine Eingabe tätigt ist ein solcher Fokusentzug. Ein Notifikationsbereich der sich verändert ist erlaubt.


==== Call ====
==== §4 Eingabesicherheit ====


Der Client iniziiert einen Call über http. Es sendet seinen Cache ID im etag mit. Dem Server seht es frei diesen eTag zu bestätigen oder ihn zuverwerfen.
Direktes Abändern/Verfälschen der Eingabe, also automatisches Vervollständigen, automatisches Setzen eines Punktes usw. ist nicht erlaubt.


==== Feedback ====
==== §5 Sichtbarkeit ====


Zusammen mit dem Client-Call wird ein Feedback Callback (optionales) installiert. Dies ist nur sinnvoll für Routinen die während ihres Ablaufes Infos an den rufenden zurückgeben wollen oder müssen. Damit liefert der Server Zwischen Infos seiner Bearbeitung ab. Dies ist für das Logging wichtig. Bei langdauernden Aktionen des Servers dient das Feedback Interface zum Bewegen der Fortschrittsanzeige. Dabei achtet der Server darauf nicht zu oft feedback zusenden.
Eingabebereiche dürfen nicht unmotviert überdeckt oder verschoben werden. Bei einer Grössenänderung muss das Zentrum (=Position des Eingabe-Cursors) beibehalten werden.
Eine Variante des Feedback-Interfaces ist einfach eine "Diagnose.txt" die nach Abschluss der Funktion üder den Dateisystem-Sync übertragen ist.
Info Texte die den Sinn des aktuellen Eingabefeldes beschreiben müssen oberhalb des EIngabefeldes stehen, es muss damit gerechnet werden dass ein Touch Keyboard direkt unter dem Eingabefeld eingeblendet wird.


Das feedback Interface ist analog zur XMLRPC Schnittstelle definiert. Sie kann also auch "remote" ablaufen:
==== §6 Klicksichtbarkeit ====


feedback :    TXMLRPC_Method;
Ein Klick auf Controls, die erst wenige ms sichtbar sind, darf nicht als Eingabe gewertet werden. Also wenn ein neu sichtbares Fenster eine alte GUI überdeckt und sich der Benutzer für einen Klick entschieden hat darf das neue Fenster diesen Klick-Event nicht verarbeiten.
TXMLRPC_Method = function(sParameter: TStringList): TStringList of object;


==== §7 Reaktivität ====


* '''Log(s)''' gibt s als Log aus
Die GUI darf niemals auf Ergebnisse des Arbeitsprozesses warten, der Job wird an der Theke abgegeben, die GUI ist sofort wieder aktiv.
* '''Info(s)''' gibt s als aktuelle Aktion aus
* '''Progress(BarName,)'''
* '''Inquire (s)''' Rückfrage


Im Rahmen der Ausführung eines Aufgabe (oder auch einfach so?!), sollte der Server die Möglichkeit haben eine kurze Rückfragen an den Client zu stellen. Die Ausführung stoppt so lange beim Server bis die Nachfrage beantwortet ist.
==== §8 Feedback ====
Dies könnte durch das normale Feedback INterface abgewickelt werden.


==== a penny for your Thoughts ===
Ausgelöste Aktionen ("Tastendruck", "Klick", "Mausbewegung") muss ein Feedback auf der GUI erzeugen. Es darf nicht der Eindruck erweckt werden weitere, andere, derselbe Klick wäre nochmal möglich (zero Feedback). Optimalerweise sollte ein Button-Symbol eine "Action" symbolisieren (ausführen, stempeln, senden), nach dem Auslösen der Aktion sollte es zu einem Feedback-Symbol werden (Wartesymbol, grüner Haken) das NICHT Klickbar ist.


Bei Feedback sendet der Server Pascal-Skript an den Client. Dieser muss das Ausführen.
==== §9 Pausen ====


https://jetpack.mozillalabs.com/sdk/1.0b5/docs/dev-guide/addon-development/web-content.html
Jede Eingabe muss zurückgestellt werden können. Eingaben auf anderen Formularen müssen dann möglich sein. Verbot von "Topmost". Verbot von Modal.


=== Interface-Caching ===
==== §10 Variante ====
 
Jedes Formular muss dupliziert werden können. Es muss Testeingabe / Versuche verkraften ohne dass eine Aktion durchgeführt wird, erst anschließendes "Buchen" führt zur Aktion oder eben "Abbruch"
 
==== §11 Rückgängig ====
 
Jede lokale Eingabe die noch nicht "abgeschickt" ist, muss rückgängig gemacht werden können
 
==== §12 Barrierefreiheit ====
 
https://www.heise.de/newsticker/meldung/Firefox-mit-neuen-Tools-fuer-ein-barrierefreies-Web-4571249.html
 
== Client Konzepte ==
 
=== Datenhaltung ===
 
* Tabellenwerte oder Eingabefelder sollen auf der Client Seite bereits mit dem HTML initial gehalten werden
** Die JSON Daten sind Teil des HTML und wandern in die "Lokale Datenbank"
** Dazu zusammen erhalten Sie einen ETAG, dieser kann einzeln abgefragt werden, das Resultat ist eine Info ob sich dieser ETAG geändert hat
** Ev. auch ein COntext-ID mit einem ETAG, also wenn BEIDE gleich geblieben sind ist die Version in der Datenbank noch aktuell
** Der Server soll bei Datenabfragen "ETAG" fähig sein, insbesondere für Daten-Requests, Also: Der Client frägt ein Dataset ab, ist es unverändert bekommt er nur das ETAG, das ist in der lokalen DB
* Server liefert neue Daten nicht im HTML sondern in der Form, http://abral.altervista.org/apps/libri/elibri.json.php
* Client benutzt eine Datenbank, die allen TABs zur verfügung stehen
** "Lokale Datenbank" ist https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API
** nur im Notfall frägt er es nochmals an, darf aber "kein Thema" sein und legitim (Full reload, oder was weis ich ...)


sagen wir mal, wir haben:
sagen wir mal, wir haben:
Zeile 184: Zeile 238:
wir sagten ja ein lokaler OrgaMon kann auf TodayStrings zugreifen, als wäre das lokal
wir sagten ja ein lokaler OrgaMon kann auf TodayStrings zugreifen, als wäre das lokal


== OrgaMon-GUI ==
=== fetch() ===
 
=== UI Ideen ===


ein Projekt, das zum Ziel hat den OrgaMon mit einer Plattform-übergreifenden GUI anzubieten
https://fetch.spec.whatwg.org/


[[Bild:OrgaMon-8-GUI.png]]
* Alle Server Anforderungen gehen sofort zunächst in einen Sync-Buffer
* Wenn mögich wird der Sync-Buffer Asynchron abgearbeitet
* Mit dem Server wird per fetch() gesprochen
* Ein Fetch kann misslingen
** IP Change
** Server Process Crash
** Client Internet Connection Gab
** Dies darf aber niemals zum Problem werden


==== farbige Tabs ====
=== Netzwerk ===


* Tab sind erst mal nicht da, können aber aus einem Suchbegriff oder einem Befehl frisch erzeugt werden. Wird z.B. ein Vertrag angewendet entstehen ev. ganz viele neue Beleg, ein Beleg wir als ein einzelner Tab angezeigt.
* WAMP-formatted WebSocket messages (JSON, MsgPack and CBOR) are now nicely decoded for inspection in the Network panel.
* Standard-Aktionen sind auf Tabs anwendbar und können als transaktion auf Gruppen von TAbs angewendet werden.
* Eine aktuell eingerichtete Tab-Gruppe (3 Personen und 2 Beleg und 1 Vertrag) kann in einer Tab-Historie gespeichert werden.  
* Tab-Favoriten gibt es auch, auf die "Umgeschaltet" werden kann aber auch "dazugeladen" werden kann.
* man kann mehrere Belege öffnen und gleichzeitig bearbeiten. Dazu "Zieht" man sich einen neuen Tab. Tabs aus der selben Gruppe haben die gleiche Farbe und sind immer zusammen angeordnet (Gruppe schliessen).
* Es gibt einen Neu Tab.
* Ein Langer gehaltener Klick auf einen Tab erzeugt einen "Drag"-Event


==== Tab-Funktionen ====
== Roadmap ==


Anklicken: Der Tab-Inhalt kommt nach vorne, jetzt erst wenn der TabInhalt sichtbar ist wird das kleine "close" sichtbar.
=== im Einsatz ===


==== Progressbereich ====
=== aktuell in Arbeit ===


* zeigt zentral aktuelle Wartezeiten an, im Hilfehinweis oberhalb laufen Log meldungen
* HTTP/2 HPACK (Andreas)
* ich bin unsicher, ob dies durchführbar ist, aber ich will eine Unstoppable GUI die einfach nur Anforderungen an eine Exekutive weitergibt. In dem Progressbereich stapeln sich einfach Aufgaben, die im Moment am laufen sind und noch nicht abgeschlossen (Beispiele Dafür: Tagwache auf einem Server, Tagesabschluss auf einem Server, Anwendung von Verträgen usw.)
* erste Modelle des UI (Andre)
** erster OrgaMon-Dialog ist "System"


==== Suchbereich ====
=== kommende Aufgaben ===
 
OrgaMon ist (wieder) über Hotkeys steuerbar: <ctrl>PN macht "Person" "neu" der Focus steht beim Vornamen usw.


==== blauer Aqua-Button ====
* "Eingabefeld",
* "Tabelle"


der Start-knopf des OrgaMon, hier kommen die ganzen früheren Menü Möglichkeiten
== Links ==


=== Technologie Review ===
* [[Chrome]]
 
* FreePascal GTK+ Binding
* http://wiki.freepascal.org/Qt4_binding
* http://www.rodi.dk/programming_cairo.php
* http://wiki.lazarus.freepascal.org/
* http://wiki.lazarus.freepascal.org/
* http://www.fox-toolkit.org/
* https://developer.gnome.org/gtk3/stable/gtk-broadway.html
* http://gsl.openoffice.org/vcl/index.html
* http://gsl.libreoffice.org/vcl/index.html
* http://www.phoronix.com/scan.php?page=news_item&px=ODgzMA
* http://www.phoronix.com/scan.php?page=news_item&px=ODgzMA
* http://www.micrel.cz/Dx/
* https://www.vertex42.com/blog/help/excel-help/using-unicode-character-symbols-in-excel.html
* http://www.foss-group.ch/de/Anwendungen/OSBD/
* https://uxframework.pearson.com/
 
* http://opensilvershowcase.azurewebsites.net/#/XAML_Controls
=== aktuelle Tendenz ===
* https://github.com/bigstepinc/jsonrpc-bidirectional
 
* https://www.jshero.net/home.html
OrgaMon versucht wie OpenOffice eine ganz normale Anwendung zu sein die für verschiedene Plattformen compiliert werden kann. Ev. macht sie auch Gebrauch von den jeweiligen Möglichkeiten des Betriebssystems ...
* https://theia-ide.org/
 
* https://ninjarockstar.dev/css-hex-grids/
=== UI Implementierungen ===
* Authentifizierung: https://github.com/fido-alliance/webauthn-demo
 
* CSS-Animation https://whistlr.info/2021/box-model-animation/
==== Browser-Technologie ====
* https://web.dev/progressive-web-apps/
 
* https://github.com/GoogleChrome/workbox
GUI ist immer im Browser als Web 3.0 Anwendung (HTML 5.0, jquery, JetPack), es gibt einen passiven Content-Provider, ev. eine PHP Apache-Kombination. Aktuelle Formulare sollen jedoch rein aus einem JSON Interface gewonnen werden, die Kommunikation erfolgt direkt zwischen XMPRequest und dem aufgebohrten cXMLRPC (der ja auch mal unter Linux laufen soll).
* https://stackoverflow.blog/2022/03/28/picture-perfect-images-with-the-modern-element/
 
* https://frontend.horse/articles/realistic-art-with-css/
* Wie das Design der Fomulare erfolgen soll weiss ich noch nicht (also mit welcher IDE, XML Definitionen, ...)
* https://designmodo.com/html-css-emails/
* Die Bedienelemente sollen ganz einfach beginnen und dann Schritt für Schritt mächtiger werden
* OpenSSL will do QUIC-Server https://github.com/openssl/openssl/blob/feature/quic-server/doc/man7/ossl-guide-quic-server-block.pod
* In einer Übergangsphase soll ein Webkit in den OrgaMon.exe integriert werden (der OrgaMon wird z.B. auch einen Magnetstreifen scannen müssen, oder Datensicherung machen, oder den Computernamen abfragen, oder?)
* https://cockpit-project.org/
 
* https://cloudscape.design/get-started/integration/using-cloudscape-components/
==== OrgaMon ====
* https://www.youtube.com/watch?v=8p5SDI4TNDc
* https://github.com/nacular/doodle
* SQLite: https://developer.chrome.com/blog/sqlite-wasm-in-the-browser-backed-by-the-origin-private-file-system/
* WebUI: https://www.patternfly.org/v4/
* https://www.youtube.com/watch?v=nkI8QanTjLs
* https://green-hill.srl/
* https://publish.illinois.edu/hpvm-project/


Ein vollständiger OrgaMon.exe läuft beim Kunden. Die wesentlichen Funktionen laufen jedoch über remoteable APIs.
=== noch zu lesen ===
dabei wird das caching Projekt mit der etag Technologie verknüpft. Auf Server-Seite läuft ein eigener Webserver mit ETAG Funktionalität


http://developer.yahoo.com/performance/rules.html
* https://solovyov.net/blog/2020/a-tale-of-webpage-speed-or-throwing-away-react/
* https://web.dev/local-fonts/
* https://skia.org/
* https://developer.chrome.com/blog/colrv1-fonts/
* https://www.leemeichin.com/posts/yes-i-can-connect-to-a-db-in-css.html
* https://css-tricks.com/getting-started-with-the-file-system-access-api/
* https://developer.chrome.com/docs/workbox/
* https://gitlab.engr.illinois.edu/llvm/hpvm-release
* https://web.dev/state-of-css-2022/
* https://www.solidjs.com/
* https://medium.com/@lodestar-design/the-dark-yellow-problem-in-design-system-color-palettes-a0db1eedc99d
* https://motif.land/blog/syncing-text-files-using-yjs-and-the-file-system-access-api
* https://jenniferdaniel.substack.com/p/what-is-black-and-white-and-read?s=r
* https://www.smashingmagazine.com/2022/05/you-dont-need-ui-framework/
* https://stackdiary.com/centering-in-css/

Aktuelle Version vom 3. November 2024, 15:32 Uhr

  • Dies ist die Konzept-Sammlung für die nächste Version des OrgaMon 9, "OrgaMon Polyzalos"
  • OrgaMon setzt wo immer möglich die Programmiersprache "Object-Pascal", auch bei Dingen die in Wirklichkeit als "JavaScript" im Browser des Anwenders laufen (CrossCompile).
  • Als Compiler wird nur noch Free-Pascal eingesetzt, Wegfall von "Delphi"
  • Es werden nur noch Open-Source Komponenten eingesetzt
  • Die mit der Delphi-IDE erstellte UI entfällt, der cOrgaMon übernimmt die Funktion eines WebServers und führt Funktionen des eCommerce-Kernel aus
  • dazu ist das HTTP2-Projekt ein wesentlicher Anteil von OrgaMon 9 Polyzalos
  • cOrgaMon wird vorrangig auf Linux Maschinen installiert, unter systemd als (Type=notify) mit "READY=1" nach lesen der ini
  • der eCommerce-Kernel soll Schritt für Schritt Kopplungspunkte bekommen wobei Kunden dann Anpassungen machen können. Das Customizing sollte aber auch wieder Open-Source sein und auch Test-Cases beinhalten so dass es für andere Kunden Regeressionsfrei bleibt.
  • Die Lazarus-IDE soll auch für Kunden eine Möglichkeit sein, auf den Code Einfluss zu nehmen. Dabei soll die neue Paket-Verwaltung von Lazarus den cOrgaMon mit wenigen Klicks "installieren" können

OrgaMon UI

User Interface (UI) Ideen

ein Projekt, das zum Ziel hat den OrgaMon mit einer Plattform-übergreifenden GUI anzubieten

farbige Tabs

  • Tab sind erst mal nicht da, können aber aus einem Suchbegriff oder einem Befehl frisch erzeugt werden. Wird z.B. ein Vertrag angewendet entstehen ev. ganz viele neue Beleg, ein Beleg wir als ein einzelner Tab angezeigt.
  • Standard-Aktionen sind auf Tabs anwendbar und können als transaktion auf Gruppen von TAbs angewendet werden.
  • Eine aktuell eingerichtete Tab-Gruppe (3 Personen und 2 Beleg und 1 Vertrag) kann in einer Tab-Historie gespeichert werden.
  • Tab-Favoriten gibt es auch, auf die "Umgeschaltet" werden kann aber auch "dazugeladen" werden kann.
  • man kann mehrere Belege öffnen und gleichzeitig bearbeiten. Dazu "Zieht" man sich einen neuen Tab. Tabs aus der selben Gruppe haben die gleiche Farbe und sind immer zusammen angeordnet (Gruppe schliessen).
  • Es gibt einen Neu Tab.
  • Ein Langer gehaltener Klick auf einen Tab erzeugt einen "Drag"-Event

Tab-Funktionen

  • Anklicken: Der Tab-Inhalt kommt nach vorne, jetzt erst wenn der TabInhalt sichtbar ist wird das kleine "close" sichtbar.
  • Schliesst man den Browser mit offenen Tabs muss am nächsten Tag ein reconnect erfolgen mit allen Inhalten parat!!!

Tabellen

  • Spaltenbreiten sollen gezogen werden können oder "auto"
  • Titel ^v wenn Hoch + Runter zu sehen ist, dann ist KEINE Sortierung aktiv
  • Titel v aufsteigende Sortierung
  • Titel ^ absteigende Sortiertung
  • Spaltenlayout soll auf "default" zurückgesetzt werden können
  • Spaltenlayout, wie es im Moment ist, soll gespeichert werden können
  • 1. Rang, 2. Rang: Idee : Ev. durch den vertikalen Abstand zur Tabelle den Rang symbolisieren, also je höher desto hochrangiger
  • Markieren sollte immer gleich funktionieren, "M" dann wird es blau ...

Progressbereich

  • zeigt zentral aktuelle Wartezeiten an, im Hilfehinweis oberhalb laufen Log meldungen
  • ich bin unsicher, ob dies durchführbar ist, aber ich will eine Unstoppable GUI die einfach nur Anforderungen an eine Exekutive weitergibt. In dem Progressbereich stapeln sich einfach Aufgaben, die im Moment am laufen sind und noch nicht abgeschlossen (Beispiele Dafür: Tagwache auf einem Server, Tagesabschluss auf einem Server, Anwendung von Verträgen usw.)

Suchbereich

  • OrgaMon ist (wieder) über Hotkeys steuerbar: <ctrl>PN macht "Person" "neu" der Focus steht beim Vornamen usw.
  • Kann man die oft in Anleitungen oder Bugreports verwendeten Bedienungsketten, also Eingaben benutzten?
  • Baustelle 🠖 Reiter "Verfügbar" 🠖 Haken bei [v] Senden 🠖 Button OK

SVG woimmer es geht

blauer Aqua-Button

der Start-knopf des OrgaMon, hier kommen die ganzen früheren Menü Möglichkeiten

ARIA Keyboard Support

Datenbank Edits

Textfeldfarben

weiss: kam so vom server
rosa: ist auf dem Server inzwischen anders
gelb: wurde hier local verändert

es soll so sein, dass eine edit gruppe einen ID bekommt, wenn der DB-Server eine Änderung der Dateninhalte erkannt hat, soll die Ungültigkeit dieser ID durch einen Farbwechsel in GUI angezeigt werden. Die dazugehörige Notification sollte per PUSH Technologie von HTTP/2 erfolgen. Dies ist aber unmöglich, da PUSH von Chrome gar nicht unterstützt wird, es ist auch so, dass es im "Service Worker" hier sicher andere Möglichkeiten gibt.

UI Implementierung

  • 22.12.2016: Das Konzept des OrgaMon 9 steht:
  • GUI ist ...
  • immer ein Chrome-Client ab Rev. 119+
  • immer https:// (HTTP/2)
    • immer window.isSecureContext
  • immer html5 und JavaScript, immer generiert aus eigenen Quellen, nach Möglichkeit keine Meta-Ebene auf dem Client, alles direkt und "nativ"
  • kein HTTPS Server dazwischen (z.B. Apache oder nxing)
  • eigene Session Verwaltung über die Datenbank
  • Die Bedienelemente sollen ganz einfach beginnen und dann Schritt für Schritt mächtiger werden
  • Als Icons sollen immer SVG Symbole verwendet werden
  • Ein erster Start könnte https://github.com/xtermjs/xterm.js sein
  • ag-grid könnte für data Grids eine gute Ersparniss sein
  • dabei soll mit Hilfe des Codes von Michael Van Canneyt JavaScript für den Client aus Pascal Programmierung erstellt werden, die JavaScript Tatsache soll versteckt bleiben

automatisierte Tests

Asynchrone UI

  • Also ein gedrückter Knopf bedeutet
    • sofortige Deaktivierung, das ist das Feedback für die Annahme des Auftrags des UI
    • die UI darf nicht blockieren, weitere Knöpfe sind weiterhin aktiv
    • folgender Status Feedback, dass der Request in die Datenbank eingetragen ist
    • folgender Status Feedback, dass der Request zum Server übertragen werden konnte (mit Offline-Zeiten ist hier zu rechnen, das darf kein Problem sein)
    • folgender Status Feedback, dass eine Antwort des Servers da ist mit neuem Status für diesen Button (Ein Erfolg, Ein Misserfolg, ein Fortschritt)

erste Schritte

  • ein Fenster mit einer Schaltfläche:
  • ein Text-Editfeld das mit einer Datenbank verbunden ist

offene Fragen:

  • Unter Linux hätte ich gerne eine "ordentlichen" systemd Integration also
    • Running-Notfification, Ini-Read Successfully oder "Die"
    • Watchdog-Notification, alive or being killed
    • Info about a HANDLE, also accept() soll systemd machen, wir bekomme einfach im Programms
HTML5-
Client  <--https/2--> systemd Socket Activation <---sd_listen_fds()---> hOrgaMon Web Server    <--fbclient----> FirebirdSQL
                                                                        (links libsystemd.so)   +--file I/O---> .\OrgaMon\

Das User-Interface-Grundgesetz

Im Zentrum einer GUI müssen unverhandelbare Grundrechte des Benutzers / Bedieners stehen. Die Optik des UI muss klare Signale an den Benutzer senden so dass dieser sich 100% auf Funktionen des Interface verlassen kann. Auswüchse die es im Moment gibt (Wir sind immer noch in der IT-Steinzeit) müssen verhindert werden. Ich will für die Tatsache sensibilisieren das heute Webinhalte den User im Unklaren lassen was er auf einem Screen machen kann. Grafisch möglicherweise perfekt muss er erst mal mit der Maus rumsuchen was anklickbar ist. Wenn er dann anklickt kommt kein Feedback. Er muss nun hoffen dass sich was tut in den nächsten 5 Sekunden.

Negativ-Beispiele die vermieden werden sollen

  • Beispiel: Edge: Während man in der Adresszeile des Browsers ist wechselt der Eingabefokus in ein anderes Control
  • Beispiel: Bevormundung: Verschiedene Programme: Eine Eingabehilfe ergänzt die Eingaben "i" zu "intelligent". "i" <ENTER> ergibt also den Eingabewert "intelligent". Man muss "i" <BLANK> <BS> <ENTER> eingeben um einfach nur "i" zu erhalten, das darf nicht sein!
  • Beispiel: Delphi: Suchbegriffe werden immer vervollständigt, will man nur nach "S" suchen, ist die Eingabe nicht möglich. "S" <Enter> sucht nach "String", da "S" nach "String" vervollständigt wird.
  • Beispiel: Man Klickt auf ein Button, jedoch wenige ms zuvor überdeckt ein unmotiviert eingeblendetes Fenster den Button, nunmehr verarbeitet dieses neue Fenster den Click auf einen zufällig deckungsgleichen Button. Und das obwohl eine gewolltes Anklicken gar nicht möglich ist.
  • Beispiel: App "VR Networld Banking": Ist die App lange unbenutzt läuft die Session im Hintergrund ab, es ist keine Verbindung mehr vorhanden. Beendet man jetzt die App kommt die Frage "Abmelden"
  • Beispiel: App "VR Networld Banking": Besteht eine Session, diese hat aber keine Fokus, und es kommt eine Pushj nachricht wird man in einen neuen Anmeldeschirm geleitet obwohl eine gültige Session da ist. Es wird eine weitere Instanz der App gestartet anstelle den Eingabefokus auf die laufende aktuelle Session zu lenken
  • Beipsile: App "VR Networld Banking": geht der Anmeldevorgang sehr lange und das Handy schaltet das Display ab wird der anmeldevorgang nicht im Hintergrund zuende geführt, es gibt einen "technischen" Fehler. Ich muss immer aufs Display tippen um die App am Leben zu halten solange sie sich anmeldet.
  • Beispiel: App "VR Secure Go": Wird eine TAN erhalten verdeckt ein Fenster "aktualisiere Push Daten" diese TAN
  • Beispiel: Unwetterzentrale: man sieht eine karte, oben ist die Werbung am Laden, man klickt auf die Karte just in dem Moment rattert die Karten nach unten, man triff einen Bereich mit dem Klick, den man nicht wollte
  • Beispiel: Cookie-Warnungen: Wichtige Teile der Seite werden einfach überblendet, es ist keine echte Position für die Meldung vorgesehen
  • Beispiel: interne App-Makros: Apps werden intern teilweise durch Klicks gesteuert. Beispiel tunein Radio-App, mann wählt seinen Sender und sieht das "Play" Symbol. Eine Sekunde lang passiert nichts. Dann per Geisterhand dreht sich plötzlich das Rad. Der Playknopf wurde intern gedrückt, jetzt spielt das Radio los. Besser wäre es gewesen den Screen mit dem "Rad" zu beginnen, ev. mit dem Pause Symbol.

§1 Klickbarkeit

Ist ein Text oder ein Bild oder ein Icon anklickbar, so muss es in einer deutlich sichtbaren Weise grafisch anders ausgeprägt werden, dass dies deutlich wird. Bei einem MoveOver muss sich auch der Zeiger ändern. Ein Button muss von einem immer gleichen Rahmen umfasst sein, innerhalb des Textes muss "["Begriff"]" stehen oder #Begriff. Unterstreichen ist keine erlaubte Link-Symbolisierung. Einfärben (es wird gerne "Blau" genommen) ist keine erlaubte Link-Symbolisierung.

§2 Bewegungsmelder

Die beobachtete Fläche muss klar ausgewiesen werden. Bei MouseEntry / Leaf muss optisch die Fläche aufleuchten (ON/OFF). Bei ON darf die Fläche nicht verschoben werden, die GUI muss fixiert werden. Bei ON dürfen umliegende Bereiche verändert werden, bei OFF muss der "Originalzustand" wieder herstellt werden.

§3 Fokus

Der Eingabefokus darf niemals programmgesteuert dem aktuell sichbaren Eingabefeld entzogen werden, während die GUI Benutzereingaben erwartet. Das Einblenden eines Meldungsfensters während der Benutzer eine Eingabe tätigt ist ein solcher Fokusentzug. Ein Notifikationsbereich der sich verändert ist erlaubt.

§4 Eingabesicherheit

Direktes Abändern/Verfälschen der Eingabe, also automatisches Vervollständigen, automatisches Setzen eines Punktes usw. ist nicht erlaubt.

§5 Sichtbarkeit

Eingabebereiche dürfen nicht unmotviert überdeckt oder verschoben werden. Bei einer Grössenänderung muss das Zentrum (=Position des Eingabe-Cursors) beibehalten werden. Info Texte die den Sinn des aktuellen Eingabefeldes beschreiben müssen oberhalb des EIngabefeldes stehen, es muss damit gerechnet werden dass ein Touch Keyboard direkt unter dem Eingabefeld eingeblendet wird.

§6 Klicksichtbarkeit

Ein Klick auf Controls, die erst wenige ms sichtbar sind, darf nicht als Eingabe gewertet werden. Also wenn ein neu sichtbares Fenster eine alte GUI überdeckt und sich der Benutzer für einen Klick entschieden hat darf das neue Fenster diesen Klick-Event nicht verarbeiten.

§7 Reaktivität

Die GUI darf niemals auf Ergebnisse des Arbeitsprozesses warten, der Job wird an der Theke abgegeben, die GUI ist sofort wieder aktiv.

§8 Feedback

Ausgelöste Aktionen ("Tastendruck", "Klick", "Mausbewegung") muss ein Feedback auf der GUI erzeugen. Es darf nicht der Eindruck erweckt werden weitere, andere, derselbe Klick wäre nochmal möglich (zero Feedback). Optimalerweise sollte ein Button-Symbol eine "Action" symbolisieren (ausführen, stempeln, senden), nach dem Auslösen der Aktion sollte es zu einem Feedback-Symbol werden (Wartesymbol, grüner Haken) das NICHT Klickbar ist.

§9 Pausen

Jede Eingabe muss zurückgestellt werden können. Eingaben auf anderen Formularen müssen dann möglich sein. Verbot von "Topmost". Verbot von Modal.

§10 Variante

Jedes Formular muss dupliziert werden können. Es muss Testeingabe / Versuche verkraften ohne dass eine Aktion durchgeführt wird, erst anschließendes "Buchen" führt zur Aktion oder eben "Abbruch"

§11 Rückgängig

Jede lokale Eingabe die noch nicht "abgeschickt" ist, muss rückgängig gemacht werden können

§12 Barrierefreiheit

https://www.heise.de/newsticker/meldung/Firefox-mit-neuen-Tools-fuer-ein-barrierefreies-Web-4571249.html

Client Konzepte

Datenhaltung

  • Tabellenwerte oder Eingabefelder sollen auf der Client Seite bereits mit dem HTML initial gehalten werden
    • Die JSON Daten sind Teil des HTML und wandern in die "Lokale Datenbank"
    • Dazu zusammen erhalten Sie einen ETAG, dieser kann einzeln abgefragt werden, das Resultat ist eine Info ob sich dieser ETAG geändert hat
    • Ev. auch ein COntext-ID mit einem ETAG, also wenn BEIDE gleich geblieben sind ist die Version in der Datenbank noch aktuell
    • Der Server soll bei Datenabfragen "ETAG" fähig sein, insbesondere für Daten-Requests, Also: Der Client frägt ein Dataset ab, ist es unverändert bekommt er nur das ETAG, das ist in der lokalen DB
  • Server liefert neue Daten nicht im HTML sondern in der Form, http://abral.altervista.org/apps/libri/elibri.json.php
  • Client benutzt eine Datenbank, die allen TABs zur verfügung stehen

sagen wir mal, wir haben:

type
 DataModuleeCommerce = class(GhostAbleInterface)
 
 published
  TodaySettings : TStringList;
 end;

wir sagten ja ein lokaler OrgaMon kann auf TodayStrings zugreifen, als wäre das lokal

fetch()

https://fetch.spec.whatwg.org/

  • Alle Server Anforderungen gehen sofort zunächst in einen Sync-Buffer
  • Wenn mögich wird der Sync-Buffer Asynchron abgearbeitet
  • Mit dem Server wird per fetch() gesprochen
  • Ein Fetch kann misslingen
    • IP Change
    • Server Process Crash
    • Client Internet Connection Gab
    • Dies darf aber niemals zum Problem werden

Netzwerk

  • WAMP-formatted WebSocket messages (JSON, MsgPack and CBOR) are now nicely decoded for inspection in the Network panel.

Roadmap

im Einsatz

aktuell in Arbeit

  • HTTP/2 HPACK (Andreas)
  • erste Modelle des UI (Andre)
    • erster OrgaMon-Dialog ist "System"

kommende Aufgaben

  • "Eingabefeld",
  • "Tabelle"

Links

noch zu lesen