[Sugar-devel] [Feature] Social Help

[Gonzalo Odiard]

Sam,
You don't loose all the space, because you don't need a fixed toolbar in
the server.
Is content, and the content will scroll.

Gonzalo

On Tue, Apr 21, 2015 at 7:27 PM, Sam P. <sam.parkinson3 at gmail.com> wrote:

> Hi Gonzalo,
>
> On Tue, Apr 21, 2015 at 9:29 PM Gonzalo Odiard <godiard at sugarlabs.org>
> wrote:
>
>> On Mon, Apr 20, 2015 at 7:28 PM, Sam P. <sam.parkinson3 at gmail.com> wrote:
>>
>>> Hi Gonzalo,
>>>
>>> On Tue, Apr 21, 2015 at 3:37 AM Gonzalo Odiard <godiard at sugarlabs.org>
>>> wrote:
>>>
>>>> But if the server url can be configured (as in the proposal)
>>>> In theory you could Sugar Network too at the server side, right?
>>>> We only need define a standard way to provide context, like a parameter
>>>> for the bundle_id
>>>>
>>>
>>> Yes, that is possible.  The api is very simple, the webview URL is set
>>> to:
>>>
>>>     SERVER/goto/BUNDLE
>>>
>>>
>> Should be good check and agree with Sugar Network developers.
>> Could be a good idea add the nick name and the user colors as
>> parameters?
>>
>
>>
>>
>>> So, you could make sugar network respond to this, add a redirect or
>>> create a separate redirector server (as I do with
>>> socialhelp.sugarlabs.org).
>>>
>>> It also has the merged native/web toolbar.  The webview adds the class
>>> "sugar" to your document body so you can then compensate for the 55x55
>>> close button on the top right.
>>>
>>>
>> I would prefer use just the standard Sugar toolbar.
>> If the page design change, or you use another server (like Suugar
>> Network) or if you
>> have a monitor with different pixel size, the merged toolbar will look
>> wrong.
>>
>
> I have to disagree with you here.
>
> For pixel size, websites just use em for the toolbar instead of px.  Sites
> like sugar-network seem to already be doing this.  You must use em in order
> to not look like tiny font on the xo anyway.
>
> For other services, it is super duper easy to integrate.  For example,
> this is all the CSS needed for discourse:
>
>     .sugar header.d-header {
>         width: -webkit-calc(100% - 2.813em);
>     }
>
> Or for sugar-network:
>
>     .sugar #toolbar {
>         width: -webkit-calc(100% - 2.813em);
>     }
>
> And even if the app does not have a toolbar, it is just a little button in
> the top right and it looks fine.
>
>
>>
>> You lost 55 px, but you remove complexity and gain flexibility.
>>
>
> 55px is very important.  On some platforms, it is actually even 75 px.
>
> You loose 55px top padding, 55px bottom padding, 55px sugar toolbar and
> then ~55px for the web toolbar.  That brings the total to 220px or 300px on
> a device with XO pixel density.  What that equates to is very small.  I had
> a go on my XO [1], and there was only 7cm height left for the content
> (almost same for discourse and sugar-network)!
>
> I understand that the XO is not our only platform.  But on a small laptop,
> adding more toolbars is just counterproductive.
>
>
>> We can use the same viewhelp.py, just adding a toggle bottom to switch to
>> the social help (at the left, the only buttons aligned at the right are
>> the Stop buttons)
>>
>
>
> The idea of a toggle in the bottom left sounds good.
>
> Thanks,
> Sam
>
> [1]  http://imgur.com/FJFAcpl
>
>
>>
>>
>>>> Regarding the proposal, I would like to see this more integrated with
>>>> the Help view.
>>>> Then the changes would be:
>>>> * Don't show two entries in the menu, one for the local help and
>>>> another for the social help.
>>>> First, because in the cases where we have a help for the activity, is a
>>>> good idea show
>>>> that first, and add a button to go o the server if configured.
>>>> * Right now, we show the Help menu only for activities with local Help
>>>> available.
>>>> We should show the menu always, and if not local help is available go
>>>> to social page.
>>>>
>>>
>>> Do you have a UI design in mind?
>>>
>>> Here is a quick mockup to start the conversation if you want:
>>> http://people.sugarlabs.org/sam/mockup.png
>>>
>>>
>>
>>>> My main concern with this feature is how to solve the change to webkit2
>>>> without break
>>>> all the webservices. I think we should include the main (and working)
>>>> webservices in the sugar code,
>>>> port them to webkit2, and then land this feature.
>>>>
>>>
>>> That sounds like a good idea.
>>>
>>> If worst comes to worst, we could use webkit1.  webkit2 has the new
>>> shiny stuff and webkit1 is old, we will have to move someday and why not
>>> before there are way too many web services!
>>>
>>
>> Is good know we have that alternative if we can't land all before May 18.
>> Maybe you can use webkit1 to land the feature and nake the change later.
>>
>> Gonzalo
>>
>>
>>>
>>> Thanks,
>>> Sam
>>>
>>>
>>>>
>>>> Gonzalo
>>>>
>>>>
>>>> On Mon, Apr 20, 2015 at 2:17 PM, Sebastian Silva <
>>>> sebastian at fuentelibre.org> wrote:
>>>>
>>>>>  Hi,
>>>>>
>>>>> For some reason this email found it's way into gmail's spam folder.
>>>>>
>>>>> However the topic is very important.
>>>>>
>>>>> I disagree that this implementation needs to be adopted.
>>>>> In particular, most deployments still don't have a reliable connection
>>>>> to the Internet and we don't want to introduce a dependency on it. Social
>>>>> help might (and should) come from peers first.
>>>>>
>>>>> However, work has been ongoing from different deployments in this
>>>>> (social) direction so it's generally accepted that Sugar needs it. Our own
>>>>> work in Perú has been aligned with Alsroot's work on the Sugar Network ( we
>>>>> developed the first UI, here's a short video explaining it:
>>>>> http://somosazucar.org/2012/06/04/un-avance-de-la-red-azucar-0-3-sneak-peek-of-sugar-network-0-3/
>>>>> ).
>>>>>
>>>>> This work is ongoing. It involves a very light local server capable of
>>>>> synchronizing user resources asynchronously (including comments, bundles,
>>>>> etc) *in both ways*.
>>>>>
>>>>> The effort is very much appreciated. I think we need to morph the
>>>>> proposal into something that is generic or pluggable, and try to work with
>>>>> Alsroot on this.
>>>>>
>>>>> Regards,
>>>>> Sebastian
>>>>>
>>>>>
>>>>> On 19/04/15 20:59, Sam P. wrote:
>>>>>
>>>>>   Hi All,
>>>>>
>>>>>  One feature I'm proposing for the 0.106 cycle is Social Help.  Social
>>>>> Help was previously proposed by Prasoon Shukla as a GSOC project, however
>>>>> my proposal is slightly different.
>>>>>
>>>>>  Patch Link:  https://github.com/sugarlabs/sugar/pull/483/commits
>>>>>  Feature Page:  http://wiki.sugarlabs.org/go/Features/Social_Help
>>>>>  YouTube Video Summary:  https://youtu.be/_WzwVZ60Tbw
>>>>>
>>>>>  I would like to invite discussion on the feature so we can land this
>>>>> for 0.106.
>>>>>
>>>>>  Thanks,
>>>>>  Sam
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Sugar-devel mailing listSugar-devel at lists.sugarlabs.orghttp://lists.sugarlabs.org/listinfo/sugar-devel
>>>>>
>>>>>
>>>>> --
>>>>> I+D SomosAzucar.Org
>>>>> "icarito" #somosazucar en Freenode IRC
>>>>> "Nadie libera a nadie, nadie se libera solo. Los seres humanos se liberan en comunión" - P. Freire
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Sugar-devel mailing list
>>>>> Sugar-devel at lists.sugarlabs.org
>>>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Gonzalo Odiard
>>>>
>>>> SugarLabs - Software for children learning
>>>>
>>>
>>
>>
>> --
>> Gonzalo Odiard
>>
>> SugarLabs - Software for children learning
>>
>


-- 
Gonzalo Odiard

SugarLabs - Software for children learning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20150421/e03b0891/attachment-0001.html>