Verständnisproblem: OSD hoch/runter und +/-?

[daffy]

Ich hab da mal ein Problem. Dabei stelle ich mir eine Kanal-Liste der folgenden Form vor (gilt genau so auch für die Favoriten):

 

1) ARD

2) ZDF

3) ARTE

..

20) ntv

21) kika

 

Jetzt mache ich das OSD auf und sehe die ersten paar Einträge, dann "Down" und "Up". Rein intuitiv sehe ich meine Liste (oben) und denke: Na, "Down", ist doch klar, oder? Nix da - es ist "up". Und daffy kratzt sich am Kopf.

 

Nun gut, ich kann mir zusammenreimen, wieso ich "up" anwählen soll: Schließlich geht die Kanal-Nr nach oben. Aber wenn ich meine Liste sehe, dann denke ich nicht "hey, ich will runter in der Liste, also muß die Nr hoch, als drücke ich "up"". Ich denke "ich will runter, also gehts "down"".

 

Glücklicherweise kann man die Eingabe-Routinen entsprechend einstellen; bei mir sind z.B. "Favouries -> Station Plus" = "Cursor ABWÄRTS" sowie "Favouries -> Station Minus" = "Cursor AUFWÄRTS".

 

So. Und nun stehe ich vor dem Dilemma - was nun? Ich finde den Status Quo nicht so prickelnd. Bei "hoch" / "runter" in einer Liste denke ich "Taste hoch" / "Taste runter". Ich nehme nicht den Umweg "Eintrag -> Nummer -> Nummer anpassen".

 

In den seltenen Fällen, in denen ich über die Tastatur einen Kanal direkt anwähle, wähle ich den auch direkt über seine Nummer an - also "1" für ARD (in den Favoriten) etc.

 

Die Aktion "Kanal-Nr hoch/runter" kommt in meiner Denke überhaupt nicht vor - nur "vorheriger" und "nächster" Kanal auf der Liste.

 

Aus meiner Sicht sind sollte man daher die derzeitige Bedeutung von plus/minus umdrehen:

 

* Hoch/Plus = in der Liste hoch (und nicht Kanal-Nr hoch = Liste runter)

* Runter/minus = in der Liste runter (analog zu oben)

 

Das paßt mit meiner Denke zusammen.

 

Stehe ich mit diesem Verständnisproblem alleine auf weiter Flur?

[Griga]

Über diese Thematik gab es schon Diskussionen ohne Ende....

 

Bei Fensehern und DVB-Receivern bedeutet die Fernbedienungs-Taste "Pfeil oben" zur nächsten Kanalnummer weiterschalten, also in der (unsichtbaren) Liste nach unten. Viele Leute sind das so gewohnt und kriegen umgehend eine fundamentalistische Krise, falls es sich irgendwo anders verhält.

 

Auf dem PC bedeutet "Pfeil oben" dagegen, in einer Liste nach oben zu gehen, also zur vorherigen Kanalnummer. Auch das hat glühende Anhänger.

 

Besonders schlimm war es zu Zeiten, als die Favoriten-Toolbar-Buttons noch nach oben und unten wiesen. Grabe in den Sedimenten des Forums, und du wirst sehen... bis zu meinem Vorschlag, die Dreiecke nach links und rechts zeigen zu lassen. Seitdem ist zumindest in der Hinsicht Ruhe.

 

Im DVBViewer GE gibt es deshalb eine Option "OSD auf/ab vertauschen (außer für OSD-Menüs)". In den Menüs bedeutet also "Up" grundsätzlich "Selektion nach oben", bei nicht sichtbarem OSD kann man es sich für FB und Tastatur aussuchen. Das gilt übrigens auch für die Seiten-Weiterschaltung im Teletext - das gleiche Problem. Als Programmierer freut man sich über das prächtig gedeihende case... if... then... else... -Gestrüpp.

[daffy]

Über diese Thematik gab es schon Diskussionen ohne Ende.... 

 

