Re: [Sugar-devel] [Dextrose] Report on Sl# 2080 , Pulsing icon delayed by 5 seconds or so.

[Eben Eliason]

On Fri, Nov 5, 2010 at 12:46 PM, Gonzalo Odiard  wrote:

>
> Hmmm, no, with Martin's below linked patch pulse colour animation is good.
>>
>> The only extra thing I noted in my email was that the 1sec zoom effect is
>> still not showing for anything by very simple icons (Log icon is simple
>> enough, Distance is not), however the zoom effect is not showing with your
>> 'skip the first update' approach either. Fixing zoom efficiency should be
>> looked at as a separate issue.
>>
>>
> Is really needed the zoom?
> If we can't do it in a efficient way, may be we can use another metaphor.
> What about moving the icon from the position in the home view to the screen
> center?
>

I think this would be nice. In our early animated mockups, this was actually
the intent (in addition to the zoom). This should work in all zoom levels
and views. I think doing that would be beneficial even with the zoom, and
might allow us to show the zoom only on devices capable of handling it.

I don't know where else this video lives, so here's a link to my copy of it:
http://www.somethingofrecord.com/images/uploads/sugar_vision.mov

Eben



> I think we must do all we can to start quickly the activities.
>
> Gonzalo
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Sugar Journal - Erase confirmation

[Eben Eliason]

On Tue, Sep 21, 2010 at 4:18 PM, Walter Bender wrote:

> On Tue, Sep 21, 2010 at 10:11 AM, Tomeu Vizoso 
> wrote:
> > On Mon, Sep 20, 2010 at 23:50, Samuel Greenfeld 
> wrote:
> >>  In Sugar's Journal, the per-entry "Erase" menu choice does not ask for
> >> any confirmation prior to deleting an object.
> >>
> >> This presents the risk of accidentally deleting something, especially
> >> since the "View Details" menu choice is immediately above it
> >>
> >> I searched bugs.sugarlabs.org looking to see if anyone had ever
> >> suggested verifying the erasure/deleting of a Journal entry prior to
> >> doing so, but could not find any obvious tickets on the subject.
> >>
> >> Does anyone know if this is by design?
> >
> > I don't really remember, adding Eben and Christian to CC in case they do.
>
> I don't remember either. We really should be asking to confirm,
> especially for user-generated data. But if and when someone digs into
> that code, it would be great to finally address the issue of selecting
> multiple objects.  Deleting one item at a time, even without the
> additional step of a confirmation, is tedious.
>

Agreed. I think the expectation there was that a confirmation dialog would
appear in a strip beneath the toolbar, with "Cancel" and "Erase" buttons.

I also agree with Walter regarding the need for multiple selection support;
we had some nice mockups with checkboxes that enabled single-click (without
modifier) selection of sets of objects to take action on.

Eben



>
> -walter
>
> -walter
>
> > Cheers,
> >
> > Tomeu
> >
> >> ---
> >> SJG
> >> ___
> >> Sugar-devel mailing list
> >> Sugar-devel@lists.sugarlabs.org
> >> http://lists.sugarlabs.org/listinfo/sugar-devel
> >>
> > ___
> > Sugar-devel mailing list
> > Sugar-devel@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Putting stuff in the control panel vs. the frame

[Eben Eliason]

On Tue, Aug 3, 2010 at 11:51 AM, Christoph Derndorfer <
christoph.derndor...@gmail.com> wrote:

> Hi all,
>
> looking at some of ParaguayEduca's latest builds I saw that they have added
> some new icons / features to the frame (e.g. CPU / memory consumption,
> accessibility, touchpad-mode, etc.)
>
> I talked to Bernie about this and we realized that there currently doesn't
> seem to be a clear consensus on what kind of features should go into the
> frame and which ones into the control panel. One could easily argue that
> some sparsely populated CP options could be removed and the options instead
> added to the corresponding frame devices (particularly power and network
> options come to mind here). Or on the contrary that things like the
> touchpad-mode should be accessed from within the CP rather than the frame.
>
> Anyway, I was wondering what people here thought about this issue.
>

I think that the dominant factor in the choice of what to show should be the
frequency with which the information or controls are used. If a setting is
changed frequently by a child within a single "session" it's a good
candidate for a device icon in the Frame. If the setting is, more often than
not, set and then forgotten it should exist only within the Control Panel,
where it won't distract from more important information and controls.

I also agree with the idea Tomeu brought up; I think linking to the
corresponding section of the Contol Panel from any devices that have
additional settings makes a lot of sense.

Eben


> Cheers,
> Christoph
>
> --
> Christoph Derndorfer
> co-editor, olpcnews
> url: www.olpcnews.com
> e-mail: christ...@olpcnews.com
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Schoolserver icon

[Eben Eliason]

Ah, I see now. At first glance at the previous iteration I thought that it
was just the stroke of a bell shape; I didn't read the bell within the arch.
I do like that idea, actually, but this version does read more clearly. It
looks great!

I'm not sure if this would be any better or not, but have you tried a solid
stroke-color "cap" on the steeple? You could also widen the steeple a bit to
make the bell even larger for clarity. (These are just "what if"s, though,
not recommendations…it already looks great.)

Eben


On Fri, Jul 2, 2010 at 10:02 PM, Gary Martin wrote:

> On 3 Jul 2010, at 01:42, Eben Eliason wrote:
>
> > The door and the bell could both be solid stroke-colored fills. That
> would give it a simpler overall shape and likely allow the bell to be more
> legible at the size.
> >
> > Eben
>
> Thanks for the feedback, good call!
>
>
>
>
>
>
>
>
>
>
> Regards,
> --Gary
>
> > On Fri, Jul 2, 2010 at 7:41 PM, Gary Martin 
> wrote:
> > Hi  Martin,
> >
> > On 2 Jul 2010, at 19:10, Martin Abente wrote:
> >
> > > On Tue, 29 Jun 2010 21:53:59 +0100, Gary Martin
> > >  wrote:
> > >> On 29 Jun 2010, at 15:39, Martin Langhoff 
> > >> wrote:
> > >>
> > >>> On Mon, Jun 28, 2010 at 6:57 PM, Bernie Innocenti <
> ber...@codewiz.org>
> > >>> wrote:
> > >>>> El Mon, 28-06-2010 a las 21:36 +0100, Gary Martin escribió:
> > >>>>
> > >>>>> A joke right? Something I missed from the early days?
> > >>>>
> > >>>> No joke! Sugar Labs is actually a masonic lodge. Oops, now I'll have
> > > to
> > >>>> kill you.
> > >>>
> > >>> *I actually got questions about masonic influence on our UI design.*
> > >>> Not kidding...
> > >>>
> > >>> Anyway - there's a nice school at the 1 minute mark in this video -
> > >>>
> http://www.dailymotion.com/video/x7ft2t_olpc-mission-video-part-1_tech
> > >>
> > >> Thanks for the pointer, yea that works, a little like the top right
> > > 'with
> > >> bell' attempt on my last sheet. I worried that one would be seen as
> too
> > >> church like.
> > >>
> > >
> > > I think that one looks really good :) Would you mind sending me the svg
> > > version?
> >
> > Sure. I've attached a SVG that is a (close) reproduction of the school
> with bell tower as shown in the OLPC promotional video (and similar to the
> top right icon from my previous email set). The one major change was to make
> proper use of fill and stroke colour, not just a single fill silhouette. The
> school-server icon needs to show colour identity in the neighbourhood, just
> like other objects.
> >
> > Martin (Langhoff): Can you confirm the server does pass some unique
> identity that could be used to set the icon fill and stroke identity
> colours? Sorry I don't know enough about the registration/ident. server
> process.
> >
> > Here's what it looks like in different colours at a small (close to
> neighbourhood view), and a larger size:
> >
> > Shout if you want changes/tweaks. Hope it's of use.
> >
> > Regards,
> > --Gary
> >
> > >> Regards,
> > >> --Gary
> > >>
> > >>> m
> > >>> --
> > >>> martin.langh...@gmail.com
> > >>> mar...@laptop.org -- School Server Architect
> > >>> - ask interesting questions
> > >>> - don't get distracted with shiny stuff  - working code first
> > >>> - http://wiki.laptop.org/go/User:Martinlanghoff
> > >> ___
> > >> Sugar-devel mailing list
> > >> Sugar-devel@lists.sugarlabs.org
> > >> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Schoolserver icon

[Eben Eliason]

The door and the bell could both be solid stroke-colored fills. That would
give it a simpler overall shape and likely allow the bell to be more legible
at the size.

Eben


On Fri, Jul 2, 2010 at 7:41 PM, Gary Martin wrote:

> Hi  Martin,
>
> On 2 Jul 2010, at 19:10, Martin Abente wrote:
>
> > On Tue, 29 Jun 2010 21:53:59 +0100, Gary Martin
> >  wrote:
> >> On 29 Jun 2010, at 15:39, Martin Langhoff 
> >> wrote:
> >>
> >>> On Mon, Jun 28, 2010 at 6:57 PM, Bernie Innocenti 
> >>> wrote:
>  El Mon, 28-06-2010 a las 21:36 +0100, Gary Martin escribió:
> 
> > A joke right? Something I missed from the early days?
> 
>  No joke! Sugar Labs is actually a masonic lodge. Oops, now I'll have
> > to
>  kill you.
> >>>
> >>> *I actually got questions about masonic influence on our UI design.*
> >>> Not kidding...
> >>>
> >>> Anyway - there's a nice school at the 1 minute mark in this video -
> >>> http://www.dailymotion.com/video/x7ft2t_olpc-mission-video-part-1_tech
> >>
> >> Thanks for the pointer, yea that works, a little like the top right
> > 'with
> >> bell' attempt on my last sheet. I worried that one would be seen as too
> >> church like.
> >>
> >
> > I think that one looks really good :) Would you mind sending me the svg
> > version?
>
> Sure. I've attached a SVG that is a (close) reproduction of the school with
> bell tower as shown in the OLPC promotional video (and similar to the top
> right icon from my previous email set). The one major change was to make
> proper use of fill and stroke colour, not just a single fill silhouette. The
> school-server icon needs to show colour identity in the neighbourhood, just
> like other objects.
>
> Martin (Langhoff): Can you confirm the server does pass some unique
> identity that could be used to set the icon fill and stroke identity
> colours? Sorry I don't know enough about the registration/ident. server
> process.
>
> Here's what it looks like in different colours at a small (close to
> neighbourhood view), and a larger size:
>
>
>
>
>
>
>
>
>
>
> Shout if you want changes/tweaks. Hope it's of use.
>
> Regards,
> --Gary
>
> >> Regards,
> >> --Gary
> >>
> >>> m
> >>> --
> >>> martin.langh...@gmail.com
> >>> mar...@laptop.org -- School Server Architect
> >>> - ask interesting questions
> >>> - don't get distracted with shiny stuff  - working code first
> >>> - http://wiki.laptop.org/go/User:Martinlanghoff
> >> ___
> >> Sugar-devel mailing list
> >> Sugar-devel@lists.sugarlabs.org
> >> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Simple Journal Backup & Restore Control Panel

[Eben Eliason]

Hello,

I realize it's been a while since this was discussed, but I figured
I'd share some thoughts, in no particular order before I archived the
thread.

• Having a settings module for this seems reasonable. It might be more
fitting to just call it "Journal Backup" instead of "Management",
since it is exclusively for this function. I could see adding any
pertinent versioning settings here as well in the future, even with
the more specific name.

• It could also be nice to have a "Back up now" option in the Journal
palette. I don't think it's necessary to expose the restore action in
the palette, though.

• The icon looks reasonable, though using the "fullscreen" icon in
this context is somewhat confusing. It might be better to use the keep
icon, with bidirectional arrows, to maintain the visual language
there.

• The large clickable buttons are nice. I think in this instance it
would be even better to have nice large up and down arrows to further
emphasize the actions. The ones that were made for the 3G device
traffic could work in this context, too.

• I think this might work better as a two column layout, with backup
on the left and restore on the right, with accompanying text and
information. As it stands, the description is a bit far removed from
the actual buttons, making it look more like the buttons are one unit
and the descriptions are a second unit, instead od relating the
description to the button.

• I would change the label to "Back up now" instead of "Backup." Two
notes on that: first, it's a pet peeve, but "back up" should be two
words when used as a verb (a "backup" is a noun), and buttons should
always read as actions; second, I think emphasizing the "do it now"
nature of the button is useful here, especially since backups should
be made automatically, periodically. In fact, changing the description
to convey this would also be useful.

• It would also be great to have an indication of the last time a
backup was made, to know whether or not it's worth invoking another. I
would add a "Last backup:" label with a relative date (eg. "3 hours
ago") to the backup column.

• The restore column would do well to convey the results of the
action. Specifically, that it will restore the Journal to a previous
state, which could result in data loss.

• It's not clear from the image what happens when either of these
actions are invoked. I'd recommend immediately disabling the "other
column" (eg. disable the restore button when a backup is initiated),
and replacing the button clicked with an inline progress bar
(determinate, if at all possible; perhaps indeterminate during
initialization) so there's adequate feedback.

• If there is any way to detect when a Journal has been
corrupted/wiped, it would be great to have the empty Journal screen be
replaced by a prompt to recover from backup, if one is known to exist.
This would make it much easier for kids to recover the Journal as it
was in such circumstances.

Eben

PS. I think its useful to consider the UI for Apple's Time Machine
here, since it has a number of similarities.


On Thu, Apr 8, 2010 at 11:05 AM, Tomeu Vizoso  wrote:
> On Thu, Apr 1, 2010 at 04:30, Bernie Innocenti  wrote:
>> On Thu, 2010-04-01 at 09:21 +1100, James Cameron wrote:
>>> On Wed, Mar 31, 2010 at 06:36:06PM -0300, mabente wrote:
>>> > So, what do you guys think?
>>>
>>> I like it.
>>>
>>> I presume it won't appear unless a school server is known?
>>
>> I wonder if this can be done at the control panel level... probably
>> easier to let the icon appear anyway, and then disable the functionality
>> in the window.
>>
>> In the future, we may want to add a backup/restore function for
>> removable storage.
>
> Any comments from the design team?
>
> Regards,
>
> Tomeu
>
>> --
>>   // Bernie Innocenti - http://codewiz.org/
>>  \X/  Sugar Labs       - http://sugarlabs.org/
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Keep confusion, yet again

[Eben Eliason]

On Wed, Apr 21, 2010 at 7:18 PM, Chris Ball  wrote:
> Hi Eben,
>
>   > I'd lean toward the first option. It's intended purpose was
>   > always to be a convenience on top of auto-save, that simply
>   > forced a new version. Once Sugar has full version support, and a
>   > Journal updated to take advantage of it, restoring the Keep
>   > functionality as it exists probably wouldn't cause problems
>   > anymore. Until then, I think the auto-save is much friendlier
>   > than the usual prompt-on-quit, with the possibility for lost
>   > work.
>
> Think I'm having trouble following -- are you proposing that we remove
> the Keep button now, and also remove the prompt-on-quit dialog now?

No, sorry.  The current prompt-on-quit is fine, as it only occurs when
you stop a brand new activity instance. It basically asks "do you want
me to keep track of this thing in your Journal," and from then on it
will auto-save as usual.

Since the Keep button is causing so much confusion, I was proposing to
remove it for now (until we have more complete version support), but
keep the prompt the first time a new instance is stopped. We can still
skip the prompt if the instance is manually renamed, under the
assumption that naming the item implies a desire to track it in the
Journal.

Eben


> Thanks,
>
> - Chris.
> --
> Chris Ball   
> One Laptop Per Child
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Keep confusion, yet again

[Eben Eliason]

On Wed, Apr 21, 2010 at 6:22 PM, Bert Freudenberg  wrote:
> On 21.04.2010, at 23:57, Chris Ball wrote:
>>
>> Hi,
>>
>>> I think that's what we want; this new string will come up as
>>> untranslated in pootle, alerting translators to submit
>>> translations for the clearer string.
>>
>> Ah, that's fine.  (I assumed we'd want to use the old translations in
>> the meantime.)
>>
>> - Chris.
>
> The actual problem is that renaming the button does not help. The mouse-over 
> balloon in Etoys says:
>
>        "Keep a copy of the current project in the Journal"
>
> It's no use.
>
> There are only two options IMHO:
>
> 1) Remove the button. If you want to copy an entry, use the Journal.
>
> 2) Make the button actually overwrite the entry. No silent auto-save on exit, 
> but ask if save is desired.

I'd lean toward the first option. It's intended purpose was always to
be a convenience on top of auto-save, that simply forced a new
version. Once Sugar has full version support, and a Journal updated to
take advantage of it, restoring the Keep functionality as it exists
probably wouldn't cause problems anymore. Until then, I think the
auto-save is much friendlier than the usual prompt-on-quit, with the
possibility for lost work.

Eben


> - Bert -
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Show file size in Journal

[Eben Eliason]

On Thu, Apr 8, 2010 at 8:35 AM, Bert Freudenberg  wrote:
> On 08.04.2010, at 13:47, Eben Eliason wrote:
>>
>> On Thu, Apr 8, 2010 at 7:18 AM, Sascha Silbe
>>  wrote:
>>> On Wed, Apr 07, 2010 at 08:43:29PM -0300, Kenny Meyer wrote:
>>>
>>>> Bernie and I have been discussing about showing the file size in Journal
>>>> view
>>>> of Sugar 0.84.x, [...]
>>>
>>> As already mentioned on the ticket, Sugar 0.86+ does that (in the details
>>> view). The commits are 85b833 [1] and 6c3fd034 [2]. A quick look suggest
>>> they should be easy enough to backport.
>>
>> Yeah, that's certainly one place it makes sense to show it; the
>> palette for Journal objects also makes sense. I like the idea of
>> exposing it as blocks, and agree with Bert that its essential that
>> those blocks be linear. With that approach, maybe the details view is
>> the only place that there is room to illustrate size that way.
>
> In the details view you only see a single entry, I'd expect the exact size 
> shown numerically there. The graphical form is much more useful for visually 
> comparing multiple entries.
>
>> One approach to showing size might be to "pretend" that we're in base
>> 9, so that one "big block" is 1MB, and 9 small blocks stack together
>> in a 3x3 grid to form a big block. I'm not sure granularity needs to
>> be more precise than that (though we could also show a precise value
>> as a number, too).
>
> Just to be pedantic: that would still be linear, not base-9 logarithmic ;)

Yeah.

> Otherwise the idea is sound, at least for entries up to a few MB. But what 
> about larger ones? Given that Sugar runs on netbooks that frequently have a 
> 160 GB disk, there should be some theory about dealing with large files IMHO.

Well, for arguments sake, we could assume that 1 unit (about 114
bytes) is 5px square. So 1MB (9 units) would be, say, 5*3 + 2 (for
spacing) = 17px square, and therefore up to 9MB is representable
within 17*3 + 4 (again, for spacing) = 55px square. That's exactly the
maximum area of an icon within one grid cell. Maybe that's too small,
but maybe not.

The real problem is that "linear" (which we both want) is
fundamentally non-scalable in a fixed screen size. Without a
logarithmic scale for size, we'd need to have a zooming factor to
continue to fit more blocks into fewer pixels. Perhaps we could drop
down to 3px squares for the smallest unit after some critical point.
Or, we could try using colors/values to convey the difference in block
sizes. Unfortunately, it's a bit harder to educate that 9 blue blocks
equals one red block than that 9 small blocks equals one large block.

Eben



>
> - Bert -
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Show file size in Journal

[Eben Eliason]

On Thu, Apr 8, 2010 at 7:18 AM, Sascha Silbe
 wrote:
> On Wed, Apr 07, 2010 at 08:43:29PM -0300, Kenny Meyer wrote:
>
>> Bernie and I have been discussing about showing the file size in Journal
>> view
>> of Sugar 0.84.x, [...]
>
> As already mentioned on the ticket, Sugar 0.86+ does that (in the details
> view). The commits are 85b833 [1] and 6c3fd034 [2]. A quick look suggest
> they should be easy enough to backport.

Yeah, that's certainly one place it makes sense to show it; the
palette for Journal objects also makes sense. I like the idea of
exposing it as blocks, and agree with Bert that its essential that
those blocks be linear. With that approach, maybe the details view is
the only place that there is room to illustrate size that way.

One approach to showing size might be to "pretend" that we're in base
9, so that one "big block" is 1MB, and 9 small blocks stack together
in a 3x3 grid to form a big block. I'm not sure granularity needs to
be more precise than that (though we could also show a precise value
as a number, too).

>> Now, I thought of an extra column "Size", showing the size of the file in
>> bytes.
>
> I don't think taking away space from other columns is a good idea on the XO.

Agreed.

> Reclaiming space sounds like a good use case for a separate activity that
> shows the data store in a view optimized for this particular task.

Long ago, we anticipated that the Journal would, at some point when
space reached a critically low point, assist children in cleaning up
their Journals. The plan was to create some heuristic for identifying
entries in the Journal that may not be that useful, and/or would be
most beneficial to remove. For instance, with versioning, it might be
safe to remove old and/or intermediate versions that were auto-saved;
it might be safe to remove really old entries that aren't starred;
entries that haven't been opened in a while; entries that are extra
large; etc. Entries that fit several of these conditions might be the
first recommended.

Anyway, in "cleanup mode", we could present a list which did highlight
size as a key element. Basically, take your suggestion of making a
separate activity, and just wrap it into a separate mode of the
Journal instead. Whether or not this mode was always entered
automatically, or also had a manual trigger, would need to be decided.

Perhaps instead of representing the total number of blocks the Journal
takes up, this mode could instead represent the number of blocks
needed to be cleared to continue using their Journal normally. Then
kids could compare the blocks of various entries against the remaining
number in their "goal" meter to make decisions about what to remove.

Eben


>
> [1]
> http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/85b833960ded9148fbb42e773720ba3bcb02145e
> [2]
> http://git.sugarlabs.org/projects/sugar-toolkit/repos/mainline/commits/6c3fd0346c1876ad501c3c91d50cdf42f7e0a9dc
>
> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJLvbtrAAoJELpz82VMF3Da7/kH/R6IMUCJi9QUEgSFGrj88EmO
> /OhArTf2vHaeiovI4Ew06xDdQLZbtLoX3+0AdXHyuMvKg+aR93F7BdGkXozB4QBY
> Dm3P6yOCI25yIKjolAOEoLpujDiHPOCldqEjqMnvmshv3IlgaB1dIM/KHQa0OY43
> I5qZYz6xxZ8fUPv238y+11qiId1VedWLHPiQVb0xHRJAELDRtiXv+D325zOrM8cm
> qY34Rq+NNF0bPDxHVCmDJ2J/QQvk40U5JD0qoxyNhWy77XVpWJHJwrSJxVqZGVAQ
> UvKojBYCxipDAsNwfPTeXX7NsSuS3/0TORpnLk/2HcZkYD/VbiOksLR//Q0eH/4=
> =RBBS
> -END PGP SIGNATURE-
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] scalability in the neighborhood view

[Eben Eliason]

On Wed, Mar 24, 2010 at 2:38 PM, Frederick Grose  wrote:
> On Wed, Mar 24, 2010 at 8:57 AM, Eben Eliason 
> wrote:
>>
>> ...
>>
>>
>>
>> Yeah, definitely. We did a lot of thinking on this topic way back
>> when, so there is some documentation already describing a proposed
>> model:
>> http://wiki.sugarlabs.org/go/Design_Team/Specifications/Groups
>>
>> We also have a first series of mockups of how this might look in the
>> UI, though I'm not sure that those are posted anywhere, ...
>
> See http://wiki.sugarlabs.org/go/Design_Team/Proposals/Groups

Yup, those are the ones! Thanks.
Eben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] scalability in the neighborhood view

[Eben Eliason]

On Wed, Mar 24, 2010 at 8:32 AM, Martin Langhoff
 wrote:
> On Wed, Mar 24, 2010 at 3:28 AM, Tomeu Vizoso  wrote:
>>> Yep - no prob for me. The GUI side probably needs a bit of extra
>>> thinking so that it avoids being specific to the backend works (moodle
>>> in this case)...
>>
>> I was thinking that Moodle would put contacts in groups in the server
>> side and Sugar would just use the standard Telepathy interfaces.
>
> Yep. Agreed, same here.
>
> What I was thinking about was the UI design... for example, just one
> very obvious case we have to deal with: it is a good idea to design
> the UI so that we have a metaphor to edit groups (create, add/remove
> users). This can work server-less or with XMPP/Moodle backends -- we
> have to define a "lowest common denominator" and aim to use just that.

Yeah, definitely. We did a lot of thinking on this topic way back
when, so there is some documentation already describing a proposed
model:
http://wiki.sugarlabs.org/go/Design_Team/Specifications/Groups

We also have a first series of mockups of how this might look in the
UI, though I'm not sure that those are posted anywhere, and they might
need some tweaking in any case. Agreeing on the behavior is key,
though.

> For the initial implementation we are discussing, I would avoid
> implementing the client-side editing, and go instead for something
> easy: just read the groups via Telepathy -> Gabble -> XMPP (which in
> turn is controlled by Moodle). But if we have a plan for the "full"
> interaction, we can start implementing the basics.

Agreed. We can start by basically just adding the filter to the UI for
now, and add any creation/management UI in the future.

> Without looking at the long term UI, maybe we implement something and
> then... have to change the UI significantly in the "next stage".

Yeah, I think that's a great goal; I also think it will be relatively
easy to succeed in doing so, especially if the only core UI added for
now is the group filter (in the Groups view, in the Journal, for
various actions eg. Share with, Send to, etc.)

> It's not a big deal... I just think it would be good to have a chat or
> two to define some of those "lowest common denominators" strategies,
> and some key "features".

I look forward to hearing feedback on that draft spec in the wiki. I
just read through it again, and from my perspective it still sounds
pretty solid. I know little of moodle, so I'd be curious to know how
well it integrates there, but it seems like a fairly basic set of
parameters and actions that will still provide a great deal of
versatility.

> An example on the 'feature' side: one of the strongest requests from
> the field I have is something I don't think we ever thought about --
> teachers want to set a mode in Moodle that forces all kids' XOs to
> only show _this_ group/course/classroom members. Not sure how that'd
> work but I get that request from several independent deployments.

Would you like to add a section to the wiki page entitled something
like "Other Requested Features" to track any specific details like
this that the current proposal doesn't cover?

> I probably need to think these ideas through, and throw them in the
> collective pot... if you're interested...

Definitely.

Eben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] scalability in the neighborhood view

[Eben Eliason]

On Wed, Mar 3, 2010 at 2:08 PM, Martin Langhoff
 wrote:
> On Wed, Mar 3, 2010 at 1:02 PM, Caroline Meeks  
> wrote:
>> would be a nice feature to eventually have to let the teacher narrow down
>> the neighborhood based on a specific Moodle group, for a specific period of
>> time.  That is have students focus on only other students in their class
>> right now.
>
> Yeah, I've thought of that, and heard/read this kind of request a few times.
>
> Once we are where Tomeu wants to take us, I think it'll make sense to
> add something like what you describe, perhaps in the neighbourhood
> view or in the 'friends' view.

This has always been the intent of the "middle" view, which was
designed as a "Groups" view (with a number of configurable filters for
various groups a student might be a part of) and is currently just a
"Friends" view. After adding further group support, I suspect
"Friends" will just be one of the available groups.

I know that improvements to Groups/Friends view have been no the table
for upcoming releases, so maybe we can start with a Moodle-only
approach and later extend to a generic system that works with or
without a server.

Eben

> It's probably a mode that Moodle signals to the laptops. The data on
> the Sugar side is the same, but the UI changes a bit to help focus.
>
> cheers,
>
>
>
> m
> --
>  martin.langh...@gmail.com
>  mar...@laptop.org -- School Server Architect
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  - http://wiki.laptop.org/go/User:Martinlanghoff
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Customizing Frame look (was: Re: Children want Sugar 0.84, for the wrong reason)

[Eben Eliason]

On Sat, Mar 13, 2010 at 9:39 AM, Sascha Silbe
 wrote:
> On Sat, Mar 13, 2010 at 01:35:55PM +0100, Bert Freudenberg wrote:
>
>> E.g., why not allow to change the gray frame color?
>
> I like that idea - it even increases security as it makes it harder to
> imitate the Frame. Not that we are even near a level of security where we
> need to worry about that...

The reason grays were chosen is because the various icons throughout
the UI (activities, XOs, clippings, etc.) all have unique colors of
their own, and without drop shadows or other visual cues, these icons
can be lost against colored backgrounds. Any effort to add
customization in the form of coloring UI elements needs to be quite
carefully considered to prevent this problem.

