[Allegro] InnovationsInitiative ZwanzigZehn: FreiRaum schaffen

[Bernhard Eversberg]

InnovationsInitiative ZwanzigZehn: FreiRaum schaffen

*Vorweg*
Ob, wo "Nano" draufsteht, auch Nano drin oder dran ist, kann der
Normalverbraucher mangels eines geeigneten Mikroskops (besser gesagt
"Nanoskops") nicht verifizieren. Der alte Römerrat "Caveat emptor"
ist in dieser Sache prohibitiv teuer. Der Versuchung, auf diese
Modewelle aufzuspringen, wollen wir füglich entsagen. Man muß, will
man glaubwürdig bleiben, seine Schlagwörter schon selber erfinden.
Uns ist zugleich aber bewußt:
Wenn am 1. April eine Meldung aus unserem Hause erscheint, wird sie mit
leicht angehobener Augenbraue aufgenommen - allzu oft wurde an diesem
Datum haarsträubender Unfug verbreitet; wobei aber stets die Phantasie
nicht gereicht hatte, restlos *alles* zu erfinden, sondern irgendwie
war immer noch was dran an der Sache, und das war ja wirklich der
Gipfel der Irritation. So soll's diesmal nicht sein! Naja, könnte der/
die LeserIn sagen, bringt doch die Meldung einen Tag früher oder
später, dann entfällt die Versuchung zum Unfugverzapfen und damit die
Irritation. Das aber wäre Kapitulation vor dem Aberglauben, vor der
naiven Suggestivität eines Datums, und das ginge denn doch zu weit.
Wir gehen, Tradition hin oder her, heute mit besten Absichten zu Werke.

*Worum geht's?*
Wer's total eilig hat, kann hier kurz reinblicken:

   http://www.allegro-c.de/doku/a30/freiraum.htm

da werden schon die Grundgedanken holzschnittartig skizziert, sonst
lesen Sie erstmal weiter.
Vor das gehobene Fahrvergnügen mit a30 haben die Entwickler die Mühe
und die Kryptik des Konfigurierens gesetzt.
Was man sowieso schon alles einzurichten, einzustellen und zu berück-
sichtigen hat, das geht eh auf keine Kuhhaut, ist doch wahr!
Als a30 hinzukam, mochte sich hier und da schon jemand am Rande
der Bahnsteigkante fühlen, das Schlußlicht des Anschlußzuges
im wabernden Wissensqualm kaum noch auszumachen...
Zwar haben wir mit einer "Fortbildung" die Situation zu entschärfen
gesucht, und es wäre ja schön und gut, wenn man tatsächlich nur
noch FLEXen müßte, um eigene Anwendungen und Erweiterungen zu
erstellen. Jedoch dürfte sich a30 - eher öfter als seltener - als
immer noch recht begrenzt erweisen, je mehr man sich vom Standard
emanzipieren will. Vor allem die Interaktivität ist das Problem:

*Was wird gebraucht?*
Man will dem Endnutzer immer mehr und immer mächtigere Werkzeuge an
die Hand geben, aber die müssen auch handlich und handhabbar sein,
ohne Handbuch und Fortbildungsseminar und all solchen Zauber! Mehr
als eine handvoll Sachen sollte sich niemand merken müssen; es gehört
Hand gelegt an die Wurzel des Übels der Komplexität, wenn einem nicht
das Heft des Handelns ganz abhanden kommen soll!

*Was also tun?*
Abermals wurde im engeren Zirkel Konzept um Entwurf um Vision ersonnen,
Paradigmen gewechselt, verfochten und verworfen. Unter dem Arbeitstitel
"FreiRaum" blieb dann eines übrig, das den Kriterien "einfach, aber
nicht primitiv" und "flexibel, aber nicht ausufernd" am nächsten kam,
ohne in prahlerische Metaphorik zu verfallen.

*Aber wie?*
"Es ist doch immer so:", beginnt das neue Konzept ganz bodenständig,
"Man will vom Nutzer eine oder mehrere Angaben abfragen, und dann soll
damit irgendwas getan werden. Nutzereingaben gehen mit Textfeldern,
Auswahllisten, Schaltern usw., Aktionen werden mit Buttons oder
ähnlichem ausgelöst. Ja zum Kuckuck, man muß doch dazu nur den
Einrichter ermächtigen, alle möglichen Eingabevorrichtungen in einem
Feld frei plazieren zu können, und dazu den oder die Buttons, hinter
denen dann jeweils ein Universal-Job steckt, geschrieben in FLEX, von
der Entw.Abt." Soweit das Konzeptvorwort, und weit hergeholt ist die
Idee wahrlich kaum, sogar nicht einmal wirklich neu, wenn wir's recht
erinnern.

