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

2010-09-21 Thread Eben Eliason
On Tue, Sep 21, 2010 at 4:18 PM, Walter Bender walter.ben...@gmail.comwrote:

 On Tue, Sep 21, 2010 at 10:11 AM, Tomeu Vizoso to...@sugarlabs.org
 wrote:
  On Mon, Sep 20, 2010 at 23:50, Samuel Greenfeld greenf...@laptop.org
 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

2010-08-03 Thread 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

2010-07-02 Thread 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 garycmar...@googlemail.comwrote:

 Hi  Martin,

 On 2 Jul 2010, at 19:10, Martin Abente wrote:

  On Tue, 29 Jun 2010 21:53:59 +0100, Gary Martin
  garycmar...@googlemail.com wrote:
  On 29 Jun 2010, at 15:39, Martin Langhoff martin.langh...@gmail.com
  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

2010-07-02 Thread 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 ifs, though,
not recommendations…it already looks great.)

Eben


On Fri, Jul 2, 2010 at 10:02 PM, Gary Martin garycmar...@googlemail.comwrote:

 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 garycmar...@googlemail.com
 wrote:
  Hi  Martin,
 
  On 2 Jul 2010, at 19:10, Martin Abente wrote:
 
   On Tue, 29 Jun 2010 21:53:59 +0100, Gary Martin
   garycmar...@googlemail.com wrote:
   On 29 Jun 2010, at 15:39, Martin Langhoff martin.langh...@gmail.com
   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] [DESIGN] Simple Journal Backup Restore Control Panel

2010-05-16 Thread 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 to...@tomeuvizoso.net wrote:
 On Thu, Apr 1, 2010 at 04:30, Bernie Innocenti ber...@codewiz.org 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

2010-04-21 Thread Eben Eliason
On Wed, Apr 21, 2010 at 6:22 PM, Bert Freudenberg b...@freudenbergs.de 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] Keep confusion, yet again

2010-04-21 Thread Eben Eliason
On Wed, Apr 21, 2010 at 7:18 PM, Chris Ball c...@laptop.org 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   c...@laptop.org
 One Laptop Per Child

___
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

2010-04-08 Thread Eben Eliason
On Thu, Apr 8, 2010 at 7:18 AM, Sascha Silbe
sascha-ml-ui-sugar-de...@silbe.org 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] [DESIGN] Show file size in Journal

2010-04-08 Thread Eben Eliason
On Thu, Apr 8, 2010 at 8:35 AM, Bert Freudenberg b...@freudenbergs.de wrote:
 On 08.04.2010, at 13:47, Eben Eliason wrote:

 On Thu, Apr 8, 2010 at 7:18 AM, Sascha Silbe
 sascha-ml-ui-sugar-de...@silbe.org 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] scalability in the neighborhood view

2010-03-25 Thread Eben Eliason
On Wed, Mar 24, 2010 at 2:38 PM, Frederick Grose fgr...@gmail.com wrote:
 On Wed, Mar 24, 2010 at 8:57 AM, Eben Eliason eben.elia...@gmail.com
 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

2010-03-24 Thread Eben Eliason
On Wed, Mar 24, 2010 at 8:32 AM, Martin Langhoff
martin.langh...@gmail.com wrote:
 On Wed, Mar 24, 2010 at 3:28 AM, Tomeu Vizoso to...@tomeuvizoso.net 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

2010-03-21 Thread Eben Eliason
On Wed, Mar 3, 2010 at 2:08 PM, Martin Langhoff
martin.langh...@gmail.com wrote:
 On Wed, Mar 3, 2010 at 1:02 PM, Caroline Meeks solutiongr...@gmail.com 
 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] [DESIGN] Showing 3G Connection Errors

2010-02-27 Thread Eben Eliason
On Sat, Feb 27, 2010 at 10:07 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote:
 On Fri, Feb 26, 2010 at 23:03, Gary C Martin g...@garycmartin.com wrote:
 On 26 Feb 2010, at 15:59, Tomeu Vizoso wrote:

 On Fri, Feb 26, 2010 at 13:30, Daniel Castelo
 dcast...@plan.ceibal.edu.uy 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 to...@tomeuvizoso.net
 wrote:

 On Fri, Feb 19, 2010 at 16:41, Eben Eliason eben.elia...@gmail.com
 wrote:
 On Wed, Feb 17, 2010 at 2:27 PM, Daniel Castelo
 dcast...@plan.ceibal.edu.uy 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] 0.88 Meeting --- 20. Feb 2010 (15:30 UTC)

2010-02-19 Thread 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
christianm...@gmail.com 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 si...@schampijer.de
 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] [DESIGN] Showing 3G Connection Errors

2010-02-19 Thread Eben Eliason
On Wed, Feb 17, 2010 at 2:27 PM, Daniel Castelo
dcast...@plan.ceibal.edu.uy 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] [Feature] [DESIGN] Enhanced Color Selector

2010-02-03 Thread Eben Eliason
On Wed, Feb 3, 2010 at 5:06 PM, Simon Schampijer si...@schampijer.de wrote:
 Thanks Tim for your feedback,

 On 02/02/2010 11:54 PM, Tim McNamara wrote:
 On 2 February 2010 22:45, Simon Schampijersi...@schampijer.de  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

2010-01-22 Thread 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 eben.elia...@gmail.com wrote:
 On Sat, Jan 16, 2010 at 2:47 PM, Simon Schampijer si...@schampijer.de wrote:
 On 01/15/2010 02:36 PM, Daniel Castelo wrote:
 On Fri, Jan 15, 2010 at 5:48 AM, Simon Schampijersi...@schampijer.dewrote:

 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


attachment: 3G_device.png___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


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

2010-01-16 Thread Eben Eliason
On Sat, Jan 16, 2010 at 2:47 PM, Simon Schampijer si...@schampijer.de wrote:
 On 01/15/2010 02:36 PM, Daniel Castelo wrote:
 On Fri, Jan 15, 2010 at 5:48 AM, Simon Schampijersi...@schampijer.dewrote:

 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

2010-01-14 Thread Eben Eliason
On Wed, Jan 13, 2010 at 8:32 AM, Walter Bender walter.ben...@gmail.com wrote:
 On Wed, Jan 13, 2010 at 8:15 AM, Gary C Martin g...@garycmartin.com wrote:
 On 11 Jan 2010, at 20:44, Walter Bender wrote:

 On Mon, Jan 11, 2010 at 3:32 PM, Simon Schampijer si...@schampijer.de 
 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

2009-12-14 Thread Eben Eliason
On Sun, Dec 13, 2009 at 12:42 AM, Aleksey Lim alsr...@member.fsf.org 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] Scrollbar width

2009-12-11 Thread Eben Eliason
On Fri, Dec 11, 2009 at 3:02 AM, Albert Cahalan acaha...@gmail.com 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] [Feature] activity.info enhancements

2009-12-11 Thread Eben Eliason
On Fri, Dec 11, 2009 at 2:26 PM, Tomeu Vizoso to...@sugarlabs.org wrote:
 On Fri, Dec 11, 2009 at 17:18, Sayamindu Dasgupta sayami...@gmail.com wrote:
 On Fri, Dec 11, 2009 at 11:13 PM, Walter Bender walter.ben...@gmail.com 
 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

2009-12-10 Thread Eben Eliason
On Thu, Dec 10, 2009 at 7:54 AM, Paul Fox p...@laptop.org 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] Scrollbar width

2009-12-10 Thread Eben Eliason
On Thu, Dec 10, 2009 at 12:30 PM, Sean DALY sdaly...@gmail.com 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 g...@garycmartin.com wrote:
 On 10 Dec 2009, at 14:58, Eben Eliason wrote:

 On Thu, Dec 10, 2009 at 7:54 AM, Paul Fox p...@laptop.org 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] seeking feedback on sketch of a new color selector

2009-12-07 Thread Eben Eliason
On Mon, Dec 7, 2009 at 12:39 PM, Gary C Martin g...@garycmartin.com 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 Schampijersi...@schampijer.de  
 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] seeking feedback on sketch of a new color selector

2009-12-07 Thread Eben Eliason
On Mon, Dec 7, 2009 at 12:52 PM, Walter Bender walter.ben...@gmail.com wrote:
 On Mon, Dec 7, 2009 at 12:39 PM, Gary C Martin g...@garycmartin.com 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 Schampijersi...@schampijer.de  
 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] adding 3G devices support to sugar

2009-12-03 Thread Eben Eliason
On Thu, Dec 3, 2009 at 1:44 PM, Martin Abente mabe...@paraguayeduca.org 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
 dcastelo.sugarl...@gmail.com 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
 martin.langh...@gmail.comwrote:

 On Wed, Dec 2, 2009 at 3:04 AM, Martin Abente
 mabe...@paraguayeduca.org
 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

