Plugin-Featuritis oder "Vollpacken, bis es platzt"?

Sollte mein Fragen-Konto nach Frage 10003 erschöpft sein, einfach kurz anmerken, irgendwann merke ich es dann auch (denke ich).

@Teralios

So schnell kann ich dich nicht aus der Antwort entlassen, Teralios, wir müssen bitte noch einmal beim Begriff "Anforderungen" ansetzen, wobei es mir nicht um die semantische Kodierung seitens euch Entwickler geht (also wir ihr den Begriff interpretiert), sondern konkret hierum:

1. Wenn ich dir als exemplarischer Kunde meine Wünsche für ein Plugin notiere, wie viel Spielraum bei der Umsetzung nutzt du dann?
Damit meine ich, wenn ich dir lediglich grob Wünsche notiere, du es in Funktionen "übersetzt", dann wird das Plugin das später aufweisen/tun, aber ab wann kommt der Sprung zu "mehr", also ab welchem "Grad", bei welchem Schritt (?) setzt dein technisches, schöpferisches (?) Wesen ein, so dass du das Plugin konzeptionell weiterentwickelst?
[Ich hoffe, das klingt jetzt nicht zu abstrakt? Sollte es wirklich nicht verständlich sein, sag es ruhig, ja? Mich interessiert im Moment mehr die Theorie, aber es ist möglich, dass ich mehr hineininterpretiere, als es in der Praxis dann so passiert.]

2. Wie definiert der Entwickler (kein spezieller, also nehmen wir den ideellen Entwickler als Rollenkonstrukt] seine/ihre "Anforderungen" in Bezug auf ein Plugin (Kundenwünsche versus fachliche Anforderungen versus individuelle Anforderungen...?)?

.....

Cr@@gle

Wahrscheinlich denkst du jetzt "Warum habe ich geantwortet? Es war klar, dass sie jetzt wieder ankommt und noch mehr fragt..." , aber da du ja ein großes Herz für fragende Nutzer hast , frage ich einfach weiter und stoppe, wenn eine Drohung kommt (im Stile "Dein Plugin-Einführungskurs beginnt morgen", "Wenn du je wieder ein Design von mir sehen willst, dann..." oder "Da sind noch XX Supportanfragen zu beantworten und ich weiß, wer das übernehmen kann..." ), ok?

Gut, ich möchte bitte auf der Stufe der Entwicklungsplanung einsetzen und der Vielfältigkeit eines Plugins. Am Besten anhand eines Beispiels, das ich noch im Hinterkopf habe: dem EasySlider.

Ausgangspunkt war rein der Gedanke, ein Slider, der sowohl textuelle Inhalte als auch Bilder durchlaufen lässt.
Stufe 2 war die dafür nötige Verlinkung, also Stichwort Schnittstellen, um Inhalte von X anzeigen zu lassen.
Stufe 3 die Optik inkl. Darstellungsoptionen

Bis hierher wäre das noch für sicherlich jeden Nutzer nachvollziehbar und das könnte man sich auch selber so herleiten (unterstelle ich einmal). Und genau hier kommen dann meine Fragen an dich:

a) Woher weißt du dann, wie du von diesen minimalsten Konzeptionsebenen weitergelangst?

b) Wie kannst du den eigentlich konkreten Nutzungseinsatz so abstrahieren, dass du weitere Optionen, Erweiterungen usw. "siehst" und einbauen kannst?

c) Wie "weit" planst du das Plugin dann konkret, was bleibt dann noch mental als Idee zurück (für ein Update?), was ergibt sich während der Entwicklung?

Von hier aus schwenke ich dann zu den Einzelfällen und dem Testen bzw. Überdenken. Du hast das Beispiel mit den Linkeinträgen angeführt, meine Fragen hierzu wären diese:

1) Ist der Kompatibilitätsaspekt deiner Meinung bzw. Erfahrung nach DER wichtigste und kritischste Punkt bei Plugins oder dass zu viele Funktionen in einem Plugin einfach nicht imemr harmonieren müssen?

2) Ein für mich heikles Thema ist der Punkt "Nutzerlogik versus Entwicklerlogik".
Je nach Plugin und ACP-Darstellung habe ich mich mitunter ertappt zu denken, dass ich Inhalte umgestellt, es anders gelöst hätte, einfach weil ich dachte, meine Sicht wäre logisch/er für den Nutzer.
Gleichzeitig habe ich dann bei Nachfrage verstanden, warum der Entwickler etwas in bestimmter Form gemacht hat. Trotzdem, wie wenig/stark muss/kann/soll man als Entwickler eigentlich bereits für den späteren Endnutzer das Plugin konzipieren oder geht das so gar nicht, es ist per se die Entwicklersicht und wir Nutzer müssen uns an sie gewöhnen?