Oh, cool!

 

Bei Fensehern und DVB-Receivern bedeutet die Fernbedienungs-Taste "Pfeil oben" zur nächsten Kanalnummer weiterschalten, also in der (unsichtbaren) Liste nach unten. Viele Leute sind das so gewohnt und kriegen umgehend eine fundamentalistische Krise, falls es sich irgendwo anders verhält.

 

Ah. Jetzt weiß ich, woher meine fundamentalistische Krise kommt! Ich kann mich nicht daran erinnern, jemals länger Zugang zu einem solchen Gerät gehabt zu haben! Ich habe z.B. noch nie einen Fernseher mein Eigentum genannt - dafür aber halt 'ne Pinnacle PCTV für den analogen Kabelempfang und die Skystar seit ein geraumer Zeit für DVB-S.

 

Als Programmierer freut man sich über das prächtig gedeihende case... if... then... else... -Gestrüpp. 

 

Ach wo. Das geht mit genau einem if/then. Man nehme

 

* ein konsistentes Konzept

(sprich: alle beteiligten verwenden "hoch" und "runter" gleich)

 

* man führe eine Abstraktion ein, die in Form von, sagen wir, function pointers zu genau dem Zeitpunkt zugewiesen wird, in dem sich ein menschliches Wesen für eine Philosophie entschieden hat

 

Der Code, der "hoch" gehen will, ruft dann einfach nur noch die Abstraktion namens "hoch" auf - und wenns dann runter geht - wenn kümmerts?

 

Damit ist es leider noch nicht so ganz getan, denn die Begriffe "erster", "letzter", "vorwärts blättern", "rückwärts blättern" sowie die Texte müßten auch noch heraus abstrahiert werden - letztlich ist das aber nur ein Singleton-Service, der Anforderungen auf direktionale Änderung verarbeitet. Macht ein wenig mehr Code, aber eine sehr saubere, sehr leistungsfähige, stark gekapselte Abstraktion - falls man das Feature denn anbieten möchte.

 

Gah.

 

Es ist spät. Sorry falls ich oben Müll schreibe.

[Griga]

Ach wo. Das geht mit genau einem if/then.

 

Die Kommandos/Konstanten acOSDUp/acOSDDown werden (nebst 125 weiteren acXXXX-Konstanten) aus folgenden Quellen

 

- Maus

- Tastatur -> benutzerdefinierte Zuweisungstabelle

- Fernbedienung -> benutzerdefinierte Zuweisungstabelle

- Kommandoparameter

- Plugins / Messages

 

einem zentralen Handler übergeben, der sie kontextabhängig anwendet auf

 

- OSD-Menünavigation

- OSD-Teletext Seitenwahl (*)

- OSD-Position (1 Min. vor/zurück bei Timeshift/Datei)

- DVD-Menünavigation

- Play/Pause bei Dateiwiedergabe

- Kanal plus/minus (*) (**)

- Favorit plus/minus (*) (**)

 

(*) Up/Down optional austauschbar

(**) Wirkung auf Kanalliste/Favoriten wählbar.

 

...weil es wegen Minimal-FBs notwendig ist, möglichst viele Funktionen mit möglichst wenigen Tasten zu erschlagen. Teilweise handelt es sich hier um Zustandsparameter, die sich gegenseitig ausschließen, teilweise können sie auch gleichzeitig auftreten, so dass eine Prioritätenregelung erforderlich ist.

 

Hinzu kommt, dass es für einige der obigen Situationen kontext-unabhängige Alternativen zu acOSDUp/acOSDDown gibt (z.B. acChannelMinus/acChannelPlus), um ein Maximum an Flexibilität zu gewährleisten. Letzendlich läuft das meiste über eine ActionList mit 104 Einträgen.

 

So in der GE, also vergleichsweise schlicht. Nun erklär noch mal etwas genauer, wie man das abstrahiert.

[Guest Lars_MQ]

