[WG: Accessibility] [DG: User Experience] UX review process ?
Eli Cochran
eli at media.berkeley.edu
Fri May 28 12:17:31 PDT 2010
I think that Ian has really hit on something that I've been wondering about for a while.
But as I reread Ian's original question, I'm not really sure who's being asked and what's being asked for, UX review, technical review, something else?
So... and I don't intend to sound critical or snarky:
- What are the artifacts that require feedback at this time?
- What level of feedback is required? (What do you need to know?)
And more specifically, at this point in the design and development of Sakai 3, who is being asked for feedback? In terms of review are you asking the general Sakai community, the more specific Sakai UX community, or the very specific and immediate Sakai 3 R&D team?
I think that there are a lot of folks in the Sakai community who would, could and *should* give feedback on the designs. But given the current process, or lack there of, I suspect that general feedback from the greater community would be disruptive and slow down the process, or lack there of.
But I hope that as we move towards a larger project with contributions from a greater number of institutions, we find clarity about what feedback looks like, who it's for, who does it, and how it's done. (In a way that still maintains a high level of development velocity.)
I'm glad that we're talking about it.
Thanks,
Eli
On May 27, 2010, at 4:36 AM, Ian Boston wrote:
> Hi,
>
> Ok that make sense, thanks. Here are some observations, please don't read anything as criticism, I am learning how to make this work as its not a development process I have used before.
>
> As it stands, I think the process, mechanism, "howto" (whatever we want to call it) might want to actively involve the people doing the back end sooner to avoid ending up in a position where the cost of implementation is beyond what the project can afford. At the moment there is almost no contact in the UX design process, and none until step 5. Consequently the 2 specs I have seen (Spaces and Dynamic User Profile) are disconnected with what comes naturally at the back end, which just makes them cost more and take longer to implement.
>
> At the moment if feels like balancing a long pole on my head standing at the bottom of a deep dark hole.
>
> Ian
>
> BTW, I think 6 and 7 are probably in the wrong order if a meaningful scope is needed. I realised last night that we are still struggling to finalise the spec for Dynamic User Profile and have probably used up all the implementation time scoped to do it. (its not in the 0.5 release).
>
>
> On 27 May 2010, at 10:59, Oszkar Nagy wrote:
>
>> I don't think there is a crystalized process for this yet, and since
>> designs only just started to flow constantly we have no documentation
>> of the process either.
>>
>> So far we have been doing roughly the following, which is true for our
>> local (Cambridge and at some degree NYU) team:
>>
>> 1. signed off UX wireframes are published
>> 2. short period to understand designs
>> 3. initial UI dev - UX design meeting where we raise technical issues
>> and ask for clarifications
>> 4. UX wireframe clean up / annotation
>> 5. UI/back-end dev discussion identifying tech and back-end service
>> needs
>> 6. JIRA ticket is created for implementation and scoped for a release
>> based on available devs
>> 7. Specs/feature requests are written
>> 8. implementation
>>
>> Now as for the factors you mentioned in deciding what is possible or
>> not:
>> So far there were only a handful of occasions where we had to
>> categorically say no from a technical point of view, and we always
>> tried to treat wireframes as a minimum requirement, putting trust into
>> the design itself, the user needs and research behind it. Time and
>> available development resources were the primary factors in scoping a
>> particular implementation JIRA, and lately the only time constraint
>> was the summer pilot deployment. If we would treat this differently
>> (or more realistically) we would introduce yet another set of walls
>> into an already hard and fragile process, which has enough blockers
>> already. Corners will probably need to be cut anyway, but IMHO rather
>> have those by necessity rather than creating them upfront.
>>
>> On how accessibility WG can tie into this process:
>> I agree that the WG should actively take part sooner rather than
>> later. Having accessibility feedback and identifying blocker issues in
>> the wireframes prior to implementation would be good, and it's one of
>> the reasons we publish everything on JIRA, and the whole UX wireframe
>> mock-up is (has been) available in public Sakai SVN repo ( https://source.sakaiproject.org/contrib/sakai3ux/trunk/Summer_Prototype/index.html
>> ).
>>
>> Oszkar
>>
>> On 26 May 2010, at 19:19, Richwine, Brian L wrote:
>>
>>> Hi,
>>>
>>> I'm curious about this too.
>>>
>>> When would be a good point in the process for the Accessibility
>>> Working Group to look at Sakai 3? Is there a library of UI
>>> components being developed for Sakai 3 we can look at? We have been
>>> exploring the Sakai 3 server at http://3akai.sakaiproject.org/dev/index.html
>>> , and believe there must a better process for us to be of help than
>>> simply poking around and writing Jira tickets on what we find.
>>>
>>> We are working on creating a short list of Sakai specific practical
>>> accessibility practices, which should be available in a month or two
>>> to be added to the Sakai 3 UX Dev Guidelines. We'd love it if
>>> designers and developers think of the accessibility WG as a resource
>>> that can be turned to for quick accessibility consultations on
>>> designs, and we'd love it if there was a more formal place in the
>>> process where we are notified of designs that we can evaluate and
>>> comment on.
>>>
>>> The accessibility working group's traditional role in the Sakai
>>> release process of performing an accessibility review comes rather
>>> late in the development process and usually limits our effectiveness
>>> to only addressing the simplest of fixes.
>>>
>>> -Brian
>>>
>>> -----Original Message-----
>>> From: sakai-ux-bounces at collab.sakaiproject.org [mailto:sakai-ux-bounces at collab.sakaiproject.org
>>> ] On Behalf Of Ian Boston
>>> Sent: Wednesday, May 26, 2010 1:56 PM
>>> To: Nakamura List; Sakai UX
>>> Subject: [DG: User Experience] UX review process ?
>>>
>>> Hi,
>>> I would like to know what the process is for reviewing the proposed
>>> functionality in the UX wireframes. (Is it documented anywhere?)
>>> The reason I ask is, once a UX wireframe has been signed off, how do
>>> we decide what is possible and what needs re-work to make it possible?
>>>
>>> Factors that might influence what is possible are:
>>> Available time before release.
>>> Number of developers to implement.
>>> Technology already adopted.
>>> Available technology.
>>> Technology we might be able to invent.
>>>
>>> Anything is possible with enough time and money, but we don't have
>>> either and there are some things I can see that could need both.
>>> Ian
>>>
>>> _______________________________________________
>>> sakai-ux mailing list
>>> sakai-ux at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>
>>> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe at collab.sakaiproject.org
>>> with a subject of "unsubscribe"
>>> _______________________________________________
>>> sakai-ux mailing list
>>> sakai-ux at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>
>>> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe at collab.sakaiproject.org
>>> with a subject of "unsubscribe"
>>
>> _______________________________________________
>> sakai-ux mailing list
>> sakai-ux at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>
>> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
> _______________________________________________
> sakai-ux mailing list
> sakai-ux at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
. . . . . . . . . . . . . . . . . . .
Eli Cochran
manager of user experience design
ETS, UC Berkeley
"The opportunity lost by increasing the amount of blank space is gained back with enhanced attention to what remains."
- John Maeda
More information about the accessibility
mailing list