JTL-Wawi 1.9 | Durcheinander: Variablen englisch 🇬🇧, DB deutsch 🇩🇪 , Vorlagen teils deutsch, teils englisch 🇬🇧, keine Performancesteigerung 🐌🐌

[Powalowski]

Hallo,

ich möchte an dieser Stelle (hoffentlich konstruktiv) mal unseren kumulierten Frust rauslassen und würde gerne auch hören, wie die restliche Community das sieht.
Vorab: Wir sind dabei seit Wawi 1.2. wir lieben das Ding und wir wollen dass es funktioniert.

Warum werden die Variablennamen auf Englisch umgestellt?
Offensichtlich läuft doch irgendwo ein fetter Mapper, da sie ja in "alten" Vorlagen auch auf deutsch funktionieren.

Warum macht ihr euch so einen Aufwand die Variablen so kompliziert umzubenennen, wenn eh die Datenbank deutsch ist?​

Für uns ergibt das gar keinen Sinn und es ist ein dicker Stein im Weg, immer zu suchen, was der bekannte Wert aus alten Vorlagen und Datenbanktabellen denn nun auf englisch heißen könnte.
Insbesondere weil in der Hauptdokumentation oft (noch?) die deutschen Bezeichnungen sind.

Wir finden vieles nicht wieder und auch die Transformation zu Eigenen Feldern scheint ein mittelmäßiges Frickelwerk zu sein.
Früher war es so, dass man die Attribute zumindest als Bastelstring per Regex rausholen konnte und nun sind bei Aufträgen (Dotliquid ist gemeint!) die Eigenen Felder scheinbar gar nicht mehr drin oder ich bin zu doof die englische Übersetzung zu finden.

@Jtl: Anstatt ein komplettes Produktionstool da reinzubasteln: Was haltet ihr davon, wenn ihr ein Release baut mit den wichtigsten Alltagsthemen für die Benutzer?
Quasi ein Codesprint zur reinen Verbesserung der wichtigsten Eckpfeiler für die Bestandsuer.

​

Vorschlag für das Variablendurcheinander:​

Da ja ohnehin ein dicker fetter Mapper am Laufen ist bei den Variablennamen - Macht doch ein Dropdown für den einfachen pragmatiuschen deutschen User:

1. Variablennamen deutsch (So wie in der Datenbank und überall anders auch seit all den Jahren)
2. Variablennamen englisch (für Café Latte trinkende Starbucks-Experten, die Herzstolpern bekommen, wenn Variablen deutschsprachig sind)

Ich hoffe, dass diese Kritik konstruktiv ankommt, für uns wirkt die JTL-Wawi Strategie ein wenig wildwüchsig und nicht mehr wirklich passend zu unserer Richtung.

Wünsche eines Powerusers mit mehreren Wawi Benutzern gleichzeitig:​

1. Wir brauchen laufende Workflows, da sind teilweise seit Jahren wünsche offen wie z.B. Bearbeiter zu wechseln (was scheinbar nur ein klitzekleiner Tabelleneitrag ist)
   => umso mehr in den Webhooks möglich ist, desto besser können wir das für uns erweitern
   (Idealerweise welche, die wir per Webhook triggern könnten, das wäre cool 😎)
2. Wir brauchen laufende Vorlagen mit System: Variablen, die idealerweise verwandt zur Datenbank sind und kein Sprachdurcheinander
3. WIR BRAUCHEN SPEED & PERFORMANCE
   Kleiner Randkommentar dazu: Bei uns läuft alles auf maximaler Perfomance, Bare Metal fetter RAM, große CPU (mit hoher Single Core Leistung) etc. etc.
   Wieso dauern die Klicks immer noch teiweise 1-2 Sekunden? Für einen guten alten Betrieb, der alles mit mehr Angestellten auf Kredit totschlägt sicherlich akzeptabel. Für ein hocheffizientes Unternehmen, das sonst überall schnelle Anwendungen hat wird das zunehmend zum Problem und auch zum Spaßkiller bei der Arbeit.
   Wieso ist die Wawi nach 10 Jahren Entwicklung immer noch auf 4GB Ram limitiert mit 32bit?
4. Gebt uns eine Schreib-API für Aufträge und Bestellungen

Ich weiß, es ist nicht immer leicht genau zu entscheiden, wo die Reise hingehen soll. Ich hoffe ich konnte ein bisschen Aufschluss geben in die Gedanken eines normalen Users, direkt nach einem großen Upgrade von 1.5 auf 1.9
Und bin ganz gespannt, wie die anderen es sehen.

