[Sugar-devel] HTML activities

[Gonzalo Odiard]

With technologies like HTML5 and EPUB3, the lines between a book and
a activity start to blur. (EPUB2 prohibited the use of javascript, but is
allowed in EPUB3)
A nice example of a book with dynamic content is
http://natureofcode.com/book/chapter-1-vectors/
The technology behind will be the same, we need think about what is better
in every case,
how can we improve the tools to create the books or activities,
and how the users can improve, comment, and share/communicate,
changing from a read-only experience to a read-write use, like in a wiki.

Gonzalo


On Thu, Jan 31, 2013 at 10:41 PM, Edward Mokurai Cherlin <
mokurai at sugarlabs.org> wrote:

> On Wed, January 30, 2013 4:26 pm, lionel at olpc-france.org wrote:
> >
> >> * What we are doing here is still heavily experimental. I don't think we
> > know exactly where we are going yet, just trying to find out. I posted on
> > the list so early
> >>  because I think it's important to get feedback.
>
> Quite right. Let me add a question, then, where I would like to get
> some feedback. One of the ideas at the foundation of the Sugar Labs
> program for Replacing Textbooks (with OERs) is to be able to write
> learning materials using tools such as HTML5 or EPUB3 in a way that
> would allow us to embed and script Sugar activities. This would make
> it straightforward to implement a curriculum fully integrated with
> Sugar. (We could also discuss what other Sugar activities would be
> needed for the purpose, and whether existing Sugar activities would
> need to be adapted to make all of this work.)
>
> Do we know how to do such a thing in HTML5? What other questions do we
> need to ask in order to start looking for more answers?
>
> >>* I think we have a bit of a different perspective. It seems like the
> >> goal
> > of your framework is to add the ability to write html activities for the
> > sugar platform, possibly
> >> mixing with python code.
> >
> > Okay. But it's interesting to have a look on today and tomorrow at the
> > same
> > time.
> > So, my idea is to see how HTML activities developed today could work (or
> > could be easily adapted) tomorrow.
> >
> >
> >> We also have that goal but, in addition, we would like to provide the
> > ability to write fully cross-platform activities. That could run for
> > example
> > on Android, on iOS, or
> >> inside a web browser. So we are talking about a toolkit which is
> > completely independent from the gtk3 one.
> >
> > It make sense.
> >
> >
> >>>> * Toolbar widget using the icons API, perhaps without palettes.
> >>>
> >>> Yes but we should allow developers to use a true Python toolbar
> >>> instead of the simple one when needed.
> >>
> >> I'm going back and forward on this. Of course I see why it's a required
> > feature from your point of view... But if we provide an html toolbar
> > implementation with all the
> >> features of the gtk one, why would developers use the gtk one for an
> >> html
> > activity? Maybe as an intermediate point while migrating from python to
> > html, but I can't
> >> think of other reasons.
> >
> > Right.
> >
> >>> * Datastore saving and loading.
> >>
> >
> >> Again a lot of back an forward on this. I initially thought to implement
> > those API with client side message passing (taking inspiration from your
> > work). Then I've seen it's
> >> implemented using the console-message signal, which doesn't really feel
> > right.
> >
> > You're right, using "console-message" is not a perfect solution. But
> > coupled
> > with JSON serialization, it's a really easy way to ensure communication
> > from
> > JavaScript to Python (communication from Python to JavaScript use the
> > WebView method "execute-script").
> > To be honest, I didn't find another way to do that. I wonder if there is
> a
> > better way, for example what is the PhoneGap way to do this.
> >
> >> I think it's a functionality that might make sense to add to webkit gtk
> >> in
> > a cleaner way but... I'm not sure it's worth if we have a server running
> > anyway. It adds one more
> >> requirement for the rendering engine we are using. Also it would be
> >> pretty
> > nice to the have the whole sugar-toolkit-html implemented in javascript,
> > rather than mixing
> >> with python.
> >
> > Yes but porting Gtk is a huge amount of work.
> >
> >> And nodejs allows us to do that. The downside of course is the overhead
> >> of
> > out process http communication.
> >
> > And adding nodejs add one more complexity.
> >
> >
> >> I disagree on this. I think Sugar visual design is one if it's strong
> > points and it should be retained. I also think all the activities should
> > have a consistent visual appearance.
> >
> > There is no so much control in Sugar. Plus, most activities are graphical
> > activities so, most activities use very few widgets. May be it could be
> > sufficient to just give some guidelines about UI: do rounded button, use
> a
> > specific font, ... Using these guidelines it will be easy for developers
> > to
> > be consistent with any JavaScript framework.
> >
> >
> >> While it's not required I think a system wide html server is a good
> >> idea.
> > It gives more flexibility than using file://. I really need to articulate
> > this better (in my mind too)
> >> but for example I would like to provide system icons by just specifying
> > them as a path.
> >
> > Yes you're right but adding a HTTP server just to share icons is very
> > expansive!
> >
> >
> >> Thanks!
> >
> > Thanks to you. I'm happy to contribute.
> >
> >       Lionel.
>
> --
> Edward Mokurai (默雷/निशब्दगर्ज/نشبدگرج) Cherlin
> Silent Thunder is my name, and Children are my nation.
> The Cosmos is my dwelling place, the Truth my destination.
> http://wiki.sugarlabs.org/go/Replacing_Textbooks
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130201/a371fd88/attachment.html>