Wanted to get back to Rüdiger's comments. (Would be good if others had input,
too.)
On Feb 24, 2012, at 11:05 AM, Ruediger Rolf wrote:
> I would say we need a (style-)guide that gives advice to developers what they
> have to regard that their code will be accepted. For sure it should be
> possible, even then, to refuse a new feature as a group if we have good
> reasons, but it should not be possible for minor reasons that should be
> covered by the guide.
Agreed that we a style guide would be helpful. Questions for me are what it
should include on the UX side of things AND (more importantly) what will
developers actually use/pay attention to? If anyone has thoughts (or examples
from other projects), please respond!
It's also not a panacea, because sometimes the usability "mistakes" developers
make are not a matter of an "incorrect" style (something that can be looked up
easily and is black&white), but rather not thinking thru the implications of
who the user is (e.g. how much can you really expect them to know about the
Matterhorn architecture) and what the full context of their use is (e.g. what
else are they doing at the time, what tasks have they done or still need to
do). And, of course, there are always issues that come up for which nobody (not
even an expert) could have foreseen. Which brings us to your next comment...
> In general an UX expert should be involved in the development of the UI for a
> new feature, but you know best probably that this is not possible because of
> limited resources.
Involving UX experts early at some level is important but I think it's going to
need to be more agile ("conversation" & iteration) than waterfall (where UX
does lots of research, creates complete designs before developers start).
I agree also that resources are limited, though I'd say we have an even greater
shortage of UI developers than UX experts: We have a serious backlog of UI
fixes that are needed for which we already have designs (or at least a first
iteration of designs) but don't have anyone to implement them. (Osnabrück team
completely rocks in terms of doing this kind of work, but we need to clone
them!)
Not clear, also, that UX involvement always helps. I got "involved" months ago
for the UI of the episode service but the UI stayed pretty much as originally
developed, due primarily (I believe) to time constraints. If developers are in
a rush to get something "done", they sometimes ignore usability feedback. (And,
yes, style guides will help some to get things done *right* in the first place,
but a willingness to make changes when new, unforeseen usability issues arise
is also key.)
Judy
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
