[Sugar-devel] [somos-azucar] [DESIGN] Home views (was: Request for Sweets Distribution logo)

Aleksey Lim alsroot at sugarlabs.org
Fri Apr 13 01:02:10 EDT 2012


On Thu, Apr 12, 2012 at 09:54:10AM -0400, Frederick Grose wrote:
> On Thu, Apr 12, 2012 at 2:29 AM, Aleksey Lim <alsroot at sugarlabs.org> wrote:
> 
> > On Thu, Apr 12, 2012 at 06:05:56AM +0000, Aleksey Lim wrote:
> > > On Wed, Apr 11, 2012 at 12:00:37PM -0400, Frederick Grose wrote:
> > > >
> > > > This segregation is not  so 'harmonic'.
> > >
> > > Yeah, thats right...
> > >
> > > > Would this be a situation where a global emblem could be applied to the
> > > > Activity icon of globally sourced Activities?
> > >
> > > You mean having a badge painted on activity icons for activities that
> > > came from the Sugar Network? It might be the way if we decide to have
> > > both kinds activities (local and from Sugar Network) in one list.
> > > Right now, it is not clear for me.
> > >
> > > > And shouldn't the Home view options be harmonized with the filters we
> > have
> > > > in the Journal?
> > > > Then one could view all in a list by removing the favorites toggle, or
> > > > filter the favorites by the menu of filters.
> > >
> > > Originally, the intention was having Sugar Network icon as a 2nd/3rd
> > > icon in Home view (not in activities tray how it is implemented right
> > > now). The problem was (it is possible but not trivial) with setting up
> > > interactions between Sugar Network client application (which is local
> > > Web application) and Sugar Shell, also, making it easy to run Sugar
> > > Network client in standalone mode.
> > >
> > > But maybe having exactly Sugar Network view embodied to Home, is the
> > > right way to go. We can, reserver a place for Sugar Network icon in Home
> > > view and move client there after completing more needed work.
> > >
> > > The original problem is, Sugar Network exists in parallel with F1/F2/F3
> > > views:
> >
> 
> This is a key feature, which suggests that one always has the relevant
> Sugar Network services at hand (nomodes), at least as a design goal.

Yeah. For example, I'm not quite happy with current implementation when
Sugar Network icon is in activities tray: it is not an activity (but
rather a general service) and, e.g., it is hard to fast switch between
Sugar Network view and current activity.

> Global features could be revealed from a button in the Neighborhood view
> toolbar, or triggered by touching the Neighborhood view icon (a subsequent
> touch would reveal the traditional Neighborhood).
> 
> Group level features could be revealed from 'project or thread' icons in
> the Group view field.

If I got you you right, you are talking about:

    If we have the current status quo:

    * F1, global view
    * F2, group view
    * F3, local/personal view

    And need to embody Sugar Network to basic Sugar Shell UI,
    we can scatter Sugar Network UI between these three levels?

    * F1, a toolbar button (or a subsequent touch for frame button)
      to switch between current F1 view and Sugar Network view with
      exposing all the content accessible globally (if we are connected
      to the server)
    * F2, the same switch mechanism for group related functionality (if
      it will exist) of Sugar Network
    * F3, the same switch mechanism to see Sugar Network content
      accessible in off-line

> Offline copies would be identified with badges in the Journal and Home
> views.  Filters could segregate them if desired.

+1, it should be really useful to save screen space, even for setting
off-line/on-line mode, e.g., if cursor is hovering over the left-bottom
corner of the activity icon, UI might expose possibility to set this flag.

> When offline copies are created from a Global-or-Group-view-triggered
> screen, a notification like the download notification would offer to take
> you to the new object's local instance for verification or immediate
> action, if desired.

>From one side, having an alert (like with downloads from Browse) is not
needed all time. The SN client library keeps a cache of bundles and if
you started the activity, you are trying to make off-line accessible,
recently, the process will be immediate. From another side, alert
might be useful if we need to expose the fact that user is going to
persistently take "n bytes" of disk space. But, if we will expose those
"n bytes" somewhere in the UI (for "X" Home mode, in popup palette), we
don't need alerts (might be annoying) at all.

Also we don't need alert to "to take you to the new object's local instance".
Because the only difference between remote and local activities is a
badge, i.e., being off-line user will find activity exactly in the same
place where he made it off-line being on-line.

> An interim modal version of the Sugar Network may seem to be an efficient
> construction plan, however, I think that it could severely, and subtly,
> limit innovation and integration of the design--if not in the minds of
> developers, certainly in the minds of many reviewers.
> 
>         --Fred

-- 
Aleksey


More information about the Sugar-devel mailing list