Re: [abfab] I-D Action: draft-ietf-abfab-usability-ui-considerations-00.txt

[Rhys Smith <[e-mail]>]

First, thanks to everyone for the feedback. I’ll deal with all the smaller comments.

The one major comment is Scott’s, and Dave’s response. Can discuss in the WG meeting later this morning. But my comments back would be -

> On 3/4/2014 3:03 AM, Cantor, Scott wrote:
>> Big question: how much to do with ABFAB does this really have, vs.
>> essentially any really usable client UI for a non-trivial GSS-API
>> mechanism? More to the point, is this open to contributions from other
>> perspectives to broaden the document's applicability? I got the sense that
>> other than mentioning an NAI a fair bit, there's not much specific to
>> ABFAB here.

My thought here is that yes, very little of it is ABFAB specific in that sense. With relatively few modifications it could probably also provide relevant guidance for other GSS-API mechs that would use an identity selector-like thing.



On 7 Mar 2014, at 07:17, Dave Crocker <[e-mail]> wrote:
> […]
> The draft offers no citations for HCI, UX, UCD or Usec research or experience.  That's an indication that it has the best of intentions, but lacks both theoretical and empirical underpinnings, for a topic that is acknowledged by its leaders to require both, when doing design.

Short response - the draft currently is not really about recommending design solutions, it’s more about helping define the problem and throwing in a few recommendations that we currently think look like best practice.

Longer respones - from our experience with UIs in the world of SAML federations, there are two major things you can do to improve the UX: 1) Improve the UI directly using established UX research (obviously), but also 2) Consistency. To some extent, it doesn’t *matter* how good or bad the UI is as long as it’s consistent across implementations.

This paper is currently more addressing 2) than 1). It’s simply an attempt to pull together the scope of the problem of designing a UI based on the experience we’ve had in designing such a beast for Moonshot (our ABFAB implementation). The aim is that others who might come along and tread the same path can understand the scope of the problem and our thought processes when producing an implementation, in the hope that end users might benefit from having some commonality between implementations. 

Don’t get me wrong, I’m not saying that the other type of work is not valuable; far from it. It’s just that’s a design specification document is somewhat of a different doc from the considerations doc in its current form and would require input  from people more versed in the current state of the art in UX design that me and the current reviewers we’ve had.

Thinking through this, a few changes could probably be made to make this a bit clearer - removing all normative keywords, for example, so that we’re not forcing design choices on implementors which may later prove to be incorrect, wrong, or just plain stupid in hindsight…

Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet - the UK's research and education network

email: [e-mail] / [e-mail]
GPG: 0x4638C985