Add-ons Center von WebsiteBaker

[Waldschwein]

Hallo!

Mit der neuen Webseite gibt es auch ein Formular zum Hochladen von Add-ons (also Modulen, Templates, Backend-Themes...)
http://www.websitebaker2.org/de/add-ons/add-ons-projekt/mitmachen.php

Grundsätzlich wird aber daran gearbeitet, den ganzen Add-on Center von Grund auf neu zu strukturieren, und für alle (Benutzer, Modulautoren, Team von WB zum Überprüfen) den Workflow, die Arbeit zu verbessern und es einfacher zu gestalten.

Alles, was darüber angedacht wird - also Vorschläge - bitte hier hineinschreiben.

Bitte beachten: Es geht _nicht_ um die Auswahl der vorhanden Add-ons, es geht _nicht_ um AMASP, es geht um das Center an sich, also die Basis des Ganzen. Gefüttert wird es erst dann, wenn alles steht.

Gruß Michael

[doc]

Hi,

folgende Punkte fände ich gut:
 - bessere Aufbereitung und Darstellung der Add-ons (z.B. https://addons.mozilla.org/de/firefox/)
 - Schnellliste aller Add-ons welche z.b. nach Typ, Downloads, Autor etc. sortiert werden kann
 - Suchfuntkion welche auf die Add-ons selbst beschränkt ist ähnlich wie bei den Templates
 - vernünftige Aufnahmekriterien für Add-ons (was muss, was kann, Template)
 - Möglichkeit den Status der eingereichten Add-ons zu analysieren (eingereicht, geprüft, xxxx)
 - Möglichkeit einzelne Add-ons zu bewerten
 - Beschreibung mehrsprachig

Soweit mal fürs erste.

Doc

[WebBird]

- bessere Aufbereitung und Darstellung der Add-ons (z.B. https://addons.mozilla.org/de/firefox/)

Gut, das ist das Mindeste. Allerdings ist das auch Geschmackssache. Da wird man auf keinen Fall eine Darstellung finden, die ungeteilte Begeisterung findet.

- Schnellliste aller Add-ons welche z.b. nach Typ, Downloads, Autor etc. sortiert werden kann

Bisher geplant ist:
* Sortierung nach Name
* Sortierung nach Bewertung
* Sortierung nach Downloads

Die Addons sind in Kategorien eingeteilt, insofern braucht man keine Sortierung nach Typ. Zudem kann man nach Addons suchen (derzeit nur nach Namensbestandteil).

- vernünftige Aufnahmekriterien für Add-ons (was muss, was kann, Template)

Bin mir nicht sicher, ob ich das richtig verstehe. Zumindest werden Addons einen Status haben, etwa "gerade erst neu registriert", "in review" (QM-Team), "freigegeben". Das paßt zu diesem Punkt:

- Möglichkeit den Status der eingereichten Add-ons zu analysieren (eingereicht, geprüft, xxxx)

- Möglichkeit einzelne Add-ons zu bewerten

Ist geplant, siehe auch Punkt "Sortierung".

- Beschreibung mehrsprachig

Versteht sich von selbst! Englische Beschreibung ist Pflicht, andere Sprachen sind optional.

[dbs]

- wegen der übersichtlichkeit nicht zu viel text zu jedem addon, erst bei mehr interesse toggle oder popup mit mehr text.
- in der beschreibung auf jeden fall beispielbild oder- link.
- englische beschreibung auf der deutschen seite macht keinen guten eindruck.

dbs

[maverik]

Englische Beschreibung ist Pflicht, andere Sprachen sind optional.

wer legt das fest?

[mr-fan]

Englische Beschreibung ist Pflicht, andere Sprachen sind optional.

wer legt das fest?

schätze das ist ein missverständniss...

denke bianka meinte nicht das englisch allein und einzig stand der dinge ist, sondern die basis!

ein Entwickler aus Indonesien stellt halt sein modul mit EN Text als Beschreibung zur Verfügung - natürlich sollte das Homepage Team das auf alle Fälle in die Sprachen der WB Seite Übersetzen......?

denk ich mir mal - englisch ist halt eine basis ohne die dir keiner das in eine andere sprache übersetzt...

gruß martin

[maverik]

ich denke mal das ist eine diskussion die nicht ins forum gehört und an anderer stelle entschieden wird / werden sollte

englisch ist halt eine basis

die basis ist derzeit en, de, nl, in den sprachen ist die seite aufgebaut und dafür gibt es übersetzer. dem deutschen entwickler zu sagen "ohne englische beschreibung kommt dein addon nicht ins repository" geht schlichtweg nicht.

[WebBird]

- wegen der übersichtlichkeit nicht zu viel text zu jedem addon, erst bei mehr interesse toggle oder popup mit mehr text.

Ist genau so vorgesehen. Es gibt eine Kurzbeschreibung und einen Langtext, letzterer erscheint nur, wenn man auf "mehr" klickt. Der Langtext ist auch nicht Pflicht.

- in der beschreibung auf jeden fall beispielbild oder- link.

Ist nicht Pflicht und hängt dann halt davon ab, was der Modulentwickler bietet.

- englische beschreibung auf der deutschen seite macht keinen guten eindruck.

Natürlich erscheint die Sprache zuerst, die der aktuellen Seitensprache entspricht. Wenn natürlich kein deutscher Text vorhanden ist, erscheint der englische. Man kann nur anzeigen, was vorhanden ist...

@maverik: Einer muß ja Pflicht sein, und das ist eben der englische. Wir wollen schließlich international sein.

[WebBird]

die basis ist derzeit en, de, nl, in den sprachen ist die seite aufgebaut und dafür gibt es übersetzer. dem deutschen entwickler zu sagen "ohne englische beschreibung kommt dein addon nicht ins repository" geht schlichtweg nicht.

Komische Schlußfolgerung.

Zudem gehe ich davon aus, daß jeder halbwegs ernstzunehmende Developer wenigstens ein bißchen Englisch kann. Ansonsten wäre er nämlich aufgeschmissen. 80% der Dokumentationen sind in englischer Sprache gehalten.

Es wurde aber nirgendwo gesagt, daß ein Addon nicht ins Repository darf, wenn der Developer nicht in der Lage ist, einen englischen Text zu verfassen. Bitte nicht irgendwelches Zeug reininterpretieren und dann auch noch darüber zu wettern anfangen. Du streitest Dich nämlich gerade mit Dir selber.

[maverik]

@maverik: Einer muß ja Pflicht sein, und das ist eben der englische. Wir wollen schließlich international sein.

"du" bist nicht "wir", deshalb überlasse diese entscheidung anderen

Zudem gehe ich davon aus,

wieder "du"

ein bißchen Englisch kann. Ansonsten wäre er nämlich aufgeschmissen. 80% der Dokumentationen sind in englischer Sprache gehalten.

englisch lesen können um eine doku zu verstehen setzt nicht zwangsläufig voraus auch englische texte schreiben zu können

[WebBird]

@maverik: Einer muß ja Pflicht sein, und das ist eben der englische. Wir wollen schließlich international sein.

"du" bist nicht "wir", deshalb überlasse diese entscheidung anderen

Wenn ich woanders - modX, Drupal, Firefox, whatever... - ein Addon registrieren will, muß ich das auch auf Englisch tun. Davon abgesehen interpretierst Du noch immer falsch, und ich glaube, Du machst das mit Absicht. Englisch ist Pflicht - aber wenn der Modulautor das selber nicht hinkriegt, kann er problemlos um Hilfe bitten oder es dem Addons-Team überlassen.

Zudem gehe ich davon aus,

wieder "du"

Hast Du ein Problem mit mir? Dann ist das hier sicherlich nicht der Ort, um das auszutragen.

Übrigens ist AMASP auch komplett Englisch, und ich wüßte nicht, daß das bisher ein großes Problem war. Mein Englisch ist auch nicht perfekt, aber es gibt genügend Leute, die man fragen kann. (Notfalls geht auch Google Translate, auch wenn das eher Anlaß zur Belustigung ist. *g*)

Vielleicht solltest Du das einfach den Entwicklern überlassen, bzw. dem Addons-Team. Du regst Dich hier über Dinge auf, die Dich erstens gar nicht betreffen, und zweitens sowieso von Dir selbst erfunden wurden.

[dbs]

- in der beschreibung auf jeden fall beispielbild oder- link.

Ist nicht Pflicht und hängt dann halt davon ab, was der Modulentwickler bietet.

vielleicht können auch besucher/interessierte einen link oder image ranheften?
jedenfalls finde ich etwas visuelles echt nötig. auf amasp bei den droplets z.b.: nur text, nix bildchen. *bäh*

dbs

[WebBird]

Ich persönlich würde keinen x-beliebigen Besucher da ranlassen wollen. Modulentwickler müssen sich registrieren, um ihre Module verwalten zu können; das ist das übliche Vorgehen, andere machen das auch so. Ob es noch einen Weg "außen rum" geben wird, etwa indem man einfach sein Modul an das Addons-Team schicken kann, ohne sich zu registrieren, entscheide ich nicht. Ich bin auch nur für die technischen Aspekte zuständig, weder für das Layout, noch für organisatorische Fragen.

Vorgesehen sind jedenfalls (aus rein technischer Sicht):

* Link auf Autor-HP
* Demo-Link
* Screenshots (theoretisch beliebig viele)

Alles bisher optional.

Edit: Letztlich ist alles auch eine Frage, wie groß und fleißig das Addons-Team dann sein wird. Die können dann ja beispielsweise im Zuge des Reviews die Texte überarbeiten, Screenshots ergänzen etc. Aber das sind wie gesagt organisatorische, nicht technische Fragen.

[Waldschwein]

Hallo,

bitte diskutiert hier nicht über Sprachen, das ist momentan völlig unsinnig. Wenn die Basis für Mehrsprachigkeit vorhanden ist, ist es gut, fertig. Wir brauchen jetzt nicht festlegen, ob es dann mal mehrsprachig wird und wer überhaupt - erst einmal brauchen wir die technische Vorraussetzung und ebenso Guidelines, Workflow etc. Die Übersetzung ist völlig unwichtig jetzt, weil es nicht braucht. EN ist Standard, alles andere nach Bedarf. Wenn Mozilla das so handhabt, müssen wir das nicht übers Knie brechen, sonst gibt's gar nichts neues.

Noch etwas: Das Homepage Team wird garantiert keine Module und deren Beschreibungen übersetzen, dafür ist es nicht da.

Gruß Michael

[WebBird]

Ich würd ja gern mal nen Screenshot posten, aber dann stürzen sich wieder gleich alle auf das Layout, welches im Moment noch überhaupt kein Thema sein dürfte.

Ich versuche mal zu beschreiben, was das Repo derzeit kann - was aber nichts damit zu tun hat, wie es dann am Ende tatsächlich umgesetzt wird:

Allgemein

* Aktuelle Seitensprache ist ausschlaggebend für die Gesamtsprache; sind allerdings für die aktuelle Seitensprache keine Übersetzungen vorhanden, erfolgt ein Fallback auf die Defaultsprache. (Ob das Englisch ist, Kantonesisch, Klingonisch oder "Bork, Bork, Bork!", ist dabei völlig unerheblich.)

Kategorien

* Beliebig verschachtelbar
* Name, Beschreibung, Icon
* Name und Beschreibung in weitere Sprachen übersetzbar, Icon immer gleich (Wiedererkennungswer t!)

Addons

* Jedes Addon hat eine Hauptkategorie, kann aber beliebigen weiteren Kategorien zugeordnet werden
* Jedes Addon hat einen Verantwortlichen, kann aber beliebigen weiteren Autoren zugeordnet werden
* Name, Kurzbeschreibung, Langbeschreibung
* Kurzbeschreibung und Langbeschreibung in weitere Sprachen übersetzbar, Name immer gleich (Wiedererkennungswer t!)
* Weitere Informationen:
** Erfassungsdatum
** Datum der letzten Änderung
** Addon-Version
** WB-Version
** Anzahl Downloads
** Bewertungspunktzahl (Rating)
** Addon-Status (review, bestätigt, zurückgezogen, whatever)
** Entwicklungsstatus (Beta, released, whatever)
** Demo-URL
* Beliebige Anzahl an Download-Links
* Beliebige Anzahl an Screenshots

Autoren

* Ein Autor muß sich registrieren, wenn er seine Addons selbst verwalten will
* Name, Homepage, Kontaktadresse

Suchmöglichkeiten

* Nach Name oder Namensbestandteil
* Nach Autor (vorhandene Autoren werden aufgelistet)
* Nach Addon-Status
* Nach Entwicklungs-Status
* Nach Kategorie

Die Suchoptionen sind natürlich kombinierbar. (Z. B. Suche nach Autor "WB Core" mit Addon-Status "freigegeben" und Entwicklungsstatus "released" in Kategorien "A", "B" und "C".)

Das sind BISHERIGE Planungen, keine ENDGÜLTIGEN. Das Frontend ist schon recht weit, das Backend existiert im Prinzip noch gar nicht, daher ist nicht kurzfristig mit einer Demo zu rechnen.

[doc]

@webbird: Klingt doch schon mal vielversprechend.

Doc

[Waldschwein]

Hallo!

Ich möchte noch das Wichtigste in den Raum werfen:

--- Automatisierung. ---

Ganz wichtig: Egal wie gut und groß das Add-on Center Modul letztendlich ist, es muss einiges mehr dahinter stecken.
Dabei müssen folgende Fragen geklärt werden, und zwar so, dass niemand der Beteiligten benachteiligt wird und jeder der Beteiligten einen Vorteil hat, und es so einfach wie möglich geht. Beiteligte sind die drei Gruppen:
- Benutzer: Also der, der herunterlädt und den man nie sieht, außer dass die Downloadzahlen nach oben gehen, aber für den man es (auch) macht.
- Modulentwickler: Der, für den man es wirklich macht. Ohne Modulentwickler keine Module, so einfach ist das. Also muss man gerade diese Zielgruppe einbinden. Und gerade diese Zielgruppe wird gerne vernachlässigt.
Hier muss man sich einige Fragen stellen:
--- Wie kann der Modulentwickler erfahren, ob sein Add-on überhaupt funktioniert, ob es auch den Richtlinien (!!!!!!!!!) entspricht, was muss er selbst tun, was kann er dabei selbst tun?
--- Wie kann der Modulentwickler das Modul überhaupt in das Add-on Center hochbringen? Allgemein geht das so: Formular ausfüllen, warten, dann wirds freigeschalten (oder eben nicht). Und gerade das ist der Knackpunkt des Ganzen: Jemand muss sich entweder für Ja oder Nein entscheiden. Und dafür braucht es wiedermal Richtlinien und einen definierten Workflow. Zudem wäre es sinnvoll, wenn der Modulentwickler nicht jedesmal alles neu hochladen muss und neu ausfüllen muss, er auch einen Überblick bekommt, welche Module er überhaupt bearbeitet. Ein Berechtigungssystem wäre dabei sehr hilfreich - oder gleich ein Projektmanagement-Tool wie Redmine, mit Git / SVN hinten dran. Doch erfahrungsgemäß benutzen die Autoren solche Systeme nicht.
--- Was passiert bei Updates, was passiert bei Weggang des Autors, wer kann es übernehmen? Etc. pp. Die jetzige Webseite bietet auch hier ein paar Ansätze, wie die Sicherheitsformular e oder eben das Add-on Formular - doch das ist ja bloß der Anfang.

Und die letzte Gruppe: Das Add-on-Team.
Das Add-on Team braucht unbedingt eine Checkliste vor sich liegen, die es abarbeitet, wenn ein Modul reinkommt, die Punkte zusammenzählt und dann in wenigen Minuten sagen kann "Durchgefallen", "Punkt 2, 5 und 8 müssen, Punkt 12 und 17 sollten verbessert werden" oder "Akzeptiert und freigeschalten". Kommt eine neue WB Version heraus, müssen alle Add-on wieder validiert werden - siehe Firefox, da klappt das auch. Man muss das ja nicht so machen, aber bezieht doch die Community ein! Es bringt nichts, wenn das Add-on Team abgeschottet im Elfenbeinturm sitzt, und sich von A - Z die ganze Mühe macht, und dann nach 12 Add-ons keinen Bock mehr hat, weil es für jedes Add-on zwei Stunden braucht.
Da muss die Community einbezogen werden. Evtl. ein Feedback-System einrichten. Diese ganzen Ratingsternchen sind zwar nett, aber nutzlos. Niemand von den aktiven hat einen Nutzen davon - denn wieso wird Bildergalerie 1 mit 4.5 / 5 bewertet, aber Bildergalerie 2 bloß 1.5 / 5? Wenn das Warum nicht Einzug hält, braucht man das ganze nicht - meiner Meinung nach, weil man keinen Nutzen hat.
Das Add-on Team braucht also
a.) einen Workflow, wo es bei jedem neuen Modul / upgedateten Modul / neuer WB-Version / ... weiß, was zu tun ist. Incl. brauchbarer Teststation.
b.) Guidelines, die für jeden sichtbar sind, und nach denen man sich richtet, und die Einzug in die verschiedenen Workflows halten

