< 7 >

Creative Explorations in Screen-Based and Physical Computing

DGMD E-15, Spring 2016

10 March 2016

  1. Some anti-patterns in project work
  2. Sharing out project mockups and prototypes to get feedback, generate code snippet requests/next steps
  3. Break
  4. Small group play, project work
    • HTML, CSS, & JS with Shaunalynn & Molly
    • JS and physical computing with Alec
    • Project brainstorming with Bakhtiar

Making just to make

If you…

  • You sit down to work, and you consistently find yourself distracted.
  • You don't know anyone personally who would benefit from what you want to make.
  • You think that a "class project" (or "app" or "art project") has to look or sound a certain way and so reject ideas of yours before they have a chance to grow.
  • You want to want or think you should want to do your project.

…then consider

  • Schedule a time to sit down with one of us to brainstorm your project, interests, and goals for the course!
  • Take one-off ideas which pique your interest seriously, even if they don't seem like a "good project."
  • Don't worry about the relative technical complexity of the project. In our experience, doing anything real is hard enough, and even small tweaks can incur plenty of technical work, if that's a priority for you.

Planning instead of growing

If you…

  • Because it's uncomfortable to not know things (much less ask for help), you instead spend more time planning, imagining, worrying about problems two- and three- and four- steps ahead.
  • You say to yourself, "I need to learn more about X before I can start."
  • You haven't yet made any small things or attempts on the path toward sculpting your initial prototype.

…then consider

  • Give yourself permission to throw things away. You might code something that you don't ultimately put into your final project. That's OK.
  • If you're not sure how to come up with something to code that's more specific than "my project," talk to us!
  • Figure out a regular practice (of sharing mockups, articulating the next thing you need to code, collecting all your open technical and/or design questions, whatever will be helpful to you).

Not getting stuck

If you…

  • You don't have code in your journal or sitting on your computer somewhere that just straight-up didn't work.
  • You're not sure what the next step for your project is, but you wouldn't say you're stuck.
  • You haven't ended a session lost in the process of getting something to work or had the experience of finally getting that thing to work the next day or week or...

…then consider

  • Sit down and articulate a milestone for the next week (or next day). Email it to us, or post it in your journal. When your deadline comes around, share what you've tried and the progress you've made (or haven't!).
  • Ask to sit down and just play and explore—we love just sitting down to sketch and brainstorm together, more like a jam session than a tennis lesson.

Letting yourself stay stuck

If you…

  • You watch video after video or read page after page about what you're trying to do, but don't feel like you're making progress.
  • You switch between possible solutions before really finding out whether one works or not.
  • You've been stuck on the same problem for more than a day or two and haven't made any articulable progress.

…then consider

  • Work on a pomes extension!
  • Post your question to Stack Overflow. Or at least sit down and write up your question and situation such that a stranger could understand what was going on and try to help.
  • And then maybe post in the DGMD Slack channel! Or email us! Or just ask to get together with us and work through the topic—not even addressing your problem directly.

Wrong level of detail

If you…

  • You find yourself drawing things out in pixel perfect detail.
  • You find yourself saying, "I'll figure this out later" instead of "I'll do this later."
  • You've drawn something out in sufficient detail to begin using HTML/CSS/JS to prototype what you've drawn, but you still spend your time refining the visual details.

…then consider

  • Even if you're not sure how to do part of your project, build out your mockup around it.
  • Identify a few of the skills or ideas you need to master for your project. Brainstorm a small sketch that you can do using those skills, or ask us to help you come up with one.
  • Ask us for guidance as to which parts of what you've put together are too detailed or not detailed enough.

Hyperfocusing on the tool

If you…

  • You spend more time searching for someone else who's done what you're trying to do than you do trying to do it yourself.
  • You know what your problem is and that you want a tool to solve it, but you're not sure how you would tackle the problem (meaning the tool isn't "just" saving you effort).
  • You spend more time trying to understand someone else's system than the fundamentals of HTML, CSS, & JavaScript

…then consider

In short, the biggest mistakes are underestimating the value of a compelling and coherent idea, not iterating in a lightweight way, and most commonly, not taking advantage of us.

We're always available by email, in #Slack, and especially in person.

Sharing out

  1. Who is the audience and how will I know if the project is good?
  2. What's the next question I need answered?
  3. What's the next skill I would really benefit from developing?

< break >

In small groups…

  • HTML, CSS, & JS (Shaunalynn & Molly)
  • JS and physical computing (Alec)
  • Project brainstorming (Bakhtiar)

For next session

  1. Share out notes and next steps from your brainstorm today in your journal
  2. Also in your journal, answer:
    1. What did you accomplish today?
    2. What do you aim to have done by next session?
    3. What can we (the teaching team) do to help?
  3. If you get stuck, submit a Code Snippet Request or get in touch on Slack if you have any trouble!

< /7 >