In fact, the specific shades of grays were chosen to provide the best
visual contrast between the available color choices and all
backgrounds, so that in low contrast situations (and specifically the
XO laptop's reflective mode) all icons remain visible.

Eben


> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJLm5VyAAoJELpz82VMF3DaK84H/0O7aepK3vYydj/DhYlqzt0H
> vMK1nXqPMMWl86Vl/VXPRDzUsZXCLmY89au+U98FiKR2wn49xVkRopvMOaGrqVpp
> jKjcGk0knPCI+FKubrYMwaZcLg3uuIomQ9pLFE41JZnI6VAdQSGLEbBPEPeoOptk
> /bdu0Ii3aSrog8glU3QDsp6qXg/fsJGr5QMlHfIByO/gdAg01NTMNaHc1syIzDXp
> GQhsAvcODF5ZtOqujdcwYEWSJ4CVbBjQ0KK1EyPS3xpCUSNgbMPeBqOTTx28hhHD
> jUkkim9BEJDbQhpumi9pJK7w3tsx0H2uofEUKmVNRmMH/O/XbDXOBusPX27pBXQ=
> =5lQh
> -END PGP SIGNATURE-
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Showing 3G Connection Errors

[Eben Eliason]

On Sat, Feb 27, 2010 at 10:07 AM, Tomeu Vizoso  wrote:
> On Fri, Feb 26, 2010 at 23:03, Gary C Martin  wrote:
>> On 26 Feb 2010, at 15:59, Tomeu Vizoso wrote:
>>
>>> On Fri, Feb 26, 2010 at 13:30, Daniel Castelo
>>>  wrote:
>>>> I've applied Eben's mockup, I also tried to show the connection errors 
>>>> using
>>>> an alert inside the palette.
>>>> This solution has the problem that Tomeu said: when user clicks "connect",
>>>> the palette is hidden and users could miss the notification.
>>>> Is a solution that doesn't look nice, because the palette should resize to
>>>> show the errors.
>>>
>>> We could bring attention to the issue by using a notification, but I'm
>>> not really seeing a good solution for this. Any ideas?
>>
>> Is it possible to override the dismissing of the palette when connect is 
>> clicked? User sees a 'connecting' positive feedback message in the palette, 
>> with the palette only auto-dismissing after a successful connection?
>
> I think it's pretty doable from the coding side and could work quite
> well in this case. About the design side, do we want to introduce this
> variation?

This could be a bit odd. Since the palette is attached to the Frame,
does that also prevent the Frame from hiding? How long does it usually
take to connect? Could it get in the way of the user?

I think in an upcoming release it makes sense to put more time into
the notification system to support this type of thing. (For instance,
upon failure, the 3G icon would appear and blink in the lower right
corner for a bit; It would continue to have a different visual
treatment within the Frame if you didn't click it in time in the
corner; When clicked it would reveal the error and any actions to
take.)

In the short term, I guess we could still use the notification system
to get your attention, though the rest of the behavior wouldn't be as
clean. But, if we're using the usual transformation of the icon from
white to XO colors when connecting, and drop back to white when
connection fails, we're no worse off than wifi connection errors until
we institute a more complete design for notifications.

Eben


> Regards,
>
> Tomeu
>
>> Regards,
>> --Gary
>>
>>> Thanks,
>>>
>>> Tomeu
>>>
>>>>
>>>> On Sun, Feb 21, 2010 at 12:27 PM, Tomeu Vizoso 
>>>> wrote:
>>>>>
>>>>> On Fri, Feb 19, 2010 at 16:41, Eben Eliason 
>>>>> wrote:
>>>>>> On Wed, Feb 17, 2010 at 2:27 PM, Daniel Castelo
>>>>>>  wrote:
>>>>>>> Hi, today we don't show all the 3G connection errors. The unique error
>>>>>>> that
>>>>>>> we show is the "Authentication Error" when the Pin/Puk Sim
>>>>>>> configuration is
>>>>>>> wrong. In this case we show the error in the connection pallete. When
>>>>>>> users
>>>>>>> clicks over the message, the pallete returns to normal behavior. We
>>>>>>> want to
>>>>>>> display all the connection errors. How is the best way to show this?
>>>>>>
>>>>>> I'd recommend showing one or more buttons for dismissing the error and
>>>>>> taking any other relevant actions within the palette. Clicking on the
>>>>>> text label likely won't be very discoverable.  For instance, this
>>>>>> error might have two normal buttons for "Cancel" and "Show Settings"
>>>>>> (assuming something in settings can be adjusted to improve the
>>>>>> situation; I don't know enough about what this error means).
>>>>>
>>>>> Hmm, but if the error appears in the palette, and the palette is
>>>>> hidden when the Connect option is clicked, won't most users miss the
>>>>> notification?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Tomeu
>>>>>
>>>>>
>>>>>> Eben
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ing. Daniel Castelo
>>>>>>> Plan Ceibal - Área Técnica
>>>>>>> Avda. Italia 6201
>>>>>>> Montevideo - Uruguay.
>>>>>>> Tel.: 601.57.73 Interno 2228
>>>>>>> E-mail : dcast...@plan.ceibal.edu.uy
>>>>>>>
>>>>>>> ___
>>>>>>> Sugar-devel mailing list
>>>>>>> Sugar-devel@lists.sugarlabs.org
>>>>>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>>>>>
>>>>>>>
>>>>>> ___
>>>>>> Sugar-devel mailing list
>>>>>> Sugar-devel@lists.sugarlabs.org
>>>>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Ing. Daniel Castelo
>>>> Plan Ceibal - Área Técnica
>>>> Avda. Italia 6201
>>>> Montevideo - Uruguay.
>>>> Tel.: 601.57.73 Interno 2228
>>>> E-mail : dcast...@plan.ceibal.edu.uy
>>>>
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Showing 3G Connection Errors

[Eben Eliason]

On Wed, Feb 17, 2010 at 2:27 PM, Daniel Castelo
 wrote:
> Hi, today we don't show all the 3G connection errors. The unique error that
> we show is the "Authentication Error" when the Pin/Puk Sim configuration is
> wrong. In this case we show the error in the connection pallete. When users
> clicks over the message, the pallete returns to normal behavior. We want to
> display all the connection errors. How is the best way to show this?

I'd recommend showing one or more buttons for dismissing the error and
taking any other relevant actions within the palette. Clicking on the
text label likely won't be very discoverable.  For instance, this
error might have two normal buttons for "Cancel" and "Show Settings"
(assuming something in settings can be adjusted to improve the
situation; I don't know enough about what this error means).

Eben


>
>
>
>
>
> --
> Ing. Daniel Castelo
> Plan Ceibal - Área Técnica
> Avda. Italia 6201
> Montevideo - Uruguay.
> Tel.: 601.57.73 Interno 2228
> E-mail : dcast...@plan.ceibal.edu.uy
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] 0.88 Meeting --- 20. Feb 2010 (15:30 UTC)

[Eben Eliason]

I,too, will be unavailable. I'm out of town for the weekend so don't
try to schedule around me, but I look forward to reviewing the meeting
notes and/or summary of findings.

Eben


On Fri, Feb 19, 2010 at 10:12 AM, Christian Marc Schmidt
 wrote:
> Hi Simon--unfortunately I won't be able to make it this Saturday, but I
> really would like to hear the outcome of the tests. Could we move the
> meeting to later that day, say around 2pm EST?
>
> Christian
>
>
> On Thu, Feb 18, 2010 at 3:12 AM, Simon Schampijer 
> wrote:
>>
>> Sorry, of course the meeting is the 20th of February.
>>
>> Regards,
>>   Simon
>>
>> On 02/18/2010 09:11 AM, Simon Schampijer wrote:
>>>
>>> Hi,
>>>
>>> this Saturday we will have our bi-weekly design meeting. We will chat
>>> about the outcome of the testing of the "Start new" vs "Resume" behavior.
>>>
>>> As a second item I would like to discuss the questions raised regarding
>>> the 3G Feature by Daniel [1]. Daniel, if you have time on Saturday, it
>>> would be great if you could attend.
>>>
>>> Thanks,
>>> Simon
>>>
>>> Channel: #sugar-meeting (irc.frenode)
>>> Time: 15:30 UTC
>>>
>>> [1]
>>> http://lists.sugarlabs.org/archive/sugar-devel/2010-February/022541.html
>>
>
>
>
> --
> anyth...@christianmarcschmidt.com
> 917/ 575 0013
>
> http://www.christianmarcschmidt.com
> http://www.linkedin.com/in/christianmarcschmidt
> http://twitter.com/cms_
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Feature] [DESIGN] Enhanced Color Selector

[Eben Eliason]

On Wed, Feb 3, 2010 at 5:06 PM, Simon Schampijer  wrote:
> Thanks Tim for your feedback,
>
> On 02/02/2010 11:54 PM, Tim McNamara wrote:
>> On 2 February 2010 22:45, Simon Schampijer  wrote:
>>
>>> In the design meeting and the ml-thread the '+' layout and the rows of
>>
>> XOs were favored. Eben brought as well the 'static rows with separated
>>> fill/stroke' on the table. Let's try to find an agreement.
>>>
>>>
>> The proposal looks great. May I suggest a revision to the string literals?
>>
>> Click to change stroke color: =>  Outline
>> Click to change fill color: =>  Body

These sound good to me.

>> Stroke/Fill are terms of art in vector drawing area. My guess is that the
>> terms outline and body (when looking at the XO figure) may be more natural.
>
> I guess this is right, stroke/fill are technical terms. Maybe
> Inline/Outline would work, too?
>
>> I feel we can omit "Click to change" or replace it with "Choose". I'm pretty
>> sure it'll be obvious by exploration that clicking on the little XOs changes
>> the big one.
>
> Choose sounds good to me, too.

We may not even need the instruction at all. I think just using
"Body:" and "Outline:" labels could suffice.

Good suggestions,
Eben

> Thanks,
>    Simon
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN][FEATURE] 3G modem support

[Eben Eliason]

On Wed, Jan 27, 2010 at 6:54 AM, Simon Schampijer  wrote:
> I had a chance to apply the latest code that is attached in #1622 and played
> a bit with a gsm-device. I think we discussed this already in some parts
> before but I am still not sure about the following:
>
> With my device attached I see the modem and hit 'connect' in the device
> palette. I get no feedback when that action was not successful and what went
> wrong. And I have no hint that I should set options in the Control Panel.
>
> I know we wanted to keep it simple but maybe someone has a smart idea how
> one could enhance the feedback and a hint to use the control panel to set

This sounds like a good time to revive the global notification idea.
The design intent there was to each corner of the screen with one edge
of the Frame (lower-right would be devices), and to have notification
icons (the device icon itself, usually) slide in and out of the
corners to grab attention in various cases, such as a failed
connection attempt.

We also had thoughts about adjusting the contents of the palette in
these cases, to contain the error message, and also provide options to
resolve the issue. For instance, the GSM device might indicate a
failed connection and offer "try again" and "change settings" options.

I think nailing this in a way that's useful system-wide and in all
edges of the Frame will take a bit of thought, but this is a good
opportunity to discuss it.

> the options? Didn't Eben suggested once to add an option to be able to
> launch the CP from within the device?

Yeah, I think hot-linking directly to the CP module for variouos
devices would be a logical addition.

Eben

> Thanks,
>   Simon
>
> PS: did we settle on the icon?
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN][FEATURE] 3G modem support

[Eben Eliason]

Here is a mockup of the panel with a proposed icon and a few visual
tweaks, as promised. Sorry it took a week to find the time. I'm happy
to export any of the icons shown as needed, once a design is agreed
upon.

Eben


On Sat, Jan 16, 2010 at 3:07 PM, Eben Eliason  wrote:
> On Sat, Jan 16, 2010 at 2:47 PM, Simon Schampijer  wrote:
>> On 01/15/2010 02:36 PM, Daniel Castelo wrote:
>>> On Fri, Jan 15, 2010 at 5:48 AM, Simon Schampijerwrote:
>>>
>>>> On 12/11/2009 08:36 PM, mabe...@paraguayeduca.org wrote:
>>>>> It has been discussed before and i have been working on it with Daniel
>>>>> Castelo from Uruguay.
>>>>>
>>>>> This is the link of the formal proposal, I will be updating it soon.
>>>>>
>>>>> http://wiki.sugarlabs.org/go/Features/3G_Support
>>>>
>>>> Hi Martin&  Daniel,
>>>>
>>>> thanks for proposing and working on this Feature!
>>>>
>>>> Your Feature has been accepted for the 0.88 release cycle. It has a
>>>> clear value for many Sugar users and the need has been expressed from
>>>> people from the field. It is, what I am especially happy about,
>>>> implemented by locals! From a technical point of view the changes are
>>>> not too invasive.
>>>>
>>>> * Design (from the Feature Page)*
>>>> An icon will be added to the frame when a modem is connected, and the
>>>> user will be able to connect and disconnect from there. Also, a section
>>>> will be added to the control panel that will allow entering the details
>>>> needed by the connection.
>>>>
>>>> We will have a design meeting this weekend [1]. Do you have any
>>>> particular questions regarding the UI for your Feature? Do you have an
>>>> icon for the frame device and the control panel already?
>>>>
>>>
>>>
>>> Great!! No, we don't have any icon.
>>>
>>>
>>>> Concerning the 0.88 release: The most important date is the Feature
>>>> Freeze Feb 01. The Feature must have been reviewed by the module
>>>> maintainer (in your case Tomeu for Sugar) and pushed to the repository.
>>>> I know that you are in contact with Tomeu already and patches are in
>>>> review. Furthermore please keep your Feature page up to date (testing
>>>> plan, release notes).
>>>>
>>>
>>> Ok. Thanks.
>>
>> Thanks, for working on the page.
>>
>> Here is the feedback from the design meeting:
>>
>> the UI design looks good, a few minor suggestions:
>>
>> ===Device Icon===
>> - the disconnect option in the device icon palette should use an icon
>> just like other network devices.
>> - the connection time should be shown in the primary palette, eg.
>> "connected for 02:22" instead
>> -  data sent: make that: [UP] 23kb     [DOWN] 31 kb
>
> I'll include a mockup of this palette along with the icon. My thought
> was that [UP] and [DOWN] above would actually be icons.
> Eben
>
>
>> ===Control Panel===
>> - left align the options
>>
>> ===Icon===
>> Eben will follow up with an icon.
>>
>>
>> Regards,
>>    Simon
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
<>___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Control Panel Font configuration

[Eben Eliason]

On Wed, Jan 20, 2010 at 3:28 PM, Daniel Drake  wrote:
> 2010/1/19 Yevlempy(Harsh Verma) :
>> Hi
>>
>> I am working on building the font configuring control panel, it will be a
>> pygtk based control panel extension for
>> handling the fonts. I have been working on few mockups for designing the
>> font configuring control panel. There
>> are three different kind of rough mockups i am giving here, with there own
>> features and would like your advice
>> and feedback on which to work upon.
>
> Is there a reason you haven't taken the 2-button approach proposed in
> the Feature page?
> http://wiki.sugarlabs.org/go/Features/Font_configuration
>
> The font size does not need to be presented to the user.

I agree that the actual font size isn't important. However, I think
the slider is a nicer presentation of the possible range. Perhaps the
slider just has "small" and "large" labels at the ends, and a
"default" label fixed somewhere in the middle. Coupling that with a
real-time resizing label would provide great feedback.

Eben


> Daniel
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Keep confusion, again

[Eben Eliason]

On Sat, Jan 16, 2010 at 6:05 AM, Sascha Silbe
 wrote:
> On Sat, Jan 16, 2010 at 11:28:50AM +0100, Sascha Silbe wrote:
>
> [Keep, Keep a copy, Keep a version]
>
> I avoided the activity_id issues in my first mail to not complicate the
> discussion even more.
>
> For "Keep a copy" (current Keep) it's quite clear to me that we should
> remove activity_id from metadata as we're creating a new object_id as well.
> Do the same for sharing related metadata (buddies, etc.).
>
> For "Keep a version" as implemented in the way I suggested (i.e. as a
> garbage collection hint) it's equally clear we shouldn't touch anything.
>
> CU Sascha

Yeah, the above details and also your previous message are dead on.

Another thought that came up in the design meeting yesterday was to
remove the primary action from the keep button, instead making a
single click open the full palette, thus exposing the possible options
(among them, "keep a copy", potentially "keep as ", and
later on "keep a version") to help clarify the behaviors.

Eben



> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQEcBAEBAgAGBQJLUZ13AAoJELpz82VMF3DaSyoIAJeObCOLxttYKTAvArlnd7yJ
> ZPJS4ssuVOBzm/yF9Pttu3B/GUtUexn56i26SgFEyyDchFgAfsle1d212IO/Xp+l
> IswSBrW7vRDzG5LUoxqHPaXOJ1ahsSxP00jdQysoNP2RHE/wq5RdIlJtBUfPIYeq
> 9EoAsfcdkBo+lIseR1Ohv1Qbp7l3YtWtwMc9PIvgVA7l8XBmgyCPCleCoB+LGzBQ
> wQLjnL35NjUve+tgAB+8ainfTitJNXKcQY2BKLuiBSnwJF+u4YVSRKKGvGYnhwUl
> VKoVjgeJjJmFwAchX++og7gQkev5eZDIdmvSV6zVxKlMRMmcN9dcrYEwYlCFHio=
> =C4qI
> -END PGP SIGNATURE-
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN][FEATURE] 3G modem support

[Eben Eliason]

On Sat, Jan 16, 2010 at 2:47 PM, Simon Schampijer  wrote:
> On 01/15/2010 02:36 PM, Daniel Castelo wrote:
>> On Fri, Jan 15, 2010 at 5:48 AM, Simon Schampijerwrote:
>>
>>> On 12/11/2009 08:36 PM, mabe...@paraguayeduca.org wrote:
 It has been discussed before and i have been working on it with Daniel
 Castelo from Uruguay.

 This is the link of the formal proposal, I will be updating it soon.

 http://wiki.sugarlabs.org/go/Features/3G_Support
>>>
>>> Hi Martin&  Daniel,
>>>
>>> thanks for proposing and working on this Feature!
>>>
>>> Your Feature has been accepted for the 0.88 release cycle. It has a
>>> clear value for many Sugar users and the need has been expressed from
>>> people from the field. It is, what I am especially happy about,
>>> implemented by locals! From a technical point of view the changes are
>>> not too invasive.
>>>
>>> * Design (from the Feature Page)*
>>> An icon will be added to the frame when a modem is connected, and the
>>> user will be able to connect and disconnect from there. Also, a section
>>> will be added to the control panel that will allow entering the details
>>> needed by the connection.
>>>
>>> We will have a design meeting this weekend [1]. Do you have any
>>> particular questions regarding the UI for your Feature? Do you have an
>>> icon for the frame device and the control panel already?
>>>
>>
>>
>> Great!! No, we don't have any icon.
>>
>>
>>> Concerning the 0.88 release: The most important date is the Feature
>>> Freeze Feb 01. The Feature must have been reviewed by the module
>>> maintainer (in your case Tomeu for Sugar) and pushed to the repository.
>>> I know that you are in contact with Tomeu already and patches are in
>>> review. Furthermore please keep your Feature page up to date (testing
>>> plan, release notes).
>>>
>>
>> Ok. Thanks.
>
> Thanks, for working on the page.
>
> Here is the feedback from the design meeting:
>
> the UI design looks good, a few minor suggestions:
>
> ===Device Icon===
> - the disconnect option in the device icon palette should use an icon
> just like other network devices.
> - the connection time should be shown in the primary palette, eg.
> "connected for 02:22" instead
> -  data sent: make that: [UP] 23kb     [DOWN] 31 kb

I'll include a mockup of this palette along with the icon. My thought
was that [UP] and [DOWN] above would actually be icons.
Eben


> ===Control Panel===
> - left align the options
>
> ===Icon===
> Eben will follow up with an icon.
>
>
> Regards,
>    Simon
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] 'Resume' vs 'Start a new' Activity

[Eben Eliason]

On Wed, Jan 13, 2010 at 8:32 AM, Walter Bender  wrote:
> On Wed, Jan 13, 2010 at 8:15 AM, Gary C Martin  wrote:
>> On 11 Jan 2010, at 20:44, Walter Bender wrote:
>>
>>> On Mon, Jan 11, 2010 at 3:32 PM, Simon Schampijer  
>>> wrote:
 On 01/11/2010 06:12 PM, Wade Brainerd wrote:
> My feeling regarding all this is that the problem is deeper than
> finding a way to Resume Latest or Start New from the home screen.
>
> IMO, the whole idea of Resume Latest is broken and needs to be
> ditched.  The Journal is the place to resume activities.  We need to
> make the Journal more discoverable and usable instead of trying to
> mash its features into the home screen.

 My findings are as well that the Journal is the natural place to resume
 an activity. The home view is the natural way to create a new activity,
 since it contains a graphical representation with the available activities.

 I think resuming is a secondary option we can provide, but should not be
 the default option when you click on the icon. To overcome the issue of
 constantly creating new activities I liked the 'open the full palette on
 left click' option. The learner is then provided with options to choose
 from.
>>>
>>> I like this too. It is worth mentioning that on non-OLPC-XO hardware,
>>> there is no easily discovered (or typed) dedicated key or mouse
>>> movement to get you to the Journal--one of the reasons we have also
>>> discussed having the Journal icon always available in the Home View (I
>>> am in favor of always at the bottom of the circle). All of these
>>> changes collectively may help.
>>
>> I've been trying to stay out of this discussion so far, watching for what 
>> might stick. So summing up so far:
>>
>> - Always show Journal in the home ring, though I'd favour having it as the 
>> first item, so that would make it always at the top of the circle ;-)
>>
>> - Home view reverted back to the 'start new' activity focus, all icons are 
>> un-coloured.
>>
>> - Single left click always reveals the palette with the 'start new' item at 
>> the top and 'resume' items below. Some minus design points here as 'start 
>> new' and 'resume' will both become 2 clicks away, and take extra palette 
>> cursoring dexterity to reach. You could argue both 'start new' and 'resume' 
>> will drop to second level features with 'activity palette information' 
>> becoming the top level home feature. Being able to read (some of) this 
>> palette text would also now be required, so our 'low floor' just got a 
>> little higher :-( I do agree though that this provides a compromise between 
>> reducing Journal spam and preventing the unintentional overwrite of existing 
>> Journal work by making the choice explicit.
>
>
> I am with you until here. I think we need to be very careful with the
> introduction of such additional complexity in the UI. Even for older
> kids, those using the OLPC-XO-1 laptops that have the old jumpy
> touchpad will have a hard time with this.
>
> I would urge the design team to explore a few more ways to solve this
> problem spatially rather than temporally.

One potential design I kind of liked (though I do recall others did
not, for various reasons) was to represent only new activities in the
ring, retaining the one-click instantiation and the palette as it
exists, and add a new yet separate feature to the view. This would
place the Journal icon persistently at (say) the bottom left corner of
Home, and then to the right of it, separated by a thin rule, a row of
the (say) 10 most recent activity instances. This line could contain
multiple instances of the same activity (eg. 3 different Write
instances), and would maintain their temporal relationship as they
"march" across the screen and "into" the persistent Journal icon. This
makes the Journal persistent, and logically separates the notion of
creating something from scratch and resuming a previous activity.

This is one of a number of potential alternatives, I think. I do also
share the sentiment that the Journal is the logical place to emphasize
for resuming, and that perhaps the first order of business is to make
sure that it's as accessible as possible. If every lesson begins with
"go to the Journal and resume the story we were working on yesterday"
or "go to the home view to create a brand new drawing" (and the UI
affordances make these equally easy to accomplish) we might not need
to conflate home view with both possibilities.

Eben



> regards.
>
> -walter
>
>> Regards,
>> --Gary
>>
>>
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] [DESIGN] Frame Panels

[Eben Eliason]

On Sun, Dec 13, 2009 at 12:42 AM, Aleksey Lim  wrote:
> Hi all,
>
> At the end Journal Plugins mutated to Frame Panles feature.
> All UI visible changes I wanted to implement in plugins could be done
> via Frame Panle components(the rest of code are shell agnostic).
>
> Frame Panles feature has the same major idea, social context - giving
> non core developers more freedom in case of releasing/supporting theirs
> code, e.g. adding GSM modem support could be implemented not in
> core(thus stuck to sugar version, when previous sugar version users
> can't grab last changes of GSM modem component) but as a standalone
> activity(and deployed as a regular activity).

Is this an extension of the "device" concept already present? The idea
there was to allow anyone to create devices (in the bottom edge of the
frame) that added extended features (such as text-to-speech,
additional hardware support, dictionaries, etc.). Having a way to
separate these from the core of Sugar, and even add or remove them at
will, would be nice.

> == Summary ==
>
> Treat frame as a containers(upper, left, right and bottom) for
> predefined or custom components i.e. having GNOME panels analog in
> sugar.

I'm a bit confused by this. The panels, clockwise from top, are for
activities, people, devices, and objects (clipboard). Only the bottom
edge is currently thought of as a place for extension. Are you
proposing that all of these would be extensible?

> == Detailed Description ==
>
> The major reason is to let activities like FileShare or Chat special UI
> representation in shell's interface. It could be also useful if user
> wants fast access to some activities like Journal replacements.

I would raise some caution here. The Frame was specifically designed
as a place for "active" elements to live, and is specifically not a
"launcher." As such, any running activities, current friends,
available devices, etc. appear there. Your description of "fast
access" makes it sound more like a launcher and less like a place of
status.

> Any of four panels could be stuck i.e. let user see its components all
> time.

This is an interesting idea. We played with similar concepts early on,
but decided at the time that the Frame as more comprehensible as a
single unit that could be shown and hidden at will. If we break that
paradigm, how do we handle the overlap that a persistent frame edge
would cause? Does the activity window move/shrink in these instances?

> === Predefined components ===
>
> * rings switch
> * activities list

These are views within the Home zoom level. What's your proposal for
making these Frame components?

> * clipboard
> * users list

Yup, these are the left and right edges, currently.

> * sources list
> * network component

Are these equivalent to the devices (bottom) edge of the frame? Are
you proposing we split them somehow?

> * notification area

I'd much rather see a general notification system built up (we have
the beginnings of one already). There are a number of design mockups
showing how notifications are "bound" to the 4 corners of the screen,
associated with the 4 edges for activities, people, devices, and
objects. notifications would include activity invitations, group
invitations, people joining/leaving activities, low battery, lost
network, etc.

I think these various notifications belong in the context of the
respective edges of the frame, instead of in a single area.


Overall, there are 7 components you've identified here, so it's
unclear to me how these map onto the 4 edges of the Frame.

> == Benefit to Sugar ==
>
> * let users more freedom to organize sugar shell how they want
> * provide to activity developers a way to integrate theirs activities
> * to shell UI(useful for activities that work in background and
> * requires some kind all-time-present indicator in UI)
> * having stable API for panel components, activity developers have more
> * freedom and aren't stuck to core releases e.g. Network
> * activity/component(analog of NM widget in GNOME) could support
> * several sugar releases and previous release sugar users will benefit
> * from last Network component.
> * previous sugar release users will benefit from last updates of
> * predefined components as well
>
> == UI Design ==
>
> * all of four frame panels could be stuck
> * manage components, way to add-new/remove/move components

This part definitely sounds like a good idea, to me.

> * components could have shell level key shortcuts

This also sounds good, but we'll have to be quite careful about it to
avoid breaking activities.

Eben


> == User Experience ==
>
> * sugar frame as a regular GNOME panels
>
> --
> Aleksey
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Feature] activity.info enhancements

[Eben Eliason]

On Fri, Dec 11, 2009 at 2:26 PM, Tomeu Vizoso  wrote:
> On Fri, Dec 11, 2009 at 17:18, Sayamindu Dasgupta  wrote:
>> On Fri, Dec 11, 2009 at 11:13 PM, Walter Bender  
>> wrote:
>>> Summary: It would facilitate the packaging of Sugar activities into
>>> RPMs and DEBs if there were additional information available in the
>>> activity.info file.
>>>
>>> Details: In walking the process of creating an RPM of one of my
>>> activities with Sebastian Dziallas, who is doing lots of packaging for
>>> Fedora and SoaS, we observed that many fields in packages' .spec files
>>> could readily be pulled from the activity.info file. A few additional
>>> fields would be necessary, such as the following:
>>>
>>>    * a short summary
>>>    * an URL to the source package
>>>    * an URL to the activity home page
>>>    * the required dependencies to run
>>>
>>> None of these additional fields are particularly onerous for an
>>> activity developer to provide and it would enable the creation of a
>>> script (as part of setup.py/bundlebuilder.py) to do most of the work
>>> in creating the .spec file. (I assume .deb has similar requirements to
>>> .rpm). Things are more complex for activities that include binaries
>>> and the like, but for the most part, we should be able to greatly
>>> facilitate upstream maintenance of our code while asking little more
>>> of Sugar developers. None of these additional fields need be required,
>>> but their inclusion would make things easier. (This is not a new idea,
>>> but one that seems timely given all the upstream interest in Sugar
>>> these days.)
>>>
>>
>> It may be interesting to factor in localization (eg: translation of
>> the description, etc) into this discussion. We already translate parts
>> of activity.info so it may be trivial to extend the mechanism.
>> However, it does increase the workload on translators a bit, and we
>> need to agree on which fields to translate (for example, if we have a
>> non-UI-visible field called category or tags, it may not make sense to
>> translate it).
>
> I was thinking of displaying these tags in the activity list (or it's
> already happening, not sure). Also, if we allow searching for those,
> we would need to do so with the ones in the local language.

I think displaying them in the list might just add visual noise, but
their primary intent is to allow searching, and as you point out, it's
critical to have good translations for that to work.

Eben


> Regards,
>
> Tomeu
>
>> It may also be worthwhile to keep some kind of compatibility with the
>> desktop-entry spec
>> http://standards.freedesktop.org/desktop-entry-spec/latest/, in case
>> we add support for standalone activities in the future.
>>
>> Thanks,
>> Sayamindu
>>
>>
>> --
>> Sayamindu Dasgupta
>> [http://sayamindu.randomink.org/ramblings]
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
>
> --
> «Sugar Labs is anyone who participates in improving and using Sugar.
> What Sugar Labs does is determined by the participants.» - David
> Farning
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Scrollbar width

[Eben Eliason]

On Fri, Dec 11, 2009 at 3:02 AM, Albert Cahalan  wrote:
> It's perfectly reasonable to have a scroll bar that isn't anywhere
> near the edge of the screen. (scrolling a list, etc.) We must not
> forget this when discussing things like "infinite target width".

Of course. My point here is simply that many activities have one large
scrolling content region (or, at least, one primary one); In cases
where the scrollbar is conceptually at the edge of the screen, we
should be sure that it is also technically at the edge of the screen.

In a sense this consideration is orthogonal to the issue of scrollbar
width, in that it should be ensured regardless since it has huge
usability benefits in many likely scenarios (though, as you point out,
certainly not all).

> That said, at least for the common case of the scrollbar being at
> the edge of the screen and possibly elsewhere, there is a solution.
> Scrollbars could widen up as the mouse goes over them, overlapping
> into/above the area that is to be scrolled.
>
> It's a nice solution, allowing for scrollbars 100 pixels wide.

This is an interesting thought, but it seems to me that it's actually
a solution proposed for the wrong circumstance. The scrollbars that
lie at the edge of the screen are the ones that needn't be large,
since grabbing them (assuming they are properly edge-aligned) is easy
regardless of their width.

It's those that float within the UI, such as a scrolling left column
(eg. Pippy examples) that are hardest to target, and which need
adequate affordances to make them usable. Increasing the target area
dynamically on hover is definitely a solution worth experimenting
with.

> Speed is critical of course. Being slow like the Frame would be
> some kind of torture. My best guess for appropriate timing:

I'm not even sure an animation would be critical to understanding this
model. One possibility might be to only increase the size of the
scroll handle (leaving the "bar" itself thin), when the cursor is
within range of it. It could grow from its center, so that it hovers
above yet centered on the bar it belongs to, perhaps settling on a
width 3x that of the bar.

Eben

> a. movement begins in less than 30 ms
> b. movement is done in less than 200 ms (no exceptions ever)
>
> In that time there ought to be 6 to 12 frames drawn. Drop frames
> as required to meet the required performance.
>
> I'm thinking the speed ought to vary, like this:
>
> 0 ms, 8 pixels (begin state)
> 20 ms, 12 pixels
> 40 ms, 16 pixels
> 60 ms, 24 pixels
> 80 ms, 40 pixels
> 100 ms, 72 pixels
> 120 ms, 88 pixels
> 140 ms, 96 pixels
> 160 ms, 100 pixels (end state)
>
> Motion blur would help. (precomputed I suppose)
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Scrollbar width

[Eben Eliason]

On Thu, Dec 10, 2009 at 12:30 PM, Sean DALY  wrote:
> FWIW, I have seen lots of kids ages 6-8 who know what a scrollbar is,
> but have a hard time mousing it up and down when using SoaS, even on a
> larger screen such as the Dell Latitude 2100 education netbook.

This, incidentally, is precisely the reason the grab key was designed.
Scrolling in this manner requires continuous pressure on the mouse
button, while simultaneously moving the finger across the trackpad,
which can be difficult, especially on smaller laptops, and for
smaller/younger fingers with less developed motor skills.

The grab button (there, quite crucially, are two of these on the XO:
one on each side of the spacebar) was designed to allow children to
use their non-dominant hand to press the button while using their
other hand on the trackpad to manipulate the view. This design was
meant both to eliminate the need to "target" the scrollbar in the
first place (since this would work anywhere within the scrolling
region, just like 2-fingered scrolling), and to make it easier for
children to do since drag'n'drop can be tricky.

Eben


> Sean
>
>
> On Thu, Dec 10, 2009 at 6:13 PM, Gary C Martin  wrote:
>> On 10 Dec 2009, at 14:58, Eben Eliason wrote:
>>
>>> On Thu, Dec 10, 2009 at 7:54 AM, Paul Fox  wrote:
>>>> benjamin wrote:
>>>>  > Hello,
>>>>  >
>>>>  > On Wed, 2009-12-09 at 22:43 -0500, Art Hunkins wrote:
>>>>  > > I've now got whole-screen scrollbars working well in my music 
>>>> activities,
>>>>  > > but I'd like to make the bars wider. The automatic settings (as used 
>>>> in most
>>>>  > > activities) are too narrow for my taste.
>>>>  >
>>>>  > First of all I would like to say: Please do not play with themes, just
>>>>  > because you don't like something that much ... (especially should you
>>>>  > dislike them in general and not only in your activity)
>>>>  >
>>>>  > Other than that. IIRC the reason for the scrollbars to be that narrow
>>>>  > was the plan to use the Grab-Key+Touchpad for scrolling. This means that
>>>>  > the main purpose of the scorllbar is to show the position, but not to
>>>>  > use the handle itself for scrolling.
>>>>
>>>> and just in case it's not clear from the above -- the grab-key+touchpad
>>>> feature is present in XO-1.5 releases, and available for the XO-1 if the
>>>> olpc-kbdshim package is installed.
>>>
>>> I was a proponent for grab scrolling in the early days of Sugar at
>>> OLPC. However, it seems clear now that, without customized hardware
>>> (which was the assumption back then) this solution simply isn't viable
>>> as an intuitive and discoverable way to navigate content. I think that
>>> retaining the functionality via some other mapping or shortcut would
>>> be nice (especially to offer the functionality as designed on the XO
>>> hardware itself), but I don't see reason not to improve the usability
>>> of Sugar on all platforms by increasing the scrollbars to a more
>>> manageable width.
>>
>> I'd argue the narrow scrollbar width is still a relevant design choice, 
>> being there to indicate document length and current view location into it. 
>> Most non-XO hardware platforms are very likely to have their own hardware 
>> support for a scroll wheel type behaviour. I very rarely need to drag a 
>> scrollbar these days, it's all two fingered scrolling which works fine in 
>> Sugar on a VM (though we could do with a control panel to adjust 
>> sensitivity).
>>
>> Regards,
>> --Gary
>>
>>> Of course, in addition to this we should make sure that wherever
>>> possible the scrollbars are given every last pixel up to the edge of
>>> the screen, so that they become, effectively infinite in width (or
>>> height, when horizontal), thus making them difficult to miss.
>>>
>>> Eben
>>>
>>>
>>>> paul
>>>> =-
>>>>  paul fox, p...@laptop.org
>>>> ___
>>>> Sugar-devel mailing list
>>>> Sugar-devel@lists.sugarlabs.org
>>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>>
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Scrollbar width

