Thanks for the clarification, Sean. Since you mentioned the subject, I thought it may be interesting to present our ideas or principles regarding interaction design 'for languages'. My big three would be:
1) The intuitions users develop should be formally justifiable, even though most people don't know the justification. The intuitions should also be valid at all scales, so they can be applied uniformly. The only way I know to achieve this principle is to focus on compositional properties. Compositional properties are the only set we can reason about without detailed knowledge of implementations, and are thus valid at large scales. The really important stuff (like security, safety, process control) should always be compositional. 2) Ka-Ping Yee's principles for "Secure Interaction Design" are excellent. These focus on keeping users continuously aware of what authorities they possess, where they come from, which authorities they have granted, universal revocability (no 'grandfather law' authorities), and controlling against accidental grants (i.e. path of least resistance is least authority). These principles guided my design of RDP: capability security model addresses most of Yee's principles, while continuous reactive dataflows help with both revocability and visibility. 3) Stan Lee's principle: power is coupled with responsibility. A language or UI should be able to enforce that certain responsibilities are discharged before it proceeds. E.g. if we start a handshake, we must finish it; if we open a connection, we must process it; if we make a promise, we must fulfill it. Most programming languages fail badly here. It easy to drop these things halfway through; i.e. there is rarely an equivalent of 'form validation' at the behavior layer. Use of substructural (affine, relevant, linear) types, however, is very useful for expressing and enforcing responsibilities. Thomas Green's cognitive dimensions of notations don't make very good 'principles'. They are like metrics that don't really offer any guidance. If I focused on them, I imagine I would be left blindly tweaking and measuring. But I believe my principles will lead to systems that score well for everything except "closeness of mapping". (Composition will too often take precedence over closeness to any specific problem domain. However, metaprogramming might support closer mappings.) Composition and consistency do seem related, as do 'role' with authorities and responsibilities. My recent designs also involve integrating the user-model with the program (see earlier e-mail). That happened more by accident than by principle. But it seems powerful, and I think there may be a few principles to shake from it. I'm interested in hearing the big ideas from other people. My principles are insufficient to guide many aspects of API design, so I've been looking for a few more. Best, Dave On Thu, Aug 29, 2013 at 4:18 PM, Sean McDirmid <smcd...@microsoft.com>wrote: > I don’t think the conference in Amsterdam is related to LIXD, it is just > about interaction design in general. “Languages of” interaction design is > their topic, not interaction design “for languages” J.**** > > ** ** > > LIXD was a lot of fun, though I’m not sure I agree with Blackwell’s ideas > about interaction design (heavily based on user studies/surveys and > Greene’s cognitive dimensions), especially since I don’t see as much of a > connection between theory and practice. Design to me remains somewhat of a > black art that is mostly informed by experience and practice. We had this > discussion before a bit on LtU, where my position was user studies actually > remain a small part of design given their expense and limited insights. ** > ** > > ** ** > > *From:* augmented-programm...@googlegroups.com [mailto: > augmented-programm...@googlegroups.com] *On Behalf Of *David Barbour > *Sent:* Friday, August 30, 2013 6:58 AM > *To:* augmented-programm...@googlegroups.com > *Subject:* Re: Programmer Models integrating Program and IDE**** > > ** ** > > Hey, a bunch of people I know went there! Next one's in Amsterdam.**** > > ** ** > > http://interaction14.ixda.org/**** > > ** ** > > Might be fun. But I can't afford that travel. And I hate travel. **** > > ** ** > > I'll probably try to make it to OOPSLA/Onward! in 2014 though.**** > > ** ** > > Best,**** > > ** ** > > Dave**** > > ** ** > > ** ** > > On Thu, Aug 29, 2013 at 1:14 AM, Roly Perera <rper...@inf.ed.ac.uk> wrote: > **** > > You might have enjoyed this workshop:**** > > ** ** > > http://www.lorentzcenter.nl/lc/web/2013/563/info.php3?wsid=563**** > > ** ** > > I wasn't able to attend, but the overall focus fits nicely with your idea. > **** > > ** ** > > (Slogans I've used in the past for similar notions: "interaction as > meta-programming", or "first-class interaction". It'll probably be a few > years before I'm able to come back to it, though.)**** > > ** ** > > Roly**** > > ** ** > > On 28 August 2013 23:35, David Barbour <dmbarb...@gmail.com> wrote:**** > > I understand 'user modeling' [1] to broadly address long-term details > (e.g. user preferences and settings), mid-term details (goals, tasks, > workflow), and short-term details (focus, attention, clipboards and > cursors, conversational context, history). The unifying principle is that > we have more context to make smart decisions, to make systems behave in > ways their users expect. This is a form of context sensitivity, where the > user is explicitly part of the context.**** > > ** ** > > Programming can be understood as a form of user interface. But, > historically, user modeling (in this case 'programmer modeling') has been > kept carefully separate from the program itself; instead, it is instead > part of an Integrated Development Environment (IDE)**** > > ** ** > > *Hypothesis:* the separation of user-model from program has hindered both > programmers and the art of programming. There are several reasons for this: > **** > > ** ** > > 1) Our IDEs are not sufficiently smart. The context IDEs keep is > heuristic, fragile, and can be trusted with only the simplest of tasks. ** > ** > > 2) Poor integration with the IDE and visual environments: it is difficult > to assign formal meaning to gestures and programmer actions.**** > > 3) Programmer-layer goals, tasks, and workflows are generally opaque to > the IDE, the programs and the type system. **** > > 4) Our code must be explicit and verbose about many interactions that > could be implicit if we tracked user context. **** > > 5) Programmers cannot easily adjust their environment or language to know > what they mean, and act as they expect. **** > > ** ** > > I believe we can do much better. I'll next provide a little background > about how this belief came to be, then what I'm envisioning.**** > > ** ** > > *Background***** > > ** ** > > Recently, I started developing a tacit representation for an arrowized > reactive programming model. Arrows provide a relatively rigid 'structure' > to the program. In the tacit representation, this structure was represented > as a stack consisting of a mix of compile-time values (text, numbers, > blocks) and runtime signals (e.g. mouse position). Essentially, I can give > the stack a 'static type', but I still used FORTH-like idioms to "roll" and > "pick" items from the stack as though it were a dynamic structure. With > just a little static introspection, I could even model `7 pick` as copying > the seventh element of the stack to the top of the stack.**** > > ** ** > > But I didn't like this single stack environment. It felt cramped. **** > > ** ** > > Often, I desire to decompose a problem into multiple concurrent tasks or > workflows. And when I do so, I must occasionally integrate intermediate > results, which can involve some complex scattering and gathering > operations. On a single stack, this integration is terribly painful: it > involves rolling or copying intermediate signals and values upwards or > downwards, with relative positions that are difficult to remember. > Conclusion: a single stack is good only for a single, sequential task - a > single pipeline, in a dataflow model.**** > > ** ** > > But then I realized: I'm not limited to modeling a stack. A stack is just > one possible way of organizing and conceptualizing the 'type' of the arrow. > I can model any environment I please! (I'm being serious. With the same > level of introspection needed for `7 pick`, I could model a MUD, MOO, or > interactive fiction in the type system.) After experimenting with tree > zippers [2] or a list of anonymous stacks [3], I'm kind of (hopefully) > settling on an easy-to-use environment [4] that consists of:**** > > ** ** > > * current stack**** > > * hand**** > > * current stack name**** > > * list of named stacks**** > > ** ** > > The current stack serves the traditional role. The 'hand' enables > developers to 'take' and 'put' objects (and juggle a few of them, like > 'roll' except for the hand) - it's really convenient even for operating on > a single stack, and also helps carry items between stacks (implicit data > plumbing). The list of named stacks is achieved using compile-time > introspection (~type matching for different stack names) and is very > flexible: **** > > ** ** > > * different stacks for different tasks; ability to navigate to a different > stack (goto)**** > > * programmers can 'load' and 'store' from a stack remotely (treat it like > a variable or register)**** > > * programmers can use named stacks to record preferences and configuration > options**** > > * programmers can use named stacks to store dynamic libraries of code (as > blocks)**** > > ** ** > > As I developed this rich environment, it occurred to me that I had > essentially integrated a user-model with the program itself. Actually, my > first thought was closer to "hey, I'm modeling a character in a game! Go go > Data Plumber!" The programmer is manipulating an avatar, navigating from > task to task and stack to stack. The programmer has items in hand, plus a > potential inventory (e.g. an "inventory" stack). To push metaphors a bit: I > can model keyrings full of sealer/unsealer pairs, locked rooms with sealed > values, unique 'artifacts' and 'puzzles' in the form of affine and relevant > types [5], quests goals in the form of fractional types (representing > futures/promises) [6], and 'spellbooks' in the form of static capabilities > [7]. But in retrospect, the relationship to user modeling seems obvious, > and I can put all this more boring terms of modeling goals, tasks, > requirements, workflows, user extensions and preferences, etc..**** > > ** ** > > All the normal abstraction principles apply, and developers will quickly > build higher-level procedures for higher-level thinking, and build > libraries of reusable abstractions. An arrowized model also supports > 'partial application' (the `first` primitive) so we can precisely control > how much of this context is made available to a subprogram. **** > > ** ** > > In the type system, the current stack, hand, stack name, and list of named > stacks is represented as a simple anonymous product type:**** > > ** ** > > (cs * (h * (csn * lns)))**** > > ** ** > > Every non-trivial action the programmer performs will manipulate the > deeper 'type' of this environment. I.e. it's extremely heterogeneous, and > very mutable (albeit in a "pure functional" way, from an outside > perspective). The environment type is complicated and mutable; short term > I'll be okay, but long term I expect I'll need something to aide my memory. > Fortunately, the IDE can help.**** > > ** ** > > *Vision***** > > ** ** > > An IDE can *render* the types in the environment, dedicating more space > and detail to the types near me. Usefully, I can even animate progressions, > easily show the environment reaches a particular state - or basically a > replay of the programmer actions. With a few idioms (e.g. a "how-to-render" > stack, or integration primitives), developers could provide a great deal of > control over how things are rendered.**** > > ** ** > > IDE integration can also cover interaction.**** > > ** ** > > When users focus on a stack in the IDE, it corresponds to navigation code > being added to the program. When a user selects an object, the appropriate > code is injected to copy or take it. When a user opens a menu, the > available options correspond to macros that will be literally added to the > program. (Also, a menu might be extensible from within the program based on > the contents of an "ext-menu" stack.) Undo would be trivially integrated > and would have real meaning. **** > > ** ** > > It isn't a big step from here, to programming with a gamepad, or in an > AR/VR environment. (Nor are we a big step from building an interactive > fiction in the type system. :)**** > > ** ** > > An IDE could still help developers in the traditional ways: provide > context-sensitive suggestions based on the current 'type' of the > environment, provide 'cleaning' operations that reorganize the contents of > a stack and eliminate unnecessary copies, provide 'refactoring' support > that analyze block-constructor code for similarities, etc.. In addition, an > IDE could be rewriting the history, optimizing it - e.g. eliminating > unnecessary navigation or sequential `take put` operations. (This isn't > strictly necessary; pure data plumbing can be trivially optimized away at > compile-time. However a faster compile-time is also nice.) Rewrites could > also be the basis for building gesture macros. Of course, the model I > developed was meant primarily for signal manipulation - e.g. a signal might > be "mouse position". I think I'd mostly be operating at another layer of > indirection, for an IDE - where the 'signals' contain static building > blocks of code that will manipulate signals on my behalf. **** > > ** ** > > Use of a programmer model within the program is a powerful, uniform basis > for rich, extensible development environments that can eventually subsume > other UI models. Essentially, all user-interaction is subsumed as > programming, all GUIs are modeled as types, and with a decent type system > this can be powerful indeed.**** > > ** ** > > (Note: I suspect that multi-programmer environments are also feasible, > i.e. with multiple programmer models. However, I would tend to model > multiple programmers as each having their own environment within a larger > system, through which they can share some capabilities or libraries.)**** > > ** ** > > Best,**** > > ** ** > > Dave**** > > ** ** > > [1] http://en.wikipedia.org/wiki/User_modeling**** > > [2] > http://awelonblue.wordpress.com/2013/08/12/tacit-programming-with-arrows-hands-and-zippers/ > **** > > [3] > http://awelonblue.wordpress.com/2013/08/14/multi-stack-environment-in-awelon/ > **** > > [4] > http://awelonblue.wordpress.com/2013/08/26/multi-stack-environment-part-2/ > **** > > [5] http://en.wikipedia.org/wiki/Substructural_type_system**** > > [6] > http://awelonblue.wordpress.com/2013/08/24/pipes-that-flow-in-both-directions/ > **** > > [7] http://en.wikipedia.org/wiki/Capability-based_security**** > > ** ** > > ** ** > > -- > You received this message because you are subscribed to the Google Groups > "Augmented Programming" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to augmented-programming+unsubscr...@googlegroups.com. > To post to this group, send email to > augmented-programm...@googlegroups.com. > Visit this group at http://groups.google.com/group/augmented-programming. > For more options, visit https://groups.google.com/groups/opt_out.**** > > ** ** > > -- > You received this message because you are subscribed to the Google Groups > "Augmented Programming" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to augmented-programming+unsubscr...@googlegroups.com. > To post to this group, send email to > augmented-programm...@googlegroups.com. > Visit this group at http://groups.google.com/group/augmented-programming. > For more options, visit https://groups.google.com/groups/opt_out.**** > > ** ** > > -- > You received this message because you are subscribed to the Google Groups > "Augmented Programming" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to augmented-programming+unsubscr...@googlegroups.com. > To post to this group, send email to > augmented-programm...@googlegroups.com. > Visit this group at http://groups.google.com/group/augmented-programming. > For more options, visit https://groups.google.com/groups/opt_out.**** > > -- > You received this message because you are subscribed to the Google Groups > "Augmented Programming" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to augmented-programming+unsubscr...@googlegroups.com. > To post to this group, send email to > augmented-programm...@googlegroups.com. > Visit this group at http://groups.google.com/group/augmented-programming. > For more options, visit https://groups.google.com/groups/opt_out. >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
