[Allegro] Erfassung: Alternativen zum Formular

[Thomas Berger]

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

Lieber Herr Eger, liebe Liste,

| Die ISBN-Prüfroutinen kann man sicher auch in Flex programmieren,
| aber warum, wenn sie intern doch schon vorhanden ist?

bezogen auf ein Unterfeld, ja oder nein. Oft stehen aber
mehrere ISBNs in einem Feld oder der Preis, das hinge in
anderen Kategorienschemata vom Indikator ab...


| Und warum den Aufwand treiben, die Artikelerkennung für x Sprachen
| noch einmal in Flex zu programmieren?

wenn sie denn sprachbezogen waere...

Und der Plausibilitaetscheck fuer Personennamen hat immer noch nicht
mitbekommen, dass es seit V14 Satzverknuepfungen gibt.

Und Daten der Form JJJJ.MM.TT habe ich eigentlich auch noch
nie gesehen...

Unter PRESTO konnte man im PV-Abschnitt eigene Meldungen generieren
lassen, unter a99 sollte man das besser bleiben lassen, denn es
entstehen Rueckfragen, die sich nur falsch beantworten lassen (cf.
< http://bugzilla.gymel.com/show_bug.cgi?id=477 >).


Sinnvolle Pruefungen hingegen:
- - Kommt die ISBN/Signatur im Index vor (und betrifft _nicht_ diesen Satz
~  oder ein uebergeordnetes)
- - Ist die eingegebene Verknuepfung eine mit einer in diesem
~  Kontext erlaubten Satzart
- - Ist hinter " : " ein Uebergehwort
- - Gibt es zur Freitexteingabe im Feld einen oder mehrere passende(n)
~  Stammsa(e)tz(e), der/die zur Uebernahme vorgeschlagen werden koennte?

Sowohl die Uralt-Pruefroutinen als auch die CFG-Features "Feldschutz"
und "Formale Maske" von V13 sind wenig bis nicht brauchbar, da
koennte es sich schon lohnen, alles in Flex nachzubauen
(< http://bugzilla.gymel.com/show_bug.cgi?id=315 >).



| Zu Kategorienummern im Formular: 20 Zeichen für die Bezeichner
| sind schon knapp, mit Kategorienummern habe ich nur noch 16.

Kategorienummern sind ein haeufiges Desiderat. Indikatoren
und andere feste Codes Vorgaben am Kategorieanfang sind ein
echtes Problem (< http://bugzilla.gymel.com/show_bug.cgi?id=497 >).

Fuer Indikatoren und auch Unterfelder wuerde man sich gerne
eine horizontale Anordnung wuenschen und wieso geht eigentlich
nicht Drag&Drop?


| Eigentlich dreht sich diese Diskussion doch um folgendes:
| Wenn die Entwicklungsabteilung Funktionen bereitstellt, die
| einerseits vom Windows-Nutzer erwarteten Komfort, andererseits
| für den Betreuer/Entwickler/Anpasser/Supporter effiziente
| Arbeit ermöglichen, hat das eine ungeheure Multiplikatorwirkung.
| Und die wünsche ich mir.

!!!

| Je weniger Zeit für die Entwicklung _und_ Anppassung der
| Software _in der Summe_ (also Entwicklungsabteilung + alle
| Anpassenden) benötigt wird, desto kostengünstiger und damit
| erfolgreicher ist Allegro.

Hm. Ich dachte, allegro kostet immer dasselbe ;-)

Aber im Ernst: Der groesste Term in der Summe ist die
Raetsel- und Umstaendlichkeits-Zeit der Anwender, das sind
natuerlich nur versteckte Kosten, die in gewissem Masse
interpretationsabhaengig sind (ist eine steile oder flache
Lernkurve opportun). Wenn aber auch in der Grenzwertbetrachtung
immer noch ganz offensichtlich Arbeitszeit vernichtet wird oder
Tennisarme und Augenkrebs hervorgerufen werden, dann ist die
Angelegenheit nicht kostenguenstig, sondern Ramsch.

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

iQCVAwUBSF/WkWITJZieluOzAQK4jQP/UqyMY1wgLf2KFL0w2UvUkPlc6nQ27lX9
ThT5pYAHcP5Tn6/UnG9eiQehZOK7VrHNknr/YlIoyZtDLaAxKR1Bsgw8BoyiCo/U
9dp8TVYOnS2kSUULrTCzLFG61MZeDZ9bdggp7J86rtOLh8sZ0wzZ1YWE8zORJSVZ
4xvS+PBWj2M=
=Fad9
-----END PGP SIGNATURE-----