PS: Die Ameise ist ein Witz, wieso ist das Fenster so klein? Für uns geht Gänsehaut auf, wenn wir nur an die Ameise denken. Ein klitzekleines Windows-Fensterchen, wo man oftmals 30 Werte zuordnen muss in ewigen Klickorgien, voller Angst vor Fehlern.
PS2: Bei den Workflows ist auch alles auf deutsch 🤔😂

 

[Powalowski]

Erfahrungsbericht1: Das Umschreiben einer schönen handgemachten E-Mail Vorlage mit dutzenden Variablen: mehrere Stunden Arbeit. Nicht nur die Fummelei am SQL, auch und insbesondere das Übersetzen der Variablen. Was für eine Ameisenarbeit..

 

[dapole]

Teilweise sehr schön zusammen gefasst.

Zur den englischen Variablen: Gebe ich dir recht. Vor allem, kann man mit Stand jetzt, noch nicht mal die Sachen abbilden, die man mit deutschen Variablen abbilden konnte...
-> KaTaStropHe ....
Aber: Falls du aber noch alte Vorlagen hast, kannst du sie importieren. (Deutsche Vorlagen) -> Diese sind noch kompatibel und funktionieren auch. Nur Gott weiß aber, wie lange es noch der Fall sein wird.



Ich vermiss auch die 1.5er ...

Gruß

 

[Powalowski]

Teilweise sehr schön zusammen gefasst.

Zur den englischen Variablen: Gebe ich dir recht. Vor allem, kann man mit Stand jetzt, noch nicht mal die Sachen abbilden, die man mit deutschen Variablen abbilden konnte...
-> KaTaStropHe ....
Aber: Falls du aber noch alte Vorlagen hast, kannst du sie importieren. (Deutsche Vorlagen) -> Diese sind noch kompatibel und funktionieren auch. Nur Gott weiß aber, wie lange es noch der Fall sein wird.



Ich vermiss auch die 1.5er ...

Gruß

Danke für den Tipp.
Das habe ich gesehen - Problem war, dass durch die Migration auf Eigene Felder unsere alten Templates nicht mehr gingen. Da wollt ich nicht weiter mit SQL anflanschen, sondern es auf JTL Art und Weise lösen. Bis ich gemerkt habe, was für ein gruseliges Ungeheuer man da füttert...

@Jtl Feedback: Es ist schön, dass List&Label jetzt besser genutzt wird. Bausteine und Benutzervariablen vorzugeben war ein guter Schritt! Nur eben nicht das Sprachwirrwarr
@dapole Weißt du, wen man von JTL verlinken könnte, damit auch jemand von JTL die Posts sieht? Nicht, dass das nachher an den richtigen vorbeigeht.

Es wäre richtig schön, wenn mal etwas in Richtung 64bit + Performance passiert. Das ist ja Horror die Warterei. Ein Tod durch tausend Nadelstiche...

 

[Verkäuferlein]

Ich hoffe, dass diese Kritik konstruktiv ankommt, für uns wirkt die JTL-Wawi Strategie ein wenig wildwüchsig und nicht mehr wirklich passend zu unserer Richtung.

Hm, in dem Punkt kann ich Dir ja noch zustimmen und würde noch hinzufügen, dass es aus meiner Sicht auch nicht so richtig mit den Entwicklungen der Umfeldbedingungen für einen Online-Händler bzw. den Online-Handel Schritt gehalten wird.

1. Wir brauchen laufende Workflows, da sind teilweise seit Jahren wünsche offen wie z.B. Bearbeiter zu wechseln (was scheinbar nur ein klitzekleiner Tabelleneitrag ist)
   => umso mehr in den Webhooks möglich ist, desto besser können wir das für uns erweitern
   (Idealerweise welche, die wir per Webhook triggern könnten, das wäre cool 😎)
2. Wir brauchen laufende Vorlagen mit System: Variablen, die idealerweise verwandt zur Datenbank sind und kein Sprachdurcheinander
3. WIR BRAUCHEN SPEED & PERFORMANCE
   Kleiner Randkommentar dazu: Bei uns läuft alles auf maximaler Perfomance, Bare Metal fetter RAM, große CPU (mit hoher Single Core Leistung) etc. etc.
   Wieso dauern die Klicks immer noch teiweise 1-2 Sekunden? Für einen guten alten Betrieb, der alles mit mehr Angestellten auf Kredit totschlägt sicherlich akzeptabel. Für ein hocheffizientes Unternehmen, das sonst überall schnelle Anwendungen hat wird das zunehmend zum Problem und auch zum Spaßkiller bei der Arbeit.
   Wieso ist die Wawi nach 10 Jahren Entwicklung immer noch auf 4GB Ram limitiert mit 32bit?
4. Gebt uns eine Schreib-API für Aufträge und Bestellungen

