English

What is the technology stack of Learning Navigator?

NLC embraces open-source technologies in realizing the Navigator and at a broad-level following are the guiding design principles used:
- Microservices architecture for better scale
- RESTful API with JSON responses to access core features
- Consistent API design for ease of development
- Open-source technologies at all layers of solution
- Queuing over message bus for communication across microservices
- Localization support
- Scalable with minimum footprint
- Deploy not tied to custom infrastructure
Consequently, the choice of technology reflects the same:
- Ubuntu Linux OS is the choice of development and deploy environment
- Java-based microservices implementation
- Postgres database as a primary datastore
- ElasticSearch extensions for search engine
- Postgres based datastore for analytics data
- Kafka as a message bus for data relay across microservices
- AWS hosting environment, leverage at infra-level and not custom services
- Github for source code management
- Atlassian Bamboo for CI/CD
- Atlassian Jira for product backlog, releases, and bug tracking

Who collaborates with NLC?

Any entity interested in adopting and implementing Navigated Learning. This includes the use of the Navigator tools and platform, adopting a competency-based approach to learning, and an interest in measuring learning Impact.

What papers and publications exist?

You can review a list of research publications here: https://gooru.org/about/research-publications/

Ownership of IP from the research?

Everything stays in public domain

How often will the openly licensed educational resources be reviewed and refreshed?

One of the many benefits of OER is the ability to update and refresh instructional materials. Instructional teams and classroom teachers that implement new instructional materials convene regularly to review and assess the current resources, add new ones, and remove outdated or ineffective resources. Districts aggregate feedback from classroom teachers throughout the year. All of the information is used to evaluate and refresh resources.

What should application developers (who will extend Navigator and make contributions to core solution — more of engineering team extension) should be prepared for?

Partners should have a good understanding of microservices architecture
Partners should have a good understanding of RESTful API design
Partners should have a good understanding of Java-based implementations
Partners should have a good understanding of front-end implementations based on EmberJS

What should Technology Partners (who will use Navigator in closed environment while extending workflows) should be prepared for?

Partners need to have an understanding of SSO models and should be using an identity provisioning system that can be configured at Navigator for SSO flows.
Partners should be able to share their roster data in OneRoster standards format, or via ClassLink Roster API.
Partners should be able to understand competency-based learning models, bring in the frameworks of interest, and be able to map the frameworks to other similar frameworks.
Partners should be able to identify, create, and curate content relevant to the competency model of interest; and be able to setup content working together with other NLC Partners.
Partners should be able to use shared API that requires an understanding of RESTful services and sync/async mechanisms to extend any workflows in their products to bring Navigator into play.
Partners should be able to push data (either as xAPI or Navigator specific data-in format) via shared API.
Partners should be able to sync data (either LTI outcomes or xAPI or Navigator specific data-out format) to their system via a shared API model.
Partners should be able to design deploy architecture based on guidance from other NLC Partners and should have expertise on AWS services, hosting & infra-manage.

What should Technology Partners (who will use our API layer to extend workflows) be prepared for?

Partners need to have an understanding of SSO models and should be using an identity provisioning system that can be configured at Navigator for SSO flows.
Partners should be able to share their roster data in OneRoster standards format, or via ClassLink Roster API.
Partners should be able to understand competency-based learning models, bring in the frameworks of interest, and be able to map the frameworks to other similar frameworks.
Partners should be able to identify, create, and curate content relevant to the competency model of interest; and be able to setup content working together with NLC.
Partners should be able to use shared API that requires an understanding of RESTful services and sync/async mechanisms to extend any workflows in their products to bring Navigator into play.
Partners should be able to push data (either as xAPI or Navigator specific data-in format) via shared API.
Partners should be able to sync data (either LTI outcomes or xAPI or Navigator specific data-out format) to their system via a shared API model.

What tool or rubric are you using for the quality assurance of instructional materials?

Gooru courses have undergone a badging process to ensure they meet standards for content quality and that they support personalized learning and instruction. Resources are evaluated against the Gooru Quality Content Rubric, and are peer-reviewed to ensure the course is an exemplary representation of the district or organization that designed and implemented it.

How is quality implemented and assessed? What is the vetting or review process for content?

The Gooru catalog was originally scaffolded with content from highly recommended educational websites and then supplemented with resources acquired through content partnerships. Organizations such as the Schusterman Foundation, Cisco, The Hewlett Foundation, and Lockheed Martin provide funding and expert advice to support the creation of quality content.
Before they are added to Gooru, resources are vetted in a multi-step process. The Gooru team monitors newly uploaded resources to ensure the content is appropriate and adheres to the “wiki” model, in which users share communal responsibility to keep Gooru safe and appropriate for student use. In addition, Gooru works to feature resources with significant educational value and without aggressive advertising.