Zudem wäre es noch wünschenswert, wenn man direkt aus dem WB-Backend upgraden könnte. Das Ganze ist bestimmt machbar. Und es wäre auch gut, wenn die Registrierung des Autors übergreifend ist, er also einen Center "Meine Module" bekommt, evtl. mit Forenzugang verknüpft, evtl. auch über die Arbeit am WB-Core (Bugtracker, Feature Requests, ... , trac muss ja nicht für die Ewigkeit sein, da gibt's mittlerweile bessere und einfachere Systeme).

Gruß Michael

[WebBird]

Nur ein kleiner Einwurf von mir - das sind hauptsächlich organisatorische Punkte. Ich mache den technischen Part. Nur, um da eine klare Abgrenzung zu schaffen. Anders gesagt, ich (ja, ich rede hier nur von mir!) werde nur zu technischen Dingen ein Statement abgeben.

[Waldschwein]

Nur ein kleiner Einwurf von mir - das sind hauptsächlich organisatorische Punkte. Ich mache den technischen Part. Nur, um da eine klare Abgrenzung zu schaffen. Anders gesagt, ich (ja, ich rede hier nur von mir!) werde nur zu technischen Dingen ein Statement abgeben.

Hallo!

Ja, das weiß ich natürlich.
Aber das Problem bei der Arbeit später dann ist ja die Organisation, nicht die Technik. Das wird gerne vergessen. Die Technik erleichter vieles, sie ist vor allem für den Benutzer da, sie soll dem Modulautoren die Arbeit erleichtern, und sie soll auch dem Add-on Team ebenfalls die Arbeit erleichtern. Aber das Hauptproblem ist die Organisation dahinter, zumindest aus meiner Sicht. Eben das großteils "unsichtbare". 

Gruß Michael
 

[WebBird]

So, hier doch mal ein Screenshot. Wehe es meckert einer über das Layout!

Was sieht man:

* Die verschiedenen Entwicklungs- und Addon-Stati sind farbig markiert. So sieht man schon beim kurzen "Drüberscannen" anhand der Farbe, welche Addons in jeder Hinsicht "stabil" sind.

* Screenshots werden als "Links" dargestellt und gehen in einer Lightbox auf. Ob das später auch so sein wird, bleibt abzuwarten. (Keine technische Frage, sondern über das Template zu lösen.)

* Hat der Autor eine Homepage, ist diese verlinkt.

* Oben sieht man die "Sprachumschaltung" in Form von Flaggensymbolen. (Die Flaggen sind Platzhalter, wie alle Grafiken auf der Seite. Wie gesagt, Optik ist derzeit kein Thema.) Gäbe es Übersetzungen, würden die entsprechenden Flaggen angezeigt. Durch Draufklicken schaltet man dann für das entsprechende Modul die Sprache um. (Um für alle Module die Sprache umzuschalten, muß man über die Seitensprache gehen. Ich halte das für logisch und nachvollziehbar.)

Wie gesagt, das ist der derzeitige Entwicklungsstand, nicht mehr und nicht weniger! Also bitte kein Geschrei wegen fehlender Informationen, nicht übersetzter Texte ("approved") oder gar des Layouts!

[gelöscht durch Administrator]

[doc]

Hi,

auch wenn ich mich wiederhole. Sieht doch schonmal ganz gut aus.

Ist geplant, für jedes Add-on eine "optionale Seite" mit weiteren Infos etc. bereit zu stellen? Auf dieser Seite könnten dann wenn vorhanden Zusatzinfos des Moduls (Installation, Abhängigkeiten), oder gar Kommentare (z.B. nur von registrierten Forennutzern) angeboten werden.

Weiter so.

Gruss Doc

[WebBird]

Ich hab sowas im Hinterkopf, würde das dann aber vermutlich für eine "Version 2" aufsparen wollen. Erst mal brauchen wir eine brauchbare Version 1 samt dahinterliegendem Workflow.

[WebBird]

Ich hab mir mal eben eine Übersetzung für Argos' Theme zusammengedrechselt; anbei ein neuer Screenshot. Zeigt die automatische Sprachwahl und die hinzugekommene Flagge, wobei die aktuelle Sprache hervorgehoben wird. (Das sind allerdings Layout-Goodies, die man dann später beliebig per CSS steuern kann.)



[gelöscht durch Administrator]

[WebBird]

Was soll's, wo ich schon mal dabei bin...

Suchformular und Suchergebnisseite (wobei das Ergebnis nicht "veraltete" Module von Argos zeigt. )

[gelöscht durch Administrator]

[dbs]

na das macht schon einen guten.
plädiere dafür little screenshot gleich mit einzubauen, sonst zu trocken ohne bildchen.

klickbare sprachumschaltung für jedes addon? wenn es keine umstellung macht, denn einmal gewählte seitensprache macht das lesen der beschreibungen in anderen sprachen überflüssig, oder?

dbs