Sugar Labs - User contributions [en]

Talk:Features/Content support

2010-07-28T23:55:40Z

Sj: 10244

I'd argue for a somewhat different approach to achieving the same goals. Instead of introducing yet another modal dialog, why not eliminate the list view and replace it with the star function in the Journal itself. Any object that is starred will show up on the Home View. (Ideally, there would be multiple stars corresponding to multiple Home Views, e.g., one for school, one for home...)

Features of this approach:
* No confusing list view
* Media objects in list view
* Utilization of star in Journal view which currently does nothing
* Reutilization of current Journal filters

--[[User:Walter|Walter]] 16:39, 20 July 2010 (EDT)
== Home views as Journal favorites views ==

I imagine the Home view becoming tightly integrated with the Journal through the Journal favorites as Walter suggests.

The 'List' Home view should be replaced by a Journal icon that would take the learner to a "non-favorite"-limited filter in the Journal view of the currently-selected Home group. Where "Home group" would be the alternate views such as, School, Games, Music, Photos, etc., created by new Journal tagging features. (The default Home view, would continue to be the favorite list of installed Activities.)

A sub-row of Home group icons (which would instantly reveal on hover) would be provided on the Home view Frame button palette to allow the learner to jump to alternate Favorite views. The Favorites Home view button would gain the same sub-row palette, and the alternate view patterns would be a sub-palette that would reveal only on a persistent hover or right-mouse button click.

To complement the easy Journal access from the Home view, we should provide a direct Home view button on the Journal toolbar—the Journal Favorites view (aka, Home view). To conserve the valuable toolbar space, this should qualify for one of the corner positions. (Are we reserving the corners for alert beacons or what?)

--[[User:FGrose|FGrose]] 16:33, 21 July 2010 (EDT)

http://lists.sugarlabs.org/archive/sugar-devel/2010-July/025615.html describes a Journal group design to support Activity and content grouping. --[[User:FGrose|FGrose]] 11:26, 28 July 2010 (EDT)

== (Ab)using the Journal for stuff that the user didn't do, create, or access ==

Both of these comments break a pretty core concept of the current journal design, in my opinion.

http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg07888.html
: Amend the "non-favorite" filter above to include only learner-tagged objects/events. Then we could extend the Journal concept to My Journal and Others' Journals (some higher level filter with appropriate colors and names). This would accommodate shared Journals and the core content that came with the Sugar image. --[[User:FGrose|FGrose]] 17:52, 21 July 2010 (EDT)

:This proposal somewhat exasperates the confusion over things pre-installed in the Journal, but this is a preexisting problem. --[[User:Walter|Walter]] 20:55, 21 July 2010 (EDT)
:: True, but with the concept of My Journal vs. Others', a System Journal may come to conveniently represent the machine (with appropriate groups, such as event and error logs, that are more closely associated with the system vs. the learner). We could find a natural way to introduce pre-installed content, which, once activated, become learner Activity instances, such as the e-book with my annotations and last page number, etc. --[[User:FGrose|FGrose]] 23:17, 21 July 2010 (EDT)
:::It is the "natural way to introduce pre-installed content" part I still struggle with, but as I said, this is a preexisting problem and shouldn't be roadblock to this feature proposal. --[[User:Walter|Walter]] 08:22, 22 July 2010 (EDT)

== Adding a search interface for non-user-created content ==

I like these suggestions a lot; it seems to me quite important to implement a first pass for use/testing/discussion.

The idea of making better use of the home screen for finding/accessing content in particular could be enhanced by making good use of the search bar there (currently disabled).

The results of a search should be an interface for discovering content of all sorts. It could also replace the current software update interface. I'd like to see it include (copied in part from [http://dev.laptop.org/ticket/10244 bug 10244]):

# Support discovery of local and remote content, including:
#* Content available locally on the machine
#* Content whose metadata / last known location is on the machine (found by searching a local metadata catalog)
#* Content whose metadata / last known location is in a public catalog (found by visiting a URL)
#:
# Support discovery of many types of content:
#* activities and content bundles (using .xo/.xol microformats or other)
#* individual books (using OPDS data or other)
#* journal entries (using standardized journal metadata if searching "others' public journals")
#:
# Support the notion of updates
#* Checking for new catalog data and offering to update local catalog data when searches are run
#* Checking metalists of available (distributed) catalogs and offering to check new catalogs for more activities/content
#* Comparing version IDs or timestamps for activities/content that have it
#* Offering hints as to the number of updates available for content already stored locally
#*: (as the current Activity Update interface offers. the default hint should probably be less bold; rather than a page listing the updates in detail and asking you to click "go!")

Talk:Features/Content support

2010-07-28T23:45:28Z

Sj: /* Adding a search interface for non-user-created content */ new section

I'd argue for a somewhat different approach to achieving the same goals. Instead of introducing yet another modal dialog, why not eliminate the list view and replace it with the star function in the Journal itself. Any object that is starred will show up on the Home View. (Ideally, there would be multiple stars corresponding to multiple Home Views, e.g., one for school, one for home...)

Features of this approach:
* No confusing list view
* Media objects in list view
* Utilization of star in Journal view which currently does nothing
* Reutilization of current Journal filters

--[[User:Walter|Walter]] 16:39, 20 July 2010 (EDT)
== Home views as Journal favorites views ==

I imagine the Home view becoming tightly integrated with the Journal through the Journal favorites as Walter suggests.

The 'List' Home view should be replaced by a Journal icon that would take the learner to a "non-favorite"-limited filter in the Journal view of the currently-selected Home group. Where "Home group" would be the alternate views such as, School, Games, Music, Photos, etc., created by new Journal tagging features. (The default Home view, would continue to be the favorite list of installed Activities.)

