Features/Classroom management: Difference between revisions

(12 intermediate revisions by one other user not shown)

Line 3:

[[Category:Feature|Classroom management]]

</noinclude>

[[Image:AnalyzeJournal.png|300px]] [[File:ScreenshotJournalShareActivity_client.png|300px]]

== Summary ==

This feature provides an infrastructure that addresses three aspects of classroom management:

This feature provides an infrastructure that addresses three aspects of classroom visualization and management:

# sharing content between students and teachers

# visualizing activity usage by students and teachers

Line 33:

Line 35:

Above and beyond these components, we need to define a workflow by which they are used:

...

;teacher server?:Journal Share makes use of a local webserver. Should that server be repurposed for background processing? Or should we utilize a school server?

;TBD: Is this an integrated Sugar feature or one that is managed at the Sugar activity level? (Easier to customize as the latter.)

;teacher buddy: [[Features/Teacher Buddy]] is a mechanism for identifying a teacher in the network neighborhood.

== Benefit to Sugar ==

Line 48:

Line 55:

== User Experience ==

;student visualizing Journal use: Simply by launching the Analyze Journal activity, a student can see a display of their activity usage, both based on instances and ~~[NEEDS TO BE ADDED]~~ on the number of times each instance has been launched. ~~By default [NEEDS TO BE ADDED],~~ Analyze Journal ~~will save~~ a datastore object associated with the activity that contains a json-encoded summary.

;student visualizing Journal use: Simply by launching the Analyze Journal activity, a student can see a display of their activity usage, both based on instances and on the number of times each instance has been launched. Analyze Journal saves a datastore object associated with the activity that contains a json-encoded summary.

:* what additional data should be captured?

:* what additional data should be captured? Is an accumulation of launch-times per activity adequate? Do we need to worry about change over time or just the current stats?

:* is it important that this be available as a background task as well? If so, when and how often?

:* or could launching it while the teacher is running Journal Share (or some equivalent) be used as an opportunity for a background upload?

;uploading student Journal use to the teacher's laptop: Once the aforementioned modifications to Analyze Journal are made, the Journal Share mechanism could be used directly to upload a student's activity usage to the teacher.

Line 68:

Line 76:

;TBD: What are the privacy concerns?

;TBD: Is this always running? Or only running when the teacher is running Journal Share?

== Dependencies ==

@@ Line 3: / Line 3: @@
 [[Category:Feature|Classroom management]]
 </noinclude>
+[[Image:AnalyzeJournal.png|300px]] [[File:ScreenshotJournalShareActivity_client.png|300px]]
 == Summary ==
-This feature provides an infrastructure that addresses three aspects of classroom management:
+This feature provides an infrastructure that addresses three aspects of classroom visualization and management:
 # sharing content between students and teachers
 # visualizing activity usage by students and teachers
@@ Line 33: / Line 35: @@
 Above and beyond these components, we need to define a workflow by which they are used:
-...
+;teacher server?:Journal Share makes use of a local webserver. Should that server be repurposed for background processing? Or should we utilize a school server?
+;TBD: Is this an integrated Sugar feature or one that is managed at the Sugar activity level? (Easier to customize as the latter.)
+;teacher buddy: [[Features/Teacher Buddy]] is a mechanism for identifying a teacher in the network neighborhood.
 == Benefit to Sugar ==
@@ Line 48: / Line 55: @@
 == User Experience ==
-;student visualizing Journal use: Simply by launching the Analyze Journal activity, a student can see a display of their activity usage, both based on instances and [NEEDS TO BE ADDED] on the number of times each instance has been launched. By default [NEEDS TO BE ADDED], Analyze Journal will save a datastore object associated with the activity that contains a json-encoded summary.
+;student visualizing Journal use: Simply by launching the Analyze Journal activity, a student can see a display of their activity usage, both based on instances and on the number of times each instance has been launched. Analyze Journal saves a datastore object associated with the activity that contains a json-encoded summary.
-:* what additional data should be captured?
+:* what additional data should be captured? Is an accumulation of launch-times per activity adequate? Do we need to worry about change over time or just the current stats?
 :* is it important that this be available as a background task as well? If so, when and how often?
+:* or could launching it while the teacher is running Journal Share (or some equivalent) be used as an opportunity for a background upload?
 ;uploading student Journal use to the teacher's laptop: Once the aforementioned modifications to Analyze Journal are made, the Journal Share mechanism could be used directly to upload a student's activity usage to the teacher.
@@ Line 68: / Line 76: @@
 ;TBD: What are the privacy concerns?
+;TBD: Is this always running? Or only running when the teacher is running Journal Share?
 == Dependencies ==