Telescope [was Re: Roassal3 and Bloc]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Telescope [was Re: Roassal3 and Bloc]

Peter Uhnak
Hmm...

right now I have one burning question:
Why build a completely new layer of indirection with different API instead of improving and extending Roassal (=Telescope alongside Roassal instead of on top of it)? It seems like a lot of effort went into creating it while it would have had bigger and better impact in Roassal...


So, how do you tell builder that you want to color or add interaction to a "group" of nodes and not all the nodes in the visu? Groups are first-class entities in Telescope. Composites are first class entities with customizable interactions.
Roassal has RTGroup, which is obviously less powerful, but often enough. Plus the
"if node matches this add/change/do this" that is also implemented by Telescope.
 
Moreover, the model takes care of updating only the concerned nodes and not all of the visualization.
Roassal updates only what should be updated, not the whole visualization. (And if some particular builder does rerender everything, that's the builder's problem.) After all this is transitive --- if Telescope can do partial changes and is on top of Roassal, so can Roassal do it...
 
The paper is not the best way to see what Telescope is able to.

Look at the demos and the presentation Anne did at Esug: http://www.slideshare.net/GuillaumeLarcheveque/telescope-introduction-and-example
I saw the presentation at ESUG but I wanted more insight (or documentation)...

Anyway, I'll continue my exploration... but the idea that I might need interaction between Telescope and Roassal elements and concepts doesn't make me happy...

Peter

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Telescope [was Re: Roassal3 and Bloc]

Peter Uhnak
On another note...

why no inspector support?

[[[
TLVisualization>>gtInspectorVisualizationIn: aComposite
<gtInspectorPresentationOrder: -1>
self generate.
aComposite roassal2
title: 'Visualization';
initializeView: [ self generator view ]
]]]


On Tue, Jul 21, 2015 at 11:52 PM, Peter Uhnák <[hidden email]> wrote:
Hmm...

right now I have one burning question:
Why build a completely new layer of indirection with different API instead of improving and extending Roassal (=Telescope alongside Roassal instead of on top of it)? It seems like a lot of effort went into creating it while it would have had bigger and better impact in Roassal...


So, how do you tell builder that you want to color or add interaction to a "group" of nodes and not all the nodes in the visu? Groups are first-class entities in Telescope. Composites are first class entities with customizable interactions.
Roassal has RTGroup, which is obviously less powerful, but often enough. Plus the
"if node matches this add/change/do this" that is also implemented by Telescope.
 
Moreover, the model takes care of updating only the concerned nodes and not all of the visualization.
Roassal updates only what should be updated, not the whole visualization. (And if some particular builder does rerender everything, that's the builder's problem.) After all this is transitive --- if Telescope can do partial changes and is on top of Roassal, so can Roassal do it...
 
The paper is not the best way to see what Telescope is able to.

Look at the demos and the presentation Anne did at Esug: http://www.slideshare.net/GuillaumeLarcheveque/telescope-introduction-and-example
I saw the presentation at ESUG but I wanted more insight (or documentation)...

Anyway, I'll continue my exploration... but the idea that I might need interaction between Telescope and Roassal elements and concepts doesn't make me happy...

Peter


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Telescope [was Re: Roassal3 and Bloc]

Peter Uhnak
So there is TLStyleSheet>>compositeExpandedByDefault:

But what if I want for example to have the option to manually resize something? Roassal gives me RTResizeable. Would I have to write some special TLInteraction or can I somehow reuse what Roassal offers? (This also applies for Roassal interactions in general).

Peter

On Wed, Jul 22, 2015 at 7:40 AM, Peter Uhnák <[hidden email]> wrote:
On another note...

why no inspector support?

[[[
TLVisualization>>gtInspectorVisualizationIn: aComposite
<gtInspectorPresentationOrder: -1>
self generate.
aComposite roassal2
title: 'Visualization';
initializeView: [ self generator view ]
]]]


On Tue, Jul 21, 2015 at 11:52 PM, Peter Uhnák <[hidden email]> wrote:
Hmm...

right now I have one burning question:
Why build a completely new layer of indirection with different API instead of improving and extending Roassal (=Telescope alongside Roassal instead of on top of it)? It seems like a lot of effort went into creating it while it would have had bigger and better impact in Roassal...


So, how do you tell builder that you want to color or add interaction to a "group" of nodes and not all the nodes in the visu? Groups are first-class entities in Telescope. Composites are first class entities with customizable interactions.
Roassal has RTGroup, which is obviously less powerful, but often enough. Plus the
"if node matches this add/change/do this" that is also implemented by Telescope.
 
