Kits is an effort to modernize the learning technology ecosystem around NGDLE concepts.
The current state of Learning Technologies has focused primarily on meeting faculty's teaching needs through the Learning Management System.
This contradicts our vision of the ideal university IT and academic culture. A culture of technological plurality and choice.
For university IT, relying on any single solution, including the LMS, is a short-sighted strategy that provides suboptimal learning experience as a monolithic system cannot provide the best learning experience for all aspects of all learning communities.
The best learning happens when appropriate apps are used in conjunction with active learning pedagogies.
How Kits Works
For faculty, Kits allows them to start with the official roster of students and add folks like teaching assistants, collaborating faculty, support staff, or librarians, creating a group.
Faculty then turn on the apps they want to use with this group, and Kits gives everyone appropriate access to all the apps at once.
This combination of group + apps is called a kit.
We're starting with courses, but the kit concept can be applied to all learning experiences someone might encounter with a university.
- Provide students a unified interface for accessing the apps used by their kits
- Provide faculty a catalogue of learning technologies for use in their kits
- Allow faculty to manage membership of and technologies used by their kits
- Provide information on learning technology management and policies.
- Organize Kits to work with learning experiences from pre-matriculation to alumni learning
- Let students know what they should do next for those classes.
- Suggest apps packages, or standard sets of app combinations, to help faculty accomplish their learning objectives.
- Solicit suggestions for new apps Duke should support, then Duke can research support, automation and provisioning behind the new apps.
- Ruby on Rails - Backend Framework
- React - Frontend Framework
- Grouper - Group Management
- Shibboleth - Single Sign On
- Learning Tools Interoperability (LTI) - Integration Standard
|kit||Functionally, for the time being, a course. Technically, a context that ties a Grouper group for a roster + guests to apps used by that group. May also be referenced as a learning community|
|App||A technology used by a kit in the context of learning that is listed in /apps. Not limited to enterprise licensed technologies. School, departmental, and unlicensed apps will also be listed.|
|Ecosystem||All of the integrated technologies used for learning. Shortened synonym for Learning Technology Ecosystem.|
|User story||"As a who, I want goal so that reasons". These are the specification for design and development work. Acceptance criteria written in Gerkin These are tracked via a Github Label.||All User Stories|
|Assumption||Unknowns that require further discussion, user research, or development iterations to be known. These are tracked via a Github Label.||All Assumptions|
|Hypothesis||A question used to drive design and development deliverables that can be tested in order to learn. Help explicitly state assumptions related to user stores. These are tracked via a Github Label.||All Hypothesis|
|MVP||The minimum viable piece/thing/product/idea/design we can build to validate or invalidate a hypothesis. These are tracked via Github Milestones.||All MVP|
|Project||Github Projects are used to track sprints||Current projects|
We don't have all the answers. We can't build it all by ourselves. Whether you're in or outside of Duke, read CONTRIBUTING.md for more information on how you can contribute to this project.