We had another good round of meetings this week. Most people said they found the concept mapping exercise useful, but a significant minority did say that it didn't fit the way they think, or that they thought it was more effort than it was worth.

About a dozen people also said that they're still trying to figure out Git, GitHub, Markdown, and how those three things fit together. If you'd like some help in the next two weeks, please mail Greg and he'll pair you up with someone. Please don't be shy about asking: this is our first time using a GitHub-based blog, and every question you ask helps us figure out how to do better next time.

Our focus for the next two weeks is developing quick multiple choice questions (MCQs) that we can use for formative assessment, i.e., to get feedback as we're teaching about how much people are actually learning. To do this:

1. Pick a small topic from our existing lessons. It doesn't have to be different from the topic you used for your concept map, but choosing something new will give you an opportunity to learn more about our lessons.
2. Come up with two MCQs and add them to the blog in the _submissions/round-12/2 directory. Please use yyyy-mm-dd-forename-surname.md as the filename (e.g., 2015-03-06-greg-wilson.md) and /yyyy/mm/forename-surname-mcq/ as the permalink (e.g., /2015/03/greg-wilson-mcq/).
   1. Start your blog post with a sentence about the lesson your MCQ is for, and a link to the lesson.
   2. The first MCQ should present the question and possible answers without any analysis or explanation.
   3. The second MCQ should present the question and possible answers and then explain what misconception each of distractors (i.e., the deliberately wrong answers) is meant to diagnose. Note that you should have misconceptions in mind when choosing distractors for the first question; you just shouldn't add them to the post. These posts are due by next Thursday (March 12, 2015).