Moreover, the model takes care of updating only the concerned nodes and not all of the visualization.
Roassal updates only what should be updated, not the whole visualization. (And if some particular builder does rerender everything, that's the builder's problem.) After all this is transitive --- if Telescope can do partial changes and is on top of Roassal, so can Roassal do it...
 
The paper is not the best way to see what Telescope is able to.

Look at the demos and the presentation Anne did at Esug: http://www.slideshare.net/GuillaumeLarcheveque/telescope-introduction-and-example
I saw the presentation at ESUG but I wanted more insight (or documentation)...

Anyway, I'll continue my exploration... but the idea that I might need interaction between Telescope and Roassal elements and concepts doesn't make me happy...

Peter



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Telescope [was Re: Roassal3 and Bloc]

Guillaume Larcheveque
In reply to this post by Peter Uhnak


2015-07-21 23:52 GMT+02:00 Peter Uhnák <[hidden email]>:
Hmm...

right now I have one burning question:
Why build a completely new layer of indirection with different API instead of improving and extending Roassal (=Telescope alongside Roassal instead of on top of it)? It seems like a lot of effort went into creating it while it would have had bigger and better impact in Roassal...
Because we created Telescope when we had to move from Roassal to Roassal2 and at this time Roassal2 was not supporting a Mondrian like syntax so we tried to create an equivalent powerful syntax than Mondrian with an object oriented approach 


So, how do you tell builder that you want to color or add interaction to a "group" of nodes and not all the nodes in the visu? Groups are first-class entities in Telescope. Composites are first class entities with customizable interactions.
Roassal has RTGroup, which is obviously less powerful, but often enough. Plus the
"if node matches this add/change/do this" that is also implemented by Telescope.
Because we are creating really interactives visualizations we were always out limit of RTGroup 
 
Moreover, the model takes care of updating only the concerned nodes and not all of the visualization.
Roassal updates only what should be updated, not the whole visualization. (And if some particular builder does rerender everything, that's the builder's problem.) After all this is transitive --- if Telescope can do partial changes and is on top of Roassal, so can Roassal do it...
Yes but Telescope does it for you... 
 
The paper is not the best way to see what Telescope is able to.

Look at the demos and the presentation Anne did at Esug: http://www.slideshare.net/GuillaumeLarcheveque/telescope-introduction-and-example
I saw the presentation at ESUG but I wanted more insight (or documentation)...

Anyway, I'll continue my exploration... but the idea that I might need interaction between Telescope and Roassal elements and concepts doesn't make me happy...

Peter

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--
Guillaume Larcheveque


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Telescope [was Re: Roassal3 and Bloc]

Guillaume Larcheveque
In reply to this post by Peter Uhnak


2015-07-22 7:40 GMT+02:00 Peter Uhnák <[hidden email]>:
On another note...

why no inspector support?

[[[
TLVisualization>>gtInspectorVisualizationIn: aComposite
<gtInspectorPresentationOrder: -1>
self generate.
aComposite roassal2
title: 'Visualization';
initializeView: [ self generator view ]
]]]
Because you cannot just open a Visualization like that; it requires some datas.

A good idea would be to have some examples data with each visualization
 


On Tue, Jul 21, 2015 at 11:52 PM, Peter Uhnák <[hidden email]> wrote:
Hmm...

right now I have one burning question:
Why build a completely new layer of indirection with different API instead of improving and extending Roassal (=Telescope alongside Roassal instead of on top of it)? It seems like a lot of effort went into creating it while it would have had bigger and better impact in Roassal...


So, how do you tell builder that you want to color or add interaction to a "group" of nodes and not all the nodes in the visu? Groups are first-class entities in Telescope. Composites are first class entities with customizable interactions.
Roassal has RTGroup, which is obviously less powerful, but often enough. Plus the
"if node matches this add/change/do this" that is also implemented by Telescope.
 
Moreover, the model takes care of updating only the concerned nodes and not all of the visualization.
Roassal updates only what should be updated, not the whole visualization. (And if some particular builder does rerender everything, that's the builder's problem.) After all this is transitive --- if Telescope can do partial changes and is on top of Roassal, so can Roassal do it...
 
The paper is not the best way to see what Telescope is able to.

Look at the demos and the presentation Anne did at Esug: http://www.slideshare.net/GuillaumeLarcheveque/telescope-introduction-and-example
I saw the presentation at ESUG but I wanted more insight (or documentation)...

Anyway, I'll continue my exploration... but the idea that I might need interaction between Telescope and Roassal elements and concepts doesn't make me happy...

