Difference between revisions of "Features/Introduction Tutorial"
ErickLavoie (talk | contribs) |
ErickLavoie (talk | contribs) |
||
| Line 24: | Line 24: | ||
== Detailed Description == | == Detailed Description == | ||
| − | The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface | + | The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. |
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. | The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. | ||
| Line 38: | Line 38: | ||
== Benefit to Sugar == | == Benefit to Sugar == | ||
This feature should lower the barrier of entry to Sugar by making it easier to learn the platform by having to resort less to external documentation. | This feature should lower the barrier of entry to Sugar by making it easier to learn the platform by having to resort less to external documentation. | ||
| + | |||
| + | As discussed with Gerald Ardito, picking up Activities seems to work well for most students. However, getting used to the specific idioms of Sugar requires more efforts. | ||
== Scope == | == Scope == | ||
Revision as of 15:52, 13 March 2010
Summary
Provide an interactive introduction to Sugar for first-time users.
Owner
- Name: Erick Lavoie
- Email: Name above in lowercase AT gmail.com
Current status
- Targeted release: 0.90
- Last updated: 03-13-2010
- Percentage of completion: 10%
Detailed Description
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface.
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial.
The tutorial should be stored in the user home directory, alongside any activity data, as an XML file representing the execution states of the tutorial.
Translation of the tutorial should be made using the gettext convention by storing translations of the tutorial strings along side the XML file using the gettext schema (.po, .pot, .mo files).
The tutorial should be independent of the screen resolution.
For the 0.90 release, the tutorial won't be user modifiable other than by modifying the XML format by hand, which won't be recommended.
Benefit to Sugar
This feature should lower the barrier of entry to Sugar by making it easier to learn the platform by having to resort less to external documentation.
As discussed with Gerald Ardito, picking up Activities seems to work well for most students. However, getting used to the specific idioms of Sugar requires more efforts.
Scope
What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?
UI Design
Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions. This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:
The tutorial will provide an overview of the Desktop, the Group and the Neighborhood Views as well as the Frame, the Journal, the Write and the Browse activity. Here are screenshots of what it might look like for some of them.
The information presented to the user will be essentially composed of bubble messages pointing at screen elements. Progress through the tutorial will be accomplished by the user clicking a next button at the bottom of the screen. Once the tutorial is over, the user will be brought back to the Desktop screen where she will be able to resume interacting with the system normally. At any time during the tutorial, the user can press the Stop button to interrupt the current tutorial an return to the original place where she was at first.
How To Test
Features/Introduction Tutorial/Testing
User Experience
If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice.
Dependencies
What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, does your feature depend on completion of another feature owned by someone else or that you would need to coordinate, which might cause you to be unable to finish on time? Other upstream projects like Python?
Contingency Plan
If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "None necessary, revert to previous release behaviour." Or it might not. If your feature is not completed in time, we want to assure others that other parts of Sugar will not be in jeopardy.
Documentation
Is there upstream documentation on this feature, or notes you have written yourself? Has this topic been discussed in the mailing list or during a meeting? Link to that material here so other interested developers can get involved.
Release Notes
The Sugar Release Notes inform end-users about what is new in the release. An Example is 0.84/Notes. The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the release team and shipped with the release.