3. Once posts are up, give at least three people feedback on their MCQs.
   1. Try to distribute your feedback: if a post already has a couple of comments, look for one that doesn't have any.
   2. Try to answer the first MCQ (the one that the author hasn't analyzed), and also try in your comment to explain what misconception you think the distractors are meant to diagnose.
   3. For both MCQs, give feedback on whether it's ambiguous, whether the distractors are plausible, how long you think it would take to answer, and anything else that comes to mind. Feedback is due before our next meeting, which will be on Thursday, March 19.

Reading: Please read Chapter 3 of How Learning Works, since our next exercise will be about motivation and demotivation. You may also enjoy:

• Peer Instructions: Ten Years of experience and results
• Halving Fail Rates Using Peer Instruction
• Success in Introductor Programming: What Works?
• It's OK - Not Everyone Can Be Good at Math

10:00 Eastern

• Michael Sarahan, Nion Co. http://swcarpentry.github.io/training-course/2015/02/manipulating-data-with-r/
  • Maybe just a link to the Jekyll docs would be sufficient for me
  • About 1 hour
  • I liked being forced to examine the connections, and for my topic in particular, how topics are interconnected. If I taught the topic, I would reinforce looking at the output of selection and of functions, to show the interconnection/type.
  • I learned a lot of organizational schemes and graphical elements. There's also an interesting mix of concept vs. procedure.
• Daiva Nielsen, University of Toronto http://swcarpentry.github.io/training-course/2015/02/loops-in-the-shell/
  • The headers that were needed (I figured that out by looking at other people's .md files)
  • \~2.5 hours. I'm a slow reader, took a while to read the lesson, digest it & understand it, then to figure out how to map it.
  • Now I understand why loops are structured the way that they are and why they are useful.
  • It's just interesting to see how others organize information visually. I noticed lots of different visualizations and two people asked to draw a concept map about the same topic would probably draw maps that look quite different.
• Karl Broman, U Wisconsin-Madison, http://swcarpentry.github.io/training-course/2015/02/gnu-make/
  • The github blog post stuff was pretty clear for me.
  • I spent about an hour on it; would've taken longer if I hadn't cheated by (a) covering something not in swc v5 and (b) not labeling the edges
  • I'm not sure I learned anything new, but I didn't really stretch myself on this.
  • Small ones with labeled edges are quite informative. I generally t8hink in terms of a hierarchy or outline, but I appreciate the value in not having to specify a particular order of topics in the network diagram
• Simon Fraser, Sanger Institute http://swcarpentry.github.io/training-course/2015/02/pipes-and-redirection/
• Konrad Förstner, Universtiy of Würzburg, Germany, https://swcarpentry.github.io/training-course/2015/02/concept-map-shell-scripts/
  • Where a good template/example could be found
  • 30 min
  • Not much - I think I should have take something more challenging/new to me
  • It's hard to boil a topic down to a small selection of key concepts. But once done they give a good overview
• Hugues Fontenelle (Oslo University Hospital) - http://swcarpentry.github.io/training-course/2015/02/git-add-commit/
  • Greg's blog post was good. Just I wish I had found it before I posted my own.
  • Doing the concept map during an actual SWC seminar.. a few seconds! (But over an hour uploading the pic and writing the image wrapper)
  • Keep it simple is often better
  • A concept map does not need to be an algorithm/flowchart
• Sarah Mount (University of Wolverhampton) - http://swcarpentry.github.io/training-course/2015/02/git-merge-conflicts/
  • (blog posts on GitHub) A bit more about the directory structure would have been great
  • 20 mins
  • It's really, really hard to describe some ideas without examples
  • That concept maps have a stricter syntax than I thought
• Filipe Fernandes: http://swcarpentry.github.io/training-course/2015/02/pyfunc-concept-map/
  • I am used to jekyll, so I am of no help here.
  • 2-3 hours. But I re-visited it the next day before submitting.
  • I am not sure yet how to use concept maps to teaching, but I like the idea of having them around for students to see while I explain a something.
  • I learned that concepts maps about the same topic might convey completely different messages.
• Laura Graham (University of Nottingham): http://swcarpentry.github.io/training-course/2015/02/git-modify-add-commit-cycle/
  • Nothing really, I quite like learning from example (and looking at other .md files was good for this). I would however now like to know where to look for more information so that I could potentially set up my own blog this way.
  • About 30-45 minutes, but I probably should have spent a little longer because (as the comments let me know), I got `git add` a little bit wrong.
  • It made me think more about how everything is connected, I now have a better idea of the steps involved in making changes to a git repository and find I can complete the git modify-add-commit cycle without really thinking about it.
  • The easier to understand concept maps were those with enough, but not too much, information.
• Arliss Collins (Mozilla Science Lab) - http://swcarpentry.github.io/training-course/2015/02/open-science-licensing/
  • can't think of anything that would have sped it up
  • about 2 hours - probably because of my perfectionist side and I included the reading of the lesson
  • concept maps for the same topic can look very different
• Joseph Long, Space Telescope Science Institute - http://swcarpentry.github.io/training-course/2015/02/python-functions-concept-map/
  • I didn't have much trouble with the blog posts and pull requests. For the future, an example post might have been helpful (e.g. to suggest including one's name in the permalink). My only problem was that someone else chose the same permalink as me after comments had already been made on mine…
  • The concept map took about 25 min (and three drafts)never
  • How hard it is to distill a complex relationship into boxes and arrows! "Result" as a concept was used on edges, but could have also been a box itself… but that could have made those edges harder to read.
  • From the other concept maps and comments I got some different perspectives on the most important information to incorporate. (Everyone agreed on the core concepts, but the details varied from person to person.)
• Adam Richie-Halford (University of Washington): https://swcarpentry.github.io/training-course/2015/02/databases-selecting-with-sql/
  • I was pretty happy with publishing the blog posts
  • How long: approx. 1 hour (not including the reading)
  • What did I learn about the topic: I was completely new to SQL so I learned a lot.
  • What did I learn about concept mapping: It's easier to get started if you think about the topic hierarchically (i.e. draw a concept map that looks like an org chart or a binary tree). But then it can be difficult to connect the leaves of different branches. This reminds me a bit of how "novices" organize their knowledge: to go from one leaf to another, they may have to travel up the entire "tree" to go back down to another leaf.
• Daniel Wheeler (National Institute of Standards and Technology): http://swcarpentry.github.io/training-course/2015/02/pipes-and-filters-wheeler/
  • Distinct naming for permalinks
  • How long: about 1 hour
  • Thought about the connection between concept maps and flow diagrams and how they interact.
  • The concept map focused my thoughts on the important abstractions in unix pipes and how to convey those abstractions, but how useful are abstractions to a beginner.
• Kyler Brown (U of Chicago) https://swcarpentry.github.io/training-course/2015/02/range-concept-map/
  • What is the function of the header?
  • 45 minutes
  • I probably made my concept map too busy
  • connecting arrows can be "verbs"
• Matt Probert (York UK) http://swcarpentry.github.io/training-course/2015/02/mpi-point-to-point-communications/
  • Did the minimal, seemed to work ok, the on-line help is good
  • Thought about it lots during the week, then took about 1 hour from start to finish
  • Basic ideas ok
  • Keep it simple - I did not appreciate it was meant to be something that could be taught in 10 minutes - I was thinking about the concept map for the topic instead.
• Ben Weinstein https://github.com/swcarpentry/training-course/blob/gh-pages/_submissions/round-12/1/2015-02-22-plotting-function-R.md
  • (no answers posted)
• Victor (Kwangchun) Lee (xwMOOC, Korea) http://swcarpentry.github.io/training-course/2015/02/git-backup/
  • The github blog approach is fine for me. and with other small pieces, perm link and image link. The github blog can do more things with limited resources much faster.
  • It took around 5 min.
  • I could understand what I know in a different aspect. and look back from workshop attendees.
  • Someday, concept map comparison with English and Korean
• Johan Hjelm (Technical University of Denmark) http://swcarpentry.github.io/training-course/2015/02/python-lists/
  • maybe some more info on the headers
  • 2 - 2.5 hours, took a while to decide on a topic as well
  • I think I got thinking a bit about how much to include when teaching beginners, I tend to add too much material…
  • it was interesting to see how different people view the same topic,
• Marios Isaakidis (Mozilla Reps) https://swcarpentry.github.io/training-course/2015/02/defensive-programming-concept-map-misaakidis/
  • How to use jekyll to serve training-course locally
  • Around 1h15m
  • Key entities/elements in concept maps are better inter-connected and are placed in the middle of the map
  • Concept maps can be extended to use symbols, lists etc. to help match how someone clusters elements
• Violet Zhang (University of Pennsylvania) http://swcarpentry.github.io/training-course/2015/02/collaborating-using-git/
  • I saw your email for the Github blog post before I made any comment
  • it took me about 30 min to make the concept map
  • Not much, but I feel like I know the connections between key concepts better
  • I know that I am very bad at drawing concept maps, too much wordings in the map
• Remi Daigle (University of Toronto) http://swcarpentry.github.io/training-course/2015/02/loading-data-in-R/
  • I was pretty confused about the headers
  • \~45 min
  • That read.csv is really just a sub-function of read.table
  • That you really want an action word on all the links (labeled edges)
• Jessica Gallinger (University of Saskatchewan) http://swcarpentry.github.io/training-course/2015/02/data-hygiene-concept-map/
  • I did not understand how GitHub functioned whatsoever
  • \~30 minutes
  • What to include in the subject area (using the lesson plan)
  • The variety of ways people represent their ideas
• Javier Garcia-Algarra (UPM, Madrid, Spain) http://swcarpentry.github.io/training-course/2015/02/dataframe-conceptmap/
  • about 60 minutes
  • I am not very good explaining sw concepts with graphs
• Donna Henderson (University of Oxford) http://swcarpentry.github.io/training-course/2015/02/relative-and-absolute-paths/
  • info about the format to add images and links
  • about 30 minutes
  • not sure, I'll come back to this
  • how different people associate command to the concepts in different ways, ie if a command is a node or an edge
• John Constable (Wellcome Trust Sanger Institute) http://swcarpentry.github.io/training-course/submissions/round-12/1/2015-02-24-files-and-directories.html
  • I would have liked the overview available to start with to help me make sense of the 'why', plus it wasn't clear about the jenkins integration was needed for offline viewing, not 'published' website
  • about 2 hours including reading the referenced paper to get the details of concept map and a couple of abortive attempts
  • I (re)learned about how inodes work!
  • I learned how hard it is to reduce concept to 7+/- concepts, and how the relationship link is so hard to define simply
• Burke Squires (NIAID) https://github.com/swcarpentry/training-course/blob/gh-pages/_submissions/round-12/1/2015-02-26-concept-map-functions-in-python.md
  • Nothing
  • 2 - 3 hours; wish I could have used OmniGraffle!
  • What (if anything) you learned about your topic from doing your concept map (i.e., what do you now understand more clearly about your subject)
  • How differently people see the same concepts and communicate them - functions in python
• Narayanan Raghupathy (The Jackson Lab) http://swcarpentry.github.io/training-course/2015/02/python-conditionals-concept-map/
  • nothing
  • about an hour to choose a topic & get the hang of concept map and an hour to get the map
  • the connections among different things in my topic and how I can not cram all the things I want to teach in just 10 mins.
  • looking at other people's concept maps helped me to learn how I could have done better and also it made clear regarding git concepts
• Arvind Sundaram (Norwegian Sequencing Centre) http://swcarpentry.github.io/training-course/2015/02/git-github-collaboration/
  • Information about blogs have been clear till now
  • 4-5 hours to think (while doing other things) about the topic and 30 mins to draw
  • concept is much clearer to me than before
  • confirms that everyone has their own perspective of the same concept
• Heather Gibling http://swcarpentry.github.io/training-course/2015/02/heather-gibling/
  • linking to images – is HTML the only way? Or can the 'markdown' way be used?
  • \~1 hour thinking/drawing + \~1 hour revising
  • branches can be broken down into 3 basic types
  • less text is more visually appealing and easier to understand (less intimidating)
• Pawel Pomorski (University of Waterloo) http://swcarpentry.github.io/training-course/2015/02/test-driven-development/
  • 2 hours thinking, 20 minutes drawing (had to redo the drawing as first one ended up too much like a flowchart)
  • doing concept map for the first time showed me how this can be useful in figuring out the order in which interconnected concepts should be taught
  • would be more useful for material that is completely unknown to me
  • hard to decide how much text to include in the concept map (speed of drawing vs. understanding by others)
• Owen Stephens (Owen Stephens Consulting) http://swcarpentry.github.io/training-course/2015/02/dataframes-in-r/
  • Happy publishing blog posts
  • 1 hour to think about topic, <30 minutes to draw. Did one draft and then a 'good' version
  • Looking at comparable lessons there were some opportunities I missed in mine - especially triggering previous learning for the viewer

15:00 Eastern

• Sarah W (college) http://swcarpentry.github.io/training-course/2015/02/what-is-git-and-setup/
  • where a template is located, maybe a bit about the headers, and the naming for the permanent links, perhaps a bit about more Git / github
  • \~ an hour (I kept revising)
  • I learned that even looking and drawing a very small part of the lesson was still incredibly involved.
  • Looking at the other maps, I found it very interesting that sometimes people's brains were inserting steps in that I couldn't see or understand. Sometimes my brain couldn't make the link. I'm sure I did the same thing in my map.
• Matt Dickenson http://swcarpentry.github.io/training-course/submissions/round-12/1/2015-02-23-functions-in-python.html
  • To double-check that the image actually worked
  • About 3-4 hours
  • To better elaborate connections between concepts (edges in the concept map)
  • The importance of making conceptually central topics also visually central in the map
• Matthew Bourque (Space Telescope Science Institute) http://swcarpentry.github.io/training-course/2015/02/sql-select-statement/
  • To be cautious about image sizes
  • A little over an hour
  • How to limit the level of detail so that the concept is not too overwhelming
  • Maps about the same concept can differ significantly, as people approach the same problem in different ways
• Catherine Devlin (18F) http://swcarpentry.github.io/training-course/2015/02/null/
  • I'm good with publishing blog posts, been doing it for a while
  • Concept map took me about 1.5 hours - so much longer than I expected!
  • Better understand relationship between line-by-line effects of 3-value logic and its implications for full result sets
  • It's really hard to keep a concept map's scope under control!
• Belinda Weaver (The University of Queensland, Brisbane, Australia) http://swcarpentry.github.io/training-course/2015/02/concept-map-for-Git/
  • Not much really - having done the first I could copy the header which I did struggle with on the first one
  • Embarrassingly long - hours - lots of revisions and I still wasn't happy - I am a linear person not a picture person
  • I did see more connections as I went on trying to visualise it in different ways - seeing other people's maps also helped with that. I also discussed my map with a colleague who helped me reconceptualise it
  • That other people do concept maps much better than I can ;) - I learned a lot by looking at so many