Peter


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--
Guillaume Larcheveque


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Telescope [was Re: Roassal3 and Bloc]

Peter Uhnak


On Wed, Jul 22, 2015 at 10:05 AM, Guillaume Larcheveque <[hidden email]> wrote:


2015-07-22 7:40 GMT+02:00 Peter Uhnák <[hidden email]>:
On another note...

why no inspector support?

[[[
TLVisualization>>gtInspectorVisualizationIn: aComposite
<gtInspectorPresentationOrder: -1>
self generate.
aComposite roassal2
title: 'Visualization';
initializeView: [ self generator view ]
]]]
Because you cannot just open a Visualization like that; it requires some datas.

What do you mean? The datas were introduced to the object already, this is same like calling "visualization open". Or maybe I am treating TL scripts too much like Roassal scripts with different API.

Why build a completely new layer of indirection with different API instead of improving and extending Roassal (=Telescope alongside Roassal instead of on top of it)? It seems like a lot of effort went into creating it while it would have had bigger and better impact in Roassal...
Because we created Telescope when we had to move from Roassal to Roassal2 and at this time Roassal2 was not supporting a Mondrian like syntax so we tried to create an equivalent powerful syntax than Mondrian with an object oriented approach 

I do understand this but that's not what I am asking. Why not create it alongside Roassal2 instead of on top of it; or just create a better Mondrian? What I am trying to understand is what is the benefit of introducing a whole new level of indirection just to simplify one thing, instead of improving the underlying layer in the first place. Because I feel that I am loosing a lot of power because Roassal is hidden from me.

And this got overlooked probably (relates to the question above):

So there is TLStyleSheet>>compositeExpandedByDefault:

But what if I want for example to have the option to manually resize something? Roassal gives me RTResizeable. Would I have to write some special TLInteraction or can I somehow reuse what Roassal offers? This also applies for Roassal interactions in general.

And even for Roassal in general... e.g.

RTShape allSubclasses size. "30"
TLSimpleShape allSubclasses size. "3"

So if I wanted to use some other shape from Roassal (for example box with rounded corners), would I have to create matching TL shape and then define mapping in the generator/connector?


Thanks,
Peter


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Telescope [was Re: Roassal3 and Bloc]

Guillaume Larcheveque


2015-07-22 12:19 GMT+02:00 Peter Uhnák <[hidden email]>:


On Wed, Jul 22, 2015 at 10:05 AM, Guillaume Larcheveque <[hidden email]> wrote:


2015-07-22 7:40 GMT+02:00 Peter Uhnák <[hidden email]>:
On another note...

why no inspector support?

[[[
TLVisualization>>gtInspectorVisualizationIn: aComposite
<gtInspectorPresentationOrder: -1>
self generate.
aComposite roassal2
title: 'Visualization';
initializeView: [ self generator view ]
]]]
Because you cannot just open a Visualization like that; it requires some datas.

What do you mean? The datas were introduced to the object already, this is same like calling "visualization open". Or maybe I am treating TL scripts too much like Roassal scripts with different API.
At this point you are not sure that data were introduced, I can do TLButterfly new inspect and then it will not work because I didn't put datas in my visu so generate will fail. In addition it's not a good idea to generate the visualization without the user approval especially if he is debugging an infinite loop for example ;-)

Why build a completely new layer of indirection with different API instead of improving and extending Roassal (=Telescope alongside Roassal instead of on top of it)? It seems like a lot of effort went into creating it while it would have had bigger and better impact in Roassal...
Because we created Telescope when we had to move from Roassal to Roassal2 and at this time Roassal2 was not supporting a Mondrian like syntax so we tried to create an equivalent powerful syntax than Mondrian with an object oriented approach 

I do understand this but that's not what I am asking. Why not create it alongside Roassal2 instead of on top of it; or just create a better Mondrian? What I am trying to understand is what is the benefit of introducing a whole new level of indirection just to simplify one thing, instead of improving the underlying layer in the first place. Because I feel that I am loosing a lot of power because Roassal is hidden from me.
Because Roassal2 was creating a whole new model (RTGroup instead of RoGroup)... Obviously you are losing some power because Telescope is not a drawing framework nor Roassal functionnalities copy, just a visualization framework and Roassal is just used as a renderer (the goal of the connector is to create easily new ways to render our model; in Bloc or html5 for example). We faced lots of difficulties when using roassal as a visualization framework especially with interactions that modify the model and so created a model specialized for that, that offers much more than just "simplifying one thing"; just try to create with roassal the demo #exampleMovingNodeToAnotherGroup and you will understand that many things are impacted.

