Verletzung der Plugin-Schnittstelle
Verletzung der Plugin-Schnittstelle
EDIT (Til): Diese Diskussion wurde vom Thread Announce: LocalImdb 0.1b hierher verschoben.
Du solltest einfach beim 1. starten auf die Icons hinweisen. Die Icons einfach anschalten is doof. Die Benutzer müßen die Reihenfolge der Plugins auch noch einstellen. Wenn du einfach "magisch" Icons anmachst, weiß ja keiner wo man die aus macht und die Reihenfolge ändert...
Du solltest einfach beim 1. starten auf die Icons hinweisen. Die Icons einfach anschalten is doof. Die Benutzer müßen die Reihenfolge der Plugins auch noch einstellen. Wenn du einfach "magisch" Icons anmachst, weiß ja keiner wo man die aus macht und die Reihenfolge ändert...
Ok, mach' ich nicht. Ich hoffe ein "Einstellungen..." Button in der Tagesübersicht erklärt die Lage demnächst auch ohne zusätzliche Hinweise:bodo hat geschrieben:Du solltest einfach beim 1. starten auf die Icons hinweisen. Die Icons einfach anschalten is doof. Die Benutzer müßen die Reihenfolge der Plugins auch noch einstellen. Wenn du einfach "magisch" Icons anmachst, weiß ja keiner wo man die aus macht und die Reihenfolge ändert...
Thanks to ImageShack for Free Image Hosting
Muss da aber heut Abend noch paar Dinge korrigieren ...
Nein, hier halte ich deinen Standpunkt für falsch.bodo hat geschrieben:Doch, für den User schon, er kann an 2 Stellen nun die Icons ändern...das is nich gut
Es gibt bei Usabilitybugs zwei Glaubensrichtungen. Die einen denken der Endanwender ist doof wenn er die Gedanken der Programmierer nicht lesen kann. Die anderen wissen, dass das GUI-Design doof ist, wenn die Endanwender es nicht sofort begreifen.
Wenn ich ein "sorry. habs übersehen" lese ist das für mich ein Schlag ins Gesicht, weil ICH zu blöd war mich in einen Endanwender hineinzudenken. Ein Freund der LocalImdb installiert hat, hat nichtmal mitbekommen, das er Einstellungen bei dem Plugin machen kann. Das ist aber irgendwie verständlich, denn es gibt keinerlei visuelle Verbindung.
Die Benutzerführung wird nicht besser wenn du den TV-Browser mit Dialogen beglückst die erklären was man tun muss wenn man irgendwann XYZ tun will. Wenn du beim Programmstart "Tip of the day"s machen willst, nur zu. Das ist aber kein Ersatz für eine vernünftige Benutzerführung.
Kleine Buchempfehlung: The Design of Everyday Things
Bitte halte dich an die Plugin-Schnittstelle und greife nicht auf Klassen im tvbrowser-Package zu. Wir können sonst nicht garantieren, in welchen Versionen dein Plugin läuft.
Die Plugin-Schnittstelle ist dazu da, die Abhängigkeiten auf das Nötigste zu minimieren. Anderenfalls ist das nicht mehr kontrollierbar.
Es ist ein grober Usability-Fehler, wenn die selbe Funktion an mehreren Stellen in der Benutzeroberfläche angeboten wird, das führt nur zu Verwirrung. Hinweise an allen Ecken und Enden sind natürlich auch blöd.
Wir können die Icon-Einstellung ja so ändern, wie wir es auch bei den Plugins gemacht haben: Standardmäßig sind alle eingeschalten. D.h. ein Benutzer muss die Icons explizit ausschalten. Dann kann der Benutzer in der neuen Version einfach dein Plugin ins plugins-Verzeichnis schmeissen und es wird automatisch aktiviert, inkl. Icons.
Die Plugin-Schnittstelle ist dazu da, die Abhängigkeiten auf das Nötigste zu minimieren. Anderenfalls ist das nicht mehr kontrollierbar.
Es ist ein grober Usability-Fehler, wenn die selbe Funktion an mehreren Stellen in der Benutzeroberfläche angeboten wird, das führt nur zu Verwirrung. Hinweise an allen Ecken und Enden sind natürlich auch blöd.
Wir können die Icon-Einstellung ja so ändern, wie wir es auch bei den Plugins gemacht haben: Standardmäßig sind alle eingeschalten. D.h. ein Benutzer muss die Icons explizit ausschalten. Dann kann der Benutzer in der neuen Version einfach dein Plugin ins plugins-Verzeichnis schmeissen und es wird automatisch aktiviert, inkl. Icons.
Hmmm ...Til hat geschrieben:Bitte halte dich an die Plugin-Schnittstelle und greife nicht auf Klassen im tvbrowser-Package zu.
Das QuickScroll-Plugin wäre ein Ding der Unmöglichkeit. Bodo meinte (im Scherz?) ich solle TV-Browser branchen wenn ich die Funktionalität wolle. Das wäre aber doch sicher schlechter für alle.
Wie erfährt man ohne Settings von wann bis wann ein Tag läuft?
Wie informiere ich ProgramChangeListener, dass sich meine Icons verändert haben?
Wie deaktiviert sich ein Plugin bei 1.0.1 ohne internes Wissen? Meine Grusellösung bei QuickScroll ... :
Code: Alles auswählen
public final Properties storeSettings() {
if (!isNewActivationSupported()) {
StackTraceElement[] ste = new Throwable().getStackTrace();
if (ste.length > 2 && "deactivatePlugin".equals(ste[2].getMethodName())) onDeactivation();
}
return getSettings();
}
Dann hätte LocalImdb ja dieselben "Rechte" wie die mitgelieferten Plugins. Bleibt aber Bodos berechtigter Einwand: "Wenn du einfach magisch Icons anmachst, weiß ja keiner wo man die aus macht und die Reihenfolge ändert."Til hat geschrieben:Wir können die Icon-Einstellung ja so ändern, wie wir es auch bei den Plugins gemacht haben: Standardmäßig sind alle eingeschalten.
Wie wäre es wenn ihr mich einfach mal machen lasst, und nach paar Monaten "Erfahrung sammeln" reden wir darüber ob Plugins wie bei Such-Panels auch bei PluginIcon-Panels einen offiziellen Funktionsaufruf kriegen.
Es wäre schon sehr arm, wenn man in einem OpenSource™ Projekt die Features beschränkt, nur weil etwas nicht von den Schöpfern vorgesehen ist.
...
Ich weiss eure Ratschläge immer zu schätzen. Seid mir nicht böse, wenn ich mich nicht immer an sie halte.
Wir wollen dich nicht einschränken. Es geht nur darum, die Software wartbar zu halten. Und dazu sind Schnittstellen nötig. Mit einer Schnittstelle kann man genau festlegen, wie ein Teil auf einen anderen zugreift. D.h. man kann beide Teile ändern wie man will, solange die Schnittstelle gleich bleibt, gibt es keine Nebeneffekte.
Wenn die Plugin-Schnittstelle nicht ausreicht, dann muss sie entsprechend erweitert werden. Da waren wir bisher immer sehr entgegenkommend. Aber bitte arbeite nicht an der Schnittstelle vorbei. Alles was dabei herauskommt ist innerhalb kürzester Zeit ein riesen Haufen von undurchschaubaren Abhängigkeiten.
Wenn man als User nicht erkennt, wo man was einstellen muss, dann müssen wir den Einstellungs-Dialog verbessern. Aber es kann nicht die Lösung sein, dass man die Icon-Reihenfolge bei allen Plugins ändern kann, die Icons anbieten. Da blickt ja keiner mehr durch...
Also bitte nimm die Sache hier nicht persönlich. Es geht hier nur darum eine modulare Software modular zu halten.
Wenn die Plugin-Schnittstelle nicht ausreicht, dann muss sie entsprechend erweitert werden. Da waren wir bisher immer sehr entgegenkommend. Aber bitte arbeite nicht an der Schnittstelle vorbei. Alles was dabei herauskommt ist innerhalb kürzester Zeit ein riesen Haufen von undurchschaubaren Abhängigkeiten.
Wenn man als User nicht erkennt, wo man was einstellen muss, dann müssen wir den Einstellungs-Dialog verbessern. Aber es kann nicht die Lösung sein, dass man die Icon-Reihenfolge bei allen Plugins ändern kann, die Icons anbieten. Da blickt ja keiner mehr durch...
Also bitte nimm die Sache hier nicht persönlich. Es geht hier nur darum eine modulare Software modular zu halten.
-
- Gold Member
- Beiträge: 236
- Registriert: 29 Dez 2004, 10:52
- Wohnort: Vichten/Luxemburg
- Kontaktdaten:
Von dem Angebot will ich doch gleich mal Gebrauch machen:Til hat geschrieben:Wenn die Plugin-Schnittstelle nicht ausreicht, dann muss sie entsprechend erweitert werden. Da waren wir bisher immer sehr entgegenkommend.
Könnt ihr dem Interface devplugin.Program eine Möglichkeit mitgeben zusätzliche Meta-Daten zu speichern ? So in der Art:
Code: Alles auswählen
program.addMetaTag (String pluginID, String tagID, Object O)
Code: Alles auswählen
Object program.getMetaTag (String pluginID, String tagID)
Sinn der Sache: ich muss für mein Plugin bodos Bewertungen auslesen. Im Moment läuft da eine Bilderkennung über "getProgramTableIcons(Program program)". Es wäre schon einfacherer und zuverlässiger wenn da z.b. ein int[] oder ein Bean zur Verfügung stehen würde. Ähnliches gilt für das NewsFeed-Plugin, localIMDB, Erinnerungen (wie lange im Vorraus ?),...
Alternative 1: Macht es möglich eigene "ProgramFieldType"-Instanzen zu erzeugen und an ein Program dranzuhängen.
Alternative 2: Ein "getMetaData(Program p)" in devplugin.Plugin/PluginProxy.
Die Objecte sollten sich natürlich nicht von Plugin-Version zu Version ändern sondern mehr oder weniger gleich bleiben. Deshalb würde ich Beans bevorzugen. Aber eine einfache Hashtable als MetaTag würde das Problem Datenübergabe schon lösen.
(Wenn das im cvs schon drin ist: sorry, ich nehm alles zurück. Bin nicht auf dem laufenden was 1.1 angeht...)
@pck: wenn du an der Plugin-Schnittstelle vorbei arbeitest, dann können wir dir nicht garantieren das dein Plugin in der nächsten Version läuft. Das heißt du hast erhöhten Pflege-Aufwand. Willst du dir das wirklich aufhalsen?
Und wenn ein Autofahrer sagt das er den Blinker nich findet, baut der Hersteller doch nich noch einen 2. Knopf ein der auch noch den Blinker betätigt, oder ? Dann positioniert er den Blinker anders.
Wenn also die Stelle in den Einstellungen nich gefunden wird, müssen wir da was ändern.
Die Tip-Of-The-Day Geschichten liest eh keine Sau. Man muß es so machen, das jeder direkt versteht was sache ist. Ohne Suchen/Nachdenken. Und das einheitlich. Wenn du nämlich jetzt in deinem Plugin die Icon-Geschichten einbaust und im TVBewerter die nicht drin sind, wirste auch viele User vor den Kopf stoßen...die werden sich fragen was das soll...
Und wenn ein Autofahrer sagt das er den Blinker nich findet, baut der Hersteller doch nich noch einen 2. Knopf ein der auch noch den Blinker betätigt, oder ? Dann positioniert er den Blinker anders.
Wenn also die Stelle in den Einstellungen nich gefunden wird, müssen wir da was ändern.
Die Tip-Of-The-Day Geschichten liest eh keine Sau. Man muß es so machen, das jeder direkt versteht was sache ist. Ohne Suchen/Nachdenken. Und das einheitlich. Wenn du nämlich jetzt in deinem Plugin die Icon-Geschichten einbaust und im TVBewerter die nicht drin sind, wirste auch viele User vor den Kopf stoßen...die werden sich fragen was das soll...
Wegen der Meta-Daten-Geschichte: Ich kapier noch nicht ganz, was genau du machen willst.
Du willst zu einem Program weitere Daten speichern. Richtig? Was für Daten sind das? Wer setzt die? Wer liest sie?
Was jetzt schon geht ist, dass du neu hereinkommende Programs modifizierst. Das macht z.B. das Showview-Plugin. Siehe Plugin.handleTvDataAdded(ChannelDayProgram)
Allerdings gehen da nur die vordefinierten ProgramFields. Wahrscheinlich reicht das nicht für das, was du vor hast.
Aber bitte erklär mir erst, was du machen willst, bevor wir das Wie diskutieren...
Du willst zu einem Program weitere Daten speichern. Richtig? Was für Daten sind das? Wer setzt die? Wer liest sie?
Was jetzt schon geht ist, dass du neu hereinkommende Programs modifizierst. Das macht z.B. das Showview-Plugin. Siehe Plugin.handleTvDataAdded(ChannelDayProgram)
Allerdings gehen da nur die vordefinierten ProgramFields. Wahrscheinlich reicht das nicht für das, was du vor hast.
Aber bitte erklär mir erst, was du machen willst, bevor wir das Wie diskutieren...
-
- Gold Member
- Beiträge: 236
- Registriert: 29 Dez 2004, 10:52
- Wohnort: Vichten/Luxemburg
- Kontaktdaten:
Ich will generische Zusatzdaten einbaubar machen. Beispiele:
tvRater könnte die Bewertung einer Sendung speichern.
NeedFeed könnte den FeedText ablegen.
Reminder könnte ablegen um wieviel Uhr erinnert werden soll.
localIMDB könnte die Bewertung aus IMDB ablegen.
Alle diese Informationen können andere Plugins weiterverwenden. Z.B. zum Export auf Handies, Kalender-Export, Zusatzanzeige in Programminfo, CRM114-plugin,...
Als Vorteil seh ich die Unabhängigkeit von der internen implementierung des Plugin. Da hätte man eine offizelle Schnittstelle zu den Daten der Plugins. Wenn das ganze als Bean gemacht wird muss da quasi nie geändert werden.
OK, nicht jeder Plugin-Autor wird seine Daten rausrücken wollen, aber das sehen wir dann später.
tvRater könnte die Bewertung einer Sendung speichern.
NeedFeed könnte den FeedText ablegen.
Reminder könnte ablegen um wieviel Uhr erinnert werden soll.
localIMDB könnte die Bewertung aus IMDB ablegen.
Alle diese Informationen können andere Plugins weiterverwenden. Z.B. zum Export auf Handies, Kalender-Export, Zusatzanzeige in Programminfo, CRM114-plugin,...
Als Vorteil seh ich die Unabhängigkeit von der internen implementierung des Plugin. Da hätte man eine offizelle Schnittstelle zu den Daten der Plugins. Wenn das ganze als Bean gemacht wird muss da quasi nie geändert werden.
OK, nicht jeder Plugin-Autor wird seine Daten rausrücken wollen, aber das sehen wir dann später.
Aber nich jeder will ein Bean programmieren....
wie wäre es mit einer HashMap? Jedes Plugin kann in die HashMap Daten reinschieben und auch wieder lesen...müßte doch reichen, oder?
Man müßte nur ein System für die Keys haben, nich das die sich überschneiden...
So z.b.:
program.addMeta("TVRater.ratingGlobal", new Integer(4));
program.getAvailableMetas() würde die Keys rausholen und mit
program.getMeta("TVRater.ratingGlobal") würde man die globalen Ratings bekommen
Nachtrag: hab gerade gelesen, das du auch eine HashMap vorgeschlagen hast
wie wäre es mit einer HashMap? Jedes Plugin kann in die HashMap Daten reinschieben und auch wieder lesen...müßte doch reichen, oder?
Man müßte nur ein System für die Keys haben, nich das die sich überschneiden...
So z.b.:
program.addMeta("TVRater.ratingGlobal", new Integer(4));
program.getAvailableMetas() würde die Keys rausholen und mit
program.getMeta("TVRater.ratingGlobal") würde man die globalen Ratings bekommen
Nachtrag: hab gerade gelesen, das du auch eine HashMap vorgeschlagen hast
-
- Gold Member
- Beiträge: 236
- Registriert: 29 Dez 2004, 10:52
- Wohnort: Vichten/Luxemburg
- Kontaktdaten:
naja:bodo hat geschrieben:Aber nich jeder will ein Bean programmieren....
Code: Alles auswählen
public class bean{
public int getGlobalRating(){
return ...
}
public int getUserRating(){
return ...
}
public int getUserFunRating(){
return ...
}
public int getUserSpannungRating(){
return ...
}
....
}
Ein String in der Art "<PluginName> + <Metatag-version> + <Metatag-teil>" ? Klar, gerne.bodo hat geschrieben:Man müßte nur ein System für die Keys haben, nich das die sich überschneiden...