[Eben Eliason]

On Thu, Dec 10, 2009 at 7:54 AM, Paul Fox  wrote:
> benjamin wrote:
>  > Hello,
>  >
>  > On Wed, 2009-12-09 at 22:43 -0500, Art Hunkins wrote:
>  > > I've now got whole-screen scrollbars working well in my music activities,
>  > > but I'd like to make the bars wider. The automatic settings (as used in 
> most
>  > > activities) are too narrow for my taste.
>  >
>  > First of all I would like to say: Please do not play with themes, just
>  > because you don't like something that much ... (especially should you
>  > dislike them in general and not only in your activity)
>  >
>  > Other than that. IIRC the reason for the scrollbars to be that narrow
>  > was the plan to use the Grab-Key+Touchpad for scrolling. This means that
>  > the main purpose of the scorllbar is to show the position, but not to
>  > use the handle itself for scrolling.
>
> and just in case it's not clear from the above -- the grab-key+touchpad
> feature is present in XO-1.5 releases, and available for the XO-1 if the
> olpc-kbdshim package is installed.

I was a proponent for grab scrolling in the early days of Sugar at
OLPC. However, it seems clear now that, without customized hardware
(which was the assumption back then) this solution simply isn't viable
as an intuitive and discoverable way to navigate content. I think that
retaining the functionality via some other mapping or shortcut would
be nice (especially to offer the functionality as designed on the XO
hardware itself), but I don't see reason not to improve the usability
of Sugar on all platforms by increasing the scrollbars to a more
manageable width.

Of course, in addition to this we should make sure that wherever
possible the scrollbars are given every last pixel up to the edge of
the screen, so that they become, effectively infinite in width (or
height, when horizontal), thus making them difficult to miss.

Eben


> paul
> =-
>  paul fox, p...@laptop.org
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] seeking feedback on sketch of a new color selector

[Eben Eliason]

On Mon, Dec 7, 2009 at 12:52 PM, Walter Bender  wrote:
> On Mon, Dec 7, 2009 at 12:39 PM, Gary C Martin  wrote:
>> Hi Walter/Simon,
>>
>> On 7 Dec 2009, at 10:37, Simon Schampijer wrote:
>>
>>> On 12/06/2009 11:05 PM, Walter Bender wrote:
 On Sun, Dec 6, 2009 at 8:54 PM, Simon Schampijer  
 wrote:
> A few questions:
> - in the Feature page you mention the 'random selector', is this option
> still available in the latest design?

 This is still in the new design in that I didn't remove it from the
 code. (If you click on the central XO icon, you get a random color as
 before.) It is a decision I leave to the design team.
>>>
>>> Ok. Maybe the design team want to comment if they think that the random
>>> functionality is a good one to have.
>>
>> Sorry, not quite following the 'random functionality' comment. Just to 
>> check, my understanding that 'forwards' and 'backwards' are hooked up to 
>> change a seed value used for a random calculation of the fill/stroke colour 
>> choices (an almost infinitely large carousel of random choices, left or 
>> right). Where the buttons act something like the below image to maintain the 
>> current behaviour where clicking the large Xo icon still progresses forward:
>>
>>
>>
>>
>> Regards,
>> --Gary
>>
>
> Just to bring clarity to what I have implemented so far:
>
> (1) clicking on the left xo icon or the < icon causes the color pair
> to cycle to the "previous" color pair in the list of colors found in
> xocolor.py
> (2) clicking on the right xo icon or the > icon causes the color pair
> to cycle to the "next" color pair in the list of colors found in
> xocolor.py
> (3) clicking on the large xo icon causes a random color pair to be
> selected from the list in xocolor.py and resets the index used in #1
> and #2. (Essentially the same as the present behavior).
>
> There is also a "hidden" button (a temporary kludge) to undo (useful
> for undoing the random selection). The intention is to associate a key
> (Ctrl-z) to the undo function.
>
> Of course, you can still back out of the whole thing by canceling the
> changes in the manner currently supported: hitting x instead of ✓ on
> the panel.

Yeah, I wouldn't place too much home in an undo shortcut being
discovered, but you're right about the ability to cancel in the
settings panel. The same is not true, of course, on first start.

> Comments on the above:
>
> (a) The order of the colors in xocolor.py is reason to cycle through.
> If you get a close approximation from random, you can fine-tune your
> selection by searching through adjacent colors.

Perhaps if we remove the random function, we could support
press-and-hold to cycle more quickly through the color space. I do see
the arguments for retaining random, of course, so maybe the
implementation you have is the right one.

> (b) I don't know how to get icons that can both be recolored and use
> accelerator keys, hence the kludge above. For accessibility purposes,
> it would be nice to add short-cuts to all the buttons in the control
> panel.
> (c) Gary, I tried the stacked icons vs running them in a row. The
> stacked icons didn't do it for me (or Eben, as I recall). The current
> configuration is xo < XO > xo.

Yeah, I think my preference was for:

(< xo) XO (xo >)

with the (< xo) units reacting as one big button. That is, you could
click on either the XO or the arrow. I believe this is how it
functions now, apart from the order of the xos and arrows being
reversed. Another possibility would be to make that more explicit by
using text/icon buttons, instead of just icons, like:

( xo Back ) XO ( xo Next)

In other words, the buttons would be the usual pill-shaped gray
buttons, with a colored XO for an icon and the word "next" or "back."
That would help reduce confusion about which XO is "My XO."

Eben


>
> -walter
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] seeking feedback on sketch of a new color selector

[Eben Eliason]

On Mon, Dec 7, 2009 at 12:39 PM, Gary C Martin  wrote:
> Hi Walter/Simon,
>
> On 7 Dec 2009, at 10:37, Simon Schampijer wrote:
>
>> On 12/06/2009 11:05 PM, Walter Bender wrote:
>>> On Sun, Dec 6, 2009 at 8:54 PM, Simon Schampijer  
>>> wrote:
 A few questions:
 - in the Feature page you mention the 'random selector', is this option
 still available in the latest design?
>>>
>>> This is still in the new design in that I didn't remove it from the
>>> code. (If you click on the central XO icon, you get a random color as
>>> before.) It is a decision I leave to the design team.
>>
>> Ok. Maybe the design team want to comment if they think that the random
>> functionality is a good one to have.
>
> Sorry, not quite following the 'random functionality' comment. Just to check, 
> my understanding that 'forwards' and 'backwards' are hooked up to change a 
> seed value used for a random calculation of the fill/stroke colour choices 
> (an almost infinitely large carousel of random choices, left or right). Where 
> the buttons act something like the below image to maintain the current 
> behaviour where clicking the large Xo icon still progresses forward:

That's my understanding as well. I think that keeping it simple, with
only next and previous controls, is probably the right way to go.
Allowing a click to generate a new random color is essentially
duplicate functionality, and without an obvious undo which is the
hallmark of the new design in the first place.

If we really want to retain functionality when clicking on the large
XO (for familiarity to those who used the old design), we could treat
it the same as a click on the next button.

Eben


>
>
>
>
> Regards,
> --Gary
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] adding 3G devices support to sugar

[Eben Eliason]

On Thu, Dec 3, 2009 at 1:44 PM, Martin Abente  wrote:
> Today i finished the systray device icon. (but i still need the icon
> graphic... any artist around?)

I'd be happy to sketch some icons. Do you have any suggestions or
examples of what an appropriate icon might be for a 3G modem?

As far as I know, they come in all shapes and sizes—including, of
course, cell phones—and I'm not sure there is an accepted or easily
recognizable form for an icon.

Eben


>
> So, now we have
>
> 1. Store settings with gconf
> 2. Configuring settings at control panel (thanks to Daniel Castelo)
> 3. Systray device icon fully working
> 4. Gsm connections management
>
> I still need to clean stuff on 1,3,4
>
> Saludos,
>
> On Wed, 2 Dec 2009 10:43:51 -0200, Daniel Castelo
>  wrote:
>> In Uruguay we need "USB_SERIAL_OPTION" for 3G Modems.
>> Martin, I could test your work using 3G Modems.
>> I could help programming the control panel and the device icon too.
>>
>>
>> On Wed, Dec 2, 2009 at 10:31 AM, Martin Langhoff
>> wrote:
>>
>>> On Wed, Dec 2, 2009 at 3:04 AM, Martin Abente
> 
>>> wrote:
>>> > I have successfully extended jarabe/model/network.py, so we can
>>> > load-in a gsm connection, tested it with my app (gsmbridge) and it
>>> > works, tomorow ill clean up the code, add the control panel and the
>>> > device icon part.
>>>
>>> Cool. Can you give us a list of kernel modules that will work with
>>> this, so we can look at building them for the XO1/1.5 kernels? They'll
>>> probably be split off in a separate rpm, but easily installable.
>>>
>>> cheers,
>>>
>>>
>>> m
>>> --
>>>  martin.langh...@gmail.com
>>>  mar...@laptop.org -- School Server Architect
>>>  - ask interesting questions
>>>  - don't get distracted with shiny stuff  - working code first
>>>  - http://wiki.laptop.org/go/User:Martinlanghoff
>>>
>>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88

[Eben Eliason]

On Tue, Dec 1, 2009 at 5:54 AM, Martin Langhoff
 wrote:
> On Mon, Nov 30, 2009 at 9:40 PM, Wade Brainerd  wrote:
>> When deleting an object from the Journal that is an activity bundle,
>> we ought to display an alert with a scary icon.  The alert should
>> clearly state that Journal entries will no longer be able to be opened
>> until the activity is reinstalled.
>
> Majority of 6 year old will not understand that.

The best way to handle this, I think, is to let kids delete activities
but also keep a reference to the source in the form of an update URL
or similar, so that fetching the activity automatically when an
instance of it is resumed can be done. There's additional UI work
there, and we can't guarantee connectivity, etc., but it would help
reduce the overhead involved. (I'm not suggesting we shouldn't find
ways to make it clearer when a deletion is happening, either, but as
noted, the dialog may not work in practice with the target audience.)

>> Some of the other operations Aleksey mentioned, like upgrading
>> activities, ought to display similar alerts.
>
> Gentlemen, alerts do not work with young users. We have to just DTRT,
> or provide actions that are very clearly different (and even then...).

On a more general note, this discussion has many hints of the
action/object views that have been tossed around for some time now.
This specifically addressed the conflict between the desire to manage
all objects and the desire to have the Journal reflect only the
actions of the child.

In this split, the action view shows actions, which reference one or
more objects (activities, people, devices, etc.) This would contain
only references to things the children have done themselves. The
object view shows objects, which is a more traditional view of
everything that's around to be manipulated. Any preinstalled
activities would appear in the object view by default, and thus be
accessible by kids to copy, share, modify, etc. (and as they do, new
actions will be created to record that).

Ultimately, the object view would look much like the current Journal
view does, and the actions view would be a bit friendlier. One benefit
of this is that young kids need only look at the actions view, while
those that wanted more control could dig into the objects directly.

Eben



> cheers,
>
>
> m
> --
>  martin.langh...@gmail.com
>  mar...@laptop.org -- School Server Architect
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  - http://wiki.laptop.org/go/User:Martinlanghoff
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sharing in Terminal

[Eben Eliason]

On Sun, Nov 22, 2009 at 6:10 PM, Wade Brainerd  wrote:
> Hey Sayamindu,
>
> This sounds great to me!  It was on my TODO list when I added tabs,
> but I never got around to attempting it.  I too like the idea of
> shared tabs.
>
> The way I would do the UI is:
>
> When the Terminal activity is shared (either the Share toolbar button
> has been clicked, or the activity was launched in response to an
> invitation), an extra button appears in the Tabs toolbar: New Shared
> Tab
>
> Any user can click this button; tab that is created will be visible by
> all participants.  The shared tab's title bar will be prefixed with
> the owner's buddy name and could even display their buddy icon.

That sounds pretty good. It would actually be nice to have a Shared
Tab control that rendered the tab itself in XO colors, instead of just
putting the XO icon inside a generic tab.

Eben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] seeking feedback on sketch of a new color selector

[Eben Eliason]

Very nice! The ability to go backward is a huge improvement.

I have a few thoughts on the layout. I'd suggest putting the arrows on
the outside, with the smaller (presumably "cell size") XOs just to the
left and right of the large one. I'd also suggest making the arrow
buttons smaller, so they don't overpower the interface (right now they
actually appear larger than cell size; I think even showing them at
the size they appear in the Journal, or in menus, might suffice).

I'm glad to see that clicking the arrows or the small XOs works!

Eben


On Wed, Nov 11, 2009 at 4:39 PM, Gary C Martin  wrote:
> Hi Walter,
>
> On 11 Nov 2009, at 17:42, Walter Bender wrote:
>
>> I just posted another version (no undo) and I think more clarity as to
>> what is going on... You can click the < > buttons or the small XOs.
>
> Yes, fab, that's much clearer, even for a static view.
>
> Here's a quick mockup at keeping the large buddy icon central so it matches
> the usual zoom presentation of your buddy icon:
>
>
>
>
> Regards,
> --Gary
>
>> -walter
>>
>> On Wed, Nov 11, 2009 at 12:31 PM, Gary C Martin 
>> wrote:
>>>
>>> Hi Walter,
>>>
>>> On 11 Nov 2009, at 15:48, Walter Bender wrote:
>>>
 I made a patch to the color selector on the About Me panel to make it
 a little easier to navigate the color selections. Please see my screen
 cast at http://dailymotion.virgilio.it/video/xb42um_color-selector_tech.
>>>
>>> I needed to watch through a number of times before I could work out the
>>> logic for the colours of the two smaller buddy icons. First couple of
>>> times
>>> through I thought one was a swapped fill/stroke, and the other was a
>>> 'light'
>>> version, then third time through I decided they must all just be random,
>>> finally I twigged that it was a scrolling history moving from right to
>>> left
>>> (small <-- big <-- small).
>>>
>>> Quick thoughts:
>>>
>>> - What you have now would be visually understandable after a single click
>>> if
>>> you added a brief transition animation so that the icons scroll
>>> left/right
>>> and resize (like a carousel).
>>>
>>> - Not convinced you need the undo icon if you can add the transition
>>> animation, it feels slightly odd at the moment that the undo is right
>>> next
>>> to the yet too be seen new colour combination (perhaps it could go above
>>> or
>>> below the centre icon if it really needs to stay in the design).
>>>
>>> - The alternative is to have N small buddy icons around the central large
>>> icon, where the small icons are a close variation of the central large
>>> icon
>>> colours. Clicking the centre icon picks a completely new random base set
>>> of
>>> colours; clicking any small icon moves it to the centre large position,
>>> and
>>> generates a new set of small variants. The colour variants could just be
>>> +/-
>>> small random steps from the main base colours, or have some spacial
>>> meaning
>>> (left/right could be +/- fill colour, up/down could be +/- stroke
>>> colour).
>>>
>>> Regards,
>>> --Gary
>>>
>>>
>>
>>
>>
>> --
>> Walter Bender
>> Sugar Labs
>> http://www.sugarlabs.org
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] another attempt at a color selector

[Eben Eliason]

Very nice! The ability to go backward is a huge improvement.

I have a few thoughts on the layout. I'd suggest putting the arrows on
the outside, with the smaller (presumably "cell size") XOs just to the
left and right of the large one. I'd also suggest making the arrow
buttons smaller, so they don't overpower the interface (right now they
actually appear larger than cell size; I think even showing them at
the size they appear in the Journal, or in menus, might suffice).
Finally, I can't tell if this works now or not from the video, but I'd
suggest that clicking the arrow or the smaller XO icons should change
the selection.

Eben


On Wed, Nov 11, 2009 at 12:41 PM, Walter Bender  wrote:
> http://dailymotion.virgilio.it/video/xb44q3_color-selector-2_tech
>
> -walter
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] ribbon, right-click, button bars (was: RFC: Kill the delayed menus for good)

[Eben Eliason]

On Tue, Oct 20, 2009 at 4:08 PM, Albert Cahalan  wrote:
> Eben Eliason writes:
>
>> palettes, we aimed to reduce accidental invocation
>> of them without entirely eliminating discovery by increasing the
>> delay.
> ...
>> I'm more worried about immediately revealing of all secondary
>> actions, which pull attention from the more efficient manner in
>> which basic actions can be performed - namely, clicking on the
>> big icons.
>>
>> If we can do this in a manner which doesn't distract from the
>> primary interaction methods and encourage inefficient paths
>> through the UI, that would be great.
>
> I believe this was first solved by Kid Pix, a few decades ago.
> One button bar swaps out another button bar.
>
> Microsoft's ribbon looks like the same thing, though I've never
> used it so I can't say for sure.
>
> Tux Paint certainly uses this model. In that case, it works fine
> for kids **way** below sugar's target age. (smart 2-year-old or
> regular 4-year-old for sure, possibly younger)

Yeah. This is very similar to the now implemented redesign of the
toolbar system for activities, which feedback has indicated is a huge
improvement. However, it doesn't instantly solve the issue for freely
positioned UI elements, such as people and activities within the
various zoom levels. There may be a variation on the technique that
could work in these contexts, of course, and some interesting
possibilities have already been suggested.

>> Another possibility would be to educate children about right click
>> somehow.
>
> On the one hand, I think it's really important to do this. Besides
> the human-compatibility issue and the extra expressive power, I think
> using a second button will help to develop the mind a bit. (you're not
> just grabbing or poking when you click; you're performing an action
> that could be determined by which button you click)
>
> On the other hand, I think both buttons should be the left button
> by default. Kids have trouble hitting the correct button. Button
> mistakes should not be something kids face from the moment go.

Yup. The hardware design was done before a UI team was organized at
OLPC. One of the first suggestions, though it was already too late,
was to limit the hardware to one button.

Since we didn't have the opportunity to change that, we opted to
provide a more traditional right-click functionality both because it
did provide a way to offer more contextual actions in a manner
consistent with other interfaces that already exist, and because we
thought it could actually be perplexing to have two buttons that
always appeared to do the same thing. If that's proving problematic
for children in practice, we could make a change there. I hadn't heard
much on that particular issue, so I don't know how common (or
persistent) it is.

>> Perhaps, as suggested by Wade, we could allude to the availability
>> of more information immediately on hover, and perhaps even try making
>> the right button the only means of invoking the secondary actions.
>> This does work today, but the lack of discoverability is a definite
>> problem.
>
> It's no less discoverable than the left button. Right-click menus

True.

> need to work two ways though:
>
> a. Press and hold down right button, move, release
> b. Click (press and release) right button, move, click either button

Agreed. This would be a good improvement to the behavior.

Eben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Re: [Bugs] #1508 UNSP: confusing wording on download from Browse

[Eben Eliason]

Since the desire to stop the activity has already been conveyed by
clicking the Stop button, the real choice to be made is whether or not
the download should be cancelled. How about changing the wording to
convey this choice directly:

To stop the activity now now you must cancel your ongoing download.
[Cancel download] [Continue download]

Clicking [Cancel download] will cancel the download and stop the
activity (as was already requested by clicking Stop). I chose to keep
the word "cancel" in the "Cancel download" button because the term
"stop" is used in the UI as an action which can be resumed, which is
untrue of the download.

Clicking on [Continue download] will cause the alert to disappear, and
implicitly cancel the previously requested "stop" action on the
activity.


On Mon, Oct 19, 2009 at 9:54 AM, Walter Bender  wrote:
> In this particular case, we may want to say:
>
> Continue with download
>
> Stop download and stop browsing

This isn't bad either, though perhaps we could say the same in fewer
words: [Continue download] [Cancel and stop]

Eben


> -walter
>
> On Mon, Oct 19, 2009 at 9:09 AM, Wade Brainerd  wrote:
>> Yeah, Stop and Don't Stop sound best to me.  Cancel is almost never an
>> appropriate button; we should grep the codebase for it :)
>>
>> On Mon, Oct 19, 2009 at 8:35 AM, Tomeu Vizoso  wrote:
>>> On Mon, Oct 19, 2009 at 13:32, Gabriel Eirea  wrote:
 How about "Quit" and "Don't quit"?
>>>
>>> That would be better, though activities are stopped, rather than quitted.
>>>
>>> Thanks,
>>>
>>> Tomeu
>>>
 2009/10/19 Tomeu Vizoso :
> Any ideas for a better wording?
>
> Thanks,
>
> Tomeu
>
> On Sat, Oct 17, 2009 at 00:40, Sugar Labs Bugs
>  wrote:
>> #1508: confusing wording on download from Browse
>> --+-
>>    Reporter:  walter                     |          Owner:  erikos
>>        Type:  enhancement                |         Status:  new
>>    Priority:  Unspecified by Maintainer  |      Milestone:  Unspecified 
>> by Release Team
>>   Component:  Browse                     |        Version:  Git as of 
>> bugdate
>>    Severity:  Trivial                    |       Keywords:
>> Distribution:  Unspecified                |   Status_field:  Unconfirmed
>> --+-
>>  If you try to quit Browse in the middle of a download, you are told that
>>  quiting will "cancel" the download and you are presented with two 
>> buttons:
>>  cancel and stop. Hitting the stop button will cancel the download and
>>  hitting the cancel button will cancel the quitting, hence not cancel the
>>  download. I wonder if there are better words we can use to make this a 
>> bit
>>  less confusing.
>>
>> --
>> Ticket URL: 
>> Sugar Labs 
>> Sugar Labs bug tracking system
>> ___
>> Bugs mailing list
>> b...@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/bugs
>>
>
>
>
> --
> «Sugar Labs is anyone who participates in improving and using Sugar.
> What Sugar Labs does is determined by the participants.» - David
> Farning
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>

>>>
>>>
>>>
>>> --
>>> «Sugar Labs is anyone who participates in improving and using Sugar.
>>> What Sugar Labs does is determined by the participants.» - David
>>> Farning
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Design mockup of a different activity launcher

[Eben Eliason]

On Sat, Oct 17, 2009 at 8:10 PM, Wade Brainerd  wrote:
> Hi Eben, thanks for the feedback!
>
> On Sat, Oct 17, 2009 at 7:27 PM, Eben Eliason  wrote:
>> On Sat, Oct 17, 2009 at 4:53 PM, Wade Brainerd  wrote:
>>> http://www.youtube.com/watch?v=OvDdN1t-0yE
>>>
>>> I was in the code and have wanted to try this for awhile!  If anyone
>>> else thinks it would be better than the pulsing icon, I'll clean up
>>> and post the patch to a Feature on the wiki.
>>>
>>> Rationale:
>>> 1) Less flashy
>>
>> Perhaps, although the screen actually feels busier to me. Perhaps with
>> some visual tweaks it would work (smaller ring, maybe?), since showing
>> how long it will take to launch is useful feedback.
>
> I'm happy to make any tweaks to the layout, colors, sizes of the dots,
> spacing, etc.  If design can provide a mockup, that would be great!
> But if not, I'm happy to take suggestions and try to improve it.
>
>> I lament the loss of the pulsing icon, though. This approach doesn't
>> retain the transition from outline to fill that's important to the
>> activity paradigm. Could we retain that, or is that the "flashy" part
>> you aim to eliminate?
>
> I wanted to stop drawing something big every frame while the activity
> is trying to start; that's the supposed performance improvement.
>
> Blinking would be fine, or a brief fade in at the beginning.

Yup, I suppose both could work. The reason to blink, I suppose, is to
illustrate the intermediate state throughout the launching phase. We
use the same metaphor for connecting to networks, as well.

>>> 2) Clock theme represents time
>>
>> I don't understand how we know how long the launch is going to take.
>> Is that something that we can estimate to a reasonable degree? Or do
>> you plan to estimate the average launch time across many launches?
>
> No - the clock just displays one new dot per second.  So an activity
> which launches in 3 seconds shows 3 dots.

Oh, hmmm. That makes this a bit less useful, and even potentially
misleading. I don't think it's a good idea to show a determinate
progress indicator for something that takes an indeterminate length of
time. Even if we mapped the ring to the time we wait before a fail
launches, I think the visual would imply to the child that success,
rather than failure, was imminent, which could be frustrating.

> I could implement some estimation capacity, but that would mean the
> dots appear faster or slower.  I prefer to let the user see there is a
> different amount of work involved in starting each activity, instead
> of implying that the same amount of work is being done at a different
> rate.

Hmm, it seems like you're arguing against the progress bar, as we know
it. =)  I guess it's just the difference between an absolute and a
relative measure of progress, and the use of an absolute makes some
sense if we can't know how long an activity is going to take to
launch, but it still strikes me as the wrong metaphor.

As I mentioned before, I think it's much more important to the child
how much longer the launch will take (not how long it's taken so far).
In either case, perhaps we can get the same type of feedback by
counting the number of times an icon blinks. You could set the
frequency to 1 second.

>>> 3) Ability to count how many seconds the launch takes
>>
>> I'm not sure I see usefulness in knowing how long it takes overall;
>> knowing how much longer it will take is definitely something a kid
>> will want to know, though, so it's good to show that.
>
> The way it's implemented now, the kid has to remember how many dots an
> activity takes to start up.  But I think that could aid children who
> are learning to count :)  (WARNING: Heresay!!)

Heh.

>>> 4) Close button (instead of timeout) when there is an error
>>
>> This is definitely a big improvement. I like this a lot, and think we
>> should also add options for looking at the crash reports and/or
>> submitting a bug containing them to the maintainer of the activity,
>> eventually.
>
> I did some work towards this, with a patch ready for 0.88, in
> http://wiki.sugarlabs.org/go/Features/Problem_Reports.  I will
> definitely make it automatically save the activity log to the Journal,
> though.

Actually, I don't think this should be automatic. I would recommend
the options (report bug), (view logs), and (stop). This would give the
child the option to look at the logs if they wanted, but wouldn't
otherwise put items in their Journal they don't want or need. I'm not
sure if reporting is possible given the current infrastructure, but it
could be

Re: [Sugar-devel] Design mockup of a different activity launcher

[Eben Eliason]

On Sat, Oct 17, 2009 at 4:53 PM, Wade Brainerd  wrote:
> http://www.youtube.com/watch?v=OvDdN1t-0yE
>
> I was in the code and have wanted to try this for awhile!  If anyone
> else thinks it would be better than the pulsing icon, I'll clean up
> and post the patch to a Feature on the wiki.
>
> Rationale:
> 1) Less flashy

Perhaps, although the screen actually feels busier to me. Perhaps with
some visual tweaks it would work (smaller ring, maybe?), since showing
how long it will take to launch is useful feedback.

I lament the loss of the pulsing icon, though. This approach doesn't
retain the transition from outline to fill that's important to the
activity paradigm. Could we retain that, or is that the "flashy" part
you aim to eliminate?

> 2) Clock theme represents time

I don't understand how we know how long the launch is going to take.
Is that something that we can estimate to a reasonable degree? Or do
you plan to estimate the average launch time across many launches?

> 3) Ability to count how many seconds the launch takes

I'm not sure I see usefulness in knowing how long it takes overall;
knowing how much longer it will take is definitely something a kid
will want to know, though, so it's good to show that.

> 4) Close button (instead of timeout) when there is an error

This is definitely a big improvement. I like this a lot, and think we
should also add options for looking at the crash reports and/or
submitting a bug containing them to the maintainer of the activity,
eventually.

> 5) Possibly less startup overhead; needs to be tested on XO

True. If CPU is a concern, I'd vote to simply blink the icon between
stroke and fill states, instead of pulsing, in order to reduce the
animation overhead while retaining the visual metaphor.

Eben


> -Wade
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] friendview.py

[Eben Eliason]

On Sat, Oct 17, 2009 at 9:40 AM, Wade Brainerd  wrote:
> Yeah, P2P activity sharing would be awesome.
>
> http://wiki.sugarlabs.org/go/Development_Team/Almanac/Activity_Bundles
> says "Activities are meant to be shared between children. If a child
> doesn't have the activity, it is automatically transfered to the child
> when he or she joins the shared activity." but I don't believe this
> was ever implemented...?

Right.

To me, it sounds like the first step in building either of these
systems (automatic p2p transfer, download from browse) is figuring out
a way to publish the activity icon so that we DON'T have to show a
question mark. I would much rather show the icon for the activity that
the child doesn't have, and perhaps badge it in some way to indicate
that they don't yet have it.

This seems desirable regardless of which solution we choose to
download the activity.

Eben


> -Wade
>
> On Sat, Oct 17, 2009 at 9:35 AM, Benjamin M. Schwartz
>  wrote:
>> Tim McNamara wrote:
>>> Naturally, people will probably want to click on that question mark. Would
>>> we be able to have a dialogue like "Search for activity %s?" % name, which
>>> if accepted opens up Browse and searches http://activities.sugarlabs.org to
>>> download it?
>>
>> That would be about ten times better than the current behavior.
>>
>>> This would be easiest if you can p2p file share activities...
>>> I've played around a bit, but it doesn't look especially obvious.
>>
>> Yes, that would be, by far, even better.  It shouldn't be incredibly
>> difficult, since Telepathy provides us with a high-level file transfer
>> operation, but there's still some code required to (1) request the
>> transfer, (2) create a bundle if necessary, (3) transfer the bundle, (4)
>> install the bundle, and then (5) launch it.
>>
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] RFC: Kill the delayed menus for good

[Eben Eliason]

I wanted to include Christian on this thread since he may also wish to
try it out and have some valuable feedback.

It seems like this thread is somewhat split between design discussions
and process issues. Should it be exclusive to the sugar-devel list? If
we want feedback from people other than developers it seems we should
have a broader scope.

Eben