2009-12-02 Thread Eben Eliason
On Tue, Dec 1, 2009 at 5:54 AM, Martin Langhoff
martin.langh...@gmail.com wrote:
 On Mon, Nov 30, 2009 at 9:40 PM, Wade Brainerd wad...@gmail.com 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

2009-11-22 Thread Eben Eliason
On Sun, Nov 22, 2009 at 6:10 PM, Wade Brainerd wad...@gmail.com 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] another attempt at a color selector

2009-11-11 Thread 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 walter.ben...@gmail.com 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] seeking feedback on sketch of a new color selector

2009-11-11 Thread 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 g...@garycmartin.com 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 g...@garycmartin.com
 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] ribbon, right-click, button bars (was: RFC: Kill the delayed menus for good)

2009-10-20 Thread Eben Eliason
On Tue, Oct 20, 2009 at 4:08 PM, Albert Cahalan acaha...@gmail.com 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

2009-10-19 Thread 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 walter.ben...@gmail.com 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 wad...@gmail.com 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 to...@sugarlabs.org wrote:
 On Mon, Oct 19, 2009 at 13:32, Gabriel Eirea gei...@gmail.com 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 to...@sugarlabs.org:
 Any ideas for a better wording?

 Thanks,

 Tomeu

 On Sat, Oct 17, 2009 at 00:40, Sugar Labs Bugs
 bugtracker-nore...@sugarlabs.org 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: http://bugs.sugarlabs.org/ticket/1508
 Sugar Labs http://sugarlabs.org/
 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] friendview.py

2009-10-17 Thread Eben Eliason
On Sat, Oct 17, 2009 at 9:40 AM, Wade Brainerd wad...@gmail.com 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
 bmsch...@fas.harvard.edu 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] Design mockup of a different activity launcher

2009-10-17 Thread Eben Eliason
On Sat, Oct 17, 2009 at 4:53 PM, Wade Brainerd wad...@gmail.com 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] Design mockup of a different activity launcher

2009-10-17 Thread Eben Eliason
On Sat, Oct 17, 2009 at 8:10 PM, Wade Brainerd wad...@gmail.com wrote:
 Hi Eben, thanks for the feedback!

 On Sat, Oct 17, 2009 at 7:27 PM, Eben Eliason e...@laptop.org wrote:
 On Sat, Oct 17, 2009 at 4:53 PM, Wade Brainerd wad...@gmail.com 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 useful, in the long run.

 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.

 Blinking would definitely be ok.

Yeah. It doesn't have quite the same appeal, but it would be less CPU
intensive. Incidentally, how does the launcher perform on the XO 1.5
units? Has anyone had a chance to try

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

2009-10-16 Thread 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 e...@laptop.org wrote:
 On Thu, Oct 15, 2009 at 10:09 PM, Avi fiendi...@gmail.com 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

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

2009-10-15 Thread Eben Eliason
On Thu, Oct 15, 2009 at 10:09 PM, Avi fiendi...@gmail.com 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 it may be useful to show the 

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

2009-10-14 Thread Eben Eliason
On Wed, Oct 14, 2009 at 12:04 PM, Simon Schampijer si...@schampijer.de 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 Stonemich...@laptop.org
 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] RFC: Kill the delayed menus for good

2009-10-14 Thread Eben Eliason
On Wed, Oct 14, 2009 at 1:41 PM, Edward Cherlin echer...@gmail.com wrote:
 I'm extracting some of the for [[The Undiscoverable]].

 On Wed, Oct 14, 2009 at 9:39 AM, Eben Eliason e...@laptop.org wrote:
 On Wed, Oct 14, 2009 at 12:04 PM, Simon Schampijer si...@schampijer.de 
 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 Stonemich...@laptop.org
 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 what we
 want kids to face?

 I don't see the problem. The nice friendly large clickable icons will
 remain where they are. You either have to create and *demonstrate* a
 path to *equal* discoverability, or you have to think about helping
 teachers help children with what they don't discover.

The problem is that the appearance of the palette seems to encourage
kids to take the longer (and harder) route to their desired
interaction. The reveal of the alternate option could distract from
the more direct path to their intended goal. Again, observation with
kids indicated that, even without revealing palettes immediately, they
tended to wait for them instead of clicking directly

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

2009-10-14 Thread Eben Eliason
On Wed, Oct 14, 2009 at 11:12 PM, Michael Stone mich...@laptop.org 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 si...@schampijer.de 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 delay as we do now, with some
 indication of more options that can be clicked 

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

2009-10-09 Thread 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 alsr...@member.fsf.org 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] ASLO layout issue in safari

2009-10-09 Thread Eben Eliason
On Fri, Oct 9, 2009 at 1:43 PM, Josh Williams j...@tucson-labs.com 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 j...@tucson-labs.com 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 alsr...@member.fsf.org 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] [ANNOUNCE] Sucrose 0.86 Branching - Activity versions

2009-10-01 Thread Eben Eliason
On Thu, Oct 1, 2009 at 7:16 AM, Peter Robinson pbrobin...@gmail.com wrote:
 On Thu, Oct 1, 2009 at 12:08 PM, Wade Brainerd wad...@gmail.com wrote:
 On Thu, Oct 1, 2009 at 5:20 AM, Simon Schampijer si...@schampijer.de
 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.))

2009-09-18 Thread 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
satel...@bendbroadband.com 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 satel...@bendbroadband.com


 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

2009-09-11 Thread 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 Marting...@garycmartin.com 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

2009-09-11 Thread Eben Eliason
On Fri, Sep 11, 2009 at 3:17 PM, Gary C Marting...@garycmartin.com 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 Marting...@garycmartin.com
 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] [IAEP] turtle art: 2 instances, no?

2009-09-07 Thread Eben Eliason
On Mon, Sep 7, 2009 at 8:15 AM, Gary C Marting...@garycmartin.com 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] Memorize create icon

2009-09-04 Thread Eben Eliason
On Fri, Sep 4, 2009 at 3:27 PM, Caroline Meekscarol...@meekshome.com 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 jpriti...@pobox.com
 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?

2009-09-03 Thread Eben Eliason
On Wed, Sep 2, 2009 at 10:01 PM, Caroline Meekssolutiongr...@gmail.com 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
 bmsch...@fas.harvard.edu wrote:

 Christoph Derndorfer wrote:
  On Mon, Aug 31, 2009 at 5:03 PM, Walter Bender
  walter.ben...@gmail.comwrote:
 
  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

2009-08-28 Thread Eben Eliason
On Fri, Aug 28, 2009 at 5:41 PM, Gary C Marting...@garycmartin.com wrote:
 On 28 Aug 2009, at 21:51, Eben Eliason wrote:

 On Fri, Aug 28, 2009 at 4:16 PM, Gary C Marting...@garycmartin.com
 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] Accessing external media from within an activity (was: Re: Problem listing journal objects)

2009-08-26 Thread Eben Eliason
On Wed, Aug 26, 2009 at 11:35 AM, Gary C Marting...@garycmartin.com wrote:
 Hi Eben,

 On 26 Aug 2009, at 14:53, Eben Eliason wrote:

 On Wed, Aug 19, 2009 at 5:43 AM, Sascha
 Silbesascha-ml-ui-sugar-de...@silbe.org 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)

2009-08-26 Thread 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
Denglermar...@martindengler.com 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 Marting...@garycmartin.com 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] [DESIGN] UI mockups

2009-08-25 Thread 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 Marting...@garycmartin.com 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] [IAEP] Yet more feedback from Boston! - Chat and Speak

2009-08-15 Thread Eben Eliason
On Sat, Aug 15, 2009 at 1:35 PM, Gary C Marting...@garycmartin.com wrote:
 On 14 Aug 2009, at 17:11, Eben Eliason wrote:

 On Thu, Aug 13, 2009 at 8:28 PM, Caroline
 Meekscarol...@solutiongrove.com 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 - activity and this
 proposed home view Start with - Friend. 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
name's activity 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 - Friend 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] Design meeting tomorrow?

2009-08-15 Thread 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 Schmidtschm...@pentagram.com 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] Activity toolbar redesign: What to do with 'simple' activities?

2009-08-12 Thread 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
Branesculucian.brane...@gmail.com 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 si...@schampijer.de:
 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] Activity toolbar redesign: What to do with 'simple' activities?

2009-08-12 Thread 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
Schmidtchristianm...@gmail.com 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 eben.elia...@gmail.com
 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
 Branesculucian.brane...@gmail.com 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 si...@schampijer.de:
  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] Share button in the activity toolbar (from the toolbar redesign thread)

