[Sugar-devel] content bundles and the "OLPC Library" Browse home page

[Gary C Martin]

On 19 Mar 2009, at 18:22, Eben Eliason wrote:

> On Thu, Mar 19, 2009 at 2:06 PM, Gary C Martin  
> <gary at garycmartin.com> wrote:
>> On 19 Mar 2009, at 16:58, Wade Brainerd wrote:
>>
>>> My hope going forward is that .xol bundles merge with .xo bundles  
>>> and
>>> that they become one and the same, each appearing on the Home view  
>>> for
>>> example.  HTML would just be another development platform for  
>>> writing
>>> Sugar activities, and what used to be non-interactive library  
>>> content
>>> would become first class activities (not necessarily with  
>>> interactive
>>> features, but possibly).
>>
>> +1 This is my hope/goal also, a selection of Sugar Activity  
>> templates/
>> examples that provide a trivial path for various media types to be
>> integrated as first class Activities.
>
> I don't have any disagreement with making a variety of development
> platforms available for activity developers, HTML included, but I
> don't understand why this is conflated with content bundles.  As I've
> always seen them, content bundles are meant as a delivery format for
> sets or collections of content: images, sounds, books/pdfs, etc.  What
> benefit is gained by considering such a collection of objects as an
> activity?

Fair point :-) some quick thoughts:

- Why have a separate UI metaphor for objects hidden away in a default  
Browse page, presented in a different way to the rest of the UI? Much  
effort in Sugar has been made to make Activity = (document instant +  
application).

- The separate .xol and hooks requires extra maintenance, testing,  
install/removal process, all for something that (to my eye)  
complicates the UI rather than simplifying it.

- Do we keep trying to push each new media type into a single Browse  
Activity UI? The Read thread from a day or so back indicates that  
differently tuned UI's for different book formats can be beneficial.  
With the choice being, are the format use cases similar enough that,  
for example, Read should have several UI faces tuned for the different  
formats, or should there be several different Read like Activities for  
the different formats (as we have now).

- Why should 'library' content be limited to the media types Browse  
supports (i.e. without making folks jump though journal context switch/ 
duplication/launch hoops for unsupported content)?

I understand this pollutes the Activities as verbs space, but to be  
honest that died a long time ago for me, and only ever really worked  
for a handful of core Activities – verbs are nice, but there's not  
usually one that makes much sense ;-)

Regards,
--Gary

> - Eben
>
>
>> This does raise the topic of scalability for the home view (a likely
>> controversial Design Meeting on Saturday...) but having so much
>> educational content it creates a UI presentation issue, would be a
>> good UI issue to be solving :-)
>>
>> FWIW, the current favourite view + full list view scales well in this
>> scenario; the list view as an equivalent your virtual book shelf, and
>> the favourite view as your current working set.
>>
>> Regards,
>> --Gary
>>
>>> There are discussions about this becoming a GSoC project, provided  
>>> we
>>> get a good student to do it.
>>>
>>> Cheers,
>>> Wade
>>>
>>> On Thu, Mar 19, 2009 at 3:07 AM, S Page <skierpage at gmail.com> wrote:
>>>> In SoaS2 I downloaded a .XOL and was able to run it from the  
>>>> Journal
>>>> and it unpacked into ~/Library.
>>>> But Browse doesn't show it on a library page.
>>>>
>>>> User "cwhii" noticed this a while back and complained about it,  
>>>> Sugar
>>>> bug #1 (!), http://dev.sugarlabs.org/ticket/1 :
>>>>  I expected "OLPC Library" with a list of libraries to pick from.
>>>> That bug somehow turned into "Add support to Browse for
>>>> distro-customised start page" and was upstreamed to Ubuntu.
>>>>
>>>> But Ubuntu providing a home page isn't going to bring the OLPC
>>>> Library
>>>> feature back.  I filed bug 574, http://dev.sugarlabs.org/ticket/574
>>>> "Sugar lacks OLPC's dynamic content library".  The code to  
>>>> rebuild a
>>>> page whenever you install a collection is in is package
>>>> olpc-library-common, it's also the same code to build the OLPC home
>>>> page from a template (more details in
>>>> http://wiki.laptop.org/go/Library#Developers:_How_it_works ).   
>>>> Sugar
>>>> 0.84 still expects this code: sugar-toolkit's contentbundle.py  
>>>> tries
>>>> to invoke /usr/share/library-common/make_index.py when you  
>>>> install a
>>>> .xol content bundle.
>>>>
>>>> I think the existing package would do the right thing in latest  
>>>> Sugar
>>>> to recreate a library page.  The only wrinkle is that Browse
>>>> hardcodes
>>>> (in webactivity.py)
>>>>  _LIBRARY_PATH = '/usr/share/library-common/index.html'
>>>> as its home page, but make_index.py doesn't build this, it builds
>>>> index.html in
>>>>  output_path = '/home/olpc/.library_pages' # old but kept around
>>>> for upgrades
>>>> The latter page is hardcoded to refresh to the former, and so the
>>>> user
>>>> in Browse sees the newly-generated library page that links to her
>>>> newly downloaded content.
>>>>
>>>> Although .xol collection handling is in sugar-toolkit, I think the
>>>> format and the nifty updating library page could be a general  
>>>> design
>>>> for content downloaded from the web, separate from Sugar.  But what
>>>> are the plans for collections and "the library" in the future?  Are
>>>> people thinking they'll be replaced by packages, or some library
>>>> metadata format?  The elusive Sj wrote
>>>> http://wiki.laptop.org/go/Dynamic_library back in 2008...
>>>>
>>>> Cheers,
>>>> --
>>>> =S Page
>>>> _______________________________________________
>>>> Sugar-devel mailing list
>>>> Sugar-devel at lists.sugarlabs.org
>>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>>
>>> _______________________________________________
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>