Renaissance/Design Proposals for “Accessing Functionality”/Community Feedback
Update: In the meantime, there has been more feedback by the community. It mainly confirms the already given points, so it won't be incorporated. For details please have a look at the full feedback thread at ux-discuss.
Contents
Design Proposal Collection „Accessing Functionality“
Some weeks ago, we started the Design Proposal Collection to address the topic „Accessing Functionality“ in OpenOffice.org. As you may know, we finished it and collected plenty of ideas ... so now it is time to revisit the process and see what went well and what did not. Since this was the first time the UX team organized such a process, we kindly asked for feedback by the community, which we received and will present in this article. We hope that sharing our experience will be interesting for other projects, even outside OpenOffice.org.
Okay, the feedback might not be that helpful, if you don't know how we planned and conducted the Design Proposal Collection. So here is a brief recap...
To get an initial idea of how people might think about such an effort, we simply asked on the mailing list at the end of March. We provided some of our ideas and the initial feedback was quite positive, so we decided to go on and work out the details. The whole time, it was very important to emphasize the idea of a collection – instead of „competition“. By the way, „we“ refers to Liz, Andreas, Frank and Christoph who sat together in Hamburg in mid of April.
Only a few days later we started the proposal collection by announcing it on the mailing lists and on GullFOSS. We provided:
- a wiki page covering the procedure, the schedule and the design details (e.g. focus, goals, design directives)
- a design proposal template for Impress which also contained the design details an a proposed set of objects to „draw“ the design idea
- a wiki page template which the authors should later use to present their individual ideas
With that material, the contributors started to work on their ideas – keeping their ideas private to not be influenced too much by other opinions. Originally, we planned the working phase to be about two weeks, but after some initial feedback, it was extended another week.
The next phase began with the ideas being published in the wiki, so we tried to ease this by setting up a wiki page template for each of the contributors. The next two weeks were reserved for the whole community to comment on the ideas on the corresponding wiki pages. Here, we tried to communicate that the focus should be put on understandability and completeness.
During the work and review phases, we listened to the questions by all people involved and tried to give feedback – either via the mailing lists or in private mails.
Finally, about one month after the start of the Design Proposal Collection process, we summarized the results and Liz presented them on GullFOSS. That's it!
Now, what did the proposal writers, observers, commentators think about thiws whole process? I repeatedly asked for feedback, and only one person provided an answer (very detailed). Additionally, Liz summarized the private questions and comments she got from five proposal writers – and added her own point-of-view. Plus, questions sent to us after the Design Proposal Collection were taken into account.
Feedback
Motivation
How motivating was the whole effort? Besides one contributor telling us that it was „fun“ and „worth the effort“, a rather implicit feedback was given by the number of contributions. In sum, we received 17 individual design proposals containing a lot of design ideas. And questions, whether there is time to work on the proposals later on...
Only one contributor asked whether there will be a prize for the winner, e.g. a shirt or a pen drive. A comparison was made to the 2006 KDE KOffice design proposal collection which offered 1000 USD for the best entry.
Procedure and Schedule
Fortunately, one contributor expressed that a „coordinated collection was the only way to really get meaningful design proposals“. He assessed “the idea to collect all the templates […] to allow others to edit them is a great idea”. Additionally, from what we saw, people accepted the different phases (working, review) of the design proposal collection rather well – except the timing.
Liz summarized it nicely with “the time frame was not generous enough”. The members writing to her mentioned that “May 4th is not really a lot of time”. Another member summarized that “the timing […] left […] little time to go into any details. Another hint concerning the strict timing were the two “late submissions” we got.
Even after the Design Proposal Collection review phase, we repeatedly received questions whether there will be time to work on the proposals later on.
Documentation and Tooling
How well was the documentation perceived, how did the people cope with the tools and documents we provided? Pretty different, since one contributor told us that he knew „quite well“ what to do, a few remaining questions had been answered „promptly“. But, the same contributor observed the different interpretation of the efforts' scope – by looking at the range of design descriptions.
Another member asked us about the level of detail, since one of our constraints was „do not remove functionality in OpenOffice.org that is currently available “. This seemed to be a bit unclear, because he asked whether every function has to be considered in the design proposal or whether presenting the basic idea would be sufficient.
We also received some criticism concerning the tooling. One member mentioned that design proposal template for Impress did not work well; having problems on both the template's side and the side of the contributors. First, the proposed elements seemed to limit the flexibility for some UI concepts – especially one element was rated to be distracting. Our embedded hint „add more if required“ seemed to get lost.
A lot of the authors did not use the presentation template, which one participant said made it difficult for him to compare the ideas. Here, we don't know any further reason as to why the authors did not use the presentation template – except that originally the individual wiki pages were to be used for the proposals and the addition of the presentation template was not clear in the directions. That also seemed to be ambiguous to another person who thought that only the design proposal wiki page template will be used to document and present his idea. Another contributor mentioned that there was no write access for him in the OpenOffice.org wiki.
Looking more closely at the wiki page template, it also worked „not too well“, since many collaborators „completely changed their template or didn't fill in certain wiki section“. The same person guessed there was confusion how to share the many ideas. Each contributor seemed to have chosen „different ways to communicate the ideas“.
The different organization and scopes caused that „all the information seemed overwhelming“. Even the community comments section lacked a clear organization, so a sample conversation was proposed.
Communication and Marketing
How well did the the communication of the whole effort go, especially the “marketing” stuff?
Our main communication channels were the mailing lists and the usual OpenOffice.org blogs and planets, plus notes on Facebook and LinkedIn. One contributor mentioned that it is a pity that there wasn't any real press coverage or more marketing outreach, since there are so many good ideas out there. He proposed we use Slashdot, LXer, ... Later, one contributor posted some information on Slashdot and our wiki page gained a lot of interest.
Lessons Learned
So what can be concluded now that the Design Proposal Collection is over? After looking at the individual feedback we got during the proposal collection and thereafter, it seems to have worked well. The weakest points seem to be the schedule and some parts of the documentation.
The initial schedule – two weeks for the working phase – was simply too tight. To be honest, some of us were unsure about that even before we announced the call for proposals. On the other hand, the decision to run it for another week gave us the opportunity to publish more information and to – hopefully – gain more interest in joining our Design Proposal Collection effort.
Concerning the documentation, there were mainly irritations about how the two templates (Impress file, wiki page) relate to each other and what level of detail is required. One idea of a solution could be to use the wiki to announce and point to the proposals, then only fill in the actual idea in the Impress-based template (which we would subsequently extend to include more). Then, somebody could have transferred all the content to a harmonized wiki page.
In a broader view, what are the alternatives to avoid confusion?
- Simply, reduce the formalism to – hopefully – gain room for further creativity. But this definitely requires more effort to collect, analyze and discuss the ideas.
- Increase the formalism and the documentation. Although this might restrict creativity and “scare” contributors, it will ease the post-processing of the results.
At the moment, it is unclear which tact would be best, so we'll leave it to be decided anew for each coordinated effort – looking at the focus, the complexity, the resources, etc. each time.Even if we put more emphasis on an effort's focus – there will always be a wide variety of response types from individual community members. In general it can be observed that community members want to share all the ideas they have and they often do so even if they do not fit the question posed. Even for a new Design Proposal Collection it seems that we can only set the expectations. The UX project is happy to serve as a multiplier to stimulate the overall brainstorming process :-) But, having in mind the constantly incoming general UX ideas, the OpenOffice.org project still lacks a central point to easily collect big and small ideas (not requests for enhancement or feature requests), which can be assessed by the whole community.
Another item is the communication channels – mostly we used blogs and mailing lists. Although this information was somehow “automatically” spread in the open-source community, such natural dissemination takes time. If we plan another effort similar to this one, and especially if there is a rather challenging schedule, then we should directly address the most important online news sites. This might save time and attract more people to join the effort.
Finally, the UX team expresses its deepest thanks to all the people involved!