1.) Geht das nicht mit einem Custom-Workflow?
2.) Grundsätzlich haben die neuen Vorlagen durch Ihren Globalcharakter ja schon mal einige Vorteile, aber es gibt da auch aus meiner Sicht noch einige Langzeit-Baustellen.
3.) Ist die "JTL-Wawi Neue Oberfläche (Beta)" nicht 64-Bit?
4.) Es gibt doch verschiedene Wege Aufträge zu schreiben und mittlerweile doch auch (teilweise) die Rest-API!?

PS: Die Ameise ist ein Witz, wieso ist das Fenster so klein? Für uns geht Gänsehaut auf, wenn wir nur an die Ameise denken. Ein klitzekleines Windows-Fensterchen, wo man oftmals 30 Werte zuordnen muss in ewigen Klickorgien, voller Angst vor Fehlern.

An der Ameise habe ich auch so einige Kritikpunkte, die kann zwar vieles aber eben auch vieles kaputt machen oder auch nicht richtig. Die Usability ist zwar auch ein bisschen besser geworden, aber immer noch sehr gering ausgeprägt. Zuletzt sind leider auch sehr viele Tickets zur Ameise abgewiesen worden, so dass ich mir schon die Frage gestellt habe, ob die Ameise bald abgekündigt wird und dann die Rest-API die Ameise "ablöst".

@Jtl Feedback: Es ist schön, dass List&Label jetzt besser genutzt wird. Bausteine und Benutzervariablen vorzugeben war ein guter Schritt! Nur eben nicht das Sprachwirrwarr

Das Problem ist vermutlich, dass Entwickler tendenziell eher an Englisch gewöhnt sind und man eben leichter (englischsprachige) Entwickler auch auf dem internationalen Markt findet, die Haupt-Nutzerschicht aber eben aktuell im deutschsprachigen Raum ist.

Meine Interpretation wäre daher, dass das einem Spagat zwischen Entwickler-Knappheit und (Normal-)Nutzer-Freundlichkeit geschuldet ist.

Aber auch mir fehlt irgendwie die Struktur und (Ziel-)Richtung in der ganzen Entwicklung der letzten Jahre oder ich verstehe sie halt nicht richtig.

 

[Powalowski]

1.) Geht das nicht mit einem Custom-Workflow?
2.) Grundsätzlich haben die neuen Vorlagen durch Ihren Globalcharakter ja schon mal einige Vorteile, aber es gibt da auch aus meiner Sicht noch einige Langzeit-Baustellen.
3.) Ist die "JTL-Wawi Neue Oberfläche (Beta)" nicht 64-Bit?
4.) Es gibt doch verschiedene Wege Aufträge zu schreiben und mittlerweile doch auch (teilweise) die Rest-API!?

1.) Wir sind dran aber sowas könnte auch gut aus der Konserve kommen
2.) natürlich - man merkt nur deutlich, dass da ein Mapper läuft, die DB ist ja nicht englisch, also Quatsch auf Rädern
3.) tatsächlich! Trotzdem laahmmmmm🐌🐌. Mich würd's nicht stören, wenn die Wawi 6GB Ram vollklatscht, wenn es doch nur ein bisschen schneller ginge!
4.) Ich empfehle einen Blick in die API -API-DOKU- da können wir nur wenig mit anfangen, ganz wenig (Stichwort: SalesOrder )

An der Ameise habe ich auch so einige Kritikpunkte, die kann zwar vieles aber eben auch vieles kaputt machen oder auch nicht richtig. Die Usability ist zwar auch ein bisschen besser geworden, aber immer noch sehr gering ausgeprägt. Zuletzt sind leider auch sehr viele Tickets zur Ameise abgewiesen worden, so dass ich mir schon die Frage gestellt habe, ob die Ameise bald abgekündigt wird und dann die Rest-API die Ameise "ablöst".

Die Ameise ist peinlich. Manchmal da frage ich mich, ob das Fenster nicht noch ein bisschen kleiner sein könnte.

Das Problem ist vermutlich, dass Entwickler tendenziell eher an Englisch gewöhnt sind und man eben leichter (englischsprachige) Entwickler auch auf dem internationalen Markt findet, die Haupt-Nutzerschicht aber eben aktuell im deutschsprachigen Raum ist.

Und deshalb baut man irgendwo einen gigantischen Mapper ein, der alles übersetzt? So ist es ja in jeder Ansicht anders gerade

Aber auch mir fehlt irgendwie die Struktur und (Ziel-)Richtung in der ganzen Entwicklung der letzten Jahre oder ich verstehe sie halt nicht richtig.

Performance, wir brauchen Performance. Stellt euch mal vor, die Wawi würde einfach flutschen und nicht stocken...