Usability: pipeline editor should indicate if there are problems in the flow configuration and where they are

[ptitzler]

Using the Beta release I've created a notebook flow and forgot to associate a runtime environment with each notebook. Running the flow the following user unfriendly stack trace is displayed in the error dialog:

Traceback (most recent call last):
  File "/Users/patti/anaconda3/envs/elyra_basic_37/lib/python3.7/site-packages/tornado/web.py", line 1703, in _execute
    result = await result
  File "/Users/patti/anaconda3/envs/elyra_basic_37/lib/python3.7/site-packages/tornado/gen.py", line 191, in wrapper
    result = func(*args, **kwargs)
  File "/Users/patti/anaconda3/envs/elyra_basic_37/lib/python3.7/site-packages/elyra/pipeline/handlers.py", line 91, in post
    pipeline = PipelineParser.parse(pipeline_definition)
  File "/Users/patti/anaconda3/envs/elyra_basic_37/lib/python3.7/site-packages/elyra/pipeline/parser.py", line 97, in parse
    parent_operations=links
  File "/Users/patti/anaconda3/envs/elyra_basic_37/lib/python3.7/site-packages/elyra/pipeline/pipeline.py", line 55, in __init__
    raise ValueError("Invalid pipeline operation: Missing field 'operation runtime image'.")
ValueError: Invalid pipeline operation: Missing field 'operation runtime image'.

The current behavior raises a couple of usability issues:

• The user needs to understand what the stack trace error is indicating in order to resolve the issue.
• Since it is known ahead of time that certain properties must be set (or the flow won't run as expected) the editor should flag problematic configuration issues, e.g. by visually marking a notebook node.
• Imagine a flow that contains 20 notebooks. If the editor doesn't indicate which node (or nodes) are misconfigured, a user has to manually inspect every node in the flow to find out which ones are not correctly configured.

[kevin-bates]

Seems like some simple schema that indicates required fields and perhaps some basic data types and values could be implemented such that it could be used on the front (and back) end (s) to perform basic value checking.

[ptitzler]

An example, for illustrative purposes, how this is surfaced in Node-RED. Problematic nodes are "tagged" and an issue summary displayed if a user hovers over the icon.

If one tries to deploy a flow that has issues a warning is displayed, alerting the user to the fact that there are issues (which might be easy to miss if there are dozens and dozens of nodes on the canvas).

Another possible approach to surface issues, which would micmic the behaviors of IDEs that expose an error view:

Personally I find this approach is more user friendly because it doesn't rely on a user's ability to notice a small icon or move the mouse cursor to an exact spot to open the tool tip. A double click on an entry navigates to the location where the problem was detected.

[ptitzler]

The same problem surfaces if one tries to export a pipeline that is misconfigured. There might be other ops that might fails as well.

[ptitzler]

See also #659. In that scenario the pipeline opens without displaying any warning that the referenced notebooks cannot be found. The only indication a user has is when he/she tries to open a notebook and nothing happens. To identify the problem one has to inspect the log file which displays a 404 and to actually solve the problem one has to manually edit the .pipeline file or rebuild it.