<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.sugarlabs.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=ErickLavoie</id>
	<title>Sugar Labs - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.sugarlabs.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=ErickLavoie"/>
	<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/go/Special:Contributions/ErickLavoie"/>
	<updated>2026-05-16T22:10:41Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.43.0</generator>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=51472</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=51472"/>
		<updated>2010-04-26T13:53:56Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Documentation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: Undefined&lt;br /&gt;
* Last updated: 04-26-2010&lt;br /&gt;
* Percentage of completion: Suspended&lt;br /&gt;
&lt;br /&gt;
Note: Due to a higher than expected work requirement at the master level, I&#039;ll be suspending work on Tutorius indefinitely.  I&#039;ll leave the page here, so that the idea is still available.  Should anybody want to have more information on how Tutorius was working, I&#039;ll be glad to share.&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
The tutorial should be stored as an XML file representing the execution states of the tutorial.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having an interactive tutorial.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
Most of the work has already been done as part of the Tutorius project that ended on December 2009. However, there is still some work to do before the existing system can reliably be integrated to Sugar.  The modifications to Sugar as well as the work to be done is outlined below.&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays, and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The tutorius service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base to the following files:&lt;br /&gt;
* sugar:bin/sugar-session (Add the tutorius service)&lt;br /&gt;
* sugar:src/jarabe/frame/frame.py (Add an Overlay and a Probe)&lt;br /&gt;
* sugar:src/journal/journalactivity.py (Add a Probe)&lt;br /&gt;
* sugar-toolkit:src/sugar/activity/activity.py (Add a Probe)&lt;br /&gt;
* sugar-toolkit:src/sugar/graphics/window.py (Add an Overlay)&lt;br /&gt;
&lt;br /&gt;
In addition to the previous modifications:&lt;br /&gt;
* The tutorius files should be found under the sugar.tutorius module. &lt;br /&gt;
* Some icons will be added.  &lt;br /&gt;
* The tutorial will be stored under ./sugar/default/tutorius in the user home directory.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
# Define an [[Features/Introduction_Tutorial/Script | exact script]] for the introduction tutorial&lt;br /&gt;
# Rebase the existing Tutorius code base on top of Sugar 0.88&lt;br /&gt;
# Create a reliable [[Features/Introduction_Tutorial/Overlay | Overlay]] for all the different Views and the Frame&lt;br /&gt;
# Make the Message Bubble position relative to the screen size&lt;br /&gt;
# Make sure the current localization mecanism is reliable &lt;br /&gt;
# Add the logging screen option (See UI Mocks)&lt;br /&gt;
# Add the option item to replay the introduction tutorial (See UI Mocks)&lt;br /&gt;
# Produce a tutorial&lt;br /&gt;
# Translate the tutorial in French&lt;br /&gt;
# Write documentation for the translation team&lt;br /&gt;
&lt;br /&gt;
The only risky item is the creation of a reliable Overlay for the different Views. For a technical description of what it involves, see [[Features/Introduction_Tutorial/Overlay]]. Any help from GTK gurus in the community is welcome, as our last attempt at this was unsuccessful.&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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 and return to the place she was when she started the tutorial.&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Source Code ==&lt;br /&gt;
&lt;br /&gt;
* http://git.sugarlabs.org/projects/tutorius&lt;br /&gt;
&lt;br /&gt;
Forks of sugar components:&lt;br /&gt;
* http://git.sugarlabs.org/projects/sugar-toolkit/repos/sugar-toolkit-tutorius&lt;br /&gt;
* http://git.sugarlabs.org/projects/sugar/repos/tutorius&lt;br /&gt;
* http://git.sugarlabs.org/projects/sugar-jhbuild/repos/tutorius&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=51471</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=51471"/>
		<updated>2010-04-26T13:50:04Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Current status */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: Undefined&lt;br /&gt;
* Last updated: 04-26-2010&lt;br /&gt;
* Percentage of completion: Suspended&lt;br /&gt;
&lt;br /&gt;
Note: Due to a higher than expected work requirement at the master level, I&#039;ll be suspending work on Tutorius indefinitely.  I&#039;ll leave the page here, so that the idea is still available.  Should anybody want to have more information on how Tutorius was working, I&#039;ll be glad to share.&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
The tutorial should be stored as an XML file representing the execution states of the tutorial.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having an interactive tutorial.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
Most of the work has already been done as part of the Tutorius project that ended on December 2009. However, there is still some work to do before the existing system can reliably be integrated to Sugar.  The modifications to Sugar as well as the work to be done is outlined below.&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays, and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The tutorius service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base to the following files:&lt;br /&gt;
* sugar:bin/sugar-session (Add the tutorius service)&lt;br /&gt;
* sugar:src/jarabe/frame/frame.py (Add an Overlay and a Probe)&lt;br /&gt;
* sugar:src/journal/journalactivity.py (Add a Probe)&lt;br /&gt;
* sugar-toolkit:src/sugar/activity/activity.py (Add a Probe)&lt;br /&gt;
* sugar-toolkit:src/sugar/graphics/window.py (Add an Overlay)&lt;br /&gt;
&lt;br /&gt;
In addition to the previous modifications:&lt;br /&gt;
* The tutorius files should be found under the sugar.tutorius module. &lt;br /&gt;
* Some icons will be added.  &lt;br /&gt;
* The tutorial will be stored under ./sugar/default/tutorius in the user home directory.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
# Define an [[Features/Introduction_Tutorial/Script | exact script]] for the introduction tutorial&lt;br /&gt;
# Rebase the existing Tutorius code base on top of Sugar 0.88&lt;br /&gt;
# Create a reliable [[Features/Introduction_Tutorial/Overlay | Overlay]] for all the different Views and the Frame&lt;br /&gt;
# Make the Message Bubble position relative to the screen size&lt;br /&gt;
# Make sure the current localization mecanism is reliable &lt;br /&gt;
# Add the logging screen option (See UI Mocks)&lt;br /&gt;
# Add the option item to replay the introduction tutorial (See UI Mocks)&lt;br /&gt;
# Produce a tutorial&lt;br /&gt;
# Translate the tutorial in French&lt;br /&gt;
# Write documentation for the translation team&lt;br /&gt;
&lt;br /&gt;
The only risky item is the creation of a reliable Overlay for the different Views. For a technical description of what it involves, see [[Features/Introduction_Tutorial/Overlay]]. Any help from GTK gurus in the community is welcome, as our last attempt at this was unsuccessful.&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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 and return to the place she was when she started the tutorial.&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=File:Introduction_Tutorial_Desktop.svg&amp;diff=49816</id>
		<title>File:Introduction Tutorial Desktop.svg</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=File:Introduction_Tutorial_Desktop.svg&amp;diff=49816"/>
		<updated>2010-03-14T05:28:01Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: Mock up for a Tutorial shown on the Desktop.

Autor: Erick Lavoie&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Mock up for a Tutorial shown on the Desktop.&lt;br /&gt;
&lt;br /&gt;
Autor: Erick Lavoie&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49815</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49815"/>
		<updated>2010-03-14T05:21:50Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Scope */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