Nun erklär noch mal etwas genauer, wie man das abstrahiert.

Ohja das würde mich auch interessieren, In der Pro sieht das ähnlich aus (mit ein paar command-parameter mehr -> siehe actions.ini).

[Guest Lars_MQ]

Jetzt mache ich das OSD auf und sehe die ersten paar Einträge, dann "Down" und "Up".

hmm, die sollten eigentlich mit group down / group up beschriftet sein, nur der text war zu lang.

 

Funktion: Im Channel oder Radio Modus wird damit zwischen den Gruppen geblättert, den gleichen effekt erhält man wenn man auf einer gruppenbeschriftung OSD-OK drückt. Im Favoritenmodus wurde deren Funktion vernachlässigt, hmm...

[daffy]

Nun erklär noch mal etwas genauer, wie man das abstrahiert. 

 

Aaaaaalsoooo... erst einmal die Warnung: Ich kenne den Code nicht. Damit sind natürlich sämtliche Nonsensicalitäten entschuldigt

 

With that being said:

 

Grundsätzlich hilft es, sämtliche Entscheidungen bis auf den allerletzten Drücker aufzuschieben. Wenn also acOSDUp/acOSDDown bereits sagen, was genau zu tun ist - a la "du mußt jetzt 5 Kanalnummern addieren", dann ist das ein wenig ungünstig.

 

Ich gehe also einmal davon aus, daß es folgendes Design gibt:

 

Es gibt einen Benutzer. Dieser Benutzer kommuniziert über einen beliebigen Interaktionskanal mit einem Stück Software. Der Interaktionskanal hat zwei Enden: Das Eingabegerät des Benutzers (IN) und die gewünschte Aktion des Nutzers (OUT).

 

IN ist hier z.B.

 

WM_INPUT

WM_CHAR

WM_LBUTTONDOWN

 

aber auch direkt

 

IN_PerformChannnelUp = WM_USER + 1234;

 

OUT ist dann die kontext-abhängige, gewünschte *Aktion* - z.B.

 

OUT_PerformChannnelUp

OUT_SwitchToFavouriteAtIndex_1

OUT_ToggleFullscreen

 

1. Problem: Kontextsensitivität.

 

Der Interaktionskanal braucht Zugriff auf relevanten Kontext um aus IN sinnvoll OUT synthetisieren zu können.

 

Lösung: Singleton "Context" das eine Kontext-Queue abbildet.

 

Jeder neue, separate Software-/Interaktionskontext wird vom Kontext selbst per

 

StartContext(ctxWasAuchImmer)

 

geöffnet. Es gibt eine Aktivität

 

DoneContext()

 

die den gerade aktiven Kontext abschließt und zum nächsthöheren Kontext zurückkehrt. DoneContext() kann durch eine "OK"-Aktion aber auch eine "Esc"-Aktion aufgerufen werden. Letztlich wird man hoffentlich irgendwann wieder dank Benutzerinteraktion bei einem leeren Kontext ankommen <g>.

 

Es gibt aber auch eine zusätzliche Aktivität

 

ClearContexts()

 

welche auch wieder den Kontext löscht (Panik-Taste drücken <g>)

 

Es gibt einen endliche Anzahl an Kontext-Zuständen. Ein Kontext-Zustand ist keine Konfigurationsoption, sondern effektiv der Zustand einer simplen state machine, gestartet durch eine vorhergehende Nutzer-Interaktion.

 

Kommt nun ein IN-event, dann wird zuerst der aktuelle Kontext daraufhin untersucht, ob er etwas mit dem IN-event anfangen kann. (Möglicherweise kann man dann noch die gesamte Kontext-Queue rückwärts durchsuchen - devil is in the detail, err, design <g>). Sollte das Context-Singleton eine (kontext-spezifische) OUT-Aktion liefern können sind wir fertig - ansonsten wird kontextfrei nach einer OUT-Aktion gesucht.

 