3) Direkt gefragt: Hast du Prüfkriterien bei deinen Plugins, also egal ob wir cls-design selber oder ein Exklusivprodukt, wie setzt du da die "Anforderungen" an (das habe ich bei Teralios oben auch schon aufgeführt)?

Weiter dann zu den Streichungen und Abwägungen, du schriebst

Zitat von Cr@@gle

Du weißt ja, dass ich selber auch immer etwas übertreibe. Aber gerade bei der Galerie-Erweiterung war mir persönlich wichtig, dass die Funktionen auch wirklich von mehreren Usern benötigt werden kann. Spezifische Erweiterungen wurden so gut wie möglich ignoriert. Aber auch "extreme" Erweiterungen wie das Battle-Modul (du hast den damaligen Entwurf von EasyChallenge gesehen und weißt ja, wie umfangreich das ausfällt) mussten hier geopfert werden.

Oh ja, von der Kombination her sind du und ich nicht soooo ideal, weil wir beide liebend gerne Funktionen integrieren wollen und den "Stopp"-Ruf gerne ignorieren.

Ich hake hier aber noch einmal ein und würde das gerne erfragen:

1. Wie setzt du für dich fest, ab wann eine Funktion von "vielen" Nutzern gebraucht werden kann/würde, Cr@@gle? Kannst du das wirklich zahlenmäßig festmachen, gehst du mental dir bekannte Foren durch, ist das einfach Erfahrung oder...?

2. Was ich schlecht bewerten kann, ist, wie ist dein Eindruck in Punkto "viele Funktionen = optimale Nutzung des Users"? Das heißt, sind multifunktionale Plugins eine Einladung an den Nutzer und die meisten klemmen sich auch dahinter oder werfen solche Plugins eher mehr Fragen und gar Probleme auf?

3. Tom hat gesagt, er würde "einfache" Plugins multifunktionalen Plugins vorziehen, weil er dann auch konsequent entscheiden kann, was er installiert und wirklich braucht. Wie siehst du das und wie würdest du deine Entscheidung erklären?

rainer: Rainer, du Nutzer der pejorativen Wendung im Milieu der derben Absonderungen , bitte beim nächsten Mal "zarter" formulieren, im Forum sind Kinder und Damen anwesend.

So, ich habe ja versprochen, dass ich entsprechend antworte und der Urlaub ist ja jetzt vorbei.

Zitat von Gabbid

1. Wenn ich dir als exemplarischer Kunde meine Wünsche für ein Plugin notiere, wie viel Spielraum bei der Umsetzung nutzt du dann?
Damit meine ich, wenn ich dir lediglich grob Wünsche notiere, du es in Funktionen "übersetzt", dann wird das Plugin das später aufweisen/tun, aber ab wann kommt der Sprung zu "mehr", also ab welchem "Grad", bei welchem Schritt (?) setzt dein technisches, schöpferisches (?) Wesen ein, so dass du das Plugin konzeptionell weiterentwickelst?

Wie erkläre ich es gut? Nun ja, wenn du mir nur sehr grobe Wünsche äußerst, werde ich in der Regel nachfragen, was du genau wünscht und dich auch mit fragen Löchern. Das ist etwas, was ich aus dem Desaster mit der Gedenkstätte gelernt habe, die kaum die Anforderungen von allen erfüllte. Ich habe dort viele Wünsche gehabt, die ich vereinen sollte und jeder stellte sich was anderes vor, also musste ich diese Wünsche zusammen fassen und mir selbst überlegen, wie ich diese Umsetzte, was raus kam war nicht gut sondern eher schlecht. Was auch der Grund war, warum ich die Gedenkstätte dann an Tom veräußert habe und mich daraus zurück gezogen habe.

Ein Sprung - wie du ihn so schön nennst - setzte nicht bei der Entwicklung ein, da setzte ich die groben Wünsche so gut es ging um, sondern meist setzt der Sprung dann ein, wenn das Produkt fertig ist und man merkt, dass es nicht optimal ist. Ich hatte für eine folgende Version der Gedenkstätte einige Planungen angestellt, die das eigentlich System sehr weit abstrahiert hätte und damit dann für viele Aufgaben geöffnet hätte. Ich habe zu der Zeit auch viele Systeme verglichen und gemerkt gehabt, dass der Grundaufbau von vielen Systemen gleich ist. Diese Überlegungen kommen meist bei mir also, wenn etwas abgeschlossen ist.