The tutorial should be stored as an XML file representing the execution states of the tutorial.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having an interactive tutorial.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
Most of the work has already been done as part of the Tutorius project that ended on December 2009. However, there is still some work to do before the existing system can reliably be integrated to Sugar.  The modifications to Sugar as well as the work to be done is outlined below.&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays, and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The tutorius service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base to the following files:&lt;br /&gt;
* sugar:bin/sugar-session (Add the tutorius service)&lt;br /&gt;
* sugar:src/jarabe/frame/frame.py (Add an Overlay and a Probe)&lt;br /&gt;
* sugar:src/journal/journalactivity.py (Add a Probe)&lt;br /&gt;
* sugar-toolkit:src/sugar/activity/activity.py (Add a Probe)&lt;br /&gt;
* sugar-toolkit:src/sugar/graphics/window.py (Add an Overlay)&lt;br /&gt;
&lt;br /&gt;
In addition to the previous modifications:&lt;br /&gt;
* The tutorius files should be found under the sugar.tutorius module. &lt;br /&gt;
* Some icons will be added.  &lt;br /&gt;
* The tutorial will be stored under ./sugar/default/tutorius in the user home directory.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
# Define an [[Features/Introduction_Tutorial/Script | exact script]] for the introduction tutorial&lt;br /&gt;
# Rebase the existing Tutorius code base on top of Sugar 0.88&lt;br /&gt;
# Create a reliable [[Features/Introduction_Tutorial/Overlay | Overlay]] for all the different Views and the Frame&lt;br /&gt;
# Make the Message Bubble position relative to the screen size&lt;br /&gt;
# Make sure the current localization mecanism is reliable &lt;br /&gt;
# Add the logging screen option (See UI Mocks)&lt;br /&gt;
# Add the option item to replay the introduction tutorial (See UI Mocks)&lt;br /&gt;
# Produce a tutorial&lt;br /&gt;
# Translate the tutorial in French&lt;br /&gt;
# Write documentation for the translation team&lt;br /&gt;
&lt;br /&gt;
The only risky item is the creation of a reliable Overlay for the different Views. For a technical description of what it involves, see [[Features/Introduction_Tutorial/Overlay]]. Any help from GTK gurus in the community is welcome, as our last attempt at this was unsuccessful.&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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 and return to the place she was when she started the tutorial.&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49814</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49814"/>
		<updated>2010-03-14T05:20:36Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Detailed Description */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
The tutorial should be stored as an XML file representing the execution states of the tutorial.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having an interactive tutorial.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
Most of the work has already been done as part of the Tutorius project that ended on December 2009. However, there is still some work to do before the existing system can be reliably integrated to Sugar.  The modifications to Sugar as well as the work to be done is outlined below.&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays, and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The tutorius service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base to the following files:&lt;br /&gt;
* sugar:bin/sugar-session (Add the tutorius service)&lt;br /&gt;
* sugar:src/jarabe/frame/frame.py (Add an Overlay and a Probe)&lt;br /&gt;
* sugar:src/journal/journalactivity.py (Add a Probe)&lt;br /&gt;
* sugar-toolkit:src/sugar/activity/activity.py (Add a Probe)&lt;br /&gt;
* sugar-toolkit:src/sugar/graphics/window.py (Add an Overlay)&lt;br /&gt;
&lt;br /&gt;
In addition to the previous modifications:&lt;br /&gt;
* The tutorius files should be found under the sugar.tutorius module. &lt;br /&gt;
* Some icons will be added.  &lt;br /&gt;
* The tutorial will be stored under ./sugar/default/tutorius in the user home directory.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
# Define an [[Features/Introduction_Tutorial/Script | exact script]] for the introduction tutorial&lt;br /&gt;
# Rebase the existing Tutorius code base on top of Sugar 0.88&lt;br /&gt;
# Create a reliable [[Features/Introduction_Tutorial/Overlay | Overlay]] for all the different Views and the Frame&lt;br /&gt;
# Make the Message Bubble position relative to the screen size&lt;br /&gt;
# Make sure the current localization mecanism is reliable &lt;br /&gt;
# Add the logging screen option (See UI Mocks)&lt;br /&gt;
# Add the option item to replay the introduction tutorial (See UI Mocks)&lt;br /&gt;
# Produce a tutorial&lt;br /&gt;
# Translate the tutorial in French&lt;br /&gt;
# Write documentation for the translation team&lt;br /&gt;
&lt;br /&gt;
The only risky item is the creation of a reliable Overlay for the different Views. For a technical description of what it involves, see [[Features/Introduction_Tutorial/Overlay]]. Any help from GTK gurus in the community is welcome, as our last attempt at this was unsuccessful.&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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 and return to the place she was when she started the tutorial.&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49813</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49813"/>
		<updated>2010-03-14T05:18:54Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Tasks */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having an interactive tutorial.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
Most of the work has already been done as part of the Tutorius project that ended on December 2009. However, there is still some work to do before the existing system can be reliably integrated to Sugar.  The modifications to Sugar as well as the work to be done is outlined below.&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays, and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The tutorius service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base to the following files:&lt;br /&gt;
* sugar:bin/sugar-session (Add the tutorius service)&lt;br /&gt;
* sugar:src/jarabe/frame/frame.py (Add an Overlay and a Probe)&lt;br /&gt;
* sugar:src/journal/journalactivity.py (Add a Probe)&lt;br /&gt;
* sugar-toolkit:src/sugar/activity/activity.py (Add a Probe)&lt;br /&gt;
* sugar-toolkit:src/sugar/graphics/window.py (Add an Overlay)&lt;br /&gt;
&lt;br /&gt;
In addition to the previous modifications:&lt;br /&gt;
* The tutorius files should be found under the sugar.tutorius module. &lt;br /&gt;
* Some icons will be added.  &lt;br /&gt;
* The tutorial will be stored under ./sugar/default/tutorius in the user home directory.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
# Define an [[Features/Introduction_Tutorial/Script | exact script]] for the introduction tutorial&lt;br /&gt;
# Rebase the existing Tutorius code base on top of Sugar 0.88&lt;br /&gt;
# Create a reliable [[Features/Introduction_Tutorial/Overlay | Overlay]] for all the different Views and the Frame&lt;br /&gt;
# Make the Message Bubble position relative to the screen size&lt;br /&gt;
# Make sure the current localization mecanism is reliable &lt;br /&gt;
# Add the logging screen option (See UI Mocks)&lt;br /&gt;
# Add the option item to replay the introduction tutorial (See UI Mocks)&lt;br /&gt;
# Produce a tutorial&lt;br /&gt;
# Translate the tutorial in French&lt;br /&gt;
# Write documentation for the translation team&lt;br /&gt;
&lt;br /&gt;
The only risky item is the creation of a reliable Overlay for the different Views. For a technical description of what it involves, see [[Features/Introduction_Tutorial/Overlay]]. Any help from GTK gurus in the community is welcome, as our last attempt at this was unsuccessful.&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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 and return to the place she was when she started the tutorial.&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49812</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49812"/>
		<updated>2010-03-14T05:17:50Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Sugar Modifications */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having an interactive tutorial.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
