[Allegro] Kahlschlag!

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

>> Ich habe die einschlaegigen Verlautbarungen nun schon ziemlich oft
>> gelesen und allmaehlich beginne ich etwas zu verstehen:
>>
> Nicht nur das! Sie beginnen auch gleich zu polemisieren. Das ist nur
> akzeptabel, wenn schon etwas mehr als nur beginnendes Verstaendnis
> vorliegt.

Hm. Und ich hatte schon leichten Eisengeschmack im Mund, so sehr
hatte ich mir beim Formulieren noch auf die Zunge gebissen...


> Sie haben immer den Vorteil, sich um die Probleme der Entwicklung keine
> Gedanken machen zu muessen, sondern Ergebnisse an der Oberflaeche
> attackieren zu koennen, und den nutzen Sie weidlich aus.

Ich habe - als "Repackager" fuer allegro-HANS und allegro-NRW leider
auch den Nachteil, dass ich alle neuen Features ausprobieren muss,
die zugehoerigen Dateien identifiziere, Kompatiblitaetsprobleme mit
frueheren Versionen im Auge behalten muss und den Anwendern eigentlich
auch noch erklaeren sollte, was das alles soll. Und Konsistenz
- - gerade an der "Oberflaeche" - ist da sehr hilfreich. Aresqa hingegen,
wie im Jahr zuvor schon Janas - ist eine im Ansatz ueberzeugende Idee
gewesen, die im uebrigen alle Anwender, die davon gehoert haben,
unbedingt "haben" wollen, abgesehen von kleinen Funktions-Demos
(etwa die Editierfunktion mit Janas, die beiden Beispielflexe fuer
aresqa) entwickeln diese Features aber schnell eine Mutation - meist
zu einer "Verbesserung" der Benutzerfuehrung - und beginnen in der
Standarddistribution ein eher ueberraschendes Eigenleben.


>> aresqa (Allegro und SQL) ist realisiert durch die beiden Flexe
>> aresqa1.flx und aresqa2.flx, die in der Praxis ihre Tragfaehigkeit
>> noch beweisen muessen (derzeit wird z.B. Quatsch exportiert, wenn
>> man mit "&kkf" Kategorien als nicht zu reimportieren kennzeichnet).
> 
> Bitte genauer, wie sieht der "Quatsch" aus.

q-test.str:
>>>
&20    Tit
&40    Aut
#41    Ed
#31p   Head
#76    Year
#81    Ann
<<<
erzeugte q-test.tab:
>>>
i37     &¶      &(              Shakespeare, William    1947
i12     &¶      &(              Shakespeare, William    1957
i56     &¶      &(              shakespeare, william#   1971
i288    &¶      &(              Shakespeare, William#   1971
<<<


>> Nur: Fuer das Handling von
>> *Tabellen*daten habe ich selten ein so ungeeignetes Werkzeug gesehen:
> 
> Wir haben nicht gesagt, dass es ein solches Werkzeug sein soll! Diesen
> Ehrgeiz brauchen wir nicht zu entwickeln, es gibt ja solche Werkzeuge,
> und diese nutzen zu koennen, ist gerade das Ziel von aresqa. Das Fenster
> ist eine Zugabe, die sich dann verselbstäendigt hat: es sollte nur einen
> schnellen, kontrollierenden Einblick in die produzierte Datei erlauben,
> bevor man sie extern mit den besseren Mitteln weiterbearbeitet.

Koennte man es dann nicht schnell wieder abschaffen und durch einen
Aufruf von notepad ersetzen? Oder zumindest das Fenster nicht
ausgerechnet "aresqa" nennen, sondern "alternView" oder irgend etwas
anderes mit "a"?


>> ViewListen als Konzept waren auch eine prima Sache, der urspruengliche
>> Plan (soweit ich ihn verstanden habe) war komplexe Sortierung von
>> Ergebnismengen mit der nachtraeglichen (bzw. vor der eigentlichen
>> Exportproduktion) Option, daraus Saetze zu eliminieren. Gerade
>> letzteres, also eine Eingriffsmoeglichkeit kurz vor Schluss, ist dann
>> irgendwann wieder herausgenommen worden:
> 
> Diese Moeglichkeit ist nicht noetig, weil man sie schon im Kurzfenster
> der Erg.Menge hat, bevor man die Viewliste erstellen laesst.

Einspruch: Den "Schmutz" sieht man erst nach der Sortierung. Das war
genau die Stelle, an der die Views das Potential zur Killer-Applikation
(damals ging es darum, Anwender zum Umstieg von PRESTO zu a99 zu
bewegen) hatten.


>> Mit "Aresqa" haben wir nun eine dritte, leicht abweichende Methode, mit
>> der in a99 Benutzerfuehrung und Menues realisiert sind, ich weiss
>> wirklich nicht mehr, wem das nuetzen sollte (und was das mit SQL zu
>> tun hat).
> 
> Wie gesagt: Nebenprodukt, mit SQL eigentlich nix zu tun. Wir selber
> setzen das aresqa-Fenster bereits intensiv fuer Menues verschiedenster
> Groesse ein und finden es sehr praktisch. Teilweise haben wir den
> select-Befehl dadurch ersetzt, weil dieser doch eher betulich und
> begrenzt ist.

Aber laesst sich diese Nutzung des Aresqa-Fensters nicht auch mit
dem View-Fenster realisieren? (An der Stelle sehe ich natuerlich,
dass die Entwicklungsabteilung die Editierfunktion schaetzt, aber
muessen dafuer alle Anwender mit einer neuen Sorte Fenster
konfrontiert werden?)

Alternativ koennten Sie aber alle bisher als Views abgespeicherten
verkappten Menues und Picklists auf Aresqa umstellen und den
Views das Feld der Kurzlistenaehnlichen Funktionen zurueckgeben
(250kB als Performance-Klippe sind allerdings fuer eine Lieferantenliste
ziemlich knapp).

Fuer meinen Geschmack sind es derzeit wirklich zu viele Bereiche,
die man mit Views oder Aresqa (oder Janas) loesen koennte, ohne dass
(auch eingeschraenkt auf den jeweiligen Bereich) eine der Loesungen
einen offensichtlichen Vorteil gegenueber den anderen hat. Ich
befuerchte ausserdem, dass auch reine AnwenderInnen diese mit Aufkommen
der aresqa-Fenster verstaerkte Uneinheitlichkeit als latenten
Stressfaktor empfinden koennten.

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCxBTTENVh3bB0lwMRAry0AKCLMvC3Sl8Ji/St/PAU1bvDgCkneACgqiw1
jdz1imQzGV+jwU55oj8HxjY=
=eJUR
-----END PGP SIGNATURE-----