• Sarah Stevens (University of Wisconsin - Madison) http://swcarpentry.github.io/training-course/2015/02/python-if-conditional/
  • Maybe a little more info about how the post must be formatted and then stitches to the blog
  • 30 min.- 1 hr.
  • I feel I better understand how connected the different concepts are to one another. They are connected as such in my mind but I think I would normally try to lay it out more linearly for a new student and forget to try and connect them back.
  • I learned that the concept map is very reflective of the different ways people think. Even given some sort of structure, it is a bit different for each person.
• Kim Moir (Mozilla) http://swcarpentry.github.io/training-course/2015/02/pipes-and-filters/
  • publishing seemed fine, had to resize the images
  • An hour. I found it really difficult.
  • how to break up the concepts into discrete parts
  • other people are really good at it! Can take a look of thought and detail. I prefer the simpler ones. The ones with too much detail can be overwhelming.
• Sue McClatchy (The Jackson Laboratory) http://swcarpentry.github.io/training-course/2015/02/creating-functions-in-R/
  • A simple link to the blog would have been very helpful. I tried to figure out how to do it using the command line, then after receiving Greg's follow-up e-mail realized that it was nothing more than adding comments to a blog.
  • It took me about 2 hours to read the lesson, consider the concepts involved, arrange them into an initial draft concept map, then upgrade to a final map.
  • I understood how the pieces of this concept fit together. I'd never considered how curly brackets relate to a function call, for example.
  • I learned that we all organize our thinking differently. I knew this already but had never seen it graphically.
