Darstellung von Boolean-Variablen in den neuen Apps

Prima, dass auch die mobilen Apps weiterenwickelt werden.

An der aktuellen Beta gefällt mir jedoch nicht, dass für Variablen vom Typ Boolean nicht mehr die Assoziationen sondern nur noch eine Checkbox angezeigt wird.

Dies kann unter Umständen zu Fehlinterpretationen führen. Zum Beispiel bedeutet bei der Keymatic Status „true“, dass die Tür nicht abgeschlossen ist. In der Mobilen App wird jedoch eine „abgehakte“ Checkbox angezeigt, was in aller Regel als „alles in Ordnung“ interpretiert wird. Eine aufgeschlossene Tür empfinde ich jedoch nicht als in Ordnung.

Sicher kann man den Status mit einer Hilfsvariablen invertieren, jedoch hat man dann nicht nur eine Statusvariable sondern zwei zu berücksichtigen. Eine für die Mobile App und eine für das „normale“ Webfront, das ja wie bisher die richtigen Assoziationen anzeigt. Oder man muss alles auf die neue, invertierte Hilfsvariable umstricken. Aber warum sollte man dies tun? Was ist der große Vorteil der Checkbox gegenüber den Assoziationen?

Außerdem kann eine Booleanvariable ja alle möglichen Zustände wiederspiegeln, ob man diesen unterschiedlichen Bedeutungen mit einer Checkbox gerecht werden kann?

Lange Rede kurzer Sinn, ich wünsche mir die Darstellung der Assoziationen zurück.

Gruß
Ralla

Da auf meinen Post noch niemand geantwortet hat, versuche ich mein Problem mal anschaulicher darzustellen.

Ich halte, wie gesagt, die Darstellung von Boolean-Variablen in der aktuellen Beta der Mobile App für sehr unglücklich. Der gesetzte bzw. nicht gesetzte Haken in der Checkbox kann schnell falsch interpretiert werden.

Beispiel Homematic Fensterkontakt und Keymatic an unserer Haustür.
Darstellung in der „alten“ App.


Darstellung in der aktuellen Beta.

Bin ich tatsächlich der einzige, der erwartet, dass eine geschlossene Tür mit einer abgehakten Checkbox und ein nicht verriegeltes Schloss mit einer offenen Checkbox dargestellt wird?

Wie gesagt, ich halte diese Darstellung für sehr fehleranfällig. Ich bin schon auf die Diskussion gespannt, die entsteht, wenn der erste in Abwesenheit seine Haustür remote öffnet, weil er den Status der Checkbox falsch interpretiert hat.

Gruß
Ralla

Das mit der Darstellung der Boolean-Variablen scheint Absicht zu sein.

Darüber sollte man vielleicht nochmal nachdenken.

Ich halte es für sehr schlimm, ja sogar gefährlich, wenn der Zustand einer Variablen in einer Visualisierung nicht zweifelsfrei zu erkennen ist.

Niemand weiß, was die Benutzer von IP-Symcon möglicherweise mit diesen Variablen verbinden. Daher kann die Reduktion der Darstellung auf eine Checkbox nicht funktionieren. Wie gezeigt, funktioniert dies noch nicht mal mit den Statusvariablen der Fensterkontakte und der Keymatic. Von eventuellen benutzerdefinierten Variablenprofilen mal ganz zu schweigen.

Gefährlich kann es werden, wenn jemand, dem nicht klar ist, dass der gesetzte Haken mal dies und dann mal das bedeutet eine Aktion auslöst. Ich denke da an Situationen wie: Er:„Schatz, schalt doch mal die erste Etage spannungsfrei, ich will mal schnell die neue Leuchte anschliessen.“ Sie: „Ist frei.“…

Natürlich hat jeder Benutzer die Pflicht selbst für eine sichere Funktion seiner Hausautomation zu sorgen, nur ob dazu jeder in der Lage ist? Wenn ich mir hier manche Frage oder Diskussion ansehe habe ich daran große Zweifel.

