With today’s morning build (3/11), the console looks much improved.
+1 on the other ideas.
Here’s a few additional comments.
I see edges on Tuple count, but can barely see many of the edges in Static
view and Oplet kind are very faint on my monitor – can the edges be
darkened a tad?
Tuple count legend
1. ‘Not applicable – counter not present’.
It looks like this is for an edge connected to counterOps that are
not between 2 real vertices and this edge always has 0 tuple count. The
blue color shades are starting to look similar. Maybe make these N/A edges
look different, say with a dotted line.
2. Legend colors:
It looks like the colors apply to the edges only? If yes, can the
legend dots be changed to a rectangle (wider than taller) to look like an
edge snippet?
For DevelopmentProvider topologies, consider adding an option to only
display non-counterOps (this would reduce the clutter).
May
On Fri, Mar 11, 2016 at 9:42 AM, Susan Cline <[email protected]>
wrote:
> HI,
>
> I merged a few changes that I believe will enhance the console:
>
> - remove the OP_X and just display X for oplets
> - make the counter ops look less significant or grey them out - I changed
> the size to always be the same, regardless of tuple flow, I turned them
> into a square and I made them a bland grey color
> - changed the timeout for dismissing the hover over the oplets to be half
> of what it was
>
> If folks think any of the other items are useful or have other suggestions
> please speak up. One thing I’m leaning towards wanting to do, but would
> like feedback on is:
>
> in the tuple count view, removing coloring by edges, instead color oplet
> by tuple flow. This would allow a user to see tuple count and stream tags
> in the same view.
>
> >>>
> >>> Somewhat related to this is there should be a view that represents how
> a
> >>> developer coded their application, which is through the topology api,
> where
> >>> (for the most part) oplets do not exist. I'm not sure what exactly this
> >>> would look like, but it's a move away from having oplets as the first
> class
> >>> objects, to having streams and windows as the first class objects.
> Maybe
> >>> such a graph would look similar but the focus would not be on oplets,
> e.g.
> >>> oplet names like OP_1 have no meaning to the application developer.
> >>>
> >>> We may in the future have the physical representation (oplets) be
> heavily
> >>> transformed from the logical view (topology), so in that case having a
> >>> logical view is much more useful, e.g. imagine an extreme case where
> the
> >>> graph has been optimized down to a single oplet.
> >>>
> >>> See: https://github.com/quarks-edge/quarks/wiki/Quarks-Etiao-Runtime
> >>>
> >>>
> >>>> 3. If a topology has counter metrics on all oplets (i.e,
> >>> DevelopmentProvider is
> >>>> used) either a) remove all oplets from the graph or b) make the
> counter
> >>> ops look
> >>>> less significant or 'grey' them out from the graph.
> >>>
> >>> I think there are a number of oplets where the visualization could be
> >>> simplified, e.g. FanIn, Union Isolate etc. could be not shown in the
> >>> graph, as they are low-level building blocks somewhat unrelated to the
> >>> application graph.
> >>>
> >>>
> >>> Dan.
> >>>
>
>
> With regard to Dan’s comment, is this something that I will need support
> from the runtime or api for? I don’t have control over what I get from the
> graph now.
>
> Here is a list of the other possible items I was thinking of for the
> console:
>
> 5. Add the ability to plot multiple oplets at the same time as line charts
> - only one oplet at a time can be plotted
>
> 6. Add the ability to view the metrics chart as a separate window -
> similar to the View all oplet properties window
>
> 7. Ability to zoom in on one region of the graph to better understand the
> topology. Either zoom into the existing graph, or put a new graph below,
> or have a new window with the zoomed in graph
>
> 9. Add a new view, similar to Tuple count, but instead show rate meters
>
> Susan
>