Most of the work has already been done as part of the Tutorius project that ended on December 2009. However, there is still some work to do before the existing system can be reliably integrated to Sugar.  The modifications to Sugar as well as the work to be done is outlined below.&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays, and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The tutorius service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base to the following files:&lt;br /&gt;
* sugar:bin/sugar-session (Add the tutorius service)&lt;br /&gt;
* sugar:src/jarabe/frame/frame.py (Add an Overlay and a Probe)&lt;br /&gt;
* sugar:src/journal/journalactivity.py (Add a Probe)&lt;br /&gt;
* sugar-toolkit:src/sugar/activity/activity.py (Add a Probe)&lt;br /&gt;
* sugar-toolkit:src/sugar/graphics/window.py (Add an Overlay)&lt;br /&gt;
&lt;br /&gt;
In addition to the previous modifications:&lt;br /&gt;
* The tutorius files should be found under the sugar.tutorius module. &lt;br /&gt;
* Some icons will be added.  &lt;br /&gt;
* The tutorial will be stored under ./sugar/default/tutorius in the user home directory.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
# Define an [[Features/Introduction_Tutorial/Script | exact script]] for the introduction tutorial&lt;br /&gt;
# Rebase the existing Tutorius code base on top of Sugar 0.88&lt;br /&gt;
# Create a reliable [[Features/Introduction_Tutorial/Overlay | Overlay]] for all the different Views and the Frame&lt;br /&gt;
# Make the Message Bubble position relative to the screen size&lt;br /&gt;
# Make sure the current localization mecanism is reliable &lt;br /&gt;
# Add the logging screen option (See UI Mocks)&lt;br /&gt;
# Add the option item to replay the introduction tutorial (See UI Mocks)&lt;br /&gt;
# Produce a tutorial&lt;br /&gt;
# Translate the tutorial in French&lt;br /&gt;
# Write documentation for the translation team&lt;br /&gt;
&lt;br /&gt;
The only risky item is the creation of a reliable Overlay for the different Views. For a technical description of what it involves, see [[Features/Introduction_Tutorial/Overlay]]. Any help from GTK gurus in the community is welcomed as our last attempt at this was unsuccessful.&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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 and return to the place she was when she started the tutorial.&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49811</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49811"/>
		<updated>2010-03-14T05:16:43Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Sugar Modifications */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having an interactive tutorial.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
Most of the work has already been done as part of the Tutorius project that ended on December 2009. However, there is still some work to do before the existing system can be reliably integrated to Sugar.  The modifications to Sugar as well as the work to be done is outlined below.&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays, and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base to the following files:&lt;br /&gt;
* sugar:bin/sugar-session (Add the tutorius service)&lt;br /&gt;
* sugar:src/jarabe/frame/frame.py (Add an Overlay and a Probe)&lt;br /&gt;
* sugar:src/journal/journalactivity.py (Add a Probe)&lt;br /&gt;
* sugar-toolkit:src/sugar/activity/activity.py (Add a Probe)&lt;br /&gt;
* sugar-toolkit:src/sugar/graphics/window.py (Add an Overlay)&lt;br /&gt;
&lt;br /&gt;
In addition to the previous modifications:&lt;br /&gt;
* The tutorius files should be found under the sugar.tutorius module. &lt;br /&gt;
* Some icons will be added.  &lt;br /&gt;
* The tutorial will be stored under ./sugar/default/tutorius in the user home directory.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
# Define an [[Features/Introduction_Tutorial/Script | exact script]] for the introduction tutorial&lt;br /&gt;
# Rebase the existing Tutorius code base on top of Sugar 0.88&lt;br /&gt;
# Create a reliable [[Features/Introduction_Tutorial/Overlay | Overlay]] for all the different Views and the Frame&lt;br /&gt;
# Make the Message Bubble position relative to the screen size&lt;br /&gt;
# Make sure the current localization mecanism is reliable &lt;br /&gt;
# Add the logging screen option (See UI Mocks)&lt;br /&gt;
# Add the option item to replay the introduction tutorial (See UI Mocks)&lt;br /&gt;
# Produce a tutorial&lt;br /&gt;
# Translate the tutorial in French&lt;br /&gt;
# Write documentation for the translation team&lt;br /&gt;
&lt;br /&gt;
The only risky item is the creation of a reliable Overlay for the different Views. For a technical description of what it involves, see [[Features/Introduction_Tutorial/Overlay]]. Any help from GTK gurus in the community is welcomed as our last attempt at this was unsuccessful.&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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 and return to the place she was when she started the tutorial.&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49810</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49810"/>
		<updated>2010-03-14T04:59:43Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Scope */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having an interactive tutorial.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
Most of the work has already been done as part of the Tutorius project that ended on December 2009. However, there is still some work to do before the existing system can be reliably integrated to Sugar.  The modifications to Sugar as well as the work to be done is outlined below.&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays, and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base but add a number of new files and concepts.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
# Define an [[Features/Introduction_Tutorial/Script | exact script]] for the introduction tutorial&lt;br /&gt;
# Rebase the existing Tutorius code base on top of Sugar 0.88&lt;br /&gt;
# Create a reliable [[Features/Introduction_Tutorial/Overlay | Overlay]] for all the different Views and the Frame&lt;br /&gt;
# Make the Message Bubble position relative to the screen size&lt;br /&gt;
# Make sure the current localization mecanism is reliable &lt;br /&gt;
# Add the logging screen option (See UI Mocks)&lt;br /&gt;
# Add the option item to replay the introduction tutorial (See UI Mocks)&lt;br /&gt;
# Produce a tutorial&lt;br /&gt;
# Translate the tutorial in French&lt;br /&gt;
# Write documentation for the translation team&lt;br /&gt;
&lt;br /&gt;
The only risky item is the creation of a reliable Overlay for the different Views. For a technical description of what it involves, see [[Features/Introduction_Tutorial/Overlay]]. Any help from GTK gurus in the community is welcomed as our last attempt at this was unsuccessful.&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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 and return to the place she was when she started the tutorial.&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49809</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49809"/>
		<updated>2010-03-14T04:57:44Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* UI Design */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having an interactive tutorial.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Most of the work has already been done as part of the Tutorius project that ended on December 2009. However, there is still some work to do before the existing system can be reliably integrated to Sugar.  The modifications to Sugar as well as the work to be done is outlined below.&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays, and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base but add a number of new files and concepts.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
# Define an [[Features/Introduction_Tutorial/Script | exact script]] for the introduction tutorial&lt;br /&gt;
# Rebase the existing Tutorius code base on top of Sugar 0.88&lt;br /&gt;
# Create a reliable [[Features/Introduction_Tutorial/Overlay | Overlay]] for all the different Views and the Frame&lt;br /&gt;
# Make the Message Bubble position relative to the screen size&lt;br /&gt;
# Make sure the current localization mecanism is reliable &lt;br /&gt;
# Add the logging screen option (See UI Mocks)&lt;br /&gt;
# Add the option item to replay the introduction tutorial (See UI Mocks)&lt;br /&gt;
# Produce a tutorial&lt;br /&gt;
# Translate the tutorial in French&lt;br /&gt;
# Write documentation for the translation team&lt;br /&gt;
&lt;br /&gt;
The only risky item is the creation of a reliable Overlay for the different Views. For a technical description of what it involves, see [[Features/Introduction_Tutorial/Overlay]]. Any help from GTK gurus in the community is welcomed as our last attempt at this was unsuccessful.&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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 and return to the place she was when she started the tutorial.&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49808</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49808"/>
		<updated>2010-03-14T04:56:01Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Sugar Modifications */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having an interactive tutorial.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Most of the work has already been done as part of the Tutorius project that ended on December 2009. However, there is still some work to do before the existing system can be reliably integrated to Sugar.  The modifications to Sugar as well as the work to be done is outlined below.&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays, and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base but add a number of new files and concepts.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