Grobe Wünsche sind also nicht so gut, da man zu viel Interpretieren kann und sich erst mal über das grundlegende Konzept Gedanken machen muss. Das schöpferische Wesen ist also damit beschäftigt die Wünsche überhaupt greifbar zu machen und wirkliche konzeptionelle Weiterentwicklungen finden erst dann statt, wenn das Produkt eigentlich fertig ist und im Test und die Leute ihre Wünsche konkretisieren. Erst dann fängt man an konzeptionell die Funktionen weiterzudenken und zu entwickeln. Was du also meinst findet meist genau dann statt, wenn man im Einsatz dann Mängel sieht und bemerkt und die Ideen klarer werden.

Anders sieht es aus, wenn die Wünsche klarer definiert sind und man sogar Beispiele bekommt. Dort kann man dann direkt ansetzten und kann diese Wünsche und Beispiele weiter entwickeln. Das beste Beispiel hier ist der Wunsch von Bibini nach einer Inhalts-Box für die BBCodes. Da sie mir Beispiele lieferte, konnte ich an diesen ansetzten und konnte mir überlegen, wie man sie effektiv und vielseitig einsetzt und wie man die Beispiele weiterentwickeln kann.

Zitat von Gabbid

2. Wie definiert der Entwickler (kein spezieller, also nehmen wir den ideellen Entwickler als Rollenkonstrukt] seine/ihre "Anforderungen" in Bezug auf ein Plugin (Kundenwünsche versus fachliche Anforderungen versus individuelle Anforderungen...?)?

Die Frage ist so einfach nicht zu beantworten. Die Frage ist primär aus welchem Grund man etwas entwickelt. BBCodes und Blog-Verbesserungen entwickel ich aus eigenem Antrieb und habe die Entwicklung auch aus entsprechendem eigenen Antrieb gestartet. Beide Produkte sollen bestimmte Anforderungen von mir erfüllen. Auch entsprechend sortiere ich die Wünsche von anderen Benutzern. Wenn ich für mich einen Mehrwert dadrin sehe, setzte ich die Wünsche um, sehe ich diesen Mehrwert nicht, dann nicht.

Anders würde es aussehen, wenn ich ein Produkt verkaufe. Da würde ich primär auf die Wünsche meiner Kunden hören, da diese sich etwas wünschen und etwas haben möchten.

Die fachlichen Anforderungen stehen dann auf einem ganz anderem Blatt. Merke ich, dass etwas nur schwer umgesetzt werden kann oder nur mit starken Umwegen, werde ich erst mal die Funktion bewerten und dann überlegen, ob es den Aufwand rechtfertigt.

Ich habe das Thema hier nicht vergessen, war nur ein wenig bei den "Vorstellungen" eingebunden, so dass ich nicht umgehend dazustoßen konnte.

Deine Erklärungen sind hilfreich, ich kann es mir vorstellen, nur zugleich habe ich direkt weitere Fragen, wobei ich denke, ich habe unbewusst eine andere Zugangsweise im Kopf als ein Entwickler. Wann immer das der Fall ist, einfach direkt sagen, dann lerne ich wenigstens noch etwas dazu.

Ich möchte gerne an der Stelle mit dem "Sprung" ( ) einsteigen, weil mir einiges noch nicht ganz klar erscheint.

Es ist nachvollziehbar, dass je konkreter ein Wunsch ist, desto besser kann ihn der Entwickler skizzieren und umsetzen. Du sagtest nun, von der Abstraktionsebene her gesehen kommt unser Sprung zur entwicklungstechnischen Freiheit bzw. dem potenziellen Erweiterungsgrad dann, wenn das Plugin an sich fertig ist und man z.B. Fehler entdeckt.
Ok, ich märze nun die Fehler aus, das Plugin läuft rund, wird angenommen und nun kommen X Nutzer, die Ideen zu Erweiterungen haben.
Meine Fragen dazu wären diese:

a) Ist es entwicklungstechnisch gesprochen einfacher oder komplexer, wenn ich ein Produkt dann "nachträglich" erweitere, oder spielt das keine Rolle?

