Bestand wählen
Merken

Fault Tolerant UX

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
the and and and and and and and and and the 1 thing that is part of perhaps you know
your own life is to work work done in a number of different projects perhaps you use some of them on I've also done consulting with with tell and I recognize the number of our clients here which is wonderful to see but on my at the beginning of my career actually I was completely different
I studied naval architecture and marine engineering and the very
1st job I had was developing software for safely loading of cargo onto ships and also salvaging ships that had become damage to us that say holds could be flooded so that the ship could be rated without it breaking into and thinking then as you can
imagine the fault tolerance is but of very important concern in naval architecture we
ships undergo extreme stress but it can be a brutal environment and the sea in
the and of course ships must be tolerant of operator faults this is this is literally a picture of me at the helm of an Exxon oil tanker but don't worry I don't think the engine was the so in
order to engineer fault tolerance in ships three-dimensional models are made up of 4 ships are constructed there they undergo Finite Element Analysis stresses are placed on these models based upon predictions for sale 100 year events a 100 year storms you know the worst possible conditions that a ship might encounter and every aspect
of a ship is engineered for fault tolerance this is a schematic of an engine room and see there's our there's a lot of redundancy user of duplicate fuel oil purifiers but you might be surprised to learn that ships even carry a spare tail staff in case of primary 1 a shared and it needs to be replaced at sea
and to engineer around the possible operator faults controls have to be laid out as clearly as possible obviously they require a lot of training used by of the but but the captain's and pilots need to know exactly what what controls do what in the state of the ship all the systems on the ships have to be conveyed to that central not control room on the deck the because I source of
bacon valuable they also also need to be classified by regulatory bodies and every aspect of a ship's construction and design was analyzed before it can be flagged in short I left left
this world behind when I had to move back east and I were in the late nineties I was probably the only 1 in leaving san francisco to start a career in web development so the nineties were pretty
find on the web the but maybe not so
serious if and engineering
practices left a little bit to be desired the but we were pretty accepting
because there was more good than bad
frankly what we were shipping to browsers wasn't that complicated it was up with sprinkles of of script to enhance the experience a little bit the serious engineering of and
fault-tolerance was expected on the server side have and with that with web servers database servers of course the security and reliability of data was still of course so let's fast forward to
today in we have a much different environment much more rigorous engineering practices across the full stack of and wonderful new front-end technologies like amber jails which really flipper's uh the
model from a sprinklings of of JavaScript almost there a JavaScript quarter with the sprinklings of marker what we're building with number j
ust our our complex sophisticated independent systems that we're launching into our users browsers and after the
glimmer demo I had to update this slide to represent member better the so are Amber apps letter users zip around at the whim within our don't are applications domain of getting getting out to to the places they need to go as quickly as possible with as little interference as possible but make no mistake these are these are complicated systems and fault tolerance needs to be of primary concern for us and the environment in which we want to
these applications is that that can also be a severe and stressful and we have of multiple devices to support multiple browsers of sometimes of browsers with JavaScript disabled sometimes with Internet disabled
sometimes with the browser itself disabled it and we have our
users with little to no training and perhaps overly optimistic to so when
I think about fault tolerance I like to think about the user experience we wanna provide to those users so that their of their shielded from any environmental was the stresses that our application encounters and when I think about b of the primary concern of providing a fault-tolerant user experience I like to think of it as a transactional user experience much like a database by has a has to operate transact who of transactional transactionally in order to be reliable it needs to have these characteristics in order to reliably at commit data transactions must be UK atomic consistent isolated and durable this is the so-called acid test for transactions reliability atomic means that a transaction must be all or nothing the if you're editing
but if you're editing data on the form that's complicated I represents multiple models all that data needs to be either safe together or discarded I think you shouldn't in this case as see the contact without saving the changes to the phone number even if under the hood you representing these these 2 of the aspects of a contact with different modeling a transaction should be consistent
it should move between valid states this
is a particular challenge of poor server rendered apps that push partial our fragments of of mark up to a page and a it's pretty easy for those partials to get in to become inconsistent this is not a problem for our frameworks such as amber in which there is a canonical died the data model that's driving be you bindings and that in our in our templates transactions should be
isolated as well that means they should allow concurrent changes so changes us if you're
editing of editing that contact and you're providing us submitted a cancel button your providing a contract with the user of your application say to say about that that you you your at your editing this contact in in its own context by in this context should be isolated from the rest of the application and should only be submitted back to it when you press submit or just discarded when you press cancel out this can be a little tricky to do and way it's why a lot of editing forms uh and modern web apps have simply adopted a done in a black and say where you're you're not providing that same contract of isolation of the of the edits in your edits are automatically flowing through to the canonical models in your application
so I transactions should also of course be durable users need be confident that they're going to persist
when you push that submit button but any you know you expect that change to be saved now and forever you can you expect when you reload your browser that that change will still be persistence so you these are
pretty pretty hard and fast rules for the but forward fault tolerant user experience is a rosy should should not violate word you really violating you'd be your users trust users have a very fixed harder mental model about trend a transactional user experience and if you cross that model then they'll feel that something is just not right with your application there's another
aspect of fault tolerant user experience and that is kind of our Angela it's a forgiving user experience it would be applications of it should try to provide the a forgiving user experience for the love of kittens this is going to make people happy the 1 aspect of a forgiving user experience is about to provide transitional persistent perhaps Tupras to per meaning to persist so long
data that has not yet been saved but is in the process of being edited I you might have experienced this on get hub when your say editing uh were commenting on a pull request and you edit entered a comment you flip over the files changed the other tab you think 0 no I might have lost that common I take all that out but you come back and you're delighted that a comment is still there that's so that's 3 I and let's see the another
aspect of a forgiving user experience is undo and redo if you make a mistake like
say deleting a few e-mails at you don't want to you didn't mean to delete the Gmail is nice enough to provide an undue the another
nice feature that kinda later users provide offline support for certain types of
applications which can really benefit from offline support and in particular applications which are editing where you're editing data are pretty much in isolation where all your data doesn't need to be tied to a response from the from the server and there's no reason the block here users user from continuing to work with that data when when your Internet connection goes down it's a in engineering challenge but but if you can solve it it's a real win for usability the on a
related note a similar feature is to provide an asynchronous interface that's that's not blocked by the request response cycle with the server where
your user can make changes as quickly as possible and regardless of the the state of your server they can those changes can be cued up and saying to that's what you're apps convenience the so I've been
talking about the user experience that we desire the fault-tolerant user experience and I'm sure that as developers you looking at at this is that these different degrees of um of of complexity in the user experience that I'm covering and then immediately thinking about engineering those user experiences whatever is terrific at providing a consistent user experience across your app as I've shown you the eye In the case of save you know way of bindings between models and templates everything is is mapped to a canonical data and it is a it's a no-brainer to keep your app consistent similarly Amber data also per provide that canonical data store and provides for consistency so inured your data models and also of through its ability to communicate through adapters with servers in many different kinds it provides durability at every data does require
a bit of work but to provide atomicity and isolated user experience on it's it's not but it takes it takes extra code of bit customization to save fork data provide editing in a separate context In persist that data back yeah similarly I a lot of of the aspects of a forgiving user experience require extra work I was thinking about
these challenges the over a year and a half ago at a time when Member data was was a less stable and was had had some of had some engineering challenges which I'm I'm glad to report many of which have been have been solved of but when I was thinking about these problems the what about the basic assumptions of data storage and the clients and the primitives that we use to model that data storage and synchronization with uh with remote sources and so I started
with the basics and with by thinking about sources as equal let disparate containing complex but different shapes of data and obviously in order to get these disparate sources to communicate with each other FIL need common interfaces and a process for those common interfaces to work well together will need to normalize data it will need to be moved between the interfaces in in a normalized fashion that they all the the sources agree upon and because I'm looking at at modeling of a lot of different types of data to be a little more specific I'm talking about perhaps the NAP that uses WebSockets might commit to rest I would also like to provide an offline experience with index DB on and and have a memory source in with which which contains the canonical data that's presented to the user so I'm trying to model all of these complex sources in a single single application and in order to tie them together there's no there's no fixed pattern that for exactly how your you're going to tight different sources of different types together so you need to allow for ad hoc connections between them and the the ad hoc pattern appealed to me most was was the event subscriber now of course resources that might be local or might be remote as as as Amber date is learned on the everything has to be a promise of 5 not if if there's a chance that it might be asynchronous and so if these events it connections could be promise aware that they could communicate this normalized data across common interfaces and it's with these primitives that I developed
for which is not member specific but it's a standalone Java Script library for coordinating access to data sources in keeping their content synchronized word it
has a couple of primary interfaces with 1 is requestable and 1 is transformable any source can implement 1 or both of these the requestable interfaces developer-friendly it provides find methods and cried methods as well as the transformable method the transformable interface provides a single method transform which takes an operation and that operation is
Jason patch data that's a form of normalized data that I arrived at his son patch and provides an operation of path and a value of so they're their operations like add remove replaced the and these other different patches developed to operate against a case document so internal the each source that you have a adjacent document and these patterns can be applied and the patterns of the the the wonderful thing about about having normalize data and I agreed upon schema is that the patterns of will and also return their inverses which can then also be applied to undo a change so in order to
connect the requestable interfaces with each other toward the transformable interfaces with each other but they're different connectors In these connectors as I've discussed a event are event driven and the the events from say if you were to take a look at a synchronous synchronous event handling it's pretty traits pretty straightforward because operate operations half so serially it but it gets more interesting when you get into asynchronous operations which we could be talking about would promote sources say resources sources from or a socket that so these events that are promised aware and so the connectors basically translate the events that contain 2 between sources and sources that want to engage with those events can return a promise and the events that originating events will be resolved until all the promises of the hour that are involved in that in a transaction power result so there are that's the async blocking pattern in which in which sources say yes I wanna be involved in the resolution of an event in the asynch non-blocking pattern and then sources might take a while to resolve but they they're saying I don't want hold the other sources so they don't return a promise of they they receive the event and they go on and perform their actions so it's with with these primitives with that that the transform and requestable connectors and wired together multiple sources of disparate types and the normalized data can flow between them and the promises keep everything in sync whether it's asynchronous or not so that's great from a
theoretical perspective but let's it's not useful without a common library of sources and so far
orbit has a few standard ones the memory source local stored source in adjacent API source which is currently in transition going as as Jason API years 1 . 0 which is hopefully going to be tomorrow and if say here you can believe that this source will be 1 of the 1st implementations of completely compliant the the and In order to normalize the data between resources they need to agree on a schema acts of models relationships and he's no since I met member
kind of I when I talk about orbit number I need to talk about number orbit which is a separate library that should feel
familiar to you if you're an amber data user it has a store that encapsulates and of in-orbit source and that provides both synchronous and asynchronous methods synchronous methods provide direct access to what's in this in the source with all filter methods asynchronous methods to access the requestable interfaces asynchronously and you can't behind the scenes you can connect multiple orbit sources and connectors and and all the data will flow through and back to the store the model is a representation of a particular record in the in the store and you can be the definition of the model informs the schema that's used across orbit just
as in amber Urals drive application state the underlying stamp orbits sources I derive the model state In in amber orbit so if you 1st socket is if a socket connectors if a soccer sources connected to your canonical Amber orbit store then does the changes that are applied in in war that will flow through to your models and your models automatically reflect those changes the so what are the
application patterns that you can use with were beyond and Amber orbit specifically where you can you can
start by developing applications with our client client 1st with no concern for other connectors you can just work within with the number ordered store of Azure application developed you can add pluggable sources so you could connect say the AU local storage source in index DB source to provide different of capacities for locals of for browser-based storage you could synchronize data between a between sockets Sockets source and arrest source in the you could set up different connectors with a bi-directional or unidirectional between them and you can provide editing isolation by just simply for being a store of providing and providing at of any complexity like form that bright thing with that's driven by Wizard that has multiple pages and those edits but done in complete isolation any the applied a discard or discarded and and then that flows back to the canonical store and last but not least be because all the changes are of deterministic staircase on patch changes and every source returns its inverse when it's changes are applied to it those changes and be tracked are deterministically and they can be I'm undone and then multiple levels or reader if you're interested in
orbit and it's getting pretty close to that to us stability by been working really hard the last few weeks I hope to get . com up it's going to be the Jason API workers delayed a few things but the I'm I'm looking to get that up in the next in the next month or so and I feel like it's it's getting close to the point where I wanna put together the the docks and guides tend to make it a lot more you developer-friendly so if you're interested in following the orbit story but please check out orbit JSI on Twitter or piracy and that even if the even if you're not particularly interested in orbit please keep in mind fault tolerance for all of your member applications they figure out there and some some and
Mereologie
Betrag <Mathematik>
Videospiel
Client
Subtraktion
Zahlenbereich
Projektive Ebene
Fehlertoleranz
Prozess <Informatik>
Software
Surjektivität
Nichtlinearer Operator
Programmierumgebung
Normalspannung
Fehlertoleranz
Informationsmodellierung
Prognoseverfahren
Stab
Relationentheorie
Konditionszahl
Dimension 3
Finite-Elemente-Methode
Ordnung <Mathematik>
Steuerwerk
Ereignishorizont
Nichtlinearer Operator
Wellenpaket
Gamecontroller
Physikalisches System
Aggregatzustand
Benutzerbeteiligung
Einheit <Mathematik>
Web-Designer
Bit
Fehlertoleranz
Benutzerbeteiligung
Bit
Computersicherheit
Datenhaltung
Browser
Server
Skript <Programm>
Informationsmodellierung
Front-End <Software>
Gebäude <Mathematik>
Zahlenbereich
Programmierumgebung
Fehlertoleranz
Rechenschieber
Domain-Name
Demo <Programm>
Browser
Kartesische Koordinaten
Physikalisches System
Programmierumgebung
Unabhängigkeitssystem
Browser
Kartesische Koordinaten
Softwaretest
Wellenpaket
Atomarität <Informatik>
Datenhaltung
Kartesische Koordinaten
Ordinalzahl
Widerspruchsfreiheit
Hinterlegungsverfahren <Kryptologie>
Fehlertoleranz
Arithmetisches Mittel
Ordinalzahl
Transaktionsverwaltung
Ordnung <Mathematik>
Charakteristisches Polynom
Transaktionsverwaltung
Subtraktion
Bildschirmmaske
Informationsmodellierung
Transaktionsverwaltung
Zustand
Mathematisierung
Zustand
Zahlenbereich
Widerspruchsfreiheit
App <Programm>
Transaktionsverwaltung
Datenparallelität
Template
Datenparallelität
Mathematisierung
Server
Datenmodell
Partielle Differentiation
Twitter <Softwareplattform>
Framework <Informatik>
Homepage
Transaktionsverwaltung
Bildschirmmaske
Informationsmodellierung
Web-Applikation
Kartesische Koordinaten
Kontextbezogenes System
Design by Contract
Fehlertoleranz
Transaktionsverwaltung
Informationsmodellierung
Twitter <Softwareplattform>
Zahlenbereich
Browser
Mathematisierung
Kartesische Koordinaten
Wort <Informatik>
Schlussregel
Transaktionsverwaltung
Schlussregel
Arithmetisches Mittel
Fehlertoleranz
Prozess <Physik>
Kartesische Koordinaten
Elektronische Publikation
Singularität <Mathematik>
E-Mail
Einfach zusammenhängender Raum
Benutzerfreundlichkeit
Endogene Variable
Datentyp
Server
Kartesische Koordinaten
p-Block
Internetworking
Schnittstelle
Mathematisierung
Dreiecksfreier Graph
Endogene Variable
Server
Aggregatzustand
Schnittstelle
Schnittstelle
App <Programm>
Schnelltaste
Bit
Subtraktion
Template
Datenmodell
Gebäude <Mathematik>
Ordinalzahl
Gibbs-Verteilung
Kontextbezogenes System
Komplex <Algebra>
Widerspruchsfreiheit
Code
Fehlertoleranz
Ordinalzahl
Informationsmodellierung
Minimalgrad
Anpassung <Mathematik>
Server
Speicher <Informatik>
Softwareentwickler
Widerspruchsfreiheit
Relationentheorie
Schnittstelle
Subtraktion
Prozess <Physik>
Kartesische Koordinaten
Synchronisierung
Client
Informationsmodellierung
Datentyp
Mustersprache
Primitive <Informatik>
Speicher <Informatik>
Schnittstelle
Einfach zusammenhängender Raum
Shape <Informatik>
Einfache Genauigkeit
Gibbs-Verteilung
Quellcode
Kontextbezogenes System
Ereignishorizont
Datenfeld
Automatische Indexierung
Festspeicher
Ordnung <Mathematik>
Normalvektor
Umwandlungsenthalpie
Nichtlinearer Operator
Schnittstelle
Applet
Content <Internet>
Patch <Software>
Quellcode
Quellcode
Verschlingung
Binder <Informatik>
Programmbibliothek
Skript <Programm>
Wort <Informatik>
Integraloperator
Programmbibliothek
Schnittstelle
Resultante
Relationentheorie
Mathematisierung
Gruppenoperation
Patch <Software>
Kontextbezogenes System
Synchronisierung
Bildschirmmaske
Multiplikation
Mustersprache
Datentyp
Umkehrung <Mathematik>
Primitive <Informatik>
Integraloperator
Ereignishorizont
Bildauflösung
Leistung <Physik>
Schnittstelle
Nichtlinearer Operator
Transformation <Mathematik>
Quellcode
Ereignishorizont
Patch <Software>
Transaktionsverwaltung
Socket
Normalvektor
Ordnung <Mathematik>
Schlüsselverwaltung
Gruppenoperation
Orbit <Mathematik>
Speicher <Informatik>
Implementierung
Quellcode
ROM <Informatik>
Eins
Quellcode
Informationsmodellierung
Orbit <Mathematik>
Perspektive
Festspeicher
Programmbibliothek
Modelltheorie
Ordnung <Mathematik>
Programmbibliothek
Einfach zusammenhängender Raum
Inverse
Selbstrepräsentation
Datenmodell
Orbit <Mathematik>
Zahlenbereich
Patch <Software>
Quellcode
Synchronisierung
Demoszene <Programmierung>
Datensatz
Informationsmodellierung
Multiplikation
Orbit <Mathematik>
Verschlingung
Programmbibliothek
Speicher <Informatik>
Schnittstelle
Mathematisierung
Datenmodell
Orbit <Mathematik>
Gibbs-Verteilung
Kartesische Koordinaten
Quellcode
Quellcode
Informationsmodellierung
Zustand
Mustersprache
Socket
Speicher <Informatik>
Aggregatzustand
Stabilitätstheorie <Logik>
Punkt
Web-Applikation
Mathematisierung
Zahlenbereich
Kartesische Koordinaten
Komplex <Algebra>
Service provider
Socket-Schnittstelle
Homepage
Fehlertoleranz
Quellcode
Client
Bildschirmmaske
Multiplikation
Rhombus <Mathematik>
Determiniertheit <Informatik>
COM
Elektronischer Programmführer
Speicher <Informatik>
Synchronisierung
Inverse
Softwarepiraterie
Stellenring
Orbit <Mathematik>
Kanalkapazität
Quellcode
Patch <Software>
Orbit <Mathematik>
Twitter <Softwareplattform>
Automatische Indexierung
Client

Metadaten

Formale Metadaten

Titel Fault Tolerant UX
Serientitel Ember Conf 2015
Autor Gebhardt, Dan
Lizenz CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben.
DOI 10.5446/34733
Herausgeber Confreaks, LLC
Erscheinungsjahr 2015
Sprache Englisch

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract The key to building and maintaining users' confidence in long running applications is fault tolerance. Not just a data and connectivity concern - fault tolerance should be considered at every level of your application. A fault tolerant application clearly conveys its state to users throughout its interface, allows users to remain as productive as possible in any particular state, and ideally works behind the scenes to recover from faults. This talk will cover UX patterns and engineering strategies for building fault tolerant Ember.js applications.

Ähnliche Filme

Loading...
Feedback