On Thu, Oct 15, 2009 at 11:19 PM, Eben Eliason  wrote:
> On Thu, Oct 15, 2009 at 10:09 PM, Avi  wrote:
>> Tomeu wrote:
>>
>>> I'm more concerned about developers proposing big user experience
>>> changes because they feel it's better. Before I look at the patch I
>>> would like to know if there's agreement from people close to our users
>>> that this behavior change is desired. How can we get that?
>>
>> How about users (me) proposing big user experience changes by asking a
>> developer (Michael) "why the fuck does this UI take so goddamned long to
>> react?" Also, define "our users". Is it people using Sugar? Is it people
>> using XOs? Is it people other than you? I'll gladly put myself into any of
>> these categories if it makes you happy.
>
> I think we'd all agree that the primary audience for Sugar is children
> of varied age groups and levels of education, and that audience should
> be considered first in terms of the user experience. I'm not
> suggesting, of course, that the rest of us aren't also users with
> valid input and experiences, or that this proposed patch was submitted
> without the best interests of that audience, or at least a reasonable
> portion of that audience, in mind.
>
> I also don't believe that Tomeu was stating a challenge of any kind,
> or insinuating that no one other than Michael was likely to have a
> positive response to the proposed change. The suggestion was that we
> collect feedback from many people, yourself included, and also from
> children in our primary audience and the teachers and instructors who
> work with them daily. In that regard, thank you for your feedback; it
> would be more constructive, of course, if you could provide it without
> the profanity and apparent disgust.
>
>> Eben wrote:
>>
>>> The initial design intent was to develop a system which worked in a
>>> sufficiently complete manner without needing palettes at all.
>>
>> 1) For whom? What about people who know how to recognize English letters and
>> words better than they remember what an obscure picture means? Because
>> you've failed on that front.
>
> For children! And actually, I agree with you. In many cases text is
> minimized more than I would like it to be. Clearly it's beneficial for
> those learning to read to see associations of words and icons, and
> words are naturally useful to those who already can.
>
>> 2) Good luck. Sincerely. I hope that if that's still your goal that it's
>> actually possible. I'm personally not convinced, but only because I haven't
>> yet seen a demonstration that shows progress on that front.
>
> Honestly, I think we've come relatively close. Would you strongly
> disagree? It's possible to create new activities, resume past
> activities, join collaborative activities, connect to networks,
> participate in activities, copy, paste, and stop activities with the
> use of primary actions only. I'm not suggesting that the full power of
> the UI is available without the need for seeing any text, but I am
> suggesting that there are a great many things you can do with Sugar
> without needing to use the secondary actions and tools available in
> palettes.
>
> If there are basic functions or actions that are frequently needed
> that aren't exposed as primary actions, it would be useful to identify
> those areas in order to make improvements. Do you have any
> suggestions?
>
>>> Finding that many kids were actually waiting for the palette to appear
>>> always, instead of, for instance, simply clicking on an activity icon
>>> to join it, encouraged us to INcrease the delay on the palettes to
>>> help emphasize this as a secondary mechanism for interaction.
>>
>> Jesus, why? Think about what you just said for a moment. Why might someone
>> wait for the palette to appear before clicking? Probably because they want
>> to see what's on the palette! The situation of the palette is that all it
>
> I was not precise enough in my statement. Upon observation, many
> children were waiting for the palette exclusively to select the first
> option within it, which is the primary action that a click on the
> object itself would also invoke. They were NOT attempting to a

Re: [Sugar-devel] RFC: Kill the delayed menus for good

[Eben Eliason]

On Thu, Oct 15, 2009 at 10:09 PM, Avi  wrote:
> Tomeu wrote:
>
>> I'm more concerned about developers proposing big user experience
>> changes because they feel it's better. Before I look at the patch I
>> would like to know if there's agreement from people close to our users
>> that this behavior change is desired. How can we get that?
>
> How about users (me) proposing big user experience changes by asking a
> developer (Michael) "why the fuck does this UI take so goddamned long to
> react?" Also, define "our users". Is it people using Sugar? Is it people
> using XOs? Is it people other than you? I'll gladly put myself into any of
> these categories if it makes you happy.

I think we'd all agree that the primary audience for Sugar is children
of varied age groups and levels of education, and that audience should
be considered first in terms of the user experience. I'm not
suggesting, of course, that the rest of us aren't also users with
valid input and experiences, or that this proposed patch was submitted
without the best interests of that audience, or at least a reasonable
portion of that audience, in mind.

I also don't believe that Tomeu was stating a challenge of any kind,
or insinuating that no one other than Michael was likely to have a
positive response to the proposed change. The suggestion was that we
collect feedback from many people, yourself included, and also from
children in our primary audience and the teachers and instructors who
work with them daily. In that regard, thank you for your feedback; it
would be more constructive, of course, if you could provide it without
the profanity and apparent disgust.

> Eben wrote:
>
>> The initial design intent was to develop a system which worked in a
>> sufficiently complete manner without needing palettes at all.
>
> 1) For whom? What about people who know how to recognize English letters and
> words better than they remember what an obscure picture means? Because
> you've failed on that front.

For children! And actually, I agree with you. In many cases text is
minimized more than I would like it to be. Clearly it's beneficial for
those learning to read to see associations of words and icons, and
words are naturally useful to those who already can.

> 2) Good luck. Sincerely. I hope that if that's still your goal that it's
> actually possible. I'm personally not convinced, but only because I haven't
> yet seen a demonstration that shows progress on that front.

Honestly, I think we've come relatively close. Would you strongly
disagree? It's possible to create new activities, resume past
activities, join collaborative activities, connect to networks,
participate in activities, copy, paste, and stop activities with the
use of primary actions only. I'm not suggesting that the full power of
the UI is available without the need for seeing any text, but I am
suggesting that there are a great many things you can do with Sugar
without needing to use the secondary actions and tools available in
palettes.

If there are basic functions or actions that are frequently needed
that aren't exposed as primary actions, it would be useful to identify
those areas in order to make improvements. Do you have any
suggestions?

>> Finding that many kids were actually waiting for the palette to appear
>> always, instead of, for instance, simply clicking on an activity icon
>> to join it, encouraged us to INcrease the delay on the palettes to
>> help emphasize this as a secondary mechanism for interaction.
>
> Jesus, why? Think about what you just said for a moment. Why might someone
> wait for the palette to appear before clicking? Probably because they want
> to see what's on the palette! The situation of the palette is that all it

I was not precise enough in my statement. Upon observation, many
children were waiting for the palette exclusively to select the first
option within it, which is the primary action that a click on the
object itself would also invoke. They were NOT attempting to access
the secondary functionality, but instead, due to the appearance of the
palette, assumed that this was the only means of interaction.

As Michael correctly points out, the contextual menus are indeed an
inferior solution to direct interactions, since they require finer
motor skills (and are difficult with poor trackpads, such as those on
XOs) and movement away from the object they wish to interact to a
secondary target within the menu. The icons are larger targets, easy
to click without delay, and would have saved children both time and
aggravation had they learned to act upon them directly.

> takes is one accident to discover that hovering shows useful information.
> And with the knowledge that the palette shows useful information, and that
> hovering shows the palette, it is reasonable that one might just engage in
> the described behavior. Either make the useful information available without
> the contextual menu or make the current expected behavior more responsive.

I think

Re: [Sugar-devel] RFC: Kill the delayed menus for good

[Eben Eliason]

On Wed, Oct 14, 2009 at 11:12 PM, Michael Stone  wrote:
> Eben,
>
> First, thanks for the interesting and detailed history of your vision. I
> very much appreciate your ability to generate thought experiments
> describing other ways that the world could be.
>
> Next...
>
> Eben wrote:
>>
>> Simon Schampijer  wrote:
>>
>> > You can use right click to get the menu immediately. The delay is on
>> > purpose.
>>
>> We should definitely get feedback. I wouldn't be entirely opposed to a
>> change, but I do want to make sure that we make such a change for the
>> right reasons, and that it's actually the right change to make.
>
> So try it, and encourage your friends to do the same! :)

I don't feel inclined to myself, as I've never had a problem with the
delay, and actually used to find the speed with which these palettes
obstructed my view of the screen frustrating before the delay was
increased. I assume there is a group of individuals — developers and
kids alike — who feel the same as I do, and others who feel the same
as you. Those that feel as you do, of course, should definitely try it
and provide feedback, which I'd be happy to hear.

I have no itch.

> (NB: merging it is a good way to accomplish this!)
>
>> The initial design intent was to develop a system which worked in a
>> sufficiently complete manner without needing palettes at all. Kids
>> should be able to start activities, resume activities, join
>> activities, write, paint, stop, etc. without ever seeing a palette at
>> all. [1] This is the "low floor". For kids with more experience or
>> curiosity, we decided to provide contextual palettes which grouped
>> related actions and provided more complex interactions with the
>> system. This is "no ceiling". Furthermore, we wanted to help introduce
>> kids to the availability of additional options in a discoverable way,
>> which is why the hover effect was chosen to provide increasing levels
>> of detail and interaction for a given object.
>
> This is a good story, but a bad implementation. A better implementation
> would be to provide the extra options in a *visible but unobtrusive

I disagree that this is an obviously better implementation. It's
"better" if you're one who frequently has needs for the additional
complexity. It's arguably not if you use only (or mostly) primary
actions.

> form* or, if you absolutely must hide them, to make them visible with a
> device like a "complexity slider" or like the new toolbar's "transient
> hover; lock on click" behavior.

Adding a preference for the delays for these palettes, as we have for
the frame, is a another reasonable possibility, and a literal
incarnation of the "complexity slider" you suggest.

> Remember -- comparisons should be made in a fixed visual field, not
> across multi-second long gulfs of time, cursor positioning, and fine
> motor control.
>
>> Finding that many kids were actually waiting for the palette to appear
>> always, instead of, for instance, simply clicking on an activity icon
>> to join it, encouraged us to INcrease the delay on the palettes to
>> help emphasize this as a secondary mechanism for interaction. A agree
>> that hovering in one place to click in another isn't great; but that's
>> also not the intended primary means of interaction, and should only
>> really be done when one of the secondary actions is desired.
>
> Understandable, but as you say, the result "isn't great". This makes it
> better. Try it! Merge it! (Then come up with something better.)

We had lots of trouble with palettes obscuring other elements of the
UI even with short delays, including, potentially, the desired target.
I can't imagine that this issue has gone away in the intervening
months, and removing the delay entirely seems it would exacerbate the
issue. Do you have any experiences to report in this regard?

>> Removing the delay pushes us, I fear, even farther away from an
>> interface in which nice friendly large clickable icons can be directly
>> manipulated and encourages every action to be done through a
>> contextual menu with a bunch of text in it. Is that really what we
>> want kids to face?
>
> It's better than the present. Again, merge it, then find something
> better.

You keep saying it's better, but fail to provide adequate reasoning or
heuristics for why you feel this to be so. Could you elaborate on the
problems you identified and the way in which this resolves them?

Also, again, it's only arguably better (though I don't fully
comprehend the argument) for those that want or need all of the
secondary functionality, yourself included, and the ability to
right-click to invoke palettes immediately exists to enable those who
feel more comfortable with the system and desire the added level of
depth it can provide to access these options without the delay.

>> Just for fun, I might suggest an alternate possibility which actually
>> decreases the discoverability of the secondary palette. We could
>> reveal the primary palette (label) on a 

Re: [Sugar-devel] RFC: Kill the delayed menus for good

[Eben Eliason]

On Wed, Oct 14, 2009 at 1:41 PM, Edward Cherlin  wrote:
> I'm extracting some of the for [[The Undiscoverable]].
>
> On Wed, Oct 14, 2009 at 9:39 AM, Eben Eliason  wrote:
>> On Wed, Oct 14, 2009 at 12:04 PM, Simon Schampijer  
>> wrote:
>>> On 10/13/2009 04:36 AM, Bernie Innocenti wrote:
>>>> Hello,
>>>>
>>>> Michael just passed by the Acetarium and, since the dinner was late, we
>>>> found the time to test and review his latest prototype^W patch.
>>>>
>>>> I'm loving how the menus suddenly are now snappy and responsive. Please,
>>>> test it yourself and report back. If we like this change, I think we
>>>> should go on and also kill the code that this patch makes redundant.
>>>> (please, let's not add another configurable knob!)
>
> Works for me. I hate hover menus.
>
>>>>> From 83ef08969ed7bee08f90c12bfa1eedcb7fb0500c Mon Sep 17 00:00:00 2001
>>>> From: Michael Stone
>>>> Date: Mon, 14 Sep 2009 22:33:12 -0400
>>>> Subject: Make various palette animations happen more quickly.
>>>
>>> Can you describe what the patch will change from the user point of view?
>>> Is this to get rid of the delayed build up of palettes when hovering
>>> over icons?
>>>
>>> You can use right click to get the menu immediately. The delay is on
>>> purpose.
>
> Yes, that's in [[The Undiscoverable]]
>
>> We should definitely get feedback. I wouldn't be entirely opposed to a
>> change, but I do want to make sure that we make such a change for the
>> right reasons, and that it's actually the right change to make.
>>
>> The initial design intent was to develop a system which worked in a
>> sufficiently complete manner without needing palettes at all. Kids
>> should be able to start activities, resume activities, join
>> activities, write, paint, stop, etc. without ever seeing a palette at
>> all. [1]
>
> That's fine, if
>
> 1) Everything is discoverable.

Yes, we could use some work there. The hover was meant to increase
discoverability, not decrease it, but perhaps it's not working
effectively.

> or
> 2) Teachers have guidance on what is not discoverable and how to
> introduce it, and on children's use cases and on how to handle those
> use cases efficiently.

Agreed.

> We have neither. I'm working on 2. Anything that improves 1 gets +1 from me.
>
>> This is the "low floor". For kids with more experience or
>> curiosity, we decided to provide contextual palettes which grouped
>> related actions and provided more complex interactions with the
>> system. This is "no ceiling". Furthermore, we wanted to help introduce
>> kids to the availability of additional options in a discoverable way,
>> which is why the hover effect was chosen to provide increasing levels
>> of detail and interaction for a given object.
>
> Was the discoverability of hover menus tested with children? I didn't
> discover it, and I'm a born lever puller and button clicker.

Almost nothing was tested with children until the first release of
Sugar on the XO-1, unfortunately; we would have liked to test more.

>> Finding that many kids were actually waiting for the palette to appear
>> always, instead of, for instance, simply clicking on an activity icon
>> to join it, encouraged us to INcrease the delay on the palettes to
>> help emphasize this as a secondary mechanism for interaction.
>
> A case of treating the symptom rather than the ailment.

Perhaps. What would you define as the ailment, yourself? The primary
intent was to encourage use of a direct interaction model, in which
palettes we're supposed to play a big role. When it turned out that
young kids, who didn't read, and who didn't have motor skills for
selecting form the palettes, we aimed to reduce accidental invocation
of them without entirely eliminating discovery by increasing the
delay.

Perhaps (assuming, of course, the rules you laid out above already) we
should remove the hover activation altogether! (Not, of course,
without testing!)

>> A agree
>> that hovering in one place to click in another isn't great; but that's
>> also not the intended primary means of interaction, and should only
>> really be done when one of the secondary actions is desired.
>>
>> Removing the delay pushes us, I fear, even farther away from an
>> interface in which nice friendly large clickable icons can be directly
>> manipulated and encourages every action to be done through a
>> contextual menu with a bunch of text in it. Is that really

Re: [Sugar-devel] RFC: Kill the delayed menus for good

[Eben Eliason]

On Wed, Oct 14, 2009 at 12:04 PM, Simon Schampijer  wrote:
> On 10/13/2009 04:36 AM, Bernie Innocenti wrote:
>> Hello,
>>
>> Michael just passed by the Acetarium and, since the dinner was late, we
>> found the time to test and review his latest prototype^W patch.
>>
>> I'm loving how the menus suddenly are now snappy and responsive. Please,
>> test it yourself and report back. If we like this change, I think we
>> should go on and also kill the code that this patch makes redundant.
>> (please, let's not add another configurable knob!)
>>
>>> From 83ef08969ed7bee08f90c12bfa1eedcb7fb0500c Mon Sep 17 00:00:00 2001
>> From: Michael Stone
>> Date: Mon, 14 Sep 2009 22:33:12 -0400
>> Subject: Make various palette animations happen more quickly.
>
> Can you describe what the patch will change from the user point of view?
> Is this to get rid of the delayed build up of palettes when hovering
> over icons?
>
> You can use right click to get the menu immediately. The delay is on
> purpose.

We should definitely get feedback. I wouldn't be entirely opposed to a
change, but I do want to make sure that we make such a change for the
right reasons, and that it's actually the right change to make.

The initial design intent was to develop a system which worked in a
sufficiently complete manner without needing palettes at all. Kids
should be able to start activities, resume activities, join
activities, write, paint, stop, etc. without ever seeing a palette at
all. [1] This is the "low floor". For kids with more experience or
curiosity, we decided to provide contextual palettes which grouped
related actions and provided more complex interactions with the
system. This is "no ceiling". Furthermore, we wanted to help introduce
kids to the availability of additional options in a discoverable way,
which is why the hover effect was chosen to provide increasing levels
of detail and interaction for a given object.

Finding that many kids were actually waiting for the palette to appear
always, instead of, for instance, simply clicking on an activity icon
to join it, encouraged us to INcrease the delay on the palettes to
help emphasize this as a secondary mechanism for interaction. A agree
that hovering in one place to click in another isn't great; but that's
also not the intended primary means of interaction, and should only
really be done when one of the secondary actions is desired.

Removing the delay pushes us, I fear, even farther away from an
interface in which nice friendly large clickable icons can be directly
manipulated and encourages every action to be done through a
contextual menu with a bunch of text in it. Is that really what we
want kids to face?

Just for fun, I might suggest an alternate possibility which actually
decreases the discoverability of the secondary palette. We could
reveal the primary palette (label) on a delay as we do now, with some
indication of "more options" that can be clicked to expand the menu to
reveal the secondary items. This would provide the (essential) primary
palette as a label and introduce kids to the existence of more
controls without encouraging them to use this as a primary method of
interaction. Advanced users, of course, could still right-click to
invoke the full menu in one shot.

Eben

[1] Incidentally, one of my major complaints with the "resume by
default" behavior is that it makes starting new activities hard to do,
and virtually impossible to do without using a secondary action, which
is the wrong approach in my mind. I think starting from home, with the
option to resume, while encouraging one-click resume from the Journal
is still the correct approach.  I think offering the option to enter
"resume by default" mode is great, but I'm not sure it should be,
itself, the default for Home view.

In practice, it seems it has worked too "well". It used to be that
kids never resumed activities. Now, it seems, they never start new
ones. The solution seems to be in encouraging use of the Journal and
the Home view for these different default actions, and in clarifying
the UI such that kids understand and desire to do so.

Eben



> Regards,
>    Simon
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] ASLO layout issue in safari

[Eben Eliason]

On Fri, Oct 9, 2009 at 1:43 PM, Josh Williams  wrote:
> Sean DALY wrote:
>> Our websites really shouldn't make any assumptions about what browser
>> our visitors are using...

Agreed.

>
> Point taken. Would you or anyone else be opposed to using something like
> http://code.google.com/p/universal-ie6-css/ for ie6? This will provide
> access to all of the application's content (but save a considerable
> amount of development time for me).
>
> Sean, you have analytics set up on ASLO now right? If so can you share
> our visitors browser statistics?

Yeah, that would be worth looking into. While I don't think we should
make assumptions about which browsers visitors will use, I also don't
think we necessarily need to jump through hoops to support backwards
compatibility in older and entirely non-compliant (in terms of web
standards) browsers. (Specifically, I'd suggest not worrying about
IE6, if we can avoid it.)

That said, I'd fully expect all our pages to work in any modern
standards compliant browser, such as FF, Safari, and Chrome, and we
should probably make sure that IE 7,8 also work smoothly. The
statistics will be enlightening, I'm sure.

Eben


> -Josh
>> Sean
>>
>>
>> On Fri, Oct 9, 2009 at 7:32 PM, Josh Williams  wrote:
>>
>>> Hi Caroline,
>>>
>>> Thanks for the feedback! I actually wasn't planning on making this a
>>> cross web browser upgrade, but only for gecko/browse. If there's a
>>> general consensus that it should be bug free for other browsers, I can
>>> see the reasoning for that and I'm willing to make it work. I'm guessing
>>> you'd like to see it work in safari/ie/chrome/opera as well?
>>>
>>> If others want to chime in please do so.
>>>
>>> -Josh
>>>
>>>
>>> Caroline Meeks
>>> Fri, 09 Oct 2009 05:13:06 -0700
>>>
>>> Nice!
>>> Here is a layout issue on Safari on a mac:
>>> http://screencast.com/t/Fyu8zoqjzfyu
>>>
>>> On Fri, Oct 9, 2009 at 2:25 AM, Aleksey Lim  wrote:
>>>
>>>  > Hi all,
>>>  >
>>>  > Josh Williams finished new Sugar theme for Activity Library(ASLO),
>>>  > please test it from [1]. Thanks Josh, it looks awesome.
>>>  >
>>>  > In several days ASLO code base will be rebased to last AMO, (it
>>>  > should give us new AMO features like tagging and new developers UI)
>>>  > and new theme will appear on the main site.
>>>  >
>>>  > [1] http://activities-devel.sugarlabs.org/
>>>  >
>>>  > --
>>>  > Aleksey
>>>  > ___
>>>  > Sugar-devel mailing list
>>>  > Sugar-devel@lists.sugarlabs.org
>>>  > http://lists.sugarlabs.org/listinfo/sugar-devel
>>>  >
>>>
>>>
>>>
>>> --
>>> Caroline Meeks
>>> Solution Grove
>>> carol...@solutiongrove.com
>>>
>>> 617-500-3488 - Office
>>> 505-213-3268 - Fax
>>>
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] New Sugar theme for Activity Library

[Eben Eliason]

Cool!

A few comments:

1. I don't really like the way that "Activities" is positioned as a
superscript after the Sugar logo. I think that "activities" could
follow on the line below the Sugar logo, left aligned (there may be
other equally good options).

2. The green interspersed throughout threw me off a bit. The
styleguide for Sugarlabs pages, as I understand it, is a two-tone
color scheme (in addition to the grayscale) inherited from the logo,
so that all of the content and links share the colors in the logo on
the page. If we could fix that, especially in the menu on the left, I
think it would tie in with the other pages better.

3. The link hover style on other Sugarlabs pages is usually to invert
the foreground and background colors, which usually means white text
against the dark logo color. This is another change that we could
integrate throughout to add consistency to the theme.

Good work!
Eben



On Fri, Oct 9, 2009 at 2:25 AM, Aleksey Lim  wrote:
> Hi all,
>
> Josh Williams finished new Sugar theme for Activity Library(ASLO),
> please test it from [1]. Thanks Josh, it looks awesome.
>
> In several days ASLO code base will be rebased to last AMO, (it
> should give us new AMO features like tagging and new developers UI)
> and new theme will appear on the main site.
>
> [1] http://activities-devel.sugarlabs.org/
>
> --
> Aleksey
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [ANNOUNCE] Sucrose 0.86 Branching - Activity versions

[Eben Eliason]

On Thu, Oct 1, 2009 at 7:16 AM, Peter Robinson  wrote:
> On Thu, Oct 1, 2009 at 12:08 PM, Wade Brainerd  wrote:
>> On Thu, Oct 1, 2009 at 5:20 AM, Simon Schampijer 
>> wrote:
>>>
>>> *Activity versions*
>>> As we use integers for activity versions (this really has to change for
>>> 0.88 with introducing minor versions), we need to cope for the famous:
>>> stable/unstable version issue. I would say to leave at least 3 version
>>> numbers open when doing a new unstable release. An example:
>>>
>>> Walter has submitted TurtleArt 69 for 0.86. He reserves the numbers 70,
>>> 71, 72 for bug fix releases. When he is doing a release from the
>>> unstable master branch (0.88 development) he is using numbers > 72.

This still seems pretty limiting. What if he finds he actually needs 4
bugfix releases? Why should replace a limited system with another
that's just as limiting (This suggestion is kind of like going from
O(0) to O(3), instead of O(n) like we really need).

>> I'm still against this plan.  Does anyone else feel like the integer numbers
>> are a good thing?

I think it's been argued that it would be easier for kids, though I've
counter-argued that it's harder to make sense of integer versioning
when it's just more confusing to attempt to map the natural numbers
onto a non-linear space. The decimal notation helps make the branching
more visible, which adds clarity in addition to complexity (and it's
clear the complexity can't be gotten rid of).

>> We have been striving to keep activity releases backwards compatible as far
>> as possible; there should be no need to branch activities for sucrose
>> releases.  If a bug is found, sucrose can be updated to the latest version.
>
> I agree. why not have 69 as the primary release and fixes against it
> for the branch as 69.1 69.2 etc. Or if its meant for a particular

This definitely makes the most sense to me. I think that the
major/minor distinction, where each portion of that version number is
monotonically increasing, will keep things relatively simple without
being too limiting. You can argue for major.minor.bugfix, too (which
is more like O(n^2)), but chances are we'd all rather avoid that if
possible. Of course, we could simply support version strings of this
kind, but collectively agree to avoid the third field unless it's
absolutely necessary.

If we really want to keep integer version numbers, perhaps we should
just "multiply by 10" and allot versions 10 at a time, so that major
releases would go from 60 to 70 to 80, etc, leaving 9 (yes, still just
a constant, O(9)) bugfix releases open per major version, but allowing
us to talk about activities as the "60s" or "70s" instead of keeping
track of which 3 or so versions run on which platform. It's worth
noting that this would get us into 4 digit version numbers a lot
faster, of course.

It could be a terrible idea, but I'm just throwin' it out there.

Eben

> version of sugar and not meant to be compatible with earlier versions
> use the same release as the release of sugar. It would at least be
> easy to work out that version 86.x is needed for sugar 0.86.x as 69
> has no relationship what so ever.
>
> Peter
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Colors in the rim (Re: sugaronastick.com (was Re: Beta Test of Sugar on a Stick Backup Service.))

[Eben Eliason]

There just aren't enough possibilities for uniqueness with only one
color. The pair as an identifier of the individual needs to stay, I
think.

We could, perhaps, expose that kind of information in the secondary
palette for XOs since it seems it would serve a purpose for some. I
don't think it's a detail kids are going to need much, especially in
local groups or schools where the distribution will be the same, so I
wouldn't expose it more than necessary.

Out of curiosity, to what extent is this a problem? Most activities
should function fine across distributions, I would think.

Eben


On Thu, Sep 17, 2009 at 10:32 PM, Thomas C Gilliard
 wrote:
> Luke:
> I am thinking more of the usage case of community jabber users.
>
> (There are differences in how different distributions applications
> collaborate and function.)
> One could then know which features are available if you invite someone to an
> activity.
>
> This would be more useful in a non- XS situation where all people on the
> neighborhood
> are not using the same Sugar-Desktop.
>
> Thus by looking at the rim color a Sugar User would immediately have this
> information.
> The inside color of the XO would still be chosen by the user, and be
> variable.
>
> Tom Gilliard
>
> Luke Faraone wrote:
>
> On Thu, Sep 17, 2009 at 18:35, Thomas C Gilliard 
>
> wrote:
>
>
>
>
> I also wish that the range of rim colors available for the XO choice in F1
> Neighborhood would distinguish what Distribution they are based on...
>
>
> I'm just curious, but how is this relevant to the end user? Most students
> probably wouldn't care about what distro their friends are using.
>
>
>
>
> 
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Calculate toolbars work in progress shots

[Eben Eliason]

On Fri, Sep 11, 2009 at 3:17 PM, Gary C Martin wrote:
> Hi Eben,
>
> On 11 Sep 2009, at 20:11, Eben Eliason wrote:
>
>> Looks great! The icons are quite nice.
>>
>> My only suggestion is that (still retaining the modularity!) the misc
>> toolbar actually just be added as another secondary toolbar. That
>> leaves the basic toolbar mostly empty, but that's ok! This is an
>> instance, I think, where all of the basic functionality of the
>> calculator lives outside of the toolbar, and each toolbar adds
>> advanced functionality on top of that. Moreover, "misc" controls seem
>> to be the worst suited for a primary toolbar, which should instead
>> contain controls that are nearly always useful, or useful in all
>> contexts.
>
> Thanks, that's pretty much where I was at but wanted another opinion :-) The
> one exception (for the future) will I hope be the Plot function. I'd love to
> see that UI improved via a Secondary toolbar, at the least with a set of
> standard example graphs for folks to plug in values (now that matplot lib is
> supported).

Yeah, definitely. It would make sense to have a toolbar dedicated to that.

I could also see dedicating a toolbar to constants. You've got buttons
for a couple of them. Perhaps a few more could be added. If some don't
have obvious symbols or frequent use, the constants toolbar could also
have a dropdown that read "add a constant" by default, and contained a
list of many with full names to add. A suggested symbol for this would
follow the trend of the color and shape icons in the mockup of the
Paint activity, which showed a small 2x2 grid of colors and shapes,
respectively. I'd use e, pi, phi, and something else.

If constants and graphs had their own secondary toolbars, I could see
an argument for exposing the display mode in the primary toolbar,
since it affects all calculations and could be useful to see at all
times.

> Any suggestions for a "Misc" icon? ;-)

I don't, unfortunately, have a good idea for a generic misc icon. It
seems like any option I can think of I would consider bad design,
which might be because using the concept of "leftovers" to group
together a set of tools in a toolbar is just a bad idea. Heh. But
short of breaking out the functionality as described above (which
itself could seem odd without more functions in each toolbar), I don't
have a better idea.

I could get behind leaving the modes and the graph button up there for
now if we could find a few more constants to add to a secondary
constants toolbar and leave it at that. What do you think?

Eben


>
> Regards,
> --Gary
>
>> On Fri, Sep 11, 2009 at 2:59 PM, Gary C Martin
>> wrote:
>>>
>>> Here's a quick set of screen grabs of a patch for Calculates toolbars,
>>> I'm
>>> making the code work for 0.82, 0.84 (keeping old style tab toolbars), and
>>> 0.86 (new style toolbars). To keep high re-use and minimum changes of
>>> code
>>> between the two toolbar styles, I'm using the same code for generating
>>> each
>>> toolbar, and the old 'Miscellaneous' tab content is being shown in the
>>> primary new toolbar design.
>>>
>>> Give me a shout if you have any feedback! I'll push my changes to a git
>>> clone of Calculate later tonight (all things going well):
>>>
>>>
>>>
>>>
>>> Regards,
>>> --Gary
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>>
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Calculate toolbars work in progress shots

[Eben Eliason]

Looks great! The icons are quite nice.

My only suggestion is that (still retaining the modularity!) the misc
toolbar actually just be added as another secondary toolbar. That
leaves the basic toolbar mostly empty, but that's ok! This is an
instance, I think, where all of the basic functionality of the
calculator lives outside of the toolbar, and each toolbar adds
advanced functionality on top of that. Moreover, "misc" controls seem
to be the worst suited for a primary toolbar, which should instead
contain controls that are nearly always useful, or useful in all
contexts.

Eben


On Fri, Sep 11, 2009 at 2:59 PM, Gary C Martin wrote:
> Here's a quick set of screen grabs of a patch for Calculates toolbars, I'm
> making the code work for 0.82, 0.84 (keeping old style tab toolbars), and
> 0.86 (new style toolbars). To keep high re-use and minimum changes of code
> between the two toolbar styles, I'm using the same code for generating each
> toolbar, and the old 'Miscellaneous' tab content is being shown in the
> primary new toolbar design.
>
> Give me a shout if you have any feedback! I'll push my changes to a git
> clone of Calculate later tonight (all things going well):
>
>
>
>
> Regards,
> --Gary
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [RFA] Feature freeze break: Read

[Eben Eliason]

