[IAEP] [somos-azucar] sugar hack - feedback

[Aleksey Lim]

On Wed, Jul 18, 2012 at 10:56:14PM -0500, Laura Vargas wrote:
> 2012/7/18 Aleksey Lim <alsroot at sugarlabs.org>
> 
> > CCing to iaep at . This is a feedback reagarding Sugar Network[1]
> > Web UI look&feel. Original post[2].
> >
> > On Tue, Jul 17, 2012 at 03:50:09AM -0500, Laura Vargas wrote:
> > > De la jornada de la mañana quedaron documentadas las siguientes
> > > recomendaciones de Julita, Alejandro y Ketty:
> > >
> > > 01 Interfase Gris? ("en Perú primaria es Sugar y Sugar es primaria")
> > >      Color* sobre los recursos problema/rojo idea/amarillo
> > >      pregunta/azul reseña/verde?
> >
> > My own perception is. It might be good for Sugar Shell (and sometimes
> > for Sugar Activities) to follow common design idea with having grey
> > "background" and objects painted to user's colors to expose the
> > ownership (or how the original design idea sounds). But I don't see any
> > reasons to extrapolate this design solution to all software that people
> > will use/run from Sugar Shell:
> >
> > * it is impossible because not all edu software is intended to be
> >   launched only from Sugar Shell;
> > * well, maybe monotone coloring is a good (not sure here) for madhouses
> >   or prisons, but for my self, I'm preferring to switch my desktop
> >   theme/colors from time to time.
> >
> > So, I'm +1 for not strictly following Sugar Shell's coloring paradigm in
> > Sugar Network UI. Partial implementation might be still useful though.
> > For example, using user's colors to expose objects ownership.
> >
> > But maybe it makes sense to forget about this paradigm entirely.
> > It works fine/as-assumed in Sugar Shell when there is a central user -
> > local user and limited number of users that local one is participating
> > with. So, the coloring variety is pretty limited. But, in Sugar Network
> > case when objects are global (at least assumed to be) within the entire
> > Sugar community, it is becoming meaningless - there is a big chance
> > to see duplicates or similar looking colors.

btw, nothing prevents us following the scheme:

* more regular web users identification, avatars
* by default, avtars are XO images painted to user's colors
  (ie, instead of stub avatars)
* but if people think it is not enough, it is possible to upload any image

> > > 03 Es posible que quede un histórico de la edición de los recursos?
> >
> > Could you elaborate it in English.
> >
> 
> Ketty, is one of the teachers that took part in the Arahuay Pilot (first
> pilot for the OLPC project in Perú). As she was very enthusiastic testing
> the Network, her feedback here refers to the convenience (or need) for
> participants
> of being able to track all modifications made by authors to the resources
> (ideas, questions, problems, reviews).
> 
> Basically Ketty's concern had to do with the fact that some comments will
> end up obsolete if not updated in accordance with the resource's evolution
> (editing). Currently only latest edition date and content is visible for
> participants.

If you mean techincal issue with not having real-time updates in UI to
reflect on changes made by other users at the same time on the same
content, then, it needs to be fixed in 0.5 for sure (it is already
implemented underneath to reuse in Web UI).

> One step we could give in this direction, would be to implement
> notifications and define participants will automatically become "followers"
> of the X resource after having at least an effective interaction (like
> giving a solution or making a comment).

But if you talking about "followers" in sense of following in social
networks, this feature is not obvious/trivial to implemented from server
side (assuming the major idea of decentralization of Sugar Network).
For sure, such kind feature needs to be implemented in some sense, but
it make sense to postpone this work until current (from server side pov)
implementation will be well polished.

> > 04 Podremos Adjuntar imagenes (o cualquier tipo de archivo) a los
> recursos?
> 
> I think it will be a good start to attach activity objects (from
> > Journal). We can improve this workflow at any time later.
> >
> 
> +1

We also have Journal related issue in current implementation. Even
during testing period, it is annoying that on every click on activity in
Web UI, it creates new Journal object. Thats sounds reasonable TODO
point to have Journal integration in 0.5.

-- 
Aleksey