Re: [sugar] journal is hard (was Re: notes from the field - Mongolia)
basically when teachers and students try to find their work (write, record, etoys) in the journal it is hard for them to locate it - especially if it is more than a few days old. This is why everyone is desperate to save their projects on USB keys. Also it seems that everything doesn't always go there. For example sometimes the pictures from a session in record are there - sometimes they aren't - sometimes it's just one picture - sometimes none. I have seen this many times - again it's why everyone wants to save on a USB right away. do you need more detail than that? On Thu, Oct 9, 2008 at 5:07 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > Hi, > > On Mon, Oct 6, 2008 at 5:20 PM, elana langer <[EMAIL PROTECTED]> wrote: >> >> 3) Basically - The journal is really hard for people/ kids to use over >> a longer period of time. Kids and teachers can't find things that they >> did unless it was done within the last 30 minutes. > > Could you please elaborate on the difficulties that people have when > using the journal? > > Thanks, > > Tomeu > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal is hard (was Re: notes from the field - Mongolia)
Elana Langer wrote from Mongolia: > basically when teachers and students try to find their work (write, > record, etoys) in the journal it is hard for them to locate it - > especially if it is more than a few days old. This is why everyone is > desperate to save their projects on USB keys. My perception of the above statement is that it is an indictment of the ability of Sugar (vs. traditional computing) to be a convincing tool for teachers (and for the students those teachers influence). When users are "desperate to save their projects on USB keys" (something that was not a principal intent of Sugar), there is something out of whack. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal is hard (was Re: notes from the field - Mongolia)
On 9 Oct 2008, at 19:57, Mikus Grinbergs wrote: > Elana Langer wrote from Mongolia: >> basically when teachers and students try to find their work (write, >> record, etoys) in the journal it is hard for them to locate it - >> especially if it is more than a few days old. This is why everyone is >> desperate to save their projects on USB keys. > > My perception of the above statement is that it is an indictment of > the ability of Sugar (vs. traditional computing) to be a convincing > tool for teachers (and for the students those teachers influence). > > When users are "desperate to save their projects on USB keys" > (something that was not a principal intent of Sugar), there is > something out of whack. Yes, this is an interesting custom getting started. I've been installing and running both release and development builds on an XO B4 since January. Managed to loose my Journal content just once, and that was a development build while I was jumping between old- data store and new data-store changes. I still had all the individual files but (my best guess), some other necessary custom magic index file for the DS had been damaged. With that said, I've not knowingly lost a Journal entry in all that time. I'm tempted to think that in these reported cases, the entries are all still in the Journal, and it's the difficulty in locating them again that is the primary issue. Given that assumption, making sure both teachers and students give their work meaningful titles may make a world of difference for them. One thing I like to do is use the title to help group entries logically together. Example: Turtle lesson plan question 1 Turtle lesson plan question 2 Turtle lesson plan question 3 Turtle lesson plan question 4 ... etc Turtle lesson plan question notes Turtle lesson plan screenshots I can then switch to Journal and type 'turtle lesson plan' for all of this to appear, or 'lesson 2' just for that lesson plan etc. You could also use the tag field, and/or the description field, but they are currently hidden away in the Journal and not quick enough to get to or find. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal is hard (was Re: notes from the field - Mongolia)
On Thu, Oct 9, 2008 at 7:18 PM, elana langer <[EMAIL PROTECTED]> wrote: > basically when teachers and students try to find their work (write, > record, etoys) in the journal it is hard for them to locate it - > especially if it is more than a few days old. What I would love to read from you is an analysis of which are the concrete difficulties that users are having when trying to find stuff in the journal, and then work with us in improving how the journal works so that users can more easily find their work. As you know, the Journal is one of the most immature parts in Sugar, thus this is a good moment to improve what is worth keeping and drop what is better to not have there. The feedback you are able to provide is critical to this improvement process. > This is why everyone is > desperate to save their projects on USB keys. Does this happen in all other deployment sites? > Also it seems that > everything doesn't always go there. For example sometimes the pictures > from a session in record are there - sometimes they aren't - sometimes > it's just one picture - sometimes none. I have seen this many times - > again it's why everyone wants to save on a USB right away. Record creates several entries in the journal: one per video, one per photo, one per audio recording and one to tie them all together. Maybe this is confusing users? Thanks, Tomeu > On Thu, Oct 9, 2008 at 5:07 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: >> Hi, >> >> On Mon, Oct 6, 2008 at 5:20 PM, elana langer <[EMAIL PROTECTED]> wrote: >>> >>> 3) Basically - The journal is really hard for people/ kids to use over >>> a longer period of time. Kids and teachers can't find things that they >>> did unless it was done within the last 30 minutes. >> >> Could you please elaborate on the difficulties that people have when >> using the journal? >> >> Thanks, >> >> Tomeu >> > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal is hard (was Re: notes from the field - Mongolia)
On Fri, Oct 10, 2008 at 8:45 AM, Garrett Goebel <[EMAIL PROTECTED]> wrote: > Elana Langer wrote from Mongolia: >> basically when teachers and students try to find their work (write, >> record, etoys) in the journal it is hard for them to locate it - >> especially if it is more than a few days old. This is why everyone is >> desperate to save their projects on USB keys. > > This could be made much easier if Sugar apps prompted the user for > tags when shutting down an application. Yes, I think we need to assume this model. I don't think this is going to break the basic paradigm of Sugar, since this prompt need only happen for *new* activities. Anything which has been previously kept in the Journal will continue to autosave. It's only the first time that you *really* need to give a meaningful title, and also then that you might decide it's not worth keeping at all. > I know it is a goal to require as little text as possible. And I'm not > sure what images could universally convey the message correctly... but > basically: > > Would you like to tag the state of this activity? Y/N > > ...followed by a prompt for the user to enter tags. We can do a little better than that, actually, by making it all one prompt. It can have a name field, already filled out with the best darn attempt at a name we can manage, a tag field (and perhaps even a list of popular tags as well, to apply to it with a click or a drag/drop), and buttons for [Erase] (Or [Don't Keep]?) and [Keep]. - Eben > cheers, > > Garrett > ___ > Devel mailing list > [EMAIL PROTECTED] > http://lists.laptop.org/listinfo/devel > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal is hard (was Re: notes from the field - Mongolia)
> > This could be made much easier if Sugar apps prompted the user for
> > tags when shutting down an application.
>
> Yes, I think we need to assume this model. I don't think this is
> going to break the basic paradigm of Sugar, since this prompt need
> only happen for *new* activities. Anything which has been previously
> kept in the Journal will continue to autosave.
Warning -- when you tell the system to shut down, from the XO-man menu,
some existing Sugar apps are hanging instead, prompting the user about
whether to save a useless Journal entry about themselves, or whether to
just quit. I noticed this in a late 8.2.0.
(A normal Linux shell "shutdown now" command will tell all processes
to terminate ("kill -TERM"), wait about 30 seconds to give them all a
chance to do it nicely, then will kill any remaining ones off nastily
("kill -KILL") and shut down the system. I didn't wait around long
enough to see whether Sugar's shutdown hung forever, or did that too.
I strongly recommend that Sugar reimplement what long experience has
showed was useful: do what the user told you to, don't let individual
activities make the system hang forever by asking stupid questions.)
John
PS: Wasn't Sugar going to be a modeless, promptless GUI for pre-literate
people? :-/
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal is hard (was Re: notes from the field - Mongolia)
> We can do a little better than that, actually, by making it all one > prompt. It can have a name field, already filled out with the best > darn attempt at a name we can manage, a tag field (and perhaps even a > list of popular tags as well, to apply to it with a click or a > drag/drop), and buttons for [Erase] (Or [Don't Keep]?) and [Keep]. > A little better solution would be if the words in the name would be treated as tags and if the save "dialog" would offer autocomplete for those tags. Tagging via the Journal could just set words to "super" tags so they would not be shown in the name but would be handled "harder" than "soft" tags in searching or in the proposed tag submenu thing. If the user would type in the tag via autocompletion then it should be treated as an explicit tag. I am not sure if you can understand it so here is another try from the opposite side: The problem with tagging is that it is painful to select something on the XO from a drop down menu (the list of available tags). (Note that developing Sugar on a Linux PC is cheating...) The whole notion of explicit tagging is also a nuisance and requiring tagging at save time is painful. So this proposal just tries to simplify the process from the user's perspective (and makes coding the Journal very very hard, but since somebody other than me will code it I do not care...). Autocompleting, not only tags but "soft" tags too, would result in that if the user is doing some project lately then the system would offer him the project's name since probably it would be used lately a lot. Also it could be used for filesystem paths as well but probably I should see that GNOME UI Hackfest video first. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal is hard (was Re: notes from the field - Mongolia)
On Fri, Oct 10, 2008 at 1:05 PM, NoiseEHC <[EMAIL PROTECTED]> wrote: > >> We can do a little better than that, actually, by making it all one >> prompt. It can have a name field, already filled out with the best >> darn attempt at a name we can manage, a tag field (and perhaps even a >> list of popular tags as well, to apply to it with a click or a >> drag/drop), and buttons for [Erase] (Or [Don't Keep]?) and [Keep]. >> > > A little better solution would be if the words in the name would be treated > as tags and if the save "dialog" would offer autocomplete for those tags. I think tag autocompletion is a definite must, to get this system off the ground. > Tagging via the Journal could just set words to "super" tags so they would > not be shown in the name but would be handled "harder" than "soft" tags in > searching or in the proposed tag submenu thing. If the user would type in > the tag via autocompletion then it should be treated as an explicit tag. I don't have a clear image in my head from this description, but I do see the direction you're heading, and it's interesting. I'm not sure exactly how the titles are handled right now, but the idea of auto-completing within the title field, in some form, might have promise. An interesting twist on this might be to look for "related" Journal entries based on the title typed thus far, in order to provide a list of most likely tags to choose from for the entry (tags which are also applied to other things with similar titles, mime-types, etc.). In this manner, once a base set of tags were in use in the Journal, tagging could become as simple as saying "yes, these three things you suggest actually do apply to this thing I made", and then optionally "and maybe this one other new tag, too". In a sense, this means that tagging is almost free, since the process of creating a good title will provide a solid set of tags to choose from. Tagging becomes an extension of naming, rather than a separate task. > I am not sure if you can understand it so here is another try from the > opposite side: > > The problem with tagging is that it is painful to select something on the XO > from a drop down menu (the list of available tags). (Note that developing Right, this is why I think intelligent filtering of the list of suggested tags is also needed. > Sugar on a Linux PC is cheating...) The whole notion of explicit tagging is > also a nuisance and requiring tagging at save time is painful. So this > proposal just tries to simplify the process from the user's perspective (and > makes coding the Journal very very hard, but since somebody other than me > will code it I do not care...). Autocompleting, not only tags but "soft" > tags too, would result in that if the user is doing some project lately then > the system would offer him the project's name since probably it would be > used lately a lot. Also it could be used for filesystem paths as well but > probably I should see that GNOME UI Hackfest video first. Hmm, I'm not sure that autocompletion on full titles is beneficial (that might not be what you're suggesting) because we want to discourage identical names, rather than encourage them. On the other hand, offering completion of words within the title based on tags is interesting. Would these "soft tags" (tags auto-completed in the title) also appear in the tag field? How would we make the system evident? Maybe it's still most clear if the title just serves as a seed for the recommended tags (some of which might be verbatim in the title) so that a few clicks can apply all those relevant. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal is hard (was Re: notes from the field - Mongolia)
On Sun, Oct 12, 2008 at 1:40 PM, elana langer <[EMAIL PROTECTED]>wrote: > file artifacts in the journal--the process went something like > this-insert a flash drive to the xo that has a lot of files on it from > windows computer, they show up in journal, remove flash drive, erase > many of the files on a windows machine, use the flash drive with > windows, mac and linux computers for a couple weeks, put it back in > the XO and old files that have been deleted are still cluttering up > the journal in usb view mode. > This is going to be fixed for 9.1. > In 650 and 656 the team saw a few instances of the journal > disappearing-reinstalling the journal activity fixed this. > I think 8.2 should be much better from this respect. But a really solid solution will be available only with 9.1. Thanks, Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal is hard (was Re: notes from the field - Mongolia)
Here are some notes from Cris Anderson, one of my interns this summer who is fluent in Mongolian. Because of his language and technical skills he heard a lot of these issues first hand. >From Cris: Tech problems I have noticed: file artifacts in the journal--the process went something like this-insert a flash drive to the xo that has a lot of files on it from windows computer, they show up in journal, remove flash drive, erase many of the files on a windows machine, use the flash drive with windows, mac and linux computers for a couple weeks, put it back in the XO and old files that have been deleted are still cluttering up the journal in usb view mode. The team had a hard time remembering all the services that need turned on when setting up a server. configuring to always start all necessary server services at runtime would help. In 650 and 656 the team saw a few instances of the journal disappearing-reinstalling the journal activity fixed this. When using an activity customization key, the additional Scratch Media and Project files and folders were not unzipped/installed with the activity. the team and teachers depend on that media to be there for teaching purposes olpc-update froze up and didn't do anything when going from 656 to 703. A work-around still needs to be developed for the 1000 pilot XOs that don't type in Mongolian. Either manufacturing data needs adjusted to auto-configure to the English/Mongolian hybrid keyboard, or a keyboard config file hack needs to be done (though this would be subsequently over-written in later OS updates). A language pack update option would be a good Sugar Control Panel addition Tomeu, in terms of the questions you asked below I will respond shortly. Elana On Fri, Oct 10, 2008 at 9:02 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > On Thu, Oct 9, 2008 at 7:18 PM, elana langer <[EMAIL PROTECTED]> wrote: >> basically when teachers and students try to find their work (write, >> record, etoys) in the journal it is hard for them to locate it - >> especially if it is more than a few days old. > > What I would love to read from you is an analysis of which are the > concrete difficulties that users are having when trying to find stuff > in the journal, and then work with us in improving how the journal > works so that users can more easily find their work. > > As you know, the Journal is one of the most immature parts in Sugar, > thus this is a good moment to improve what is worth keeping and drop > what is better to not have there. The feedback you are able to provide > is critical to this improvement process. > >> This is why everyone is >> desperate to save their projects on USB keys. > > Does this happen in all other deployment sites? > >> Also it seems that >> everything doesn't always go there. For example sometimes the pictures >> from a session in record are there - sometimes they aren't - sometimes >> it's just one picture - sometimes none. I have seen this many times - >> again it's why everyone wants to save on a USB right away. > > Record creates several entries in the journal: one per video, one per > photo, one per audio recording and one to tie them all together. Maybe > this is confusing users? > > Thanks, > > Tomeu > >> On Thu, Oct 9, 2008 at 5:07 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: >>> Hi, >>> >>> On Mon, Oct 6, 2008 at 5:20 PM, elana langer <[EMAIL PROTECTED]> wrote: 3) Basically - The journal is really hard for people/ kids to use over a longer period of time. Kids and teachers can't find things that they did unless it was done within the last 30 minutes. >>> >>> Could you please elaborate on the difficulties that people have when >>> using the journal? >>> >>> Thanks, >>> >>> Tomeu >>> >> > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal is hard (was Re: notes from the field - Mongolia)
Elana Langer wrote from Mongolia: > basically when teachers and students try to find their work (write, > record, etoys) in the journal it is hard for them to locate it - > especially if it is more than a few days old. This is why everyone is > desperate to save their projects on USB keys. This could be made much easier if Sugar apps prompted the user for tags when shutting down an application. I know it is a goal to require as little text as possible. And I'm not sure what images could universally convey the message correctly... but basically: Would you like to tag the state of this activity? Y/N ...followed by a prompt for the user to enter tags. cheers, Garrett ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
