Difference between revisions of "Features/Teacher Buddy"

Latest revision as of 14:00, 5 November 2013

Summary

This feature provides a new field in the presence server buddy mechanism for identifying teachers.

Owner

Name: Walter Bender
Name: Gonzalo Odiard

Email: <walter AT sugarlabs DOT org> <gonzalo AT sugarlabs DOT org>

Current status

Targeted release: 1.0
Last updated: 29 July 2013
Percentage of completion: 90% (sugar3/presence/buddy.py, jarabe/model/buddy.py, and jarabe/view/buddyicon.py are finished. Need to finalize the teacher icon design and test.)

Detailed Description

For several different applications in the Features/Classroom management feature, we need to be able to identify the classroom teacher. We are proposing adding a new field to the buddy presence system to mark a buddy as a teacher. This will be used in the GUI to make it easier to find the teacher in the neighborhood view and also in some of the automated classroom management processes where activities share information with the teacher.

Benefit to Sugar

By adding a mechanism for identifying a teacher, we can automate many of the Features/Classroom management features, such as handing in assignments, sharing stats, etc.

Scope

The feature requires:

adding a new field to sugar3/presence/buddy.py
adding a new field to jarabe/model/buddy.py
a new icon for a teacher XO
a test in jarabe/view/buddyicon.py for the teacher buddy

UI Design

As a placeholder, we are using an upside-down XO icon for teacher-xo.svg

How To Test

Features/Teacher Buddy/Testing

User Experience

If the feature is not exploited, there is no change to the user experience.
The basic change to the user experience is simply a different icon to represent a teacher in the UI. The auto-detection of teachers will be exploited in the Features/Classroom management systems.
The exact mechanism for setting the teacher boolean (in gconf) is to be determined.

Dependencies

No new dependencies

Contingency Plan

No impact as this is a new feature.

Documentation

Release Notes

Comments and Discussion

See discussion tab for this feature

@@ Line 16: / Line 16: @@
 * Targeted release: 1.0
 * Last updated: 29 July 2013
-* Percentage of completion: 50% (buddy.py is finished. we need to add a corresponding mechanism for visualizing teachers in the GUI)
+* Percentage of completion: 90% (sugar3/presence/buddy.py, jarabe/model/buddy.py, and jarabe/view/buddyicon.py are finished. Need to finalize the teacher icon design and test.)
 == Detailed Description ==
+For several different applications in the [[Features/Classroom management]] feature, we need to be able to identify the classroom teacher. We are proposing adding a new field to the buddy presence system to mark a buddy as a teacher. This will be used in the GUI to make it easier to find the teacher in the neighborhood view and also in some of the automated classroom management processes where activities share information with the teacher.
 == Benefit to Sugar ==
+By adding a mechanism for identifying a teacher, we can automate many of the [[Features/Classroom management]] features, such as handing in assignments, sharing stats, etc.
 == Scope ==
 The feature requires:
 * adding a new field to sugar3/presence/buddy.py
+* adding a new field to jarabe/model/buddy.py
 * a new icon for a teacher XO
 * a test in jarabe/view/buddyicon.py for the teacher buddy
 ==UI Design==
+As a placeholder, we are using an upside-down XO icon for teacher-xo.svg
+[[Image:teacher-xo.svg]]
 == How To Test ==
@@ Line 35: / Line 41: @@
 == 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 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.
+* If the feature is not exploited, there is no change to the user experience.
+* The basic change to the user experience is simply a different icon to represent a teacher in the UI. The auto-detection of teachers will be exploited in the [[Features/Classroom management]] systems.
-:* 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?
+* The exact mechanism for setting the teacher boolean (in gconf) is to be determined.
-:* 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.
-:* is this something that is better done as a background task? If so, when and how often?
-;visualizing classroom statistics: A few different ways in which this could happen. A new activity [NEEDS TO BE WRITTEN], similar to Analyze Journal, could be written to aggregate the stats uploaded by the students into one unified visualization. Or the classroom data could be sent out to a webservice [NEEDS TO BE WRITTEN] that provides cumulative statistics.
-:* is this something that is better done as a background task? If so, when and how often?
-;setting the favorites view on a classroom full of laptops: Might be worthwhile doing from Journal Share [NEEDS TO BE WRITTEN]. Or do we want it to be background? Best if used with multi-homeview patch [https://github.com/walterbender/sugar/commit/2ffa1cf6742bdb6b70c470d21969b4f45568038e 5].
-;distributing activities to a classroom full of laptops: Seems that adding this to Journal Share would be intuitive and logical [NEEDS TO BE WRITTEN].
-;TBD: How do we identify the teacher laptop? Using the 'age' field?
-;TBD: What are the privacy concerns?
-;TBD: Is this always running? Or only running when the teacher is running Journal Share?
 == Dependencies ==
+No new dependencies
 == Contingency Plan ==
@@ Line 65: / Line 52: @@
 == Documentation ==
-Some discussions with the design team regarding the placement of the buttons on the palettes.
 == Release Notes ==