Hi,
I confess I haven't seen either the Welcome or Bulletin Board
activities. I also saw there is a Teach Teacher activity. These all look
like promising contributions.
Naturally, the translation issue with a screenshot depends on the amount
of text in the screen. In ShowNTell, my usual practice is to explain
(audio) what the user is to do from the point of the screenshot or to
challenge the user to get to the screenshot. In some ways this is
analogous to the practice that many of us use - walking around the room
showing the screen to the students. With ShowNTell, the screen is
visible on the student's laptop.
Tony
On 10/16/2012 11:18 AM, Gary Martin wrote:
Hi Tony,
On 16 Oct 2012, at 15:47, Tony Anderson <tony_ander...@usa.net> wrote:
Hi,
The ShowNTell activity provides both slide show and sound capability. The
slides are images at present.
Hmmm, seems like some amount of overlapping activity effort and target use
cases going on. You might like to also take a quick look at Portfolio [1]
(already part of the default OLPC builds), and Bulletin Board [2] (more aimed
at documenting the work group projects, and has some support for audio
recording and playback). Though I think the Welcome activity still has somewhat
separate goals from ShowNTell/Portfolio/Bulletin Board (e.g. first time user
introduction to Sugar and XO).
Slide shows based on screenshots are easy to create.
FWIW: Most screenshots are a pain for translation/localisation (UI text), it
pretty much ties down any content generated to one locale.
Regards,
--Gary
[1] http://activities.sugarlabs.org/en-US/sugar/addon/4437
[2] http://activities.sugarlabs.org/en-US/sugar/addon/4588
I am trying to port it to use webkit so the slides can be html. This is a
problem at present because use of webkit now requires a port to gtk3.
Tony
On 10/16/2012 10:22 AM, Gary Martin wrote:
Hi Tony,
On 16 Oct 2012, at 14:34, Tony Anderson <tony_ander...@usa.net> wrote:
Hi,
What is the purpose of help? In Windows, help is a method to find out how to
accomplish a particular task using an application. It is not a means to learn
how to use the computer or Windows.
The Help activity is a specialized reader for the Floss (pdf) manuals.
Unfortunately, the text in the Floss manuals was written for experienced
computer users who were new to the XO and the Sugar.
I believe we need a Sugar activity to introduce the XO and Sugar to those who
have no prior computing experience. Further, we need to use the 'learn to
learn' approach we advocate for the XO, i.e. these materials should be designed
for experimentation (trial and error) and collaborative learning. The beauty of
the computer is that it provides instant feedback on whether you did something
'right' or not.
Yes an initial version of this landed in the last release cycle, it was the
Welcome Activity. It's just really a basic slideshow, that has a simple folder
structure that is intended to be customised by deployments to add their own
material. It's success will be down to what quality of content it contains.
Currently it just supports images, not animations or sound, though that was a
future 'like to have' on the feature list. The activity also used by a matching
first boot behaviour that displays that same content on first boot before the
user is asked to type their name or choose a colour. The current default
content is almost all visual/cartoony, no text reading expected (though there
are some screenshots of the UI as part of the cartoons), one issue is that if
it dose need to be locale customised, good image content does not seem to be
easy for many to create, and can make the activity larger than otherwise ideal.
Gonzalo: Is it worth uploading the Welcome activity to ASLO (I just looked and
couldn't find it), or will this cause some issues for deployments (e.g. a user
'upgrading' at ASLO might wipe local generated content)? Though it would
provide all existing users/deployments the chance to see the content (and
suggest/provide improvements)
Regards,
--Gary
I also believe that use of screenshots, screencasts and icons can reduce the
dependency of these materials on text. Another underutilized tool is audio. If
the text instructions were spoken, any deployment would be able to provide the
same instructions in the native language (the skill needed would be a speaker
of the native language who also knows English). Incidentally, in deployments
where English is a medium of instruction, using both versions can help children
learn English.
Tony
Message: 3
Date: Tue, 16 Oct 2012 09:05:08 -0300
From: Gonzalo Odiard <gonz...@laptop.org>
To: "S. Daniel Francis" <fran...@sugarlabs.org>
Cc: Sugar-dev Devel <sugar-devel@lists.sugarlabs.org>
Subject: Re: [Sugar-devel] Purpose for Help Activity
Message-ID:
<caj+ipvrgke8qenkjc3dqv8dufybjczesdtg8qvrxv8hzfqv...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Help issues are known and we need solve it,
but I don't agree with the proposed solution.
The style can be changed with css, that is not a problem.
The biggest problem we have today, is found people to write the help.
If we impose to a potential writer the work of learn docbook,
will be worst. And writing a docbook editor is not a trivial task.
About having help content inside the activities,
probably is a good idea. We need think about:
* how enable the translation of that content (and how much disk space
will use if we have all the translations inside the activity)
* where put the content related to sugar (not activities)
Gonzalo
On Mon, Oct 15, 2012 at 10:03 PM, S. Daniel Francis
<fran...@sugarlabs.org>wrote:
Hi,
Looking at the Help activity, I see the following issues:
- It looks very orange. A more integrated style is needed.
- Activities should be documented independently of the help activity.
(Not very related with my purpose but important for deploy a solution)
- The documentation needs to be updated and Gonzalo told me about
there were efforts to update it. ?Where are them?
Now I purpose some solutions:
- Using docbook.
Docbook is used by the GNOME documentation team and can be styled
easily with CSS.
- Save the documentation in each activity.
With that way, Help could scan each activity for documentation, that
documentation could depend of the installed version of each activity.
And documentation for non-core activities could be seen from the Help
activity.
Knowing that the Help isn't up to date, I only migrated the first
chapter for give you a preview of my purpose.
A screenshot:
http://wiki.sugarlabs.org/go/File:Help-docbook-purpose.png
On the git repository:
http://git.sugarlabs.org/~danielf/help/help-docbook
For generate the HTML files I used the following command: (Already
generated in the repository)
$ yelp-build html -o ./help/ sources.xml
Warm regards,
Daniel Francis.
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
.
.
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