On Tue, Sep 8, 2009 at 2:19 PM, Simon Schampijer wrote:
> On 09/08/2009 08:10 PM, Sayamindu Dasgupta wrote:
>> On Tue, Sep 8, 2009 at 10:00 PM, Gary C Martin  wrote:
>>> On 7 Sep 2009, at 23:13, Simon Schampijer wrote:
>>>
 On 09/07/2009 08:37 PM, Sayamindu Dasgupta wrote:
> Hello,
> Attached is the patch for making Read support the new toolbar system
> (patch courtesy of Simon). While it is a bit long, most of the changes
> is moving around stuff.
>
> Known issue:
> a) The TOC combobox, the bookmark toggle and the Stop buttons
> occasionally "overflow", as detailed in the post:
> http://lists.sugarlabs.org/archive/sugar-devel/2009-September/019021.html
> There is no know workarounds yet.
>
> There seems to be no other regressions as per my brief testing.
>
> Thanks,
> Sayamindu
 I have attached a new patch. It does move the TOC-combobox into a
 secondary toolbar to overcome the space issue. One issue with this is, that
 one uses the combobox and dismisses it, the secondary toolbar does not get
 dismissed automatically as well (toc-list-open, toc-list). Aleksey any idea
 if this triggers something is in the toolbarbox code itself?

 I have played with using the view-list icon for that option or the
 bullet-list one from the Write activity (bullet-icon). Feedback welcome.

  From testing, there is no regression.

 -
 General Feedback:

 Finally, would be nice to add a little text to the combobox, when there is
 not TOC information, at the moment we have an unusable button (no-toc). Or
 make it insensitive, or...
>>> If there is no TOC, the ToolbarButton (and one of the separators) should not
>>> be displayed at all. So you only see TOC ToolbarButton if the document has a
>>> TOC.
>>>
>>
>> In Read 73, the TOC button is not displayed if there is no support for
>> ToC, or if the document does not have a ToC.
>>
>> Thanks,
>> Sayamindu
>
> Actually, we could make the button insensitive as well. I like that more
> than hiding, because the general functionality is still there - can just
> not be used with this document (we do the same for the share button for
> example).

The question of making a control insensitive vs. hiding it entirely is
always a little tricky. Generally, the decision should be made based
on two things:

1. Can the control be enabled via some action on the part of the user
(making the appropriate selection, entering some text, changing focus,
adjusting another control, etc.)?
2. Does the control provide useful information in its disabled state?

If the answer is "yes" to either, the control should probably be shown
but made insensitive. If the answer is "no" to both, it should
probably be hidden.

I think we can answer yes to question two for the share button, which
indicates both that the current activity is private, and also that the
activity doesn't support sharing. Both are useful facts. I think I'd
probably answer no to both for the TOC, though. The absence of a table
of contents is a property of the book, which the user can't modify (it
would be different if it were editable!), and the only useful info the
insensitive control would provide is that, for *some* books, there is
some other feature available, but it wouldn't provide useful info in
the context of this particular activity.

Eben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] turtle art: 2 instances, no?

[Eben Eliason]

On Mon, Sep 7, 2009 at 8:15 AM, Gary C Martin wrote:
> Hi Bill,
>
> On 7 Sep 2009, at 12:09, Bill Kerr wrote:
>
>> I can't see any way to load 2 instances on the SoaS version
>>
>> If I have a project loaded, saved and named
>> Then go into the journal and try to load an older saved version then
>> it doesn't load but puts me back to the current open version
>> I have to first close the current version and then open the older
>> version to get it
>
> This is not a bug with TurtleArt. It's (in my view) the major design
> backfire that is the "Keep" button... Keep is not like a copy,
> duplicate or 'save as' file operation in other OS environments. Sugars
> "Keep" is actually a (bad) attempt at "Keep version snap shot",
> unfortunately no where in the Journal UI is this visually indicated/
> referenced. Think of "Keep" a little like non-linear undo states
> stored to Journal.

This is true. Perhaps we could make it more explicit by naming it
"Save a version" instead. What we really need is a "Keep a copy"
secondary action that can be used in the manner many desire, to create
a clone of the instance with a separate activity ID. Equally
important, we should have a "Make a copy" or "Duplicate" button in the
Journal to enable this as a top level function there.

Here's some more background reading:
http://lists.sugarlabs.org/archive/sugar-devel/2009-July/016494.html

> The problem with all this is that Sugar currently treats all versions
> you "Keep" from an activity as the same activity. You can only have
> one of the versions active at once, this is what you're seeing when

This is actually another bug. On several of the threads discussing
versions this came up, and it's clear that there is value to having
multiple versions of the same activity instance open at once,
specifically for the purpose of copying elements from an older version
into a newer one. Revising Sugar to make this possible, regardless of
when we land version support, would be beneficial.

> you try to resume (what you think is another old activity is actually
> a version) and Sugar switches to the current version of it you already
> have open.

We also discussed that this might be a choice (to join the existing,
or work on the older version).

Eben

> To create fresh new activities, you need to:
>
> 1) start new activity
> 2) create masterpiece
> 3) stop activity
> 4) goto step 1
>
> If you ever find yourself clicking "Keep" give your self a small jab
> in the hand with a sharp protractor ;-)
>
> In every release of Sugar to date, "Keep" == horrible design failure,
> even for the upcoming 0.86. The problem is "the real deal" (true
> versioning) is always just over the horizon, like the pot of gold at
> the end of the rainbow, and the blasted button some how makes it
> through (and causes way more grief then it ever solves as the common
> use case is "I want a duplicate copy of this").
>
> Regards,
> --Gary
>
>> Also if I am working on a project and remember an idea from a sample
>> project then I can't just load the sample view the idea and then
>> quickly return to my current project to implement there
>> I have to close current project, then open sample and view idea,
>> then close sample, then reopen current project, etc.
>>
>> Please correct if I am wrong about this
>> ___
>> IAEP -- It's An Education Project (not a laptop project!)
>> i...@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/iaep
>
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Remove the naming alert in 0.86

[Eben Eliason]

On Sat, Sep 5, 2009 at 11:51 AM, Gary C Martin wrote:
> On 5 Sep 2009, at 12:53, Tomeu Vizoso wrote:
>
>> On Sat, Sep 5, 2009 at 13:46, Benjamin M.
>> Schwartz wrote:
>>> Tomeu Vizoso wrote:
 I also think that improving the default texts will improve greatly
 this issue. Anybody wants to tackle it? Maybe for a reduced number
 of
 activities at first?
>>>
>>> Ah, but what should it say?
>>
>> I think that the best automatic title will be activity-dependent.

Definitely.

>> Activities can already set any title they want in the write_file()
>> method, but should respect the title_set_by_user property.
>>
>>> How about "Change this title to a description of this Write
>>> Document!"?
>
> E no thanks!! :-)
>
>> That's interesting, though has its drawbacks.
>
> Drawbacks, are that many will still choose to not edit the name, and
> Journal will fill with this junk text when ever they don't bother (I
> usually only edit a name if I think the content is of future use).
>
> The auto-title needs to be smarter, more useful, not more annoying ;-)

Agreed.

> Two good concrete example suggestions I've seen so far:
>
> Eben suggested Chat at least (and perhaps some others) could be using
> the buddy name as part of its default title, "Gary's Chat Activity'.
> This has the added benefit that when shared, the Neighbourhood view
> will get that more descriptive title (you currently need to edit a
> title before sharing for the text to show up).
>
> Christoph suggested Write could use the first few words from the
> document as part of the default title so "The Lazy Dog Write
> Activity". This could get quite smart, but a few cases could be enough
> ie. take first line of text followed by newline as title, limit to N
> words, if longer than N also add ellipsis. "A voyage in space; a
> course of six lectures 'adapted... Write Activity"
>
> It's also been suggested that when title names are identical, it would
> be nice to append a unique number so at least there is some different

Yes, I think this would be really good.

> text in the title. Perhaps a natural language date string could serve
> as the same device (as the Journal is not providing any way of
> presenting creation dates and could realy help when searching "tuesday
> august 18 notes").

I can see some utility there, but it could also be rather confusing to
have multiple dates exposed for every entry in the Journal. I'd lean
toward a simpler and shorter counting mechanism.

> I think each Activity will have different options to get a good name
> (i.e in Labyrinth I could have it take the text from the primary man
> node), but se should agree on some general improvements so we can have
> some consistency in behaviour (i.e. an extended set of recommended
> title guidelines for activity authors).

Would it be easier for activities to provide a method like
get_default_title() that the shell calls when appropriate? If we had
this, then activities wouldn't have to deal with checking whether or
not the user has already titled something, minimizing effort and
possible error, and we could also have the shell check the DS for
same-name entries and append a unique identifier itself, again
ensuring consistency and removing work from the activity. The shell
would only call this function once when an activity is first closed
(when the naming alert currently appears), and then only when the
title hasn't yet been set by the user.

Eben



> Regards,
> --Gary
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Memorize create icon

[Eben Eliason]

On Fri, Sep 4, 2009 at 3:27 PM, Caroline Meeks wrote:
> On my wish list is the ability to combine tiles from different students.  So
> each student could do a couple of States then you could play a game with all
> the states by sharing tiles from the whole class.

That would be pretty awesome. It might be (relatively) easy to allow
collaborative creation of tiles, with each child's display showing
their own "creator" screen, but a shared collection of tiles. Whether
or not that would be clear enough to be usable is another question. I
suppose the tiles would/could be colored according to their creator
while in create mode, which would certainly help.

> Another issue is what to do about identical answers. For instance you make a
> math game. 2+2 = 4 and 1+3 =4 but right now if you click on the wrong 4 I
> don't think it matches.

This problem is fairly easy to solve technically, but actually rather
advanced to expose to kids in the creation UI. It requires identifying
equivalence classes  of pairs (one equivalence class, as per your
example, would contain both (2+2, 4) and (1+3, 4)). The pairs in these
equivalence classes many or may not be ordered, which would be another
complex choice to require of the user. That is, 1+3 = 2+2, but it is
likely the intent of the creator to always match an expression to a
value. An equivalence class defined having pairs (2+2, 4) and (4, 1+3)
is "correct" mathematically, but would still yield unexpected matches
in play.

Alternatively, the items in the equivalence class could be treated
individually instead of in pairs, eg. (2+2, 1+3, 4, 4), in which case
any item in the class can be matched to any other. This, again, may
not actually be desired.

Eben


> Thanks,
> Caroline
>
> On Fri, Sep 4, 2009 at 2:35 PM, Joshua N Pritikin 
> wrote:
>>
>> On Fri, Sep 04, 2009 at 10:55:10AM -0400, Walter Bender wrote:
>> > To whomever is going to make these invasive changes, there are some
>> > rendering "bugs" in Memorize as well. Images should be centered in the
>> > tiles; presently they are justified to the top of the tile. Also, we
>> > should probably use a drop shadow for the text so that white text on
>> > white image problems are circumvented.
>>
>> I'd also like an option to play with all the tiles uncovered.
>> Memorization is hard enough without needing to temporarily memorize the
>> locations of all the tiles.
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
> --
> Caroline Meeks
> Solution Grove
> carol...@solutiongrove.com
>
> 617-500-3488 - Office
> 505-213-3268 - Fax
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Friends view UI affordances?

[Eben Eliason]

On Wed, Sep 2, 2009 at 10:01 PM, Caroline Meeks wrote:
> My vision is that we would create Moodle Classes for all the various
> groupings that students have throughout the day.
> Then maybe the Neighborhood view shows only people who share a group with
> you, or maybe those people get preference if the Neighborhood gets too
> crowded.

I think giving preference to people one knows/interacts with is a
logical approach.

> On the Friends view it might be useful to pick just one of these groups. So
> if I'm in Reading Group A right now I could choose Reading Group A in a drop
> down in the friends view and it would show only people in my reading group.
>  Later I am in Mr. J's Afterschool club and I pick that so I can work with
> them.  After that I'm in homework time and I want to work on my Reading
> Group, I can use this to easily see if anyone else from my Reading Group is
> around to work on the homework assignment with.

+1. This has been our intent for the groups view all along, and the
lack of groups (naturally) has left it mostly useless. I think we
should retain the ability to make friends, who should also appear in
the view (and give it some utility until the rest is built), but the
ability to filter the view to see and interact with specific groups of
individuals is key to the collaborative experience.

We had an ambitious view of what groups should be in the absence of a
server, before Moodle was investigated. Perhaps we can start with a
moodle approach and merge/sync that with a server-less approach later.
Or perhaps the server-less "ideal" isn't actually needed, and Moodle
is the appropriate means of introducing this much desired feature.

Eben


> On Mon, Aug 31, 2009 at 11:46 AM, Benjamin M. Schwartz
>  wrote:
>>
>> Christoph Derndorfer wrote:
>> > On Mon, Aug 31, 2009 at 5:03 PM, Walter Bender
>> > wrote:
>> >
>> >> 5. Automatically add anyone with whom you have been collaborating to
>> >> the Friends view. (Doesn't quite solve the problem Michael describes,
>> >> but it will result in a populated view. And it is easy enough to
>> >> delete entries.)
>> >
>> >
>> > Personally I'm very much opposed to doing something like this without
>> > the
>> > user's explicit consent, especially since this is quickly going to
>> > result in
>> > a very cluttered "friend's view".
>>
>> I agree... unless we rename it to something like the "Recent Friends"
>> view.  It could simply show, say, the 20 people with whom we have most
>> recently collaborated.  This would discard existing functionality in favor
>> of different, new functionality.  I suspect that this would still be an
>> improvement, and that the current Friends view is little-used, but it
>> would be nice to have confirmation from deployers before tearing out that
>> feature.
>>
>> Ideally, both of these functions could coexist in the context of the
>> Groups View, but we have only the vaguest mockups of how Groups should
>> function, and even less of a blueprint for implementing them.
>>
>> --Ben
>>
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
>
> --
> Caroline Meeks
> Solution Grove
> carol...@solutiongrove.com
>
> 617-500-3488 - Office
> 505-213-3268 - Fax
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Ad-hoc network identification badge

[Eben Eliason]

On Fri, Aug 28, 2009 at 5:41 PM, Gary C Martin wrote:
> On 28 Aug 2009, at 21:51, Eben Eliason wrote:
>
>> On Fri, Aug 28, 2009 at 4:16 PM, Gary C Martin
>> wrote:
>>>
>>> On 27 Aug 2009, at 22:24, Simon Schampijer wrote:
>>>
>>>> On 08/27/2009 10:42 PM, Gary C Martin wrote:
>>>>>
>>>>> Quick ping,
>>>>>
>>>>> Do we need something like an emblem-buddy.svg for ad-hoc network icons
>>>>> (e.g. an XO icon used in same way as the star and lock icon are used
>>>>> to badge AP icons)? Sorry couldn't find a trac ticket or the right ML
>>>>> thread.
>>>>>
>>>>> Regards,
>>>>> --Gary
>>>>
>>>> Yeah, I think we settled on a badged AP icon. If you have something in
>>>> mind - please share it with us ;p
>>>
>>> OK :-) Just tested the buddy icon pretty much as is for an emblem, but it
>>> doesn't quite ring true (feels too fussy). Here's a few screen shots:
>>>
>>> So taking a leaf out of the emblem-locked style and came up with what I
>>> think is a much better emblem using a box outline and solid stroke colour
>>> for the buddy icon:
>>
>> Yup. I would definitely recommend the (unstroked, as you show it) XO
>> icon within the box, as well. The badge feels just a little high in
>> your mockups (it should be at a 45 degree angle from center, and
>> positioned so that the lower-right corner falls outside the 55px
>> recommended icon region, at (70,70)), but that's just an issue of
>> defining the hotspot correctly.
>
> I copied the existing emblem-locked.svg positioning without falter, so
> assume this is the emblem placing code that's a little off (unless
> emblem-locked is wrong).
>
>> Also, all bages are supposed to be
>> black fills with white strokes (and white symbols within the box, eg.
>> the XO itself). I think that never happened because entity support was
>> never added for badges.
>
> Oh, OK. So black box (white stroke?) with white buddy icon (in this example)
> is the intention?

Yup, these look great!

>> Does someone know how to add that so we can fix the badges up?
>> Alternatively, does someone want to update all of the default SVGs for
>> the badges so that they use the correct colors without use of
>> entities?
>
> Well the one's I've looked at have &stroke_color and &fill_color so it could
> just be a simple code change I guess (above screen shot was taken just by

Right. I made them with the proper entities, but the code path for
creating the badges isn't tied into the Sugar classes that do the
entity replacement (or something like that). So we'd have to look into
the badging code to see how to hook that up.

> changing stroke to white, and fill to black). But I can do that in each of
> the emblem-*.svg if that's all that is needed, and is easier for core devs?

That seems like a really quick short term fix, so it might be worth
doing, unless a few minutes investigation of the code presents an
obvious solution. Actually, we've honestly never had any designs for
colored badges and I don't anticipate them in the near term, so maybe
supporting entities there is overkill and modifying the SVGs directly
is the right course anyway.

Eben


>> Thanks Gary! (For the mockups, that is; I'm not volunteering you for
>> the above task).
>
> Hey, no problem, I've been volunteered for far worse things ;-)
>
> Regards,
> --Gary
>
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Ad-hoc network identification badge

[Eben Eliason]

On Fri, Aug 28, 2009 at 4:16 PM, Gary C Martin wrote:
> On 27 Aug 2009, at 22:24, Simon Schampijer wrote:
>
>> On 08/27/2009 10:42 PM, Gary C Martin wrote:
>>>
>>> Quick ping,
>>>
>>> Do we need something like an emblem-buddy.svg for ad-hoc network icons
>>> (e.g. an XO icon used in same way as the star and lock icon are used
>>> to badge AP icons)? Sorry couldn't find a trac ticket or the right ML
>>> thread.
>>>
>>> Regards,
>>> --Gary
>>
>> Yeah, I think we settled on a badged AP icon. If you have something in
>> mind - please share it with us ;p
>
> OK :-) Just tested the buddy icon pretty much as is for an emblem, but it
> doesn't quite ring true (feels too fussy). Here's a few screen shots:
>
>
>
> So taking a leaf out of the emblem-locked style and came up with what I
> think is a much better emblem using a box outline and solid stroke colour
> for the buddy icon:

Yup. I would definitely recommend the (unstroked, as you show it) XO
icon within the box, as well. The badge feels just a little high in
your mockups (it should be at a 45 degree angle from center, and
positioned so that the lower-right corner falls outside the 55px
recommended icon region, at (70,70)), but that's just an issue of
defining the hotspot correctly. Also, all bages are supposed to be
black fills with white strokes (and white symbols within the box, eg.
the XO itself). I think that never happened because entity support was
never added for badges.

Does someone know how to add that so we can fix the badges up?
Alternatively, does someone want to update all of the default SVGs for
the badges so that they use the correct colors without use of
entities?

Thanks Gary! (For the mockups, that is; I'm not volunteering you for
the above task)

Eben

>
>
>
> Attaching the .svg for this version to the email, though happy to provide
> the other if folks think that looks better.
>
> Regards,
> --Gary
>
>
>
>
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Accessing external media from within an activity (was: Re: Problem listing journal objects)

[Eben Eliason]

On Wed, Aug 26, 2009 at 12:13 PM, Gary C Martin wrote:
> Hi Jim,
>
> On 26 Aug 2009, at 16:09, Jim Simmons wrote:
>
>> Eben,
>>
>> I have given some thought to how I would implement getting image files
>> from removable media and I think I have a workable plan.  Before I
>> describe it I'd like to confess that it is *not* true that .84 code
>> will show objects on the root directory of a thumb drive.  It won't
>> show *anything* on a thumb drive, as some of you have pointed out.
>> .82 shows every file whether it is on a thumb drive or in the Journal.
>> It is shown as a flat list with no way to tell what came from where.
>>
>> What I think I might do is emulate this behavior in .84.  Python has
>> an os.walk() function that will list out all the files within a
>> subdirectory.  I was thinking that after I load the table with Journal
>> objects I could do the os.walk() for the directory /media, which is
>> where all the removable media seems to get mounted.  In my table model
>> I would store the filename and a wrapper class for a Journal object.
>> If there is an actual Journal object in there it would call the object
>> to get a path to the image file in the Journal.  If not, it would
>> simply get a real path to a file on a removable device.
>>
>> I would not check for mounts, etc.  Instead, my Activity has a Refresh
>> button which reloads everything.  The user would know when he needs to
>> use it.
>>
>> I might put some sort of icon in the table rows so the user knows
>> which entries are from the Journal and which are from thumb drives,
>> etc.
>>
>> I suppose the ObjectChooser should be improved as much as possible,
>> but I doubt I'll ever use it myself.  If you want to load only one
>> file into an Activity you could just as easily restore the file from
>> the Journal.  If you need to load more than one file having a modal
>> dialog pop up each time just slows you down.
>
> FWIW (though I know you're trying to support existing Sugar releases); I see
> whispers happening in git that suggest ObjectChooser might be visited by the
> new thumbnail view that is the hawk swooping towards the rabbit silhouetted
> Journal, trying to bolt for its feature freeze warren... If the hawk is
> faster than the rabbit, in the next release cycle (0.88), multi-selection in
> both Journal and ObjectChooser would be fine features to champion as unified
> ways browsing/importing objects! :-)
>

Agreed. That seems ideal to me.

Of course, there's also support for asking the datastore for all
objects of a specific mime-type, specifically to allow activities to
display the content inline, in their own way, if they choose to do so.
Perhaps that system could be extended to include data on external
devices as well as the Journal so that the legwork is still done by
Sugar, but activities gain access to external media.

Eben


> Regards,
> --Gary
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Accessing external media from within an activity (was: Re: Problem listing journal objects)

[Eben Eliason]

I think I'm looking in the right place, but the info isn't as readily
available as I'd hoped. I'm looking here:
http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Installation/OLPC

In particular, I'm looking at options 2 and 3. The third says it's not
yet supported. The second says it's not fully supported (though
"recent builds are better"; perhaps the limitations listed there
should be removed if it's working with new builds...), and simply
links to several mailing list threads. I did read these in the past,
and in general it was more digging than I was really into doing at the
time, and required following several intertwined discussions about not
only installing to NAND, but also running off a USB stick.

Moreover, there are some download links within the mailing list posts,
but those (as far as I could tell) were for older versions, and
there's no clear indication that I can get the latest or exactly what
to do with it on the wiki itself. In fact, it's odd to me that after
clicking "Get Sugar" and finding my desired platform, there was no
direct download link at all.

Now, I don't want this to sound like I'm complaining. I think that the
"Get Sugar" link is easy enough to find, but it wouldn't hurt to have
a much bigger one somewhere in the main page. There is a big link to
SoaS (which also has nice direct download instructions), and perhaps
that's the most common way people will install it and that's the
reason for not making the "Get Sugar" page more prominent. In any
case, the "Get Sugar" page, listing the various platforms is great!
It's very clear. It's the content on the specific platform page (in my
case, OLPC-XO) that left me unclear on exactly how to proceed.

Eben


On Wed, Aug 26, 2009 at 11:55 AM, Martin
Dengler wrote:
> On Wed, Aug 26, 2009 at 11:43:54AM -0400, Eben Eliason wrote:
>> On Wed, Aug 26, 2009 at 11:35 AM, Gary C Martin wrote:
>> > You really do need to upgrade ;-p
>>
>> I know! I've been waiting to figure out how to get the latest releases
>> flashed onto my XOs. The last time I looked I didn't see clear
>> instructions for doing so. Any pointers?
>
> Where did you look?  It'd be useful to know so interested people like
> me could fix that lack.
>
>> > Regards,
>> > --Gary
>>
>> Eben
>
> Martin
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Accessing external media from within an activity (was: Re: Problem listing journal objects)

[Eben Eliason]

On Wed, Aug 26, 2009 at 11:35 AM, Gary C Martin wrote:
> Hi Eben,
>
> On 26 Aug 2009, at 14:53, Eben Eliason wrote:
>
>> On Wed, Aug 19, 2009 at 5:43 AM, Sascha
>> Silbe wrote:
>>>
>>> On Wed, Aug 19, 2009 at 08:41:28AM +0200, Tomeu Vizoso wrote:
>>>
>>>> The public API is the POSIX one, though I don't know how this will be
>>>> affected by future versions of Rainbow.
>>>
>>> I can't find anything regarding mount points in POSIX 2001. How do you
>>> expect Jims activity to discover them?
>>> Two ways come to my mind:
>>> a) parse /proc/mounts periodically
>>> Linux-only, time-wasting but future-proof
>>>
>>> b) use what the Journal is using internally, i.e. the Gnome way of the
>>> day
>>> cross-platform (as much as Gnome/Sugar are), event-driven, but likely to
>>> break on next release
>>>
>>> Just as a reminder: The intended workflow for Jims activity seems to be:
>>> 1. Start activity
>>> 2. Plug in USB stick with photos
>>> 3. Select and/or manage(?) photo from within the activity
>>>
>>> Answering "use POSIX" is like "use a computer", it doesn't help getting
>>> the
>>> job done. If the answer is "we want the user to copy the photos to the
>>> data
>>> store first", that doesn't get the job done either, but it's a policy and
>>> can be catered for (i.e. documented).
>>
>> The way I saw this working would be to extend the object chooser to
>> allow multiple sources, including external media. Where there is
>> currently a Journal icon in the chooser, we would also show any USB
>> sticks and SD cards present, and these would be selectable (with the
>> Journal the default, of course). Any activity could then invoke the
>> object chooser to select objects from the Journal or from external
>> media, without the overhead of building their own UI. Once the objects
>> are loaded into the activity, they can be bundled up and saved as
>> desired.
>>
>> We even have some preliminary design sketches for this feature:
>> http://wiki.sugarlabs.org/go/Design_Team/Designs/Object_Chooser#04
>
> You really do need to upgrade ;-p

I know! I've been waiting to figure out how to get the latest releases
flashed onto my XOs. The last time I looked I didn't see clear
instructions for doing so. Any pointers?

> It's implemented and displays the content of external media (see attached
> image). You can even eject and insert new sticks all from within the
> ObjectChooser while you hunt about for that stick with those embarrassing

Nice!

> holiday photos on. But before you get too excited, I'm not having much luck
> actually opening any files displayed from an external USB stick, (though I
> am running sugar-jhbuild that seems to be a 'between releases' hybrid just
> at this point in time). I've filed ticket
> http://dev.sugarlabs.org/ticket/1241
>
> Eben: While I've got you here, can you confirm or deny that the icon being
> used to represent the Journal data-store is wrong. Note that for a release
> or so (~0.84 I think) the icon being shown here (ObjectChooser) and in the
> toolbar at the bottom of the Journal is an XO icon – it used to be the
> Journal icon (aka, note pad/book). I'm not convinced this change was
> intentional.

No, I don't believe it was intentional. We should reinforce the
identity of the Journal as strongly as we can. Thanks for pointing it
out.

Eben


> Regards,
> --Gary
>
>
>
>
>
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Accessing external media from within an activity (was: Re: Problem listing journal objects)

[Eben Eliason]

On Wed, Aug 19, 2009 at 5:43 AM, Sascha
Silbe wrote:
> On Wed, Aug 19, 2009 at 08:41:28AM +0200, Tomeu Vizoso wrote:
>
>> The public API is the POSIX one, though I don't know how this will be
>> affected by future versions of Rainbow.
>
> I can't find anything regarding mount points in POSIX 2001. How do you
> expect Jims activity to discover them?
> Two ways come to my mind:
> a) parse /proc/mounts periodically
> Linux-only, time-wasting but future-proof
>
> b) use what the Journal is using internally, i.e. the Gnome way of the day
> cross-platform (as much as Gnome/Sugar are), event-driven, but likely to
> break on next release
>
> Just as a reminder: The intended workflow for Jims activity seems to be:
> 1. Start activity
> 2. Plug in USB stick with photos
> 3. Select and/or manage(?) photo from within the activity
>
> Answering "use POSIX" is like "use a computer", it doesn't help getting the
> job done. If the answer is "we want the user to copy the photos to the data
> store first", that doesn't get the job done either, but it's a policy and
> can be catered for (i.e. documented).

The way I saw this working would be to extend the object chooser to
allow multiple sources, including external media. Where there is
currently a Journal icon in the chooser, we would also show any USB
sticks and SD cards present, and these would be selectable (with the
Journal the default, of course). Any activity could then invoke the
object chooser to select objects from the Journal or from external
media, without the overhead of building their own UI. Once the objects
are loaded into the activity, they can be bundled up and saved as
desired.

We even have some preliminary design sketches for this feature:
http://wiki.sugarlabs.org/go/Design_Team/Designs/Object_Chooser#04

Eben


> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQEcBAEBAgAGBQJKi8kiAAoJELpz82VMF3Da9+kH/iA64CVf2gkml2dmLezzWdPt
> HwDhOjpqh+eAs06i+we8UlqwRAgoEmqBMQ7eC16eqm4UrWhSKo6OeX0Rk1RdW8/o
> Lf1a7HsHpCjxWhudDOtxMcGUeLtb4ahGZR+0mYNiXG5I6DhJh6Diq+UAbGqRXZy7
> mo80yjbFDf6NTW2J7qI6mTvhNJl1pEOEpx+FF30Dg5BpUZ+b5ES03nL2WhDK4LUV
> O6FTEPFfsXSLvYFUTG2TA7Ggjz43RxeAnp2Vuc2Pu6YbNX21iT5OT+12hAWzyMDx
> QWqOSjEedKZZvT6bhXOWsBGPuff/XmOz83KESR4JsLXQp208BI+3zFBEmxBoYDQ=
> =Yl9z
> -END PGP SIGNATURE-
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Tag designs (was Re: [DESIGN] UI mockups)

[Eben Eliason]

On Wed, Aug 19, 2009 at 6:10 PM, Eduardo H. Silva wrote:
> I also remembered something else, more of the description could appear
> as a tooltip.

I'd definitely like to see more info about entries in the palette. It
would be great to have the preview and at least the first part of the
description there.
Eben

> Eduardo
>
> 2009/8/19 Eduardo H. Silva :
>> Hi, just saw the mockup, where beneath each journal entry it shows the
>> tags it has. Have you thought about showing the first line of the
>> entry description in there? Perhaps it is more rich in information
>> than tags, to have the first line of the description in there, and
>> would extra incentive for the user to describe his journal entries.
>>
>> Eduardo
>>
>> 2009/8/19 Bert Freudenberg :
>>>
>>> On 19.08.2009, at 18:41, Gary C Martin wrote:
>>>
 On 19 Aug 2009, at 17:19, Bert Freudenberg wrote:

>> [forwarded from christian]
>>
>> several options for the Journal,
>> exploring various toolbars, the grid view, and tagging;
>>
>> [1] http://shell.sugarlabs.org/~erikos/090818_journal_thumbnails.pdf
>
>
> I like the tags icon. It should be used throughout to indicate tags
> (currently it's missing in the menu palette showing tags).
>
> For selecting tags, instead of the vertical list which wastes screen
> real estate due to different tag lengths, why not lay them out
> horizontally wrapped (using the same white rounded rects as in the
> menu), using the whole width of the screen? This would work either in
> a hover palette, or a panel at the bottom of the screen.

 Kind'a like these mock-ups?

       
 http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tags_palette
>>>
>>>
>>> Yes, though there needs to be a search pane like in Christian's
>>> mockups. And potentially we need to deal with lots of tags, so using
>>> more of the screen plus scroll bars seems to be necessary.
>>>
>>> - Bert -
>>>
>>>
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] UI mockups

[Eben Eliason]

Actually, the mockup is incomplete. The gray fills are meant to
represent actual images that I simply didn't have time to add to the
mockup. Any entry without a preview at all was intended to have a
light outline, with its activity icon shown within it instead.

http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#10

Eben