Scripting philosophy was also problematic for us because we have to maintain lots of visualizations and observe that we were copying/pasting lots of code that was complicated to keep up to date. The abstraction of Action/Interaction composition was really reward-full with composite nodes especially.


And this got overlooked probably (relates to the question above):

So there is TLStyleSheet>>compositeExpandedByDefault:

But what if I want for example to have the option to manually resize something? Roassal gives me RTResizeable. Would I have to write some special TLInteraction or can I somehow reuse what Roassal offers? This also applies for Roassal interactions in general.
compositeExpandedByDefault is not about resizing; it is about showing children of a composite node. Resizing is just a side effect because currently Telescope make some room for that (maybe a better strategy would be to create smaller elements for children and not resize parent). If you want to resize something, just change style with TLStyleCustomizationAction.

And even for Roassal in general... e.g.

RTShape allSubclasses size. "30"
TLSimpleShape allSubclasses size. "3"

So if I wanted to use some other shape from Roassal (for example box with rounded corners), would I have to create matching TL shape and then define mapping in the generator/connector?
In my opinion, rounded corners are not another kinds of shapes, just a customization of existing and so should be a style attribute. Yes you can create your own subclasses of TLShape but Telescope is not designed to just make easier to use Roassal but to offer a bigger level of abstraction. 

Telescope is not about thinking in term of drawing but in term of visualization model.


Thanks,
Peter


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--
Guillaume Larcheveque


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Telescope [was Re: Roassal3 and Bloc]

stepharo
In reply to this post by Peter Uhnak
Peter

telescope idea is that you can define visualization (model) where you can
define advanced behavior and reuse it.
We presented last year the model to alex and this year again and
he saw that there is a real added value.

Scripts does not let us reuse and build more complex model.
Telescope has a visualziation model (not a canvas on which you write)
+ composite + advanced interaction.
telescope model should be taken and used in future version of Roassal.
We do not take it personally if alex takes synectique's code/ideas.
For us we will continue to build around and if telescope is fusioned
into Roassal 3
then even better.

I dream about
     Roassal 3 = Bloc + Telescope + some part of Roassal 2 (layout....)

And roassal 3 does not have to be compatible to Roassal2. And people do
not have
to migrate to Roassal 3.

Stef

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Telescope [was Re: Roassal3 and Bloc]

Peter Uhnak
Hi Stef,

I do understand (at least partially) the value behind it and I tried to play with it more, and there were things that I really liked...
However I feel like many of those concepts should've been introduced directly as part (or an extension) of Roassal, instead of top of it, because that seriously limits its (re)usability without fully committing to Telescope.

In any case from my experiments and considering all other things (like serious lack of documentation, even smaller user-base, different API, ...), I think that it would be currently too much work for too little added value for me,
because I already had to solve some of the problems you guys had on my own, so I would be basically spend a lot of time rewriting code and at the end I would be where I started... and then Roassal 3 would come and I would have to rewrite again.

Also another important part is the overall user experience, so this definitely means that I will need to dive deep into Roassal (and even Morphic) to make things work (as I've already done and continue to do). And since you decided that you want yet another layer between Telescope and Roassal (to be able have another rendering libraries (although from the Telescope code I've seen it's not exactly separated)).
So this would mean for me that I would have to write a lot of stuff twice (or three times (Roassal+Telescope+adapter)); and again, with little added benefit for me (and since I'm not payed for what I do; what I want is my primary concern).

So to summarize...
I think that currently best scenario is to postpone it and look at it again when Roassal 3 starts rolling around, because I will be migrating to Roassal 3 for sure also because of Bloc.
This will also give me more time to familiarize myself more with Telescope and make the transition less painful.

Peter

On Sat, Jul 25, 2015 at 12:41 PM, stepharo <[hidden email]> wrote:
Peter

telescope idea is that you can define visualization (model) where you can
define advanced behavior and reuse it.
We presented last year the model to alex and this year again and
he saw that there is a real added value.

Scripts does not let us reuse and build more complex model.
Telescope has a visualziation model (not a canvas on which you write)
+ composite + advanced interaction.
telescope model should be taken and used in future version of Roassal.
We do not take it personally if alex takes synectique's code/ideas.
For us we will continue to build around and if telescope is fusioned into Roassal 3
then even better.

I dream about
    Roassal 3 = Bloc + Telescope + some part of Roassal 2 (layout....)

And roassal 3 does not have to be compatible to Roassal2. And people do not have
to migrate to Roassal 3.

Stef


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev