What an interesting thread. I have been working on an approach to UX/UI for my company and some of the ideas in this thread touch on it.
My neighbor is a control systems guy and he has this crazy train set in his basement that's all rigged with servos and widgets and the whole thing is controlled by a programmable control unit. He tests a lot of his thinking out about various kinds of state and timing problems in this rig. So that got me thinking there is a sort of irony (don't kill me if I used that word wrong here) in the fact that some complicated systems, like a high-density/bandwidth ethernet switch or router, are built by control and real-time systems people.... however, they sort of fail to see that, like Russian dolls, that there is a broader control/real-time loop between the user and the network. And the user is the control. The network is the process or the plant. And within this sphere, there are many other loops between the user(s) and the individual switches/routers/firewalls. In this way, could we describe formally with FSM or Petri Nets, BPM, or SysXML, or whatever, this broader view where the user is part of the system and we must account for the psychology of the user? We know they will make take shortcuts and make mistakes and introduce vulnerabilities when the system is too hard to use. The consequence of this is nearly impossible to predict with complicated systems. Well, for the user. But not necessarily for the adderall-riddled 19 year old trying to break into your systems. What I have found is that, especially for complex systems, that the more stuff that is packed into the software the buggier it becomes and the less usable it becomes. In fact, it even becomes *less useful.* Where we are today is that for some systems, we just don't have the science, the math, or the money to put a "go" button on it and completely encapsulate the problem to the point where user intervention isn't necessary. My mother can't stand up a data center network the way she dials a phone or drives a car. So if user intervention is required, and we want to take into account how the user thinks... then that would be an interface where the user drives the workflow naturally. Naturally is a loaded word, so what does that mean? Well, much to my employer's frustration, I took a 3 month detour into the psychology of problem solving and I came up with a model of how people navigate a complex problem space. Which you can read here <http://www.plexxi.com/2014/08/network-engineer>. The article is written in the context of network engineers, but ignore the neteng-ish language. The idea is that there is a "referential space" that people navigate abstractly (in their minds) and this space is a sort of landscape whose features are the data, relationships, theories, laws, specifications, methodologies, processes, etc that govern the complex space they specialize in. The most important feature is "data" which will be of numerous types. These data blobs are all interconnected. As you navigate your space (solving a problem, completing a task, modeling something, etc), you move from data point to data point in this space following the relationships that exist according to the rules that govern it. Don't get hung up on the word data, each node is really a combination of data and associated logic that will guide you to the next node or nodes. When someone is working in their specialized area of expertise, they start with a node. A blob of data/logic. What node they start with and the direction they go in, especially in a complex space, is highly situational. So traditional statically structured interfaces (and static, predetermined automated workflows) are actually completely antithetical to user workflow, much less the insecurity and difficulty in use it brings. What if the interface allowed the user to enter their space where ever they wish? And from that point they can move to the next as they would anyway in their mind? In traditional systems, moving from one node to the next means backing out of a set of dialogues and digging another dialogue rabbit hole, or moving from one syntactically different textual stanza to another. The cognitive friction is obscene. This should actually reduce the complexity of the front end, as it now becomes a sort of collection of discrete objects and tasks (discrete meaning more easily defined and tested) which are linked together in an organic workflow as the user cognitively moves through referential space. In short, a lot less code, logic, hierarchy, parsing, meta-class fuckery, and other stuff that goes into making the weird machine. I think, but I could be totally bullshitting myself. We'll see. Sorry for the TL;DR Derick On Tue, Jul 9, 2013 at 4:23 PM, Nils Dagsson Moskopp < n...@dieweltistgarnichtso.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > "Meredith L. Patterson" <clonea...@gmail.com> schrieb am Tue, 09 Jul > 2013 18:43:42 +0200: > > > State machine formalisations of interaction patterns? I'm entirely in > > favour of this. > > > > Is he on this list? If not, mind inviting him? > > I already sent him a message regarding LANGSEC and this mailing list. > > - -- > Nils Dagsson Moskopp // erlehmann > <http://dieweltistgarnichtso.net> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iF4EAREIAAYFAlHcf1EACgkQZGjbY/Ag5QlW2gD9GbPnCRzhPpe0ncJA9Pwx7Yoa > NLsF1WSD6r1JjkP+slMA/Av4v0/b+B8b2YM1O378D52HEyD32ZhEyAFV7z6ukdCN > =yXmU > -----END PGP SIGNATURE----- > _______________________________________________ > langsec-discuss mailing list > langsec-discuss@mail.langsec.org > https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss >
_______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