On Sun, Aug 23, 2009 at 10:38 AM, Gary C Martin wrote:
> On 23 Aug 2009, at 12:34, Simon Schampijer wrote:
>
>> On 08/22/2009 09:30 PM, Aleksey Lim wrote:
>>>
>>> On Sat, Aug 22, 2009 at 08:16:38PM +0100, Gary C Martin wrote:

 On 22 Aug 2009, at 19:50, Aleksey Lim wrote:

> On Sat, Aug 22, 2009 at 02:05:03PM +, Aleksey Lim wrote:
>>
>> On Wed, Aug 19, 2009 at 05:12:34PM +0200, Simon Schampijer wrote:
>>>
>>> [forwarded from christian]
>>>
>>> Hi all,
>>>
>>> I've attached two (annotated) PDFs with mockups of the issues
>>> we talked
>>> about on Sunday. The first has several options for the Journal,
>>> exploring various toolbars, the grid view, and tagging; the
>>> second looks
>>> at simple vs. complex toolbars in activities.
>>>
>>> Make sure you read the annotations, and let me know what you
>>> think. Once
>>> we have reached a consensus, I can generate PNGs and post to
>>> the wiki.
>>>
>>>
>>> Christian
>>>
>>> PS. Let's also figure out a time to chat, unless email seems
>>> sufficient.
>>> I can be available for a short time around 10am (EST)/2pm
>>> (UTC) tomorrow
>>> morning, if necessary.
>>>
>>> [1] http://shell.sugarlabs.org/~erikos/090818_journal_thumbnails.pdf
>>> [2] http://shell.sugarlabs.org/~erikos/090818_toolbars.pdf
>>
>> You can try Thumbs view implementation from cloned repo[3]
>> or see screenshot[4].
>>
>> In comparing with mockups it has lack of multi selection and sorting
>> features, I heard that we are not in consensus on that(?)
>> * using check boxes of Shift key to multi select
>> * using title like buttons[5] or something else
>>
>> Also I moved details button from cell bottom to the left.
>>
>> [3] http://git.sugarlabs.org/projects/sugar/repos/thumbs
>> [4] http://wiki.sugarlabs.org/go/File:Thumbs.png
>> [5] http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#10
>
> I've encountered another problem - I can't get rid of popups in
> thumbs view, since all workspace belongs to thumbs.
> I think we can do not auto popup palette and open them only on right
> click.

 What is it like if just the thumb image rectangle has the auto
 pop-up?
>>>
>>> Thats it, only thumb rectangle is sensitive but even in that case auto
>>> popups could be annoying.
>>
>> To me, the delay for the palette looks good enough to prevent accidental
>> popups.
>>
>> I have attached a screenshot where some of the thumbnails have no border
>> and therefore the shape of the thumb can not be distinguished that well.
>> Maybe we should add a little black border by default?
>
> FWIW, Eben used a light grey fill in his design for empty thumbs, not sure
> if there was a specific decision behind that. Just did a quick mock-up with
> light grey fills vs. outlines, and they both seem to work well (though the
> fill is perhaps a little stronger).
>
>
>
>
>
> Regards,
> --Gary
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Ad-hoc network UI feedback

[Eben Eliason]

On Mon, Aug 24, 2009 at 5:23 PM, Christian Schmidt wrote:
>
> 
> From: Tomeu Vizoso [mailto:to...@sugarlabs.org]
> To: Daniel Drake [mailto:d...@laptop.org]
> Cc: Gary C Martin [mailto:g...@garycmartin.com], Christian Marc Schmidt
> [mailto:schm...@pentagram.com], Sugar-dev Devel
> [mailto:sugar-de...@lists.sugarlabs.org], Eben Eliason
> [mailto:eben.elia...@gmail.com]
> Sent: Mon, 24 Aug 2009 03:54:13 -0400
> Subject: Re: [Sugar-devel] Ad-hoc network UI feedback
>
> On Sat, Aug 22, 2009 at 06:17, Daniel Drake wrote:
>> 2009/8/22 Gary C Martin :
>>> 1) Is it a bug that there are 2 'grey circles' showing the same "Create
>>> new
>>> wireless network" entry?
>>
>> It's acting as designed - showing the status of all the wireless
>> devices it can find in the system. eth0 and msh0.
>
> Is this desirable from the users POV?

This seems very confusing to me. Can you have an ad-hoc network on
both? Also, the mesh should have the mesh icon, which appears absent
in the screenshots. I concur with Gary that the light gray state is a
bug; the icons should be white stroke (no fill), or colored.

> Is there a place on the wiki where I can read up on this proposal? At first
> glance it seems confusing--at the last we should differentiate the two
> functions, but I'm also certain there is a better way to handle this
> interaction.

Agreed.

Eben


> Thanks,
>
> Christian
>
> Regards,
>
> Tomeu
>
>> Daniel
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
>
> --
> «Sugar Labs is anyone who participates in improving and using Sugar.
> What Sugar Labs does is determined by the participants.» - David
> Farning
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Design meeting tomorrow?

[Eben Eliason]

Thanks Christian, and sorry all! I would have spoken up sooner, but my
vacation plans have been somewhat undefined and only today did I know
exactly what time I'd be available. I'm looking forward to chatting
with everyone tomorrow.

Eben


On Sat, Aug 15, 2009 at 9:23 PM, Christian Schmidt wrote:
> Hi again
>
> Eben has to leave at 10:30 EST tomorrow, so why don't we start 30 mins
> earlier, at 9:30 EST/3:30 UTC. Hopefully that works for everyone.
>
> Thanks,
>
> Christian
>
> 
> From: Gary C Martin [mailto:g...@garycmartin.com]
> To: Christian Schmidt [mailto:schm...@pentagram.com], Daniel Drake
> [mailto:d...@laptop.org]
> Cc: Simon Schampijer [mailto:si...@schampijer.de], Sugar-dev Devel
> [mailto:sugar-de...@lists.sugarlabs.org], Eben Eliason
> [mailto:eben.elia...@gmail.com]
> Sent: Sat, 15 Aug 2009 18:42:09 -0400
> Subject: Re: Design meeting tomorrow?
>
> Hi Christian,
>
> Looking at your To/Cc list, I think we're all in for the meeting,
> excepting I haven't seen a confirmation email from Daniel yet. Given
> the feature freeze is on Thursday, we should cover what we can, as
> soon as we can, and obviously pick up any additional feedback before
> the feature freeze if we can.
>
> Regards,
> --Gary
>
> On 15 Aug 2009, at 22:58, Christian Schmidt wrote:
>
>> Hi everyone
>>
>> I suggested earlier this week that we meet via IRC (#sugar-meeting)
>> at 10am EST (2pm UTC) tomorrow to discuss the new toolbars and
>> several other current issues before the next feature freeze. Are we
>> still on for this? There are a few people I haven't heard back from
>> yet. We can also move it to another time during the week if tomorrow
>> doesn't work for everyone.
>>
>> Thanks,
>>
>>
>> Christian
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Yet more feedback from Boston! - Chat and Speak

[Eben Eliason]

On Sat, Aug 15, 2009 at 1:35 PM, Gary C Martin wrote:
> On 14 Aug 2009, at 17:11, Eben Eliason wrote:
>
>> On Thu, Aug 13, 2009 at 8:28 PM, Caroline
>> Meeks wrote:
>>>
>>> Neither wind nor rain nor flaming emails will deter me from telling you
>>> about what happened with kids and Sugar today in Boston! You however are
>>> free to use your delete key at any time.
>>> Today, working with 6th grade students at the Museum of Science Computer
>>> Clubhouse I learned not to start a Sugar intro session with chat.  It was
>>> hard for us to believe but the kids spent 3 hours really wanting to do
>>> nothing but use chat to talk to other kids in the same room!!  We did get
>>> them to use other things but
>>> next time I will end with Chat, not start with it :)
>>> We used both Chat and Speak.  Chat was more robust.
>>> I suggest that Speak be limited to about 4 participants. It seemed die a
>>> lot and if someone typed a lot of garbdy gook it would try to say it all and
>>> get behind.  What do other people think of this idea? Should I ticket it?
>>> I started the lesson by creating a chat, sharing it and showing the
>>> students
>>> how to join from their neighborhood. That worked fairly well.
>>> However, some of the students wanted to create a private chat.  It could
>>> be
>>> done but it was very challenging workflow.  The problem is if two kids
>>> decide they want to chat the natural thing for them to do is both goto
>>> Home
>>> and click on Chat and share that with the neighborhood.  This results in
>>> two
>>> chats and much confusion.  I don't know how to solve this, as I'm not
>>> gifted
>>> at UI design, but its clearly a problem.  Perhaps when you start chat you
>>> have a UI inside of chat that lets you join other existing chats
>>> directly.
>>
>> I think there are a few first-steps to simplify this process that have
>> already been designed. First and foremost, it should be possible to
>> select a sharing scope when starting a new activity. In past mockups,
>> we offered this functionality via a "Start with >" option, which
>> revealed a submenu containing both a list of friends, and a list of
>> groups. We could build the first part of this today.
>>
>> Likewise, the redesign of the sharing controls within the activity
>> itself provide us the chance to do the same when sharing an ongoing
>> activity. In addition to listing "private" and "my neighborhood", we
>> could also introduce "my friends", as well as individuals.
>
> Ooohhh, nice one, +1, though I think the actual menu needs some thinking
> about so we don't conflate the Journal "Resume with -> " and this
> proposed home view "Start with -> ". Also think "Start with ->

Good point. Perhaps resuming should say "Resume in >" instead, to
indicate that you're entering into a new activity context.

> Neighbourhood" should be in that list. There is also the issue of shared

Oh, absolutely. In my mind, "My Neighborhood" and "My friends" should
act like two implicit groups. I think the best way to order the
submenu is [my neighborhood, my friends, {list of groups}, {list of
friends}].

> activity titles... Currently you have to title your activity before sharing
> (though that even feature seems somewhat buggy, not sure if this is broken
> Sugar UI, or an issue with Telepathy), otherwise you just get default "Chat
> Activity" activities in the neighbourhood.

There have been a number of discussions and ideas around better
default names for activity titles. Perhaps we could take a small step
with a potentially large payoff and make the default activity title
"'s  activity" instead, so that at least we'd have
"Eben's chat activity" and "Gary's chat activity", which is far more
useful as a default.

> Tthere is at least one obvious string change to be made to the home activity
> palettes. "Start" should be "New", or given above possible feature perhaps
> "Start new" is better, so that "Start new with -> " will read a
> little better:

I like keeping the distinction between "start" and "resume", both of
which are verbs. That's important. If we fel the need to make it more
explicit by appending "new", that could work, but I'm not sure it's
necessary with the proper uncolored icon.

Eben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity toolbar redesign: What to do with 'simple' activities?

[Eben Eliason]

I would be willing to set some time aside for that. Early mornings are
best for me.

Eben


On Wed, Aug 12, 2009 at 9:24 AM, Christian Marc
Schmidt wrote:
> Yes, I agree. Unless everyone is on the same page, it may make sense to
> schedule a meeting this weekend, also to go over proposals for list view in
> Neighborhood and to discuss groups. What does everyone think?
>
>
> Christian
>
>
> On Wed, Aug 12, 2009 at 9:15 AM, Eben Eliason 
> wrote:
>>
>> Last we discussed this, I think we decided that activities which don't
>> modify the toolbars in any way should have a single toolbar containing
>> all of the activity toolbar controls: title entry, sharing, keep, etc.
>> Only if the activity wanted to modify the toolbars would the activity
>> specific stuff be moved under a toolbar button.
>>
>> I recall coming to the same conclusion with Christian as well.
>>
>> Eben
>>
>>
>> On Wed, Aug 12, 2009 at 7:19 AM, Lucian
>> Branescu wrote:
>> > Would it be possible to offer a more compact design, with a single
>> > bar, but with the new API?
>> >
>> > 2009/8/12 Simon Schampijer :
>> >> Hi,
>> >>
>> >> I just ported the hello world example to the new toolbar design [1]. I
>> >> remember that once Gary pointed out, that simple activities will look
>> >> 'empty' when we move them to the new design (screenshot attached), Chat
>> >> would be a famous case. Most of the activities does have options,
>> >> though.
>> >>
>> >> How do we go forward with that? Live with that compromise? Other ideas?
>> >>
>> >> Thanks,
>> >>   Simon
>> >>
>> >> [1]
>> >>
>> >> http://git.sugarlabs.org/projects/hello-world/repos/mainline/blobs/master/activity.py#line36
>> >>
>> >> ___
>> >> Sugar-devel mailing list
>> >> Sugar-devel@lists.sugarlabs.org
>> >> http://lists.sugarlabs.org/listinfo/sugar-devel
>> >>
>> >>
>> >
>
>
>
> --
> anyth...@christianmarcschmidt.com
>
> http://www.christianmarcschmidt.com
>
> 917/ 575 0013
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity toolbar redesign: What to do with 'simple' activities?

[Eben Eliason]

Last we discussed this, I think we decided that activities which don't
modify the toolbars in any way should have a single toolbar containing
all of the activity toolbar controls: title entry, sharing, keep, etc.
Only if the activity wanted to modify the toolbars would the activity
specific stuff be moved under a toolbar button.

I recall coming to the same conclusion with Christian as well.

Eben


On Wed, Aug 12, 2009 at 7:19 AM, Lucian
Branescu wrote:
> Would it be possible to offer a more compact design, with a single
> bar, but with the new API?
>
> 2009/8/12 Simon Schampijer :
>> Hi,
>>
>> I just ported the hello world example to the new toolbar design [1]. I
>> remember that once Gary pointed out, that simple activities will look
>> 'empty' when we move them to the new design (screenshot attached), Chat
>> would be a famous case. Most of the activities does have options, though.
>>
>> How do we go forward with that? Live with that compromise? Other ideas?
>>
>> Thanks,
>>   Simon
>>
>> [1]
>> http://git.sugarlabs.org/projects/hello-world/repos/mainline/blobs/master/activity.py#line36
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Design help needed for web applications within Sugar

[Eben Eliason]

On Tue, Aug 11, 2009 at 1:13 PM, Lucian
Branescu wrote:
> 2009/8/11 Simon Schampijer :
>> On 08/11/2009 12:14 PM, Lucian Branescu wrote:
>>>
>>> In fact, there is the option to install the SSB activity as well,
>>> http://dl.getdropbox.com/u/317039/create%20ssb.png
>>
>> Yes seen that.
>>
>>> rgs on IRC suggested that the 'Keep in Journal' button could either
>>> save an offline version by itself or there could be a drop down with
>>> several options.
>>
>> Do you mean the activity keep button? Like the one in Write - where we have
>> the options to save a richt text format or others? If yes - yeah that sounds
>> like a good option actually.
>
> I'll go ahead and try to implement that, then.
>
>>
>>> About modifying SSBs, right now all the tools for modification are
>>> inside the actul activity. I'd like to see modification of userscripts
>>> and userstyles done in 'View Source' (as well).
>>
>> Oh, yeah view source. Sounds interesting to me, too. We just need to make
>> sure to not overload it. I mean editing text is easy. When it comes to
>> changing the icon it gets more complicated, though.
>
> Perhaps the Sugar shell should allow users to change activity icons?

It's an unfortunate fact that there is no activity suitable for
creating SVG icons for Sugar. We need a "Draw" activity to fill this
gap and compliment Paint...

> In any case, View Source already has Document view and Bundle view. We
> could either expand Document view to have a TreeView on the left like
> Bundle view or create a separate Editables view.

I hesitate to overload the view source mechanism this way, actually.
Should we instead be providing a seamless mechanism for modifying
code, icons, etc. with other activities, so that users (eventually)
have choices regarding their editors? View source is a logical step in
the process, so we should certainly expose the ability to launch into
editing from there, of course. I suppose an alternative argument can
be made for the level of integration we could provide when editing
within the view source dialog. If we could hook it up to have
"real-time" effect on the running activity, so that making a change
couldbe tested right away, that may make it worth doing...

Eben

>>
>> Regards,
>>   Simon
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Design] Ad-hoc networks - New Icons

[Eben Eliason]

On Tue, Aug 11, 2009 at 11:22 AM, Simon Schampijer wrote:
> On 08/11/2009 03:49 PM, Eben Eliason wrote:
>>
>> On Tue, Aug 11, 2009 at 6:21 AM, Simon Schampijer
>>  wrote:
>>>
>>> On 08/11/2009 11:50 AM, Daniel Drake wrote:
>>>>
>>>> 2009/8/11 Simon Schampijer:
>>>>>
>>>>> I think it would help, to have a new icon for the ad-hoc network to
>>>>> distinguish them. Could be a badged wireless network one? Or is the
>>>>> mesh
>>>>> icon appropriate? Or something completely new?
>>>>
>>>> I think new icons would be best, to distinguish from the mesh. I think
>>>> we can expect mesh support again soon ;)
>>>
>>>  From the user POV they are the same I guess. A local network, that does
>>> not
>>> need any infrastructure.
>>
>>> Though, the mesh on the XO is handled automatically, the ad-hoc network
>>> requires user interaction to create it. I wonder if we ever will see a
>>> user
>>> using both (not at the same time) on the same machine. To think about the
>>> visual clash, at least.
>>
>> Perhaps we could use the mesh icon with a little XO badge, to indicate
>> that it's functionally similar to the "real" mesh, but enabled by a
>> specific XO. Thinking about this now, it might be the case that Tomeu
>> had built this functionality as an extension of the wireless network
>> device in the Frame; Should it be an extension of the mesh device
>> instead, based on its perceived similarities to that feature more than
>> an AP?
>>
>> Eben
>
> Yes, as of today, it is an extension of the wireless network frame device.
> http://1.bp.blogspot.com/_OoKpv4QinxI/SiFiDO2RsAI/ACU/go8n8S6rrE0/s1600-h/soas-create.png
>
> From the similarities, I agree, a badged mesh icon would work well to
> demonstrate that.

I suppose I see arguments in both directions. A badged AP icon would
also make sense. Ben's question about the persistence of the network
in the absence of the creator is also important to answer.

> Another question is the behavior: Gary and some others were wondering if we
> should fallback to an adhoc network automatically, if we are not connected
> to an AP.

This might bias us towards treating it more or less like the mesh. For
what it's worth, it seems like the ability for separate classes (for
instance) to create separate networks would be a benefit in terms of
network reliability.

Eben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Design] Ad-hoc networks - New Icons

[Eben Eliason]

On Tue, Aug 11, 2009 at 6:21 AM, Simon Schampijer wrote:
> On 08/11/2009 11:50 AM, Daniel Drake wrote:
>>
>> 2009/8/11 Simon Schampijer:
>>>
>>> I think it would help, to have a new icon for the ad-hoc network to
>>> distinguish them. Could be a badged wireless network one? Or is the mesh
>>> icon appropriate? Or something completely new?
>>
>> I think new icons would be best, to distinguish from the mesh. I think
>> we can expect mesh support again soon ;)
>
> From the user POV they are the same I guess. A local network, that does not
> need any infrastructure.

> Though, the mesh on the XO is handled automatically, the ad-hoc network
> requires user interaction to create it. I wonder if we ever will see a user
> using both (not at the same time) on the same machine. To think about the
> visual clash, at least.

Perhaps we could use the mesh icon with a little XO badge, to indicate
that it's functionally similar to the "real" mesh, but enabled by a
specific XO. Thinking about this now, it might be the case that Tomeu
had built this functionality as an extension of the wireless network
device in the Frame; Should it be an extension of the mesh device
instead, based on its perceived similarities to that feature more than
an AP?

Eben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Share button in the activity toolbar (from the toolbar redesign thread)

[Eben Eliason]

On Tue, Aug 11, 2009 at 9:19 AM, Aleksey Lim wrote:
> On Tue, Aug 11, 2009 at 08:02:10AM -0400, Walter Bender wrote:
>> On Tue, Aug 11, 2009 at 6:49 AM, Simon Schampijer wrote:
>> > On 08/06/2009 04:59 PM, Simon Schampijer wrote:
>> >> On 08/06/2009 03:37 PM, Eben Eliason wrote:
>> >>> On Thu, Aug 6, 2009 at 6:56 AM, Simon Schampijer   
>> >>> wrote:
>> >>>> On 07/31/2009 05:14 PM, Eben Eliason wrote:
>> >>>>> On Fri, Jul 31, 2009 at 8:41 AM, Aleksey Lim
>> >>>>>    wrote:
>> >>>>>> On Fri, Jul 31, 2009 at 02:05:48PM +0200, Tomeu Vizoso wrote:
>> >>>>>>> On Fri, Jul 31, 2009 at 13:47, Simon Schampijer
>> >>>>>>>    wrote:
>> >>>>>>>> Another question that came up today:
>> >>>>>>>>
>> >>>>>>>> Should the activity toolbar contain the "share" option by default?
>> >>>>>>>> Disabled by default?
>> >>>>>>> Maybe we could use the max_participants property to know when to
>> >>>>>>> disable the button?
>> >>>>> This makes sense to me. I think it's useful to keep it in view to
>> >>>>> indicate that the activity is private. A non-collaborative activity
>> >>>>> still has a sharing scope.
>> >>>>>
>> >>>>>> So, the question is - what is default value for max_participants :)
>> >>>>>>
>> >>>>>> In current code it equals to 0 but old sharing component compares it
>> >>>>>> with 1 thus share combo is visible by default.
>> >>>>> An activity that supports 0 participants (or fewer!) sounds pretty
>> >>>>> useless. Clearly 1 is the logical default for this property.
>> >>>>>
>> >>>>>> btw all activities, I've seen before that don't want sharing, hide
>> >>>>>> share combo by share.props.visible not by max_participants, I guess
>> >>>>>> it signalizes about not consistency of current implementation where
>> >>>>>> user can hide/show share button by two different methods.
>> >>>>> Yup, we should push towards consistency here. I'd bet activities
>> >>>>> wouldn't bother to hide it if Sugar made it insensitive properly.
>> >>>>>
>> >>>>> Eben
>> >>>> So, sounds like max-participants should be set to '1' by default. And 
>> >>>> we use
>> >>> Definitely.
>> >>>
>> >>>> this value to display the sharing option or not.
>> >>>>
>> >>>> Or did you mean to display it and make it sensitive/insensitive, Eben?
>> >>> I think it should always be shown, but made insensitive accordingly
>> >>> based on max_participants.
>> >>>
>> >>> Eben
>> >>
>> >> Sounds good to me.
>> >>
>> >> Thanks for following up,
>> >>      Simon
>> >
>> > There had been some discussions on the max_participants property in the
>> > last days. What we agree on is that the share_button should be made
>> > insensitive when the activity does not provide that functionality. The
>> > API at the moment let's you set max_participants to 1, or just use
>> > sensitive property of the button and set it to false.
>> >
>> > The max_participants property makes sense, when we have more things that
>> > need to change in the UI accordingly, not only the share button. For
>> > example, the invite option in the neighborhood view. Though the shell
>> > can not access that property neither. An option would be to move this
>> > property to the activity.info.
>> > And to give the max_properties a real meaning, we would have to know how
>> > many participants are currently in that activity. To grey it out in the
>> > mesh view, when not more people can join or similar. This request would
>> > need to be made to the PS, not sure if there exist such an option. All
>> > in all I wonder if this would be a needed functionality for 0.86, or if
>> > we should better invest in making collaboration more stable.
>> >
>> > Comments appreciated,
>> >    Simon
>> >
>> >
>>
>> Somewhat tangential, but I don't ac

Re: [Sugar-devel] multiple activity versions installed simultaneously (was Re: [Bugs] #1042 UNSP: cannot install new activity version)

[Eben Eliason]

On Mon, Aug 10, 2009 at 11:52 AM, Benjamin M.
Schwartz wrote:
> Martin Dengler wrote:
>> On Mon, Aug 10, 2009 at 09:26:58PM +0545, Daniel Drake wrote:
>>> 2009/8/10 Tomeu Vizoso :
 Hi,

 any opinions on this?
>>> I dislike the idea of having multiple versions installed at
>>> once. The argument I saw for this case was that different versions
>>> might have incompatibilities in their collaboration protocols.
>>>
>>> Are there other reasons?
>>
>> Learner-generated activity patches, perhaps?  Like, we're under a tree
>> and here's my patched Terminal/Pippy/Speak that you may want to try
>> but not commit to blowing-away your "official" version...
>
> I agree... and this is why we need to have real activity versioning
> support.  The plan has always been to piggyback activity multiversion
> support on top of the datastore's versioning capabilities, and until that
> has landed, in my view, there's not much we can do.

I think I agree with both Ben and Tomeu, here. Supporting multiple
activity versions is crucial to allowing kids to modify activities, or
create their own. At the same time, I also believe that a new owner
(as in the example of modifying the Speak activity under a tree)
should result in a new activity "thread". That is, the resulting
activity would actually be version one of (potentially) many. For this
reason, encouraging a name change when ownership changes might be
apropos.

Eben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Share button in the activity toolbar (from the toolbar redesign thread)

[Eben Eliason]

On Thu, Aug 6, 2009 at 6:56 AM, Simon Schampijer wrote:
> On 07/31/2009 05:14 PM, Eben Eliason wrote:
>>
>> On Fri, Jul 31, 2009 at 8:41 AM, Aleksey Lim
>>  wrote:
>>>
>>> On Fri, Jul 31, 2009 at 02:05:48PM +0200, Tomeu Vizoso wrote:
>>>>
>>>> On Fri, Jul 31, 2009 at 13:47, Simon Schampijer
>>>>  wrote:
>>>>>
>>>>> Another question that came up today:
>>>>>
>>>>> Should the activity toolbar contain the "share" option by default?
>>>>> Disabled by default?
>>>>
>>>> Maybe we could use the max_participants property to know when to
>>>> disable the button?
>>
>> This makes sense to me. I think it's useful to keep it in view to
>> indicate that the activity is private. A non-collaborative activity
>> still has a sharing scope.
>>
>>> So, the question is - what is default value for max_participants :)
>>>
>>> In current code it equals to 0 but old sharing component compares it
>>> with 1 thus share combo is visible by default.
>>
>> An activity that supports 0 participants (or fewer!) sounds pretty
>> useless. Clearly 1 is the logical default for this property.
>>
>>> btw all activities, I've seen before that don't want sharing, hide
>>> share combo by share.props.visible not by max_participants, I guess
>>> it signalizes about not consistency of current implementation where
>>> user can hide/show share button by two different methods.
>>
>> Yup, we should push towards consistency here. I'd bet activities
>> wouldn't bother to hide it if Sugar made it insensitive properly.
>>
>> Eben
>
> So, sounds like max-participants should be set to '1' by default. And we use

Definitely.

> this value to display the sharing option or not.
>
> Or did you mean to display it and make it sensitive/insensitive, Eben?

I think it should always be shown, but made insensitive accordingly
based on max_participants.

Eben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] buddy tags

[Eben Eliason]

On Tue, Aug 4, 2009 at 8:36 PM, Benjamin M.
Schwartz wrote:
> Gary C Martin wrote:
>> Mock-ups amended, they now show self tags in the secondary palette area:
>>
>>       http://wiki.sugarlabs.org/go/Design_Team/Proposals/Buddy_Tags
>
> Why are we calling this section "tags"?
>
> When I look at these mockups, I see a perfect illustration of a "buddy
> profile" [1], like an AIM profile or "away message".  Specifically, the
> mockups appear to preserve the entire string, and not merely provide an
> unordered set of space-delimited strings.
>
> I think this is a "feature".  All you need to do is change the label on
> the entry field from "Tags" to "Profile", and let the search field be a
> full-text search in the profiles.  Users can use their profiles as tags,
> or however they want.

Agreed. I see no reason to enforce a space/comma separated list. I
still kind of like "likes" as the prompt, but something more general
like "profile" could also work.

Eben


> If you want to add tag-specific features like machine-readable tags,
> internationalization, etc., that's fine... but I would make that an
> additional, separate entity from the more flexible Profile.
>
> [1] http://dev.laptop.org/ticket/6686
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] buddy tags

[Eben Eliason]

On Tue, Aug 4, 2009 at 8:21 PM, Gary C Martin wrote:
> On 4 Aug 2009, at 03:16, Gary C Martin wrote:
>
>>> The palette, on the other hand, doesn't work as you've mocked it up.
>>> The primary palette is a fixed height, and only supports single line
>>> primary and secondary titles. I think the tags/description belong in
>>> the secondary palette instead. See
>>> [http://wiki.sugarlabs.org/go/Design_Team/Designs/Activity_Management#03
>>> ]
>>> for a related sketch. We've abandoned the gray background, and we
>>> don't have avatars or structured content as shown here, but I think we
>>> could add a "section" to the secondary palette containing this extra
>>> info. It would expand, but the primary palette would always be a fixed
>>> size.
>>
>> Thanks. I didn't know that. I will amend my mock-ups, should work just
>> as well with that change.
>
>
> Mock-ups amended, they now show self tags in the secondary palette area:
>
>        http://wiki.sugarlabs.org/go/Design_Team/Proposals/Buddy_Tags

Looks good. The more I look at it, the more I think we need to come up
with a good label for this. I keep coming back to the simple but
appropriate "likes" idea. In the settings, we could label the field "I
like:", and in buddy palettes we could have a label "Gary likes:"
which would provide some context for the list. It's also nice because
this short and intuitive label seems to imply a list format, to some
extent.

We should also consider a limit on the entry field, or a way to limit
the amount shown in the palette (probably just an ellipsis).

Eben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] buddy tags

[Eben Eliason]

