Mathias Bauer wrote:
Joe Smith wrote:
I've started to see these messages on the features announce list (via
Gmane). This seems like a good thing, but I have some questions:
1) Is there any mechanism for feedback on these features?
None seem to have any issue number; are they supposed to be tracked
through the CWS name? If so, is there a feedback channel there?
I think they should have an issue number - in case there is a single
issue for that feature. Besides that they can indeed by tracked through
the CWS name in EIS.
Most have a CWS name, but in this case (a "community patch") there is
not even that.
2) Do these features go through any UX process? Perhaps it is all internal.
Every new feature is expected to go through a UX process, at least on an
informal level. I don't know what "internal" should mean so let me
describe what we are doing in Hamburg. ...
Sorry I wasn't clear, but you understood my meaning of "internal"
accurately.
Getting feedback from a wide an audience as possible seems like a good
way to go. It is so hard to change any UI design after the fact.
As every work UX work needs a focus. IMHO posting new features to a
"discuss" list at random will not produce useful results. Perhaps it
will make things even worse when the discussions (as often) won't come
to an end or end without a concrete result.
I agree: a random discussion is not the way to do UX design, but it is
part of the way. The iTeam can easily make a final decision and move on
at any time, if there is no consensus.
I think a feature always should have a dedicated UX worker (and of
course at least one developer ;-)). If all people involved in developing
the feature think that they need more input they may use our UX project
and its mailing list to collect more input. But that's just my personal
opinion.
Yes, but it is precisely when the developers think that no outside input
is needed that the outside input is most needed ;-)
Of course the developers are professionals and can make good decisions,
I'm not saying that everything has to be reviewed, only that comments
should be solicited for all features, even if the solicitation is
implicit (a link to a feedback channel).
Tracking a feature through EIS is not good: it's very difficult and
there is no place for direct feedback. Not every CWS links back to any
issue; many link to several issues.
There should be some link on the feature announcement, either to an
issue id, or to a mailing address ([EMAIL PROTECTED] is not
useful to outsiders!) or mailing list where comments can be made that
will definitely be seen by the iTeam. I expect most will get no
comments, but some will and some will be useful.
In the case of this specific feature:
Context menu entry to quickly insert picture background for slides
the spec (http://specs.openoffice.org/impress/sd.insertbackground.odt)
has a broken image of the proposed menu.
I have no idea how and if a UX review happened for that particular
feature. At least it would be a violation of our rules if it hadn't got
one. But even a review may fail to prevent errors.
Ok, well maybe this list will work in this case, but some channel should
be opened to make it easy for a community volunteer to provide feedback
on a feature before it is integrated.
Thanks so much for taking time to explain the process.
<Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