*Worauf können wir aufsetzen?*
a30 bringt zwar schon zwei Ansatzpunkte mit:
a) eine sehr einfache Syntax, mit der die Inhalte und die Zustände
    der Oberfläche gesteuert werden
b) Start beliebiger Jobs aus jeder Situation heraus, wobei die
    Jobs wiederum beliebige Elemente der Oberfläche mit neuen Daten
    beliefern.
Einiges an der Struktur der Oberfläche selbst ist ebenfalls
variabel:
1. Die Formulare unter dem FORM-Tab
2. Das System-Menü
3. Das mit schlichtem HTML zu gestaltende Menü unter dem MENU-Tab
4. Einbezug von JavaScript für z.B. Validierungen, womit man
    um Eingriffe in das ActionScript-Programm von a30 herumkommt,
    aber nur mit guten JavaScript-Kenntnissen.
5. In der Datenanzeige können Hyperlinks gesetzt werden, aber
    auch nur mit FLEX oder gar Parametrierung.

*ABER!*
Die Formulare sind leider allzu wenig flexibel und richtig einfach
zu erstellen und handhaben auch nicht, und das Menu-Tab kann keine
HTML-Formulare und -Buttons usw. darstellen. Und das "Grid" wirkt in
seiner rigiden Tabellarität schon gar nicht multifunktional.
Die oben umrissene Vision von Freiheit und Abenteuer kann also mit
diesen Mitteln noch nicht Realität werden.

*"Was her muß", *
so wird das Konzept dann messerscharf konkret, "ist ein neues Tab!
Darunter muß ein Raum sein, in dem man eben ganz frei alle nötigen
Elemente anordnen kann und ihnen Funktionen (Jobs) zuordnen!"
Kurz: ein FreiRaum wird gebraucht - wie der Name schon sagt, und
eine neue Methodik, mit der man darin, schnell mal eben und ganz
leicht, ein komplexes Formular mit allem, was nötig ist, frei
arrangieren kann. Es wurden schnell mal zwei Muster angefertigt,
damit man sich was vorstellen kann unter "komplexes Formular" und
"frei arrangieren"; hier nochmal der Einblick:

   http://www.allegro-c.de/doku/a30/freiraum.htm

Und dann kommt das Konzept erst richtig zur Sache:
(und Sie erkennen gleich, warum hier die Versuchung erwachsen könnte,
das Nano-Modewort kreativ nachzunutzen)

*Forderung Nr.1* für den FreiRaum: *Minimalstmöglicher Lernbedarf*
Wer im FreiRaum was arrangieren will, soll nicht erst FLEX lernen
müssen, von "Adobe Flex" ganz zu schweigen.
a30 war ja schon marktschreierisch angepriesen worden mit dem Argument,
man müsse damit weder PHP noch JavaScript können, sondern nur noch
allegro FLEX. Da setzen wir noch eins drauf mit dem FreiRaum, indem
wir für den Normalfall auch FLEX noch an den Rand drängen!

*Das 2.wichtigste Prinzip* lautet: Schlichte Aufgaben müssen extrem
leicht zu lösen sein - so leicht, daß es *leichter nicht denkbar* ist!
Und zehn Minuten sollten genug sein auch für eine mittelschwere Sache.

Als *3. Prinzip* kommt hinzu: Alles, aber wirklich alles, was nicht
*zwingend* nötig ist, kann weggelassen werden und wird dann durch
Defaults ersetzt. [Eine zeitgemäße Anwendung des aus der Philosophie
altbekannten Prinzips von William Ockham (sog. "Occam's Razor"). Und
auch der Satz von Montesquieu über die Gesetze, die man nicht machen
sollte, ordnet sich hier ein.]

Und *4. ist ein Paradigmenwechsel angesagt:*
An die Lösung ist erstmals *nicht von der Programmiererseite* aus
heranzugehen, sondern von der Seite des Einrichters (Systemverwalters),
der ja nur zu oft kein Allegrologe ist und gern intuitionsbasiert
statt kenntnislastig arbeitet. Nicht hinzunehmen ist also letztlich
die irritierende Kluft zwischen Wünschen und Können.

Die ersten, tastenden *Vorüberlegungen* fanden im Brainstorming-Raum
statt, und im Protokoll des Initiativmeetings - erstmals legen wir ein
solches Dokument offen - können Sie hier verfolgen, wie sich die neuen
Spezifikationen Punkt für Punkt herausschälen, immer getrieben von den
Wunschvorstellungen eines (namentlich ungenannten) Einrichters:

