Date: Thu, 28 Mar 2024 06:22:40 -0500 (CDT) Message-ID: <1206084495.29662.1711624960674@PUBEDFIPRDWEB5.public.local> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_29661_1560348861.1711624960673" ------=_Part_29661_1560348861.1711624960673 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Ed-Fi Working Draft 2: Learning App Tool Usage
Technical Suite: Suite 3
Status: Active
By: Ed-Fi Assessment Work Group
Contact: eric.jansson@ed-fi.org
Publication Date: June 22, 2020=
span>
These materials propose a simple design for= capturing and exchanging data on learning app usage. The designs here= focus on simplified metrics around learning app usage by individuals such = as times, durations, basic indicators of activity or content area, and lear= ning standards alignment. This design is not focused on detailed telemetry = or "event stream" capture either in terms of the granularity of interaction= s or the periodicity of the capture.
Contents
The number of options for software tools to= deliver and assess instruction as well as to provide interventions has gro= wn exponentially, but within this growth teachers and district administrato= rs do not have access to basic data on the usage of these tools. A set of b= asic data on learning tool usage would assist in making decisions rega= rding redeploying, increasing, sustaining, or transitioning from these tool= s within school district programs.
There is also a growing policy movement to = require administrators to use school improvement funding for programs that = meet evidence standards, such as that released under the 2015 authorization= of ESSA. As a result of these changes, instructional programs are increasi= ngly conducting and providing research-based evidence as a matter of genera= l practice.
The designs here focus on capture transfer = of what might be termed "granular aggregates."
As such, the design uses simplified concepts such as "TimeOnSystem" and = "LearningAppActivity" that represent more coarse-grained elements in the st= udent's interaction.
The proposed data model is shown below. There are three main entities:= p>
Proposed key fields are shown in italics. Student would be part of the k= ey on LearningAppUsage, and LearningAppSession would inherit all key fields= of LearningAppUsage.
Figure 1: data model diagram (click to= expand).
It is assumed that each of these entities would be bound to a REST-ful A= PI providing CRUD operations. Authorization could be driven by either the p= rovider namespace (the namespace on LearningApp) or by access to the studen= ts records (via the Student reference on the supplied entities).