# Define an [[Features/Introduction_Tutorial/Script | exact script]] for the introduction tutorial&lt;br /&gt;
# Rebase the existing Tutorius code base on top of Sugar 0.88&lt;br /&gt;
# Create a reliable [[Features/Introduction_Tutorial/Overlay | Overlay]] for all the different Views and the Frame&lt;br /&gt;
# Make the Message Bubble position relative to the screen size&lt;br /&gt;
# Make sure the current localization mecanism is reliable &lt;br /&gt;
# Add the logging screen option (See UI Mocks)&lt;br /&gt;
# Add the option item to replay the introduction tutorial (See UI Mocks)&lt;br /&gt;
# Produce a tutorial&lt;br /&gt;
# Translate the tutorial in French&lt;br /&gt;
# Write documentation for the translation team&lt;br /&gt;
&lt;br /&gt;
The only risky item is the creation of a reliable Overlay for the different Views. For a technical description of what it involves, see [[Features/Introduction_Tutorial/Overlay]]. Any help from GTK gurus in the community is welcomed as our last attempt at this was unsuccessful.&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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 and return to the original place where she was at first.&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial/Overlay&amp;diff=49807</id>
		<title>Features/Introduction Tutorial/Overlay</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial/Overlay&amp;diff=49807"/>
		<updated>2010-03-14T04:53:22Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Conceptually, the Overlays should be seen as additional layers in the desktop rendering, as shown in the following diagram.  An explanation of the expected behavior for each layer follows.&lt;br /&gt;
&lt;br /&gt;
[[File:Introduction Tutorial Overlayer.svg | center | 700px]]&lt;br /&gt;
&lt;br /&gt;
Currently, the behavior of the Sugar Shell exhibits an implicit 3 layer structure.  The Activity/View displays things on layer &amp;quot;5&amp;quot;.  Sometimes, like for Journal entries, a popup menu will show up at layer 3.  The Frame still show up on top of that pop-up at layer 2. To allow showing tutoring elements we need at least two other layers, one for the Frame (1) and one for Activities/Views (4).  In the future, we might even like to have another Layer to display tutoring elements on top of popup menus but for now those are not strictly needed. The Frame Overlay should hide and show with the Frame. Each Activity and View should have its own Overlay that would also hide and show with it.&lt;br /&gt;
&lt;br /&gt;
The order of the layers should stay the same, even if the Frame is shown/hidden and even if Views/Activities are switched.&lt;br /&gt;
&lt;br /&gt;
=== Issues ===&lt;br /&gt;
&lt;br /&gt;
The main problem we had trying to implement that layering is caused by the relative order of windows used by GTK. It is possible to add a constraint on a window so that it always shows on top of another but we haven&#039;t found a way to force a window to be &amp;quot;sandwiched&amp;quot; between two others.  From the little experiments we did, it seems that sometimes, windows are fighting to be on top. Also, when switching views, the corresponding overlays would simply disappear.  We guess the ordering of the windows was not preserved. I guess there might be a way to achieve it using Composition but at this point, I don&#039;t know if it is supported by Sugar and how it should be implemented. I will have a second try at this in the next weeks.  In the meantime, if anyone has an idea how to implement it is welcome to add a code sample/patch on this page.&lt;br /&gt;
&lt;br /&gt;
Also, the extra windows induced by overlays are seen as &amp;quot;Activities&amp;quot; in the activity tray (grey dots).  I have not yet found a way to prevent those from being displayed. Any suggestion is welcomed.&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial/Overlay&amp;diff=49806</id>
		<title>Features/Introduction Tutorial/Overlay</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial/Overlay&amp;diff=49806"/>
		<updated>2010-03-14T04:13:05Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: Created page with &amp;#039; 700px&amp;#039;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[File:Introduction Tutorial Overlayer.svg | center | 700px]]&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=File:Introduction_Tutorial_Overlayer.svg&amp;diff=49805</id>
		<title>File:Introduction Tutorial Overlayer.svg</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=File:Introduction_Tutorial_Overlayer.svg&amp;diff=49805"/>
		<updated>2010-03-14T04:07:42Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: uploaded a new version of &amp;quot;File:Introduction Tutorial Overlayer.svg&amp;quot;:&amp;amp;#32;Fixed a rendering issue for a text box&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{PD-self}}&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=File:Introduction_Tutorial_Overlayer.svg&amp;diff=49804</id>
		<title>File:Introduction Tutorial Overlayer.svg</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=File:Introduction_Tutorial_Overlayer.svg&amp;diff=49804"/>
		<updated>2010-03-14T04:06:02Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: {{PD-self}}&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{PD-self}}&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49803</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49803"/>
		<updated>2010-03-14T03:13:22Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Benefit to Sugar */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having an interactive tutorial.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Most of the work has already been done as part of the Tutorius project that ended on December 2009. However, there is still some work to do before the existing system can be reliably integrated to Sugar.  The modifications to Sugar as well as the work to be done is outlined below.&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base but add a number of new files and concepts.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
# Define an [[Features/Introduction_Tutorial/Script | exact script]] for the introduction tutorial&lt;br /&gt;
# Rebase the existing Tutorius code base on top of Sugar 0.88&lt;br /&gt;
# Create a reliable [[Features/Introduction_Tutorial/Overlay | Overlay]] for all the different Views and the Frame&lt;br /&gt;
# Make the Message Bubble position relative to the screen size&lt;br /&gt;
# Make sure the current localization mecanism is reliable &lt;br /&gt;
# Add the logging screen option (See UI Mocks)&lt;br /&gt;
# Add the option item to replay the introduction tutorial (See UI Mocks)&lt;br /&gt;
# Produce a tutorial&lt;br /&gt;
# Translate the tutorial in French&lt;br /&gt;
# Write documentation for the translation team&lt;br /&gt;
&lt;br /&gt;
The only risky item is the creation of a reliable Overlay for the different Views. For a technical description of what it involves, see [[Features/Introduction_Tutorial/Overlay]]. Any help from GTK gurus in the community is welcomed as our last attempt at this was unsuccessful.&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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 and return to the original place where she was at first.&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49802</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49802"/>
		<updated>2010-03-14T03:11:02Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* UI Design */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having tutorials.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Most of the work has already been done as part of the Tutorius project that ended on December 2009. However, there is still some work to do before the existing system can be reliably integrated to Sugar.  The modifications to Sugar as well as the work to be done is outlined below.&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base but add a number of new files and concepts.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
# Define an [[Features/Introduction_Tutorial/Script | exact script]] for the introduction tutorial&lt;br /&gt;
# Rebase the existing Tutorius code base on top of Sugar 0.88&lt;br /&gt;
# Create a reliable [[Features/Introduction_Tutorial/Overlay | Overlay]] for all the different Views and the Frame&lt;br /&gt;
# Make the Message Bubble position relative to the screen size&lt;br /&gt;
# Make sure the current localization mecanism is reliable &lt;br /&gt;
# Add the logging screen option (See UI Mocks)&lt;br /&gt;
# Add the option item to replay the introduction tutorial (See UI Mocks)&lt;br /&gt;
# Produce a tutorial&lt;br /&gt;
# Translate the tutorial in French&lt;br /&gt;
# Write documentation for the translation team&lt;br /&gt;
&lt;br /&gt;
The only risky item is the creation of a reliable Overlay for the different Views. For a technical description of what it involves, see [[Features/Introduction_Tutorial/Overlay]]. Any help from GTK gurus in the community is welcomed as our last attempt at this was unsuccessful.&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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 and return to the original place where she was at first.&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49800</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49800"/>
		<updated>2010-03-14T03:07:44Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* UI Design */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having tutorials.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Most of the work has already been done as part of the Tutorius project that ended on December 2009. However, there is still some work to do before the existing system can be reliably integrated to Sugar.  The modifications to Sugar as well as the work to be done is outlined below.&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base but add a number of new files and concepts.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