Für die Macher von IP-Symcon stellt sich möglicherweise im Falle eines, durch Fehlinterpretation des Hakens, entstandenen Sach- oder gar Personenschadens die Frage der Mitverantwortung. Sicher hat sich z.B. der Elektriker selbst vom spannungslosen Zustand zu überzeugen, ob der Hersteller des falsch beschrifteten Leitungsschutzschalters im Falle eines Unfalls aber völlig unbeschadet weg kommt?

Ich werde die Mobile App in diesem Zustand weder selbst benutzen noch von anderen benutzen lassen.

Gruß
Ralla

Sorry Ralla, du bist hier nur ein Beispiel, aber ich finde es immer wieder spannend, welche Erwartungshaltung bei manchen Benutzer der Entwicklungsumgebung! IP-Symcon vorhanden ist.

Wir reden ja nicht über ein fertiges Produkt, dass jeden möglichen Anwendungsfall out-of-the box abdeckt!

Jeder Benutzer entwickelt seine eigene Oberfläche auf Basis der Möglichkeiten und wenn die Darstellung interpretationsfähig ist, dann liegt das nur sehr eingeschränkt an IPS.

Und zu Mitverantwortung, 5 Sicherheitsregeln! Zum Glück sind wir mit solchen Themen nicht in den USA, im Sinne von „Hunde darf man nicht in der Mikrowelle trocknen“.

Über das Design und den Interpretationsspielraum lässt sich sicher streiten.
In dem Zusammenhang von Verantwortung und Haftbarkeit zu sprechen, finde ich etwas über das Ziel hinausgeschossen.

IPS ist letztlich nur ein Werkzeug. Was man daraus macht, liegt in der Verantwortung desjenigen, der es benutzt.
Letztlich gibt es doch überall Interpretationsspielraum. Im Straßenverkehr erklärt mir auch erst jemand, dass ich bei rot zu halten habe und bei grün fahren muss und nicht umgekehrt.

Ist die Status-LED an meinem Taster rot, wenn das Licht an ist, weil mir rot sagt, Achtung die Lampe ist an und grün, alles ok, du verbrauchst keinen Strom oder ist grün Lampe an und rot aus, weil die meisten Menschen grün mit ein und rot mit aus assoziieren?!

Für viele Dinge gibt es halt kein richtig oder falsch, sondern es kommt auf die individuelle Sichtweise an und auch auf die Einweisung der Benutzer, die mit einem solchen System arbeiten sollen.

Und wer IPS nutzt, um etwas freizuschalten, der sollte sich ohnehin fragen, ob er weiß, was er tut.

Aber wie sieht es denn mit den offensichtlich noch vorhandenen Bugs aus? Gibt es dazu schon Neuigkeiten?

Guten Morgen Ralf,

mir ist durchaus bewußt, dass IP-Symcon eine Entwicklungsumgebung ist und jeder Benutzer selbst für die Sicherheit seiner Hausautomationslösung verantwortlich ist. Das habe ich ja auch geschrieben, soviel zu meiner angeblichen Erwartungshaltung.

Ich habe nur darauf aufmerksam machen wollen, dass mit der neuen Mobile App „out-of-the box“ der Zustand von Boolean-Variablen nicht mehr zweifelsfrei dargestellt wird und dies unter Umständen zu gefährlichen Situationen führen kann. Mein Beispiel mit dem Homematic Fensterkontakt und der Keymatic zeigt dies, glaube ich, ganz anschaulich. Hierzu war übrigens keine Änderung meiner Oberfläche erforderlich, der Zustand ergab sich „out-of-the box“.

Und zu Mitverantwortung, 5 Sicherheitsregeln! Zum Glück sind wir mit solchen Themen nicht in den USA, im Sinne von „Hunde darf man nicht in der Mikrowelle trocknen“.

Als Fachkraft für Arbeitssicherheit kann ich das nicht so entspannt sehen.

