Tag Archives: NHL

More Fun Than Annual Class Trip: Making at School, Some First Observations

In the past weeks I’ve been part of a team working with a class of 10/11 year olds, as an experiment around increasing agency with 21st century digital skills, under the title Impact through Connection. In this I’m partnering with the NHL (university of applied sciences), and the regional Frisian library BSF, with some funding coming from the Dutch Royal Library as part of their Vision Mediasavviness 2016-2018 program. The experiment centered around helping the group to identify communal issues, situations they would like to change, and then to develop ideas and realize them. So that the group ‘gets’ that with various making and other machines and instruments, they have the agency, have the power, to change their surroundings for themselves as a group.

Since January we’ve been meeting with the school’s team, and then weekly 6 times with the class of 22 children. It was loads of fun, not just for the kids involved. The highest compliment we received was that one of them said “this is more fun than the annual school trip”. Another remarked feeling sorry that all other classes had to work, while they were making stuff. We pointed out that they too were working very hard, but differently, and that having fun does not mean you’re not working.

Yesterday we’ve had the final session, ending with presentations of the things they built (such as phone covers for phone-types that aren’t otherwise available, a way to look under water, a class room MP3 player for audiobooks, games, computer controlled door locks, a candy machine, a robot to counteract bullying, websites documenting the process, and a money system for the school).

Afterwards I returned home and jotted down a list of observations to reflect on. We plan to do a similar experiment with a group of adults from the same neighborhood as the school serves, as well as will aim to replicate it for other school classes.

First, for context, the order of the sessions we did.
Session 1: group discussion about the children’s environment, things they would like to change, ideas for making things they had. Resulted in a ‘wall of ideas’, ordered from ‘looks less hard to do’, to ‘looks harder to do’.
Session 2: getting to know maker machines (3d printers, laser cutters, electronics, etc.), by bringing the machines to the class room, and parking the Frysklab Mobile FabLab out front.
Session 3: getting to know programming (using Micro:bits, all the children got one to keep)
Session 4: Diving deeper in to the idea now they have a notion of what is possible with the machines and material available, using a canvas to think about what the idea solves, whom it is for, what part of the idea to zoom in on, and who in their own social network could help them realize it.
Session 5: building prototypes (again with Frysklab parked outside)
Session 6: building prototypes and presenting results

In non-specific order here are some of the raw observations I made in the past weeks, that we can further elaborate and chew on, to create the next iteration of this experiment.

On the process (time, time time!):

  • The school team school was extremely supportive, and the teacher showed enormous flexibility. She rearranged her normal class schedule extensively to ensure we had more time than we thought possible.
  • The process we designed worked, but we could have spent more time and attention to several parts of it.
  • The process worked in the sense that we got everyone to make things, and have them dive deep beyond the initial magic and wow of 3d-printing and laser cutters
  • We asked them to map out the groups they belonged to, and both their own and their classmate’s skills. We spent too little time to do that properly and to use it fruitfully in the process afterwards
  • We didn’t succeed in our original plan to bring the group to defining one or a few projects that were less person and more group focussed (except for the kid that designed a currency system for the school), and then select parts of that on which individuals or small groups could work. It seems we would need to spend more effort in the run-up to the cycle of sessions to do that properly
  • Working with a pool of people with specific domain knowledge that we could bring in when needed worked very well and strengthened the results
  • I used a canvas to help the group get to better defined projects, and while it worked, the steps in filling the canvas could have been better defined. Now some raced ahead, without key information for the next bits, while I worked with others to take the first few steps
  • The overall process hasn’t become clear to the group as a distinct shape, I think. Although that would enable them to design their own projects on their own (more on that later)
  • Having the children present their work to the group at the end was fun, useful and a good way to bring everything together again

P1040015 P1040013
Two filled out canvases

On our team and the teacher

  • When we look at Making, we see how it is different from what was before, how all of a sudden ‘anyone’ can do things that took specialised machines and factories earlier, and how that changes the dynamics of it all. The children don’t see it that way, because they don’t have that history. Although that history is the source of our own fascination it is not the fascination you can confer to the children, as it is by definition a meaningless comparison to them.
  • Our large pool of people to help out was necessary to be able to provide adequate guidance. Even if adding 5-7 adults to a classroom feels like a lot.
  • More clearly articulating to the group which roles team members help might be helpful (e.g. I don’t know my way around the Frysklab truck, but still got asked a lot by the kids about it. I solved it by saying, I don’t know either, let’s go find out together)
  • The teacher could likely have a more defined role during the sessions (other than trying to keep a semblance of order), maybe also in building the bridges to other parts of the curriculum in the run-up?
  • We had several preparatory meetings with the teacher and others inthe school
  • There’s a lot I can’t do (too little experience with the machines to have internalized all routines, my own thinking is often too little visual and too much textual) It’s partly a pro as well (as it makes it easy for me to led the child lead the thinking proces, as I don’t have answers either)