• John Pormann (Duke University Libraries) http://imgur.com/mhdWbIq (pull request is still pending)
  • maybe not necessary: but more details on how it all fits together
  • 20-30 min; I've done mindmaps before
  • I hadn't thought to use them as a learning assessment tool
  • I might like mindmaps better (more emphasis on color/drawing/connections), but perhaps less useful as a learning tool
• Malvika Sharan (University of Würzburg, Germany) https://github.com/swcarpentry/training-course/blob/3597697a2ee84acf4f70911ac236cd3a4c74bdd3/_submissions/round-12/1/2015-02-26-Python_dict_ConceptMap.md
  • Do not hurry in committing the changes and work through the terminal rather than the github pages directly.
  • more than 5 trials and several pages for a simple concept map which i did not expect as i considered myself good at drawing :)
  • Drawing a concept map is hard in the beginning but its a good way to put all the features/idea related to a topic on a page and re-visit the ideas that i rarely use.
  • To draw my concept map i looked/refereed at others map, some of the concept maps were very complicated to understand compared to the concept itself, but some of them were neat and easy to understand: I learnt not to use too many boxes for the concept map, it can overwhelm people, its better to break the concept in smaller concepts and explain them individually.
• Jon Borrelli (Stony Brook University) http://swcarpentry.github.io/training-course/2015/02/Conditional-Statements/
  • I wish I had known about including the header information
  • About 30 minutes but 2 attempts
  • I found out I need to think more about connections between concepts and that the way I have been thinking about it may make it more difficult to understand if you had never thought about conditionals before.
  • From what I looked at it seems very important to think more about how specific concepts are connected, often we tend to clump concepts together when they should be separate boxes that are connected.