Wir sind völlig einer Meinung darin, dass zunächst jeder selbst für die sichere Bedienung seiner Oberfläche verantwortlich ist. Meine Lösung habe ich beschrieben.

P.S. Ich benutze auch keine Hämmer, bei denen der Stiel wackelt.

Weich einfach auf Integer Variablen mit Assoziation aus. Damit umgehst du das Problem dieser Darstellungsform.

Wir haben diese Darstellung lange diskutiert und sind zum Entschluss gekommen dass die aktuelle Variante, in der (änderbare) Boolean Variablen immer als Haken dargestellt werden, die beste Lösung ist. Wenn du deine Text ggf. etwas angepasst (z.B. Tür geschlossen und Tür entriegelt) macht der Haken wieder Sinn. Falls du deine Darstellung genau so haben willst wie vorher kannst du Integer Variablen mit Assoziationen nutzen. Mit der alten Version konntest du nur den Haken haben, wenn das ~Switch Profil genutzt wurde. Mit der neuen Variante haben wir eine wesentlich höhere Flexibilität und mit der Option auf Integer Variablen aus zu weichen auch eine Alternativen für die besonderen Randfälle.

paresy

Danke für die Klarstellung paresy.

Das es Möglichkeiten gibt die Folgen eurer Entscheidung zu umgehen ist mir schon klar gewesen. Doch das verursacht mir Aufwand. Wer mag das schon? :rolleyes:

Mir war es wichtig, auf dieses Problem hinzuweisen. Den wie du selbst schreibst:

Wenn du deine Text ggf. etwas angepasst (z.B. Tür geschlossen und Tür entriegelt) macht der Haken wieder Sinn.

Ist ein aktives Eingreifen der Benutzer erforderlich damit der Haken wieder Sinn macht. Ob das jedem klar war?

Außerdem steh ich nicht so auf viele Bildchen und Häkchen, aber das ist mein persönlicher Geschmack und tut hier nichts zur Sache.

Liebe Grüße
ralla

Sorry, dass ich mich noch einmal melde, aber die Sache mit der Haftung geht mir nicht aus dem Kopf. Vielleicht bin ich berufllich da etwas übersensibilisiert.

ralfs und Slummis Ansicht ist sicherlich nochvollziehbar, wenn man nur den privaten Benutzer von IP-Symcon im Blick hat. Die Nutzung von IP-Symcon ist aber auch im gewerblichen Umfeld gestattet.

Stellt euch einmal vor, ein Entwickler installiert bei einem Endkunden IP-Symcon. Alles ist nach bestem Wissen und Gewissen ausgeführt und tausendmal getestet worden. Der Endkunde wurde eingewiesen und die erforderliche Dokumentation wurde ausgehändigt.

Nun installiert sich der Endkunde, ohne Wissen des Entwicklers, die neue Mobile App, in der die Deutung des gesetzten Hakens, ohne Änderungen in der Programmierung, zumindest nicht immer zweifelsfrei möglich ist. Die Installation ist auf dem Handy ja so schön einfach und schließlich ist es ja nur die neue Version der mobilen Bedienoberfläche. In der Folge kommt es durch Fehlinterpretation des Hakens zu einem Schadensfall. Das mag unwahrscheinlich sein, ist aber sicher nicht unmöglich. Wer haftet?

Zumindest für die gewerblichen Nutzer ist das sicherlich eine interessante Frage.

Versteht meine Ausführungen bitte nicht als Nörgelei.

Gruß
Ralla

Das ist ja Sippenhaft was Du da skizzizierst.

Wenn ich davon ausgehe wie viel schlechte Software ich schon gesehen habe die mit Ihren Fehlern echte Schäden angerichtet hat, dann müssten die Gefängnisse voll von Softwareingenieuren sein, die die Programmiersprachen entwickelt haben mit denen wiederum die Softwareentwickler Ihre Software erstellt haben. :eek:

