[etoys-dev] Copying Graphing tools and Speech Bubbles to Inbox
Steve Thomas
sthomas1 at gosargon.com
Mon Aug 16 01:29:01 EDT 2010
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.
Also I got a good laugh when I opened your project, the visuals are great ;)
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.
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.
2. 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.
3. Not sure how you added the objects to use as "points" unless through
collections
4. 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.
5. The ability to plot lines would be nice.
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.
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.
All that said I still really feel all we need for the graph is:
- a Number line object
- 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.
- 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)
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)
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.
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>
...
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".
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.
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/1d8389e5/attachment-0001.html>
More information about the etoys-dev
mailing list