Rahul Bhargava and I just co-authored an article in the Journal of Community Informatics called Design Principles, Tools and Activities for Data Literacy Learners. In it, we make the case that most tools that help people work with data prioritize flashy visualizations and outputs rather than helping to scaffold a learning process. This ends up making the process of data analysis like a black box (especially for people from non-technical backgrounds). We pose the question - what would it be like if we designed tools for learners rather than users? We offer four qualities that a tool designed for learners should aspire to be: focused, guided, inviting, and expandable and we go on to talk about Databasic.io as a case study. Databasic is what I showed at Barnraising 2015 and consists of four suite simple tools that help explain basic concepts of analyzing and interpreting data.****Here are the four qualities:
A focused tool strives to do one thing well. These tools are easily learnable and relatively constrained. Focused tools do not provide many types of options, and thus can provide a low entry point for data literacy learners. They create a small playground that is rich enough for the learner to play within, but not so rich that they get lost.
A guided tool is introduced with strong activities to get the learner started. Blank-slate websites and software packages require novice users to imagine usage scenarios. Guided tools combat this by introducing themselves with an activity that holds the learner's hand as they get started. These tools might immediately present an on-ramp for learners via example data and example outputs.
An inviting tool is introduced in a way that is appealing to the learner. This might involve using data on a topic that is relevant or meaningful to them, or simply using humor and playfulness to invite the learner to experiment. Inviting tools make conscious decisions about visual design, user interface and copywriting to offer a consistent, appealing, and non-intimidating invitation to the learner. Inviting activities use familiar materials to produce playful outputs that attract interest and excitement from learners.
An expandable tool is appropriate for the learner's abilities, but also offers them paths to deeper learning (perhaps by leaving the tool and graduating to more complicated tools). They overcome a single-minded focus by including call-outs and capabilities that allow the learner an opportunity and pathway to learn more about how the tool works. Expandable tools recognize that they are steps along the path to building stronger data literacy for the learner, and help bridge from previous work to next steps.
I'm posting this short synopsis here to see if they may have relevance to design considerations for Public Lab tools, especially ones that we consider introductory for new members to the community. For example, I think that the balloon mapping kit and the coquí fit these qualities really nicely, especially now that we have some nice introductory guides (ok yes, I'm bragging about the tutorial that I made with @akshaya) for using them.
I'm curious what others think - when does a DIY environmental science tool need to be designed for learners?
PS - Our paper is part of a special issue on data literacy published by the Journal of Community Informatics. Those of you interested in the topic might enjoy some of the other papers.
10 Comments
I love this framework, thank you!!
I guess though that I wonder what prevents a learner's tool from being a user's tool -- thinking of Scratch here -- and whether all users of tools are learners and remain so through most of their usage of a tool. That doesn't affect your framing of these four types, of course, but it might have bearing on PL methods -- one difference might be whether a learner's tool is not flexible enough to be used beyond a learning context?
Is this a question? Click here to post it to the Questions page.
Also, v important question: what color would your next tool in this suite be? Purple? :-)
Is this a question? Click here to post it to the Questions page.
Yes - I think to some extent all tools should probably be designed for learners. But certain very large and very flexible tools are bad/intimidating for beginning learners but great for more experienced users (I'm thinking of things like GIS software for mapping or Photoshop for graphics or Tableau in the data realm). One of the things we've been thinking about is how to scaffold people to learn the terminology and process and some of the inner workings related to data so that they can "graduate" to the flexible/complex tools that can make many kinds of outputs. And there's always design decisions for how much of the "inner workings" the learner actually needs to learn versus what can be productively hidden for reasons of simplicity and focus.
And yes - I think purple or hot pink would have to be the next tool color :D
I've been thinking more about this and recalled Sara Hendren's great piece All Technology is Assistive, which I love.
I started thinking that there's something related to what you're describing as well -- which I have yet to articulate fully in my hear. Perhaps it's that if we thought of all technology addressing newcomers, or learners, that would be a productive framework. I mean, so much of expertise is non-linear -- although even Harry Collins talks about experts and non-experts in the sense of a spectrum, within a group of experts, there are many different understandings of the same body of information. Both experts and learners are adapting to, and learning from, one anothers' viewpoints.
I'm thinking that if we design as if all technology is for newcomers, it's not just the newcomers who gain. In some ways, our #first-timers-only and other #software-outreach strategies are bearing this out -- we've been observing that the specific practices that go into making a first-timers-only issue are also beneficial for those who know a great deal about the codebase, or about programming. They lead to good practices in terms of code modularization, of clean and legible interfaces between different functions, and to breaking complex problems up into self-contained, testable, re-usable solutions.
I don't know if this is generalizable, but I'm tempted to look closer. The same aspects that make our code easier for newcomers to contribute to are powerful ones for coders of all levels, and in many ways it's the "experts" who often think they don't have to follow such strict conventions because they're "good enough" to just hold it all in their heads at once -- which can lead to buggy, unmaintainable and unreadable code.
I think I have to stew on this a bit more, but I guess one thing that strikes me is that I used to think that making engaging onboarding pathways was something only bigger, high-capacity projects could take on, and that it'd be faster to "just get things done" before inviting others in. After the past six months of our new software outreach initiatives, I think the opposite is true -- the only way to build enough capacity to get things done quickly is to treat every problem as one you can help someone else tackle.
Whoa, that was a lot! I'm also curious to hear from @cindy_excites or @hagitkeysar on this topic, they having spent a great deal of time thinking through some of these issues.
Hello @kanarinka I couldn't access the paper to read it (their sever seems to be having issues right now) so this is just a quick note to say that if you had not seed them already, a lot of these things have been discussed by: Blikstein 2013 Digital Fabrication and ‘Making’ in Education: The Democratization of Invention https://tltl.stanford.edu/publications/papers-or-book-chapters/digital-fabrication-and-making-democratization-invention Gerstein 2016 Becoming a Maker Educator https://www.questia.com/magazine/1G1-466298228/becoming-a-maker-educator and Kolb and Kolb 2005 Learning styles and learning spaces: Enhancing experiential learning in higher education https://www.researchgate.net/profile/David_Kolb/publication/201381976_Learning_Styles_and_Learning_Spaces_Enhancing_Experiential_Learning_in_Higher_Education/links/0c96052ab8d5142c1b000000.pdf
Thanks @Cindy_Excites - these are super resources and I have not seen them previously. I wonder how the emerging field of data literacy could borrow from this work around maker communities and digital fabrication education. We have definitely been using some of the same folks - Dewey, Freire, bell hooks, Papert - for inspiration.
@warren - I love this - "I'm thinking that if we design as if all technology is for newcomers, it's not just the newcomers who gain" and how you are starting to apply this to open source software development. One of the things I've realized as an educator is that my understanding of any topic is deepened by teaching it to someone else. I often have students teach things to the class and to each other. So I totally agree that "oldtimers" can learn a great deal by acting as mentors/guides/facilitators into a technology and/or community.
Thanks for copying me in this discussion! I especially like the direction you are taking here - you not only talk about how to create literacy, where there is lack of, but about how to provoke learning and affect that are distributed more equally between learners, designers, and users. We are all learners!
I am thinking that even when you do a really great job at designing for learners you always keep on creating experts that share a common language that, with complexity, becomes more and more exclusive. So designing for learners or newcomers is a step in the process of learning/engaging or is it oriented towards the ongoing development of a "beginner's mind"?
In other words, I am asking whether designing for learners/newcomers is a methodology (oriented towards a particular purpose: learning to code, work with data) or can we think about it as technology in its own right?
I am not sure I am clear in regard to the difference, and I know you can help me here with your questions and thoughts. But I am thinking about the transformative, political potentials of designing for learners. From my interpretation, it comes across from the conversation above that designing for learners can be a way to develop a 'common language' for collaborative/civic tech development (that is, if we are all learners), in which both designers and those-who-are-defined-as-learners see this as a a technology for how to become a learner.
Is this a question? Click here to post it to the Questions page.
Love this! That even if nobody is reading (learning) from your shared work, you are changing the knowledge in your own understanding, potentially to your benefit.
Another phrase occurred to me with regard to the tendency to create new experts and jargon - that of "storing less in your brain" -- that is, being conscious of whether you're using knowledge (of context, perhaps) which isn't being recorded or exchanged, or if you're providing that extra information when you're communicating your knowledge, so that you or someone else can fully access and engage with what you're sharing.
Maybe this is not quite clearly articulated, but I just love the idea of preserving your "beginner's mind" as you develop expertise. It allows for such empiricism when others read or use your work.
Is this a question? Click here to post it to the Questions page.
Ok - less in your brain maybe needs more elaboration: how about "remembering to leave contextual notes to your future self so you can pick your work back up later" as one way of unlocking the implicit knowledge that it's difficult to remember to share when you're exchanging knowledge with others.
You must be logged in to comment.