Oder anders gesagt - nur weil sich jedes Jahr Leute auf dem Oktoberfest bis zum Verlust der Muttersprache besaufen und randalieren, kann man den Hersteller der Bierkrüge dafür nicht haftbar machen.

Ganz so einfach ist diese Frage sicher nicht zu beantworten.

Die erste Fundstelle bei der Suche nach „Software“ „Produzentenhaftung“ macht deutlich, dass der Sachverhalt schon recht komplex ist. Ich bin aber auch kein Jurist.

Der Vergleich mit dem Bierkrug hinkt, weil unser Endbenutzer die Software ja weiterhin bestimmungsgemäß benutzt hat und trotzdem ein Schaden entstanden ist. Das Problem ist halt, dass sich plötzlich die Bedeutung der Zustandskennzeichnung ändert.

In Slummis Ampel-Beispiel würde das bedeuten, dass plötzlich nicht mehr eine rote und eine grüne Leuchte leuchten, sondern ein grüner, gesetzter Haken oder eben kein Haken. Die Bedeutung des grünen, gesetzten Hakens wäre aber nicht „du darfst gehen“, sondern (wie paresy ja auch andeutete) „Das Überqueren der Strasse ist jetzt verboten“. Wer kommt denn darauf?

Ich will hier aber auch niemanden mit einer endlosen Diskussion nerven oder IP-Symcon schlecht machen, ich wollte nur die möglichen Auswirkungen so einer vermeintlich kleinen Änderung skizzieren. Ich denke, so etwas kann schnell sehr unangenehm werden.

Gruß
Ralla

Ralla spricht mir aus der Seele. Kann dem gesagten nur zu 100% beipflichten.
Nach den letzten Änderungen sind auch meine Darstellungen (z.B. Garage offen/geschlossen) unbrauchbar.

Was vor der Anpassung klar und verständlich Dargestellt wurde ist jetzt wieder unklar.
Ehrlich gesagt ist so eine Änderung unzumutbar!!! Im Gewerblichen Bereich ein absolutes no-Go.
Würde ich IPS einem Kunden verkaufen und der macht mal einen Update … gar nicht dran zu denken was da los ist.

Mal wieder werden Änderungen gemacht die Niemand braucht und nur bewirken alles vorher konfigurierte wieder an die Änderungen in der SW anzupassen. Und das ist leider nicht das erste mal … ich habe schon etliche male zig Stunden damit verbraucht alles umzukonfigurieren nur weil nach einem Update etwas komplett anders Funktioniert hat.

Es ist immer wieder ein hin und her ohne daß wirkliche Verbesserungen dazu kommen.
Echte Features fehlen und es gibt nicht einmal einen anständigen Update der verfügbaren Icons. Die letzten Jahre hat sich in Richtung Virtualisierung so gut wie nichts getan. Genau das ist doch gerade der Trend!

Und leider leider leider werden konstruktiv gemeinte Meinungen immer als „'Angriff“ verstanden und eine klare Antwort darauf ausgeschwiegen.

Ich verstehe das Problem nicht. Tür zu = Boolean FALSE = kein Haken. Ist doch logisch und macht Sinn, oder? Wer erwartet bei TRUE einen Haken?

Am besten der Status wird zukünfig in Hex oder Binary Code angezeigt. Text Status und Icons zur Darstellung der Zustände gibt es ja nicht.

Jeder der die Hausautomation in der Familie zusammen mit Frau und Kinder verwendet wird die Problematik verstehen. Habe gerade den Status der Garage in der App hier mehreren Kollegen gezeigt und dazu gefragt „wie ist der Status des Garafentors?“ Auf den Anblick des Hakens kam von ALLEN Kollegen die Antwort … „keine Ahnung?“.

Also wenn die Zielgruppe von IP-Symcon nur „Frickler“ sind, dann weiter so. Für den Betrieb der Hausautomation in einer normalen Familie absolut unbrauchbar. Heute so, morgen anders. Es fehlt Stabilität und Konzept. Gutes Beispiel auch der Wechsel von Bezahl-App nach Free-App.

