[etoys-dev] Copying Graphing tools and Speech Bubbles to Inbox

[Ricardo Moran]

On Mon, Aug 16, 2010 at 2:29 AM, Steve Thomas <sthomas1 at gosargon.com> wrote:

> Ricardo,
>
> Thanks, don't worry too much about the ballon help for now, I can provide a
> first draft of wording later if it helps.
>

That would be great. I'll write something as well. I don't think it's too
much work and if I keep cleaning these tools there would be even less.


>
> Also I got a good laugh when I opened your project, the visuals are great
> ;)
>

Haha :)


>
> In the Tables, the "remove row" seems to only remove the last row, which
> means I can't remove a row in the middle. One way to deal with this would be
> to have it remove the row at "row index".
>
> Your "*row* first" and "*row* second" seem to have the values of the first
> and second *column* of the "row index" *row*. This also limits you to only
> two columns for the table implementation. I think a more general solution
> could meet the need.
>

Maybe we can adapt the Spreadsheet object for this stuff. We need to think
of a way of linking rows or columns with axes but it could be done I think.


>
> A couple of points on the "point graph":
>
>    1. You can only plot one set of points (I tried opening a second point
>    table from the menu, but the items simply moved no new items were added.
>
> If we manage to adapt the spreadsheet object this won't be a problem
anymore.

>
>    1. If I add additional objects to the graph (for example I may want to
>    add some descriptive text or items that are not to be used as "displayable
>    points", when I click apply they disappear.
>
> As it is now, any object dropped into the graph becomes a point (except for
the axes, labels, grids and stuff, which are building parts of the graph).
Maybe we could ask the user every time he drops an object whether he wants
to use it as a point or not. I don't really like this solution. Other idea
would be to never use texts as points. Or maybe add an option to the
object's menu that will allow it behave as a point or not. I don't know...
I'm just throwing some ideas...

>
>    1. Not sure how you added the objects to use as "points" unless through
>    collections
>
> I don't really understand what you mean, sorry.

>
>    1. I added a point (using "add point" in the "plot points" category and
>    it was placed at 0,0, then when I moved the point I accidentally moved the
>    arrow that was the axis line.
>
> Maybe I could lock the building parts of the graph. That would avoid this
happening.

>
>    1. The ability to plot lines would be nice.
>
> Yes, it would. Maybe we could make different object behave as points or
lines or segments or vectors... When dropping the object, the graph would
then distinguish each case... I don't know. Maybe Lines behave like
lines/segments, Arrows as vectors, Ellipses/Sketches could be points. In any
case, I think this would complicate things a little. Maybe Dr. Geo is the
right tool for that kind of stuff.

>
>
> In general a lot of clever stuff, I especially like your latest addition of
> being able to define your own "point graphics".  You could do a Hans
> Rosling Gapminer style graphs <http://www.youtube.com/watch?v=hVimVzgtD6w>with this type of approach, (although we should make sure the kids don't try
> sword swallowing ;)  This would be a good Etoys project a great way to show
> change over time and facilitate appropriate comparisons and help determine
> causality. This project could actually be done now with Etoys 4.
>

Wow, I really liked Hans Rosling graphs. I didn't know about them and I
think we're getting closer to his approach.


>
> I feel there are too many categories for the graph (that said I am not sure
> how to reduce them, I have been looking at other implementations of graphs
> (Excel, Open Office {which has chart junk that makes Excel look good, etc)
> to get ideas. Numbers from iWork has the interface elements I like best so
> far.
>

I too believe so. We could make a new object like a properties panel which
would change the graphs properties, but it wouldn't be scriptable and I
don't really like this idea neither.


>
> All that said I still really feel all we need for the graph is:
>
>    - a Number line object
>
> I think this is a very good idea. I haven't built it this way but now I
think I should. This number line could be used for so many other thinks like
time lines and stuff like that. IIRC there used to be a timeline object in
Etoys (I couldn't find it though). This could be useful for teaching history
I guess (I know of an uruguayan teacher who would use such object).
Also, building graphs composing this objects would help decrease the amount
of viewer categories of the graph because the range, the legend spacing,
colors, etc. would be a part of the number line.

>
>    - a way to change the scaling of X and Y in a playfield (ie: 1 unit =
>    20 pixels, with perhaps different units in X and Y to allow logarithimic
>    graphs.)
>       - This could have other uses, I have seen a similar implementation
>       of this in the UNCW version of STEM Etoys.
>
> I think Playfields are already very complex objects. I don't know how much
work this would take but it would be a great addition.

>
>    - a way to have the gridding start at an offset from the bottom left
>    corner of the playfield (to allow for a cleaner looking single quadrant
>    chart)
>
> Again a good addition, which I don't know yet how to implement :)

>
>
> Then the table could be holder with the following new features:
>
>    - fixed width row and column sizes
>    - the ability to address a particular row and column (yes the kids
>    could do the math, but I think this is one of the things that should be
>    easy)
>
> I keep thinking the best object for this would be the Spreadsheet.

>
>
> The Number line you almost have complete (hash marks would be a nice
> addition).
> Scaling of movement in a playfield should be trivial (if the code is well
> designed ;)
> Changing gridding don't know, but doing it with a pen trails is simple
> enough.
>

I will look into this, I think they are all great ideas.


> Making a table using a holder would be relatively easy with scripting
> tiles, by using fixed size text boxes or Holders and whatever you want.
> You could even have a column for the point graphic (which could be  player
> variable, or a graphic scaled to the standard row/column size) for example:
>
> X, Y, Object to use as Point
> 1, 2   <Star graphic>
> 2, 20 <graphic 2>
> ...
>
>
>
One great idea of the Skeleton spreadsheet was letting the user link a
cell's value with a viewer tile by dropping it inside the cell. We could
make the Spreadsheet object work like that or see if Skeleton could be
integrated in Etoys. I like it even though I think it's a very big and
complex tool.


>
> You could plot the number of useful code changes over time using Day as the
> X axis and the other values along the Y axis with a table like this:
>
> Day  Richo   Stephen  Bert
>  1        1            0         2
>  2        3            0         4
>  3        5            0         6
>
>
> In fact if we just had a just number line kids could develop their own
> graphing tools (which if there was an easy way to package up and re-use what
> you create, hint hint nudge nudge wink wink)  would be a great thing for
> kids to do. Imagine kids making their own tools!! They might evolve (of
> course after spending most of their free time playing "Call of Duty" and the
> like, they would probably create weapons to kill people). But of course
> games don't have any influence on kids behavior, that's why we are wasting
> our time at things like "Games for Change" and "Games for Learning".
>

Yes! Let the kids built their own tools. It would be great!


>
> Hey wait a minute!!!! Richo's Morph I/O could be used by kids as a way to
> package their own tools!!!!  Good job RIcho.
>

:)

Thanks for your comments Steve! I think the graphing tools will become much
nicer with all these ideas :D
Richo

>
>
> Stephen
>
>
> On Sun, Aug 15, 2010 at 11:38 PM, Ricardo Moran <richi.moran at gmail.com>wrote:
>
>> I think you're going to like this version :)
>> http://tecnodacta.com.ar/gira/gsoc/NewGraphingTools.002.pr
>>
>> I still haven't done all the things you told me but I'm getting there. I
>> finally removed the PointMorph and BarMorph classes. Everything works as
>> before but you can use now any object as a Point or Bar, you just drop it on
>> the graph and it gets added to the point/bar list (well... almost any
>> object, I guess there might be problems with some complex morphs...)
>>
>> In the case of the bars, I used the object's height as its value and the
>> object's name as its label, like you suggested. Also, the objects you add to
>> a graph get a new viewer category for its specific slots. I haven't done the
>> same for vectors yet but I will do it soon. As I'm thinking it, we will have
>> three different graphs for bars, points, and vectors. That's the easiest way
>> I found to distinguish each drop correctly.
>>
>> I also merged the PointTableMorph and BarTableMorph classes into
>> TableOfValuesMorph, and I merged a few short viewer categories. What I
>> haven't done yet is writing the balloon helps and using the holder
>> vocabulary for the graphs but I wanted to show this at least, which I think
>> it's much nicer than what I had before. Please comment if you think this is
>> the right direction. Thanks!
>>
>> Richo
>>
>>
>> On Sat, Aug 14, 2010 at 8:58 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:
>>
>>> On 15.08.2010, at 00:37, Ricardo Moran wrote:
>>>
>>> On Sat, Aug 14, 2010 at 4:15 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:
>>>
>>>>
>>>> On 14.08.2010, at 19:00, Ricardo Moran wrote:
>>>>
>>>> > Hi, I've just uploaded a new commit to the inbox. It contains all the
>>>> graphing tools and speech bubbles with most of Bert's suggestions fixed. I'm
>>>> sorry for the big commit but I moved my older commits to treated because
>>>> they were incomplete. Now the only commits needed to have these tools
>>>> working properly are: Morphic-Richo.33 and Etoys-Richo.32
>>>> > I hope they got accepted into Etoys. I'm excited :)
>>>>
>>>> I think they will :) I cleaned out the inbox today, merged all
>>>> submissions, made minor modifications.
>>>>
>>>> I only did not merge Etoys-Richo.32 yet. It is much nicer than the
>>>> previous version, but still not quite there IMHO:
>>>>
>>>> * the "remove" tile duplicates the existing "erase" tile
>>>> * barColor duplicates color
>>>> * a lot of graph tiles duplicate holder functionality
>>>> * a "bar table" is something in a club ;) I think calling it "table of
>>>> values" would be better
>>>> * privateExtent:/privateCenter:/privatePosition: methods duplicate the
>>>> existing extent:/center:/position: methods
>>>> * there is still a reference to Vector (though only in an example
>>>> method)
>>>> * there already is another object called "Graph" in the object catalog
>>>> * none of the new slots have a balloon help
>>>> * some of the "plot - ..." categories are quite short, they should be
>>>> merged
>>>> * apply, max, min, remove, are all a bit short. There is already
>>>> minVal/maxVal and getMinVal/getMaxVal for example which you could reuse
>>>>
>>>> I think the apparent complexity could be simplified when adopting more
>>>> of the holder vocabulary. Instead of "index" call it "cursor". "point x"
>>>> would be "x value at cursor" or so. Etc.
>>>>
>>>
>>> Most of these can be fixed easily. Specially the terminology ones (I
>>> didn't know about the "bar table", otherwise I would have used other
>>> term :P)
>>>
>>>
>>>> Ideally, the graph would just *be* a holder/playfield. E.g. in a bar
>>>> graph, the user might just put plain rectangles or sketches or whatever.
>>>> Instead of extra labels, use the rectangle's name. The value would simply be
>>>> calculated from the object's width and the bar scale factor (just like you
>>>> did for points, which can be moved freely - cool). Same for xy graphs - the
>>>> points could be *any* object in a playfield. And possibly even points and
>>>> vectors could be unified - a point would just be a vector of length 0? That
>>>> might be not the best idea, I don't know. How much more time do you have in
>>>> your project?
>>>>
>>>
>>> So adding a bar/point/vector would be just dropping an object (any
>>> object) into the graph... I like it, I think it's possibly a good idea (if
>>> we manage to figure out a nice way of unifying vectors and points... maybe
>>> different graphs for each?), but it's quite different from what I currently
>>> have and I'm not sure I'll be able to make it in time for this release.
>>> Since this seems like a big change I think adding these tools to the Etoys
>>> release may not be such a good idea. Maybe we should wait to hear the
>>> opinion of the educators about this change and if they like it, work on this
>>> for the next release.
>>>
>>> The GSoC deadline is this monday and I didn't even finish the seven items
>>> in my proposal. I will still work on this after gsoc is over but I worked
>>> very little in the PaintBox and I haven't even touched the EtoyMaker. That's
>>> a bummer...
>>>
>>>
>>>>
>>>> I have no serious complaints about the bubble implementation (except for
>>>> the empty help balloons on the tiles), but you submitted both together so I
>>>> could not merge them yet.
>>>>
>>>
>>> I'll write the balloon help and I'll push the bubbles to Etoys myself, if
>>> that's ok with you.
>>>
>>>
>>> Certainly.
>>>
>>>  - Bert -
>>>
>>>
>>>
>>> _______________________________________________
>>> etoys-dev mailing list
>>> etoys-dev at squeakland.org
>>> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>>>
>>>
>>
>> _______________________________________________
>> etoys-dev mailing list
>> etoys-dev at squeakland.org
>> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakland.org/pipermail/etoys-dev/attachments/20100816/14556d98/attachment-0001.html>