Solution Scene Control / Workflow

In this Lesson

In this lesson you will learn techniques which can help you manage the user experience.


There are two questions which help define your solution’s personality.

The on-ramp question

What does a person see when they click on your product icon?

The on-ramp question determines the starting point for the workflow. Let’s look at some possible patterns before we get into the details.

Here are two very simple examples

These examples present more instrumentation to the user via multiple scenes

These two offer user authentication. One requires authentication before the solution can be used and the other allows some portion to be used without authentication.

The exit-ramp question

What does a person see when they complete a task?

The exit-ramp question is concerned with bringing a person back to a sensible place once they have completed a process.

Initial Scene

Every solution specifies an initial scene which answers the on-ramp question.

The initial scene is generally what the user first sees – but it does not have to be.

The default behavior will

  1. Start the Initial Scene in the center session
  2. Start any supporting scenes listed in the Scenes to Start with the Initial Scene section

The supporting scenes make this style of initial presentation possible

If you need variable initial scene behavior then the initial scene’s agent could do one of two things

  1. Use an API to start the appropriate scene (discussed in a future lesson)
  2. Set boolean values in its scheme which indicate the type of information to be displayed and allow the designer to use state bound layer injection to display the proper layer(s) in the initial scene.

Home Scene

A solution may optionally define a home scene which can be used in two different ways

  1. The solution starting point
  2. The process return point
Solution Starting Point

You might think the initial scene is always the starting point for a solution – but this is generally not the case for authenticated solutions. The sign on scene is the initial scene presented to the user but it is not the starting point for the solution. The solution is started only after the user is successfully authenticated.

The sign on agent is responsible for calling the API to test the user ID and password and then starting the solution after successful authentication. The sign-on process has three options for starting the solution

  1. The scene could perform a scene transition to start the solution
  2. The agent could make a scene request to start the solution
  3. The agent could call the startSolution method in the Pump class

The startSolution API uses these definitions from the solution.

The default behavior for startSolution is as follows

  1. If the solution specifies a Home Scene Adapter class then the Pump will ask that class for the scene to be started. The adapter is a class which implements com.seronix.soiree.navigation.HomeSceneAdapterInterface.
  2. If there is no adapter class then the Pump will start the Home scene in the center session if one is specified.
  3. The Pump will start any supporting scene listed in the Scenes to Start with the Home scene.

The Home Scene Adapter allows you to provide a variable home scene based on the user profile or other criteria.

Process Return Point

If a Home Scene is specified it is used as the return point for the center session. If the scene in the center session is closed (i.e. closing all of its layers) then the Pump will start the home session in the center session.

This is a convenient way to specify the default return point for all processes. The alternative would be to have each closing scene to transition to another scene.

The Soiree client will close its home window if all the layers in all of the home’s scenes are closed.

One possible example of this feature would be a solution that shows a menu in the center scene (as opposed to a docked scene). The menu would be displayed when the solution is started and any time the center session scene is closed. This provides forward and reverse navigation without any hard-wiring of scene transitions.

Reverse Scene Transition

Every agent contains a boolean node named reverseSceneTransitionAllowed. This node is not observable in the agent editor because it is automatically added to all agents. The node is available for use in the scene editor as shown here

This node is set to true if the scene containing the agent was started via a scene transition. This node can be used to perform conditional reverse navigation by binding the boolean value to elements in the scene

  • A “back” button could be displayed if this node is true. That button would be defined to perform a reverse transition as shown here

  • A “close” button could be hidden if this node is true. That button would simply close all the layers in the scene.
  • These two buttons could occupy the same location in the scene. In this way the use either sees “back” or “close” depending on how they arrived at the scene.
There are times when you may want to ‘reset’ the forward transition stack. Perhaps you have transitioned to a ‘new’ starting point and you don’t want the reverseSceneTransitionAllowed node to be true again until the next transition. Call Pump.clearSceneTransitionHistory. After calling this method any future requests for a reverse scene transition requests will be a NOOP until a new forward scene transition is received.
Work Flow Processing

One could always leave the home scene blank and hard-wire the navigation flows into the solution via scene transitions in the scene or scene requests in the agent.

One could also imagine the creation of a work-flow engine operating within the solution.

  1. Create a ‘workflow’ agent responsible for deciding what the next step in the process should be. This agent would look at the state of the information contained in the solution in order to determine where to go next.
  2. Create a ‘work flow’ scene which contains the agent but no visual elements.
  3. Every step in the process could be a normal scene which captures, displays, or processes information. Each of these scenes would transition to the ‘workflow’ scene when they are done.
  4. The workflow scene would cause the workflow agent to be started which would then use the API to request the next appropriate scene.

  5. That concludes this lesson.