• Martin Bentley (NMMU) http://swcarpentry.github.io/training-course/2015/02/git-remote/
  • The blog posting seemed pretty straightforward. I just used the template, and found out that github pages used jekyll, so I looked that up anyway. No real trouble.
  • I took about 30 minutes to get something workable, and then had fairly minimal suggestions for revision, so was able to make those changes in about 15 minutes or so.
  • The idea was relatively solid in my head, but it did help me to make some things more concrete.
  • That it is quite blurry to draw a line between "concept map" and "flow chart", if you are making a concept map about a process.
• Peter Fields (University of Basel) https://swcarpentry.github.io/training-course/2015/02/unix-shell-files-directories/
  • The blog posting was relatively straightforward. Probably the aspect I was least familiar with was the use of a fork. The literature available through github made execution of the updating of the fork easy though.
  • In total time for the creation of the concept map was about 2 hours. This included looking at example plots, and then determining which of the lessons I felt most comfortable with. I had initially thought of doing more complicated lessons but then I felt less comfortable with how well I might actually understand the more advanced lessons.
  • I'm not sure I learned a great deal more about the concept, perhaps as the result my answer to question two. It did make think a bit more about how a person newer to Unix might try to understand the concept, perhaps linking it to things they knew more about.
  • I learned a lot about a number of different concepts, and reinforced others I knew something already about. But there certainly were clear instances of emphasis on things that I may not have made.
• John Moreau (University of Missouri-Kansas City) http://swcarpentry.github.io/training-course/2015/02/tables-records-and-fields/
  • What I wish Greg had told you about publishing blog posts on GitHub
    • What is markup and how does it work? I don't actually know why what I did worked. I just sort of blindly copied what I saw in other files.
  • How long it took you to do your concept map (thinking + drawing + revising)
    • Maybe 30 minutes?
  • What (if anything) you learned about your topic or how to teach it from doing your concept map (i.e., what do you now understand more clearly about your subject)
    • It can be quite hard to make meaningful connections to past knowledge
    • Starting from the basics might be too basic for some learners (or not?)
  • What you learned about drawing concept maps from the ones you looked at
    • There are a lot of different ways to draw a concept map! I always thought of concept maps as using circles. It's a weird thing to assume and makes me question what else I'm assuming about the right way to do things.
    • I also felt like I had too little content for a good concept map?
    • Concept maps without edge labels were much harder to interpret
    • It can be quite easy to include a term without defining it because the author overestimates their expertise.
• Andrew MacDonald (University of British Columbia) http://swcarpentry.github.io/training-course/2015/02/what-is-a-commit/
  • 1) that you're supposed to have a header and 2) do be careful not to use the same URL as somebody else, or you will clobber their post (sorry Michael)
  • My concept map took about 1hr - 30 mins to choose something, 10 to draw it an 20min trying to find a way to get it into a computer. <This sounds familiar. mtb
  • I think I improved my thinking about my topic (which was "What is a commit"). I feel like many of the other concept maps that I saw were covering something too large. I'm also confused about how as SWC instructors we are going to use concept maps: are we supposed to draw them in front of a room of students? Do we use them to organize our thinking before we create a SWC lesson?

19:00 Eastern