2009-08-11 Thread Eben Eliason
On Tue, Aug 11, 2009 at 9:19 AM, Aleksey Limalsr...@member.fsf.org wrote:
 On Tue, Aug 11, 2009 at 08:02:10AM -0400, Walter Bender wrote:
 On Tue, Aug 11, 2009 at 6:49 AM, Simon Schampijersi...@schampijer.de 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 Schampijersi...@schampijer.de   
  wrote:
  On 07/31/2009 05:14 PM, Eben Eliason wrote:
  On Fri, Jul 31, 2009 at 8:41 AM, Aleksey Limalsr...@member.fsf.org
     wrote:
  On Fri, Jul 31, 2009 at 02:05:48PM +0200, Tomeu Vizoso wrote:
  On Fri, Jul 31, 2009 at 13:47, Simon Schampijersi...@schampijer.de
     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 actually know what the upper bound
 for my activities are. It so much depends on how they are being used
 and what the network is like they are being used on... For example, I
 had no problem sharing Turtle Art among 25+ students on a wired
 network when they were all essentially using it to get a copy of a
 project from the teacher. As soon as they all started making
 modifications, all hell broke out. So my long-winded point is,
 max_participants is a really fuzzy concept. (I suppose in the case of
 Turtle Art, I should restrict modifications to a max_partiicipants,
 but let how every many people who want to copy (or watch) the action.

 +1

 I suspect that exact value for max_participants won't be so popular
 and will be useful only in special cases(e.g. chess), so I'm not sure we

That's true, but fuzzy numbers (let's call it an upper bound) could
still be marginally useful.

 should add so complex logic(which should cover both sides, server and
 all possible clients).

 Activities that restrict number of playable participants could do it on
 theirs own like add spectator mode or on opening shared instance send

Actually, it would be my desire that the shell would handle watching
generally for all activities, and that's one of the reasons that
having this exposed is important. It's also nice to be able to either
prevent others from joining, or change join to watch accordingly.
If choosing a static number is problematic, perhaps we can make it a
method the shell calls on the activity while running instead. In fact,
maybe it doesn't return a number, but instead a boolean indicating
whether

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

2009-08-11 Thread Eben Eliason
On Tue, Aug 11, 2009 at 6:21 AM, Simon Schampijersi...@schampijer.de wrote:
 On 08/11/2009 11:50 AM, Daniel Drake wrote:

 2009/8/11 Simon Schampijersi...@schampijer.de:

 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] [Design] Ad-hoc networks - New Icons

2009-08-11 Thread Eben Eliason
On Tue, Aug 11, 2009 at 11:22 AM, Simon Schampijersi...@schampijer.de wrote:
 On 08/11/2009 03:49 PM, Eben Eliason wrote:

 On Tue, Aug 11, 2009 at 6:21 AM, Simon Schampijersi...@schampijer.de
  wrote:

 On 08/11/2009 11:50 AM, Daniel Drake wrote:

 2009/8/11 Simon Schampijersi...@schampijer.de:

 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 help needed for web applications within Sugar

2009-08-11 Thread Eben Eliason
On Tue, Aug 11, 2009 at 1:13 PM, Lucian
Branesculucian.brane...@gmail.com wrote:
 2009/8/11 Simon Schampijer si...@schampijer.de:
 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] multiple activity versions installed simultaneously (was Re: [Bugs] #1042 UNSP: cannot install new activity version)

2009-08-10 Thread Eben Eliason
On Mon, Aug 10, 2009 at 11:52 AM, Benjamin M.
Schwartzbmsch...@fas.harvard.edu wrote:
 Martin Dengler wrote:
 On Mon, Aug 10, 2009 at 09:26:58PM +0545, Daniel Drake wrote:
 2009/8/10 Tomeu Vizoso to...@sugarlabs.org:
 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)

2009-08-06 Thread Eben Eliason
On Thu, Aug 6, 2009 at 6:56 AM, Simon Schampijersi...@schampijer.de wrote:
 On 07/31/2009 05:14 PM, Eben Eliason wrote:

 On Fri, Jul 31, 2009 at 8:41 AM, Aleksey Limalsr...@member.fsf.org
  wrote:

 On Fri, Jul 31, 2009 at 02:05:48PM +0200, Tomeu Vizoso wrote:

 On Fri, Jul 31, 2009 at 13:47, Simon Schampijersi...@schampijer.de
  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

2009-08-04 Thread Eben Eliason
On Tue, Aug 4, 2009 at 7:44 AM, Gary C Marting...@garycmartin.com wrote:
 On 4 Aug 2009, at 04:54, Eben Eliason wrote:

 On Mon, Aug 3, 2009 at 10:16 PM, Gary C Marting...@garycmartin.com
 wrote:

 Hi Eben,

 On 4 Aug 2009, at 02:19, Eben Eliason wrote:

 On Mon, Aug 3, 2009 at 3:39 PM, Gary C Marting...@garycmartin.com
 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 into settings
in general. The suggestion to have a computer device in the frame
could fix that...

 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.

 Might that conflate left click vs. right click behaviour? But, other than
 that, yes this is a fair call I think, and resolves the issue (safely) of
 what would be the default action when clicking on some other buddy icon.
 Perhaps the general rule clicking icons with no default action should
 reveal full palette can be used else where (e.g. battery device frame icon,
 network device frame icon).

That's always been the intended behavior for buttons without actions,
actually. I've informally referred to them as palette buttons (akin
to toolbar buttons), as their purpose is simply to reveal the
corresponding palette. I do see the problem with conflating right/left
clicks, though. The same would be true for eg. speaker vs. battery,
where the former has

Re: [Sugar-devel] buddy tags

2009-08-04 Thread Eben Eliason
On Tue, Aug 4, 2009 at 8:21 PM, Gary C Marting...@garycmartin.com 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

2009-08-04 Thread Eben Eliason
On Tue, Aug 4, 2009 at 8:36 PM, Benjamin M.
Schwartzbmsch...@fas.harvard.edu 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] Erase in the Ring and less hot hot corners

2009-08-03 Thread Eben Eliason
On Mon, Aug 3, 2009 at 8:37 PM, Gary C Marting...@garycmartin.com 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 qu...@laptop.org
 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)

2009-07-31 Thread Eben Eliason
On Fri, Jul 31, 2009 at 8:41 AM, Aleksey Limalsr...@member.fsf.org wrote:
 On Fri, Jul 31, 2009 at 02:05:48PM +0200, Tomeu Vizoso wrote:
 On Fri, Jul 31, 2009 at 13:47, Simon Schampijersi...@schampijer.de 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

2009-07-30 Thread Eben Eliason
On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijersi...@schampijer.de 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

2009-07-30 Thread 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 Eliasone...@laptop.org wrote:
 On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijersi...@schampijer.de 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


attachment: toolbar_edit.svgattachment: toolbar_view.svgattachment: toolbar_colors.svg___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


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

2009-07-30 Thread Eben Eliason
On Thu, Jul 30, 2009 at 10:07 PM, Gary C Marting...@garycmartin.com 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

2009-07-30 Thread Eben Eliason
On Thu, Jul 30, 2009 at 10:28 PM, Aleksey Limalsr...@member.fsf.org wrote:
 On Thu, Jul 30, 2009 at 06:02:00PM -0400, Eben Eliason wrote:
 On Thu, Jul 30, 2009 at 3:46 PM, Simon Schampijersi...@schampijer.de 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 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.

 What do you mean exactly, position, size or arrows shape
 (in case of shape it uses paint_arrow gtk function, I guess its much
 straight forward to use gtk function instead of custom images e.g. using
 the same shape like arrows in other widgets)

I'd like it to match the arrow in the mockups. In fact, I think we've
intended to use this filled triangle everywhere in the UI (such as
nested menus), so it would be fine to change this at the gtk level.
Actually, I thought Ben B. had worked on that at one point, but I
never saw

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

2009-07-30 Thread Eben Eliason
On Thu, Jul 30, 2009 at 9:21 PM, Gary C Marting...@garycmartin.com 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.

Again, this depends on the context, and where a given toolbar buttons
resides within the 

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

2009-07-29 Thread Eben Eliason
On Tue, Jul 28, 2009 at 10:12 PM, Gary C Marting...@garycmartin.com wrote:
 On 28 Jul 2009, at 19:03, Eben Eliason wrote:

 On Tue, Jul 28, 2009 at 12:07 PM, Simon Schampijersi...@schampijer.de
 wrote:

 On 07/28/2009 03:48 PM, Eben Eliason wrote:

 On Mon, Jul 27, 2009 at 5:26 PM, Simon Schampijersi...@schampijer.de
  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 in the hot
 seat task for re-designing the toolbar layouts fairly extensively (at least
 for any non trivial cases).

I'm not sure that's entirely true. I think keeping the generic
activity functions all in one place, separate from the primary
toolbar, makes it easiest for developers to use the primary toolbar to
their greatest benefit. I don't think there needs to be any rules
requiring specific feature sets to be present in the primary
toolbar—some developers may well choose to place solely toolbar
buttons in the primary toolbar; Others may choose to place basic
controls there as appropriate.