******* PROTOKOLL Initiativmeeting 2010-04-01 *******
(1)
Gehen wir mal aus von einer sehr schlichten Aufgabe: Der Endanwender
soll den angezeigten Datensatz bearbeiten können, aber nur die Felder
#90, #20, #40, #75  - mehr nicht.
Wie soll der Einrichter das dann konfigurieren müssen? "Extrem leicht"
dürfte man es nur nennen, wenn er dazu nur irgendwohin zu kritzeln
hätte:
#90
#20
#40
#75
und sonst *NICHTS*! (Oder ging's noch einfacher? Mit XML vielleicht?)
Hm, Prinzip 3 könnte fordern, daß auch das # noch fortlaßbar wäre. Das
jedoch hat mit der Identität des Systems zu tun, mit seiner Erkennbar-
keit, deshalb verbietet es sich.

(2)
Aber was ist mit den Feldbezeichnungen? Dem Bearbeiter wird man nicht
die Kategorienümmerchen als Beschriftung des Formulars zumuten wollen!
Na, die Feldbezeichnungen stehen doch in der CFG, da kann das System
sie selber rausholen und im Formular vor die Felder setzen!

(3)
Hmnja, wenn aber ein Feld im Formular eine andere Beschriftung kriegen
soll? Dann diese kurzerhand dahinterschreiben; das Programm soll das
dann nehmen statt der CFG-Bezeichnung:

#76 Jahr      [statt "EJahr", wie's in der CFG steht]

(4)
Und wenn es mehr Felder sein sollen, z.B. mehr als 14? Dann die
Liste verlängern. Unbegrenzt, was sonst, geht nich gibt's nich!

(5)
Nur, Halt!, bei sehr langen Formularen sollte man Zwischenüberschriften
einschieben können, das verbessert die Übersicht. Wie könnte das gehen?
Am einfachsten wär, sie schlicht dazwischenzuschreiben zwischen die
Kategorienummern; aber damit's nicht zu monoton wird, mit HTML-Attri-
buten versehen, also schlicht sowas wie diese Zeile:

#85
<i><b>Sonstige Angaben:</b></i>
#81

Und analog auch obendrüber ne Schlagzeile in größerer, roterer Schrift.
(Schwarz ist ja, soll eine Kanzlerin mal gesagt haben, das dunkelst-
mögliche Rot.)

Und wie könnte man noch was HINTER ein Eingabefeld schreiben?
Auch wieder (auf eigener Zeile) mit + am Anfang:

#nnn
+ Text

(6)
Tja, unbedingt muß man auch mal 2, 3 Felder NEBENeinander setzen können,
statt alles stur UNTEReinander. Dann paßt mehr in das sichtbare Feld.
Gut, das ginge am einfachsten so, hier mit der #76:

<b>Bearbeitungsformular</b>
#90
#20
#40
<i>Sonstige Angaben</i>
#75
+#76

Dann erschiene #76 samt seiner Bezeichnung rechts neben #75, ansonsten
alles untereinander, in der angegebenen Reihenfolge.

(7)
Paßwörter! Dafür braucht man ein Eingabefeld, in dem *** statt xyz
erscheint. Kein Problem, dafür wäre dann zu schreiben
*nnn   statt   #nnn    bzw.
+*nnn  statt   +#nnn

(8)
Na schön, aber einige Felder sind ja sehr kurz, andere sehr lang.
Es muß möglich sein, die Länge der Eingabefelder zu variieren! Die
"alten" Formulare sind langweilig, alle Felder gleich lang...
Was wäre da die einfachste Syntax? Keinem fiel was Einfacheres ein,
als die gewünschte Länge hinter diejenigen Feldnummern zu schreiben,
bei denen sie vom Standard (z.B. 400 Pixel) abweichen soll:

#20 700
#40
#75 90
+#76 20 Jahr
#90 50

Die Zahlen sollen Pixel bedeuten, nur so ist echtes Finetuning möglich.
(Überschlägig ist ein Zeichen 6 oder 7 Pixel breit.)
Und dann, aber das versteht sich von selbst: wenn #20 doch mal länger
ist als 400, muß der Text eben im Feld "scrollen". Oder besser gesagt:
Wenn eine gewisse Länge überschritten wird, sollte das Programm ein
passend großes mehrzeiliges Eingabefeld machen, ebenfalls scrollfähig.

Und natürlich muß man auch mehrere Datenfelder samt Kategorienummern
in *einem* Eingabefeld anzeigen und bearbeiten können, wobei sie nach
der Absendung wieder sachgerecht zerlegt werden - das wird ja wohl
*irgendwie* zu machen sein... Für die eingefleischten PRESTO-Fans ist
das geradezu eine conditio sine qua non, nebenbei bemerkt. Damit könnte
man sie - wenn überhaupt mit was - endlich von diesem klapprigen Oldie
mal weglocken!

(9)
Unterfelder, logo, müssen auch leicht einbeziehbar sein. Das kann
einfachstmöglich nur so aussehen:

#90$u Entleiher
+#90$D Entleihdatum

(10)
Dann noch die Hilfestellung! Jedem Eingabeelement muß man einen
ToolTip beigeben können, der bei Berührung mit der Maus erscheint.
Irgendein frei formulierbarer Text, längenmäßig nicht begrenzt.
Einfachste Lösung? So:

#90  50
tip Auf richtige Anzahl Stellen und korrekte Schreibung achten!
#20 700
tip Titel des Dokuments (Haupttitel : Zusatz)
#40
tip Erster Verfasser (Form: Nachname, Vorname)
#75  80
tip Verlagsname, wie er im Buche steht
+#76 24 Jahr
tip Erscheinungs- oder Entstehungsjahr

Die Zahl muß man natürlich weglassen können, dann wird eben dafür
der Standard genommen. (Leerzeichen hier nach Belieben, von wegen der
Übersichtlichkeit - sie haben keine Wirkung.)

(11)
Doch auch, indem wir dieses niederschreiben,
hört's noch nicht auf, wir müssen's weiter treiben:
Wenn man schon mal dabei ist, dann bitteschön gleich noch ein paar
nette Elemente bereitstellen:

1. Einen Datumswähler, d.h. so ein Kalenderchen, mit dem man ein Datum
    auswählen kann.

2. Eine Checkbox zum Anhaken für solche Fälle, wo eine ja/nein-Eingabe
    gebraucht wird.

3. Eine ComboBox: Das ist eine Auswahlliste, aus der man vorgegebene
    Sachen auswählen kann, z.B. eine Sprache.

Wie könnten diese Sachen am einfachsten aussehen? Wir denken, so:

Datum #nn1

Check #nn2 Text   [der Text erscheint dann rechts neben der Checkbox]

Combo #nn3
de|deutsch
de|englisch
fr|polnisch
Combo

(12)
Auch hierbei sollte noch + davor stehen können, damit das Element
auf dieselbe Zeile kommt. Auch ToolTips muß man diesen Elementen
beigeben können: einfach noch ne tip-Zeile folgen lassen.
Beim Absenden an acon würde dann #nn1 mit dem gewählten Datum belegt
(Format JJJJMMDD), und #nn2 mit dem Wert 1, falls angehakt wurde,
sonst eben 0. Und bei "Combo" landet in #nn3 der Code der ausgewählten
Zeile.

In jedem Fall müssen unbedingt auch #u-Variable verwendet werden
können, also z.B.
Check #uck Mit Sahne

(13)
Momentchen! Es gibt *zwei* Sorten Comboboxen: Solche, wo man etwas
anderes eingeben kann, wenn das Angebot der Liste nicht reicht, und
welche, wo man NUR aus der Liste auswählen kann. Wie kann das gehen?
(Mannomann, auch das noch!) Na ok, sagen wir so:

Combo #nnn|edit

und dann soll die Combobox ein freies Eingabefeld haben. Wird keine der
Zeilen aus der Liste gewählt, kommt der Inhalt vom Eingabefeld in #nnn.

(14)
Jetzt natürlich noch die Absendung! Es muß möglich sein, daß die
Daten an einen frei wählbaren Job geschickt werden, nicht immer
an denselben. Will sagen, man muß einen Rücksendebutton setzen
können. Kein Problem, ein Button könnte doch wohl am einfachsten
so konfiguriert werden:

Button Senden|jobname.typ
#90
#20
#40
#75
...

Wobei "typ" wahlweise php, pl, oder sonstwas sein kann; wenn der Typ
aber fehlt, dann  gilt .job (zu starten dann von a30ajax.php).
Damit soll a30 dann einen Button erscheinen lassen, auf welchem
"Senden" steht, und er soll den Job  jobname.job  bzw. das Skript
jobname.typ  mit den Daten des Formulars beliefern.

(15)
Wenn also ein Button nicht reicht, müssen weitere möglich sein, die
jeweils eigene Funktionen auslösen. Also dann mehrere solche Zeilen,
ruhig auch mal zwischen den Feldern irgendwo! Soll er nicht auf eine
eigene Zeile, dann + davor, siehe oben...
Setzt man gar keinen Button, soll standardmäßig einer kommen, auf dem
eben "Senden" steht und der das Skript a30put.php auslöst. Dieses muß
die Inhalte aller definierten Felder übergeben kriegen.

(16)
Ja ABER! Aus dem Formular heraus soll wahlweise ein vorhandener Satz
modifiziert ODER ein neuer angelegt werden! Wie wäre das auszulösen?
Als Standard wird dem Job automatisch die Variable #urN mit der Nummer
des aktuellen Satzes mitgegeben, wenn es aber ein Neusatz sein soll,
dann wäre die zu ignorieren. Und wie soll man das dann hier sagen?
Einfachstmöglich so:

Button Als neuen Satz speichern|NEW jobname.typ

Apropos Neusatz: Man muß leere Felder mit einer Vorgabe füllen können,
sehr wichtig! Simpler Vorschlag:

#37 50 Sprache
data de

um ein 50 Pixel breites Feld mit dem Label "Sprache" davor und dem
Inhalt "de" anzulegen.


(17)
Nicht zu vergessen: Kommentare! Eine FreiRaum-Liste könnte ja recht
lang werden, man sollte Hinweise einstreuen können, die keine Wirkung
auf die Verarbeitung haben. Einfachste und intuitivste Syntax:

// Kommentar

D.h. jede mit // beginnende Zeile ist Kommentar - wie bei den meisten
Programmiersprachen und auch bei FLEX.

(18)
Noch was? Ja, Zwischenräume! Man muß einen Befehl haben, der eine
neue Zeile einläutet und einen, der einen genauen Zwischenraum setzt.
Gut, aber keine kryptischen Symbölchen hierfür, sondern leicht merkbare
Wörter:

newline     macht eine neue Zeile auf

space 150   setzt einen Zwischenraum von 150 Pixel Breite.

(19)
Ach, die Schriftgröße noch! Es sollte dafür einen Befehl geben, dann
braucht man nicht jedesmal wieder erst eine Einstellung zu machen,
wenn einem der Standard nicht paßt. Also gut, so:

size 14
um z.B. 14 Punkt Schriftgröße einzustellen.


(20)  Schlußendlich:
Die Einbindung in das Menü muß natürlich auch superleicht sein.
Sagen wir, die FreiRaum-Liste heißt  abc.frl, in der man alles
in der hier vorgeschlagenen Weise aufgeschrieben hat. Die Zeile in
einem HTML-Menü sollte dann einfach so aussehen:

  <a href="event:F abc">Datensatz im Freiraum bearbeiten</a>

Also ein neuer event-Link mit dem Buchstaben F und dem Namen der Datei.
(Hinw.: Mit  event:X jobname  wird  jobname.job  aktiviert.)


Puh, mehr fällt uns im Moment nicht ein, aber falls ein Leser bis hier
gekommen ist, fällt dem garantiert noch was ein...

******* PROTOKOLL ENDE *******

Soweit mal die Ergebnisse der Sitzung mit der herausgeschälten
Spezifikation. Wenn sie Zustimmung findet, können wir etwa in
Jahresfrist langsam die erste Realisierungsphase initiieren.
Zuerst wird man eine fähige, junge Entwicklergruppe rekrutieren müssen.
Aber ein Anfang ist gemacht, die Innovationsinitiative eröffnet!

Mulmig wird uns nun aber doch: Ist das erst alles realisiert, können
die bisherigen Formulare entfallen, denn was die tun, ist dann alles
im FreiRaum genauso möglich! Das aber heißt, wir haben nebenbei auch
noch XML rausgekantet - können wir das wollen? Da scheint noch
Diskussionsbedarf zu sein, denn "XML-basiert", das ist doch ein
zugkräftiges Argument... Aber wie auch immer:

Wetten werden angenommen, was und wieviel aus diesem Konvolut von
Maximalforderungen sich als in vertretbarer Zeit machbar erweisen wird.

Naja, 20 Punkte sind nicht richtig viel, oder? Eine FreiRaumliste soll
im Schnitt nicht länger als 10 Minuten zum Aufschreiben kosten, und
auch das ist nicht viel. Da sehen Sie, wie wir auf "ZwanzigZehn"
gekommen sind! Sagen Sie selbst: dies nun des Effekts halber auf "Nano"
zu reduzieren wäre etwas gewagt; nicht zu sagen hanebüchener Unfug...