On Tue, Aug 4, 2009 at 7:44 AM, Gary C Martin wrote:
> On 4 Aug 2009, at 04:54, Eben Eliason wrote:
>
>> On Mon, Aug 3, 2009 at 10:16 PM, Gary C Martin
>> wrote:
>>>
>>> Hi Eben,
>>>
>>> On 4 Aug 2009, at 02:19, Eben Eliason wrote:
>>>
>>>> On Mon, Aug 3, 2009 at 3:39 PM, Gary C Martin
>>>> wrote:
>>>>>
>>>>> On 2 Aug 2009, at 15:00, Tomeu Vizoso wrote:
>>>>>
>>>>>> Hi Gary (and others),
>>>>>>
>>>>>> what was decided about buddy tagging?
>>>>>
>>>>> No one else has commented yet :-(
>>>>
>>>> I had a brief conversation with Christian about this recently. He said
>>>> he'd try to catch up on the thread and maybe give a few comments.
>>>
>>> Fab, that would be great!
>>>
>>>>>> Were you interested in working on it?
>>>>>
>>>>> Yes, I've just added some new mock-ups (keeping them as
>>>>> simple/achievable
>>>>> as
>>>>> possible), so maybe someone else can take a look at them and provide
>>>>> some
>>>>> feedback:
>>>>>
>>>>>      http://wiki.sugarlabs.org/go/Design_Team/Proposals/Buddy_Tags
>>>>
>>>> I think the settings panel looks like a good start. I wonder if we
>>>> should stick with "tags" here, or if it would be worth calling this a
>>>> "description" or "things I like" or something similar.
>>>
>>> Yea, I was playing safe with the input box name. I wanted to avoid
>>> suggesting folks type in a natural language sentence or paragraph. If we
>>> had
>>> tokenised text field support, life here would be easier (and else where
>>> we
>>> want folks to use tags) ;-)
>>>
>>>
>>>  http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Sugar_Interface#Tokenized_Text_Fields
>>>
>>>> The palette, on the other hand, doesn't work as you've mocked it up.
>>>> The primary palette is a fixed height, and only supports single line
>>>> primary and secondary titles. I think the tags/description belong in
>>>> the secondary palette instead. See
>>>>
>>>> [http://wiki.sugarlabs.org/go/Design_Team/Designs/Activity_Management#03]
>>>> for a related sketch. We've abandoned the gray background, and we
>>>> don't have avatars or structured content as shown here, but I think we
>>>> could add a "section" to the secondary palette containing this extra
>>>> info. It would expand, but the primary palette would always be a fixed
>>>> size.
>>>
>>> Thanks. I didn't know that. I will amend my mock-ups, should work just as
>>> well with that change.
>>>
>>>> It might also be nice to have the ability to have a button in one's
>>>> own palette that links directly to the "about me" section of settings
>>>> to change the info. This will also improve discoverability. The
>>>> ability to open the settings to a specific section (and even anchored
>>>> subsection, perhaps) is something we've wanted to expose in many
>>>> places. It might be a nice task for someone looking for a nice
>>>> self-contained feature to build.
>>>
>>> On the fence about this one, I find one's own palette is getting a little
>>> to
>>> long already (My Settings, Logout, Restart, Shutdown, Register).
>>
>> Ugh! "Register" really needs to be dealt with; the fact that it ever
>> entered this menu is frustrating, and it is another long-standing
>> temporary hack that never got fixed. The intended solution for this
>> particluar feature is to represent school servers in the neighborhood;
>> The "Register" action is supposed to be performed on the server, not
>> on "you".
>
> +1 that would be great.
>
>> Isn't "My settings" just "About me" in disguise? Maybe we should just
>> change that string. There's no need to have the same button appear
>> twice in the palette
>
> So just a string change, you'd still end up at the top level of the control
> panel, right?

Oh, no! My mistake. I was thinking that the XO would be an appropriate
place to expose a direct link to the "About me" settings. I wasn't
thinking clearly, and forgot that this was the only way in

Re: [Sugar-devel] buddy tags

[Eben Eliason]

On Mon, Aug 3, 2009 at 10:16 PM, Gary C Martin wrote:
> Hi Eben,
>
> On 4 Aug 2009, at 02:19, Eben Eliason wrote:
>
>> On Mon, Aug 3, 2009 at 3:39 PM, Gary C Martin wrote:
>>>
>>> On 2 Aug 2009, at 15:00, Tomeu Vizoso wrote:
>>>
>>>> Hi Gary (and others),
>>>>
>>>> what was decided about buddy tagging?
>>>
>>> No one else has commented yet :-(
>>
>> I had a brief conversation with Christian about this recently. He said
>> he'd try to catch up on the thread and maybe give a few comments.
>
> Fab, that would be great!
>
>>>> Were you interested in working on it?
>>>
>>> Yes, I've just added some new mock-ups (keeping them as simple/achievable
>>> as
>>> possible), so maybe someone else can take a look at them and provide some
>>> feedback:
>>>
>>>       http://wiki.sugarlabs.org/go/Design_Team/Proposals/Buddy_Tags
>>
>> I think the settings panel looks like a good start. I wonder if we
>> should stick with "tags" here, or if it would be worth calling this a
>> "description" or "things I like" or something similar.
>
> Yea, I was playing safe with the input box name. I wanted to avoid
> suggesting folks type in a natural language sentence or paragraph. If we had
> tokenised text field support, life here would be easier (and else where we
> want folks to use tags) ;-)
>
>  http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Sugar_Interface#Tokenized_Text_Fields
>
>> The palette, on the other hand, doesn't work as you've mocked it up.
>> The primary palette is a fixed height, and only supports single line
>> primary and secondary titles. I think the tags/description belong in
>> the secondary palette instead. See
>> [http://wiki.sugarlabs.org/go/Design_Team/Designs/Activity_Management#03]
>> for a related sketch. We've abandoned the gray background, and we
>> don't have avatars or structured content as shown here, but I think we
>> could add a "section" to the secondary palette containing this extra
>> info. It would expand, but the primary palette would always be a fixed
>> size.
>
> Thanks. I didn't know that. I will amend my mock-ups, should work just as
> well with that change.
>
>> It might also be nice to have the ability to have a button in one's
>> own palette that links directly to the "about me" section of settings
>> to change the info. This will also improve discoverability. The
>> ability to open the settings to a specific section (and even anchored
>> subsection, perhaps) is something we've wanted to expose in many
>> places. It might be a nice task for someone looking for a nice
>> self-contained feature to build.
>
> On the fence about this one, I find one's own palette is getting a little to
> long already (My Settings, Logout, Restart, Shutdown, Register).

Ugh! "Register" really needs to be dealt with; the fact that it ever
entered this menu is frustrating, and it is another long-standing
temporary hack that never got fixed. The intended solution for this
particluar feature is to represent school servers in the neighborhood;
The "Register" action is supposed to be performed on the server, not
on "you".

Isn't "My settings" just "About me" in disguise? Maybe we should just
change that string. There's no need to have the same button appear
twice in the palette. I suppose there's no ridding of 'Logout",
"Restart", and "Shutdown". =)

> Hmmm, random thought. Should clicking on your buddy icon open "My Settings"
> as the default operation? Right now it's just a pretty picture with a
> palette hanging off it. That way you'd just click your buddy icon and pick
> "About Me", avoiding all those nasty techie strings.

That's an interesting idea, though if the button is in the palette,
that might be enough. I might instead suggest as a global rule that
clicking on a buddy should reveal the (full) palette by default.

Eben


>>> Though I'm not sure I have the stamina to get past your code reviews for
>>> any
>>> original coding. It's hard enough to get a bug fix r+ accepted when
>>> making a
>>> minimal tweak to existing code! ;-)
>>>
>>>> From the last Sugar releases tags are broadcasted along the rest of
>>>> the buddy info when using gabble. Was it decided that we also needed
>>>> tags in Salut for 0.86? Or it could come in a later stage?
>>>
>>>
>>> Not knowing the

Re: [Sugar-devel] buddy tags

[Eben Eliason]

On Mon, Aug 3, 2009 at 3:39 PM, Gary C Martin wrote:
> On 2 Aug 2009, at 15:00, Tomeu Vizoso wrote:
>
>> Hi Gary (and others),
>>
>> what was decided about buddy tagging?
>
> No one else has commented yet :-(

I had a brief conversation with Christian about this recently. He said
he'd try to catch up on the thread and maybe give a few comments.

>> Were you interested in working on it?
>
> Yes, I've just added some new mock-ups (keeping them as simple/achievable as
> possible), so maybe someone else can take a look at them and provide some
> feedback:
>
>        http://wiki.sugarlabs.org/go/Design_Team/Proposals/Buddy_Tags

I think the settings panel looks like a good start. I wonder if we
should stick with "tags" here, or if it would be worth calling this a
"description" or "things I like" or something similar.

The palette, on the other hand, doesn't work as you've mocked it up.
The primary palette is a fixed height, and only supports single line
primary and secondary titles. I think the tags/description belong in
the secondary palette instead. See
[http://wiki.sugarlabs.org/go/Design_Team/Designs/Activity_Management#03]
for a related sketch. We've abandoned the gray background, and we
don't have avatars or structured content as shown here, but I think we
could add a "section" to the secondary palette containing this extra
info. It would expand, but the primary palette would always be a fixed
size.

It might also be nice to have the ability to have a button in one's
own palette that links directly to the "about me" section of settings
to change the info. This will also improve discoverability. The
ability to open the settings to a specific section (and even anchored
subsection, perhaps) is something we've wanted to expose in many
places. It might be a nice task for someone looking for a nice
self-contained feature to build.

> Though I'm not sure I have the stamina to get past your code reviews for any
> original coding. It's hard enough to get a bug fix r+ accepted when making a
> minimal tweak to existing code! ;-)
>
>> From the last Sugar releases tags are broadcasted along the rest of
>> the buddy info when using gabble. Was it decided that we also needed
>> tags in Salut for 0.86? Or it could come in a later stage?
>
>
> Not knowing the amount of work involved I can't really make a call. My last
> comment is best I can make:
>
> "Well ejabberd was definitely the first to have solved as it represents a
> solution for a more dispersed community, less likely to know about the
> others. But having both [gabble + salut] would obviously be much more
> consistent.– If you told me 'journal grid view' won't happen, or tool bar
> 'stop' always visible won't happen, or 'ad-hoc wirless networks' won't
> happen, or 'tags under Journal titles' won't happen, or 'Metacity layering
> issue will persist',– then I'd say let salut slip to 0.88."

I agree. I think I'd sooner have basic buddy self-tagging working in
both scenarios than have tagging of others (pseudo groups) in one or
the other, though.

> I was also hoping to get some feedback on the first boot experience if
> anyone has a strong opinion:
>
> "I really do like the simple 'first' boot experience, pick colours, enter
> name, and your are done! Great! What do folks think about exposing an
> optional self tag prompt at this point? Wording is going to be tough, and
> would likely need some prompting example tags. As a challenge, feel free to
> reply with some single word tag lists you might assign to yourself..."

I'm not sure it's necessary to do this. the more streamlined this
process is (and the less description/guidance needed) the better. I
think that adding this info could be part of a first day lesson, if
it's something that instructors wanted to emphasize.

Eben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Erase in the Ring and less hot hot corners

[Eben Eliason]

On Mon, Aug 3, 2009 at 8:37 PM, Gary C Martin wrote:
> On 4 Aug 2009, at 00:26, Caroline Meeks wrote:
>
>> +1 to taking erase out of the activity ring.  We need to keep that
>> view as simple as possible for the youngest children.  Moving the
>> mouse is a challenge for the youngest kids, fewer targets with less
>> that can go wrong is a big win.

Sounds fine to me.

> Filed:
>
>        http://dev.sugarlabs.org/ticket/1128
>
>> I think I'm also a +1 on the less hot hot corners.  I definitely see
>> issues with getting the frame unintentionally.  But that seems like
>> a choice with more tradeoffs.
>
> Can we hold off the Frame wars for just now ;-)

=)

We could, perhaps, agree to increase the default delay for corner
activation, since this is configurable in settings. Alternatively,
this should be configurable for specific distributions, I believe.

I've always been comfortable with about .25 seconds, but perhaps those
who work with kids will have a better idea, given their motor skills,
what a reasonable delay might be. I wouldn't go much beyond .5
seconds, in any case, since discoverability is still important.

Eben

> Regards,
> --Gary
>
>> On Mon, Aug 3, 2009 at 7:13 PM, James Cameron 
>> wrote:
>> On Tue, Aug 04, 2009 at 01:22:35AM +0545, Christoph Derndorfer wrote:
>> > e.g. here in Nepal they [...] removed the 'Remove' option from the
>> > activities menu in Home View (so activities can only be truly
>> removed
>> > from the List View).
>>
>> I confirm that with the children I test on, using OLPC build 802, they
>> lose activities from the ring as a result of accidental mouse
>> movements.
>> After a few hours though they don't do it.
>>
>> --
>> James Cameron
>> http://quozl.linux.org.au/
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>> --
>> Caroline Meeks
>> Solution Grove
>> carol...@solutiongrove.com
>>
>> 617-500-3488 - Office
>> 505-213-3268 - Fax
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Share button in the activity toolbar (from the toolbar redesign thread)

[Eben Eliason]

On Fri, Jul 31, 2009 at 8:41 AM, Aleksey Lim wrote:
> On Fri, Jul 31, 2009 at 02:05:48PM +0200, Tomeu Vizoso wrote:
>> On Fri, Jul 31, 2009 at 13:47, Simon Schampijer wrote:
>> > Another question that came up today:
>> >
>> > Should the activity toolbar contain the "share" option by default?
>> > Disabled by default?
>>
>> Maybe we could use the max_participants property to know when to
>> disable the button?

This makes sense to me. I think it's useful to keep it in view to
indicate that the activity is private. A non-collaborative activity
still has a sharing scope.

> So, the question is - what is default value for max_participants :)
>
> In current code it equals to 0 but old sharing component compares it
> with 1 thus share combo is visible by default.

An activity that supports 0 participants (or fewer!) sounds pretty
useless. Clearly 1 is the logical default for this property.

> btw all activities, I've seen before that don't want sharing, hide
> share combo by share.props.visible not by max_participants, I guess
> it signalizes about not consistency of current implementation where
> user can hide/show share button by two different methods.

Yup, we should push towards consistency here. I'd bet activities
wouldn't bother to hide it if Sugar made it insensitive properly.

Eben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Initial implementation of toolbars design

[Eben Eliason]

On Thu, Jul 30, 2009 at 9:21 PM, Gary C Martin wrote:
> On 30 Jul 2009, at 20:46, Simon Schampijer wrote:
>
>> On 07/29/2009 07:03 PM, Gary C Martin wrote:
>>>
>>> Sorry if that wasn't clear. Activity icon and stop icon are essential.
>>> The Activity icon is going to be critical for identifying what activity
>>> you are in at a glance, especially if the actual title name is hidden
>>> away in a sub toolbar. A downside if we loose the title in the primary
>>> toolbar is reinforcement of knowing what activity you are in (say you
>>> are copy/pasting between two similar Write documents)...
>>
>> Ok, thanks for the explanation. The differentiation of the running
>> instance of two activities of the same type is a good point. But, does this
>> happen often? I guess many kids will run one activity of each type at a
>> time, and remember performance constraints ;p And one can use the frame to
>> distinguish the activities.
>
> OK, next nit pick (apologise as it is clearly a design oversight not
> implementation issue).
>
> Are we suggesting we make all the lovely, really simple, Activities (the
> ones who have managed to avoid tabs and just a "title", "keep", "stop", and
> perhaps sharing) now show a 95% empty top bar (with just the activity icon
> at one end and the stop over at the other). And require popping up and
> potentially adjusting the canvas sizes to fit the Activity sub toolbar? Just
> did a very (very) quick/rough dig through.

That's an interesting question. I'll have to take a look at some of
these activities. I actually find it odd that so many wouldn't have
any use for buttons or other controls. Perhaps a number of them are
revealing these controls in the canvas below instead of using
toolbars?

For what it's worth, I have always found it a bit odd when activities
embed their own custom controls amidst the cross-activity controls.
Perhaps we could institute a rule by which the primary toolbar will BE
the only toolbar (not a toolbar button) if and only if the activity
adds no toolbar controls at all. If, on the other hand, the activity
wants their own controls, these would appear in the primary toolbar to
the right of the activity icon.

> Pippy (though we could finally move "run" and "stop" into the toolbar).

That would be great!

> Maze
> IRC
> Chat
> Typing Turtle
> EToys (has title, sharing, keep, stop, and other buttons, )

Etoys has always behaved slightly differently since it's not using GTK.

> Most (all?) of every MaMaMedia (Slider Puzzle, Jigsaw Puzzle, Poll builder,
> Story builder Joke Machine, etc...)
>
> et al...
>
> Ideally I'd like to see an activity icon, and its journal title appearing,
> so you have the best chance of knowing 'what' you are currently looking at.
>
> OT: Activity icon followed by title makes an activity instance look like the
> Journal entry row it came from, which would be a good thing, but I couldn't
> find a reliable design for that formula.
>
>> Personally, I see more the issue of naming an activity, since as said in
>> another post I am not really convinced about the naming alert.
>
> I know what you mean. I did wonder once if a modal activity alert style
> pop-up, below the activity toolbar, would be less intrusive, and more in
> context with the activity than a pop-up dialogue that hides most of the
> Activity context.

That's a possibility, but as a general rule those alert "bars" are
non-modal. However, clearly any naming alert when stopping the
activity must be modal, since it needs to prevent the action from
taking place until the dialog is settled.

>> One little thing I am a bit worried about, is that we miss labels for the
>> sub-toolbars. I hope the icons are meaningful enough for the users - but
>> then labels can be misleading as well, and many of our users can't possibly
>> read.
>
> +1
>
> Extremely good icons are essential or else WE FAIL and walk backwards here.
> :-( At least this is something we can iterate on before the 0.86 official
> release that gets documented and pushed out to deployments.

Yup. I think providing a fairly extensive set of default icons would
be a good thing, both to help activity developers out, and for
consistency in the UI. I'd be happy to help out with this. It would
also be nice to extend the default icon set further in general. There
are lots of common icons that we should be providing, for the same
reasons as above, that just never made it. I have a list, and perhaps
many even designed already, somewhere.

>> About alignment (attached is a snapshot), should we align the 'share
>> button' and the 'keep one' to the left that the way to get to this button is
>> not so long, when revealing the toolbar?
>
> My vote is for no right align. Put those icons (share with, keep) left
> aligned near any other icons (perhaps a tag feature can show here in
> future). My main concern here would be for a child trying to drive the mouse
> all the way over from the far left of the display, to the far right to hit a
> target.

Ag

Re: [Sugar-devel] Initial implementation of toolbars design

[Eben Eliason]

On Thu, Jul 30, 2009 at 10:28 PM, Aleksey Lim wrote:
> On Thu, Jul 30, 2009 at 06:02:00PM -0400, Eben Eliason wrote:
>> On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijer wrote:
>> > On 07/29/2009 07:03 PM, Gary C Martin wrote:
>> >>
>> >> Hi Simon,
>> >>
>> >> On 29 Jul 2009, at 08:55, Simon Schampijer wrote:
>> >>
>> >>>> FWIW: Picking the top level tool set is going to be a real tough call in
>> >>>> a number of cases as we loose toolbar space for each extra tab, plus the
>> >>>> activity icon on far left (essential for Activity recognition), plus the
>> >>>> stop icon on far right (essential, no questions, no doubts). The
>> >>>> features that actually fit in the remaining space may seem quite an
>> >>>> arbitrary hotchpotch.
>> >>>
>> >>> Gary, I am not sure I get your arguments right :/ Can you elaborate?
>> >>> What I conclude of all the answers, I think that space in the primary
>> >>> toolbar is an issue. So we need to decide what to put there. Does
>> >>> activity icon and stop icon sounds good to you as well?
>> >>
>> >> Sorry if that wasn't clear. Activity icon and stop icon are essential.
>> >> The Activity icon is going to be critical for identifying what activity
>> >> you are in at a glance, especially if the actual title name is hidden
>> >> away in a sub toolbar. A downside if we loose the title in the primary
>> >> toolbar is reinforcement of knowing what activity you are in (say you
>> >> are copy/pasting between two similar Write documents)...
>> >
>> > Ok, thanks for the explanation. The differentiation of the running instance
>> > of two activities of the same type is a good point. But, does this happen
>> > often? I guess many kids will run one activity of each type at a time, and
>> > remember performance constraints ;p And one can use the frame to 
>> > distinguish
>> > the activities.
>> >
>> > Personally, I see more the issue of naming an activity, since as said in
>> > another post I am not really convinced about the naming alert.
>>
>> I'll have to think about this idea more, but: we could also have the
>> naming "alert" appear as a palette attached to the stop button,
>> instead. It doesn't change the behavior too much (it requires 2 clicks
>> to stop an activity for the first time if it hasn't been named), but
>> the use of the palette might feel more consistent with Sugar in
>> general. On the other hand, it could be strange to change the behavior
>> of the stop button between the first and other cases.
>>
>> > One little thing I am a bit worried about, is that we miss labels for the
>> > sub-toolbars. I hope the icons are meaningful enough for the users - but
>> > then labels can be misleading as well, and many of our users can't possibly
>> > read.
>>
>> Yes, we had some thoughts. We'll hash it out some more.
>>
>> > About alignment (attached is a snapshot), should we align the 'share 
>> > button'
>> > and the 'keep one' to the left that the way to get to this button is not so
>> > long, when revealing the toolbar?
>>
>> I think we should be thinking about this in the general case.
>> Sometimes one will need to reach the other end to reach controls (and
>> (though not for the activity toolbar) this depends on where the
>> toolbar button sits within the primary toolbar). We should make sure
>> that the palette behavior works well in these instances. For instance,
>> it shouldn't disappear immediately on mouse-leave. Perhaps the delay
>> should be longer than for normal palettes, due to their peculiar
>> dimensions.
>>
>> That said, I'd be fine with aligning these buttons to the left in this 
>> instance.
>>
>> Eben
>>
>> PS a few notes on the design:
>>
>> 1. Is this screenshot showing the hover state of the toolbar button
>> with the toolbar already locked in?
>
> Nope, in current implementation there is no way to open hover palette
> if toolbar is locked in

OK, then the arrow should still be pointing down at this point,
indicating that clicking the button will lock it in place below. Once
locked in, it changes directions to point up indicating that a second
click will close it. Refer to:
http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars#06

>> If not, the small arrow beneath
>> the activity i

Re: [Sugar-devel] Initial implementation of toolbars design

[Eben Eliason]

On Thu, Jul 30, 2009 at 10:07 PM, Gary C Martin wrote:
> Hi Eben,
>
> On 31 Jul 2009, at 01:18, Eben Eliason wrote:
>
>> Here are the icons we used for the view, edit, and color toolbars,
>> Sugarized of course. If anyone has suggestions for other common
>> toolbars across activities that deserve icons in artwork, let me know.
>> Eben
>
> "Share with:" is one, unless you're OK with one of the ones I knocked up,
> though if it's on a secondary palette and primary space isn't anymore an
> issue, then the full text menu can stay (and make the Activity palette less
> empty):
>
>        http://wiki.sugarlabs.org/go/File:Toolbar_mockup_gary_share_with.png
>
>  http://wiki.sugarlabs.org/go/File:Toolbar_mockup_gary_share_with_v2.png

I think the sharing scope should be indicated by the corresponding
zoom level icons. It might be worth keeping the dropdown once we have
proper group support, since the name of the group is important and not
communicated by the icon itself.

Eben

> Regards,
> --Gary
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Initial implementation of toolbars design

[Eben Eliason]

Here are the icons we used for the view, edit, and color toolbars,
Sugarized of course. If anyone has suggestions for other common
toolbars across activities that deserve icons in artwork, let me know.
Eben

On Thu, Jul 30, 2009 at 6:02 PM, Eben Eliason wrote:
> On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijer wrote:
>> On 07/29/2009 07:03 PM, Gary C Martin wrote:
>>>
>>> Hi Simon,
>>>
>>> On 29 Jul 2009, at 08:55, Simon Schampijer wrote:
>>>
>>>>> FWIW: Picking the top level tool set is going to be a real tough call in
>>>>> a number of cases as we loose toolbar space for each extra tab, plus the
>>>>> activity icon on far left (essential for Activity recognition), plus the
>>>>> stop icon on far right (essential, no questions, no doubts). The
>>>>> features that actually fit in the remaining space may seem quite an
>>>>> arbitrary hotchpotch.
>>>>
>>>> Gary, I am not sure I get your arguments right :/ Can you elaborate?
>>>> What I conclude of all the answers, I think that space in the primary
>>>> toolbar is an issue. So we need to decide what to put there. Does
>>>> activity icon and stop icon sounds good to you as well?
>>>
>>> Sorry if that wasn't clear. Activity icon and stop icon are essential.
>>> The Activity icon is going to be critical for identifying what activity
>>> you are in at a glance, especially if the actual title name is hidden
>>> away in a sub toolbar. A downside if we loose the title in the primary
>>> toolbar is reinforcement of knowing what activity you are in (say you
>>> are copy/pasting between two similar Write documents)...
>>
>> Ok, thanks for the explanation. The differentiation of the running instance
>> of two activities of the same type is a good point. But, does this happen
>> often? I guess many kids will run one activity of each type at a time, and
>> remember performance constraints ;p And one can use the frame to distinguish
>> the activities.
>>
>> Personally, I see more the issue of naming an activity, since as said in
>> another post I am not really convinced about the naming alert.
>
> I'll have to think about this idea more, but: we could also have the
> naming "alert" appear as a palette attached to the stop button,
> instead. It doesn't change the behavior too much (it requires 2 clicks
> to stop an activity for the first time if it hasn't been named), but
> the use of the palette might feel more consistent with Sugar in
> general. On the other hand, it could be strange to change the behavior
> of the stop button between the first and other cases.
>
>> One little thing I am a bit worried about, is that we miss labels for the
>> sub-toolbars. I hope the icons are meaningful enough for the users - but
>> then labels can be misleading as well, and many of our users can't possibly
>> read.
>
> Yes, we had some thoughts. We'll hash it out some more.
>
>> About alignment (attached is a snapshot), should we align the 'share button'
>> and the 'keep one' to the left that the way to get to this button is not so
>> long, when revealing the toolbar?
>
> I think we should be thinking about this in the general case.
> Sometimes one will need to reach the other end to reach controls (and
> (though not for the activity toolbar) this depends on where the
> toolbar button sits within the primary toolbar). We should make sure
> that the palette behavior works well in these instances. For instance,
> it shouldn't disappear immediately on mouse-leave. Perhaps the delay
> should be longer than for normal palettes, due to their peculiar
> dimensions.
>
> That said, I'd be fine with aligning these buttons to the left in this 
> instance.
>
> Eben
>
> PS a few notes on the design:
>
> 1. Is this screenshot showing the hover state of the toolbar button
> with the toolbar already locked in? If not, the small arrow beneath
> the activity icon should still be pointed downwards, to indicate that
> clicking on the button will lock it into place. It should appear
> pointing upward only when already locked in.
>
> 2. We should fix the style for the text entry so it appears correctly
> on black backgrounds.
>
> 3. I'll get you those scissors tonight, for real this time. Also, can
> we change the arrow to match those in the mockups? The one shown here
> competes with the icons themselves.
>
> 4. But these are nitpicks. Fantastic work!!
>
>
>> Thanks,
>>   Simon
>>
>
<><><>___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Initial implementation of toolbars design

[Eben Eliason]

On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijer wrote:
> On 07/29/2009 07:03 PM, Gary C Martin wrote:
>>
>> Hi Simon,
>>
>> On 29 Jul 2009, at 08:55, Simon Schampijer wrote:
>>
 FWIW: Picking the top level tool set is going to be a real tough call in
 a number of cases as we loose toolbar space for each extra tab, plus the
 activity icon on far left (essential for Activity recognition), plus the
 stop icon on far right (essential, no questions, no doubts). The
 features that actually fit in the remaining space may seem quite an
 arbitrary hotchpotch.
>>>
>>> Gary, I am not sure I get your arguments right :/ Can you elaborate?
>>> What I conclude of all the answers, I think that space in the primary
>>> toolbar is an issue. So we need to decide what to put there. Does
>>> activity icon and stop icon sounds good to you as well?
>>
>> Sorry if that wasn't clear. Activity icon and stop icon are essential.
>> The Activity icon is going to be critical for identifying what activity
>> you are in at a glance, especially if the actual title name is hidden
>> away in a sub toolbar. A downside if we loose the title in the primary
>> toolbar is reinforcement of knowing what activity you are in (say you
>> are copy/pasting between two similar Write documents)...
>
> Ok, thanks for the explanation. The differentiation of the running instance
> of two activities of the same type is a good point. But, does this happen
> often? I guess many kids will run one activity of each type at a time, and
> remember performance constraints ;p And one can use the frame to distinguish
> the activities.
>
> Personally, I see more the issue of naming an activity, since as said in
> another post I am not really convinced about the naming alert.

I'll have to think about this idea more, but: we could also have the
naming "alert" appear as a palette attached to the stop button,
instead. It doesn't change the behavior too much (it requires 2 clicks
to stop an activity for the first time if it hasn't been named), but
the use of the palette might feel more consistent with Sugar in
general. On the other hand, it could be strange to change the behavior
of the stop button between the first and other cases.

> One little thing I am a bit worried about, is that we miss labels for the
> sub-toolbars. I hope the icons are meaningful enough for the users - but
> then labels can be misleading as well, and many of our users can't possibly
> read.

Yes, we had some thoughts. We'll hash it out some more.

> About alignment (attached is a snapshot), should we align the 'share button'
> and the 'keep one' to the left that the way to get to this button is not so
> long, when revealing the toolbar?

I think we should be thinking about this in the general case.
Sometimes one will need to reach the other end to reach controls (and
(though not for the activity toolbar) this depends on where the
toolbar button sits within the primary toolbar). We should make sure
that the palette behavior works well in these instances. For instance,
it shouldn't disappear immediately on mouse-leave. Perhaps the delay
should be longer than for normal palettes, due to their peculiar
dimensions.

That said, I'd be fine with aligning these buttons to the left in this instance.

Eben

PS a few notes on the design:

1. Is this screenshot showing the hover state of the toolbar button
with the toolbar already locked in? If not, the small arrow beneath
the activity icon should still be pointed downwards, to indicate that
clicking on the button will lock it into place. It should appear
pointing upward only when already locked in.

2. We should fix the style for the text entry so it appears correctly
on black backgrounds.

3. I'll get you those scissors tonight, for real this time. Also, can
we change the arrow to match those in the mockups? The one shown here
competes with the icons themselves.

4. But these are nitpicks. Fantastic work!!


> Thanks,
>   Simon
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Initial implementation of toolbars design

[Eben Eliason]

On Tue, Jul 28, 2009 at 10:12 PM, Gary C Martin wrote:
> On 28 Jul 2009, at 19:03, Eben Eliason wrote:
>
>> On Tue, Jul 28, 2009 at 12:07 PM, Simon Schampijer
>> wrote:
>>>
>>> On 07/28/2009 03:48 PM, Eben Eliason wrote:
>>>>
>>>> On Mon, Jul 27, 2009 at 5:26 PM, Simon Schampijer
>>>>  wrote:
>>>>>
>>>>> On 07/18/2009 04:17 AM, Gary C Martin wrote:
>>>>>>
>>>>>> Hi Caroline,
>>>>>>
>>>>>> On 17 Jul 2009, at 22:14, Caroline Meeks wrote:
>>>>>>
>>>>>>> We can put it in front of actual kids once you get a sample working.
>>>>>>> We could even try playing the video for our existing classes. I don't
>>>>>>> know if they'll be able to give you feedback from just seeing the
>>>>>>> video. Might be interesting to find out.
>>>>>>
>>>>>> Yes that's an interesting one... I have more understanding of
>>>>>> usability
>>>>>> studies with literate adults, where you can have a controlled
>>>>>> environment. With the idea that you set goals/tasks to be completed
>>>>>> with
>>>>>> the interface and ask the user to vocalise what they think they are
>>>>>> doing ("I'm clicking this because I think it's the search button...").
>>>>>> You only interact with them once they are clearly stuck, to help them
>>>>>> get back on track. Asking for any-ones opinion is usually frowned upon
>>>>>> in usability studies, as opinion is almost always different from
>>>>>> actual
>>>>>> behaviour – but some opinions are better than nothing, which is why I
>>>>>> keep asking :-)
>>>>>>
>>>>>> Perhaps I should work with Walter and Aleksey's initial toolbar code
>>>>>> and
>>>>>> make an identical test clone of TA but with the new toolbar design (I
>>>>>> can use Aleksey's Write mock-up code as an example)? Then you could
>>>>>> let
>>>>>> the class (or a random selection of the class) use it for some tasks
>>>>>> and
>>>>>> watch how well (or not) they manage with the new interface?
>>>>>>
>>>>>> Simon: have you used TA yet in your lessons?
>>>>>
>>>>> Yes, the problem is, that I won't get into class before September again
>>>>> -
>>>>> we
>>>>> have summer holidays :/
>>>>>
>>>>> About the design - as already noted, the current implementation does
>>>>> not
>>>>> match gary's mockups. I think the mockups are more consistent in using
>>>>> icons
>>>>> in the primary toolbar. Having the text entry field (activity name)
>>>>> present,
>>>>> could help the users that know Sugar already. They would not feel that
>>>>> much
>>>>> lost.
>>>>
>>>> I think that the title, sharing, keep, and other buttons (perhaps with
>>>> the exception of stop, since I know many want this on the primary
>>>> toolbar...) should live inside a secondary "activity toolbar", in much
>>>> the same way we have an activity tab now. The icon for the activity
>>>> toolbar would be the activity icon itself, colored, and always placed
>>>> at the far left of the primary toolbar.
>>>>
>>>> The primary reasons for this are 1) consistency across activities and
>>>> 2) saving space in the primary toolbar for the activity itself.
>>>
>>> Hmm, giving a title could be seen as a "first class" action. We want the
>>> user to give a title (naming alert), so it can be found more easily in
>>> the
>>> journal. Maybe this should be in the top toolbar as well? I know this has
>>> issues space wise.
>>
>> It's true, but those buttons consume a lot of valuable real estate in
>> the primary toolbar, and the user is unlikely to name or share more
>> than once, and should never really need to keep manually. That means
>> that about half of the ever-present controls shown aren't important
>> for regular use of the activity.
>
> With my ActivityTeam hat on; you do realise this is the option requiring the
> most rework for authors and maintainers? It puts them/us back

