[Sugar-devel] [IAEP] Article on "Why files need to die"
dthornburg at aol.com
Sun Jul 17 18:00:35 EDT 2011
I think we need to remember that the desktop interface as we developed it a PARC in the 70's was based on files and folders because our storage was so limited that finding stuff later wasn't a problem. Today I almost always find things by searching for them, either on my computer, or on the Web. My challenge is that I often name things one way and then try to retrieve them with another set of descriptors. My informal research on the topic shows I'm not alone.
One of the early attractions of Sugar (to me) was that I could look at things by time, not by name. The idea of finding what I was doing yesterday, made great sense.
I'm happy to see people working on the problem and found the blog quite interesting.
Warm regards to all,
Sent from my iPad
On Jul 17, 2011, at 10:49 AM, Martin Dengler <martin at martindengler.com> wrote:
> On Fri, Jul 15, 2011 at 11:54:40AM +0200, Christoph Derndorfer wrote:
>> Please also see this article (
>> http://blogs.gnome.org/mccann/2011/06/08/new-pony/) which Tomeu Vizoso (one
>> of the early Sugar developers) just shared on Google+, well worth a
> The article offers no solution that avoids the problem of naming and
> organising documents. It ends with "other people are setting up
> clouds, where's ours?", which doesn't seem very relevant to
> educational software in an intermittently connected world like the one
> I think we're targeting.
> The words privacy, security, or control do not appear in the article.
> The article is good insofar as it lays out one avenue of improvement:
> we need to take advantage of new connectivity options and improve the
> user interfaces for the information which is often or hard to manage
> right now.
> But would our computers be useful for learning, writing, reading, or
> playing if the only user interface was like Facebook or iTunes?
> We (this audience, and others like GNOME) are in danger of being
> distracted by the current limitations of moving audio-visual data
> around into thinking that our conversations, thoughts, and stories
> don't deserve designers' time, or can be managed in the same simple
> ways. At their essence this information is neither audio nor visual;
> it is textual (for practical, useful definitions of "essence"). And
> their labels (meta-data) are the same.
> Sure, these things can be compressed or expressed in different forms.
> But they cannot be easily used, or separated easily from context (what
> the original article's author found so terrible), without the control
> that the cloud takes away or the simplicity of the written word.
> We are at risk of sacrificing clarity and simplicity of expression so
> that Facebook or Apple or Google can sell us ads for the Kabbalah,
> mormonism, or DVDs. That is, if what what google.com and bing.com
> suggest when I search for 'the meaning of life' is any indication.
> Speaking of which, I'll finish this postscript after I watch the
> Meaning of Life...
> 1. Even after the author has narrowed the scope of the "file problem"
> three times to Document, then to MS-Office-type document, then to
> document one never needs to move outside of the cloud, he still
> doesn't say anything about how this fixes "file management" (which I
> infer he thinks of as naming, organising, and sharing.
> 2. One of the commenters basically said the author and other are
> getting distracted into re-creating "appliances" rather than designing
> for "general purpose computers"; rather than helping people manage the
> information they generate or manage mostly unconsciously now, it seems
> a big inferiority complex is being fed, since Facebook is so good and
> iCloud will make sure your documents (whose naming is never discussed)
> can appear on all your devices. Which is almost never useful unless
> you a) have always-on, low latency connections; and b) have a large
> amount of bandwidth; and c) never need to do anything with the
> information except look at it onscreen or what the cloud provider lets
> you do with it.
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
More information about the Sugar-devel