An example of the former kind might be write (or any activity with
lots of tabs). Browse (and perhaps even paint), on the other hand are
examples which clearly illustrate the benefits of keeping primary
controls in the primary toolbar. First, it means that they are exposed
up front, and second it means that they can be used in combination
with other sets of secondary tools. In Browse, it remains possible to
navigate the web even if you want to have edit or view controls
visible. In paint, it's possible to change the drawing tool while also
keeping a palette of colors available.

This choice should be seen as a benefit, not a burden.

 But glad this is finally being discussed, it was pretty much the first
 feedback I was after, and Aleksey also I think – his Write toolbar test was
 closer to your original designs, but didn't manage to get all the buttons in
 ;-b

 FWIW: Picking the top level tool set is going to be a real tough call in a
 number of cases as we loose toolbar

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

2009-07-28 Thread Eben Eliason
On Mon, Jul 27, 2009 at 5:26 PM, Simon Schampijersi...@schampijer.de 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] Initial implementation of toolbars design

2009-07-28 Thread Eben Eliason
On Tue, Jul 28, 2009 at 12:07 PM, Simon Schampijersi...@schampijer.de wrote:
 On 07/28/2009 03:48 PM, Eben Eliason wrote:

 On Mon, Jul 27, 2009 at 5:26 PM, Simon Schampijersi...@schampijer.de
  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 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

 Ok, cool. Do you have the scissor icon already? ;p

Yeah, I'll dig it up tonight when I get home.

Eben

 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

Re: [Sugar-devel] Book bundles and Read

2009-07-26 Thread Eben Eliason
On Sun, Jul 26, 2009 at 11:56 AM, Gary C Marting...@garycmartin.com 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 = file-inside-bundle-with-preview

 [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 w/o _file suffix) will be fetched from file
 inside of the bundle e.g. preview_file=filename-from-bundle to fill
 preview field.

 Thanks, sorry I missed the relevance of 

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

2009-07-26 Thread Eben Eliason
On Sat, Jul 25, 2009 at 11:35 PM, Gary C Marting...@garycmartin.com wrote:
 Hi Eben,

 On 25 Jul 2009, at 16:26, Eben Eliason wrote:

 On Sat, Jul 25, 2009 at 10:59 AM, Gary C Marting...@garycmartin.com
 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] Buddy Tagging (Was: GPA Goals Status)

2009-07-25 Thread Eben Eliason
On Sat, Jul 25, 2009 at 10:59 AM, Gary C Marting...@garycmartin.com wrote:
 Hi Eben,

 On 25 Jul 2009, at 03:01, Eben Eliason wrote:

 On Wed, Jul 22, 2009 at 1:17 PM, Gary C Marting...@garycmartin.com
 wrote:

 On 21 Jul 2009, at 23:51, Caroline Meeks wrote:

 On Tue, Jul 21, 2009 at 4:15 PM, Gary C Martin
 g...@garycmartin.com 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, and there is no limit
to the number or types of tags that one attributes to oneself, so the
possibility of lying is present. These tags serve solely as an item
to search on, and don't provide a structure for collaboration or
sharing.

Open groups: allow kids to self-organize into groups in an open but
constrained way. The formalization of the group means that, unlike
tags, any group one is a part of will appear in a filter in the Groups
view. The group creation process enables a single individual to send
invitations to the initial group members, so that only one needs to
actually type the group name (preventing mistakes). Moreover, while
anyone in an open group may freely invite others to it (hence, the
open name), no child outside the group can self-tag so as to
become a member of the group without their knowledge. The formality
(not the best word, but oh well) of the open group provides a
structure for sharing and collaborating with group members.

So, to conclude: self-tagging is great for search and discovery.
Open-groups are a mechanism for kids to self-organize (eg. for class
projects) in a structured way so that actions like send to [my
group] or share with [my group] are possible.

 Pro: Clean design. I can

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

2009-07-24 Thread 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 Dasguptasayami...@gmail.com 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] Book bundles and Read

2009-07-24 Thread Eben Eliason
On Thu, Jul 23, 2009 at 5:09 PM, Gary C Marting...@garycmartin.com 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] Buddy Tagging (Was: GPA Goals Status)

2009-07-24 Thread Eben Eliason
On Wed, Jul 22, 2009 at 1:17 PM, Gary C Marting...@garycmartin.com wrote:
 On 21 Jul 2009, at 23:51, Caroline Meeks wrote:

 On Tue, Jul 21, 2009 at 4:15 PM, Gary C Martin
 g...@garycmartin.com 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 benefit of having a profile is that each kid individually
will want to fill theirs out, and the whole neighborhood benefits as a

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

2009-07-24 Thread Eben Eliason
Sorry, I've let some threads linger in my inbox...

On Mon, Jul 13, 2009 at 5:22 AM, Tomeu Vizosoto...@sugarlabs.org wrote:
 On Tue, Jul 7, 2009 at 20:12, Benjamin M.
 Schwartzbmsch...@fas.harvard.edu 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] GSoC Groupthink Update: SharedTextDemo-4

2009-07-19 Thread Eben Eliason
On Fri, Jul 17, 2009 at 1:23 PM, Walter Benderwalter.ben...@gmail.com wrote:
 On Fri, Jul 17, 2009 at 12:35 PM, Benjamin M.
 Schwartzbmsch...@fas.harvard.edu wrote:
 Walter Bender wrote:
 On Thu, Jul 16, 2009 at 10:06 PM, Benjamin M.
 Schwartzbmsch...@fas.harvard.edu 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

2009-07-17 Thread Eben Eliason
On Fri, Jul 17, 2009 at 9:55 AM, Frederick Grosefgr...@gmail.com wrote:
 On Fri, Jul 17, 2009 at 9:25 AM, Eduardo H. Silva hoboprim...@gmail.com
 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


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

2009-07-11 Thread Eben Eliason
On Sat, Jul 11, 2009 at 10:23 AM, Gary C Marting...@garycmartin.com wrote:
 On 11 Jul 2009, at 14:40, Aleksey Lim wrote:
 On Sat, Jul 11, 2009 at 11:12:31AM +0200, Simon Schampijer wrote:
 a) DESIGN: discuss the design further and get some mockups
 together, one
 question that came up is: do we always have a one line secondary tool
 bar?

 Do you mean hiding sub-toolbars like palettes?
 I'm using new toolbar in Memorize, and should say - its much useful to
 have persistent sub-toolbar(and not auto-hiding them like palettes)

 Ebens designs describe both interaction methods:

 1). If you hover over one of the new tab replacement buttons the
 palette appears (over the top of the canvas) and will auto-hide if you
 move the mouse way (just like any normal palette)

 2). If you click one of the new tab replacement buttons the palette
 appears (and shifts the canvas down the screen) and is locked in
 place. Clicking the button a 2nd time unlocks it so it behaves like a
 regular palette again.

Yup, that's the idea. I think it should be up to the activity, by the
way, to decide if any of the secondary toolbars are locked in when a
new activity instance is created. For instance, Paint might decide
that making the colors available by default is the wise choice.

We should also institute policy for retaining toolbar state in the
metadata for a given activity entry in the Journal, so that resuming
restores that context. Perhaps this is something that the toolkit can
do so that activity doesn't have to think about it.

 How would more complex widgets like the color chooser look like
 http://wiki.sugarlabs.org/go/File:ColorToolButton.png ? Or would they
 open from the secondary palette?

 I'm personally, +1 for
 http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars#11

Just to be clear, this new toolbar design is in no way intended to
replace palettes in general. Instead, it's provided as a unique
alternative to tabs that allows palette-like interaction, but also
allows these secondary toolbars to be locked in place persistently,
which can be of great usefulness. Therefore, we needn't ask ourselves
how does this palette look/work in the new toolbar design? at all.
We should be asking which of these palettes would work better
functionally as a secondary toolbar?.

I think that Paint, for instance, would gain heaps of usability if the
colors were a secondary toolbar, and that were shown by default. That
doesn't mean that Write, for instance, necessarily needs to replace
the current color chooser palette. It's should be up to activities to
decide what parts of the UI are best suited to the two modes.

Both primary and secondary toolbars can have as many normal palette
buttons as desired.

 I guess one unanswered question is do you allow the stacking of more
 than 2 rows of toolbar... And, how much work is going to be needed on

This is something we tossed around a little bit while designing them.
I think the answer is no, personally, since it adds a lot more
complexity to the UI, and also begins to consume too much of the
screen. I'm hoping that [primary toolbars  secondary toolbars 
palettes] are sufficient for most use cases here; we don't want to
wind up with MS Word-like feature complexity!

That said, if we do support it, I think the rule is basically that
closing any parent toolbar hides all of its children, and reopening a
parent toolbar that had child toolbars open when it was last hidden
should reveal all those same children open as they were. But again,
I'd much rather just support one level of secondary toolbars.

 all the Activities if you start hand redesigning and customising each
 edge case. I think the current colour palette in Write would work as