20170313_103243 20170313_103227
At work in the FabLab truck, and 3d printers chugging away

The path the children took

  • Large differences within the group, also in self-image, means very different speeds within the process (‘I don’t think there’s something I am really really good at’)
  • Finding out that the path from your fantasy to making it tangible reality contains disappointments (what is possible, what is realistic within time given, how does a result compare to what you imagined at first), and finding or not finding ways to surmount that disappointment
  • Not everyone was able to visualize from their ideas towards the parts that make up the whole, or different aspects and steps
  • Enormous richness in ideas, but sometimes very narrowly focussed
  • It is very important to build a bridge from the classroom project to at home (“can I take this home” “but this is something I can’t do at home”). Part of the empowerment lies here. (Also as they proudly told and partly mobilized their parents for their ideas as well)
  • They willingly left us their projects so the Frysklab team could show them on a national conference the day after the last session, after promising to return their projects soon

Visible impact and affect during the sessions

  • Really listening to ideas and trying think them through, remembering what they said about it 3 weeks earlier, is a boost in empowerment for the kids in itself
  • Children don’t have as many experience based associations and ‘hooks’ to listen to our stories, so examples are needed
  • Examples from ‘nearby’, such as the kid with a 3d printed hand prosthetic living in the neighbouring province are therefore very valuable. We need to collect many more of them.
  • Such appealing examples may also aid in bringing across the process and thinking model itself better
  • Giving everyone a Micro:bit during the process therefore turned Jeroen into a hero of everyone in the room (loud cheers!)
  • Taking things home is a source of pride
  • Other classes were jealous of this group
  • The group quickly build attachment to the team (where is Ton? Cheers when a team member arrives a bit late)
  • Concepts like ‘prototyping’ are hard, and zooming in on something small and maintaining attention is too

20170313_125512 20170313_124104
20170313_124010 20170313_124024
Some of the created projects

The making itself

  • Robots! At first almost everyone wanted to build robots (to clean their room e.g.)
  • Things for yourself, versus things for the group. As said, before the making we likely need to build a ‘ramp’ towards more communal oriented projects
  • The realization for the chidren that things take time, can be complicated. That it isn’t magic but actual work
  • The dawning notion that programming means cutting everything into tiny ‘stupid’ steps (‘like explaining it to my 3 yr old sibling’)
  • Software is equated to computers and phones. That things that don’t look like computers can be programmed, and that hard- and software are getting merged more and more (cars, IoT, robots) takes time to land
  • Likewise ‘making’ is connected to hardware, objects and software mostly. Creating ‘systems’ or ‘processes’ is a novel concept (except for the currency making project). Challenging systems is like a fish changing the water it swims in.
  • Similarly for most, their actual environment (the street, the neighborhood, city etc, are also like ‘water’ and mostly perceived as immutable. Measuring things in your environment and acting on it was notably absent in the ideas
  • The attention span needed to zoom in on a small part at a deep enough level to be able to apply it is pretty hard to maintain
  • Building websites to document projects is an essential part the children came up with themselves. Needs to become a standard component of the process.

20170313_123716 20170313_122600
Presenting results

Other circumstantial elements

  • Searching online for examples and useful material (like code snippets) can be a stronger part of the process (as answer to the frequent question “but how can I do that?”). Means paying attention to searching skills.
  • The mentioned websites can contribute to that by collecting links to resources etc.
  • Data collections didn’t play a role (likely as there were no ‘sensing’ projects), but could be a resource in other iterations
  • E-mail is not available to all children (not allowed to, don’t want to give out their parents e-mail), but often needed to register for online coding and making tools, or to create a website. Providing throw-away e-mails, like I personally do with 33Mail, is something to add to our toolkit.

Gathering the group for the final group picture

(more pics here in this Dutch language posting by the Frisian library and Frysklab team)

Student’s Six Big Data Lessons

Students from a minor ‘big data’ at the local university of applied sciences presented their projects a few weeks ago. As I had done a session with them on open data as a guest lecturer, I was invited to the final presentations. From those presentations in combination several things stood out for me. Things that I later repeated to a different group of students at the Leeuwarden university of applied sciences at the begining of their week of working on local open data projects for them to avoid. I thought I’d share them here too.

The projects students created
First of all let me quickly go through the presented projects. They were varied in types of data used, and types of issues to address:

  • A platform consulting Lithuanian businesses to target other EU markets, using migration patterns and socio-economic and market data
  • A route planner comparing car and train trips
  • A map combining buildings and address data with income per neighborhood from the statistics office to base investment decisions on
  • A project data mining Riot Games online game servers to help live-tweak game environments
  • A project combining retail data from Schiphol Airport with various other data streams (weather, delays, road traffic, social media traffic) to find patterns and interventions to increase sales
  • A project using the IMDB moviedatabase and ratings to predict whether a given team and genre have a chance of success

Patterns across the projects
Some of these projects were much better presented than others, others were more savvy in their data use. Several things stood out:

1) If you make an ‘easy’ decision on your data source it will hurt you further down your development path.

