3

Consider a use case of the form:

  1. The system shows a list of potential filters (by name, by creation time...).
  2. User chooses a filter and supplies necessary parameters.
  3. System shows a list of potential objects.
  4. User chooses a single object.
  5. System returns the chosen object in some way.

I'm stuck on how this sequentiality would be enforced in the application.

Assume that we try to loosely couple the UI from the business logic. I would suspect that we have some kind of UI class (Command-line, graphical...). This would be one end of the boundary. On the other side of the boundary, there would be one or more controller classes.

On the one hand, I could enforce this sequentiality in the UI. By going step by step through this use case, it would be very easy to prevent the user from starting step 4 before completing step 2. In the controllers, there would be some method for every substep ( searchWithFilters(...), chooseInList(...)) and the UI would call them at the appropriate times. However, if the UI happen to be redesigned in something else, it is up to that designer to enforce the sequentiality in his UI.

Is there any way I can enforce this sequentiality in the controller, so that this burden is not upon the UI? Would this be a good idea to do? How would I do this?

  • 5
    Why is there a need to "enforce sequentiality"? This sounds like a workflow whose desirability depends on UX reasons rather than a technical limitation. Maybe the user who reaches step 4 wants to link that object to others, who will thereby skip the first three steps. As long as objects and filters have globally unique ids, what would be wrong with an alternative UI doing those steps "out of order"? – Ixrec Feb 20 '16 at 0:37
5

Is there any way I can enforce this sequentiality in the controller, so that this burden is not upon the UI? Would this be a good idea to do? How would I do this?

Enforcing this workflow is probably NOT a good idea in the API. The UI design and layout is always going to be a "burden" on the UI and forcing a particular UI is going to limit potential UIs in the future. For example, I may create a UI on a mobile device or smartwatch that shows a limited list or a single entry only, skipping or replacing steps 1 to 3.

The best way of approaching this is to split the API into multiple areas (possibly represented by different controllers).

One area would be accessing lists of filtered objects, handling steps 1 to 3. The filters could either be hard coded or described in some form of query language. The query language gives the UI the most flexibility but is more work to create and potentially creates security vulnerabilities. You should also consider paging or limiting the results of you are dealing with large numbers of objects. Standards like OData help for truly generic data but you probably do not have to go that extent.

The second area would be viewing and editing individual objects for steps 4 and 5. How you do this depends heavily on the API and data being edited. You may want to use straight JSON over REST in a single call or split the object into different web calls for different aspects of the object.

If you must handle sequentiality in APIs, such as steps in a workflow, create some form of context or workflow ID and pass that to each API call. Each API can check whether the required preceding steps have been completed. It can also be an identifier for state information. Note that this design can create server affinity issues or add more load on the system with the additional checks.

  • Your post answered all my questions. Thanks a lot. – user2890248 Feb 20 '16 at 8:14
1

You can guild the user thru these steps by selectively revealing the available information that enables the user to reach the next step.

However, we don't want to be too restrictive on a specific ordering. For example, there should be a loop (backedge) from 3 to 2, in that the user may apply additional criteria.

For the UI, what I would do is provide two panes or areas. One having the battery of potential filters, sorts, etc..., and the other having filtered results. The first time to this page or window (e.g. no filters selected), your domain might have too many results, so you just show a placeholder instructing the user to select filters, otherwise you show all results.

If your data is tabular, you can integrate the filter & sorts into the column headers.

Each time a filter is selected, you elicit the parameters; this in the first pane. Each time a filter is given parameters, you update the second pane, which has the current filtered results.

At any point in time, if the user clicks on one item, you take them there (i.e to another page or window showing that single item).

When it comes to command line, you will have more trouble enforcing, but then so what? Provide useful command line options, and let the user issue commands as they see fit. Provide a query of potential filter/sort options. Possibly allow the assembly of a filter set, and allow a query using that filter set. And allow selection a single item by primary key, for example. There's no need to restrict the ordering here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.