Re: [Sugar-devel] Initial implementation of toolbars design

[Eben Eliason]

On Tue, Jul 28, 2009 at 12:07 PM, Simon Schampijer wrote:
> On 07/28/2009 03:48 PM, Eben Eliason wrote:
>>
>> On Mon, Jul 27, 2009 at 5:26 PM, Simon Schampijer
>>  wrote:
>>>
>>> On 07/18/2009 04:17 AM, Gary C Martin wrote:
>>>>
>>>> Hi Caroline,
>>>>
>>>> On 17 Jul 2009, at 22:14, Caroline Meeks wrote:
>>>>
>>>>> We can put it in front of actual kids once you get a sample working.
>>>>> We could even try playing the video for our existing classes. I don't
>>>>> know if they'll be able to give you feedback from just seeing the
>>>>> video. Might be interesting to find out.
>>>>
>>>> Yes that's an interesting one... I have more understanding of usability
>>>> studies with literate adults, where you can have a controlled
>>>> environment. With the idea that you set goals/tasks to be completed with
>>>> the interface and ask the user to vocalise what they think they are
>>>> doing ("I'm clicking this because I think it's the search button...").
>>>> You only interact with them once they are clearly stuck, to help them
>>>> get back on track. Asking for any-ones opinion is usually frowned upon
>>>> in usability studies, as opinion is almost always different from actual
>>>> behaviour – but some opinions are better than nothing, which is why I
>>>> keep asking :-)
>>>>
>>>> Perhaps I should work with Walter and Aleksey's initial toolbar code and
>>>> make an identical test clone of TA but with the new toolbar design (I
>>>> can use Aleksey's Write mock-up code as an example)? Then you could let
>>>> the class (or a random selection of the class) use it for some tasks and
>>>> watch how well (or not) they manage with the new interface?
>>>>
>>>> Simon: have you used TA yet in your lessons?
>>>
>>> Yes, the problem is, that I won't get into class before September again -
>>> we
>>> have summer holidays :/
>>>
>>> About the design - as already noted, the current implementation does not
>>> match gary's mockups. I think the mockups are more consistent in using
>>> icons
>>> in the primary toolbar. Having the text entry field (activity name)
>>> present,
>>> could help the users that know Sugar already. They would not feel that
>>> much
>>> lost.
>>
>> I think that the title, sharing, keep, and other buttons (perhaps with
>> the exception of stop, since I know many want this on the primary
>> toolbar...) should live inside a secondary "activity toolbar", in much
>> the same way we have an activity tab now. The icon for the activity
>> toolbar would be the activity icon itself, colored, and always placed
>> at the far left of the primary toolbar.
>>
>> The primary reasons for this are 1) consistency across activities and
>> 2) saving space in the primary toolbar for the activity itself.
>
> Hmm, giving a title could be seen as a "first class" action. We want the
> user to give a title (naming alert), so it can be found more easily in the
> journal. Maybe this should be in the top toolbar as well? I know this has
> issues space wise.

It's true, but those buttons consume a lot of valuable real estate in
the primary toolbar, and the user is unlikely to name or share more
than once, and should never really need to keep manually. That means
that about half of the ever-present controls shown aren't important
for regular use of the activity.

One alternative is to start activities with the activity toolbar shown
beneath the primary toolbar, but again that would mostly just serve
for naming. I hesitate to do this, since I'd much rather, again, allow
the activity to decide if it wants a secondary toolbar to be shown by
default. For instance, I think Paint should show the secondary color
selector toolbar by default, so that both colors and the basic drawing
tools are visible when entering the activity.
(http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars#11)

I think the current naming alert behavior is probably sufficient,
unless feedback indicates that it's not helping in practice.


> In any case, would be nice to sort this one out sooner then later. We want
> to push a first version on Thursday, that people can test the redesign out -
> ideally in class. Feature Freeze is approaching:
> http://wiki.sugarlabs.org/go/0.86/Roadmap#Schedule

OK, time is tight! Christian any thoughts?

>>> Can we get mockups for Browse? I would do the cha

Re: [Sugar-devel] Initial implementation of toolbars design

[Eben Eliason]

On Mon, Jul 27, 2009 at 5:26 PM, Simon Schampijer wrote:
> On 07/18/2009 04:17 AM, Gary C Martin wrote:
>>
>> Hi Caroline,
>>
>> On 17 Jul 2009, at 22:14, Caroline Meeks wrote:
>>
>>> We can put it in front of actual kids once you get a sample working.
>>> We could even try playing the video for our existing classes. I don't
>>> know if they'll be able to give you feedback from just seeing the
>>> video. Might be interesting to find out.
>>
>> Yes that's an interesting one... I have more understanding of usability
>> studies with literate adults, where you can have a controlled
>> environment. With the idea that you set goals/tasks to be completed with
>> the interface and ask the user to vocalise what they think they are
>> doing ("I'm clicking this because I think it's the search button...").
>> You only interact with them once they are clearly stuck, to help them
>> get back on track. Asking for any-ones opinion is usually frowned upon
>> in usability studies, as opinion is almost always different from actual
>> behaviour – but some opinions are better than nothing, which is why I
>> keep asking :-)
>>
>> Perhaps I should work with Walter and Aleksey's initial toolbar code and
>> make an identical test clone of TA but with the new toolbar design (I
>> can use Aleksey's Write mock-up code as an example)? Then you could let
>> the class (or a random selection of the class) use it for some tasks and
>> watch how well (or not) they manage with the new interface?
>>
>> Simon: have you used TA yet in your lessons?
>
> Yes, the problem is, that I won't get into class before September again - we
> have summer holidays :/
>
> About the design - as already noted, the current implementation does not
> match gary's mockups. I think the mockups are more consistent in using icons
> in the primary toolbar. Having the text entry field (activity name) present,
> could help the users that know Sugar already. They would not feel that much
> lost.

I think that the title, sharing, keep, and other buttons (perhaps with
the exception of stop, since I know many want this on the primary
toolbar...) should live inside a secondary "activity toolbar", in much
the same way we have an activity tab now. The icon for the activity
toolbar would be the activity icon itself, colored, and always placed
at the far left of the primary toolbar.

The primary reasons for this are 1) consistency across activities and
2) saving space in the primary toolbar for the activity itself.

> Can we get mockups for Browse? I would do the changes then there.

We have them! Browse was the first activity I worked with when working
up the new toolbar designs. The activity icon I spoke of above is
notable absent from my early mockups, but that shouldn't have much of
an effect on things. Here they are:

http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars

> When doing testing we should maybe do tests for people that have used Sugar
> before already, and probands with no knowledge of Sugar at all.
>
> Regards,
>   Simon
>
> Btw: I was lost a bit with that the canvas is only shifted down when the
> toolbar is locked. But I guess it makes sense, in order to have not shifting
> the canvas down when you search for an option and pulling down the different
> toolbars. Not sure, yet.

Yes, this is by design. The theory here is that it's possible to use
them like palettes, for occasional actions, without locking into place
and changing the canvas. I suppose the effect could be a little
strange when they become locked, but I'd suspect it would be even
stranger to have the canvas constantly shifting back and forth while
hovering over toolbar buttons.

Eben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Buddy Tagging (Was: GPA Goals Status)

[Eben Eliason]

On Sat, Jul 25, 2009 at 11:35 PM, Gary C Martin wrote:
> Hi Eben,
>
> On 25 Jul 2009, at 16:26, Eben Eliason wrote:
>
>> On Sat, Jul 25, 2009 at 10:59 AM, Gary C Martin
>> wrote:
>>>
>>> If you can find your previous group mock-ups, that would be great (been
>>> googling, wiki searching, and Spotlighting my email but haven't found
>>> them
>>> yet).
>>
>> Will do. I'll post them before the weekend is out.
>
> Cool.

I've posted my earlier sketches to the Groups proposal page [1], along
with comments on the ideas illustrated, and some thoughts relating
them to Gary's designs. I also want to pose the question (as stated in
the intro to my mockups): How do we use local group tagging as a
stepping stone to open/closed groups?

Eben

[1] http://wiki.sugarlabs.org/go/Design_Team/Proposals/Groups
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Book bundles and Read

[Eben Eliason]

On Sun, Jul 26, 2009 at 11:56 AM, Gary C Martin wrote:
> Hi Aleksey,
>
> On 25 Jul 2009, at 17:02, Aleksey Lim wrote:
>
>> On Sat, Jul 25, 2009 at 04:24:33PM +0100, Gary C Martin wrote:
>>>
>>> Hi Aleksey,
>>>
>>> On 25 Jul 2009, at 05:02, Aleksey Lim wrote:
>>>
 On Sat, Jul 25, 2009 at 04:53:33AM +0100, Gary C Martin wrote:
>
> The term "content bundles" is still pretty wooly for me. Are we
> talking zip files, perhaps with some formal structure?

 Object Bundles[1] will deprecate .xol in 0.86 and in case of previews,
 it will be regular field in METADATA file:
 "preview_file = "

 [1] http://wiki.sugarlabs.org/go/Features/Object_Bundles
 [2] http://wiki.sugarlabs.org/go/Features/Object_Bundles#METADATA_file
>>>
>>> Thanks for the references. Having read that page I'm still confused
>>> about aspects of this proposal. Not sure I'm clear enough to ask
>>> sane questions. Let me try:
>>>
>>> 1) By "composite object" do you mean a container of many
>>> files/folders (a little like current .xol), or a container of many
>>> Journal compatible entries (i.e. 40 Read Activity pdf ebooks with
>>> thumbnail images, tags, and description)?
>>
>> Container of of many files/folders that represented by one Journal entry
>> so, in case of library it would be: one entry in Journal which has
>> text/html
>> and directory with content of library(somewhere). After activating it,
>> Browse will open one of "many files/folders" e.g. index.html
>>
>>> 2) Is .xol extension proposed to go away, or will .xol be repurposed
>>> as a the "composite object"?
>>
>> In case of [1] .xol is just a subset of object bundles
>> and sugar will still support former .xol(but they will be deprecated)
>>
>>> 3) Why should a "composite object" open in Browse, is this just an
>>> example of a zipped up web site?
>>
>> Because Journal entry which represent composite object will have
>> text/html mime_type, in face there is only one difference between
>> regular Journal objects and composite - regular object has only one
>> file but composite has directory.
>
> +1
>
> Thanks, understood.
>
>>> 4) Will .xo will be used to store Activity bundles (i.e as we have
>>> now), and Activity entries (i.e. all meta-data and files as found
>>> for a Journal entry)?
>>
>> Activity just another example of composite object(in common sense)
>> and I'm thinking about adding them to 0.86 as well.
>>
>> According to [2] there could be two forms of object bundles:
>> * one or several packed Activity entries
>>  (they can have activity field)
>> * the while bundle as composite object which will be represented by one
>>  Journal activity-less object (e.g. library or activity)
>
> OK, I think I understand that :-)
>
> 1) 1 (to N) Activity entries, all wrapped inside the .xo, on download to
> Journal they are all expanded as individual Journal entries. +1 :-)
>
> 2) A zipped folder of files/folders that is placed in the Journal as a
> single entry (composite object). Question: Is this equivalent to an .xol?
> Or, can it hold arbitrary files (i.e .xol is a subset), like a bunch of C
> source files? Maybe you want to make a Gcc Activity to open this composite
> object at some point? ;-b

I've always envisioned a "Bundle" activity which is a glorified
tar/zip/other-bundle-format viewing and creation tool. With Bundle, it
would be possible to open any such file in the Journal (including
activity bundles, of course) to view its contents. It would also
support extracting all or part of the bundle contents to separate
Journal entries, as well as creating new bundles from arbitrary
collections of objects.

It would even be possible to add collaboration on top of this, so
groups of kids could create bundles together, aggregating entries from
each of their Journals into a single product. This would be useful for
group projects, for instance.

I know a class took this on as a project at one point, though I never
heard how that turned out. I believe
this—http://activities.sugarlabs.org/en-US/sugar/addon/4079—is the
result, but I haven't had a chance to try it yet. In any case, it
might be nice to keep it in mind, and perhaps extend its features in
line with these new discussions for object bundles if appropriate. For
instance, it might be possible to add some GUI tools for
viewing/populating Sugar-specific manifest files, when desired.

As a side note, I have an icon for "Bundle" which we've had around
since the early design stages of Sugar, and the icon shown there isn't
HIG compliant. Jake, would you be willing to update the bundle with a
new icon if I supplied you with one?

Eben


>>> 5) Meta-data kept in an INI rather than json a file?
>>
>> In INI format since its easier for hand-editing
>>
>>> What about non-
>>> text meta-data, the preview image comes to mind, but an activity
>>> might be storing other non text blobs of meta-data.
>>
>> Any field in METADATA file can have _file suffix, in that case content
>> of this field(substring 

Re: [Sugar-devel] Buddy Tagging (Was: GPA Goals Status)

[Eben Eliason]

On Sat, Jul 25, 2009 at 10:59 AM, Gary C Martin wrote:
> Hi Eben,
>
> On 25 Jul 2009, at 03:01, Eben Eliason wrote:
>
>> On Wed, Jul 22, 2009 at 1:17 PM, Gary C Martin
>> wrote:
>>>
>>> On 21 Jul 2009, at 23:51, Caroline Meeks wrote:
>>>
>>>> On Tue, Jul 21, 2009 at 4:15 PM, Gary C Martin
>>>>  wrote:
>>>>
>>>>> Hi Greg,
>>>>>
>>>>> On 21 Jul 2009, at 14:51, Greg Smith wrote:
>>>>>
>>>>>> I may also add a feature to share a file from one
>>>>>> computer to another. I want to see a lesson plan needing that first.
>>>>>> Then I'll try out the suggestions recently posted to the list
>>>>>> before I
>>>>>> ask for a new feature.
>>>>>
>>>>> Have you tried using the "Send to --> friend" Journal feature?
>>>>> Obviously you need local collaboration working first, and added some
>>>>> friends:
>>>>>
>>>>>
>>>>> http://wiki.sugarlabs.org/go/0.84/0.83.5_Notes#Journal_entry_palette
>>>>
>>>> Send to sends to one person and we need to have one person (the
>>>> teacher in
>>>> this use case) send to everyone in the class/neighborhood.
>>>>
>>>> That said, I wonder if we can use this as a work around while we
>>>> wait for
>>>> designers and programmers to figure out the usecase.
>>>>
>>>> Is there a clever human engineering solution that would quickly
>>>> allow each
>>>> kid to send it to two other kids and get full coverage quickly?
>>>> sort of
>>>> like a calling tree?  I think what I'm asking is how could I in a
>>>> classroom
>>>> management situation set up file sending tree quickly that includes
>>>> everyone
>>>> and doesn't cause too much chaos and is resilient to kids being
>>>> absent and
>>>> some kids being socially isolated.
>>>
>>> One of the 0.86 roadmap items was buddy tagging, but think it may have
>>> slipped:
>>>
>>>       http://wiki.sugarlabs.org/go/Tagging_Proposal
>>>
>>> Here's some random misc. thoughts -
>>>
>>> Buddy tagging questions:
>>>
>>> 1) Can only add tags to myself?
>>>
>>> In this, case a teacher would need to get each of her class to add a
>>> specific unique tag themselves "class_greentree7" (or she could add it
>>> before handing out the sticks). This tag would be visible/searchable
>>> in the neighbourhood by anyone on the same network/server. Anyone on
>>> the same network/server could use the "send to --> class_greentree7"
>>> to send items to the whole class. Other people could potentially tag
>>> themselves as class_greentree7, the teacher could see this in the
>>> neighbourhood, if she checked, but class_greentree7 could potentially
>>> not be exclusive if she isn't watching.
>>
>> Have you read the design specification for groups as they were
>> initially envisioned? (some details may have changed since this was
>> written, but I think you'd find it useful background, and it answers
>> some of your questions.)
>> http://wiki.laptop.org/go/Specifications/Groups
>
> Thanks for the reminder :-) yes I'd read this a while back (but wasn't sold
> at the time, though it's a good starting discussion). FWIW this document is
> over on SL as well:
>
>        http://wiki.sugarlabs.org/go/Design_Team/Specifications/Groups
>
>> I still think that adding groups is a logical and even necessary
>> extension of Sugar as it exists now, so I'd urge you not to try to
>> solve all the problems that groups are designed to solve with tagging
>> alone. Or, perhaps an early implementation of groups can come out of
>> your work as well.
>
> OK, so I'd suggest my 1) above description of self tagging (a personal
> profile), replaces the use cases for "Open groups". The "open groups" will
> naturally form by users self tagging their interests, projects, or being
> asked to enter some after school club name, etc.

This is an interesting observation, but I think that open groups and
self-tagging are still separate ideas and individually useful.

Self-tagging: allows kids to identify themselves as anything they
choose, allowing others to search for them by topic or interest. Any
number of kids can apply the same tag at will, an

Re: [Sugar-devel] Choosing to merge: a mockup

[Eben Eliason]

Sorry, I've let some threads linger in my inbox...

On Mon, Jul 13, 2009 at 5:22 AM, Tomeu Vizoso wrote:
> On Tue, Jul 7, 2009 at 20:12, Benjamin M.
> Schwartz wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Mockup:
>> http://dev.laptop.org/~bemasc/merge_share_selection_mockup.png

The mockup doesn't look bad, though I wonder a few things. I think
this would work well visually if the "merge" visual were a real-time
representation of the group currently working on the activity, rather
than an icon. (This may be your intent, but I wanted to make it
explicit). In the same vein, I think "your XO" should appear above the
same activity icon, so that the picture painted is clear...if you
click on "work alone", you'll have your own copy and they'll have
theirs.

I'd also greatly simplify the text to something like "Join" and "Work alone."

>> Idea:
>> If I resume an Activity session from my Journal, and there is already a
>> session in progress with the same activity_id, and the Activity in
>> question supports automerge,  then Sugar will show me the above screen,
>> asking me whether I want to merge my work with the shared session, or to
>> work alone.  This is enough to enable basic asynchronous collaboration.

Visual details aside, I'm still unsure if we actually need to expose
this choice. I'm still partial to doing the merge/join automatically
if the entry being opened is the most recent in the history, and
opening it as a separate instance otherwise.

>> The screen simply has two buttons.  One is the image of the shared session
>> in question, identical to the one shown in the Neighborhood View.  The
>> other is an image of my XO icon.  The text below each button explains its
>> purpose, and also gives the name of the shared session and the local
>> session, as these may have diverged.  Knowing the names may help the user
>> to decide whether or not to merge.

That's a good point. Perhaps I have to retract my statement about the
simplified text, though perhaps it could still be shortened some.

>> As I understand it, the current activity architecture requires an activity
>> to know if it is a joining a shared session as soon as initialization
>> begins, so activity startup cannot proceed until the user makes a choice.
>
> Perhaps we should review this. Is providing the choice in the launcher
> screen our best option user experience-wise? Or would be better to
> leave it entirely in the activity's hands if it was possible?

Yeah, perhaps. Another thought, if there has to be Some Way to prevent
automatic merge is to offer "Resume alone" next to the "Resume" and
"Resume with" options, to override the merge and start a separate
session.

Eben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Buddy Tagging (Was: GPA Goals Status)

[Eben Eliason]

On Wed, Jul 22, 2009 at 1:17 PM, Gary C Martin wrote:
> On 21 Jul 2009, at 23:51, Caroline Meeks wrote:
>
>> On Tue, Jul 21, 2009 at 4:15 PM, Gary C Martin
>>  wrote:
>>
>>> Hi Greg,
>>>
>>> On 21 Jul 2009, at 14:51, Greg Smith wrote:
>>>
 I may also add a feature to share a file from one
 computer to another. I want to see a lesson plan needing that first.
 Then I'll try out the suggestions recently posted to the list
 before I
 ask for a new feature.
>>>
>>> Have you tried using the "Send to --> friend" Journal feature?
>>> Obviously you need local collaboration working first, and added some
>>> friends:
>>>
>>>
>>> http://wiki.sugarlabs.org/go/0.84/0.83.5_Notes#Journal_entry_palette
>>
>> Send to sends to one person and we need to have one person (the
>> teacher in
>> this use case) send to everyone in the class/neighborhood.
>>
>> That said, I wonder if we can use this as a work around while we
>> wait for
>> designers and programmers to figure out the usecase.
>>
>> Is there a clever human engineering solution that would quickly
>> allow each
>> kid to send it to two other kids and get full coverage quickly?
>> sort of
>> like a calling tree?  I think what I'm asking is how could I in a
>> classroom
>> management situation set up file sending tree quickly that includes
>> everyone
>> and doesn't cause too much chaos and is resilient to kids being
>> absent and
>> some kids being socially isolated.
>
> One of the 0.86 roadmap items was buddy tagging, but think it may have
> slipped:
>
>        http://wiki.sugarlabs.org/go/Tagging_Proposal
>
> Here's some random misc. thoughts -
>
> Buddy tagging questions:
>
> 1) Can only add tags to myself?
>
> In this, case a teacher would need to get each of her class to add a
> specific unique tag themselves "class_greentree7" (or she could add it
> before handing out the sticks). This tag would be visible/searchable
> in the neighbourhood by anyone on the same network/server. Anyone on
> the same network/server could use the "send to --> class_greentree7"
> to send items to the whole class. Other people could potentially tag
> themselves as class_greentree7, the teacher could see this in the
> neighbourhood, if she checked, but class_greentree7 could potentially
> not be exclusive if she isn't watching.

Have you read the design specification for groups as they were
initially envisioned? (some details may have changed since this was
written, but I think you'd find it useful background, and it answers
some of your questions.)
http://wiki.laptop.org/go/Specifications/Groups

I still think that adding groups is a logical and even necessary
extension of Sugar as it exists now, so I'd urge you not to try to
solve all the problems that groups are designed to solve with tagging
alone. Or, perhaps an early implementation of groups can come out of
your work as well.

> Pro: Clean design. I can search the neighbourhood to find other's tags
> (social network). Individual kids can form groups by agreeing to use
> matching tags ("school_play").

I think this is definitely the place to start with tagging.

I'd like to see the ability for kids to provide tags for themselves in
a "profile" of sorts. It would also be nice to expose these profiles
in the secondary palettes for people in the UI. Perhaps one's own
palette allows editing. We could also expose even more details in the
"about me" section of settings.

> Con: I can't make my own ad-hoc tag lists of friends
> ("friday_art_club", "people_who_helped_me"), I have to rely on each of
> them to self tag.

I think this con is acceptable, for now. I understand the desire to
allow anyone to tag anyone, but it's not clear how to expose this in
the UI clearly, and it moves into the realm of "groups". Of course,
groups are also mutual sets of people, rather than local labels for
people.

> Equivalent to: Joining (or leaving) mail lists (ie. you can join/
> leave, you can't force others to join/leave)

Again, this kind of membership issue is really a feature of groups,
and I think the proposal I linked to handles it rather well. In most
cases membership is at will, but there are special provisions in the
UI for, say "class_greentree7" so the teacher can manage the class
group as needed.

> 2) Can I only tag other buddies?
>
> These tags would simply be local to my install of Sugar for my one
> use, with nothing shared.
>
> Pro: Simple. Clean design. I can search the neighbourhood for buddy
> tags I've added. I can make my own personally relevant ad-hoc tag
> lists to work with those groups of people I want to work with. I have
> full control over who I tag with what.
>
> Con: No sharing of tags with others, no discovery of others through
> their own tags. Each person needs to create their own tag lists
> (duplication of effort if, say, each member of the "school_play" each
> has to "school_play" tag all other members of the school play).

Yes, I don't think this is powerful enough for kids. That is, the
primary

Re: [Sugar-devel] Book bundles and Read

[Eben Eliason]

On Thu, Jul 23, 2009 at 5:09 PM, Gary C Martin wrote:
> On 23 Jul 2009, at 21:36, Jim Simmons wrote:
>
>> Gary,
>>
>> What Scotty wants is a listing that can be easily browsed, and which
>> shows image files for book covers.
>
> Yes, book cover images, is the big missing feature with current
> Journal abilities when accessing external media (along with a Journal
> thumb view, but hopefully that feature is coming).

We should provide a way to populate the previews for the entries
within content bundles. With this, and a grid view, we'd be in good
shape.

>> The problem I have with USB
>> devices on the Journal is that they are listed in descending order by
>> the date and time they were created.  Even a few hundred books on a
>> USB stick isn't all that easy to manage.  (I have an SD drive with 2
>> GB worth of comic books and it really bugs me that they aren't in
>> alphabetical order).  Searching is fine if you know what you're

The Journal is spec'd to have sorting capability, and Tomeu has done
some work toward this end. It should be possible to sort by date,
title, type, and participants.

>> looking for.  In this case the kid might be asked by his teacher to
>> pick out a book from the "conduct of life" collection and do a report
>> on it.
>
> The teacher asking students "to pick out a book from the 'conduct of
> life'" is the easy case :-) The kid just types 'conduct of life' into
> the Journal search filed, and just those books are listed. All that
> the USB stick would have needed is for those books to be in a
> directory called "conduct of life", or for that text to be part of
> each books file name title. Like any real bricks and mortar library,
> putting the books in some sort of order, up front, really helps the
> punters in finding what they are looking for ;-)
>
>> In that case the kid really needs to be able to search the USB
>> drive as if it was a real bookshelf, look at the book covers, read
>> descriptions, etc.  What I had proposed would allow that.
>
> Yes, Journal type meta-data is not supported on external media
> unfortunately (though that is a really tough problem to solve). I
> guess you can make the argument for creating custom file layouts /
> index that you implement in Journal (E), so that you can stick
> book thumbs and metadata in known names/folders... But this is just a

Oh. That's what I was suggesting above. I guess you're right. It would
be very useful, though...

> re-implementation of the data-store format from Tomeu, so no need to
> re-invent or re-implement, just use the existing format for free!
>
> What this would mean for the Journal is allowing external volumes/
> media to be flagged in some way so that the Journal would read and
> display their data just like from the local Sugar data-store. I guess
> this could be very low hanging fruit, you'd need to ask Tomeu... The

We have discussed the idea of offering an "Extend my Journal" option
for external media. It would be particularly useful for SD cards which
can be more or less permanently installed. I think it's an intriguing
idea.

> flag could be something as simple as an empty root level file on the
> volume named to indicate the volume is in data-store format and should
> be treated as such.
>
>> The idea is to provide books to kids that don't have access to the
>> Internet, either because it isn't available or because of parental
>> concern.
>
> +1
>

Eben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full screen view - making the the restore button go away

[Eben Eliason]

Sounds like a fine idea to me. It's probably one of the "nice to have"
features that just never got implemented.

Eben


On Fri, Jul 24, 2009 at 7:25 PM, Sayamindu Dasgupta wrote:
> Hello,
> Is there a reason why the square restore button in full screen mode
> does not go away after a timeout (temporarily - unless you move the
> cursor) ?
> Thanks,
> Sayamindu
>
>
> --
> Sayamindu Dasgupta
> [http://sayamindu.randomink.org/ramblings]
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] GSoC Groupthink Update: SharedTextDemo-4

[Eben Eliason]

On Fri, Jul 17, 2009 at 1:23 PM, Walter Bender wrote:
> On Fri, Jul 17, 2009 at 12:35 PM, Benjamin M.
> Schwartz wrote:
>> Walter Bender wrote:
>>> On Thu, Jul 16, 2009 at 10:06 PM, Benjamin M.
>>> Schwartz wrote:
 1. Any session saved in the Journal that was previously shared, will be 
 shared
 again with the same scope upon resume.
 2. If there is an existing shared session visible with the same 
 activity_id, the
 activity will join that session.

I think this is good, but again want to state that I personally feel
that this should happen only when the session being resumed is the
most recent in the individuals thread. It should be possible to open
older versions of the session without instigating a merge.

 This behavior is good enough for me.  However, it does preclude users from
 working privately on the results of a shared session, unless they totally

Perhaps this could be accommodated by allowing different types of
"resume" actions. For instance, we've long desired to have both
"start" and "start with >", where the latter would reveal a submenu
allowing a child to start an activity in a "neighborhood" scope, or
with individual friends (and later groups). Perhaps we could likewise
have "resume" and "resume alone", or something similar, so that the
choice can be made in the process of resuming the session.

 deactivate their network connection.  I could add this ability to work
 privately to groupthink's GroupActivity superclass, or it could be added to
 sugar's Activity class.  A number of other interesting behaviors, such as
 forking an existing document, are also unavailable in the present system.
>>>
>>> Maybe an option for "keep" could be to "keep a private copy"?

This has always been my mental model for the "keep a copy" button (not
the "keep" button). I think my thinking is similar to Ben's, here.

>> I think this makes sense.  "Keep a copy" would reset the sharing scope to
>> private, and create a new activity_id.  It's hard to reason about, but I
>> think this makes sense for a versioned datastore as well, where creating a
>> copy is only necessary if you want to break the history (otherwise Keep is
>> sufficient to make a checkpoint in the version history).

Yup.

>> However, this still doesn't allow temporary private work.  In order to be
>> able to work privately on a shared document, and then later merge it back
>> into the shared stream, users would need to be able to choose to work
>> privately for a single session, without altering the activity_id.  It's
>> not yet clear to me how important this feature is.
>>
>> --Ben
>>
>>
>
> A private copy can be shared again. So it seems the real question is

That's true, but if the new copy is private, it will have a new
tree_id and be part of a new thread, with a separate history. It would
be possible to manually merge this with the former thread, or share it
with others in its current thread, but the two threads would not be
automatically merged.

> one of merging. If each of us are working on different versions and we
> want to share again, we need some reconciliation mechanism. I would
> argue that for the time being, that should be a manual process.

I think manual merge should always be the fallback. However, I like
the idea of supporting automatic merge of the "most recent" versions
from several individuals in a collaboration thread.

Eben

> -walter
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Click response areas

[Eben Eliason]

On Fri, Jul 17, 2009 at 9:55 AM, Frederick Grose wrote:
> On Fri, Jul 17, 2009 at 9:25 AM, Eduardo H. Silva 
> wrote:
>>
>> ...
>>
>>
>>
>> (Students at the Gardner Pilot Academy...)
>> > - Clicked on drop down instead of icon (e.g. clicking stop they put
>> > the cursor over the stop sign then saw the drop down text saying
>> > "Stop" then clicked on that and nothing happens. They should click
>> > directly on the stop sign itself.
>> Stop is probably the first toolbar button a user/kid uses, so I think
>> it is normal that they don't yet know how it works.
>
> Is there a sufficient reason that the button label is not click-responsive?

No, this is a long-standing bug. The "primary palette" which serves as
a label for the button should be a clickable extension of the button
itself.

Eben

> Having a larger target is a benefit for all users.  Radio buttons and check
> marks that respond when their text labels are clicked are more usable, as
> well.
>
>     --Fred
>
>>
>> ...
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel