Nativer SoD Client

[bademeister]

Hallo alle zusammen,

erstmal großes Lob an das 4.0.7 Update und den nativen SoD Client.
Allerdings hat dieser bei unseren User nun schon vermehrt zu erhöhten Nachfragen geführt, da die Bedienung im Vergleich zur vorherigen WebGUI scheinbar nicht sehr intuitiv ist.
Für mich, der den configed regelmäßig im Einsatz hat, erschließt sich die Nutzung ohne weiteres. Für 08/15 User ist das eher etwas schwierig.

Sind hier in Zukunft noch Verbesserungen an der Oberfläche geplant? Ggf. auch mit zusätzlicher Eingabe bestimmter ProductPropertys?

Viele Grüße,
Felix

[n.wenselowski]

Hi Felix,

erstmal großes Lob an das 4.0.7 Update und den nativen SoD Client.

Danke

Allerdings hat dieser bei unseren User nun schon vermehrt zu erhöhten Nachfragen geführt, da die Bedienung im Vergleich zur vorherigen WebGUI scheinbar nicht sehr intuitiv ist.
Für mich, der den configed regelmäßig im Einsatz hat, erschließt sich die Nutzung ohne weiteres. Für 08/15 User ist das eher etwas schwierig.

Wir haben vermutlich auch einen größeren Tunnelblick auf die Sache, wenn wir ständig damit arbeiten. Deshalb bin ich sehr interessiert an Blicken von Usern, die nicht so tief drin stecken.
Was können wir denn besser machen oder was ist schwierig für die Anwender draußen?

Sind hier in Zukunft noch Verbesserungen an der Oberfläche geplant? Ggf. auch mit zusätzlicher Eingabe bestimmter ProductPropertys?

Es sind auf jeden Fall noch Verbesserungen geplant!
Was genau meinst du mit Eingabe von Properties?


Gruß

Niko

[bademeister]

Hi Niko,

Wir haben vermutlich auch einen größeren Tunnelblick auf die Sache, wenn wir ständig damit arbeiten. Deshalb bin ich sehr interessiert an Blicken von Usern, die nicht so tief drin stecken.
Was können wir denn besser machen oder was ist schwierig für die Anwender draußen?

es ist immer viel einfach nur Kritik zu üben. Konstruktive Vorschläge zu geben fehlt dann wieder jedem schwer.
Ich versuchs trotzdem mal:
Ich denke, dass die Komplexität durch die Tabelle kommt. Bei der nicht klar ersichtlich ist, was ein actionRequest ist bzw. was das für den User bedeutet. Ich denke von der Bedienung her ist es für den User einfach bei einem Produkt direkt einen Button/Checkbox zu haben: "Install" oder "Uninstall".
Mit globalen, direkt sichtbaren Buttons "Sofort ausführen" oder "Beim nächsten Client aufrufen - normalerweise nach Neustart" sollte dann schonmal einiges getan sein. Das ist allerdings bisher nur meine Meinung. Vielleicht kann man hier einen zeitlich begrenzten Thread zu aufmachen, in dem man mit der breiten User-Masse diskutiert und die sinnvollsten Vorschläge ableitet.

Es sind auf jeden Fall noch Verbesserungen geplant!
Was genau meinst du mit Eingabe von Properties?

Wir nutzen ProductProperties im configed z.B. um system_architecture "x64", "x86" oder "auto" zu setzen. Andere beispiele sind das "desktopicon" in eurem Chrome vom Update-Abo.
Dies Properties kann der User via SoD nicht setzen. Jetzt ist es natürlich nicht sinnvoll, ihm alle zu geben, weil damit schon sehr systemrelevante Dinge durchgeführt werden können. Allerdings wäre es vielleicht interessant etwas wie ein [ProductPropertyPublic] im control File anzugeben, welches dann an den SoD Client weitergereicht wird.
Im Vergleich zur GUI wird dieser Eingriff jedoch wohl etwas schwerwiegender und daher auch wirklich nur ein Vorschlag.

Ich hoffe das hilft dir soweit weiter. Bei Fragen einfach melden.
Viele Grüße,
Felix

[dark alex]

Zum Interface:

Code: Alles auswählen

Produkt1   [Installieren] [Einmal ausführen] [Entfernen] [Nichts ändern]
Produkt2   [Installieren] [Einmal ausführen] [Entfernen] [Nichts ändern]

So in der Art... Und es sollten Radio-Buttons sein...
Am Ende dann zwei Buttons "Sofort ausführen" und "Beim nächsten Neustart ausführen"
Allerdings... Hat schon mal jemand bedacht, dass manche Produkte evtl gar nicht "on_demand" ausgeführt werden können/sollten? Weil z.b. kein Browser laufen darf o.ä.

