Re: [TYPO3-german] [TYPO3-v4] Announcing TYPO3 4.5 beta1

Stephan Schuler Sat, 20 Nov 2010 10:38:51 -0800

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hallo zusammen.

Ich hatte mir eigentlich fest vorgenommen, auf diese Diskussion nicht
einzusteigen. Der anfänglich enorm herbe Ton gefällt mir nicht und das
ursprüngliche Thema ("warum kann ich keine X Bilder und Links in ein
Text-mit-Bild-Element bauen") ist sowohl ausführlich besprochen als auch recht
leidig.

Die Diskussion ist in eine Richtung abgedriftet, die mich dann aber doch ein
wenig interessiert. Man darf das aktuell hier besprochene Problem wohl als
"mangelhafte Standardwerte" zusammenfassen. Die gibt es auf diversen Ebenen und
in diversen Komponenten.

Meine Meinung dazu: Das ist ein *sehr* schwieriges Thema. Aus meiner Praxis
kann ich sagen, dass der größte Teil Individualisierung ist. Ich könnte bei den
wenigsten Parametern einen sinnvolleren Standard nennen als den aktuellen weil
meine Projekte dazu deutlich zu unterschiedlich sind.

Zum einen wurde das Fehlen sinnvoller Templates angesprochen. Ich halte das
Introduction Package allerdings für optisch gar nicht so schlecht, und weitere
Templates sollte man wohl auch via Google finden. Zugegeben, ich kenne keinen
größeren Anbieter (egal ob freier oder kostenpflichtiger) Templates. Den
Vermerk (sinnhaft, den Wortlaut habe ich mir nicht gemerkt) "freie Layout von
XYZ" habe ich aber schon das ein oder andere mal gelesen. Wenn hier wirklich
der Bedarf besteht, vielleicht kann man sowas ja auf typo3.org veröffentlichen.
Evtl. lässt sich das ähnlich wie das TER aufziehen. Ein solches Layout sollte
sich recht leicht als t3d-File exportieren lassen, sodass man gebündelt
CSS-Dateien, HTML-Gerüst, Bilder und bei Bedarf Templavoila-Records in einer
Datei hat. Es spricht aus meiner Sicht nichts dagegen, sowas "offiziell" zu
machen. Vielleicht sollte man sowas mal an passender Stelle (sprich dem
zuständigen TYPO3-Core-Team-Member, wer auch immer das ist) vorschlagen. Es
kommt bei uns -- und so sicherlich auch bei vielen anderen -- ab und an vor,
dass man mal einen Pitch nicht gewinnt und dann auf einem halb fertigen
Photoshop-Dokument sitzt. Ich kann nichts versprechen weil ich hier die
Preispolitik meiner Firma nicht beeinflussen kann. Vielleicht lässt sich so ein
Layout mit relativ wenig Aufwand dann doch noch in Ansätzen realisieren. Das
wären für mich jedenfalls die idealen Kandidaten für eine kostenfreie
Veröffentlichung weil der Großteil der Layoutarbeit eh schon erledigt ist aber
kein Kunde dafür existiert.
=> Wenn jemand ernsthaft Interesse daran hat soll er das mal in die Wege leiten
und ggf. eine größere Abstimmung darüber anleiern.

Ein weiterer Punkt sind schlechte bzw. fehlende Defaultsettings für den RTE.
Ich hab weiter oben die sinngemäße Antwort "das macht ja jeder Integrator nur
einmal im Leben" gelesen. Kann ich, ehrlich gesagt, bestätigen. Ich muss aber
auch zugeben, mir in dieser Beziehung das Introduction Package nicht näher
angesehen zu haben. Wenn sowas irgend wo existiert dann wohl da. Beim Core
handelt es sich immerhin ganz bewusst um eine nicht-konfigurierte Variante. Und
wenn nicht wäre das ein Thema für einen Featurerequest konkret zum Introduction
Package. Auch hierzu würde ich vorschlagen, eine gesonderte Diskussion über
"was muss der RTE können und was gehört standardmäßig versteckt" anzustoßen.

Das nächste Thema sind sinnvolle Standardsettings für (zum Beispiel)
sr_feuser_register.
Zunächst muss ich sagen: Ich habe gestern Abend eine Installation von 4.3 auf
4.4 gezogen und dabei alle Extensins mit aktualisiert, darunter auchi
sr_feuser_register. Es verschickt nach wie vor E-Mails und man kann sich nach
wie vor anmelden. Es sieht im Frontend exakt so aus wie vor dem Update. Kaputt
kann ich das nicht bezeichnen.
Hier sind wir aber wieder bei der Individualisierung und der Frage, was hier
der sinnvolle Standard sein soll. Im einfachsten Fall fragt man lediglich die
E-Mail-Adresse und den Namen an um Newsletteranmeldungen zu sammeln. In
umfangreicheren Fällen wird das Formular mehrseitig. Ich könnte wirklich nicht
mit Sicherheit sagen, welches die sinnvollere Standardeinstellung wäre.
Ganz davon abgesehen handelt es sich dabei (mit Recht, wie ich finde) um eine
Extension und somit müsste dieser Vorschlag der verantwortlichen Gruppe
zugetragen werden, nicht dem Core-Team.

Nun noch kurz doch ein paar Worte zum Problem der vielen Bildlinks:

Ich kann grundsätzlich beide Fraktionen verstehen. Einerseits verstehe ich die
Entwickler die sagen, dass man zwar technisch das Feld vergrößern kann, dass
das aber keine langfristig befriedigende Lösung sein wird. Ich verstehe aber
andererseits auch die Endbenutzer die fragen, warum man das nicht trotzdem
einfach so machen kann. Letztendlich bin ich aber eher auf de Seite der
Entwickler. Zum einen wohl, weil ich selbst einer bin. Zum anderen aber, weil
ich die grundlegende Struktur "in ein Feld x Bilder, ein ein zweites x Texte,
in ein drittes x Links" für äußerst "unergonomisch" halte. Das Problem, dass
ein Komma ein in ener URL zulässiges Zeichen darstellt wurde schon genannt. Und
jetzt erklär mal einem Kunden, dass die Eingabe von
"http://www.xyz.de/foobar.html#text,links,2"; in diese Zeile dazu führt, dass
das erste Bild mit "http://www.xyz.de/foobar.html#text"; verlinkt wird, das
zweite Bild nicht und das dritte Bild mit der internen Seite mit der UID 2. Das
Feld einfach zu erweitern greift schlicht zu kurz. Gerade die von Kunden
gewünschten Änderungen (das betrifft nicht dieses Problem sondern ist eher so
etwas wie eine Gesetzmäßigkeit) in der Größenordnung 15 Minuten sind häufig
die, die noch wochenlang Regressionen nach sich ziehen.

Aus dieser Sicht heraus könnte man von einem Designfehler sprechen. Wenn es
zwischen Text und Bild eine 1:n-Beziehung gibt muss diese Sachverhalt sinnvoll
wiedergegeben werden, eine kommaseparierte Liste kann das in meinen Augen nur
bedingt.

Ich für meinen Teil würde, soviel sei gesagt, mittels Templavoila (die
Diskussion über dessen Sinn und Unsinn möchte ich hier nicht führen, das
passiert mit Joey schon oft genug off-topic) passende FCEs definieren.
Der Grund dafür ist recht simpel: Die Größenordnung in der ich TYPO3 einsetze
bringt stehts ein recht umfangreiches Sammelsurium an Layoutelementen mit sich.
Wenn der Grafiker ein entsprechendes, tabellarisches Bilderelement vorsieht ist
der Kunde in der Regel froh, wenn seine Redakteure mit möglichst wenigen
Handgriffen genau das Layout füllen können. Er stört sich dagegen daran, wenn
sich seine Redakteure durch Unachtsamkeit oder schlicht Unwissen (Bild 200px
breit statt 190 zum Beispiel) auf fünf Seiten auf fünf unterschiedliche Arten
an das Layout lediglich annähern. Kurzum, FCEs helfen, Konsistenz zu erzeugen.

Die gewünschte Lösung, das Textfeld auf xyz Zeichen zu erweitern ist wegen der
enorm schlechten Bedienbarkeit absolut keine Musterlösung. Das wurde auch schon
angesprochen. Ob man es dann nun durch Pages und ein HMENU löst oder tt_address
spielt eigentlich keine Rolle, es müssen jedenfalls geeignete (!) Elemente
dafür sein.
Auch könnte ich mir vorstellen, dass man das Text-mit-Bild-Element um ein
IRRE-Feld erweitert, mit dem sich diese geeigneten Elemente dann anwählen
lassen. Das ergibt dann immerhin auch eine Lösung, die der Redakteur an recht
beliebiger Stelle wiederverwenden kann.

Wie ich es auch drehe: Es läuft für mich immer auf einen anfänglichen, recht
geringen (Joey hat von 15 Minuten gesprochen, und lassen wir es 30 sein)
Aufwand als Aufgabe eines Integrators hinaus, anschließend existiert für den
Redakteur eine Möglichkeit, das (und genau das) zu erzielen.

Grüße,

Stephan Schuler
Web-Entwickler

Telefon: +49 (911) 539909 - 0
E-Mail: stephan.schu...@netlogix.de
Internet: http://media.netlogix.de

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Stefan Buchta, Matthias Schmidt

________________________________________

Von: typo3-german-boun...@lists.typo3.org
[typo3-german-boun...@lists.typo3.org] im Auftrag von Claus Fassing
[cl...@fassing.eu]
Gesendet: Samstag, 20. November 2010 18:18
An: typo3-german@lists.typo3.org
Betreff: Re: [TYPO3-german] [TYPO3-v4] Announcing TYPO3 4.5 beta1

* PGP Signed by an unknown key

Hallo Bernhard,

Am 20.11.2010 17:49, schrieb LUCOMP mediale kommunikation &
internetDesign Bernhard Ludwig:
> Oh Wunder, Joomla, Magento, einfach mal ausprobieren, macht Spaß und
> funktioniert sogar.

sieht für mich so aus als wenn die Integration von Backup/Restore bei
Joomla lediglich zur Abstimmung vorliegt [1].

> War mir aber schon klar, dass Dein Interesse nicht ernsthafter Natur war...

Das habe ich weder geschrieben noch zwischen den Zeilen platziert.

[1]http://ideas.joomla.org/forums/84261-joomla-idea-pool/suggestions/1213469-built-in-backups?ref=title

* Unknown Key
* 0xAE74E6DF(L)
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.0.0 (Build 2881)
Charset: Windows-1252

wpUDBQFM6BW3pp0IwsibV8MBCCzmBACH3L2hl0G4wXTGzcRTiDneSVPgcOvAhMt4
vMqSXRPMVMPLwKZI+b+IvaLnMQbT6IAgtx0ek57dYLFeNtR/ze12sqfutV16wHE7
ggJ32wOTs40a9XY3xz2lhmkNUWRoWc2bTL3jjUIX+pg6OPhXVYdAhw/B9rml4g5J
qxZ+avMFeg==
=g+bv
-----END PGP SIGNATURE-----
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] [TYPO3-v4] Announcing TYPO3 4.5 beta1

Antwort per Email an