b) Unwissend gefragt: Warum würde ich bei einem Plugin nicht bereits nach seiner stabilen Nutzungsphase hergehen und dem Plugin zumindest latent (das ist dann übertragen gesehen zu lesen, wir geben dem Plugin also codetechnisch schon seine zusätzlichen Optionen mit, aber "aktivieren" sie einfach noch nicht? Ich denke da an eine Art Dummy-Platzhalter-Idee, habt ihr das in der Entwicklung auch oder versuche ich gerade etwas aus der linguistischen Syntax auch auf die Entwicklung zu stülpen?) zusätzliche optionale Funktionen mitgeben - hat das praktische Gründe, ist es ein Kosten-Nutzungsvergleich bzw. hat rein vermarktungstechnische Gründe (Update-Aspekt zwecks Nutzerbindung)?

c) Wo ziehe ich die Grenze zwischen Anpassung (individuell/allgemein) und prinzipieller Funktionsvielfalt?

......

Das würde ich dann auch gerne näher durchsprechen:

Zitat von Teralios

Wenn ich für mich einen Mehrwert dadrin sehe, setzte ich die Wünsche um, sehe ich diesen Mehrwert nicht, dann nicht.

Wie würde man, wenn man es sollte, bei einem Plugin von einem Mehrwert in Punkto Funktionen sprechen?
Sieht man das rein quantitativ (wenn XX Nutzer den selben Wunsch haben, ist es ein Mehrwert), schrammen wir da an der Grenze zum "Sprung", weil man das Plugin an sich eben hinsichtlich seiner grundsätzlichen Ausrichtung/er her ideal/er ausnutzt, oder wägt man recht nüchtern nach Einsatzfeld ab (Mehrwert = Plugin kann vielfältiger in unterschiedlichen Foren eingebunden/genutzt werden)?

......

Ich selber "muss" mich jetzt nicht wirklich praktisch mit Plugins und der Entwicklung auseinandersetzen, nur streife ich diese Bereiche unweigerlich. Dabei stellen sich mir Fragen, die vermutlich schon aus meiner Herangehensweise und dem fehlenden fachlichen Hintergrund bedingt sind. Falls ich mein Fragenkonto damit nicht überziehe, vielleicht kann man diese Stichpunkte noch in die Gesprächsrunde einbeziehen?

1) Wie musst man am Ende des Tages bei einem Plugin entscheiden - baut man es mehr aus Sicht des Entwicklers oder muss zu mehr als 50% den späteren Nutzer im Kopf haben und somit eventuell Kompromisse eingehen?

2) Womit tun sich Anwender tendenziell leichter:
a) Das Plugin wird sukzessive erweitert und man lernt die Handhabung dann ebenso aufbauend
b) Das Plugin ist komplett funktional erstellt und der Nutzer muss sich alles sofort aneignen

3) Was ist für den Nutzer praktisch gesehen einfacher und gar besser (?):
a) Ich gestalte die ACP-Konfiguration überwiegend simpel im Stile von "select fields"
b) Ich gestalte das ACP so, dass ich weniger direkte Auswahloptionen vorgebe, sondern die Nutzer abeiten selber bspw. mit CSSCode?

Müsste ich antworten, sähe meine "Lösung" so aus:

1) Antwort B, ich würde eher auf den späteren Nutzer hin entwickeln
2) Antwort a) wäre einfacher und man hat die Chance es von grundauf zu lernen
3) Antwort a), das ist subjektiv gesprochen für mich die einfachere und logischere (?) Option

Vom Gefühl her sehe ich nun die Entwickler schon mit den Füßen scharren und mir mental einen Knuffer geben, weil ich vermutlich falsch denke, richtig? Das Problem ist, ich könnte nicht alles mit vielen Argumenten belegen, es ist mitunter einfach ein subjektiver Eindruck oder liegt daran, dass ich es so gewohnt bin (?), seitens einiger Entwickler und deren Produkte "verwöhnt" (?) bin? Von daher wäre es spannend zu erfahren, ob es jeweils wirklich faktische Gründe für eine Antwort gäbe, gibt es solche?

Ich stoppe hier, weil ich sonst wieder zu viel auf den Tisch packe und es unleserlich wird. Die Rückmeldung wiederum ist nun nicht eine Form der "Hausaufgabe, richtet sich nicht rein an sich, Teralios, also nicht denken, das gilt es nun abzuarbeiten, weil es sonst keinen Fleißkeks gibt.

Das ist wieder ein gewaltiger Beitrag, der einen doch auch fast erschlägt. Bitte sei daher nicht böse, wenn etwas ungenauer ist, da einfach nach fragen.

Zitat von Gabbid

Ist es entwicklungstechnisch gesprochen einfacher oder komplexer, wenn ich ein Produkt dann "nachträglich" erweitere, oder spielt das keine Rolle?