Yup.

 is, at least that's how I was going to show it in a mockup, Activity
 bar - text bar below - existing drop down colour palette from its

One advantage of this design is that the primary toolbar is always
visible, and secondary toolbars can be shown or hidden as needed. The
mockups of Browse and Paint try to illustrate how useful this can be
in defining a set of core tools that are always—or nearly
always—applicable to interacting with the activity. In the case of
browse, the forward and back buttons, address bar, and bookmarking
button are always available in the primary toolbar. In Paint, some of
the core painting tools are surfaced.

So, the idea here is to define a primary toolbar which contains a) the
core set of tools/controls and b) toolbar buttons for the secondary
sets of tools/controls.

In the case of Write, I'd expect some of the basic text editing
controls (bold, italic, underline, font-size, font, for example) to be
surfaced in the primary toolbar, while tables, images, paragraph
formats, and other secondary features each had a secondary toolbar of
their own. In this way, it would be possible to reveal the table
controls, while retaining the basic text controls, which is clearly
quite useful since you can edit text within a table.

 

Re: [Sugar-devel] Nobody understands Keep

2009-07-10 Thread Eben Eliason
On Fri, Jul 10, 2009 at 5:28 AM, Tomeu Vizosoto...@sugarlabs.org wrote:
 On Fri, Jul 10, 2009 at 05:41, Eben Eliasone...@laptop.org wrote:
 On Thu, Jul 9, 2009 at 7:55 PM, Eduardo H. Silvahoboprim...@gmail.com 
 wrote:
 2009/7/9 Tomeu Vizoso to...@sugarlabs.org:
 On Thu, Jul 9, 2009 at 12:29, Martin Denglermar...@martindengler.com 
 wrote:
 On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote:
 On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote:
  On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote:
   Nobody in the world seems to understand the Keep button. People think
   it's for regular saving and you should do it before you close or 
   switch
   away from your activity.
 
  That's not far from the truth, right?  At least in any work-losing or
  surprising way...

 It's far from the truth in that it's not normally what you want to
 do.

 My quoting-foo is bad, so I've caused confusion (in myself, too :)).

 To save your work, simply click the Stop button or change so that
 another activity has focus. If you click Keep, you'll end up with 2
 copies - one from when you clicked Keep, and one from when you clicked
 Stop (or focused on another activity).

 As far as I understand it, Keep is useful for these types of scenarios:
 - you've done a lot of work but now it's time to refactor/reorganize the
 whole thing. However you want to keep a copy of the rough version you
 have now, as insurance or perhaps for reference while you re-mangle
 the work.
 - you've made a template for something, now you want to save that
 template (as a blank template) before starting on a version where you
 fill in the content.

 This is a great explanation -- it should be in the HIG or something.

 But the biggest problem is how do we explain this to users without
 them having to read the HIG (or manual)?

 Should be called Keep a copy?

 +1
 For a while, in the pt_PT translation of Sugar I did, I named the Keep
 button as Keep a copy.

 I urge again that keep a copy is not what is intended, in the long
 run. Without proper versions, of course, this is effectively how it
 behaves. Therefore, it's no surprise many saw it this way. But with
 versions, the keep button is actually a keep new version button.
 As mentioned before, a new version retains the tree_id, whereas a
 true copy does not.

 But are you meaning that we should name the current one Keep a copy
 and when we have versions add Keep?

No, no. I'm urging that we name it Keep new version now if we rename
it, so that it's meaning doesn't change down the road when versions
are introduced.

Eben


 Regards,

 Tomeu

 Since versions are on the way, we should make sure to clarify the 
 distinction!

 Eben



 Regards,

 Tomeu

 Daniel

 Martin

 ___
 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] Nobody understands Keep

2009-07-10 Thread Eben Eliason
On Fri, Jul 10, 2009 at 10:05 AM, Martin
Denglermar...@martindengler.com wrote:
 On Fri, Jul 10, 2009 at 10:01:19AM -0400, Eben Eliason wrote:
 On Fri, Jul 10, 2009 at 5:28 AM, Tomeu Vizosoto...@sugarlabs.org wrote:
  But are you meaning that we should name the current one Keep a copy
  and when we have versions add Keep?

 No, no. I'm urging that we name it Keep new version now if we rename
 it, so that it's meaning doesn't change down the road when versions
 are introduced.

 Keep new version seems a lot closer to a description of the
 implementation than of the user-desired result.  Unless this new
 version becomes the active one (i.e., the one upon which the user
 continues to work, assuming they don't close the application), isn't
 the result of the button press better called Keep[ing of a] backup
 version?

I'm happy to entertain other terminology. All I'm really trying to get
across is that, technically, this action is strictly not what I
interpreted as keep a copy in the presence of versions, and I don't
want to confuse the terminology later by mixing up the terms.

I'd be equally satisfied, I think, by finding a better term for what
I'm presently describing as keep a copy, wherein a brand new tree_id
is assigned to the copy, detaching it from the history (and
collaboration scope) of the original. The fundamental issue is whether
or not version/collaboration history is retained with the action, so
let's ensure that we name both of these types of copy operations at
the same time, even if we only have one of them for now, so that it
can be extended later.

Ben's suggestion of checkpoint could work. Perhaps Keep checkpoint
would be better to retain the action. You're right that it's more like
keep backup versionthat is, the keep operation which retains the
tree_id basically writes the current state of the activity as a
version (the just-now-previous one), and allows you to continue
working in the most current one. No branching, in the traditional
sense, happens here.

Eben

  Regards,
 
  Tomeu

 Eben


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


Re: [Sugar-devel] Nobody understands Keep

2009-07-10 Thread Eben Eliason
On Fri, Jul 10, 2009 at 10:29 AM, Tomeu Vizosoto...@sugarlabs.org wrote:
 On Fri, Jul 10, 2009 at 16:25, Eben Eliasone...@laptop.org wrote:
 On Fri, Jul 10, 2009 at 10:05 AM, Martin
 Denglermar...@martindengler.com wrote:
 On Fri, Jul 10, 2009 at 10:01:19AM -0400, Eben Eliason wrote:
 On Fri, Jul 10, 2009 at 5:28 AM, Tomeu Vizosoto...@sugarlabs.org wrote:
  But are you meaning that we should name the current one Keep a copy
  and when we have versions add Keep?

 No, no. I'm urging that we name it Keep new version now if we rename
 it, so that it's meaning doesn't change down the road when versions
 are introduced.

 Keep new version seems a lot closer to a description of the
 implementation than of the user-desired result.  Unless this new
 version becomes the active one (i.e., the one upon which the user
 continues to work, assuming they don't close the application), isn't
 the result of the button press better called Keep[ing of a] backup
 version?

 I'm happy to entertain other terminology. All I'm really trying to get
 across is that, technically, this action is strictly not what I
 interpreted as keep a copy in the presence of versions, and I don't
 want to confuse the terminology later by mixing up the terms.

 I'd be equally satisfied, I think, by finding a better term for what
 I'm presently describing as keep a copy, wherein a brand new tree_id
 is assigned to the copy, detaching it from the history (and
 collaboration scope) of the original. The fundamental issue is whether
 or not version/collaboration history is retained with the action, so
 let's ensure that we name both of these types of copy operations at
 the same time, even if we only have one of them for now, so that it
 can be extended later.

 Ben's suggestion of checkpoint could work. Perhaps Keep checkpoint
 would be better to retain the action. You're right that it's more like
 keep backup versionthat is, the keep operation which retains the
 tree_id basically writes the current state of the activity as a
 version (the just-now-previous one), and allows you to continue
 working in the most current one. No branching, in the traditional
 sense, happens here.

 Should we discuss this in sugar-devel? Why not asking any of the
 teachers in IAEP what is more natural for them?

Makes sense to me, as long as we can convey to them first the
distinction between the two. The problem at hand is that keep a copy
makes perfect sense, until you toss in this alternate action to
confuse things.

As another note, I have another reason why I interpreted keep a copy
to mean new tree_id, and not just new version. Looking at the design
mockups for the action/object views of the Journal, we designed the
object view to show only the most recent version of any object. That
is, each object is represented just once in that list. Here, it seems
like keep a copy should mean give me a new object in this list;
Keeping a version is just an action which snapshots a previous state
of the current object, without making a true copy of it.

Maybe we could always refer to versions as history in Sugar (seems
logical, given the Journal metaphor!). Then, we could call what the
new tree_id case keep a copy as I initially suggested, and the new
version_id case keep in history, to indicate that pressing it will
add a new listing in the history of the current object.

Eben

 Regards,

 Tomeu

 Eben

  Regards,
 
  Tomeu

 Eben




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


Re: [Sugar-devel] Datastore redesign

2009-07-09 Thread Eben Eliason
On Thu, Jul 9, 2009 at 8:00 AM, Tomeu Vizosoto...@sugarlabs.org wrote:
 On Mon, Jul 6, 2009 at 16:33, Eben Eliasone...@laptop.org wrote:
 On Mon, Jul 6, 2009 at 10:02 AM, Sascha
 Silbesascha-ml-ui-sugar-de...@silbe.org wrote:
 On Mon, Jul 06, 2009 at 12:29:53PM +0200, Tomeu Vizoso wrote:

 Agreed. I have to say that your proposal is excellent, congratulations!

 Thanks, I'm flattered. :)


 Is the asynchronous API design useful enough to warrant more complex
 implementation?

 I'm not sure, but I think that whatever decision we take should be
 made based on actual usage of the DS. What about proposing an example
 of how an existing activity would be modified to use the new API?

 OK, will work on one.


  - For save() calls activity needs to wait for result (containing new
    version_id) before it can invoke save() again for the same object
    which can take quite some time if save() is sync - especially if other
    activities are saving at the same time.

 What about having a separate call that returns synchronously a new
 tree_id and/or version_id?

 Interesting idea, need to think about it. As we're going to use UUIDs not
 using requested versions shouldn't be an issue (for other version number
 schemes like the one you propose below holes in the numbering could be
 troublesome).

 I think holes can be expected, so we should definitely be prepared for 
 them.


 Making the API fully asynchronous is the cause for much of the complexity
 of
 my proposal, but if we eliminate the queueing the response times for
 write
 accesses and checkout() can be very long even for unrelated operations.

 Why for unrelated operations?

 Because we're serializing VCS operations. They are IO bound (more
 specifically: disk bound) and parallelisation would only lead to IO
 starvation, especially for HDDs.


 # do we want an optimized way to determine (only) the branch HEADs of
 a given tree_id?

 This depends on the intended UI. My opinion is that if we branch at
 every interesting modification (triggered by the activity detecting an
 interesting change or by the user clicking on the Keep button), we

 I don't think we need to branch in these instances. These events
 should create new versions, but not necessarily new branches.

 In my proposal, branch is not a concept directly exposed to the user.
 Is just an artefact that allows the journal to display the relevant
 info to an user. If we branch at the following events, displaying only
 HEADs of branches in the journal list view makes sense for the user:

 - new tree_id,
 - resume entry,
 - keep button,
 - after a big change in the activity model (user deletes the whole
 drawing, etc).

 There are other ways to manage what we want, but this approach made it
 very easy to implement.

 Just to make sure I'm understood, I see why using branches this way
 may seem conceptually wrong, it's not how we would work in a VCS or
 CMS. But by creating new branches at those points and displaying only
 HEADs of branches in the list view is the simplest way I found of
 displaying the relevant entries in a robust way (resisting activity
 crashes).