[Hmm. Wo ist der Unterschied zwischen "kein Kontext" und der invariant condition "context queue length == 1" - sprich, es gibt immer einen Basis-Kontext? Ah. Details, Details. Was auch immer genehm und bequem ist... Hm. Wahrscheinlich ist der Basis-Kontext sinnvoller - a la TV / Radio / DVD / Musik]

 

[Amüsant: Mir fällt gerade auf, daß es mit diesem Design prinzipiell möglich ist, im OSD bei gleichem Input - z.B. Taste "OK" - andere Aktionen auszuführen als anderswo. Oder die Zifferntasten im OSD-Teletext. Hmm. Auch Konfiguration geht einfach: Man lasse den Nutzer einen Basis-Kontext definieren - und erlaube ihm dann, im Mega-Kontext Teletext / OSD / DVD-Playback etc overrides vorzunehmen. Das müßte sogar benutzerfreundlich gehen.]

 

So. Nun haben wir einen OUT-Wert. Phew. Nehmen wir der Einfachheit halber die bereits oben definierten

 

OUT_ToggleFullscreen

OUT_PerformChannnelUp

 

Nun routen wir einfach einmal kurz die OUT-Aktion zum Empfänger:

 

case OutAktion of

 

OUT_ToggleFullscreen:

PerformFullScreenToogle();

 

OUT_PerformChannnelUp:

ChannelSwitcher.PerformUp();

// Kontext stellt sicher, daß ChannelSwitcher sinnvoll ist

 

2. Problem: "Channel Up ist Kanal-Nummer Down" = mein Problem ;-)

 

Was ist ChannelSwitcher?

 

Entweder ist ChannelSwitcher direkt eine Implementierung, a la

 

procedure ChannelSwitcher.PerformUp()

begin

 

if SwapUpDownSemantics then

begin

InternalPerformDown();

Exit;

end;

 

InternalPerformUp();

end;

 

wobei SwapUpDownSemantics eine Konfigurationsoption ist. Alternativ - und das ist jetzt im wesentlichen identisch, ist ChannelSwitcher ein globaler record

 

TChannelSwitcher = record

PerformUp: procedure;

PerformDown: procedure;

end;

 

oder eine ähnliche Indirektion - z.B. ein "IChannelSwitcher = interface".

 

Am Ende dieses Monologs muß ich realisieren, daß dieses Design

 

a) wohl ziemlich leistungsfähig ist

recht aufwendig in eine existierende Implementierung

zu integrieren sein dürfte, weil es halt die gesamte

Benutzerinteraktion abdeckt

 

Oh - caveat emptor: Ich hab obiges einfach mal so kurz . Der Rote Faden dürfte daher an einigen Stellen ein paar Windungen und Knoten haben. Vielleicht hilfts trotzdem. Irgendwie.

[Guest Lars_MQ]

Man lasse den Nutzer einen Basis-Kontext definieren - und erlaube ihm dann, im Mega-Kontext Teletext / OSD / DVD-Playback etc overrides vorzunehmen. Das müßte sogar benutzerfreundlich gehen.]

Oh ja, soweit war ich schon -> suche myWinlirc plugin. Da der "Mega-Kontext" sich letztendlich auf OSD-Seitenebene*DVBViewerzustände herunterbrach (Oh wie schön wäre programmieren ohne Userwünsche ), kam dabei eine Konfiguration heraus, die ich selber nachher nicht mehr überblickt habe.

 

Das Singleton (aka Actionmanager) wurde recht frühzeitig wieder verworfen, da zwar sehr flexibel, aber unkonfigurierbar (zumindest für den 08/15 User) und durch eine sehr abgespeckte Version ersetzt.

 

Bisher habe ich den heiligen gral der userinteraction auch noch nicht gefunden. Wenn es ihn denn überhaupt gibt...

[Griga]

Vielleicht hilfts trotzdem.

 

