- Mixing Noble Pursuits with Practicality
- Many Skill Trees Over Monolith Skill Trees
- Skill Tree Size Management
- Solving Too Many Problems at Once
- Solving the Main Problem
The following is a response to my previous post about the initial design.
Categorizing knowledge and passively building the human knowledge tree is a noble pursuit. However, practically speaking, it is unwieldy to force users to categorize a node under subjects and sub-subjects. Such categorization will result in categorization bloat. It's important to recognize that not everyone categorizes knowledge the same way. Everyone's brain is unique. Not only that, categorizations are often dynamic and change over time and across cultures.
The solution to the problem above is foregoing node categorization in favor of skill tree categorization: go back to the original idea of multiple, shareable skill trees instead of a single monolithic skill tree per user.
A large skill tree with many nodes can be either overwhelming or unmanageable. There are two ways to make skill trees manageable:
- Create an artificial limit of nodes on the skill tree
- I'm thinking of a limit of eight layers per skill tree. The problem with this is that even if I only allow binary branches from a single node, it can still result in a mess.
- Allow skill trees to be nested inside of skill trees.
- The problem with this is that the tree becomes way too messy.
It seems like the best solution is to let people create skill trees in any way they want, but reward people with affirmative audio and visuals for categorizing their nodes. We're trying to gamify learning after all.
As much as I would like for my application to be the silver bullet for education, I really should just focus on the problems I stated in an early post in that order. The first priority is to help educators make learning more fun by gamifying it through skill trees.
I was thinking of putting too much priority on solving problem 4; the "what next" in the learning process. This application was turning into a note-taking app before I knew it.
Thinking back to why I'm actually creating this, it's so that I'll be able to teach and evaluate my students in a fun and engaging way.
Each teacher will receive a teacher ID and have their own username. Their students can look up the teacher by their ID, username, or simply have a link to the skill tree that they'll be using for their class.
Each node will have a list of recommended resources: internet links, book ISBNs, PDF documents. I don't think it will be a good idea to use online evaluation. The highest quality conversations and evaluations will occur in-person between student and teacher. I'm not going to automate away tests and evaluations. There are many applications for that. Instead, there will simply be multiple choice for the student to press to indicate how much they feel like they understand a topic. Under the multiple choice, there is a feedback box that students can express what they feel uncertain on. Teachers can read the feedback box to better work on future lessons.
Pressing the "Submit Feedback" button will play a satisfying audio, visual cue where the node and background will change color based on the response.
This can be useful for university students as well as in tracking what they know and don't know for a class.
Branching nodes will be useful when the teacher goes back to the topic after going on an important tangent. In this way, students can at least visually make the connections that the teacher is making. The most creative teachers can actually make a picture with their skill trees.
The solution above is a much more laser-focused idea that is useful for both students and teachers while being accessible for everyone. It's certainly much easier to create and use in terms of a mobile application.