Sorry, aber das musste raus.
Ich würde mir einfach nur wünschen das IPS endlich aus der Beta Phase kommt.

Ein konstruktiver Vorschlag zur Lösung des Darstellungsproblems in der Mobile App 3.0.1.

Mittlerweile scheint Einigkeit darin zu bestehen, dass die Darstellung des Zustandes von Boolean Variablen in der App nicht unproblematisch ist. So deute ich wenigstens die Stellungnahme von paresy.

Um den Zustand von Boolean Variablen in der App zweifelsfrei darzustellen sind auf jeden Fall Änderungen auf dem Server erforderlich (z.B. Texte für die Darstellung in der App anpassen, Integer Variablen verwenden und durch Skripte mit dem Zustand der Booelan Variablen verknüpfen).

Gegen dieses Vorgehen sprechen aus meiner Sicht folgende Gründe:

  1. Manche User möchten gar keine Häkchen in ihrer Darstellung haben (ich zum Beispiel). Die klare und sachliche Darstellung aller Variablen war für mich gerade ein Grund mich für IP-Symcon zu entscheiden.
  2. Wahrscheinlich alle Benutzer der Mobile App sind gezwungen, im Falle der Verwendung von Integer Variablen teils aufwändige, Änderungen auf ihren Servern vorzunehmen.
  3. Mir widerstrebt es Änderungen auf dem Server vorzunehmen, weil eine Zusatzapplikation zur Darstellung des Systemzustands ansonsten keine zweifelsfreie Darstellung des Systemzustands ermöglicht.

Vielleicht läßt sich der Aufwand für die erforderlichen Änderungen ja verteilen. Im Eigenschaftendialog einer Variablen lässt sich wählen, ob der Graph einer geloggten Variablen in der Visualisierung angezeigt werden soll oder nicht.

Was haltet ihr davon, wenn es für die Darstellung von Boolean Variablen in der Mobile App eine ähnliche Checkbox gebe. Dies hätte folgende Vorteile:

  1. Die wesentliche Änderung wäre nur einmal erforderlich. Nämlich in IP-Symcon. Dadurch reduziert sich der insgesamt erforderliche Arbeitsaufwand.
  2. Auch die User müssten Änderungen vornehmen, kämen also auch nicht ungeschoren davon.
  3. Jeder könnte problemlos die Darstellung wählen, die er für richtig hält.

Gruß
Ralla

Wäre eine tolle Variante „Alt-bewährtes“ mit „Neuem“ zu verbinden !

Kann man diese sinnlose Änderung nicht einfach wieder ausnehmen?
Warum muß die Darstellung im Webfront anders sein als in der App?
Sorry, total unlogisch.

Und ein Haken (Checkbox) macht auch wirklich nur da Sinn wo der User auch tatsächlich den Status durch aktivieren/deaktiviern des Hakens den Zustand schalten kann. Bei einem Türkontakt an einer manuell betätigten Türe wäre es eine Sünde einen Haken darzustellen.

Es wäre so einfach. Darstellung in der App genau so wie im Webfront.
Einfach, logisch und Anwenderfreundlich.

Also die nicht schaltbaren Boolean sind schon korrekt, wenn man ein Profil zugewiesen hat.
Michael

Nur mal so für mich, weil ich vielleicht das Problem nicht sehe mit den Boolean-Variablen, aber was hindert euch daran ein Profil mit sprechenden Ausprägungen zu verwenden? :confused: Ansonsten steht es jedem Frei die Variable vernünftig zu benennen, aber dann sollte man halt der Boolschen-Algebra mächtig sein. Jeder kann auf einem Formular eine Fragebogen mit Ankreuzkästchen ausfüllen und hier genügt es plötzlich nicht mehr? Dann kann ja nur der Text links vom Kreuz das Problem sein, oder?