That's fine, assuming these are actually the entries we want to show,
but I'm not sure that's always the case. For instance, we might show
only the most recent version in the object view, while showing each
version within the action view. If we store action-objects as Ben
proposed, we may have an entirely different way of querying what
should be shown in the actions view anyway.

We've also had some ideas on how to expose the branching structure
within the version popup, in which case branching as one would in a
VCS would make more sense.

Eben

 would like to display in the object list all the HEADs of each branch
 in each tree_id. In that case yes, we need a way to retrieve that list
 that is fast on both the client and the server side.

 My imagined usage of branches was to create them automatically upon altering
 a non-HEAD version.

 This makes sense to me, personally.

 A user basing off an old version could mean the newer version is broken
 (in that case promoting the new version to the HEAD of the current branch
 makes more sense) or that (s)he uses the older version as a kind of template
 to create derivates (so creating a branch would make most sense).
 But I'm open to alternative suggestions. We'd most likely need a way to
 explicitly create branches then.


 # using symlink instead of hardlink for incoming queue since we want
 to support directory trees, not just files

 What justifies this new requirement?

 That it's
 a) of use to activities (IIRC some of them use ZIP files right instead now),

 This has its own merits, though. Encapsulating the related files as a
 single archive makes transporting the file around, or sending it to a
 friend, trivial. It's good for the same reason that activity bundles
 are good.

 But this may be considered an internal implementation detail of the
 DS, unless we want to support users directly 

Re: [Sugar-devel] Nobody understands Keep

2009-07-09 Thread Eben Eliason
On Thu, Jul 9, 2009 at 8:03 AM, Gary C Marting...@garycmartin.com wrote:
 On 9 Jul 2009, at 11:29, Martin Dengler wrote:

 On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote:
 On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote:
 On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote:
 Nobody in the world seems to understand the Keep button. People
 think
 it's for regular saving and you should do it before you close or
 switch
 away from your activity.

 +1


 That's not far from the truth, right?  At least in any work-losing
 or
 surprising way...

 It's far from the truth in that it's not normally what you want to
 do.

 My quoting-foo is bad, so I've caused confusion (in myself, too :)).

 To save your work, simply click the Stop button or change so that
 another activity has focus. If you click Keep, you'll end up with 2
 copies - one from when you clicked Keep, and one from when you
 clicked
 Stop (or focused on another activity).

 As far as I understand it, Keep is useful for these types of
 scenarios:
 - you've done a lot of work but now it's time to refactor/
 reorganize the
 whole thing. However you want to keep a copy of the rough version you
 have now, as insurance or perhaps for reference while you re-mangle
 the work.

Exactly.

 - you've made a template for something, now you want to save that
 template (as a blank template) before starting on a version where you
 fill in the content.

Not exactly. This would work, but I wouldn't call this a recommended
use. To start a new document from a template, it would be more
appropriate to Create a copy (which should exist in the Journal
itself), or Keep a copy (which would do the same thing, but from
within the activity)

 This is a great explanation -- it should be in the HIG or something.

 Hmmm, this still does not cover the special behaviour that Sugar now
 treats those Journal entries with. All these entries will have the
 same activity_id, Sugar shell uses this ID to know if it already has

Yes, that's intended. Keep actually means Keep a new version We
don't have proper versions yet, but that's the model.

 an Activity resumed. If an Activity with a matching activity_id is
 already instanced, resuming one of the older/newer entries will just
 switch you to the existing instance (with no change of content).
 Collaborating, with the Sugar shell treating any single entry in this
 long chain of entries as the same, is likely to cause quite some
 confusion for those involved as well...

 Perhaps visually showing all 'kept' entries as one single block (not
 multiple entries), with the past ones visually  'depreciated' in some

This was our thought behind the design mockups for the object view.
There would be one entry per object in the list, with a way to expand
or reveal past versions.

The opposite, however, is true of the design for the action list. Each
version is created as part of a unique activity session, so each of
these would be recorded as a distinct action, and refer to the
associated version.

 way (like old undo states), might help? Perhaps the keep button is
 just wrong altogether.

I think it's really important to have a manual method of invoking the
equivalent of saving. Maybe labeling the Keep button something
like Keep extra version would help.

 Maybe Sascha's GSoC version work will help us sort out the correct
 behaviour here.

Yes, it may.

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] Nobody understands Keep

2009-07-09 Thread Eben Eliason
On Thu, Jul 9, 2009 at 8:03 AM, Tomeu Vizosoto...@sugarlabs.org wrote:
 On Thu, Jul 9, 2009 at 12:29, Martin Denglermar...@martindengler.com wrote:
 On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote:
 On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote:
  On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote:
   Nobody in the world seems to understand the Keep button. People think
   it's for regular saving and you should do it before you close or switch
   away from your activity.
 
  That's not far from the truth, right?  At least in any work-losing or
  surprising way...

 It's far from the truth in that it's not normally what you want to
 do.

 My quoting-foo is bad, so I've caused confusion (in myself, too :)).

 To save your work, simply click the Stop button or change so that
 another activity has focus. If you click Keep, you'll end up with 2
 copies - one from when you clicked Keep, and one from when you clicked
 Stop (or focused on another activity).

 As far as I understand it, Keep is useful for these types of scenarios:
 - you've done a lot of work but now it's time to refactor/reorganize the
 whole thing. However you want to keep a copy of the rough version you
 have now, as insurance or perhaps for reference while you re-mangle
 the work.
 - you've made a template for something, now you want to save that
 template (as a blank template) before starting on a version where you
 fill in the content.

 This is a great explanation -- it should be in the HIG or something.

 But the biggest problem is how do we explain this to users without
 them having to read the HIG (or manual)?

 Should be called Keep a copy?

Careful, here. keep a copy really is a fundamentally different
action. Keeping a copy will result in a new tree_id; Just keeping (or
keeping a new version) will only result in a new version_id. We need
to find a way to make these actions distinct.

Eben


 Regards,

 Tomeu

 Daniel

 Martin

 ___
 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] Nobody understands Keep

