Re: [Sugar-devel] [IAEP] Journal criticism
I, too, encounter difficulty finding elements in the Journal but haven't found time yet to contribute to a feature discussion. just 2 cents about hierarchical representation: it certainly has uses. The coolest one I ever saw was 8 years ago by a company (trying to remember the name) that provides intranet search to corporations: users enter text in a Google-like box; the bottom half of the screen shows hit-parade results (links) by relevancy, but the top half dynamically generated a hierarchy by type: text file (subclassed by format upon drilling down), media file, intranet web page, database result (interrogation by prebuilt connectors), etc. Clicking on any hierarchy entry regenerated the hit-parade by that type. Private tagging was possible, tied to the user's profile but exportable. Viewing rights were handled too; if unavailable to the profile, the link would be greyed but the info source within the company shown, so the user could militate for access (as opposed to not knowing its existence). Related: I heard Steve Jobs say in 1998 that folders were great for small numbers of files, but it didn't scale... so he had resorted to e-mailing files to himself, with different accounts and keywords in the subject lines... and sort/filter available in mail software. Today, OSX uses "Spotlight" which indexes not just text, but media file metadata, a subject dear to my heart (the Ogg container is well-suited to that). However, since I find Spotlight windows a pain (the commandline version is often faster), I continue to use the system I've used these past ten years: e-mailing documents between my accounts adding as many keywords as I can and searching in different ways (gmail search is not bad but could actually be quite a lot better). I think the Journal will be fine if additional search options are very carefully selected... and as much metadata as possible is pulled out of media files. I have found exiftool to be wonderful in this respect Sean On Thu, May 28, 2009 at 1:19 PM, Jonas Smedegaard wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > On Thu, May 28, 2009 at 06:18:35AM -0400, Albert Cahalan wrote: >>On Thu, May 28, 2009 at 5:49 AM, Jonas Smedegaard wrote: >>> On Thu, May 28, 2009 at 04:58:17AM -0400, Albert Cahalan wrote: Tomeu Vizoso writes: >> > I think it's very important if we want to keep pushing Sugar that > we distinguish between design decisions and bugs and unimplemented > features. If we bring down good design ideas not by themselves but > because of its implementation status, we risk ending up with > nothing that brings new value compared to existing desktops. You say that like it would be a bad thing. The existing desktops are at least time-tested. Learning to deal with the common features of modern desktop systems is very valuable for children. >>> >>> I flat out disagree that Sugar should be a learning experience >>> towards using alternative user interfaces. >>> >>> In that mindset we should mimic Word, Excel and the Windows desktop, >>> not for the quality of their interface designs, but simply because >>> they are expremely popular so getting acquainted to them is "very >>> valuable for children". >> >>To the extent that there are common features that are highly >>unlikely to change across versions or even OSes, definitely. >> >>MacOS System 6, MacOS X, OS/2 Warp, and Windows Vista >>have certain basic features in common. It's a safe bet to say that >>most of these features will remain in the computers of 2017. > > Actually, I am not so sure about that: I suspect user interfaces (as > well as many other features of our society) do not evolve linear, but > more and more rapidly transform. > > So I am willing to challenge you in that bet. :-D > > I suggest, for simplicity sake in our later judgement, that we limit the > bet to "do all popular computer desktop environments still use (and > directly expose to the edn user) a hierarchical file system in 2017, as > they did in 2009?" > > And I propose a symbolic item from looser to winner, with a fun > punishment twist added: One bottle of bewerage of the winner's choosing, > delivered personally at the winner's door step. > > How does that sound? > > > Kind regards, > > - Jonas > > - -- > * Jonas Smedegaard - idealist og Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEAREDAAYFAkoeczYACgkQn7DbMsAkQLhjdACgg6Q4x+mudFAyWE7tZBMMkC1d > mdQAoISLHzNrsO5kO0WqCzjU977WKGU3 > =mR8C > -END PGP SIGNATURE- > ___ > 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/
Re: [Sugar-devel] [IAEP] Journal criticism
There are 3 different ideas when we are talking about Journal vs Directories: 1. Whether we are limiting the user to use exactly one filtering category for his/her documents (and lets call them Files and the filter the Files' Directory) or we allow multiple filters (and call them Tags). 2. Whether we are showing the user a open/save dialog which has a Directory tree and File list or we just ask for a name and some tags for save and let the user filter open. 3. Whether the document store is a filesystem or a database. so remembering these points, answers are inlined: Albert Cahalan wrote: In graphical environments alone, directories are over 25 years old. Since 8 is less than a third of that, there is only one safe bet. It'd be way more than 25 years, except that we didn't even have graphical environments much beyond that. Directories go back about 40 years. 8 years is just another 20%. I am sure that 100 years ago when the car was invented, because humanity has been used horses for 5000 years and the next 100 years is only 2% of that, people predicted that we will still ride horses now This isn't the "Microsoft Windows XP Service Pack 2" feature set. This is a concept that is pretty fundamental in computing. It crosses platforms, it's in our network protocols, and it's even required for all the programming languages that implement Sugar. Having a filesystem does not conflict with that the user will never ever see one (3. is a differ idea than 2.). The following things unfortunately cannot be done with a flat filesystem view: 1. Revision based view. 2. Tagging. First, I think you didn't mean "flat". That's the Journal. Second, both flat and tree systems can handle that. I meant flat filesystem so I have written exactly that. I meant a filesystem which can be drawn on a 2D surface in a tree (where the files are leafs). Contrast it to a multidimensional "filesystem" where a File can have multiple Directories and which stores all the versions. See I do not want to argue over semantics so if we will have some system which can handle this multidimensional storage then we can call it a filesystem if you insist. After all a filesystem is just a database which maps names to disc block numbers (and the canceled WinFS was marketed as a filesystem after all). What is sure that this future "filesystem" will have a completely different access semantics that for example ext2. It is a totally different problem that the current Journal barely implements those things but dropping it in favor of "time-tested" solutions is a mistake IMHO. (Note that no filesystem solves those problems I have mentioned.) No filesystem should! It looks like GNOME 3.0 will get you those features on top of a plain old UNIX-style filesystem tree though, without making the filesystem incompatible with both software and humans. Have you noticed that as the world evolved, filesystems gained unimaginable capabilities like resource forks, extended attributes, access control lists, transactions? Is your point that we should drop the Journal just to be compatible with those softwares that possibly no child will ever use? I would vote to make the Journal more usable rather than trying to stop the world. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] journal criticism
On Thu, May 28, 2009 at 5:34 AM, Albert Cahalan wrote:
> James Zaki writes:
>
>> 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.
>
> Perhaps the concept is easier to learn as a child. If you've gone
> many decades without it ("non-tech elder relatives") and gotten set
> in your ways, you may be at a disadvantage.
>
> Let's not leave the next generation at a disadvantage too.
>
>> Perhaps an activity/game could be made that teaches the concepts
>> of a hierarchical file structure.
>
> That won't get enough use. Learning to deal with the general features
> of modern computing is much of the reason why the XO even exists, yet
I'm pretty sure most of us agree, and that you already know, that this
is precisely not the case. Sugar was not designed so kids could learn
to use computers. It was designed so kids could learn. Learning about
computers is certainly a subset of that goal, but by no means the
primary one as you suggest.
/me notes the name of the list...
> the children are denied the opportunity to learn about directories.
An activity which presents these topics would provide such an
opportunity for those kids inclined to explore it, would it not? It
seems that you are confusing opportunity with obligation.
Incidentally, I would actually like to see some changes come about to
the underlying data structures of the Journal so that it isn't so
completely alienated from the filesystem itself. I think many others
would too, but I don't think that forcing that on kids is particularly
useful. Still, making underlying changes to provide the opportunity
for kids to dig in deeper — via an activity, or via the command line —
is a worthy goal.
Eben
> ___
> 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] [IAEP] Journal criticism
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Thu, May 28, 2009 at 06:18:35AM -0400, Albert Cahalan wrote: >On Thu, May 28, 2009 at 5:49 AM, Jonas Smedegaard wrote: >> On Thu, May 28, 2009 at 04:58:17AM -0400, Albert Cahalan wrote: >>>Tomeu Vizoso writes: > I think it's very important if we want to keep pushing Sugar that we distinguish between design decisions and bugs and unimplemented features. If we bring down good design ideas not by themselves but because of its implementation status, we risk ending up with nothing that brings new value compared to existing desktops. >>> >>>You say that like it would be a bad thing. The existing desktops are >>>at least time-tested. Learning to deal with the common features of >>>modern desktop systems is very valuable for children. >> >> I flat out disagree that Sugar should be a learning experience >> towards using alternative user interfaces. >> >> In that mindset we should mimic Word, Excel and the Windows desktop, >> not for the quality of their interface designs, but simply because >> they are expremely popular so getting acquainted to them is "very >> valuable for children". > >To the extent that there are common features that are highly >unlikely to change across versions or even OSes, definitely. > >MacOS System 6, MacOS X, OS/2 Warp, and Windows Vista >have certain basic features in common. It's a safe bet to say that >most of these features will remain in the computers of 2017. Actually, I am not so sure about that: I suspect user interfaces (as well as many other features of our society) do not evolve linear, but more and more rapidly transform. So I am willing to challenge you in that bet. :-D I suggest, for simplicity sake in our later judgement, that we limit the bet to "do all popular computer desktop environments still use (and directly expose to the edn user) a hierarchical file system in 2017, as they did in 2009?" And I propose a symbolic item from looser to winner, with a fun punishment twist added: One bottle of bewerage of the winner's choosing, delivered personally at the winner's door step. How does that sound? Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREDAAYFAkoeczYACgkQn7DbMsAkQLhjdACgg6Q4x+mudFAyWE7tZBMMkC1d mdQAoISLHzNrsO5kO0WqCzjU977WKGU3 =mR8C -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] journal criticism
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Thu, May 28, 2009 at 12:29:23PM +0200, James Zaki wrote: >Not sure where my complete email went... something to do with awaiting >approval I think. [actual content snipped] Please subscribe to the lists that you post to, to bypass our spam screening process which causes delays and risk of lost emails. Kind regards, Jonas (one of only two list moderators - more volunteers appreciated!) - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREDAAYFAkoeb9IACgkQn7DbMsAkQLgzngCbBqCPIoKRoJbqEvSmHwUxdhXH nCMAoIUoWKZFKa5OQpomsUadbVq+TdrB =ZGFN -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Journal criticism
On Thu, May 28, 2009 at 12:07, Albert Cahalan wrote: > 2009/5/28 NoiseEHC : >> >> I think it's very important if we want to keep pushing Sugar that we >> distinguish between design decisions and bugs and unimplemented >> features. If we bring down good design ideas not by themselves but >> because of its implementation status, we risk ending up with nothing >> that brings new value compared to existing desktops. >> >> >> You say that like it would be a bad thing. The existing desktops >> are at least time-tested. Learning to deal with the common features >> of modern desktop systems is very valuable for children. >> >> >> This relies on the assumption that 8 years from now when children grow up we >> will still use directories. I do not dare to predict the future so I will >> leave it to you... :) > > In graphical environments alone, directories are over 25 years old. > Since 8 is less than a third of that, there is only one safe bet. > > It'd be way more than 25 years, except that we didn't even have > graphical environments much beyond that. Directories go back > about 40 years. 8 years is just another 20%. > > This isn't the "Microsoft Windows XP Service Pack 2" feature set. > This is a concept that is pretty fundamental in computing. > It crosses platforms, it's in our network protocols, and it's even > required for all the programming languages that implement Sugar. > >> The following things unfortunately cannot be done with a flat filesystem >> view: >> 1. Revision based view. >> 2. Tagging. > > First, I think you didn't mean "flat". That's the Journal. > Second, both flat and tree systems can handle that. > >> It is a totally different problem that the current Journal barely implements >> those things but dropping it in favor of "time-tested" solutions is a >> mistake IMHO. (Note that no filesystem solves those problems I have >> mentioned.) > > No filesystem should! It looks like GNOME 3.0 will get you those > features on top of a plain old UNIX-style filesystem tree though, > without making the filesystem incompatible with both software > and humans. As I said earlier, I would like to see hierarchical views of filesystems in Sugar. They are waiting for someone to implement them. I think we are beating a dead horse here. http://coreygilmore.com/wp-content/uploads/2007/08/beating_a_dead_horse.jpg Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] journal criticism
Not sure where my complete email went... something to do with awaiting
approval I think.
But just for clarity to all, I said the arrowed ">" text.
2009/5/28 Albert Cahalan
> James Zaki writes:
>
> > 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.
>
> Perhaps the concept is easier to learn as a child. If you've gone
> many decades without it ("non-tech elder relatives") and gotten set
> in your ways, you may be at a disadvantage.
>
> Let's not leave the next generation at a disadvantage too.
>
> > Perhaps an activity/game could be made that teaches the concepts
> > of a hierarchical file structure.
>
> That won't get enough use. Learning to deal with the general features
> of modern computing is much of the reason why the XO even exists, yet
> the children are denied the opportunity to learn about directories.
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Journal criticism
On Thu, May 28, 2009 at 5:49 AM, Jonas Smedegaard wrote: > On Thu, May 28, 2009 at 04:58:17AM -0400, Albert Cahalan wrote: >>Tomeu Vizoso writes: >>> I think it's very important if we want to keep pushing Sugar that we >>> distinguish between design decisions and bugs and unimplemented >>> features. If we bring down good design ideas not by themselves but >>> because of its implementation status, we risk ending up with nothing >>> that brings new value compared to existing desktops. >> >>You say that like it would be a bad thing. The existing desktops >>are at least time-tested. Learning to deal with the common features >>of modern desktop systems is very valuable for children. > > I flat out disagree that Sugar should be a learning experience towards > using alternative user interfaces. > > In that mindset we should mimic Word, Excel and the Windows desktop, not > for the quality of their interface designs, but simply because they are > expremely popular so getting acquainted to them is "very valuable for > children". To the extent that there are common features that are highly unlikely to change across versions or even OSes, definitely. MacOS System 6, MacOS X, OS/2 Warp, and Windows Vista have certain basic features in common. It's a safe bet to say that most of these features will remain in the computers of 2017. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Journal criticism
2009/5/28 NoiseEHC : > > I think it's very important if we want to keep pushing Sugar that we > distinguish between design decisions and bugs and unimplemented > features. If we bring down good design ideas not by themselves but > because of its implementation status, we risk ending up with nothing > that brings new value compared to existing desktops. > > > You say that like it would be a bad thing. The existing desktops > are at least time-tested. Learning to deal with the common features > of modern desktop systems is very valuable for children. > > > This relies on the assumption that 8 years from now when children grow up we > will still use directories. I do not dare to predict the future so I will > leave it to you... :) In graphical environments alone, directories are over 25 years old. Since 8 is less than a third of that, there is only one safe bet. It'd be way more than 25 years, except that we didn't even have graphical environments much beyond that. Directories go back about 40 years. 8 years is just another 20%. This isn't the "Microsoft Windows XP Service Pack 2" feature set. This is a concept that is pretty fundamental in computing. It crosses platforms, it's in our network protocols, and it's even required for all the programming languages that implement Sugar. > The following things unfortunately cannot be done with a flat filesystem > view: > 1. Revision based view. > 2. Tagging. First, I think you didn't mean "flat". That's the Journal. Second, both flat and tree systems can handle that. > It is a totally different problem that the current Journal barely implements > those things but dropping it in favor of "time-tested" solutions is a > mistake IMHO. (Note that no filesystem solves those problems I have > mentioned.) No filesystem should! It looks like GNOME 3.0 will get you those features on top of a plain old UNIX-style filesystem tree though, without making the filesystem incompatible with both software and humans. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Journal criticism
I think it's very important if we want to keep pushing Sugar that we distinguish between design decisions and bugs and unimplemented features. If we bring down good design ideas not by themselves but because of its implementation status, we risk ending up with nothing that brings new value compared to existing desktops. You say that like it would be a bad thing. The existing desktops are at least time-tested. Learning to deal with the common features of modern desktop systems is very valuable for children. This relies on the assumption that 8 years from now when children grow up we will still use directories. I do not dare to predict the future so I will leave it to you... :) The following things unfortunately cannot be done with a flat filesystem view: 1. Revision based view. 2. Tagging. Of course, these views could be shown as a tree-like structure but it does not necessary mean that a filesystem should be the underlying storage. It is a totally different problem that the current Journal barely implements those things but dropping it in favor of "time-tested" solutions is a mistake IMHO. (Note that no filesystem solves those problems I have mentioned.) Another different problem is that Sugar should have a compatibility mode for example for USB drives but it will be implemented as I know so talking about that is moot. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Journal criticism
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Thu, May 28, 2009 at 04:58:17AM -0400, Albert Cahalan wrote: >Tomeu Vizoso writes: >> I think it's very important if we want to keep pushing Sugar that we >> distinguish between design decisions and bugs and unimplemented >> features. If we bring down good design ideas not by themselves but >> because of its implementation status, we risk ending up with nothing >> that brings new value compared to existing desktops. > >You say that like it would be a bad thing. The existing desktops >are at least time-tested. Learning to deal with the common features >of modern desktop systems is very valuable for children. I flat out disagree that Sugar should be a learning experience towards using alternative user interfaces. In that mindset we should mimic Word, Excel and the Windows desktop, not for the quality of their interface designs, but simply because they are expremely popular so getting acquainted to them is "very valuable for children". Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREDAAYFAkoeXhkACgkQn7DbMsAkQLgOQACghzX9Ts4NNCUR09PevDZi9LDs /1wAniwQFsPTn6KXe74NOEmuG/NpZjFt =PWgK -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] journal criticism
James Zaki writes:
> 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.
Perhaps the concept is easier to learn as a child. If you've gone
many decades without it ("non-tech elder relatives") and gotten set
in your ways, you may be at a disadvantage.
Let's not leave the next generation at a disadvantage too.
> Perhaps an activity/game could be made that teaches the concepts
> of a hierarchical file structure.
That won't get enough use. Learning to deal with the general features
of modern computing is much of the reason why the XO even exists, yet
the children are denied the opportunity to learn about directories.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Journal criticism
Tomeu Vizoso writes: > On Wed, May 27, 2009 at 04:54, wrote: >> 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. ... >> 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. You probably would look trollish and upset a few people, but this can be good for sugar and/or education. If few people ever dare to point out problems, we have useless groupthink. I certainly point out problems, but you can't rely on me alone. It's easy to dismiss one person as a grumpy old troll, but not so easy to dismiss a variety of unrelated people pointing out that something isn't right. The more fundamental/core/central the issue, the more this applies. >> 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. Instead of trying to add hierarchical storage to the journal, consider inverting the issue. Modern desktop systems often have special ways to view particular directories. For example, Windows does something special with the directory you use for MP3 files. It also does something special for the font directory. Suppose that one directory got a special view called "journal view". This could be a "My Documents" or "Desktop" directory. Activities throw stuff in there using the journal API. AFAIK, GNOME's Nautilus just needs a plug-in to enable a journal view to work there. 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 > > 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 Given that they are everywhere, it's an educational issue. This isn't like the particulars of Microsoft Office 2007. This is something pervasive throughout the world of computing. > 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. The most interesting feedback from the field was about the kids teaching each other to wipe the journal with "rm". ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Journal criticism
Tomeu Vizoso writes: > On Wed, May 27, 2009 at 20:20, Lucian Branescu > wrote: >> I'm new to Sugar, so I may be horribly wrong. >> >> But to me, the Journal seems more of an annoyance than anything else. >> A lot of the work I see done is towards bringing back some of the >> properties that regular filesystems have >> >> What advantage does it have as opposed to a regular filesystem with >> support for versioning and metadata? A filesystem would be more >> compatible with existing software (which could just ignore the >> metadata), at least. > > I can very easily understand that for someone who is used to a regular > filesystem, the journal may seem as an annoyance when an attempt to > use it in the same way is done. The same can be said of any other > diversion in Sugar from how Windows/OSX behave. > > Though, interestingly, many people have successfully switched from > files-in-folders-in-folders email clients to GMail. Maybe it is > because the journal is not as mature as gmail? There are big differences in the problem space. GMail is dealing with text. Text search is somewhat reliable. Sugar is dealing with all sorts of random data, like video. GMail can briefly throw **lots** of beefy hardware at the problem, allowing searches to be fast. Sugar can operate a single wimpy processor. Also, lack of folders in GMail is a common complaint. People put up with it because they like other things about GMail. I switched partly because Evolution was eating my inbox. > If I think that something like the journal is worth having, it is: > > - because I can easily observe how non-technical users are unable to > find the files that they stored in folders some time ago, or forget to > save an important document, or modify a file that Firefox saved to > /tmp and it got deleted after a reboot, etc, Now we have equality. The technical users are now also unable to find their files. :-( > I think it's very important if we want to keep pushing Sugar that we > distinguish between design decisions and bugs and unimplemented > features. If we bring down good design ideas not by themselves but > because of its implementation status, we risk ending up with nothing > that brings new value compared to existing desktops. You say that like it would be a bad thing. The existing desktops are at least time-tested. Learning to deal with the common features of modern desktop systems is very valuable for children. > And btw, the Sugar people aren't alone in this, as GNOME will ship > with a very similar journal concept in their 3.0 version. You can > find info in the net and read their own justifications for it. > > Would be awesome if the Sugar Journal and the GNOME one could share > its backend. Could someone check out the current state of the GNOME > one and compare with our needs? It looks like a heavy-duty version of "Recent Documents". It's far from being a Journal clone as far as I can tell, but it certainly deals with the concerns that led to the creation of the Journal. Converting the Journal database is possible I think, allowing for an excellent migration path. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
