Hi, > 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 agree that I don't think a style guide can be written to solve all of these situations. Might still be useful to have a style guide, but for the Episode service sized questions I'm not sure that would cover it. We have two issues: 1. If UX and Developer agree on the future goal of the UX, who will build it? Often the Developer of the feature is not a UI person (which we are short on). 2. If we don't have agreement, how do we come to resolution on it? > 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. This has the potential to get very dangerous and messy. Are there ways we can mitigate it? We have a code review process, though I don't know that I've been added as a reviewer on anything done outside of my institution in a *long time*, so perhaps this process is failing to help build consensus...is a design review process necessary? I see both (1) and (2) happening with respect to the episode service. We have alot of features planned for 1.4, and most features seem to be developed by individual institutions, so I imagine that we're going to see alot more of (1) and (2). But a product without a cohesive UX is not good for adopters. Maybe we can brainstorm this at an upcoming dev meeting? Chris _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
