Flow Based Programming with Hololens

[Ged Byrne]

Hi All,

I have to admit that I'm rather excited about Microsoft's Hololens: https://www.youtube.com/watch?v=8t3dNIl0AeU

Imagine a cross functional team wearing these augmented reality headsets walking around a three dimensional flow graph describing their production systems.  The movement of IPs is shown in real time before their eyes.  A member can drill down to a component a view the queueing packets or examine it's internal state.  Errors are raised immediately and dealt with interactively.

Does anybody else think that this is how software should be done?

Would the use of three dimensions open up any new opportunities?  What extra information could be conveyed in that extra dimension?

Could this actually be a nightmare, with sprawling graphs of tiny, ill considered blocks, filling the room with a virtual mess?

Regards, 

Ged

[Raoul Duke]

> Could this actually be a nightmare, with sprawling graphs of tiny, ill
> considered blocks, filling the room with a virtual mess?

it will be a nightmare for the maintenance programmer who doesn't have
a hololens setup.

sort of like flowers for algernon.

[Alfredo Sistema]

I've been thinking about FBP in a VR environment for a long while, and
since then started to make my own editor and DSL for it, but 2D. I
settled with autolayouting for various reasons, but I think that
what's valuable in a 3d environment is not just the graph but the
accesories, like documents, videos, audio, anything that enriches the
graph. Also views, for example packet load, or any kind of debug data
that can be seen as a whole. In my humble opinion a big part of FBP is
the study of the input data, and usually it comes from the "real
world", that is, a garbled mess of requirements and problems. Wouldn't
it be nice to have this data within the graph, or extracting
information from the graph to use a "gauges" in your overall hololens
experience?
We already have "augmented reality" in a very primitive form, that is,
printed paper with data, we don't even notice that, but if you think
about it, when you are discussing some software architecture or
implementation in a meeting, you carry some printed paper with you, or
show some metaphor of it with a phone/tablet/laptop, even a projector,
you could convey the same information in better ways with this kind of
setup.
I would love to experiment with a VR setup and/or Hololens for FBP but
money is a problem.

> --
> You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Sam Watkins]

On Wed, May 20, 2015 at 07:33:47AM -0700, Ged Byrne wrote:
> Imagine a cross functional team wearing these augmented reality headsets
> walking around a three dimensional flow graph describing their production
> systems.

I like the idea of examining a running FBP system, but I think a 2d
display is sufficient to do this, and 3d might bring more problems than
it solves. I've played plenty of 3d games, wandering around in a 3d
maze can be very confusing!

It's good to be able to print a graph, or view it on a 2d monitor.
Up until now almost all of humanity's knowledge has been printed on 2d
paper or encoded on 2d webpages.

Still, we can use automatic graph layout to render graphs in 2d or in 3d
depending on the viewer's preference.

[Paul Morrison]

I tend to agree with Sam that 2D is good enough for most purposes, while free-form 3D could get confusing!  That said, possibly 2.5D might work well for subnets or zooming in and out.  Zooming has always been a bit of a problem in these diagrams - some packages opt for showing more or less of the detail within a block, depending on the zoom level, while others just reduce everything to the point of illegibility - or the other way, of course!  So I could sort of see spawning or dropping levels of a diagram as the user zooms in or out, respectively.

Regards,

Paul M.