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.

or is it oriented towards the ongoing development of a "beginner's mind"?

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.