Anregend, und schön zu lesen auf jeden Fall. Manchmal träume ich von blitzsauberen, höchst eleganten Datenstrukturen und Abläufen... um dann hauptsächlich von zwei Faktoren in die Realität zurückgeholt zu werden: Anwender und existierendes DVB.

 

Unglücklicherweise ist es Ziel des DVBViewers, beide zusammenzubringen, und beide sträuben sich auf ihre Weise dagegen, abstrahiert zu werden.

 

Zum Beispiel StartContext(ctxBroadcastProvidesSubtitles) - etwas in der Art hätte ich letztlich gerne realisiert. Teletextseiten enthalten ein Flag, das Untertitel als Inhalt signalisiert. Unsere Öffentlich-Rechtlichen verwenden es im Hinblick auf Hörbehinderte gemäß den Spezifikationen.

 

Die RTL-Gruppe sendet dagegen überhaupt keine Teletext-Untertitel - auf Anfrage von Hörbehinderten hieß es, die Sendekapazitäten wären bereits ausgelastet - markiert aber als Über-Kompensation sämtliche Seiten mit NewsFlash-Einblendungen als Untertitel. Dafür ist zwar eigentlich ein anderes Flag zuständig, aber was soll's?

 

Ich habe aus solchen Anlässen schon erboste Mails abgeschickt: "Hey, warum richtet ihr euch nicht nach den Spezifikationen und macht es wie die anderen auch? In ETSI EN 300 706, Abschnitt 9.3.1.3, Control Bits, steht klar und deutlich...". Als Anwort kommt dann ein Standardschreiben "Vielen Dank für Ihr Interesse an unserem Programm. Falls Sie weitere Fragen haben...".

 

So sieht's aus. Vielen Dank für Ihren netten Textbaustein...

[daffy]

Ich muß dieses Thema nochmals aufwärmen - sorry.

 

Mit Verlaub, ich habe ernsthafte Schwierigkeiten den DVBViewer intuitiv über die Tastatur (oder Fernbedienung) zu steuern.

 

Nur mal ein Beispiel:

 

* gehe nach "Standardansicht für Fernseher"

* "Page Up" == "Nächster Favorit"

* "Cursor up" == "Nächster Kanal"

 

Ok, ist halt so konfiguriert.

 

* gehe nach "htpcHome"

* "Page Up" == "Nächster Favorit" funktioniert weiterhin

* "Cursor up" == Selektion hoch runter

 

Argh. Soviel zum Thema Konsistenz.

 

Es könnte vielleicht helfen, Modi oder Kontexte zu definieren, in denen "Aktionen" etwas verursachen. Momentan ist ja anscheinend alles aktiv, es sei denn, irgendetwas anderes erkennt die Aktion eher / schneller.

 

Ich glaube, es ist wichtig, daß dem Nutzer zu jedem Zeitpunkt klar ist, was "geht". Im OSD-Modus beinhaltet das, möglichst viele Aktionen *auszublenden* und alle Möglichkeiten der Interaktion per Eingabegerät (Tastatur, Fernbedienung) anzuzeigen.

 

Ich versuche übrigens gerade die HTPC-Möglichkeiten auszuloten - daher meine Verwirrung ;-)

[Guest Lars_MQ]

* gehe nach "Standardansicht für Fernseher"

* "Page Up" == "Nächster Favorit"

* "Cursor up" == "Nächster Kanal"

Tatsächlich liegt ein missverständniss vor. Cursor Up ist OSD-Up. nur auf rücksicht auf verkrüppelte FBs (Ohne Ch+/Ch-) wird das dort so interpretiert (ähnliches passiert mit volume +/-). Um Deinen Vergleich passend zu machen, musst Du ch+/ch- ebenso wie die Favoritenbefehle auf tasten legen.

 

Die Diskussion über eine Kontextsensitive Belegung kommt alle 1/4 jahr einmal hoch, allerdings war bisher noch niemand in der lage ein Konzept zu präsentieren, das ebenso flexibel wie universell und dann noch einfach zu konfigurieren ist.