[n.wenselowski]

Hi Felix & dark alex,

vielen Dank für die Rückmeldungen! Ich finde das hört sich sinnvoll an und ich reiche das gerne weiter

Es sind auf jeden Fall noch Verbesserungen geplant!
Was genau meinst du mit Eingabe von Properties?

Wir nutzen ProductProperties im configed z.B. um system_architecture "x64", "x86" oder "auto" zu setzen. Andere beispiele sind das "desktopicon" in eurem Chrome vom Update-Abo.
Dies Properties kann der User via SoD nicht setzen. Jetzt ist es natürlich nicht sinnvoll, ihm alle zu geben, weil damit schon sehr systemrelevante Dinge durchgeführt werden können. Allerdings wäre es vielleicht interessant etwas wie ein [ProductPropertyPublic] im control File anzugeben, welches dann an den SoD Client weitergereicht wird.
Im Vergleich zur GUI wird dieser Eingriff jedoch wohl etwas schwerwiegender und daher auch wirklich nur ein Vorschlag.

Das ist tatsächlich wieder ein größerer Eingriff, der - wenn man es ordentlich machen will - auch eine Änderung der Datenstruktur beinhaltet. Wir wollen mit dem nächsten großen Release einige Sachen ändern. Ich würde sowas am besten in einem gesonderten Thread diskutieren (gabs nicht bereits einen dazu?).

Allerdings... Hat schon mal jemand bedacht, dass manche Produkte evtl gar nicht "on_demand" ausgeführt werden können/sollten? Weil z.b. kein Browser laufen darf o.ä.

Das ist schwer zu lösen, weil man das dem Produkt ja erstmal nicht ansieht. Aktuell muss dazu der Paketbetreuer sein Script entsprechend bauen, dass es auf die Besonderheiten reagiert.


Viele Grüße

Niko

[dark alex]

wie wärs mit einer neuen Eigenschaft im control file a la
"blockedEvents" die dann eine kommaseparierte Liste enthält?
Falls Eigenschaft nicht da, standard ""

[ueluekmen]

Hi,

"blockedEvents" die dann eine kommaseparierte Liste enthält?

du kannst das nicht im Produkt hinterlegen, du kannst das aber mit dem neuen Client-Agenten von 4.0.7 über die Eventkonfiguration steuern:

http://download.uib.de/opsi4.0/doc/html ... ual-client
Kapitel:
Steuerung der Produkte die ausgeführt werden pro Event

An der Stelle würde sich die Varinate mit exclude anbieten.

[dark alex]

Ünicht im Produkt hinterlegen, du kannst das aber mit dem neuen Client-Agenten von 4.0.7 über die Eventkonfiguration steuern

Warum einfach, wenn's auch umständlich geht

D.h. als PAketierer muss ich jedes Mal wenn ich ein neues SoD-Paket erstelle auch den Client anfassen bzw dessen Config.
Also in meinen Augen macht so ein Eventfilter im Paket mehr Sinn als in der Clientconfig. Wobei ich auch hier eine Daseinsberechtigung sehe. Evtl weiß man z.b. dass auf Client X die Software aus Paket Y immer läuft und auf keinen Fall beendet werden darf, will aber trotzdem andere Updates on_demand einspielen o.ä.

[bademeister]

Hallo,

mich würde mal interessieren, ob folgendes Verhalten nur bei uns auftritt oder auch andere User davon berichten können:

Der native SoD ist bei uns vergleichweise "träge". Das äußert sich insbesondere dadurch, dass die Liste verfügbarer Produkte relativ lange braucht, bis sie geladen ist. Nach Auswahl eines "setup" actionRequests und dem Drücken von "Aktionen speichern" braucht der SoD eine ganze Weile (was nicht direkt ersichtlich ist), um dies an das Depot zu kommunizieren. Drückt man innerhalb dieser langen Zeitspanne irgendwo (User sind ja grundsätzlich ungeduldig), bekommt man eine "Keine Rückmeldung" Information und die gewählten actionRequests werden nicht garantiert übertragen. Insbesondere fehlt im Anschluss die Frage nach dem Ausführungszeitpunkt (Beim nächsten Systemstart oder sofort).

Ist dies bekannt und sind an dem Client in diesem Bereich sowie auch an der Usability Updates geplant?

Viele Grüße,
Felix

[n.wenselowski]

Hallo Felix,

Was ist denn eine lange Liste verfügbarer Produkte? Wirf uns doch mal eine grobe Zahl zu, das macht das Nachstellen einfacher.

Der neue Kiosk-Clients wird weiterhin Updates erhalten, nur einen genauen Zeitpunkt für neue Versionen kann ich nicht nennen.


Viele Grüße

Niko