2) If you want to do ‘big data’ be really prepared to struggle with it to understand the potential and limitations

To illustrate both those points:
The Dutch national building and address database is large and complicated, so a team had opted to use the ‘easier’ processed data set released by a geodata company. Later they realized that the ‘easier’ dataset was updated only twice per year (the actual source being updated monthly), and that they needed a different coordinates system (present in the source, not in the processed data) to combine it with the data from the statistical office.

Similarly the route planner shied away from using the open realtime database on motorway traffic density and speed, opting for a derivative data source on traffic jams and then complaining that came in a format they couldn’t really re-use and did not cover all the roads they wanted to cover.
That same project used Google Maps, which is a closed data source, whereas a more detailed and fully open map is available. Google Maps comes with neat pre-configured options and services but in this case they were a hindrance, because they do not allow anything outside of it.

3) You must articulate and test your own assumptions

4) Correlation is not causation (duh!)

The output you get from working with your data is colored by the assumptions you build into your queries. Yes average neighbourhood income can likely be a predictor for certain investment decisions, but is there any indication that is the case for your type of investment, in this country? Is entering the Swedish market different for a Lithuanian company from let’s say a Greek one? What does it say about the usefulness of your datasource?

Data will tell you what happened, but not why. If airport sales of alcohol spike whenever a flight to Russia arrives or leaves (actual data pattern) can that really be attributed to the 2-300 people on that plane, or are other factors at work that may not be part of your data (intercontinental flights for instance that have roughly the same flight schedule but are not in the data set)?

Are you playing around enough with the timeline of your data, to detect e.g. seasonal patterns (like we see in big city crime), zooming out and zooming in enough, to notice that what seems a trend maybe isn’t.

5) Test your predictions, use your big data on yourself

The ‘big’ part of big data is that you are not dealing with a snapshot or a small subset (N= is a few) but with a complete timeline of the full data set (N = all). This means you can and need to test your model / algorithm / great idea on your own big data. If you think you can predict the potential of a movie, given genre and team, then test it with a movie from 2014 where you know the results (as they’re in your own dataset) on the database from before 2014 and see if your algorithm works. Did Lithuanian companies that already have entered the Swedish market fail or flourish in line with your data set? Did known past interventions into the retail experience have the impact your data patterns suggest they should?

6) Your data may be big, but does it contain what you need?

One thing I notice with government data is that most data is about what government knows (number of x, maps, locations of things, environmental measurements etc), and much less about what government does (decisions made, permits given, interventions made in any policy area). Often those are not available at all in data form but hidden somewhere in wordy meeting minutes or project plans. Financial data on spending and procurement is what comes closest to this.

Does your big data contain the things that tell what various actors around the problem you try to solve did to cause the patterns you spot in the data? The actual transactions of liquor stores connected to Russian flight’s boarding passes? The marketing decisions and their reasons for the Schiphol liquor stores? The actions of Lithuanian companies that tried different EU markets and failed or succeeded?

Issue-driven, not data-driven, and willing to do the hard bits
It was fun to work with these students, and there are a range of other things that come into play. Technical savviness, statistical skills, a real understanding of what problem you are trying to solve. It’s tempting to be data-driven, not issue-driven even if in the end that brings more value. With the former the data you have is always the right data, but with the latter you must acknowledge the limitations of your data and your own understanding.

Like I mentioned I used these lessons in a session for a different group of students in a different city, Leeuwarden. There a group worked for a week on data-related projects to support the city’s role as cultural capital of Europe in 2018. The two winning teams there both stood out because they had focussed very much on specific groups of people (international students in Leeuwarden, and elderly visitors to the city), and really tried to design solutions starting with the intended user at the center. That user-centered thinking really turned out to be the hardest part. Especially if you already have a list of available data sets in front of you. Most of the teacher’s time was spent on getting the students to match the datasets to use cases, and not the other way around.