Wie meine Professorin so schön sagt und sagte: »Es kommt drauf an«. Je nach Planung des Systems und ob man bestimmte Faktoren beachtet hat oder nicht, kann es einfacher sein ein Produkt zu erweitern oder eben schwerer. Das hängt von der Planung ab.

Ein für mich sehr gutes Beispiel ist aktuell die Suche vom WCF. Diese wurde bereits soweit abstrahiert, dass hier für die Suche eine eigene Index-Tabelle genutzt wird. Die Abstraktion funktioniert jedoch nur mit sehr ähnlichen Typen von Datenbanken, da sehr viel noch auf den einen Typ ausgelegt ist. Es ist daher schwerer weitere Datenbanken - die z.B. spezialisiert sind auf Volltext suche (SolR, ElasticSearch usw.), einzubinden und benötigt viel arbeit. Die Suche also durch eine »bessere« zuersetzten ist daher schwer und komplex.

Anders sieht es jedoch aus bei weiteren Datenquellen, die den Suchindex füttern sollen. Diese können sehr einfach einbezogen werden. Die Frage ist immer, was in der Planung beachtet wurde und wie weit man denken konnte.

Zitat von Gabbid

b) Unwissend gefragt: Warum würde ich bei einem Plugin nicht bereits nach seiner stabilen Nutzungsphase hergehen und dem Plugin zumindest latent (das ist dann übertragen gesehen zu lesen, wir geben dem Plugin also codetechnisch schon seine zusätzlichen Optionen mit, aber "aktivieren" sie einfach noch nicht? Ich denke da an eine Art Dummy-Platzhalter-Idee, habt ihr das in der Entwicklung auch oder versuche ich gerade etwas aus der linguistischen Syntax auch auf die Entwicklung zu stülpen?) zusätzliche optionale Funktionen mitgeben - hat das praktische Gründe, ist es ein Kosten-Nutzungsvergleich bzw. hat rein vermarktungstechnische Gründe (Update-Aspekt zwecks Nutzerbindung)?

Ich habe aktuell durchaus auch schon Dummy-Platzhalter in einer Entwicklung verwendet, da die Funktionen geplant wurden, aber noch nicht für den Einsatz gedacht waren oder ich mit der Lösung noch nicht zufrieden war. Nur muss man diese Dummys gut verstecken, denn wenn der Nutzer sie sieht, wirkt das Produkt unfertig.

Zitat von Gabbid

c) Wo ziehe ich die Grenze zwischen Anpassung (individuell/allgemein) und prinzipieller Funktionsvielfalt?

Entschuldige die sehr platte und einfache Antwort: Du ziehst die Grenze dort, wo du sie ziehen willst. Jeder definiert diese Punkte anders. Die Frage könnte man nämlich auf die grundlegende Frage des Themas runter brechen.

Zitat von Gabbid

Wie würde man, wenn man es sollte, bei einem Plugin von einem Mehrwert in Punkto Funktionen sprechen?
Sieht man das rein quantitativ (wenn XX Nutzer den selben Wunsch haben, ist es ein Mehrwert), schrammen wir da an der Grenze zum "Sprung", weil man das Plugin an sich eben hinsichtlich seiner grundsätzlichen Ausrichtung/er her ideal/er ausnutzt, oder wägt man recht nüchtern nach Einsatzfeld ab (Mehrwert = Plugin kann vielfältiger in unterschiedlichen Foren eingebunden/genutzt werden)?

Auch das ist eine Frage, die jeder für sich selbst beantworten muss. Ich erkläre es dir aber mal aus meiner Sicht und wie ich bei den Blog-Verbesserungen vorgehe. Dazu ist folgendes Thema für dich und auch andere als Grundlektüre wichtig: User-Blog statt Kategorien bzw. Blog für jeden User.

Hier wird von User-Blog statt der aktuellen Ausrichtung gesprochen und entsprechende Vorschläge gemacht. Ich habe mir davon bestimmte Vorschläge angesehen und habe dann entschieden, was ich gerne auch im aktuellen Blog hätte als Betreiber und was eben nicht. Beispiel ist eine Autoren-Seite bei dem alle Beiträge des Autors aufgelistet wird. Das ist aktuell zwar möglich, sieht jedoch nicht sehr schick aus. (Zu sehen in meinem Blog) Da würde ich gerne eine etwas schönere Seite gestalten mit dem üblichen kleinen Profil in der Seitenleiste, seinen favorisierten Artikel usw. Das wäre dann eine interessantere Seite. Da bietet der Vorschlag aus dem genannten Thema einen Mehrwert für mich, da ich es gerne auch so sehen würde. Die Benutzerblogs sind für mich jedoch - in der Form wie dort gefordert - jedoch kein Mehrwert mehr, da ich diese Art von Blog nicht brauche.