A sub-row of Home group icons (which would instantly reveal on hover) would be provided on the Home view Frame button palette to allow the learner to jump to alternate Favorite views. The Favorites Home view button would gain the same sub-row palette, and the alternate view patterns would be a sub-palette that would reveal only on a persistent hover or right-mouse button click.

To complement the easy Journal access from the Home view, we should provide a direct Home view button on the Journal toolbar—the Journal Favorites view (aka, Home view). To conserve the valuable toolbar space, this should qualify for one of the corner positions. (Are we reserving the corners for alert beacons or what?)

--[[User:FGrose|FGrose]] 16:33, 21 July 2010 (EDT)

http://lists.sugarlabs.org/archive/sugar-devel/2010-July/025615.html describes a Journal group design to support Activity and content grouping. --[[User:FGrose|FGrose]] 11:26, 28 July 2010 (EDT)

== (Ab)using the Journal for stuff that the user didn't do, create, or access ==

Both of these comments break a pretty core concept of the current journal design, in my opinion.

http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg07888.html
: Amend the "non-favorite" filter above to include only learner-tagged objects/events. Then we could extend the Journal concept to My Journal and Others' Journals (some higher level filter with appropriate colors and names). This would accommodate shared Journals and the core content that came with the Sugar image. --[[User:FGrose|FGrose]] 17:52, 21 July 2010 (EDT)

:This proposal somewhat exasperates the confusion over things pre-installed in the Journal, but this is a preexisting problem. --[[User:Walter|Walter]] 20:55, 21 July 2010 (EDT)
:: True, but with the concept of My Journal vs. Others', a System Journal may come to conveniently represent the machine (with appropriate groups, such as event and error logs, that are more closely associated with the system vs. the learner). We could find a natural way to introduce pre-installed content, which, once activated, become learner Activity instances, such as the e-book with my annotations and last page number, etc. --[[User:FGrose|FGrose]] 23:17, 21 July 2010 (EDT)
:::It is the "natural way to introduce pre-installed content" part I still struggle with, but as I said, this is a preexisting problem and shouldn't be roadblock to this feature proposal. --[[User:Walter|Walter]] 08:22, 22 July 2010 (EDT)

== Adding a search interface for non-user-created content ==

This interface, or variations of it, should

# Support discovery of local and remote content, including:
#* Content available locally on the machine
#* Content whose metadata / last known location is on the machine (found by searching a local metadata catalog)
#* Content whose metadata / last known location is in a public catalog (found by visiting a URL)
#:
# Support discovery of many types of content:
#* activities and content bundles (using .xo/.xol microformats or other)
#* individual books (using OPDS data or other)
#* journal entries (using standardized journal metadata if searching "others' public journals")
#:
# Support the notion of updates
#* Checking for new catalog data and offering to update local catalog data when searches are run
#* Checking metalists of available (distributed) catalogs and offering to check new catalogs for more activities/content
#* Comparing version IDs or timestamps for activities/content that have it
#* Offering hints as to the number of updates available for content already stored locally
#*: (as the current Activity Update interface offers. the default hint should probably be less bold; rather than a page listing the updates in detail and asking you to click "go!")

User talk:Dogi

2010-07-28T20:14:31Z

Sj: Created page with '<acquires a chunk of data> <looks for fileserver> :-) ~~~~'

<acquires a chunk of data> <looks for fileserver> :-) [[User:Sj|+sj]] [[User Talk:Sj|+]] 16:14, 28 July 2010 (EDT)

User talk:Mchua

2010-07-28T20:13:52Z

Sj:

Do you know any wiki template-transfer fu? [[User:Cjl/Sandbox]] is just a partial, mostly unculled list. [[User:Cjl|Cjl]] 05:57, 16 May 2008 (UTC)

== SO AS to say ==

Whenever the wiki talks about "SOAS installation" it means "burning an iso image to a key". People who have never booted a machine from a USB key won't understand this, and will want to know how to 'install' or 'run' Sugar once they have their key... a page on "how to run SOAS" would be handy. [[User:Sj|+sj]] [[User Talk:Sj|+]] 16:13, 28 July 2010 (EDT)
: Instead, searching for that phrases used to run up [[Sugar on a Stick meetings|this page]]! :)

2009-10-09T01:21:46Z

Sj: ..

2009-09-26T22:33:05Z

Sj: quote

A 12-person SOAS decision panel was appointed by a [[Oversight_Board/Meeting_Minutes-2009-09-25#Decision_Panel|September, 2009]] Oversight Board decision.

== Mandate ==
{{quote|
We appointed a decision panel (by a vote of 3 for, 0 against, 1 abstain, 3 absent) with the following mandate:
:"Investigate the situation of how SoaS should be treated by Sugar Labs, and related questions, including answers to the following:
:* "Should Sugar Labs be a GNU/Linux distributor, rather than just an upstream producing Sugar releases?"
:* "Should SL be neutral about distributions containing Sugar, and refuse to endorse one over another?"
:* "Should 'Sugar on a Stick' be a phrase that SL asks its community to avoid using unless they refer to the SoaS-Fedora distribution?"
:* Any other question the Decision Panel deems required to provide an answer to the original question:"Is the current SoaS going to be the primary way Sugar Labs distributes a Sugar-centric GNU/Linux distribution?"
}}

== Members ==
* Sebastian Dziallas
* Luke Faraone
* Martin Dengler
* Bill Bogstad
* Faisal Khan
* Benjamin M. Schwartz
* Samuel Klein
* Sean Daly
* Tabitha Roder
* Caryl Bigenho
* Daniel Drake
* Abhishek Indoria

[[category:decision panels]]