Towards stream/varying explanation

[Evan Czaplicki]

I am thinking about how to visualize streams and varyings to see if we can come up with a really nice way to document how these things work. The challenge will be: can we come up with an equally good explanation with signals?

There should be a preview of visualizations for stream and varying below. I'm wondering if it's possible to do better than marble diagrams (which I found quite confusing at first). I'm also thinking it might be valuable to make these interactive, so people can see what happens as they do stuff.

​

[John Mayer]

Looks OK...

For events, I wouldn't have a y axis, but instead just time with values inside the marbles.

For varying, I'd connect the graph, make it more like a step function. Use oscilloscope colors maybe :-)

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Richard Feldman]

I actually really like the way these are right now...imagining the Keyboard.presses graph without a Y-axis seems like it wouldn't feel like a graph anymore, and I like the disconnected lines on the Window.width graph.

Separately, these are great and really seem like they'll do a good job getting the distinction across!

[Dobes Vandermeer]

I agree with John, that for events it should be a grid where the Y axis is the event and the X axis is time.  For keys the content of the event would be written side-by-side.

For a "continuous" value the row could be a bit taller and have its own mini y-axis should it's value over time.

If you are using the concept of a timeline, there's such a widget in animation programs that kind of operates and looks this way.  The audio tracks, events, and animation parameters each get their own row.

e.g.

https://www.reallusion.com/iclone/help/iclone5/Images/Animation_Timeline_Editing_01.jpg

On Mon, Mar 23, 2015 at 2:53 PM Richard Feldman <richard....@gmail.com> wrote:

I actually really like the way these are right now...imagining the Keyboard.presses graph without a Y-axis seems like it wouldn't feel like a graph anymore, and I like the disconnected lines on the Window.width graph.

Separately, these are great and really seem like they'll do a good job getting the distinction across!

--

[Max Goldstein]

Keep the window width disconnected.

Regardless of whether it gets flattened, I'd like to see the keyboard better emphasize that the events are not (necessarily) periodic.

[Jeff Smits]

Marble diagrams work well in Rx because an Observable has a start, an normal end, or an abnormal end (exception), and can have sub-observables (and even marble diagrams stretch pretty thin there). 

Those marble diagrams are nice because it's a detailed demonstration of behaviour of a method that works on observables. It's an observable timeline, then a box naming the method (optionally with other arguments), then the resulting observable timeline. Because the observable timelines are vertically stacked you can easily compare what happens with time. And you can stack multiple of these operation boxes. 

I think these two graphs show pretty well how Stream (pulses) and Varying (jump discontinuous) are different. But if you want to use these in marble-diagram-like situations to show what functions on Stream/Varying do, I think you need a shorter Y-axis to keep it clear. 

On Mon, Mar 23, 2015 at 11:47 PM, Max Goldstein <maxgol...@gmail.com> wrote:

Keep the window width disconnected.

Regardless of whether it gets flattened, I'd like to see the keyboard better emphasize that the events are not (necessarily) periodic.

--