Der Mehrtwert der Funktionen ergibt sich in meinem Fall also daraus, ob die Benutzbarkeit des Blogs besser wird in meinen Augen.

Zitat von Gabbid

1) Wie musst man am Ende des Tages bei einem Plugin entscheiden - baut man es mehr aus Sicht des Entwicklers oder muss zu mehr als 50% den späteren Nutzer im Kopf haben und somit eventuell Kompromisse eingehen?

Die Frage ist, wen ich ansprechen möchte mit meinem Plugin. Ich baue meine Plugins primär für mich und stell sie dann anderen zur Verfügung. Ich baue meine Plugins also immer aus meiner Sicht und die lasse ich mir auch nicht nehmen. Wenn mir etwas nicht zusagt, werde ich es nicht einbauen. Anders sieht es aus, wenn ich die Plugins primär für andere bauen würde und sie verkaufen würde. Dort würde ich dann auf meine Kunden hören und das einbauen, was dort die Mehrzahl will.

Zitat von Gabbid

2) Womit tun sich Anwender tendenziell leichter:
a) Das Plugin wird sukzessive erweitert und man lernt die Handhabung dann ebenso aufbauend
b) Das Plugin ist komplett funktional erstellt und der Nutzer muss sich alles sofort aneignen

Schwierige Frage und ich zitiere wieder meine Professorin: Es kommt drauf an. Jeder Mensch lernt anders und für jeden Menschen gibt es andere Wege, wie er arbeitet. Für mich wäre sowohl a) also auch b) möglich.

Zitat von Gabbid

3) Was ist für den Nutzer praktisch gesehen einfacher und gar besser (?):
a) Ich gestalte die ACP-Konfiguration überwiegend simpel im Stile von "select fields"
b) Ich gestalte das ACP so, dass ich weniger direkte Auswahloptionen vorgebe, sondern die Nutzer abeiten selber bspw. mit CSSCode?

Auch hier ist die Antwort: Es kommt drauf an. (Frau Prof. Dr. Petras, ich danke ihnen für diesen Satz!) Wenn ich vieles sehr einfach gestalte, nehme ich den Benutzern viele Möglichkeiten oder muss diese simplifizieren. Letzteres kann die Gefahr bergen, dass es am Ende komplizierter für alle wird und sogar Fehleranfälliger, als wenn man einfach bestimmte Kenntnisse voraussetzt.

Es gibt auf die letzten Fragen von dir keine richtige und auch keine falsche Antwort, sondern nur individuelle Antworten.

Zitat von Teralios

Das ist wieder ein gewaltiger Beitrag, der einen doch auch fast erschlägt. Bitte sei daher nicht böse, wenn etwas ungenauer ist, da einfach nach fragen.

Oh bitte, ich habe mich extra kurz gefasst und sag nichts Falsches, das ist kurz für meine Verhältnisse! Und bevor du fragst:
Nein, wir können die weiterführende Diskussion nicht via Quellcode abhandeln, denk nicht einmal daran!
Nein, ich möchte keine Einführungsrunde in die Entwicklung (das steht nicht in meinem Vertrag )
Nein, du kannst mich nicht ins Community Forum abschieben und sagen, sie sollen sich dort mit mir befassen.

Hmm, der Wink mit der Professorin wiederum ist gut, wobei, sie würde mich wohl auf Anhieb durchschauen und sagen, es war eine gute Entscheidung, dass ich bei den Geisteswissenschaften gelandet und geblieben bin...

Machen wir einfach weiter? Ja, machen wir, ich lege los:

Weil du die WCF-Suche eingeführt hast und wir schon einmal beim Thema Such-Systeme waren - du kennst doch die Suchsystme der Bibliotheken, nicht wahr?
Also zum einen die "Einfache Suche", die "Erweiterte Suche" , die diversen Katalog- und Archivsuchen. Das Prinzip basiert also, wenn ich dich richtig verstanden habe, darauf, dass wir ähnliche Datenbanken vom Grundgerüst her haben und die in der Kombination funktionieren, ja? Das wiederum kann ich nicht nehmen und "schnell mal" in die WCF-Suche integrieren, da es unterschiedliche Quellen wären, ich müsste das also irgendwie kombinieren und "verbinden", einfach gesagt (?).