• Elizabeth Wickes, UIUC (http://swcarpentry.github.io/training-course/2015/02/files-in-git/)
  • Took about an hour to go through the materials, reference how to create them in the book, and figure out my scope.
  • I feel like I have a better understanding of the git vocabulary
  • header metadata formatting
• Luke Johnston, University of Toronto, http://swcarpentry.github.io/training-course/2015/02/why-use-r-functions/
  • I use gh-pages already so I can't say what Greg might have missed
  • \~1hr
  • Forced me to think about how I would lay out how I would teach it
  • That people have different ideas of how to set up a concept map, tho I really do think a well-developed concept map can speak a thousand words
• Kristopher Keipert (IAState) (http://swcarpentry.github.io/training-course/2015/02/pipes-in-bash-2/)
  • Permalink rules
  • \~45 minutes (20min thinking, 10min drawing, 15min revising)
  • I reinforced links between information that were already there. Being self-aware of the linkages between concepts will likely help me convey the information to others.
  • It is difficult for me to distinguish between a concept map and a flow chart
• Amy Boyle (Washington State University) http://swcarpentry.github.io/training-course/2015/02/pipes-are-rad/
  • \~1.5 hour
  • Got me to think about how all the pieces connect more, and how I would explain that to others
  • I'm actually pretty comfortable on Github, I use gh-pages for my personal blog
  • It was interesting to see how people organize information in their brain differently than me for the same subject
• Dirk Eddelbuettel http://swcarpentry.github.io/training-course/2015/02/modifying-variables-in-R/
  • I co-run a similar jekyll-based "blog" at http://gallery.rcpp.org so was familiar before
  • Maybe 30 to 45 mins.
  • Not much, but I cheated and took an easy topic
  • I am not yet sold on concept maps, but I do like visual sketches.
• Auriel Fournier http://swcarpentry.github.io/training-course/2015/02/git-conflict/
  • probably 45 minutes or so
  • It helped me visualize it better, and explain it better to others
  • How the headers worked,
  • I probably don't have the level of mastery I need to really match together the big ideas and concepts. I'm still going the long way through things.
• Brian Magill (SSAI) http://swcarpentry.github.io/training-course/2015/02/python-errors-exceptions-concept-map/
  • a few hours
  • I had a better idea of the different types of Exceptions
  • After I got the hang of it, posting on GitHub wasn't that bad.
  • It helps to have the both the concepts and connections labeled
• Evgenij Belikov (Heriot-Watt University) http://swcarpentry.github.io/training-course/2015/02/function-concept-map/
  • some more info on markdown/Jekyll
  • ca. 1h
  • justifying the use of functions is easier based on making relations to other concepts (e.g. code quality) and teaching from general to specific following the hierarchy of the concept map
  • few concepts usually chosen by most people but few different concepts and relations came up in different maps
• Dorota Jarecka (University of Warsaw / National Center for Atmospheric Research) http://swcarpentry.github.io/training-course/2015/02/shell-scripts/
  • a few days spend thinking around 10min and the last day still
  • needed around 1.5h
  • have learned that people use different amount of details
• April Clyburne-Sherin (The Hospital for Sick Children) http://swcarpentry.github.io/training-course/2015/02/tracking-changes-to-files/
  • It took me about 2 hours to do my concept map.
  • It really helped solidify how staging and tracking files works! I also think it helped me learn how to explain tracking files in git.
  • I wish I had known about the '!' infront of the link when posting to the blog, but had a comment help me out, which was nice.
  • I learned that it is really difficult to create a concept map rather than a flow-chart, or hierarchy chart. Teasing out the concepts requires a more in-depth understanding of the lesson than I originally thought.
• Kathy Chung (U of Toronto alum) https://swcarpentry.github.io/training-course/2015/02/git-repos-and-basic-commands/ (sent PR for resized image but it hasn't been merged yet, as of 3 March)
  • concept map took about 2-3+ hrs?
  • what I learnt re. topic (git repos & commands): thinking about relationships btw the repos, I realise I'm fuzzy about how collaborators resolve conflicts when both have modified a file;
  • re. submitting blog posts:(1) how to submit comments (looks like you have to create a ?discus? [can't remember name] account before your comments show up; (2) I had trouble using the search function on the blog page [tried with three different browsers: chrome, firefox, IE]. I wanted to find posts by Greg and found it hard to do so (3) keep the images small
  • Re concept maps: it's hard to identity or decide which are the concepts, what makes a concept, and how to label relationships. For example, I found, looking at other people's concept maps, that what some people consider concepts seem to me relationships or actions
• Will Cornwell (UNSW, Australia) [pull request still needs to be merged]
  • Concept map took about 30 min.
  • Did learn something about how to present how to explain how different classes in R need to be dealt with in different ways
  • I didn't totally understand whether the concept map was supposed to out conceptual understanding of the subject–as we would explain it to students–versus representing what is the in lesson. Also still don't understand when the headers are necessary
  • Seems to be some conceptual differences about what a concept map is
• Kai Yang (U of Washington) (pull request still needs to be merged)
  • At current moment (6 pm EST) my concept map posting did have chance to be listed on http://swcarpentry.github.io/training-course/submissions/round-12/index.html, although I received acknowledgment for my pull request a week ago. The gap between pull request and merge sounds a black box to me. Maybe Greg is able to provide a mechanism to make the workflow easier to trace.
  • I spent around four hours to work and polish my concept map.
  • The concept map helped me to clarify how to present the topic rather than learn the topic.
  • Since I am studying graph databases (another hot NoSQL), I particularly paid attention to how people presented concept map with a graph. From this exercise, I realized graph data modeling is not as straightforward as vendors claimed.
• Horacio Vargas (Max Planck Institute of Polymer Researcholymer Research) [pull request still needs to be merged]
  • there are some outstanding fixes needed I believe
• Tessa Pierce (Scripps Institution of Oceanography)
  • no requests about blog posts on github - I've been looking into this a fair bit in trying to make my own blog
  • 1-2 hrs
  • Learned from my concept map: it's difficult to condense your knowledge into a simple but comprehensive graphical representation
  • Learned from other's concept maps: shapes, layout etc can be helpful in distinguishing concepts from processes
• Laurie Baker (Glasgow University)
  • 20 minutes
  • I realize now that I made my concept map more of a flow chart. Seeing other people's made me see how you could use the concept as a guide for people work flow or to show them how different aspects relate.
  • I liked how some people wrote on the connectors to explain the relationship and integrated different aspects of their map. For example using an outer larger circle to encompass things that went on within a certain part of git hub.
• Stephanie Mark(University of Toronto) http://swcarpentry.github.io/training-course/2015/02/stephanie-mark/
  • \~15 min
  • I learned that what I was thinking of as concepts were not concepts but rather processes and what I thought were processes turned out to be the concepts
  • I wish Greg had given some more specific info about posting images online
  • What I learned from other people's maps was that it's useful to include many kinds of information
• Fran Navarro (University of Alicante, Spain) http://swcarpentry.github.io/training-course/2015/02/mutable-immutable-python-concept-map/
  • 1-2 h
  • I was surprised by the variety of concept maps I have seen. It seems that this idea is more likely an individual exercise. I guess with practise better concept maps (i.e. understandable to anyone, better formatting, etc) can be drawn.
  • PR can be directly updated from source (I learnt this before, but it could have been a problem 2 weeks ago)
  • I think I (finally) understood better the topic addressed (immutable vs mutable). This one has resisted me since I learnt programming with a language that didn't care about this.
• Matthew Collins, http://swcarpentry.github.io/training-course/2015/02/programming-with-databases/
  • How long it took - Maybe 30-40 min
  • What (if anything) you learned I read a bit more about what a cursor actually is and contains
  • What I wish Greg had told - PRs should be made on branches
  • What I learned from others - They should be smaller :) and color is helpful
• Richard Kip (UC Santa Barbara) http://swcarpentry.github.io/training-course/2015/02/unix-files-directories/
  • it took about 60 minutes to create the map
  • What I learned: its tough to distill even things you know well to a map
  • What Greg should have told about Github: branches
  • looking at toher maps help me refine mine (making it more concise)
• Derek Howard (Hospital for Sick Children):
  • http://swcarpentry.github.io/training-course/2015/02/collaborating-with-git/
  • \~1hr
  • What you learned: Difficulty in deciding what information should be left out
  • What I wish Greg told me about publishing blog posts on GitHub:
  • What I learned from others:Legibility and colour is important.
• Darya Vanichkina (University of Queensland, Australia) http://swcarpentry.github.io/training-course/2015/02/25/creatingfunctionsR-conceptmap/
  • How long it took you to do your concept map (thinking + drawing + revising)
    • 20 minutes. Did 2 drafts, since the first time around my layout was completely hairball
  • What (if anything) you learned about your topic or how to teach it from doing your concept map
    • Made it clearer in my mind as to how the concepts link, hence easier to teach
  • What I wish Greg had told you about publishing blog posts on GitHub
    • Nothing really, I run a personal website on github, so I've had to figure out how to get jekyll/md to work when setting that up (which was FRUSTRATING)
  • What did you learn from drawing your concept map (i.e., what do you now understand more clearly about your subject)
    • How to teach it.
  • What I learned from others: how differently different people see even the same simple topic.

Notes 2015-03-05

• Feedback about concept maps
  • What you leave out is as important as what you put in.
    • Scope control.
    • You can use "blank spaces" in concept maps, indicating knowledge you don't plan to teach but that still relates to what you're teaching
  • You need to know what knowledge is needed for what you do.
  • Concept map can show you whether you have too much stuff that you will try and do.
• Glass's Law: any new tool or technique initially slows you down
• Two different people will draw different concept map unless they have worked together and developed a consensus approach
  • Over time, their mental models of things start to align.
• Feedback is not nearly as common in teaching as in most other things (music, paper-writing, presentation)
  • Requires a culture of trust. Need to understand how to give that feedback.
  • Getting novices to accept and give code review in some sort of formal way is relatively rare.
  • Feedback for coding\programming is standard practice in industry
• Asking questions:
  • Find a question that will indicate whether learning has occurred or not.
    • Needs to be quick.
  • Asking 'do you know X' does not actually provide assessment of knowledge or indicate depth of knowledge.
• Pair Programming
  • https://en.wikipedia.org/wiki/Pair_programming
  • \~ two people - one keyboard
    • "pilot" at the keyboard
    • navigator helping
  • the benefits of this constellation seems to take of after some weeks; they
  • also good technique to use in workshops
  • One person typing, but both people solving the problem - knowledge transfer & communication
  • Start using it early so that people won't feel like they are being singled out if you introduce it later on
  • Can let them pair with whoever they are sitting beside, but in a more structured environment better for instructor to organize pairs/groups
  • Question: Greg Wilson: suppose you are putting students in groups of 4 to work on an exercise, you know their standing in the class (i.e., their grades), how should you group them?
  • a) they choose
  • b) randomly
  • c) top 4, then next 4, etc.
  • d) striping (A, B, C, D in one group, then next A, next B, next C, next D in the next group, etc.) to get wide spread of ability in each group
  • Results:
    • Option D) give the best results for people at all levels, not just the ones at the bottom.
    • Self-select is the worst option, they will just group with their friends
    • Random works better than striking (Option C - top 4, next top 4, etc..)
    • Affect wears off after approx 6 weeks
  • when setting up a workshop check that pairing up is easy
  • Every relationship between concepts could be a concept on its own (the words on the arrows could be boxes)
