I did not know there was much debate about this, because for me the journal in its current state made sense for the target audience of sugar. Understanding hierarchical file structures use the concepts of containers and recursion with no limits (except for total capacity). It is not naturally intuitive, like a tree where branches get smaller from the trunk with fruit/leaves only at the end nodes. Empirically I've seen many new people approach computers (non-tech elder-relatives included), and hierarchical structures are not initially utilised. It was a secondary focus that had to be learnt out of necessity. At the time I would say this was due to a lack filters at their disposal. Tools such as GoogleDesktop or, more evidently, OS X "Spotlight" are conceptually more approachable to a beginner/non-tech person, and further defers the need to learn about their tool rather than just using it effectively immediately. Perhaps an activity/game could be made that teaches the concepts of a hierarchical file structure. It could demonstrate inifite recursion with inifinite capacity at each node, but reward "good" storage somehow. Once they complete the game to a certain level, then they can unlock heirarchical file structures in journal? But I think there is enough on everyone plates for now before this gets considered. Cheers, James <div class="gmail_quote">2009/5/27 Tomeu Vizoso <<a href="mailto:tomeu@sugarlabs.org">tomeu@sugarlabs.org</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> [forgot to add IAEP and sugar-devel] ---------- Forwarded message ---------- From: Tomeu Vizoso <<a href="mailto:tomeu@sugarlabs.org">tomeu@sugarlabs.org</a>> Date: Wed, May 27, 2009 at 12:11 Subject: journal criticism (was Re: Re: Re: [IAEP] [RELEASE] TurtleArt-51) To: <a href="mailto:forster@ozonline.com.au">forster@ozonline.com.au</a> Cc: Walter Bender <<a href="mailto:walter.bender@gmail.com">walter.bender@gmail.com</a>> Hi all, see my replies inline below. To everybody who would like to join this conversation: please change the subject line accordingly or this thread will become hard to follow. On Wed, May 27, 2009 at 04:54, <<a href="mailto:forster@ozonline.com.au">forster@ozonline.com.au</a>> wrote: > Hi Tomeu & Walter > > I am happy to expand this to the list. I have raised the journal once or twice before but mainly kept quiet not wanting to be trollish. > > <a href="http://lists.sugarlabs.org/archive/iaep/2008-August/001475.html" target="_blank">http://lists.sugarlabs.org/archive/iaep/2008-August/001475.html</a> > & more but i cant easily find > > > The journal and sharing are probably the two central things that distinguish sugar as as a purpose built learning platform. The team have a huge investment of time and energy and are rightly proud of their achievement. That presents a problem for constructive discussion around the journal, the last thing I want to do is be trollish and destructive. > > For me, the workings behind the journal are hidden and there is a lack of tools to make it do different things when the default operation is not what you want. Also temporal and tagging is fine as a primary method of storage but hierarchical storage is not offered as an alternate method. > > in addition to today's filename issue, other problems that I can remember: > altering the filenames and extensions of email attachments Could you please expand on this use case? > offline web pages do not navigate because the directory structure is lost This is scheduled to be addressed in 0.86 by downloading the page as a zip file and storing that in the journal. > can't inspect or alter mime to force something to open This could be fixed in the journal easily, with no need to refactor or throw out anything. We need more people to help us with developing Sugar further. > journal spam In 0.84 landed several modifications that should improve this somehow, have you seen if that helped? > (I haven't found a way to select a block so every spam item has to be individually deleted Would be awesome to be able to operate on multiple items at once, but unfortunately it hasn't been implemented yet. > resume by default will probably cause students to lose work) Versioning in the journal is scheduled for 0.86, which should address this one. > accidental overwriting of files through autosave Same as in the previous one, if I understand it correctly. >> Thanks for the feedback. >> >> Adding Tomeu, but we should probably expand the discussion to the list. >> >> I cannot argue with you that the fact that the Journal hid information >> from the user is a problem--really I would characterize it as a bug. >> But the goal of the Journal wasn't to simplify (and certainly not to >> hide information from the user) as much as it was to provide a >> representation of the file system that is first and foremost temporal >> rather than hierarchical with an emphasis on annotating, tagging, and >> searching rather than browsing. Secondary goals are automatic >> recording of actions and objects and the ability to extract from the >> Journal highlights. These latter goals could as well be accomplished >> using a hierarchical representation, but still would require a >> database backend of some sort. >> >> -walter >> >> On Tue, May 26, 2009 at 7:18 PM, <<a href="mailto:forster@ozonline.com.au">forster@ozonline.com.au</a>> wrote: >> > Thanks, I now have V51 on my XO >> > >> > Short rant follows: >> > >> > This is another example why I do not like the Journal. The Journal does not preserve filenames or directory structures. The download showed in the Journal as >> > >> > "File turtle_art-51.xo from <a href="http://activities.sugarlabs.org/en-US/sugar/downloads/file/26052/turtle_art-51.xo" target="_blank">http://activities.sugarlabs.org/en-US/sugar/downloads/file/26052/turtle_art-51.xo</a>." >> > >> > As soon as I downloaded to Windows it was obvious that this was not the file that downloaded. I'm failing to understand the problem. Could you please explain further? >> > The Journal hides too much of the workings from the user and so disempowers the user. The user is denied a deep understanding of what they are doing and the opportunity to use the system in ways that were not thought of by the designers. They are Users, not Creators or Authors. >> > >> > The hiding of the file system was well intended, files and directories are probably just a passing phase in computing and they cause some confusion to beginners, but they are the system which underlies the Journal and the way we interface with the www >> > >> > The price for low entry is too high if it disempowers the user, enforces artificial walls and ceiling. I think we have a problem of miscommunication here, in part I guess because our understanding of the problem has changed with time and also because it's hard to keep up with everybody's opinions. How I see this issue is that in the spirit of "low floor, no ceiling" we should keep moving forward in our implementation of the journal as devised, while adding more intermediate steps that go towards the understanding and manipulation of all the pieces of the educational machine, regardless of its complexity. I agree that it would be helpful to have hierarchical views of the file system in Sugar, though I don't think they should be the default one because IMO a flat view like gmail with good filtering and search capabilities is more efficient for users that don't want to spend their energy in keeping their data in directories. I understand this opinion is very debatable, but it comes from my observation of how people around me use their computers and also from the feedback about Sugar from the field. Where I see value in having a hierarchical view of the filesystem is in browsing a file system that isn't the main journal (the root filesystem, a removable device, etc). I have done work in the past to make easier to have such a hierarchical view and also to be able to browse the contents of the journal with traditional file browsers, but my time is very limited compared to all that needs to be done and I have decided to focus on other areas that IMO have a higher priority. But I would be very happy to give pointers to anyone who wishes to work on this, I have several ideas about how this could be implemented. Thanks, Tomeu _______________________________________________ Sugar-devel mailing list <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </blockquote></div>