Update instructions and template

Author: rafd

README.md

@@ -18,25 +18,28 @@ In the first hour, we will do a brief explanation of data-driven APIs, and then
 
 ## Your Design Task
 
-1. Choose one of the problem domains from [this list](./problem-domains.md).
+1. You will be designing a data-driven DSL to solve some problem.
 
-   We recommend choosing a problem domain that you are at least somewhat familiar with (to better understand how your syntax might be used in practice).
+   Choose one of the problems from [this list](./problems.md).
 
-   If you've thought of other problem domain that you'd like to design a data-driven API for, go ahead!
+   We recommend choosing a problem domain that you are at least somewhat familiar with (to better understand how your DSL might be used in practice).
 
+   If you've thought of some other problem that you'd like to design a data-driven API for, go ahead!
 
-2. Design a data-driven DSL for that problem domain.
 
-   give some examples of how you would use it.
+2. Take a moment to scan through the [list of reflection questions](./evaluating-notations.md) to get an idea of some of the characteristics that you might want to keep in mind while working on your design.
 
-   see [the template](./template.md)
+3. Now the hard part: design a data-driven Clojure DSL for your chosen problem.
 
-   The task is *not* to implement the system, it is just to design the data-driven API.
+   You don't have to implement the actual library! Just sketch out what the syntax and workflow might be for using the library.
 
-   You do not have to implement the entire language, just use the existing language as inspiration.
+   Many of the suggested problems already have some existing declarative languages (which isn't data-driven), but, many of these languages are quite general and complex (and maybe even turing-complete) -- your design does *not* need to match them 1:1 in features, feel free to focus on a subset of functionality or just use the existing languages as inspiration/"prior art".
 
-3. Reflect using [these questions](./evaluating-notations.md)
+   We recommend you start your design work by choosing a few specific sample use-cases to design for.
 
-4. After you're done with your design(s), if you'd like to have them potentially discussed in Part 2 of the workshop, add a link to [the spreadsheet](https://docs.google.com/spreadsheets/d/1F7TGID104-ayVhOT47RV3fCLHpvAaeOGZScIKdvG9-8/edit?usp=sharing).
+   The end goal is to come up with a mock README for your library, featuring an explanation of what it does and examples of how to use it. See [the template](./template.md)
 
+3. After you are done your design (or time is running out), take a moment to reflect on your design using [these questions](./evaluating-notations.md). Perhaps add some notes to you README if you find some of these questions make you identify something particularly good or bad about your design.
+
+4. If you'd like to have your design potentially discussed in Part 2 of the workshop, push your README to GitHub and add a link to [the spreadsheet](https://docs.google.com/spreadsheets/d/1F7TGID104-ayVhOT47RV3fCLHpvAaeOGZScIKdvG9-8/edit?usp=sharing).
 

problem-domains.md renamed to problems.md

@@ -0,0 +1,30 @@
+# [ libname ]
+
+[ Libname ] is a Clojure(script) library for [ some task ].
+
+[ Some extra information if you'd like. ]
+
+<sup>(Protip: If you're having a hard time coming up with a name for your design, just do what Metosin does: pick the most matter-of-fact word to describe your library, but in Finnish instead of English).</sup>
+
+## Quick Start
+
+```clojure
+  ;; one or more examples of how someone would use libname
+  ;; inputs, outputs, workflow
+  ;; is it just one function or more?
+```
+
+
+
+
+
+
+
+## Limitations / Future Work
+
+[ what would you like to have added or changed in your design? ]
+[ any particular challenges? ]
+[ was a data-driven approach suitable for this problem? ]
+[ any of the reflection questions particularly relevant? ]
+
+