Responses to questions from Mary Hodder about Design Patterns, the Human Trust Experience and Privacy
Thank you Mary for this thoughtful response. I will be replying over the next several days in a number of ways.
ARR: In Bold
To begin—
Why is Identity_Design_Patterns and related material on its own section on the wiki and not under “User Experience Approaches” or something like that? It makes it seem that there is agreement that this is the right approach and language. I don’t think that has been ventilated. I don’t think there is anything intrinsically more valuable from the individual human user’s perspective about a design pattern approach. It could be but it could not be as well. There are however many privacy and other human rights and human dignity issues involved in extracting human behavioral characteristic from data sets including analyzing those behaviors and making design decisions based on this approach. The larger the dataset(s), while not linear necessarily, the more specificity is achieved in identifying individual human user’s living behavior. Unfortunately we will have to do the hard work of sorting this out probably by context. The context of a natural disaster emergency have very difference requirements than commercial settings where organizations want an individual to buy something. For this reason the ethical considerations need to lead the discussion. I might add that from my experience with Christopher Alexander much of his inspiration for his Pattern Language was to empower individual humans and communities to build their own housing solutions and not have to depend on architects. In our current Identity setting we are not teaching/empowering individuals to express their own requirement but extracting and perhaps modifying behavior.
More comments interleaved below.
From: Userexp_wg [mailto:userexp_wg-bounces@idecosystem.org] On Behalf Of M a r y H o d d e r
Sent: Tuesday, September 23, 2014 6:41 PM
To: userexp_wg@idecosystem.org
Subject: [Userexp_wg] Design Patterns question
Hi All,
In our meeting today, we discussed Design Patterns, generally and specifically (a bit) that Tom has worked on for our group.
They are located on the UXC wiki and here is a specific Design Pattern on Identity:
https://www.idecosystem.org/wiki/Identity_Design_Patterns
I will be adding comments on the Discussion pages on the Wiki as well.
You can find more (there are several) by searching for “pattern” in the wiki search box.
The purpose of Design Patterns or Anti-Patterns is to show a positive or negative pattern of activity that is useful or not useful.
What is a positive or negative pattern of activity? Who decides this? What is useful or not useful? From whose perspective and to what ends? Without answering these questions there is no ethical frame of reference or context.
We sent some time today addressing Ann’s questions and issues around Design Patterns as a category of work
for IDESG, as well as her specific concern about data collection and privacy issues to do with Design Patterns.
My concern is not merely data collection as I have tried to begin to amplify here. But I do think it is an important question to ask who does a pattern of activity belong to? The individual human that generated/created the pattern of activity? A “pattern of activity” tends to make invisible how that pattern of activity was obtained. Obtaining a pattern of activity could also be described surveillance.
Ann, I would invite you to discuss this in email with the group as I have not likely fleshed out your concerns completely.
But I will also say that during the meeting, I couldn’t see how a Design Pattern would involve specific data collection
that would cause a specific privacy violation. I can see that if a vendor or provider used a design pattern, that in their specific
implementation, they would likely collect identifying data about individuals. But the Design Patterns aren’t really designed to manage that.
Doesn’t that depend on the implementation? There is no out of the box guarantee.
Instead, there are places to mitigate this potential problem: 1. for our purposes, a UXC-made Design Pattern will go through a Privacy Committee review.
The role of the Privacy Committee and the Privacy Committee Liaison is to note privacy challenges as the work product is being developed and work to modify the work product to eliminate the privacy challenge before it goes through a Privacy Review.
2. Vendors or providers that want to do something that IDESG would certify, or allow as
a standard, or allow to use a Trustmark, would, if they didn’t protect individual privacy, not pass the Privacy Committee’s
reviews because they wouldn’t comply with the NSTIC requirements.
This is part of the problem I brought up about the complexity of the requirements and interactions including within the Functional Model and “Trustmarks”. There are so many steps and so many processes so many levels of expertise needed to track and evaluate all the moving parts that clarity as to trustworthiness is extremely difficult and more importantly impractical. If someone wanted to create a system where the parts most especially individual human users were to make judgments about trustworthiness someone would not go about it this way! It is dangerous in my view to conclude that IDESG certifications, privacy reviews and standards will solve this problem. It may and it may not. It may for a time and then fail. The important consideration is how much people care about the system they are creating and how much agreement there is about the purposes it should serve.
Our job here is to focus on usability, and usability of privacy issues if necessary. But the Privacy Committee is first responsible for that.
Does that make sense?
They are interdependent and more so in ways that some other working areas may not be.
In my view, Design Patterns are a very useful way to communicate a pattern of activity we would like to see vendors or providers follow,
outside of other concerns like Privacy, Security or Standards, for example.
You may be right about that. However I don’t know that the design patterns so far listed do that. Still I have been trying to get a recording of your session at the Plenary so I can review it. It may be possible to co-create such a pattern.
Lastly, you were concerned about whether Design Patterns were a good fit for UXC to focus on for fulfilling the NSTIC requirements
and since I use them a lot in my other work, I do find them very useful. Others here do as well.
As I mentioned I need to understand what is meant by useful. And how that is measured. I think that discussion could bring a lot of clarity.
Can you elaborate on what the issue is, so that we can understand your concerns?
Or, if you’d like, we can translate the UXC Guidelines doc we have just had the Chairs group looking at onto our wiki,
and try to suss through the options and hierarchy of work possibilities there?
Not sure I understand the choices here. I am planning to comment and provide input on the UXC Guideline doc.
I do want to address your concerns, but also want to keep the group moving, so if we could work through this in the next couple
of days here in email, and then resume our agenda right where we left off, on Tuesday, that would be very helpful.
I don’t think a couple of days is adequate although I do agree that we need to continue to make progress. It has already been a couple of days and I am just now getting to this…to be sure it is not for lack of effort.
Regards,
Ann Racuya-Robbins
Thank you,
Mary