2009-07-09 Thread Eben Eliason
On Thu, Jul 9, 2009 at 7:55 PM, Eduardo H. Silvahoboprim...@gmail.com wrote:
 2009/7/9 Tomeu Vizoso to...@sugarlabs.org:
 On Thu, Jul 9, 2009 at 12:29, Martin Denglermar...@martindengler.com wrote:
 On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote:
 On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote:
  On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote:
   Nobody in the world seems to understand the Keep button. People think
   it's for regular saving and you should do it before you close or switch
   away from your activity.
 
  That's not far from the truth, right?  At least in any work-losing or
  surprising way...

 It's far from the truth in that it's not normally what you want to
 do.

 My quoting-foo is bad, so I've caused confusion (in myself, too :)).

 To save your work, simply click the Stop button or change so that
 another activity has focus. If you click Keep, you'll end up with 2
 copies - one from when you clicked Keep, and one from when you clicked
 Stop (or focused on another activity).

 As far as I understand it, Keep is useful for these types of scenarios:
 - you've done a lot of work but now it's time to refactor/reorganize the
 whole thing. However you want to keep a copy of the rough version you
 have now, as insurance or perhaps for reference while you re-mangle
 the work.
 - you've made a template for something, now you want to save that
 template (as a blank template) before starting on a version where you
 fill in the content.

 This is a great explanation -- it should be in the HIG or something.

 But the biggest problem is how do we explain this to users without
 them having to read the HIG (or manual)?

 Should be called Keep a copy?

 +1
 For a while, in the pt_PT translation of Sugar I did, I named the Keep
 button as Keep a copy.

I urge again that keep a copy is not what is intended, in the long
run. Without proper versions, of course, this is effectively how it
behaves. Therefore, it's no surprise many saw it this way. But with
versions, the keep button is actually a keep new version button.
As mentioned before, a new version retains the tree_id, whereas a
true copy does not.

Since versions are on the way, we should make sure to clarify the distinction!

Eben



 Regards,

 Tomeu

 Daniel

 Martin

 ___
 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] Datastore redesign

2009-07-06 Thread Eben Eliason
On Mon, Jul 6, 2009 at 10:02 AM, Sascha
Silbesascha-ml-ui-sugar-de...@silbe.org wrote:
 On Mon, Jul 06, 2009 at 12:29:53PM +0200, Tomeu Vizoso wrote:

 Agreed. I have to say that your proposal is excellent, congratulations!

 Thanks, I'm flattered. :)


 Is the asynchronous API design useful enough to warrant more complex
 implementation?

 I'm not sure, but I think that whatever decision we take should be
 made based on actual usage of the DS. What about proposing an example
 of how an existing activity would be modified to use the new API?

 OK, will work on one.


  - For save() calls activity needs to wait for result (containing new
    version_id) before it can invoke save() again for the same object
    which can take quite some time if save() is sync - especially if other
    activities are saving at the same time.

 What about having a separate call that returns synchronously a new
 tree_id and/or version_id?

 Interesting idea, need to think about it. As we're going to use UUIDs not
 using requested versions shouldn't be an issue (for other version number
 schemes like the one you propose below holes in the numbering could be
 troublesome).

I think holes can be expected, so we should definitely be prepared for them.


 Making the API fully asynchronous is the cause for much of the complexity
 of
 my proposal, but if we eliminate the queueing the response times for
 write
 accesses and checkout() can be very long even for unrelated operations.

 Why for unrelated operations?

 Because we're serializing VCS operations. They are IO bound (more
 specifically: disk bound) and parallelisation would only lead to IO
 starvation, especially for HDDs.


 # do we want an optimized way to determine (only) the branch HEADs of
 a given tree_id?

 This depends on the intended UI. My opinion is that if we branch at
 every interesting modification (triggered by the activity detecting an
 interesting change or by the user clicking on the Keep button), we

I don't think we need to branch in these instances. These events
should create new versions, but not necessarily new branches.

 would like to display in the object list all the HEADs of each branch
 in each tree_id. In that case yes, we need a way to retrieve that list
 that is fast on both the client and the server side.

 My imagined usage of branches was to create them automatically upon altering
 a non-HEAD version.

This makes sense to me, personally.

 A user basing off an old version could mean the newer version is broken
 (in that case promoting the new version to the HEAD of the current branch
 makes more sense) or that (s)he uses the older version as a kind of template
 to create derivates (so creating a branch would make most sense).
 But I'm open to alternative suggestions. We'd most likely need a way to
 explicitly create branches then.


 # using symlink instead of hardlink for incoming queue since we want
 to support directory trees, not just files

 What justifies this new requirement?

 That it's
 a) of use to activities (IIRC some of them use ZIP files right instead now),

This has its own merits, though. Encapsulating the related files as a
single archive makes transporting the file around, or sending it to a
friend, trivial. It's good for the same reason that activity bundles
are good.

 b) easy enough to achieve with the new design and
 c) leads to better delta compression and thus disk space effiency.


 # since an index rebuild can take a lot of time we need to provide UI
 feedback while doing that

 Any I/O operation can potentially take a lot of time, but with the
 current version of the DS rebuilding an index with a few thousands of
 entries is not so slow on the XO. We should never need to rebuild the
 index, so this new requirement might not be justified (given the
 current resources, all the other work we need to do, etc).

 OK, good to know index rebuilding is fast. So the simple, boolean API I
 proposed (check_ready() / Ready()) suffices.


 # detecting identical files across objects isn't as important since
 duplicates are mostly expected to occur as versions of the same object

 Based on how current activities are using the DS, this isn't like
 that.
 The most common case I have heard from the field are children
 downloading a PDF for reading several times.

 Oh, didn't know that, so it's a new requirement.

 An alternative to the current method for detecting duplicates is moving
 this task to
 activities, is that what you suggest?

 I'm ambivalent about it. On one hand it's not so easy to achieve in
 datastore (for various backends) and more indicative of UI deficiencies (why

This might be the case, indeed. On other operating systems/browsers,
this (downloading multiple copies if the link is clicked multiple
times) is expected behavior. Perhaps we can work out some ways to make
the UI clearer.

 did the children download the file several times in the first place; it's
 bandwidth wastage as well), on the other hand it might not 

Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

2009-07-06 Thread Eben Eliason
I like these terms, but I don't think they define the split I'm
referring to. object-push and object-pull describe, sending an object
to a friend and taking something from my friend's Journal
respectively. Both of these types of sharing are object-sharing (the
recipient gets the resulting object, with a new tree_id).

The more I think about it, I kind of like the object-sharing and
activity-sharing distinction, since in all of our high-level
outlines of Sugar we break the UI down into 3 core components: people,
activities, and objects. In this paradigm, we have:

object-sharing: the transfer of objects from people to people, via
push (send to) or pull (view published journal)
activity-sharing: collaboration among two or more people within an
activity, acting on a shared object or objects

Can someone phrase this more clearly?

Eben


On Mon, Jul 6, 2009 at 10:56 AM, Benjamin M.
Schwartzbmsch...@fas.harvard.edu wrote:
 Eben Eliason wrote:
 PS. I think we need to come up with some better terminology to
 distinguish between collaboration sharing and journal sharing. That
 would make this much easier to talk about.

 I've been using the terms object push and object pull.

 --Ben


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


Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

2009-07-04 Thread Eben Eliason
On Sat, Jul 4, 2009 at 2:00 AM, Andrés Ambroisandresambr...@gmail.com wrote:
 On Saturday 04 July 2009 12:31:48 am Eben Eliason wrote:
 On Fri, Jul 3, 2009 at 11:19 PM, Gary C Marting...@garycmartin.com wrote:
  On 4 Jul 2009, at 03:13, Eben Eliason wrote:

 snip

  PS. I think we need to come up with some better terminology to
  distinguish between collaboration sharing and journal sharing. That
  would make this much easier to talk about.
 
  You're not kidding there :-)

 should we call both sharing, but differentiate it with a modifier,
 like collaboration vs. document, or maybe activity vs. object.
 This latter might be the best I've thought of so far. activity
 sharing is real-time collaboration; object-sharing is public
 Journal entries, the output. Thoughts? Better suggestions?

 How about publishing? It seems to me the most concise way to express the
 action of making content available to a wider audience.

That's a pretty good suggestion. The only aspect of the problem this
doesn't seem to cover nicely is the direct object transfer from child
A to child B. This form of transfer is of the object-sharing kind,
but I'm not sure publishing is the right term to cover it.  I would be
quite happy to describe all aspects of the Journal interface for
making things public as publishing, though.

Eben

 Eben

  Regards,
  --Gary

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

 --
  -Andrés

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


Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

