Design Process in an Open Community Ecaterina Moraru — 31 Oct 2014 —
Design process in an Open Community
Jun 23, 2015
Talk at 'Design Jam' event in Iasi, Romania, on 31 Oct 2014, https://www.eventbrite.com/e/design-jam-autumn-edition-tickets-13430066691
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
What is an Open Community?
A community is a social unit of any size that shares common values
An open-source software has its source code made available with alicense that provides the rights to study, change and distribute the softwareto anyone and for any purpose
An open community:
let's everyone participate in the processmakes her processes transparent the discussions are open and inclusivelistens to community opinions and takes decisions based on them
·
·
·
····
Design Examples: Drupal Design, Mozilla Creative, Mozilla UX, WordPress UI, XWiki Design, etc. 2/22
Want to be a designer?
Several subcategories in Design
User Research, User Testing, Product Design, Graphic/Visual Design,Interaction Design, Information Architecture, Usability, Interface Design,User Experience Design, Accessibility, Human-computer Interaction,Game Design, Industrial Design, Knowledge Visualisation, Sound Design,Web Design, User-Centered Design, Software Design, etc.
Find our what suits you
Start designingYou don't have to be hired in order to designAll Open Communities need designers (and developers, and testers, and ... )
·
·
·
·
··
3/22
Open / Design / Product Communities
Each community has its rules & processes:
Communication channels (IRC, Mailing list)Periodic meetingsFeedback & StatisticsDocumentation processesAcceptance / Critique rulesVoting rules
What you need in order to provide designs:
A problem to solveFamiliarity with the product / serviceFamiliarity with the targetMinimal usage of collaboration toolsMinimal understanding of rules & procedures
·
······
·
·····
4/22
LGPL 2.1 open source licenseJan 2004 initial release
820,996 lines of code from 36,080 commits
95 contributors 19 active committers
700+ extensions with over 150 applications
11,637 issues reported 1,849 issues resolved last year
259,526 mail messages 4,479 discussions last year
What is XWiki?http://www.xwiki.org
5/22
Design Process Steps
PlanningFeatures according to the Roadmap or cycle themeIdeas / suggestions can be submitted anytime
DiscussionsMade on IRC or mailing listsPublic and referenceable
ProposalsDeliverables (use cases/requirements/mockups/prototypes) are created ondesign.xwiki.org in an iterative mannerReceive feedback for them on mailing list
Tags: [Brainstorming], [Discussion], [Proposal], [Vote]
·
··
·
··
·
·
··
6/22
ProductGeneric platform for developingcollaborative applicationsExtensible and customisable forspecific needs
TargetAddressed to everyone
Preference for enterprise users
Open Source communities areusually technical
Deliverables:research reports, use cases,storyboards, sketches, wireframes,mockups, prototypes, implementationarchitecture, usability reports, etc.
Design.xwiki.org
·
·
·
·
··
·
·
7/22
Proposal Evolution
Product vs. ProjectsGet to see how your proposals hold the test of timeLots of diversity from making an extensible and customisable productGet to understand how many small components build the big picture
Creativity vs. ImplementabilityCreativity is encouraged, but users prefer standard patternsUsers don't like big changes from one version to another
ConclusionsDesign as generic as you can Consistency is kingUse as much standards and patterns as you can
·
···
·
··
·
···
8/22
Decision Making
Contribution Levels:
Users (Lvl. 1), Contributors (Lvl. 2), Committers (Lvl. 3)
Voting:
Majority of discussions / decisions are done using our mailing listsCommunity members are encouraged to participateCommitters have a duty to participate in [VOTE] discussionsPossible votes: +1 — I agree and I'll help as I can+/-0 — I'm ok but I'm letting the others decide and I'll be happy withwhatever the outcome is -1 — I'm against it and I veto the change
A vote cannot pass if a committer has voted -1
·
·
·
····
··
··
9/22
Decision Making
Closed Design Process vs. Open Design Process
1++ Clientrepresentatives
0..m Community members
1 Major Vetovote
c Committers Veto votes
u Initial use cases u(+m) Iterative adaptable use cases f Functionalities f+(+m) Functionality + integrable + extensible +
backward compatibility + cross browser +platform independent + multi lingual + ...
Obs1. Cannot make everybody happy
Obs2. Take the best decision for the project (according to vision and principles)
·
·
·10/22
Decision Making — Symptom: "Bike Shed" (1/4)
The bike shed story tells of a management committee’sdecision to approve a nuclear power plant, which it does so
with little argument or deliberation.
The story contrasts this with another decision on choosing thecolour of the bike shed where the management gets into a nit-
picking debate and expends far more time and energy than on the nuclear power plant decision.
— Source
“
”
11/22
Thread: New location of the"Add" menu in the newFlamingo skin
Thread: A new javascriptservice to get XWikimetadata
Decision Making — Symptom: "Bike Shed" (2/4)
Also known as "Parkinson's law of triviality" (1957)
The amount of discussion is inversely proportional to the complexity ofthe topic
Trivial decisions often come under debate because everyone is on equalfooting
Choose a conversation to get involved:
·
·
·
·
12/22
Thread: New location of the"Add" menu in the newFlamingo skin
62 replies — 10 participants
Thread: A new javascriptservice to get XWikimetadata
10 replies — 5 participants
Decision Making — Symptom: "Bike Shed" (3/4)
13/22
Thread: Interface and ContentLanguage Separation
29 replies — 13 participants
Decision Making — Symptom: "Bike Shed" (4/4)
14/22
Decision Making — Symptom: "Make everything configurable"
Premises:
Usually happens when is hard to reach a conclusionCompromise method in order to satisfy multiple use casesGives power to the user, but the user's profile is advanced
Problem: Increases the complexity of the product (branching functionality isharder to test). Documentation is mandatory
Solution: "Good Defaults" pattern
Pre-fill the configuration with most common default valuesImportant to know which use case is used moreAlternative is to use Themes / Profiles
·
···
·
·
···
15/22
Decision Making — Symptom: "I don't know what I was voting"
Premises:
Partial understanding of the problem / solutionMissing information from the voting process
Solutions:
Best designs are iterative (improvements after a period of testing)Try to provide clear mockups and prototypes
Conclusions:
"NO perfect proposal". Changes in: target, purpose, technology evolves,new requirements appear, new user behaviour found, etc.It's normal for people to change their mind
·
··
·
··
·
·
·
16/22
Decision Making — Other Symptom
S4: "But the competition does it"
S5: "I tested it with ONE user"
S6: "It's a nice idea for ... next century"
S7: "Cannot implement it like this since it's not supported by ... " (code, IE,mobile, JS disabled, etc.)
Other...
·
·
·
·
·
17/22
Advantages for Participants:
Easy to participate Multiple eyes Helpful feedback / collaboration Honesty High impact of proposal Longer lifespan (open projects die
harder) Everything is public and referenceable Meritocracy
Advantages for Product:
Many ideas from many participants Know what users are wanting 'Automatic' sort of higher quality
solutions Work in iterations (no deadline) Testing, maintenance and feedback
from community Rapidly knowing if something goes
wrong
Disadvantages for Participants:
Endless discussions Slow decision process Expect criticism
Disadvantages for Product:
Hard to determine statistics (target,usage)
Designing in the Open
· ·
· ·
18/22
Join a community — Start designing!
Other Questions?
Related Documents
