I had this in my outbox for a couple of days now, hoping for someone else to add his/her voice to the discussion and hesitant to comment the situation from a more abstract perspective (not sure whether the proposal is actually off the table now...). To me, this looks like a potential deadlock: Obviously, Judy is not happy with some of the UI suggestions that come with new features and functionalities. The best she can do as the only UX/UI expert we have is to point to potential problems in the UI and UX and provide alternatives (not in code though...). These, however, might not be what the committer had in mind. And worse, as Judy is not a developer, the committer would have to implement them (this is how I understand the situation) regardless. Now, unless the committer is willing to do so, how to deal with that situation? Ideally, this would be discussed at length, with the parties concerned coming to a compromise. The reality though is that there seems to be no time for these discussions. Would a style guide help to solve these issues without these lengthy discussions? I doubt whether that is the case, not only for the reasons that Judy mentions, but also because the guide couldn't be so comprehensive as to solve all future problems (it still might be a good idea to circumvent smaller issues, if developer express interest in having such a guide). And, there are of course different perspectives on who the user is, what he/she would like to do and what we can expect from him/her. Impossible to cover in a guide, impossible to implement in one product. Impossible to solve therefore?
I think the only solution we have is to let go of the idea(l) that we can further develop Matterhorn with a comprehensive UX/UI perspective. If there are no resources around this (or the relevant resources "choose" not to go with what would be ideal from a UX/UI perspective), we probably have to accept this. The alternative is to either frustrate committers by blocking their features or to prevent features from being implemented because they don't follow the rules, which cannot be good for the product (nor the committers). Does this mean that committers can do whatever they choose to? Certainly not, not only do we expect them to announce any features with impact on the UI way in advance, but we also make the discuss these changes with others. And there are of course other committers to veto them. But these vetoes have to come with an alternative at some stage and this alternative has to come with resources attached at some stage. At least that's my understanding. If you don't have resources to commit (or contribute), then the only way to influence the further development of Matterhorn is to convince committers of what you have in mind. If you fail to do so, then you should accept that the project is driven by those who have resources, even if you don't like the way they are being spent. It's not the only area where we have to live with that kind of reality. O >-----Ursprüngliche Nachricht----- >Von: [email protected] [mailto:matterhorn- >[email protected]] Im Auftrag von Judy Stern >Gesendet: Dienstag, 28. Februar 2012 21:28 >An: Opencast Matterhorn >Betreff: Re: [Opencast Matterhorn] style guide (was: Enabling the Episode >service >for 1.3 by default #proposal > >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] >_______________________________________________
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