Wenn das so grob richtig ist, warum würde ich dann eine WCF-Suche nicht gleich so bauen, dass sie irgendwie "offener" ist, dass ich "einfach" irgendwie mit einer Schnittstelle alles mögliche verbinden kann, weil ich genau das für mein Projekt benötige? Die Suche dann z.B. im Community Forum wäre dann so passend für dort, ich würde (als Beispiel) für cls-design eine andere Suche brauchen, du für deinen Blog wieder eine andere usw. Vertehst du wie ich es meine und ist das überhaupt möglich oder muss man sagen, auch Community Software hat ihre Grenzen in Punkto Flexibiliät?

.....

Zitat von Teralios

Ich habe aktuell durchaus auch schon Dummy-Platzhalter in einer Entwicklung verwendet, da die Funktionen geplant wurden, aber noch nicht für den Einsatz gedacht waren oder ich mit der Lösung noch nicht zufrieden war. Nur muss man diese Dummys gut verstecken, denn wenn der Nutzer sie sieht, wirkt das Produkt unfertig.

Du wirst es geahnt haben ...

...wo platziert man einen solchen Dummy?
...wie würde ich als Nutzer ihn erkennen?
...wie macht man es, dass man ihn nicht erkennt?
...kann ich theoretisch und praktisch viele Dummys einbauen?

Ich frage, weil ich nachvollziehen möchte, ob sich so etwas praktisch überhaupt bewähren würde, wenn ja, wie man es machen würde und dann würde ich später gerne die Pro- und Contra-Liste aufmachen.

.....

Den Blog stelle ich kurz zurück, aber Danke für den Lesetipp, das ist interessant und ich habe mir Notizen für Einwürfe gemacht. Ich denke das "Problem" in der Diskussionsrunde dort liegt schon in der Definition Blog, der Einbindung in einem Forum und ich habe intuitiv das Gefühl, man müsste Nutzerprofil (gerade bei WBB 4), Blog und Blogs einerseits separiert betrachten und dann zugleich verbinden, was technisch komplexer wird (das habe ich einmal angefangen mit Cr@@gle zu besprechen und puh, nicht so einfach. ). Aber, das Thema an sich ist nicht uninteressant, wenn ihr das auch so seht, wollen wir nicht daraus ein eigenes Thema machen, rüberspringen und es näher abklopfen?

.....

Zitat von Teralios

Die Frage ist, wen ich ansprechen möchte mit meinem Plugin. Ich baue meine Plugins primär für mich und stell sie dann anderen zur Verfügung. Ich baue meine Plugins also immer aus meiner Sicht und die lasse ich mir auch nicht nehmen. Wenn mir etwas nicht zusagt, werde ich es nicht einbauen. Anders sieht es aus, wenn ich die Plugins primär für andere bauen würde und sie verkaufen würde. Dort würde ich dann auf meine Kunden hören und das einbauen, was dort die Mehrzahl will.

Ich möchte jetzt sozusagen für einen Moment in deinen Kopf hinein.
Du beschließt also ein Plugin zu bauen, für dich, nehmen wir einfach deinen Blog und du baust etwas dafür. Was tust du als erstes, wie skizzierst du das "Problem", wie entwirfst du das Plugin auf dem Reißbrett und ab wann kommt der spätere potenzielle Nutzer dazu, der es auch nutzen wird?

Du bist jetzt sicher schon von der Handhabung her so "gedrillt", dass du automatisch wie ein Entwickler denkst, richtig oder falsch vermutet? Wenn das richtig ist anzunehmen, dann heißt das auch, du gehst funktional an das Plugin heran, schaust was aus Entwicklersicht sinniger/besser/einfacher (?) ist, aber das wiederum muss später nicht für den Anwender einfach sein, wie Rainer angemerkt hat?
Wenn nun bspw. ich als Nutzer ankomme und dir sagen, wo ich bei deinem Plugin Probleme sehe/habe, kannst du das als Entwickler so nachvollziehen oder musst du dann bis zu einem gewissen Grad einfach deiner Linie treu bleiben, weil es entwicklungstechnisch eventuell besser ist oder hast du Spielraum und am Ende würden die besseren Argumente zählen?

.....

Zitat von Teralios

Zitat von »Gabbid«

2) Womit tun sich Anwender tendenziell leichter:

a) Das Plugin wird sukzessive erweitert und man lernt die Handhabung dann ebenso aufbauend

b) Das Plugin ist komplett funktional erstellt und der Nutzer muss sich alles sofort aneignen

Schwierige Frage und ich zitiere wieder meine Professorin: Es kommt drauf an. Jeder Mensch lernt anders und für jeden Menschen gibt es andere Wege, wie er arbeitet. Für mich wäre sowohl a) also auch b) möglich.