• Concept maps
  • What you leave out of them is also important
• Formative vs. summative assessment
  • Good teaching requires rapid feedback so see if/where the teaching failed
  • you want a formative assesment - while the teaching take place
  • MCQ - Multiple choice question
    • can be useful if properly designed
    • bad: do not help to learn about be misconceptions of the learner; lack of diagnostic power
    • good: one right answer and 3-4 plausible distractors
  • Advantage - they are fast
  • Example of good multiple choice Q: What is 27 + 15?
    • a) 42
    • b) 32
    • c) 312
    • d) 33
  • Each wrong answer typifies a common mistake made when learning multi-digit addition and so provides a diagnostic tool for tackling issues in the class
  • Much better than having MCQ answers where one answer is right and the others are incorrect but don't give any clue to what has been misunderstood
  • This is a bad one:
    • 27 + 15 = ?
      • a) 42
      • b) 1001
      • c) -5
      • d) a fish!
  • There is no way to link a wrong answer to a particular misconception, unlike the first one.
  • MCQ design requires thought about likely misconceptions. (It's like unit testing on your class!) - thus drives better lesson design (like TDD) (Or designing an experiment)
  • Use MCQ \~4 times in a class of one hour
    • Can put question up using projector
      • Answers can be done using
        • fingers (1 to 4 for each answer)
        • sticky notes
        • letters on a card
  • OpenUK has an example of excellent online assessment
  • Most of the time we are at the speed of the most advance learners. With MCQ we have feedback if we leave learner behind
  • casual, rough-looking forms of feedback help defuse the adversarial feeling that "I'm being evaluated!"
  • morale will significantly go up and learning improves as learners feel that the teacher cares about their learning
  • Peer instructions
• https://en.wikipedia.org/wiki/Peer_instruction
  • Motivation: If group of learners understood a concept they all understand it the same; if they did not understand it they might understand different parts
  • Video: http://blog.peerinstruction.net/2013/05/06/a-two-minute-video-shows-the-power-of-using-peer-instruction-to-flip-your-classroom/
  • Scales much better than broadcast-style instruction!
  • This may slow down the amount of material you can "cover", but now you're matching the actual speed of learning
  • Peer instruction:
  • ask MCQ
  • Have people answer/vote
  • In groups each tries to convince the others that their answer is the correct one
  • Vote again
  • Give correct answer
  • Have groups discuss again - members can identify where others are misunderstanding
    • Misconceptions are most likely to be unique to each person.
    • Working together with a peer is likely to highlight these.
  • Mixing people of different abilities gives good results, because the top is forced to explain things to the bottom. Teaching is a great way to learn.