Pro Yearly is on sale from $80 to $50! »

Design in the realm of Open Source

Ee5bae7fa46b3195869c285ecbb4619e?s=47 Coby Chapple
August 19, 2013

Design in the realm of Open Source

I gave this talk at Refresh Belfast (http://refreshbelfast.com) in August 2013, talking about how design fits into the realm of open source, with the aim of lowering some of the barriers for designers to contribute, and providing some direction and resources to help people get started.

Ee5bae7fa46b3195869c285ecbb4619e?s=128

Coby Chapple

August 19, 2013
Tweet

Transcript

  1. Design OPEN SOURCE In the realm of Refresh Belfast—August 2013

    @cobyism
  2. Hi, I’m Coby. @cobyism online.

  3. None
  4. It’s not very common to find designers working in open

    source. STATUS QUO
  5. It can be intimidating to try and get started with

    open source. STATUS QUO
  6. It’s not very intuitive to know where to find help

    and resources. STATUS QUO
  7. Good tools are lacking for designers working in open source.

    STATUS QUO
  8. Lower perceived barriers to contributing to open source projects. GOALS

  9. Give you some direction with clear examples and useful resources.

    GOALS
  10. Share approachable tools that make building amazing stuff awesome. GOALS

  11. What does open source soware even mean? Infrequently Asked Question™

  12. Open Source Soware What even is:

  13. Open Source Soware What even is:

  14. Native applications are soware.

  15. Mobile applications are soware.

  16. Web applications are soware.

  17. Websites are soware.

  18. Themes and plugins are soware.

  19. Frameworks are soware.

  20. Documentation is soware.

  21. Ideas and specs can be soware.

  22. Books & knowledge can be soware.

  23. Open Source Soware What even is:

  24. Free as in beer. Open Source (usually) means…

  25. Free as in speech. Open Source (usually) means…

  26. Built by a community. Open Source (usually) means…

  27. Improvements are shared. Open Source (usually) means…

  28. right-click! The web has always been open.

  29. “view source” for everything. front-end web code mobile apps native

    apps back-end web code systems code VIEW SOURCE docs, ideas & knowledge
  30. “view source” for everything. front-end web code mobile apps native

    apps back-end web code systems code VIEW SOURCE docs, ideas & knowledge OPEN SOURCE
  31. “view source” for everything. front-end web code mobile apps native

    apps back-end web code systems code VIEW SOURCE docs, ideas & knowledge OPEN SOURCE
  32. How does design fit into open source? Infrequently Asked Question™

  33. We oen appear secretive about our design process. Designers

  34. “Thanks for your input, let me go away and work

    on that for you.” One Mindset
  35. READ THIS ARTICLE hp://37signals.com/svn/posts/2928-designing-in-the-open

  36. Labels are bullshit. DIGRESSION

  37. Closing disciplines off from one another is a recipe for

    disaster. DIGRESSION Labels are bullshit.
  38. People’s skillsets just fall on different parts of a wide

    spectrum. DIGRESSION Labels are bullshit.
  39. Case in point: @github/designers DIGRESSION Labels are bullshit.

  40. Case in point: @github/designers DIGRESSION Labels are bullshit.

  41. Design is a philosophy, not a profession. DIGRESSION Labels are

    bullshit.
  42. Engineering is a philosophy, not a profession. DIGRESSION Labels are

    bullshit.
  43. If the end product is quality soware, Designers, why can’t

    you code? DIGRESSION Labels are bullshit. — Kyle Neath @kneath
  44. If the end product is quality soware, Engineers, why can’t

    you design? DIGRESSION Labels are bullshit. — Kyle Neath @kneath
  45. Move past labels and focus on the quality of the

    end result. DIGRESSION Labels are bullshit.
  46. Design is as necessary as engineering in the realm of

    open source. An Answer
  47. We need to get comfortable working in the open. The

    question now becomes How?
  48. There are more ways to contribute other than commiing code.

    Fun Fact
  49. Help improve docs. Read the docs, suggest improvements.

  50. Actually try stuff out. Follow instructions, file issues if things

    break.
  51. Help triage. Replicate, verify, and clarify others’ issues.

  52. Review others’ code. See if you can spot room for

    improvement. Evven pointing out typos is handy.
  53. Discuss features Talk about features you’d love to see.

  54. Share your experiences. Write publicly about what it’s like to

    use.
  55. Create mockups. Help people visualise just how amazing things could

    be.
  56. Designing in the open is easier using code. Hypothesis

  57. Design in the browser. DIGRESSION

  58. A design should start where it’s going to live: in

    the browser. DIGRESSION Designing in the browser. — Meagan Fisher @owltastic hp://24ways.org/2009/make-your-mockup-in-markup/
  59. Web inspector. DIGRESSION Designing in the browser. Live debugging your

    CSS and JS awesome.
  60. CSS3, Sass, Less. DIGRESSION Designing in the browser. Radii, shadows,

    variables, colour math, mixins, includes. It’s all awesome.
  61. Real font rendering. DIGRESSION Designing in the browser. It’s no

    longer such a shitshow.
  62. Retina. DIGRESSION Designing in the browser. Having things not look

    like a blurry, pixelated mess is awesome.
  63. Icon fonts. DIGRESSION Designing in the browser. Not having to

    use images awesome.
  64. Web fonts. DIGRESSION Designing in the browser. Having options is

    awesome.
  65. Version control. DIGRESSION Designing in the browser. Having a design

    history is awesome.
  66. Interaction design. DIGRESSION Designing in the browser. Designing for transitions,

    loading states, taps, swipes, and zooms is awesome.
  67. Multi-device. DIGRESSION Designing in the browser. Going back to a

    responsive web is awesome.
  68. Responsiveness. DIGRESSION Designing in the browser. How it performs is

    the experience.
  69. Ways you can begin designing in open source today. Opportunities

  70. Documentation sites. Just about every project needs one.

  71. Angry redesigns. Make something horrible suck less.

  72. Create frameworks. Done something more than once lately?

  73. Themes and plugins. Use a text editor? Use a CMS?

  74. Graphs. Make publicly available data interesting. Also: d3.js is ridiculously

    cool.
  75. Design for designers. Developers oen develop for developers. Why don’t

    designers design for designers?
  76. Portfolio pieces. Build stuff for your portfolio.

  77. Non-portfolio pieces. Build the things you want to build anyway.

  78. Open source type. Ever wanted to try type design?

  79. Emoji. These things maer, damnit! hps://github.com/github/gemoji

  80. Things that make designing in the open easy and fun.

    Tools
  81. Jekyll Static site generator. HTML with includes, layouts, variables etc.

    Understands Markdown, knows about blogs. hp://jekyllrb.com
  82. GitHub Pages Free site hosting. Because fuck FTP. hp://pages.github.com

  83. Heroku Free app hosting. Because fuck PHP. hp://heroku.com

  84. GitHub for education. We offer free accounts for students and

    professors to have private repositories.
  85. GitHub web flow Create a branch. Create, edit, move, rename,

    and delete files. Open a Pull Request. Merge the branch. Delete the branch.
  86. Image diffs Seriously useful if you work with images.

  87. GitHub for Mac mac.github.com

  88. GitHub for Windows windows.github.com

  89. How to learn, improve, and find help when you get

    stuck. Resources
  90. Everything weekly. Subscribe to all of the web newsleers. Warning:

    can be noisy.
  91. Google is your friend. Google your error, find the stackoverflow

    link.
  92. Stackoverflow.com Google your error, find the stackoverflow link.

  93. Mozilla MDN Because it’s not w3schools.

  94. Examine frameworks. Learn how they did it.

  95. Mentoring hp://mentoring.is

  96. Contribute to an open source project by this time next

    week. My challenge to you
  97. Let’s talk coby@github.com @cobyism