Alles anzeigen

Ich möchte dich festnageln, was sagt bei der Frage...
a) der Entwickler Teralios
b) der Anwender Karsten

?

.....

Zitat von Teralios

Zitat von »Gabbid«

3) Was ist für den Nutzer praktisch gesehen einfacher und gar besser (?):

a) Ich gestalte die ACP-Konfiguration überwiegend simpel im Stile von "select fields"

b) Ich gestalte das ACP so, dass ich weniger direkte Auswahloptionen vorgebe, sondern die Nutzer abeiten selber bspw. mit CSSCode?

Auch hier ist die Antwort: Es kommt drauf an. (Frau Prof. Dr. Petras, ich danke ihnen für diesen Satz!) Wenn ich vieles sehr einfach gestalte, nehme ich den Benutzern viele Möglichkeiten oder muss diese simplifizieren. Letzteres kann die Gefahr bergen, dass es am Ende komplizierter für alle wird und sogar Fehleranfälliger, als wenn man einfach bestimmte Kenntnisse voraussetzt.

Alles anzeigen

Ich bin noch nicht glücklich mit der Antwort.

Was ist aus deiner Sicht "einfacher", a) oder b)?
Wo genau wären die Probleme, wenn etwas zu einfach ist, hättest du ein Beispiel parat?
Fehleranfälliger, weil Nutzer etwas falsch machen oder...?

.....

Ich mag den Begriff bzw. die Titulierung nicht, auch wenn ich verstehen kann, wie sie zustande kam. Wenn ich sie nun einmal gebrauchen darf und euch frage: Wäre es eigentlich sinnvoller (?), wenn man Plugins so gestaltet, dass sie wirklich für den DAU (pardon ) gedacht sind - also doch einfacher, weniger komplex und weniger Funktionen? Sprich, je weniger komplex, desto einfacher zu bedienen und simpel einsatzfähiger, daher auch weniger fehleranfällig, oder geht die Rechnung so nicht auf, man muss einen anderen Anwendertypus im Kopf haben?

Interessante Eindrücke und Einblicke, IronEagle, darf ich prompt nachhaken?

Von deiner Herangehensweise als Nutzer/Anwender - würdest du tendenziell ein "vollgepacktes" Plugin von den Funktionen her eher/eher nicht interessant finden oder unterscheidest du streng nach deiner Nutzung? Das heißt, wägst du immer recht nüchtern (?) nach Bedarfsfall ab oder nimmst du auch Produkte, die mehr können, nutzt sie dann sogar nach und nach (wie beim CMS-Beispiel auf deiner Plattform)?

Eine vermutlich komische Frage, aber machst du dir eigentlich Gedanken darüber, dass je mehr Plugins von unterschiedlichen Entwicklern/Anbietern du hast, das zugleich auch im Bedarfsfall mehr Support, das Stelldichein auf unterschiedlichen Seiten und ggf. Probleme mit sich bringen könnte (Stichwort Kompatibilität, Entwickler stampft das Produkt ein u.ä.) oder spielt das keine Rolle, du blendest das aus?

Wenn du das überblicken und grob einschätzen kannst - wie stark nutzt du deine Plugins aus, wenn ich fragen darf? Ich habe deine Kleingarten-Seite noch grob im Kopf und du hast hier das CMS-Beispiel vermerkt, wie sieht das auf deiner anderen Seite aus bzw. mit anderen Plugins?

Dein Gefühl und deine Erfahrung: Sind simple Plugins (simpel = auf eine Funktion beschränkt) einfacher zu nutzen und werden tendenziell bevorzugt oder multifunktionale Plugins, die aber eventuell mit Anleitungen geliefert werden und nicht immer komplett von den Funktionen her ausgeschöpft werden (können)?

Zum Schluss noch ein Schwenk hierzu:

Zitat von IronEagle

früher hatte ich die einstellung je mehr plugins desto besser.

Kannst du dich noch erinnern, wie du zu dieser Haltung kamst und ab wann bzw. wie hat es sich geändert?

Ich hoffe, ich "löchere" dich nicht (?), aber wenn du magst und irgendwann Zeit hast, schreib gerne, erzähle und falls du auch hier und da Beispiele hast, nur zu, Links&Co. sind willkommen.
Mir fehlt einfach zu viel praktische Erfahrung, daher finde ich reale Erfahrungsberichte und Einschätzungen immer sehr spannend und hilfreich, es ist dann nicht so theoretisch wie Anleitungen und Artikel aus z.B. Fachblogs.