Graphic and interaction design are two fields critical to software development that — unlike code have — have not yet nourished a successful collaboration model. What can we learn from the Wordpress community’s latest attempts to involve designers in the open source process? Can we simply apply the same collaboration methods from code to design? And what other examples and models are available for us to borrow from? What are the challenges of networked collaboration in the creative process? Can they and how might they be solved? Or is it just that designers don’t like to work together? Mushon will be presenting and leading a discussion on the subject with examples from the Wordpress community, his own work, and the research done in his Open Source Design class taught in Parsons’ AAS Program in Graphic Design. Speaker: Mushon Zer-Aviv. More on http://mushon.com

1. Hi, I’m Mushon
@Mushon.com Nov 09

2. Shual.com
@Mushon.com Oct 09

3. Beyond Sharing:
“Open Source Design”
Wordcamp NYC 2009
@Mushon.com Nov 09

4. Open source is great!
But does it really exist
beyond code?

7. -

8. -

9. -

12. -

13. e happe ns here
Ope n Sourc
}
-

14. 1. Getting on the Wagon

15. 1. Getting on the Wagon
• OS motivation - personal interest in
(and low costs for) collaboration

16. 1. Getting on the Wagon
• OS motivation - personal interest in
(and low costs for) collaboration
• OSD motivation - not so straight-forward

17. 1. Getting on the Wagon
• OS motivation - personal interest in
(and low costs for) collaboration
• OSD motivation - not so straight-forward
• Chicken & Egg - Designers don’t use OSS

18. 2. Granularity

19. 2. Granularity
• In coding (software) and writing (wikis) the
building block is granular - a character

20. 2. Granularity
• In coding (software) and writing (wikis) the
building block is granular - a character
• Allows for varied contribution:

21. 2. Granularity
• In coding (software) and writing (wikis) the
building block is granular - a character
• Allows for varied contribution:
• Accessible ladder of contribution

22. 2. Granularity
• In coding (software) and writing (wikis) the
building block is granular - a character
• Allows for varied contribution:
• Accessible ladder of contribution
• History

23. 2. Granularity
• In coding (software) and writing (wikis) the
building block is granular - a character
• Allows for varied contribution:
• Accessible ladder of contribution
• History
• Moderation

24. 2. Granularity
• In coding (software) and writing (wikis) the
building block is granular - a character
• Allows for varied contribution:
• Accessible ladder of contribution
• History
• Moderation
• Transparency

25. 3. Language
Encoding/Decoding
Stuart Hall 1980

26. Encoding
framework
of knowledge
A

27. Mutual Language

28. framework
Decoding of knowledge
B

29. Encoding
A A
Decoding

30. Encoding
B A
ERROR
Decoding

31. A A A

32. A
A
A
A A

33. Encoding

34. Encoding
• Defining a language (code) is key in design
(graphic, color, layout, animation, interaction...)

35. Encoding
• Defining a language (code) is key in design
(graphic, color, layout, animation, interaction...)
• Coding without a shared language (code) is
impossible

36. Encoding
• Defining a language (code) is key in design
(graphic, color, layout, animation, interaction...)
• Coding without a shared language (code) is
impossible
• Setting collaboration standards is essential

37. Encoding
• Defining a language (code) is key in design
(graphic, color, layout, animation, interaction...)
• Coding without a shared language (code) is
impossible
• Setting collaboration standards is essential
• Standardization VS. Innovation

38. Decoding

39. Decoding
• Code either executes or it doesn’t,
but a message interpretation isn’t binary

40. Decoding
• Code either executes or it doesn’t,
but a message interpretation isn’t binary
• Inconsistent design fragments the message
(our brains can’t really multitask)

41. Decoding
• Code either executes or it doesn’t,
but a message interpretation isn’t binary
• Inconsistent design fragments the message
(our brains can’t really multitask)
• Wikipedia’s has a largely rational guidelines
for decision making, design’s doesn’t

42. So is it simply undoable?
(would I be wasting your time if I thought so?)

43. Resource
sharing
/ Open Culture

44. Wordpress 2.5
admin by HappyCog
Wordpress 2.7
Modified by the Wordpress team

57. Fixing it: 1. Getting on the
Wagon

58. Fixing it: 1. Getting on the
Wagon
• Price is always itching, but it’s not enough

59. Fixing it: 1. Getting on the
Wagon
• Price is always itching, but it’s not enough
• We can’t force the use of bad tools as an
ideologic statement

60. Fixing it: 1. Getting on the
Wagon
• Price is always itching, but it’s not enough
• We can’t force the use of bad tools as an
ideologic statement
• Some success in webdesign / Wordpress

61. Fixing it: 1. Getting on the
Wagon
• Price is always itching, but it’s not enough
• We can’t force the use of bad tools as an
ideologic statement
• Some success in webdesign / Wordpress
• Still very code-based

62. Fixing it: 2. Granularity

63. Fixing it: 2. Granularity
• When possible, use granular building blocks
- namely: use code

64. Fixing it: 2. Granularity
• When possible, use granular building blocks
- namely: use code
• Get designers on version control systems

65. Fixing it: 2. Granularity
• When possible, use granular building blocks
- namely: use code
• Get designers on version control systems
• Put all master files online

66. Fixing it: 2. Granularity
• When possible, use granular building blocks
- namely: use code
• Get designers on version control systems
• Put all master files online
• Explore file non-code versioning (Dropbox?,
Alienbrain?)

67. Fixing it:
3. Language

68. Fixing it:
3. Language
Collaborative Encoding:

69. Fixing it:
3. Language
Collaborative Encoding:
• 1st step:
Conduct a networked research
(we already have collaborative tools for that)

70. Fixing it:
3. Language
Collaborative Encoding:
• 1st step:
Conduct a networked research
(we already have collaborative tools for that)
• 2nd step:
Define a modular and extensible language
* Support simple inheritance (like in CSS)

71. Fixing it:
3. Language
Collaborative Encoding:
• 1st step:
Conduct a networked research
(we already have collaborative tools for that)
• 2nd step:
Define a modular and extensible language
* Support simple inheritance (like in CSS)
• 3rd step:
Document the language (style guides)

72. Fixing it:
3. Language

73. Fixing it:
3. Language
Collaborative Decoding:

74. Fixing it:
3. Language
Collaborative Decoding:
• Some design decisions are rational, and can
achieve consensus, like:

75. Fixing it:
3. Language
Collaborative Decoding:
• Some design decisions are rational, and can
achieve consensus, like:
• UX research

76. Fixing it:
3. Language
Collaborative Decoding:
• Some design decisions are rational, and can
achieve consensus, like:
• UX research
• Technical aspects of design

77. Fixing it:
3. Language
Collaborative Decoding:
• Some design decisions are rational, and can
achieve consensus, like:
• UX research
• Technical aspects of design
• Design best practices (in typography, use
of icons, interaction paradigms...)

78. Fixing it:
3. Language
Collaborative Decoding:
• Some design decisions are rational, and can
achieve consensus, like:
• UX research
• Technical aspects of design
• Design best practices (in typography, use
of icons, interaction paradigms...)
• Blogs share resources and documentation

80. -

81. A nuanced analysis of OS:
Openness + Leadership
-

82. We can’t just sprinkle design
with the magic pixie dust of
“Open Source”

83. Collaboration is hard!
Let’s make it easier.
Suggestions?

84. @Mushon.com Nov 09