# Define an [[Features/Introduction_Tutorial/Script | exact script]] for the introduction tutorial&lt;br /&gt;
# Rebase the existing Tutorius code base on top of Sugar 0.88&lt;br /&gt;
# Create a reliable [[Features/Introduction_Tutorial/Overlay | Overlay]] for all the different Views and the Frame&lt;br /&gt;
# Make the Message Bubble position relative to the screen size&lt;br /&gt;
# Make sure the current localization mecanism is reliable &lt;br /&gt;
# Add the logging screen option (See UI Mocks)&lt;br /&gt;
# Add the option item to replay the introduction tutorial (See UI Mocks)&lt;br /&gt;
# Produce a tutorial&lt;br /&gt;
# Translate the tutorial in French&lt;br /&gt;
# Write documentation for the translation team&lt;br /&gt;
&lt;br /&gt;
The only risky item is the creation of a reliable Overlay for the different Views. For a technical description of what it involves, see [[Features/Introduction_Tutorial/Overlay]]. Any help from GTK gurus in the community is welcomed as our last attempt at this was unsuccessful.&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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 and return to the original place where she was at first.&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=User:ErickLavoie&amp;diff=49799</id>
		<title>User:ErickLavoie</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=User:ErickLavoie&amp;diff=49799"/>
		<updated>2010-03-14T03:04:44Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Short Bio */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;email: User name in lower case @gmail.com&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Short Bio ===&lt;br /&gt;
