[IAEP] [Fwd: 0.84 goals]

[victor rajewski]

On Sat, Aug 16, 2008 at 6:47 PM, Albert Cahalan <acahalan at gmail.com> wrote:
> victor rajewski writes:
>> On Sat, Aug 16, 2008 at 3:05 PM, Albert Cahalan <acahalan at gmail.com>
>> wrote:
>
>>> You're using it exclusively, right...? (no bash, no MacOS, etc.)
>>>
>>> If it's not good enough for you, then it's definitely not good
>>> enough to be forced on other people.
>>
>> That would be like expecting gnome/OSX/windows developers to use
>> the GUI exclusively without using the command line. The GUI is for
>> a particular set of users, power users and developers might need
>> something else. A 10 year old student and a tertiary educated software
>> developer will have different needs from a file system.
>
> I don't know about gnome developers, but as for OSX and windows,
> yes they definitely do work exclusively in the GUI. I've seen it
> with my own eyes for Windows. (creepy!) I have to assume that
> pre-OSX developers didn't use a command line, because there
> wasn't any command line at all.

True. I guess my point is there are aspects of the OS that 'normal'
users see, and aspects that they don't need to see.

>> Gmail and delicious (and no doubt others) use a tag-and-search system;
>> they both work great for me, and if a similar functionality existed
>> for my regular filesystem, I'd use it in a second.
>
> Gmail is tolerable (barely) because email is mostly searchable text
> and because Google throws a massive compute farm at the problem.
> On the XO, we have mostly non-text and no compute power to spare.

Non-text is not the issue - that's what the tags are for.

>>> Here is an example: pretend you are a kid who wants to learn about
>>> his computer by exploring the filesystem. You want to look in /dev,
>>> look in /etc, and so on. Using only Sugar, can you do it?
>>
>> No, just like you can't do this in OSX using just the GUI. That's what
>> the terminal is there for.
>
> I can do that with GNOME, KDE, and Windows. While I think bash is
> wonderful, forcing people into it just to view files is no good.

/dev, /etc, on windows? hidden away into the API and registry.
Abstractions/layers. They're everywhere in the OS; that's what the OS
does.

>>> Clearly you are not a Journal user. You may have played with it,
>>> and you may have even written some code for it... but clearly you
>>> do not really use it.
>>
>> This is the tricky part - we are not the intended audience of the
>> journal/sugar. The intended audience is school kids. We need to be
>> looking at how they use it and if it suits them, not if it suits us.
>
> This bothers me greatly. I'll do my best to explain, but it isn't
> all that easy.
>
> Perhaps you've heard of "the soft bigotry of low expectations".
> You're... looking down on the kids when you decide that they can't
> use the same thing as yourself. They get toys, not tools.
>
> I can agree that some of the more complex stuff should be out of
> the way by default. The journal is more than that though; it makes
> the more complex stuff simply unavailable. It also encourages a
> mental model that is not in line with reality. The result is a
> limit to how far a kid can advance.

I understand where you are coming from. I personally don't have a
problem with using sugar/the journal since I'm happy to use the
command line when I need it, and so can the students. But throwing a
student in the deep end will not do them any favours; they'll just get
scared and switch off. In the broader sense, I don't really understand
what you mean by a 'mental model in line with reality'. Do you mean a
filesystem that mirrors existing filesystems? A filesystem that models
a physical filing cabinet-folder-file system? Just to do something
because that's what we've always done is not ideal; this is a chance
to try something different. With more powerful computers and increases
in storage space, OS designers have been trying to re-define
filesystems, but have been hamstrung by the need/expectations of
backwards compatibility. The way we think about information is
changing.

vik