Implementing a workflow... (1 Viewer)

lpapad

Registered User.
Local time
Today, 17:15
Joined
Jul 7, 2018
Messages
47
Please suggest best practices on implementation of a workflow, the user should be guided to complete a number of forms by following certain sequence.
 

NauticalGent

Ignore List Poster Boy
Local time
Today, 11:15
Joined
Apr 27, 2015
Messages
6,286
For clarification, when you mention workflows, do you mean Sharepoint workflows?
 

Cronk

Registered User.
Local time
Tomorrow, 02:15
Joined
Jul 4, 2013
Messages
2,770
I don't know about "best practices" but I'd be inclined to have one or more forms opened in dialog mode with Forward/Backwards arrows with data entry controls hidden, apart from the first one, but in a sequence revealed after the data validity checks on the entry in the previous control had been made.
 

MarkK

bit cruncher
Local time
Today, 08:15
Joined
Mar 17, 2004
Messages
8,178
New database designers typically make interfaces that are, let's call it 'data-centric', in which they design the interface based on the structure of the data. Maybe there is a main form, say for Jobs, fully editable with ALL the parent row fields, and maybe four subforms, datasheets, for contacts, orders, JobSections, expenses, whatever. This design is data-centric in that it is an interface that mimics the structure of the data.

But when you look at tasks and workflow, what you find is that for every job created, the user creates, on average, 127 expenses in a subform of the jobs form, three pages in on a tab control, and needs to enable edits by clicking a button. Grrr.

Make the task simpler. Forget about the monolithic 'data-centric' UI. Make a 'user-centric,' or 'task-centric' UI, and create an Add Expense Wizard, where the user can keep the form open all the time, can select the job using a combo, can start adding a new expenses record right away, without delay, without navigating to the parent row, without tabbing thru subforms.

This is, I think, what separates good tools from crappy ones. Simplicity and clarity of purpose. Focus on the objective not on the context. Make the objective the only obvious thing the user can do.

hth
Mark
 

Cronk

Registered User.
Local time
Tomorrow, 02:15
Joined
Jul 4, 2013
Messages
2,770
Mark, I fully agree about aiming to provide a good tool. As developers, we need to keep in mind the end purpose is not a well designed database, or table structure or whatever, it's to provide a good tool for the user - although all the former lay a path to achieve that goal.



I tell front line users at the beginning of any new project that my aim is to produce a tool which is easy to use and will make their jobs easier. Any database has to be easy to enter data, and then easy to subsequently find records for edit or viewing. I make a commitment to be judged on that.


Bosses get told a different story about better productivity and good reporting for management and planning.
 

jleach

Registered User.
Local time
Today, 11:15
Joined
Jan 4, 2012
Messages
308
Somewhere I have a template form and accompanying class module that creates a wizard shell, and you load it up and point a bunch of subforms to it, one for each page. The shell is a form with a header and footer buttons (next, previous, finish, cancel as applicable) and is responsible for calling each "page" (subform's) public Validate method (or use an interface/implements if you want to be fancy) and a few other required methods to determine which buttons are enabled, etc.

It was nice to have all the common "wizard logic" separate from the the pages, but was one of those projects where I'm not sure the effort of writing it all ever really paid off (e.g., didn't use it often enough after to justify the time into developing the wizard base code, but OTOH, that's the way it would have been done if it were done "right" anyway...)

Just an idea. Not actually sure where that code is now (or whether it's in publicly publishable state!)
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 11:15
Joined
Feb 19, 2002
Messages
42,986
Workflow might be helpful in some situations but you have to be flexible. What happens if someone gets three forms in and for some reason can't finish? How can they save what they've done and then get back to it. You'll have to track partially completed workflows so the users don't lose them because you need to prompt them every time they come back to the application that they need to finish something they started.

The most flexible method of controlling a workflow is to keep a table of what forms to display in what order. Then as a user completes each one, it is logged so you can keep track of where they are. Using a table to control the flow will be the easiest to modify if you need to add a form or change the order.

New developers tend to get wrapped up in controlling every mouse movement and that is simply not productive. I once had a developer lock up the entire CICS system on our mainframe, during testing because his code prevented the user from leaving the form before it was finished.
 

Users who are viewing this thread

Top Bottom