Oh mein Gott, zum Glück bist du nicht Bundestrainer.
Wir ham eh 80 Millionen Bundestrainer hier im Land ![]()
Oh mein Gott, zum Glück bist du nicht Bundestrainer.
Wir ham eh 80 Millionen Bundestrainer hier im Land ![]()
Das würde ja schon ausreichen wenn ein kleiner feiner Kreis sich darauf einigen würde
Ähm, da braucht man sich nicht drauf einigen.
Entweder nen Entwickler hälts sich daran, oder nicht. Was das nun für den Ruf des Entwicklers bedeutet, ist Sache des Entwicklers. Wenn man kein Problem damit hat, damit zu leben, als - sagen wir mal kreativ - bekannt zu sein, der muss eben damit leben.
Alles, was man da machen kann, ist dafür zu werben, dass eben jeder sich an die Richtlinien hält. Ansonsten wird das ein lustiges Meeting. "Ich halt mich an die WCF Richtlinien. Jo ich auch. Schön. Ich nicht. Aha." Schulterzucken und weitergehen, Meeting beendet.
ZitatLachender 3. war auf mit 2-3 Klicks Community zusammenstellen gemünzt ohne Ärger mit EA´s oder Plugin.
Schonmal versucht, Möbel zu kaufen? Diese frei kombinierbaren? Das geht sich auch selten problemlos aus...
Das es in allen möglichen Fällen immer zu 100% passt ist schlichtweg eine Utopie, das kannst du nicht erreichen. Manchmal werden ein paar Anpassungen nötig sein. Gerade bei Stilen und Plugins, die eigene Lösungen suchen müssen, weil das WCF dafür bisher keine bietet. Der Stil kann nur Dinge berücksichtigen, die im WCf vorhanden sind.
LESS wird da einiges vereinfachen, es wird einfacher sein, bestehende WCF-Elemente neu zu kombinieren, und zwar Stil-treu, das wird es ggf. auch für Plugin-Entwickler einfacher machen.
Wie wäre es denn wenn sich ein paar Designer und Entwickler zusammen tun würden.
Wozu?
Wobei willst du "lachender Dritter" sein? Mir erschließt sich nicht, worauf du hinauswillst?
Wie bereits gesagt, halten sich alle an die Vorgaben, so hast du bereits 90% aller Fälle, in denen ein Stil nicht mit einem Plugin harmoniert, gelöst. Alle anderen Fälle können eh nur im Einzelfall gelöst werden und nicht im vorhinein.
Ich meine auch nicht das gemeinsam an einem Projekt arbeiten! Ich meine deine Style nehmen zu können, von Tim die Linkliste von Netzwerg den Blog und alles passt problemlos zusammen.
Wie gesagt, wenn sich alle an geltende Standards und Regeln halten, ist das alles kein Problem ![]()
ZitatEin Problem habe ich aber damit, wenn ich für etwas zahle, das in der Folge dann nur Probleme verursacht.
Dann poch darauf, dass bestehende Mängel behoben werden, wenn es wirklich Mängel sind. Manchmal gibt es aber auch Dinge wo ein Stil zu einem Plugin nicht 100%tig passt weil so etwas im WCF noch nirgendwo vorkommt und der Stilhersteller somit auch keine Chance hat, den Stil von vorne herein darauf auszulegen.
ZitatIm Umkehrschluss vermute ich mal, das sich Plugin und EA leichter verkaufen, wenn sie als problemlos harmonisch bekannt sind.
Sagen wir einfach, das Sprichwort "Ist der Ruf erst runiniert, dann lebt es sich ganz ungeniert" trifft auch auf die Plugin-Entwicklung zu, und natürlich auch auf mögliche Kunden.
Ich frage mich nur, was du uns damit konkret sagen willst? Das alle Plugins mit allen möglichen Stilen *immer* auf Anhieb funktionieren kann per definitionem nicht gehen. Weder kann ich alle Stilhersteller vorher informieren, wenn ich in einem meiner Plugins etwas spezielles basteln muss, noch kann ich erwarten, dass alle Stilhersteller kuschen und ihre Stile dann auf mein Plugin abstimmen. Da kann man einfach nur individuell hergehen und anschließend dafür sorgen, dass es in jedem Einzelfall sauber gelöst wird. Das unterscheidet dann die wirklich guten Plugin- und Stilhersteller von denen, die auf Support keinen Wert mehr legen.
Natürlich wünsche auch ich mir eine umfangreiche Plattform zum Thema WCF, so wie andere Frameworks das schon seit Jahren vormachen. Aber ohne offizielle Unterstützung wird der Betrieb sehr schwer und mühselig.
Sowas wie WoWAce, nur fürs WCF und noch ein bisl aufgepeppt wär sicherlich nicht verkehrt ![]()
Und sicher ist es auch möglich das 5 Entwickler sich an die Regeln halten, es trotzdem nicht miteinander wirklich harmonisiert!
Möglich ist vieles, aber man kann unmöglich vorher alle Eventualitäten ausbügeln. Viel wichtiger ist es, dass wenn einem solche Dinge auffallen, dass man dann hergeht und den Dialog sucht, um das ganze in Harmonie zu bringen. Ich bin da sicherlich nie abgeneigt.
Meine WCF 2.0 Pakete werden alle offen auf GitHub liegen, dass alleine sollte es es anderen Entwicklern (oder auch Designer, sollte ich in den Templates etwas verbocken, was durchaus mal sein kann) leicht machen, auf solche Dinge in meinen Paketen hinzuweisen bzw. selbst mit Pull-Request oder dem Erstellen von Issues darauf aufmerksam zu machen und den Dialog zu suchen.
ZitatZum Konzept passt zum Beispiel auch das Lexikon nicht wirklich.
Naja, das schöne am Lexikon ist, man braucht es nicht nutzen. Das gilt zwar theoretisch für jedes Plugin, aber bei manchen Plugins hätte man zwar gerne die Funktion, aber nicht so... wundersam umgesetzt.
Genau das was du verstanden hast, ist nicht angedacht! Keine zusammenarbeit am Projekt sondern am System.
Na ja da ist schon mehr notwendig als sich an die Regeln zu halten.
Wie wärs wenn du einfach mal konkret schreiben würdest, was du dir denkst, anstelle irgendwelcher kryptischer Hinweise, in die man alles und nichts reininterpretieren kann?
Um ein absolut einheitliches Look & Feel zu erhalten reicht es schon, sich an alle expliziten und impliziten Layoutvorgaben zu halten. Da gibts nicht viel dran zu deuteln
Das hat auch mit "Regeln" im Wortsinne wenig zu tun ![]()
ZitatAktuell hat jeder sein WBB, bestückt das eben individuell nach Belieben mit Plugins und (s)einem Design und die Entwickler bieten je nach Ausrichtung kostenfreie/kostenpflichtige Plugins für User an. In Punkto individuelles Aussehen kann man also bis zu einem gewissen Grad kreativ sein, warum sollte man etwas aus einem Guss wollen?
Es geht nicht darum, dass jedes WBB gleich aussieht, sondern, dass die Oberfläche so gestaltet ist, dass die Oberfläche jedes individuellen WBBs für sich genommen konsistent ist.
Nehmen wir mal an, ich entscheide mich, an einer bestimmten Stelle einen Rahmen um einen Teil der Oberfläche zu setzen. Das Framework sieht vor, dass der Template-Quelltext dafür einer bestimmten Form folgt. Nun mache ich also meinen eigenen Stil und füge da den Rahmen ein. Sieht auch an jeder Stelle in der Software passend aus, ich hab überall meinen Rahmen. Nun hat aber dummerweise ein Entwickler eines plugins sich etwas ganz schlaues anderes ausgedacht und seine Templates anders gebaut, und auf den Seiten seines Plugins ist mein Rahmen plötzlich kaputt oder sehr entstellt. Und ich fange an, entweder mit jeder Menge zusätzlichem CSS da rumzumurksen, bis das endlich passt, oder ich lass es gleich ganz bleiben, wodurch ein Bruch in der Oberfläche stattfindet - bestimmte Teile meines Forums passen eben nicht mehr 100%ig zum restlichen Auftritt.
Ein anderes Beispiel sind S-icons in Subtabs. WoltLab selber verwendet nirgendwo S-Icons in Subtabs, obwohl das technisch möglich ist. Aus guten Grund. Nun gehen einige Entwickler hin und setzen S-Icons in die Subtabs. Sieht natürlich blöde aus, wenn in gesamten Forum nirgendwo S-Icons in den Subtabs sind, aber an der einen Stelle doch. Es ist nur eine Kleinigkeit, stört aber die Gesamtharmonie.
Ich empfehle in diesem Zusammenhang mal den folgenden Artikel, der bringt imho einiges gut auf den Punkt:
http://woltersdorfertagblatt.t…ler-von-pluginentwicklern
Der Artikel beleuchtet das ganze zwar mehr unter dem Aspekt "Usability", das geht aber auch sehr stark in Richtung "einheitlicher Oberfläche".
Hat aber jeder sein Projekt, Tim die Interessengruppen, Netzwerk den Blog, halte ich es für nicht nur möglich sondern für wahrscheinlich das Absprachen zu Aussehen und Aufteilung funktionieren, wenn dann ein Designer wie Tom noch seinen Senf dazu gibt, fahren glaube ich alle gut!
Wenn sich jeder Entwickler an alle expliziten und impliziten Design- & Layoutvorgaben des Frameworks halten, so bekommst du ganz automatisch etwas, dass aus einem Guss ist und bei dem keiner mehr erkennen kann, dass es nicht schon von Anfang an fest ins Framework eingebaut war.
Das Problem ist jedoch, dass einige Entwickler manchmal schlichtweg nicht wissen was sie da zu beachten haben, oder es absichtlich ignorieren, weil sie denken, sie könnten es besser. Nun, manchmal ist das sogar der Fall, und WoltLab hat ggf. eine Art und Weise gewählt, die nicht optimal ist. In dem falle muss man dann abwägen - hält man sich, um dem Anwender ein konsistentes Bild zu bieten trotzdem an die Vorgaben (was ich in dem falle tun würde), oder setzt man auf Teufel komm raus sein eigenes Ding durch - auf Kosten einer einheitlichen, konsistenten Oberflächengestaltung.
In der Hinsicht kannst du nur denjenigen, die gegen die Design- und Layoutvorgaben verstoßen darauf hinweisen, und sie bitten, sich an die Vorgaben zu halten - und das wars auch schon.
Netzwerg Hälst du es für Möglich, das sich diesmal ein paar Entwickler und Designer zusammen tun um ein größeres Paket u realisieren?
Ich habe die Erfahrung gemacht, dass man meistens besser damit fährt, Dinge selbst zu machen. Zu viele Köche verderben den Brei.
Schau dir das Woltnet-Wiki an. Ein paar commits am Anfang, und danach absolute Sendepause. letzter commit am 06.05.2012. ich hab in einem Issue dazu aufgefordert, darzulegen, wie man die interne Datenstruktur plant (dies geht bisher aus den Dateien nicht wirklich hervor) und angeboten, da ggf. bei den Planungen zu helfen, falls benötigt, da ich durchaus gerne da hin und wieder einen Pull-Request gestartet hätte um bei der Entwicklung zu starten: Ergebnis: Stille. Kein Antwort, nix, nada. Keiner weiß, we es mit dem Ding hin soll. Nu ist das Ding OpenSource und auf GitHub, wo viele helfen könnten, aber keiner kann helfen, weil die Core-Entwickler wie nen schwarzes-Loch nix von sich hören lassen und auch sonst keinerlei Linie bekannt ist, wo das Ding hin entwickelt werden soll.
Das ist nur das letzte und aktuellste Beispiel, wieso ich Gemeinschaftsentwicklungen eher skeptisch gegenüberstehe. Meist kommt da eh nichts bei rum, wenn nicht mind. einer dabei ist, der sich wirklich die ganze Zeit um die Koordination kümmert und anderen auf die Füße tritt.
Btw, man schreibt mich Netzwerg ![]()
Hast du oder dein hoster etwas an den servereinstellungen verändert? open_basedir beschränkt bei dir den zugriff.
Frage 1: Hat einer von euch eine Art Zusammenfassung, Liste o.ä. wo man gezielt als Anwender nachsehen kann, welche neuen Features für die Endnutzer da sein werden? Bitte schreibt mir jetzt nicht "Lies bei Github nach", das ist der Spielplatz für euch Entwickler, Leute wie ich finden nicht einmal den Weg hinein, alles blöd usw.
Twitter und Facebook, sowie die Ankündigungen auf woltlab.com und z.B. woltcafe, wo es auch immer mal neue Bilder gibt. Viel mehr Infos hat auch von uns keiner ![]()
ZitatFrage 3: Überwiegend wird die Sicht für den Entwickler thematisiert und ja, das ist wichtig, zumal eure Plugins die Community weiter vorantreiben bzw. die Foren ausstaffieren, aber letztendlich sind es die reinen User, die die Software erwerben und benutzen werden. Könnt ihr grob sagen, wie viele der Wünsche für WBB seitens der reinen User kommen und was haben sich Entwickler/Designer gewünscht (und wurde realisiert)?
Naja es wurden schon eine ganze Menge Wünsche der User umgesetzt. Sie dir mal alleine die Meilensteine im WBT an, das ist doch eine ganze Menge. und auch einige Dinge, die da nicht explizit aufgeführt sind, wurden verbessert.
Zum anderen ist WCF 2.0 / WBB4 aber schlichtweg noch nicht fertig. Das Framework ist letzten Endes nur der Unterbau, auf dem hinterher alles aufbauen wird. Insofern kann man dazu, wie viele und welche der Wünsche für WBB4 hinterher umgesetzt wurden, noch kaum abschätzen. Es lässt sich nunmal ganz gut über viele der für Entwickler interessanten Schnittstellen reden, weil diese eben so langsam aber sicher immer mehr fertig werden. das, was der User hinterher davon hat, wird aber erst später da drauf gebaut.
Insofern würd ich mit etwaigen Feature- und umgesetzten Wunschlisten für WBB4 noch vorsichtig sein. Zumal wir WBB4 erst zu sehen bekommen werden, wenns an die Beta-Phase geht.