2009-07-03 Thread Eben Eliason
On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com wrote:
 On 2 Jul 2009, at 14:47, Eben Eliason wrote:

 On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote:

 But in that case we should provide possibility to mark objects that can
 be shared(I guess sharing all local objects by default is not a nice
 idea).

 Right. This would be essential. There's definitely some thought that
 needs to be done here.

 Scott had an interesting proposal which basically exposed the Journal
 (or some subset of it) as an RSS feed. This was really neat, because
 it meant we could build a UI for someone else's Journal in Sugar,
 populating it with that data, but also that these feeds could be
 shared globally, for anyone with an RSS reader to benefit from. That's
 a really powerful approach in my mind, and there is some starter code
 lying around as a proof of concept already!


 +1 to rss feed concept, makes life a lot easier in a heterogeneous
 environment.

 I'm still catching up on email so apologies if this has been mentioned
 already. But the UI for marking of entries as sharable does not necessarily
 need to be another Journal user-interface addition** In the simplest
 approach you could just extend the Activity Share with: my Neighbourhood
 control to mark a Journal entry as part of the RRS feed. Would need some

The problem I see with this is that we're talking about two different
kinds of sharing. Just because I want to make a picture I drew
available for anyone to look at, or even make a photocopy of to
scribble on, doesn't mean that I want to let them into a shared
painting session so they can scribble on the original with me.

This is the difference between sharing an activity with someone
collaboratively, and sending them (a copy of) the resulting object.

 thought on wording, do you add more levels of sharing? Or do you just
 simplify the Share with: language language to Private, Share with:
 Anyone.

 **though I would like entries to visually show their sharing state, the
 buddy column hints at this but should be made explicit

I do actually think that the Journal is the best place to expose this,
especially since the way we plan to expose the feature in the UI is
something like view my friend's Journal. I'm not sure exactly how
or where that happens. Perhaps if we can abandon the checkbox for the
multi-selection we can use that space for a public/private toggle of
some kind.

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


Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

2009-07-03 Thread Eben Eliason
On Fri, Jul 3, 2009 at 7:25 PM, Gary C Marting...@garycmartin.com wrote:
 On 3 Jul 2009, at 23:50, Gary C Martin wrote:

 On 3 Jul 2009, at 18:29, Eben Eliason wrote:

 On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com
 wrote:

 On 2 Jul 2009, at 14:47, Eben Eliason wrote:

 On Wed, Jul 1, 2009 at 1:42 PM, Aleksey
 Limalsr...@member.fsf.org wrote:

 But in that case we should provide possibility to mark objects
 that can
 be shared(I guess sharing all local objects by default is not a
 nice
 idea).

 Right. This would be essential. There's definitely some thought that
 needs to be done here.

 Scott had an interesting proposal which basically exposed the
 Journal
 (or some subset of it) as an RSS feed. This was really neat, because
 it meant we could build a UI for someone else's Journal in Sugar,
 populating it with that data, but also that these feeds could be
 shared globally, for anyone with an RSS reader to benefit from.
 That's
 a really powerful approach in my mind, and there is some starter
 code
 lying around as a proof of concept already!


 +1 to rss feed concept, makes life a lot easier in a heterogeneous
 environment.

 I'm still catching up on email so apologies if this has been
 mentioned
 already. But the UI for marking of entries as sharable does not
 necessarily
 need to be another Journal user-interface addition** In the simplest
 approach you could just extend the Activity Share with: my
 Neighbourhood
 control to mark a Journal entry as part of the RRS feed. Would need
 some

 The problem I see with this is that we're talking about two different
 kinds of sharing. Just because I want to make a picture I drew
 available for anyone to look at, or even make a photocopy of to
 scribble on, doesn't mean that I want to let them into a shared
 painting session so they can scribble on the original with me.

 This is the difference between sharing an activity with someone
 collaboratively, and sending them (a copy of) the resulting object.

 Devils advocate here, so just because someone was late to the realtime
 party, they don't get to download an otherwise openly published piece
 of work that could be re-published at any time by any of the
 temporally lucky contributors? Downloading a Journal entry would not

I think you misunderstand me, as I think I'm arguing exactly the
opposite. I wouldn't want to deprive people the ability to download
finished works because the sharer doesn't want to open the document up
for public collaboration. The distinction is important, so that it's
possible to share things with others without having to make my own
documents open to collaboration.

 allow you in anyway to edit the remote users copy, you'd just get a
 snapshot downloaded to your Journal as if they had performed an
 equivalent Send to function.

Exactly. If you conflate public vs. private states for documents with
the collaboration sharing scope, every public document would also be
open for public collaboration, which might not be desired, and might
discourage people from sharing their output.

 Replying to myself, always a bad sign ;-)

 Use case: Darn, I missed the weekly project chat meeting, AGAIN... Oooh,
 Bob is still online, let me see if I can download the meeting activity
 entry.

This might not be the best example, since by definition the chat
meeting is an open collaboration, with a neighborhood (for example)
sharing scope.

 Misc supporting argument: If you default to Journal sharing OFF and make it
 a new separate manual public sharing UI tick box/setting (required for

I'm not necessarily stating that it should be off by default
(everything private). I'm simply arguing that it should be independent
of the collaboration scope. What may make sense (maybe this is what
you meant?) is to default all documents which become shared with the
neighborhood to public, while all others would default to private.

Eben

PS. I think we need to come up with some better terminology to
distinguish between collaboration sharing and journal sharing. That
would make this much easier to talk about.


 privacy), folks will rarely set it, there will be little to share from
 someone else's Journal so you'll rarely bother looking for something
 remotely. Changing the Activity sharing language from Share with:
 Neighbourhood to Share with: Anyone, means both synchronous and
 asynchronous sharing could happen, suddenly allows deployments to
 automatically** cross pollinate content and activities as folks move from
 otherwise isolated network islands.

 **by automatically, I mean that the sharer has not needed to be asked to
 provide specific access to some entry, if it already was public, then it is
 shared. Though this does suggest to me that we should finally be allowed to
 un-publicly share an entry if desired (a manual choice); and perhaps a
 global manual setting for deployments/users to switch of all Journal
 sharing.

 Regards,
 --Gary


___
Sugar

Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

2009-07-03 Thread Eben Eliason
On Fri, Jul 3, 2009 at 9:52 PM, Andrés Ambroisandresambr...@gmail.com wrote:
 On Friday 03 July 2009 02:29:56 pm Eben Eliason wrote:
 On Fri, Jul 3, 2009 at 10:42 AM, Gary C Marting...@garycmartin.com wrote:
  On 2 Jul 2009, at 14:47, Eben Eliason wrote:
  On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org
 wrote:
  But in that case we should provide possibility to mark objects that can
  be shared(I guess sharing all local objects by default is not a nice
  idea).
 
  Right. This would be essential. There's definitely some thought that
  needs to be done here.
 
  Scott had an interesting proposal which basically exposed the Journal
  (or some subset of it) as an RSS feed. This was really neat, because
  it meant we could build a UI for someone else's Journal in Sugar,
  populating it with that data, but also that these feeds could be
  shared globally, for anyone with an RSS reader to benefit from. That's
  a really powerful approach in my mind, and there is some starter code
  lying around as a proof of concept already!
 
  +1 to rss feed concept, makes life a lot easier in a heterogeneous
  environment.
 
  I'm still catching up on email so apologies if this has been mentioned
  already. But the UI for marking of entries as sharable does not
  necessarily need to be another Journal user-interface addition** In the
  simplest approach you could just extend the Activity Share with: my
  Neighbourhood control to mark a Journal entry as part of the RRS feed.
  Would need some

 The problem I see with this is that we're talking about two different
 kinds of sharing. Just because I want to make a picture I drew
 available for anyone to look at, or even make a photocopy of to
 scribble on, doesn't mean that I want to let them into a shared
 painting session so they can scribble on the original with me.

 This is the difference between sharing an activity with someone
 collaboratively, and sending them (a copy of) the resulting object.

  thought on wording, do you add more levels of sharing? Or do you just
  simplify the Share with: language language to Private, Share with:
  Anyone.
 
  **though I would like entries to visually show their sharing state, the
  buddy column hints at this but should be made explicit

 I do actually think that the Journal is the best place to expose this,
 especially since the way we plan to expose the feature in the UI is
 something like view my friend's Journal. I'm not sure exactly how
 or where that happens. Perhaps if we can abandon the checkbox for the
 multi-selection we can use that space for a public/private toggle of
 some kind.

 How about using special tags? A Publish tag seems reasonable for this, and
 consistent with the fact that it could live in a publish directory an HTTP
 server would serve.

I think it's a good idea to store these states as metadata, but I also
think that we need to expose the feature visually to highlight the
capability and make it easier to manage. I wouldn't want kids to have
to type publish into the correct field in order to share their work.

 I can also imagine a tags used for starred entries and other metadata (in a
 general sense) used by sugar. This would make them searchable as well.

Yup. I don't think this works yet, but the intent has always been to
allow advanced search queries by specifying key:value pairs (as in
gmail). In fact, all of the filters we support should have text
equvalents, eg. cat kind:image with:alice favorite:yes (or similar).

Eben


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

 --
  -Andrés

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


  1   2   >