&lt;br /&gt;
Erick is currently pursuing a Master degree at [http://www.umontreal.ca Université de Montréal] on P&lt;br /&gt;
programming language design and implementation.  During the last year, as part of his final project of Computer Engineering at [http://www.usherbrooke.ca Université de Sherbrooke], he was part of a team that has developed a prototype tutorial system for Sugar, [http://www.tutorius.org Tutorius ].&lt;br /&gt;
&lt;br /&gt;
He is currently working part-time on merging the work done to the official release of Sugar.&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=User:ErickLavoie&amp;diff=49798</id>
		<title>User:ErickLavoie</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=User:ErickLavoie&amp;diff=49798"/>
		<updated>2010-03-14T03:04:19Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Short Bio */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;email: User name in lower case @gmail.com&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Short Bio ===&lt;br /&gt;
&lt;br /&gt;
Erick is currently pursuing a Master degree at [http://www.umontreal.ca | Université de Montréal] on P&lt;br /&gt;
programming language design and implementation.  During the last year, as part of his final project of Computer Engineering at [http://www.usherbrooke.ca | Université de Sherbrooke], he was part of a team that has developed a prototype tutorial system for Sugar, [http://www.tutorius.org | Tutorius ].&lt;br /&gt;
&lt;br /&gt;
He is currently working part-time on merging the work done to the official release of Sugar.&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=User:ErickLavoie&amp;diff=49797</id>
		<title>User:ErickLavoie</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=User:ErickLavoie&amp;diff=49797"/>
		<updated>2010-03-14T03:03:41Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: Created page with &amp;#039;email: User name in lower case @gmail.com   === Short Bio ===  Erick is currently pursuing a Master degree at  Université de Montréal on P programm…&amp;#039;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;email: User name in lower case @gmail.com&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Short Bio ===&lt;br /&gt;
&lt;br /&gt;
Erick is currently pursuing a Master degree at [[http://www.umontreal.ca | Université de Montréal]] on P&lt;br /&gt;
programming language design and implementation.  During the last year, as part of his final project of Computer Engineering at [[http://www.usherbrooke.ca | Université de Sherbrooke]], he was part of a team that has developed a prototype tutorial system for Sugar, [[http://www.tutorius.org | Tutorius ]].&lt;br /&gt;
&lt;br /&gt;
He is currently working part-time on merging the work done to the official release of Sugar.&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49792</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49792"/>
		<updated>2010-03-14T01:14:16Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Tasks */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having tutorials.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Most of the work has already been done as part of the Tutorius project that ended on December 2009. However, there is still some work to do before the existing system can be reliably integrated to Sugar.  The modifications to Sugar as well as the work to be done is outlined below.&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base but add a number of new files and concepts.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
# Define an [[Features/Introduction_Tutorial/Script | exact script]] for the introduction tutorial&lt;br /&gt;
# Rebase the existing Tutorius code base on top of Sugar 0.88&lt;br /&gt;
# Create a reliable [[Features/Introduction_Tutorial/Overlay | Overlay]] for all the different Views and the Frame&lt;br /&gt;
# Make the Message Bubble position relative to the screen size&lt;br /&gt;
# Make sure the current localization mecanism is reliable &lt;br /&gt;
# Add the logging screen option (See UI Mocks)&lt;br /&gt;
# Add the option item to replay the introduction tutorial (See UI Mocks)&lt;br /&gt;
# Produce a tutorial&lt;br /&gt;
# Translate the tutorial in French&lt;br /&gt;
# Write documentation for the translation team&lt;br /&gt;
&lt;br /&gt;
The only risky item is the creation of a reliable Overlay for the different Views. For a technical description of what it involves, see [[Features/Introduction_Tutorial/Overlay]]. Any help from GTK gurus in the community is welcomed as our last attempt at this was unsuccessful.&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49791</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49791"/>
		<updated>2010-03-14T01:13:29Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Tasks */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having tutorials.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Most of the work has already been done as part of the Tutorius project that ended on December 2009. However, there is still some work to do before the existing system can be reliably integrated to Sugar.  The modifications to Sugar as well as the work to be done is outlined below.&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base but add a number of new files and concepts.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
# Define an [[Features/Introduction_Tutorial/Script | exact script]] for the introduction tutorial&lt;br /&gt;
# Rebase the existing Tutorius code base on top of Sugar 0.88&lt;br /&gt;
# Create a reliable [[Features/Introduction_Tutorial/Overlay | Overlay]] for all the different Views and the Frame&lt;br /&gt;
# Make the Message Bubble position relative to the screen size&lt;br /&gt;
# Make sure the current localization mecanism is reliable &lt;br /&gt;
# Add the logging screen option (See UI Mocks)&lt;br /&gt;
# Add the option item to replay the introduction tutorial (See UI Mocks)&lt;br /&gt;
# Produce a tutorial&lt;br /&gt;
# Write documentation for the translation team&lt;br /&gt;
&lt;br /&gt;
The only risky item is the creation of a reliable Overlay for the different Views. For a technical description of what it involves, see [[Features/Introduction_Tutorial/Overlay]]. Any help from GTK gurus in the community is welcomed as our last attempt at this was unsuccessful.&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49790</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49790"/>
		<updated>2010-03-14T01:12:42Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Scope */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having tutorials.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Most of the work has already been done as part of the Tutorius project that ended on December 2009. However, there is still some work to do before the existing system can be reliably integrated to Sugar.  The modifications to Sugar as well as the work to be done is outlined below.&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base but add a number of new files and concepts.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
# Define an exact script for the introduction tutorial&lt;br /&gt;
# Rebase the existing Tutorius code base on top of Sugar 0.88&lt;br /&gt;
# Create a reliable [[Features/Introduction_Tutorial/Overlay | Overlay]] for all the different Views and the Frame&lt;br /&gt;
# Make the Message Bubble position relative to the screen size&lt;br /&gt;
# Make sure the current localization mecanism is reliable &lt;br /&gt;
# Add the logging screen option (See UI Mocks)&lt;br /&gt;
# Add the option item to replay the introduction tutorial (See UI Mocks)&lt;br /&gt;
# Produce a tutorial&lt;br /&gt;
# Write documentation for the translation team&lt;br /&gt;
&lt;br /&gt;
The only risky item is the creation of a reliable Overlay for the different Views. For a technical description of what it involves, see [[Features/Introduction_Tutorial/Overlay]]. Any help from GTK gurus in the community is welcomed as our last attempt at this was unsuccessful.&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49789</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49789"/>
		<updated>2010-03-14T01:08:31Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Tasks */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having tutorials.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base but add a number of new files and concepts.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
# Define an exact script for the introduction tutorial&lt;br /&gt;
# Rebase the existing Tutorius code base on top of Sugar 0.88&lt;br /&gt;
# Create a reliable [[Features/Introduction_Tutorial/Overlay | Overlay]] for all the different Views and the Frame&lt;br /&gt;
# Make the Message Bubble position relative to the screen size&lt;br /&gt;
# Make sure the current localization mecanism is reliable &lt;br /&gt;
# Add the logging screen option (See UI Mocks)&lt;br /&gt;
# Add the option item to replay the introduction tutorial (See UI Mocks)&lt;br /&gt;
# Produce a tutorial&lt;br /&gt;
# Write documentation for the translation team&lt;br /&gt;
&lt;br /&gt;
The only risky item is the creation of a reliable Overlay for the different Views. For a technical description of what it involves, see [[Features/Introduction_Tutorial/Overlay]]. Any help from GTK gurus in the community is welcomed as our last attempt at this was unsuccessful.&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49788</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49788"/>
		<updated>2010-03-14T00:54:39Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Scope */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having tutorials.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base but add a number of new files and concepts.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
* Define an exact script for the introduction tutorial&lt;br /&gt;
* Rebase the existing Tutorius code base on top of Sugar 0.88&lt;br /&gt;
* Create a reliable Overlay for all the different Views and the Frame&lt;br /&gt;
* Make the Message Bubble position relative to the screen size&lt;br /&gt;
* Make sure the current localization mecanism is reliable &lt;br /&gt;
* Add the logging screen option (See UI Mocks)&lt;br /&gt;
* Add the option item to replay the introduction tutorial (See UI Mocks)&lt;br /&gt;
* Produce a tutorial&lt;br /&gt;
* Write documentation for the translation team&lt;br /&gt;
&lt;br /&gt;
The only risky item is the creation of a reliable Overlay for the different Views. For a technical description of what it involves, see [[Features/Introduction_Tutorial/Overlay]]. Any help from GTK gurus in the community is welcomed as our last attempt at this was unsuccessful.&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49787</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49787"/>
		<updated>2010-03-14T00:35:49Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Scope */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having tutorials.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
=== Sugar Modifications ===&lt;br /&gt;
The major changes to Sugar consist in introducing two new concepts, Probes and Overlays and an additional service in the sugar-session.  &lt;br /&gt;
&lt;br /&gt;
Probes allow obtaining events from Activities/Shell and the execution of arbitrary actions from a separate process. This ability should be reviewed in light of the security policy of Sugar.  &lt;br /&gt;
&lt;br /&gt;
Overlays are Layouts or Windows used to draw custom graphics on top of Activities, the Frame, the Journal or any Sugar View. A more complete description for Probes and Overlays is given in the Tutorius Architecture document referred in the Documentation section.&lt;br /&gt;
&lt;br /&gt;
The service in the sugar-session adds an Engine to execute tutorials, a registering mecanism to register and unregister Probes when Activities are started and stopped and a dbus interface to start and stop tutorials.&lt;br /&gt;
&lt;br /&gt;
Those changes involve modifications of less than 100 lines of code in the existing Sugar code base but add a number of new files and concepts.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49786</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49786"/>
		<updated>2010-03-14T00:02:43Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Documentation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having tutorials.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the component diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49785</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49785"/>
		<updated>2010-03-14T00:02:17Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Documentation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having tutorials.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community in a later release.&lt;br /&gt;
&lt;br /&gt;
The execution scenarios presented are not completely up-to-date and will be revised in the next weeks.  For the time being, the most interesting part should be the components diagrams and descriptions. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en#Components_2405436521573161_98 (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49784</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49784"/>
		<updated>2010-03-14T00:00:19Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Documentation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having tutorials.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They are kept in case a further integration of those tools is accepted by the community. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49783</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49783"/>
		<updated>2010-03-13T22:34:12Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Benefit to Sugar */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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 and therefore would benefit from having tutorials.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They will be kept in case a further integration of those tools might be envisoned in the future. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49779</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49779"/>
		<updated>2010-03-13T21:39:24Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* User Experience */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform other than providing a tutorial on the first connexion.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They will be kept in case a further integration of those tools might be envisoned in the future. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49777</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49777"/>
		<updated>2010-03-13T21:37:29Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Documentation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They will be kept in case a further integration of those tools might be envisoned in the future. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
* http://www.tutorius.org (Website for the project that ended on December 2009)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49776</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49776"/>
		<updated>2010-03-13T21:33:46Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Documentation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They will be kept in case a further integration of those tools might be envisoned in the future. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49775</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49775"/>
		<updated>2010-03-13T21:32:04Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Documentation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
The following document provides a high-level view of the Tutorius Architecture.  The original system was more powerful since it allowed Creation and Sharing of tutorials from within Sugar also.  However, for the purpose of this feature proposal and to ease integration, only the Execution of tutorials will be considered.  For the time being, any reference to the Store, the Workshop, the Creator and the Remote may safely be ignored.  They will be kept as a further integration of those tools might be envisoned in the future. &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en (Tutorius Architecture)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49774</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49774"/>
		<updated>2010-03-13T21:14:59Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Documentation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney) &lt;br /&gt;
*http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en (Tutorius Architecture)&lt;br /&gt;
*http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49772</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49772"/>
		<updated>2010-03-13T21:12:14Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== User Experience ==&lt;br /&gt;
The tutorial won&#039;t affect the regular workflow or experience for the platform.&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
None.&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
Revert to the previous release behavior.&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTF0dzMyNGdnag&amp;amp;hl=en (Meeting with Gerald Ardito and John Tierney) &lt;br /&gt;
http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOWdqeGtyZmY2&amp;amp;hl=en (Tutorius Architecture)&lt;br /&gt;
http://docs.google.com/Doc?docid=0AVT_nzmWT2B2ZGN3dDd2MzRfNTBka3J4bW1kaA&amp;amp;hl=en (Tutorius Engine States)&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
A default interactive tutorial is provided on the first login to help familiarize a new user to Sugar.  This tutorial can also be replayed anytime from the option menu.&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49769</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49769"/>
		<updated>2010-03-13T20:52:54Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. &lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
== User Experience ==&lt;br /&gt;
&#039;&#039;If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
&#039;&#039;What other packages (RPMs) depend on this package?  Are there changes outside the developers&#039; 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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
&#039;&#039;If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as &amp;quot;None necessary, revert to previous release behaviour.&amp;quot;  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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49768</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49768"/>
		<updated>2010-03-13T20:51:55Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface. 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.&lt;br /&gt;
&lt;br /&gt;
The proposal aims at giving an overview of the Frame, the different Views, the Journal, Browse and Write in a single tutorial. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
== User Experience ==&lt;br /&gt;
&#039;&#039;If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
&#039;&#039;What other packages (RPMs) depend on this package?  Are there changes outside the developers&#039; 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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
&#039;&#039;If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as &amp;quot;None necessary, revert to previous release behaviour.&amp;quot;  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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49767</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49767"/>
		<updated>2010-03-13T20:39:19Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Detailed Description */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
&#039;&#039;Expand on the summary, if appropriate.  A couple of sentences suffices to explain the goal, but the more details you can provide the better.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
On top of that, the tutorial should be designed to be robust against unscripted actions made by the user. It means that if the user clicks on any button while the tutorial is showing the different elements of the interface, the tutorial should never become out-of-sync with the state of the interface in a way that cannot be resolved by the user. The examples given previously simply rely on the user pressing the next button when she is ready to move on, therefore issues about the exact state of the interface should be avoided.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
&#039;&#039;What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Make sure to note here as well if this feature has been requested by a specific deployment, or if it has emerged from a bug report.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
== User Experience ==&lt;br /&gt;
&#039;&#039;If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
&#039;&#039;What other packages (RPMs) depend on this package?  Are there changes outside the developers&#039; 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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
&#039;&#039;If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as &amp;quot;None necessary, revert to previous release behaviour.&amp;quot;  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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49766</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49766"/>
		<updated>2010-03-13T20:37:41Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Detailed Description */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
&#039;&#039;Expand on the summary, if appropriate.  A couple of sentences suffices to explain the goal, but the more details you can provide the better.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface and activities.  This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&lt;br /&gt;
http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
On top of that, the tutorial should be designed to be robust against unscripted actions made by the user. It means that if the user clicks on any button while the tutorial is showing the different elements of the interface, the tutorial should never become out-of-sync with the state of the interface in a way that cannot be resolved by the user. The examples given previously simply rely on the user pressing the next button when she is ready to move on, therefore issues about the exact state of the interface should be avoided.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
&#039;&#039;What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Make sure to note here as well if this feature has been requested by a specific deployment, or if it has emerged from a bug report.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
== User Experience ==&lt;br /&gt;
&#039;&#039;If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
&#039;&#039;What other packages (RPMs) depend on this package?  Are there changes outside the developers&#039; 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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
&#039;&#039;If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as &amp;quot;None necessary, revert to previous release behaviour.&amp;quot;  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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49765</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49765"/>
		<updated>2010-03-13T20:36:20Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Detailed Description */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
&#039;&#039;Expand on the summary, if appropriate.  A couple of sentences suffices to explain the goal, but the more details you can provide the better.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface and activities.  This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;img src=&amp;quot;http://tutorius.org/blog/wp-content/uploads/2010/03/login1-300x226.png&amp;quot; alt=&amp;quot;login&amp;quot; title=&amp;quot;login&amp;quot; width=&amp;quot;300&amp;quot; height=&amp;quot;226&amp;quot; class=&amp;quot;aligncenter size-medium wp-image-241&amp;quot; /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;img src=&amp;quot;http://tutorius.org/blog/wp-content/uploads/2010/03/options-300x225.png&amp;quot; alt=&amp;quot;options&amp;quot; title=&amp;quot;options&amp;quot; width=&amp;quot;300&amp;quot; height=&amp;quot;225&amp;quot; class=&amp;quot;aligncenter size-medium wp-image-231&amp;quot; /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;img src=&amp;quot;http://tutorius.org/blog/wp-content/uploads/2010/03/desktop-300x214.png&amp;quot; alt=&amp;quot;desktop&amp;quot; title=&amp;quot;desktop&amp;quot; width=&amp;quot;300&amp;quot; height=&amp;quot;214&amp;quot; class=&amp;quot;aligncenter size-medium wp-image-227&amp;quot; /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;img src=&amp;quot;http://tutorius.org/blog/wp-content/uploads/2010/03/neighborhood-300x214.png&amp;quot; alt=&amp;quot;neighborhood&amp;quot; title=&amp;quot;neighborhood&amp;quot; width=&amp;quot;300&amp;quot; height=&amp;quot;214&amp;quot; class=&amp;quot;aligncenter size-medium wp-image-230&amp;quot; /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;img src=&amp;quot;http://tutorius.org/blog/wp-content/uploads/2010/03/journal-300x216.png&amp;quot; alt=&amp;quot;journal&amp;quot; title=&amp;quot;journal&amp;quot; width=&amp;quot;300&amp;quot; height=&amp;quot;216&amp;quot; class=&amp;quot;aligncenter size-medium wp-image-228&amp;quot; /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;img src=&amp;quot;http://tutorius.org/blog/wp-content/uploads/2010/03/write-300x216.png&amp;quot; alt=&amp;quot;write&amp;quot; title=&amp;quot;write&amp;quot; width=&amp;quot;300&amp;quot; height=&amp;quot;216&amp;quot; class=&amp;quot;aligncenter size-medium wp-image-232&amp;quot; /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
The tutorial should be independent of the screen resolution.&lt;br /&gt;
&lt;br /&gt;
On top of that, the tutorial should be designed to be robust against unscripted actions made by the user. It means that if the user clicks on any button while the tutorial is showing the different elements of the interface, the tutorial should never become out-of-sync with the state of the interface in a way that cannot be resolved by the user. The examples given previously simply rely on the user pressing the next button when she is ready to move on, therefore issues about the exact state of the interface should be avoided.&lt;br /&gt;
&lt;br /&gt;
For the 0.90 release, the tutorial won&#039;t be user modifiable other than by modifying the XML format by hand, which won&#039;t be recommended.&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
&#039;&#039;What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Make sure to note here as well if this feature has been requested by a specific deployment, or if it has emerged from a bug report.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
== User Experience ==&lt;br /&gt;
&#039;&#039;If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
&#039;&#039;What other packages (RPMs) depend on this package?  Are there changes outside the developers&#039; 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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
&#039;&#039;If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as &amp;quot;None necessary, revert to previous release behaviour.&amp;quot;  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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49764</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49764"/>
		<updated>2010-03-13T20:34:50Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Current status */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: 0.90&lt;br /&gt;
* Last updated: 03-13-2010&lt;br /&gt;
* Percentage of completion: 10%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
&#039;&#039;Expand on the summary, if appropriate.  A couple of sentences suffices to explain the goal, but the more details you can provide the better.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
&#039;&#039;What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Make sure to note here as well if this feature has been requested by a specific deployment, or if it has emerged from a bug report.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
== User Experience ==&lt;br /&gt;
&#039;&#039;If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
&#039;&#039;What other packages (RPMs) depend on this package?  Are there changes outside the developers&#039; 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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
&#039;&#039;If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as &amp;quot;None necessary, revert to previous release behaviour.&amp;quot;  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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49763</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49763"/>
		<updated>2010-03-13T20:33:57Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: /* Owner */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
* Email: Name above in lowercase AT gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: (SUGAR_VERSION)&lt;br /&gt;
* Last updated: (DATE)&lt;br /&gt;
* Percentage of completion: XX%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
&#039;&#039;Expand on the summary, if appropriate.  A couple of sentences suffices to explain the goal, but the more details you can provide the better.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
&#039;&#039;What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Make sure to note here as well if this feature has been requested by a specific deployment, or if it has emerged from a bug report.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
== User Experience ==&lt;br /&gt;
&#039;&#039;If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
&#039;&#039;What other packages (RPMs) depend on this package?  Are there changes outside the developers&#039; 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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
&#039;&#039;If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as &amp;quot;None necessary, revert to previous release behaviour.&amp;quot;  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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49762</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49762"/>
		<updated>2010-03-13T20:30:04Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
Provide an interactive introduction to Sugar for first-time users.&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
* Name: [[User:ErickLavoie| Erick Lavoie]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved&#039;&#039;&lt;br /&gt;
* Email: Same as user name with gmail.com&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: (SUGAR_VERSION)&lt;br /&gt;
* Last updated: (DATE)&lt;br /&gt;
* Percentage of completion: XX%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
&#039;&#039;Expand on the summary, if appropriate.  A couple of sentences suffices to explain the goal, but the more details you can provide the better.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
&#039;&#039;What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Make sure to note here as well if this feature has been requested by a specific deployment, or if it has emerged from a bug report.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
== User Experience ==&lt;br /&gt;
&#039;&#039;If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
&#039;&#039;What other packages (RPMs) depend on this package?  Are there changes outside the developers&#039; 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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
&#039;&#039;If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as &amp;quot;None necessary, revert to previous release behaviour.&amp;quot;  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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49761</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49761"/>
		<updated>2010-03-13T20:20:52Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction_Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Comments and Explanations:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
There are comments (in italic) providing guidance to fill out each section, see also the [[Features/Policy|Feature Policy Page]] for a more detailed explanation of the new-feature process. &#039;&#039;&#039;Copy the source to a &#039;&#039;new page&#039;&#039; named Features/&#039;&#039;Your Feature Name&#039;&#039; before making changes!  DO NOT EDIT THIS TEMPLATE.&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
&#039;&#039;A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
&#039;&#039;This should link to your home wiki page so we know who you are&#039;&#039;&lt;br /&gt;
* Name: [[User:AcountName| Your Name]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved&#039;&#039;&lt;br /&gt;
* Email: &amp;lt;your email address so we can contact you, invite you to meetings, etc.&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: (SUGAR_VERSION)&lt;br /&gt;
* Last updated: (DATE)&lt;br /&gt;
* Percentage of completion: XX%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
&#039;&#039;Expand on the summary, if appropriate.  A couple of sentences suffices to explain the goal, but the more details you can provide the better.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
&#039;&#039;What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Make sure to note here as well if this feature has been requested by a specific deployment, or if it has emerged from a bug report.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
== User Experience ==&lt;br /&gt;
&#039;&#039;If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
&#039;&#039;What other packages (RPMs) depend on this package?  Are there changes outside the developers&#039; 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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
&#039;&#039;If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as &amp;quot;None necessary, revert to previous release behaviour.&amp;quot;  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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49760</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49760"/>
		<updated>2010-03-13T20:20:34Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|Introduction Tutorial]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Comments and Explanations:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
There are comments (in italic) providing guidance to fill out each section, see also the [[Features/Policy|Feature Policy Page]] for a more detailed explanation of the new-feature process. &#039;&#039;&#039;Copy the source to a &#039;&#039;new page&#039;&#039; named Features/&#039;&#039;Your Feature Name&#039;&#039; before making changes!  DO NOT EDIT THIS TEMPLATE.&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
&#039;&#039;A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
&#039;&#039;This should link to your home wiki page so we know who you are&#039;&#039;&lt;br /&gt;
* Name: [[User:AcountName| Your Name]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved&#039;&#039;&lt;br /&gt;
* Email: &amp;lt;your email address so we can contact you, invite you to meetings, etc.&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: (SUGAR_VERSION)&lt;br /&gt;
* Last updated: (DATE)&lt;br /&gt;
* Percentage of completion: XX%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
&#039;&#039;Expand on the summary, if appropriate.  A couple of sentences suffices to explain the goal, but the more details you can provide the better.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
&#039;&#039;What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Make sure to note here as well if this feature has been requested by a specific deployment, or if it has emerged from a bug report.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
== User Experience ==&lt;br /&gt;
&#039;&#039;If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
&#039;&#039;What other packages (RPMs) depend on this package?  Are there changes outside the developers&#039; 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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
&#039;&#039;If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as &amp;quot;None necessary, revert to previous release behaviour.&amp;quot;  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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
	<entry>
		<id>https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49688</id>
		<title>Features/Introduction Tutorial</title>
		<link rel="alternate" type="text/html" href="https://wiki.sugarlabs.org/index.php?title=Features/Introduction_Tutorial&amp;diff=49688"/>
		<updated>2010-03-12T04:34:46Z</updated>

		<summary type="html">&lt;p&gt;ErickLavoie: Created page with &amp;#039;&amp;lt;noinclude&amp;gt;{{TOCright}} Category:Feature Page Incomplete &amp;lt;Feature Name&amp;gt; &amp;lt;!-- You can add categories to tie features back to real deployments/schools requ…&amp;#039;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;noinclude&amp;gt;{{TOCright}}&lt;br /&gt;
[[Category:Feature Page Incomplete]]&lt;br /&gt;
[[Category:Feature|&amp;lt;Feature Name&amp;gt;]]&lt;br /&gt;
&amp;lt;!-- You can add categories to tie features back to real deployments/schools requesting them, for example &lt;br /&gt;
[[Category:Features requested by School Xyz|&amp;lt;Feature Name&amp;gt;]] (the |Feature Name option sorts the entry on the category page under the first letter of &amp;lt;Feature Name&amp;gt;). --&amp;gt;&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Comments and Explanations:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
There are comments (in italic) providing guidance to fill out each section, see also the [[Features/Policy|Feature Policy Page]] for a more detailed explanation of the new-feature process. &#039;&#039;&#039;Copy the source to a &#039;&#039;new page&#039;&#039; named Features/&#039;&#039;Your Feature Name&#039;&#039; before making changes!  DO NOT EDIT THIS TEMPLATE.&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- All fields on this form are required to be accepted.&lt;br /&gt;
 We also request that you maintain the same order of sections so that all of the feature pages are uniform.  --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Summary ==&lt;br /&gt;
&#039;&#039;A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Owner ==&lt;br /&gt;
&#039;&#039;This should link to your home wiki page so we know who you are&#039;&#039;&lt;br /&gt;
* Name: [[User:AcountName| Your Name]]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved&#039;&#039;&lt;br /&gt;
* Email: &amp;lt;your email address so we can contact you, invite you to meetings, etc.&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Current status ==&lt;br /&gt;
* Targeted release: (SUGAR_VERSION)&lt;br /&gt;
* Last updated: (DATE)&lt;br /&gt;
* Percentage of completion: XX%&lt;br /&gt;
&lt;br /&gt;
== Detailed Description ==&lt;br /&gt;
&#039;&#039;Expand on the summary, if appropriate.  A couple of sentences suffices to explain the goal, but the more details you can provide the better.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Benefit to Sugar ==&lt;br /&gt;
&#039;&#039;What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Make sure to note here as well if this feature has been requested by a specific deployment, or if it has emerged from a bug report.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Scope ==&lt;br /&gt;
&#039;&#039;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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
==UI Design==&lt;br /&gt;
&#039;&#039;Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== How To Test ==&lt;br /&gt;
{{:{{PAGENAME}}/Testing}}&lt;br /&gt;
== User Experience ==&lt;br /&gt;
&#039;&#039;If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
&#039;&#039;What other packages (RPMs) depend on this package?  Are there changes outside the developers&#039; 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?&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Contingency Plan ==&lt;br /&gt;
&#039;&#039;If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as &amp;quot;None necessary, revert to previous release behaviour.&amp;quot;  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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Release Notes ==&lt;br /&gt;
&#039;&#039;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.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Comments and Discussion ==&lt;br /&gt;
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] &amp;lt;!-- This adds a link to the &amp;quot;discussion&amp;quot; tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. --&amp;gt;&lt;/div&gt;</summary>
		<author><name>ErickLavoie</name></author>
	</entry>
</feed>