|
|
| Line 35: |
Line 35: |
| | == User Experience == | | == 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.
| + | The exact mechanism for setting the teacher boolean is to be determined. |
| | | | |
| − | :* 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 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. |
| − | :* 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 == | | == Dependencies == |
Revision as of 08:39, 29 July 2013
Summary
This feature provides a new field in the presence server buddy mechanism for identifying teachers.
Owner
- 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: 50% (buddy.py is finished. we need to add a corresponding mechanism for visualizing teachers in the GUI)
Detailed Description
Benefit to Sugar
Scope
The feature requires:
- adding a new field to sugar3/presence/buddy.py
- a new icon for a teacher XO
- a test in jarabe/view/buddyicon.py for the teacher buddy
UI Design
How To Test
Features/Teacher Buddy/Testing
User Experience
The exact mechanism for setting the teacher boolean is to be determined.
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.
Dependencies
Contingency Plan
No impact as this is a new feature.
Documentation
Some discussions with the design team regarding the placement of the buttons on the palettes.
Release Notes
Comments and Discussion