Heute möchte ich über Smart Homes und IoT-Geräte sprechen. Aber es ist kein gewöhnlicher Artikel. Sie finden keine Beschreibung der Hardware, Links zu Herstellern, Codestapeln oder Repositorys. Heute werden wir etwas von einer höheren Ebene diskutieren - Prinzipien, die verwendet werden, um „intelligente“ Systeme zu organisieren.
Smart Home ist ein System, das anstelle einer Person einige Alltagsroutinen ausführen kann. Es führt uns zum ersten und wichtigsten Prinzip:
1. Smart Home muss das Leben leichter machen.
Smart Home ist ein System zum Leben, es ist kein Spielzeug für Geeks. Systeme, deren Verwendung
1 komplizierter ist als ein Switch, sind kein Smart Home.
Jedes neue Ding muss gegen dieses Prinzip getestet werden. Wenn es das Leben nicht einfacher macht und Sie nicht verstehen, wie Sie es verbessern können, um das Leben einfacher zu machen, ist es nichts für Smart Home.
Das zweite wichtige Prinzip ist, wie ein Benutzer mit dem System interagiert:
2. Eine gute Benutzererfahrung ist wichtiger als die Funktionalität.
Ein cooles Tool, das schwer zu bedienen ist, ist keinen Cent wert. Praktische und zuverlässige Geräte mit eingeschränkten Funktionen haben im Vergleich zu komplizierten Geräten für alle möglichen Anwendungen und Anwendungen viel größere Erfolgschancen.
2.1. Praktische Schnittstellen sind besser als Anpassungen.
Wenn Sie nicht verstehen, wie Sie zahlreiche Funktionen und eine einfache Benutzeroberfläche kombinieren und einfach alle Funktionen auf Lager haben, in der Hoffnung, dass ein Benutzer alles selbst herausfinden kann, sollten Sie vielleicht Ihre Berufswahl überdenken.
Wenn Sie nicht verstehen, wie Sie Komfort und zahlreiche Funktionen integrieren können, müssen Sie einige Einstellungen entfernen. Jede Funktion ist besser als ein normaler Schalter. Wenn es jedoch zu kompliziert ist, kehrt ein Benutzer zu einem Schalter zurück.
Gleiches gilt für die Qualität der Arbeit. Ein Knopf, der das Licht einfach ausschaltet, ist besser als ein Dimmer, der manchmal funktioniert und manchmal nicht funktioniert:
2.2. Die Qualität der realisierten Funktionen ist wichtiger als die Anzahl der Funktionen
Es ist besser, nur wenige zuverlässige Funktionen zu haben als zahlreiche fehlerhafte.
Einer der Mechanismen, die im Laufe der Evolution im Geist des Menschen entwickelt wurden, ist eine emotionalere Reaktion auf negative Reize. Negative Faktoren sind wichtiger als positive - es ist viel gefährlicher, einen sich nähernden Tiger nicht zu bemerken, als eine reife Frucht auf einem Baum zu verpassen. Wenn Ihr System bestimmte Funktionen nicht hat, ist daran nichts auszusetzen. Es ist einfach das Fehlen eines positiven Stimulus. Wenn Sie jedoch eine Funktion haben, die jedoch nicht funktioniert, ist dies ein negativer Reiz, an den Sie sich lange Zeit leicht erinnern können.
2.3. Die Systemnutzung darf die übliche Arbeitsgeschwindigkeit nicht verringern
Verzögerungen sind unzulässig, da sie sich negativ auf die Benutzererfahrung auswirken. Es ist auch ein negativer Reiz. Wenn eine Person keine Verzögerung zwischen dem Umlegen des Schalters und dem Einschalten des Lichts bemerkt, darf sie dies in Ihrem System nicht bemerken.
Moderne Hardware arbeitet mit hoher Geschwindigkeit. Es ist kein Problem, Frequenzen von Dutzenden von MHz auf Controllern und mindestens Dutzenden Kilobit pro Sekunde auch über einen Funkkanal zu erreichen. Wenn Ihr Benutzer mit dieser Hardware immer noch Verzögerungen bei der Arbeit hat, sollten Sie Ihre Berufswahl überdenken.
2.4. Das System darf bereits gebildete Benutzergewohnheiten nicht brechen.
Ihr System ist ein kleiner Teil des Lebens eines Menschen. Normalerweise überschreitet die Lebensdauer einer Person die Nutzungsdauer eines Systems. So werden Systeme kommen und gehen und das Leben eines Menschen wird weitergehen. Und dieses Leben ist voll von Gewohnheiten über die Lichthelligkeit, den Standortwechsel und die Art und Weise, wie er oder sie es für bequem hält, Licht und Klima zu kontrollieren.
Gewohnheiten können nicht gewaltsam geändert werden. Neue Dinge können angeboten, aber nicht erzwungen werden.
Sie können einem Benutzer nicht sagen: "Jetzt schalten Sie das Licht eines Smartphones ein - es ist modern, stilvoll und cool." Es widerspricht diesem und einigen anderen Prinzipien.
Was tun?
2.5. Das System muss neue Erfahrungen bringen und darf die alten nicht ersetzen.
Wenn Sie der Meinung sind, dass Ihre Steuerung von Heimsystemen besser ist als eine alte, bieten Sie sie einem Benutzer an. Wenn es wirklich bequem ist, wird er den neuen selbst auswählen (ja, verschiedene Leute wählen verschiedene Wege). Alles, was Sie tun können (und müssen), ist ihm eine Wahl zu geben.
Die Logik der Arbeit spielt im Smart Home eine wichtige Rolle. Es definiert die Regel, nach der Smart Home funktioniert. Und es führt uns zum nächsten Prinzip:
3. Die Benutzerlogik kann nicht eingeschränkt werden.
Wenn ein Benutzer einen Wasserkocher
3 kochen möchte, wenn die Temperatur in einem Raum steigt, lassen Sie ihn dies tun. Sie müssen auch eine Situation vermeiden, in der eine erforderliche Aktion auf Hardware- oder Softwareebene ausgeführt werden kann, diese jedoch nicht verfügbar ist, nur weil ein Entwickler der Meinung ist, dass „niemand sie jemals benötigen wird“.
3.1. Je einfacher - desto besser: Das Erstellen von Logiken darf keine besonderen Kenntnisse der Systemstruktur erfordern.
Wenn Sie Geräte mit unterschiedlichen Versionen und mit unterschiedlichen Protokollen haben, stellen Sie sicher, dass ein Benutzer nur in Fällen davon Kenntnis hat, in denen dies wirklich notwendig und unvermeidbar ist.
Wenn Sie einem Benutzer die Mühe ersparen können, auch auf Kosten der Entwickler spezielle Kenntnisse zu erlangen, tun Sie dies. Ein Entwickler wird zwei Tage dafür aufwenden und es wird tausend Benutzer pro Stunde dauern. Wenn wir 48 Stunden gegen 1000 Stunden betrachten, ist die Antwort offensichtlich.
Schläfst du gut, John, ein Serienprogrammierer?
3.2. Geräte mit den gleichen Funktionen müssen auf die gleiche Weise gesteuert werden.
Ein Benutzer muss nicht wissen, dass ein Wasserventil durch bestimmte Befehle und ein Wasserhahn durch andere gesteuert wird. Wenn beide das Wasser in einem Rohr kontrollieren, müssen sie auf Benutzerebene die gleichen Schnittstellen haben: „offenes Wasser“, „Wasser schließen“.
Wir leben in einer physischen Welt. Der Körper und das Gehirn des Menschen sind so geformt, dass sie mit physischen Objekten interagieren. Es führt uns zum nächsten Prinzip.
4. Physische Steuergeräte sind besser als virtuelle.
Alle Apps auf einem Smartphone, selbst die besten, sind nicht so gut wie ein normaler physischer Switch an einem erforderlichen Ort.
Es ist eine andere Sache, dass ein Schalter genau an der
richtigen Stelle platziert werden muss . Es führt zu einer anderen Regel:
5. Drahtlose Systeme sind besser als kabelgebundene.
Kabelgebundene Systeme sind zuverlässig, aber nur drahtlose Systeme ermöglichen die Platzierung eines neuen Schalters oder Relais, ohne einen Raum zu renovieren. Sie können auch einen Schalter bewegen, wenn Sie der Meinung sind, dass ein neuer Ort bequemer ist. Es gibt jedoch bestimmte Ausnahmen:
5.1. Schlechte drahtlose Systeme sind schlechter als kabelgebundene.
Für ein gutes drahtloses System spielt es keine Rolle, wie weit Geräte von der zentralen Steuerung entfernt sind. Gute drahtlose Systeme sind Protokolle mit
Mesh-Netzwerk : ZigBee, Z-Wave, 6LoWPAN usw.
Alle anderen Optionen, einschließlich Wi-Fi, sind nicht so gut. Proprietäre Protokolle wie "433 MHz", obwohl sie in anderen Frequenzen arbeiten können und sich stark voneinander unterscheiden, sind auch nicht so gut.
Die Nachteile von Wi-Fi sind, dass Sie keine voll funktionsfähigen "Schlaf" -Geräte herstellen können, die automatische Einstellung kompliziert ist und nicht mit anderen Wi-Fi-Geräten im Haus kompatibel ist.
Die Nachteile proprietärer Protokolle bestehen darin, dass sie in den meisten Fällen keine Kontrolle über die Bereitstellung, Verschlüsselung und verfügbaren Spezifikationen haben. Weder Wi-Fi noch proprietäre Protokolle verfügen über ein Mesh-Routing, das zu folgenden Schwierigkeiten führt: „Ich kann keinen Switch in diese Ecke stellen, da er zu weit vom Router entfernt ist.“
Sie können kein 100% zuverlässiges System erstellen, das nicht gewartet werden muss. Geräte sind außer Betrieb, es gibt Stromstöße, Nachbarn können Sie überfluten, Batterien entladen, ein Kind kann Suppe auf eine Lampe verschütten usw. Aber:
6. Das Reparieren, Aktualisieren, Warten und Diagnostizieren muss einfach sein.
Im B2B ist alles klar. Es gibt einen Benutzer, einen Entwickler und einen Bediener, es ist eine Person oder Organisation, die weiß, wie das System aussieht und wie man auf professioneller Ebene damit arbeitet. Ein Buchhalter muss keine Programmierkenntnisse haben, um seine professionelle Software verwenden zu können. Eine Person, die ein Büro mietet, muss nicht wissen, wie die Belüftung funktioniert. Sie muss lediglich sagen: „Im Büro ist es stickig“.
Eine kluge Lösung für den Kauf eines Systems wird auf der Grundlage der Berechnung der Gesamtbetriebskosten getroffen, die sich aus dem Preis des Systems und den Wartungskosten zusammensetzt.
Bei Systemen, die in Privathaushalten verwendet werden, ist dies etwas komplizierter. Ein Bediener und ein Benutzer sind ein und dieselbe Person, die nicht über die erforderlichen Kenntnisse des Systems verfügt. Leider sind dies die Grenzen des Verbrauchermarktes. Und es führt zu folgenden Prinzipien.
6.1. Geräte funktionieren entweder oder nicht. Es gibt keine dritte Option.
Wahrscheinliche Arbeiten, Teilarbeiten oder Fehlfunktionen sind unzulässig. Vermeiden Sie Situationen, in denen Ihr Gerät nicht jedes zweite Mal von einem von zehn Mal funktioniert. Wenn Sie der Meinung sind, dass Ihr Gerät fehlerhaft funktioniert, schalten Sie es aus Sicherheitsgründen aus, um eine positive Benutzererfahrung zu gewährleisten. Das Ersetzen eines Geräts ist nicht angenehm, aber es ist besser, einen Benutzer dazu zu bringen, ein Gerät auszutauschen, als sich die Meinung zu bilden, dass das System „jedes zweite Mal“ funktioniert. Es gibt nur zwei mögliche Zustände eines Systems: Es ist nicht in Ordnung oder es funktioniert nicht, es ist in Ordnung und es funktioniert.
Wenn Sie sicher sind, dass eine Systemverschlechterung möglich ist, informieren Sie einen Benutzer mithilfe einer leicht verständlichen Meldung darüber: "Der zweite Dimmerkanal ist nicht in Betrieb. Ersetzen Sie den Dimmer. Den ersten Dimmerkanal weiter benutzen? Ja / Nein »
6.2. Das Ersetzen eines defekten Geräts muss einfach sein.
Das System muss ein Modul eins sein. Wenn ein Sensor außer Betrieb ist, muss nur dieser Sensor ausgetauscht werden. Es ist nicht korrekt, ein Relais durch eine Fernbedienung durch einen Sensor zu ersetzen, da diese in der Fertigungsphase gekoppelt sind.
Es ist nicht richtig zu fordern, dass „ein neuer Sensor nur von unserem Spezialisten installiert werden kann“, da es offensichtlich ist, dass Ihre Spezialisten mit der Zeit nicht ausreichen werden, um Millionen von Benutzern zu bedienen, wenn die Popularität Ihres Systems zunimmt. Somit treten zu einem bestimmten Zeitpunkt Probleme auf. Natürlich wird ein Benutzer ein Gerät nicht selbst reparieren, aber wenn es außer Betrieb ist, muss er die Möglichkeit haben, es selbst zu ersetzen.
6.3. Benutzerfreundliche Nachrichten.
Wenn etwas schief geht, muss ein Benutzer darüber Bescheid wissen und wissen, was genau schief gelaufen ist. Sie können die Meldung "Fehler Nr. 45" nicht anzeigen, die besagt, dass er sie verstehen muss. Eine solche Nachricht muss einem Benutzer angezeigt werden: „Gerät antwortet nicht. Versuchen Sie, es neu zu laden und erneut zuzuweisen, oder wenden Sie sich an den technischen Support. Fehler # 45 ”
Sie können nicht erfahren, dass ein Gerät nicht antwortet (wenn Sie dies können) und diese Informationen einem Benutzer vorenthalten. Es ist nicht angenehm, Nachrichten über ein Problem zu erhalten. Es ist jedoch viel unangenehmer zu erfahren, dass ein Gerät seit einer Woche außer Betrieb ist, wenn Sie dieses Gerät letztendlich benötigen.
6.4. Keine zusätzlichen Informationen in Nachrichten.
Spam einen Benutzer nicht mit Protokollen. Ein Benutzer benötigt Informationen wie im vorherigen Prinzip, da sie Informationen enthalten, was genau schief gelaufen ist. Wenn er Informationen nicht verstehen kann oder nicht der Adressat ist, braucht er sie nicht.
Zeigen Sie nicht Hunderte typischer Meldungen an: "Verbindung zum Gerät ist unterbrochen", "Verbindung zum Gerät wird wiederhergestellt". Sie müssen entscheiden, ob es sich um wichtige Informationen handelt, und ein Benutzer muss darüber informiert werden. Wenn die Verbindung wiederhergestellt ist, sind diese Informationen nicht wichtig. Zeigen Sie sie daher nicht an.
4 .
6.5. Für Wartungsarbeiten sind keine besonderen Kenntnisse oder Geräte erforderlich.
Ermöglichen Sie einem Benutzer, die Firmware zu aktualisieren, indem Sie auf einige Schaltflächen klicken. Dies kann über eine Standardschnittstelle (USB / BT / Wi-Fi) erfolgen oder die Aktualisierung über den SPI-Programmierer überhaupt nicht erwähnt werden.
Sie können nicht erwarten, dass ein Benutzer Bitmasken berechnet, um ein Gerät zu konfigurieren.
6.6. Das System darf nicht ständig gewartet werden.
Wenn ein Dimmer jeden Monat die Verbindung verliert und ein Benutzer eine Leiter hinaufsteigen muss, um eine Lampe zu erreichen und den Aktuator wieder anzuschließen, ist dies nicht bequem. Wenn die Batterien alle zwei Monate in einem Schalter gewechselt werden müssen, ist dies nicht bequem. Selbst wenn die durchschnittliche Wartungszeit eines Geräts sechs Monate beträgt, ist dies nicht bequem. Wenn sich ungefähr zwanzig Geräte im Haus befinden, muss ein Benutzer alle neun Tage etwas tun.
6.7. Das System muss Möglichkeiten zur Aktualisierung und Erweiterung haben.
Die Ausgaben für die Erweiterung eines Systems müssen linear steigen.
Vermeiden Sie Situationen, in denen ein Benutzer, der einen Sensor hinzufügen möchte, einen neuen Controller kaufen muss, da der alte nicht mehr als 6 Sensoren unterstützt
5 .
Vermeiden Sie Situationen, in denen neue Sensor-Firmware nur mit einer neuen Version eines Controllers funktioniert.
Solche Einschränkungen wirken sich positiv auf das Einkommen aus und veranlassen Benutzer, neue Geräte zu kaufen. Aber es ist ein Weg ins Nirgendwo. Durch solche Tricks können Sie das Vertrauen Ihrer Benutzer verlieren und dadurch viel mehr verlieren, als Sie hätten verdienen können.
7. Selbstverträglichkeit: Externe Netze sind eine Option, keine Voraussetzung.
Ein System, bei dem Befehle über einen externen Server gesendet werden müssen, ist nicht praktisch. Sie können stundenlang über praktische Schnittstellen, moderne Apps und coole Neuronetzwerke sprechen, aber sie bedeuten nichts, wenn ein Benutzer das Licht in der Toilette nicht einschalten kann, wenn das Internet nicht verfügbar ist. Glauben Sie wirklich, dass ein solches System als gut angesehen werden kann?
Ich verstehe wirklich nicht, warum dieses Prinzip nicht selbstverständlich ist. Wenn Sie einen externen Server in ein Projekt aufnehmen, wird dies zu einem möglichen Fehlerpunkt. Externe Dienste sind cool, sie können weitere Funktionen hinzufügen, aber sie können nicht die einzige Variante der Steuerung sein. Obwohl sie wunderbar als zusätzlicher Steuerkanal, Backup-Speicher, Tool zur Datenanalyse usw. verwendet werden können.
8. Zentralisierung: Das Fehlen eines zentralen Hubs schränkt die verfügbaren Logiken ein.
Ein dezentrales System ist jedoch auch nicht ideal, obwohl es zuverlässig ist.
Ein dezentrales System ist ein System, bei dem ein Schalter einer Lampe „sagt, dass sie sich ausschalten soll“ und ein Temperatursensor eine Heizung einschaltet, wenn die Temperatur sinkt. Ein dezentrales System verliert an ein zentrales, da es nur für die einfache Interaktion zwischen Geräten geeignet ist, wenn ein Gerät ein anderes Gerät steuert. Wenn ein System komplizierter wird, tauchen viele Fragen auf. Wenn mehrere Sensoren vorhanden sind, akzeptiert die Heizung den Befehl von allen? Soll die Heizung Sensoren selbst anfordern? Wenn eine Entscheidung über die Analyse der tatsächlichen Daten getroffen werden muss, wo soll das Archiv gespeichert werden? Wo speichern und wie Logik ändern? Wie speichere ich Logiken auf "dummen" Geräten? Wie aktualisiere ich die Logik?
All diese Fragen verschwinden, wenn davon ausgegangen wird, dass ein Hub als Dateninteraktionspunkt und Speicherort für die Logik eines Benutzers erforderlich ist. Geräte können „dumm“ sein, dh sie können Daten senden und Befehle abrufen, da die Aufgabe, Daten zu speichern, Daten zu verarbeiten, Entscheidungen zu treffen und mit externen Diensten zu interagieren, bei der zentralen Steuerung liegt.
Die Dezentralisierung kann teilweise gespeichert werden. Wenn kein Hub vorhanden ist, können Befehle direkt als ausfallsicherer Modus gesendet werden. Es gibt keine Logik, aber das Licht kann eingeschaltet werden.
9. Das System darf keine potenziell gefährlichen Aktionen ausführen, ohne einen Benutzer zu informieren oder eine Bestätigung von ihm zu erhalten.
Solange wir in einer Welt leben, in der ein Programmierer nicht für den durch seine Software verursachten Schaden verantwortlich ist, treten Fehler in der Software auf, einschließlich der Software von Smart Home. Die einzige Möglichkeit, Fehler nicht zuzulassen, die schwerwiegende Folgen haben, besteht darin, die unabhängigen Aktionen des Systems einzuschränken. Potenziell gefährliche Aktionen dürfen nur ausgeführt werden, wenn ein Benutzer darüber informiert wird, oder noch besser, nachdem ein Benutzer sie bestätigt hat. Das Licht kann automatisch eingeschaltet werden, ein Fehler in der Software weckt einen Benutzer nachts oder erhöht seine Stromrechnung. Es ist nicht angenehm, aber es ist nicht gefährlich. Wasserhähne können jedoch nicht automatisch geöffnet werden, wenn keine Werkzeuge vorhanden sind, die ein Hochwasser verhindern. Dachte, es ist nicht gefährlich, Wasserhähne automatisch zu schließen.
Dies bedeutet nicht, dass die automatische Steuerung von Heizungen, Kesseln, Kaminen, Wasserkochern usw. verboten ist. Dies bedeutet, dass Sie sicherstellen müssen, dass die Gefahr die Benutzerebene nicht erreicht, wenn Sie eine potenziell gefährliche Aktion automatisch ausführen möchten. Stellen Sie sicher, dass ein Wasserkocher automatisch ausgeschaltet wird, wenn eine bestimmte Temperatur erreicht ist, dass ein Bad über Lecksensoren verfügt usw.
10. Das System muss über Optionen zur Selbstkontrolle und Selbstdiagnose verfügen.
Ein heutiger Entwickler von Smart-Home-Systemen muss ein wenig paranoisch sein. Dem Internet kann nicht vertraut werden, es kann ausgefallen sein. Code kann nicht vertrauenswürdig sein, es kann Fehler geben. Kann man Hardware vertrauen? Nein, auf Hardware kann man sich nicht verlassen. Relais können kleben, Triacs können sich öffnen, Sicherungen können brennen. Sogar ein Benutzer kann einen Kilowattkessel an eine 100-Watt-Steckdose anschließen. Somit sind ein Spannungssensor, ein Stromsensor und ein Temperatursensor erforderlich. Wenn die Temperatur die Grenzwerte überschreitet, schalten Sie alles aus und senden Sie eine Warnung. Wenn der Strom die Grenzwerte überschritten hat, schalten Sie alles aus. Wenn ein Relais ausgeschaltet ist, aber immer noch Spannung anliegt, senden Sie eine Benachrichtigung. Wenn Sie ein Relais ausschalten und keine Spannung anliegt, senden Sie eine Benachrichtigung.
11. Das System muss manuell gesteuert werden.
Selbst wenn Sie alle paranoischen Dinge berücksichtigen, wird es eine Situation geben, in der alle Kontrollen fehlgeschlagen sind und etwas zusammengebrochen ist. Es kann ein Switch, ein Router oder der zentrale Hub sein, aber dennoch möchte ein Benutzer das Licht in der Toilette einschalten. Was tun?
Es muss immer eine Taste vorhanden sein, mit der die Sonne im manuellen Modus untergehen kann. Diese Taste kann das Licht JETZT ein- und ausschalten. Da es einen Tag dauern wird, bis ein neuer Hub geliefert wird und ein neuer Switch später gekauft werden kann, muss das Licht im Schlafzimmer heute Abend ausgeschaltet werden.
12. Hacker sind genauso wichtig wie normale Benutzer.
Regelmäßige Benutzer bringen Ihnen Geld, Hacker
6 kann an neue Funktionen denken. Eine Manufaktur kann und darf nicht alle Szenen der Systemnutzung entwickeln, da sie nicht in allen Bereichen über Kenntnisse verfügt und die Wirkung solcher Dinge nicht berechnen kann. Es ist durchaus möglich, dass eine intelligente Steckdose bequem über einen Thermostat einer mobilen Brauerei gesteuert werden kann, da sie über einen PID-Regler verfügt. Das Beispiel ist etwas weit hergeholt, aber die Idee ist, dass es nicht schlecht ist, günstige Bedingungen für Hacker zu schaffen, da diese Ihrem System die Bewegungskraft verleihen können.
13. Offenheit: Das System muss über eine offene API verfügen, um in andere Systeme integriert zu werden.
Sie können nicht alle Bedürfnisse Ihrer Kunden mit Ihren eigenen Geräten erfüllen. Es wird immer Geräte geben, die Sie nicht haben. Oder Sie haben die Geräte, aber Geräte anderer Hersteller können besser sein. Um Ihr System mit anderen zu verbinden, ist eine offene, gut dokumentierte API unbedingt erforderlich. Wenn Sie keine API haben, können Ihre Benutzer keine heterogenen Systeme haben. Aber auch große Unternehmen mit proprietärer Hardware und Software können es sich nicht leisten.
14. Dokumentation: Es ist genauso wichtig wie Hardware und Code.
Es spielt keine Rolle, wie cool Ihre Hardware ist oder wie gut Ihre Software ist, wenn ein Benutzer nicht versteht, wie er Ihr System startet und wie er damit arbeitet. Eine gute Dokumentation ist die nach dem Lesen, bei der ein Benutzer nicht daran denkt, sich an den technischen Support zu wenden, oder die geistigen Fähigkeiten des Entwicklers nicht negativ bewertet. Es ist unmöglich, eine solche Dokumentation zu schreiben, aber es ist etwas, nach dem man streben muss.
Und zu guter Letzt:
15. Selbstverträglichkeit und Selbsttragfähigkeit: Das System muss weiter funktionieren, auch wenn das Unternehmen nicht mehr existiert.
Eine Person lebt ungefähr 70-90 Jahre, ein in ihrem Haus installiertes System funktioniert ungefähr 5-10 Jahre (bestenfalls), Unternehmen halten noch weniger. Erstellen Sie kein System, das nicht mehr funktioniert, wenn Ihr Unternehmen stirbt. Fühlen Sie sich für Benutzer. Planen Sie das System so, dass es auch dann funktioniert, wenn das Unternehmen und der Entwickler nicht mehr auf dieser Welt sind.
Wenn einem Gerät das Abrufen eines Tokens vom Server eines Entwicklers zugewiesen ist, klicken Sie auf die Schaltfläche "Abrufen eines Tokens überspringen". Wenn die Firmware beim ersten Systemstart von der Website aktualisiert werden muss, können Sie die Standard-Firmware herunterladen, wenn die Website nicht verfügbar ist. Und so weiter.
In diesem Artikel habe ich versucht, die Erfahrungen mit der Verwendung, Entwicklung solcher Systeme und der Arbeit mit ihnen in 15 Prinzipien zu beschreiben. Ein Teil von ihnen kann weit hergeholt erscheinen, andere sind umstritten (es ist normal) und andere sind abgedroschen (es ist auch normal).
Aber wenn Sie sich Zeit genommen haben, um auch nur an einen von ihnen zu denken, wurde der Artikel nicht umsonst geschrieben.
Kommentare
1. Mit "verwenden" meine ich den Prozess der regelmäßigen Interaktion mit dem System, aber nicht der Einstellung.
2. Ich möchte betonen, dass ich sage "ein Benutzer darf es nicht bemerken", aber nicht "die Verzögerung muss dieselbe sein wie". Die Praxis zeigt, dass ein Mensch keine Verzögerung von 300 Millisekunden bemerkt.
3. Vielleicht ist er in Asien gewachsen und glaubt, dass heißes grüner Tee das beste Mittel gegen Hitze ist.
4. Wenn ich "Keine Informationen anzeigen" sage, bedeutet dies, dass einem Benutzer nicht jedes Mal eine Nachricht darüber gesendet werden muss. Es muss auf Anfrage eines Benutzers angezeigt werden, z. B. "Protokoll anzeigen" oder "Debug-Informationen anzeigen", wenn eine Taste gedrückt wird. Betrachten Sie Benutzer nicht als Idioten, respektieren Sie ihre Zeit.
5. Es ist oder natürlich unmöglich, ein System zu entwerfen, das eine unbegrenzte Anzahl von Geräten unterstützt. Es wird immer Grenzen geben, aber es ist die Aufgabe eines Entwicklers, sie in 99% aller Fälle irrelevant zu machen. Die Beschränkung auf 6 Sensoren ist nicht akzeptabel. Einhundert oder zweihundert Geräte in einem Netz reichen für die meisten Benutzer von Smart Homes aus.
6. Ich verwende das Wort "Hacker" in der wesentlichen Bedeutung dieses Wortes gemäß RFC1983 und nicht die Bedeutung einer Person, die Computer verwendet, um unbefugten Zugriff auf Daten zu erhalten.
Dieser Text wurde von iRidium Mobile bei der Übersetzung ins Englische unterstützt , wofür ich ihnen sehr danke.