playMaker

Author Topic: Predictive suggestion of states and actions  (Read 1281 times)

Broken Stylus

  • Beta Group
  • Hero Member
  • *
  • Posts: 772
Predictive suggestion of states and actions
« on: September 11, 2019, 09:00:00 AM »
In classical text-based coding, the NDE provides a set of tools to help the programmers work faster within their environment. One of these tools is the simple suggestion of what to add next in a given line of code, based on the first and then successive letters or symbols added by the user.

I think the next big step, a major feature of Playmaker, could be something similar with the suggestion of use of certain actions based on three sources of data:

 1. most logical combinations of actions (most likely defined by the Playmaker team)
 2. the developer's most used combinations of actions (this is an extension of favorites that takes into account what actions are usually used together by the user)
 3. the developper's input in a search box

One thing I really dig about PM is how its search function for action is very lax; because it does not care about capital letters, spacing or even the placement of words. Maybe it could even prove even more tolerant by allowing for ignoring certain typos (like, 25% of typo is OK) but that's another topic.
I refer to this search function because it's relevant to point (3).

Now, how could this integrate into the Graph View? How could this present itself?
Obviously a popup that would appear where it seems logical. In text coding, this happens where the cursor is, as the dev types.
There are three main contexts:

 A. within the graph view
 B. within a state

In the first case (A), it would be logical that if no state is selected, the arrowed popup, a rectangle with a small triangle affixed to one of its vertical edges, pointing to somewhere in the graph view, appears where the cursor is or in the middle of the graph view.
When a state is selected, it appears next to the state. This requires a bit of scanning of the zone to detect where other states already are and if links are already criss-crossing the area.
The state and the first action including inside is based on the sum of all actions in the selected state, on its last action, on its exiting actions and its exit transitions.
The newly created state will be autolinked if the link is obvious, such as the currently selected one having only a FINISHED transition, or if a transition is already selected.

In the second case (B), the predictive behavior happens within the state and should happen on the State's inspector area. This where the popup should appear. The system will look into what actions have already been added into the state and also give a major influence on the last or selected action.
If an action is selected, the popup obviously tries to add a new action right after the currently selected action. As the popup appears, its little triangle (same one as explained above) therefore point to the bottom line of the selected action; this is where the blue line appears when you're moving an action manually with the mouse, trying to cram it between two other actions. Maybe this time the bar would look orange, yellow or blue.

The popup itself contains three areas:

 1. The input field at the top, where the user types the name of the action.
 2. the suggestions below, themselves divided into two vertical rectangles:
  a. the one on the left that strictly responds to the input and behaves like the search function in the action browser;
  b. the right rectangle that would contain the predictive suggestions (this is where a bit of artificial intelligence intervenes). Much less responsive to the input field, although it would also start to filter the list of proposed likely combinations if the input string becomes quite long, showing that the dev is looking for something more specific. The more the user has built a database of combinations, the more it would influence results and ignore the default combinations, although a default combination would probably be displayed at the top of that list. Default and favorite combinations might have their own slightly different colored backgrounds.

Both rectangles would grow to a certain size but beyond a given maximum size, scrollbars would appear.

Navigation through these two rectangles would be accessible via arrows too.
Down would automatically slide to the first suggestion below the input field, into the left rectangle. Left/Right would move from one rectangle to the other, to the action on the same level/line or closest level.

The popup itself is called with a very simple shortcut and intuitive combination of mouse buttons and keyboard keys.

As a commentary to this, if we go back to cases (A) and (B), the second one seems to be the most needed. It is the one which most of the work would be needed for. Case (A) would be an extension of this, providing states already filled with a most appropriate action.