Would any one else say that enterprise systems (+150 tables) are mainly
consisted of wizards.
The flow in the software from screen to screen is looselt based on how
the business flows, and is required to be very structured. From screen
to screen the options available to the user are very limited. There is
not much freedom and the user is not overwhelmed with options.
Complex applications require wizards.
For simple applications wizards are not required.
What do you think?
How does rails fare when looked at in conjunction with the wizard
style?
Rails doesn’t seem architectured towards the wizard style.
Would any one else say that enterprise systems (+150 tables) are mainly
consisted of wizards.
I think it is accurate to say that many enterprise systems have highly
railroaded interaction methods, like Wizard abuse and very deep menu
structure.
The flow in the software from screen to screen is looselt based on how
the business flows, and is required to be very structured. From screen
to screen the options available to the user are very limited. There is
not much freedom and the user is not overwhelmed with options.
This is because they don’t have the resources to make a proper design.
Much of the UI matches the way that additions are made - if
functionality
is bolted on, it gets bolted-on UI interaction.
Complex applications require wizards.
For simple applications wizards are not required.
Thats bad UI dogma. I don’t think that Rails should adopt the weakest
UI structures just because they are prevalent in the industry.
Economic constraints on the development of large in-house
enterprise systems force them frequently to take a non-systems
approach to ongoing development. You often get duplicated
database tables for instance, or the reverse, over-fat GUIs that
are artificially creating table relationships in code, because the
schema is untouchable. These systems typically have the
worst UIs imaginable, and force their users through wizards,
byzantine menus, etc. because its the only way that they can reliably
enter data.
This does bring up an interesting point about flow control.
Even when you’re not using a wizard-style intereface, there will be
times when the application needs to have a slightly more complex
behavior than a simple redirect or render. Say, a chain of redirects
that happens only when the user first signs up.
It seems ugly to embed this across several actions and controllers.
.
I’ve been thinking about the possibility of separating program flow
from controllers / actions. To make a kind of DSL that says, “under
these conditions, follow this path”
Have done some work on a plugin - nothing that’s release-worthy though.
How does rails fare when looked at in conjunction with the wizard
style?
Not too well but you can engineer it fairly easily. There also were
plugins designed to make the task easier.
Rails doesn’t seem architectured towards the wizard style.
No, because Rails is architectured around doing an action in one
request-response cycle. It’s not well fit for spreading a business
transaction across many requests, but you can do it nevertheless.
Never mentioning that wizards are terribly ugly and
humiliating for the users, in the first place
Would any one else say that enterprise systems (+150 tables) are mainly
consisted of wizards.
The flow in the software from screen to screen is looselt based on how
the business flows, and is required to be very structured. From screen
to screen the options available to the user are very limited. There is
not much freedom and the user is not overwhelmed with options.
I just wanted to re-iterate that this is a sign of bad design and has
nothing to do with enterprises.
Very few things should ever use wizards. The book, About Face 2.0 has
a great discussion of when you should and should no use wizards.
Even when you’re not using a wizard-style intereface, there will be
times when the application needs to have a slightly more complex
behavior than a simple redirect or render. Say, a chain of redirects
that happens only when the user first signs up.
Couldn’t you handle this in one controller? Place cross-controller
code in helpers?
I’ve been thinking about the possibility of separating program flow
from controllers / actions.
I thought controllers controlled application flow. Controllers don’t
have to map to just one model. Right? (Or am I just crazy?)
You’re right - for most cases controllers handel application flow just
fine. After you create a record, you’ll probably want to redirect to
the list of records, etc.
But there are certain cases where you need to completely change this
up. For example: An app I’m working on has two ways you can sign up -
full and partial. The program flow looks something like this (it might
look weird here, but makes sense in context of the project):
Sure, I could add conditional redirects to each of these actions. But
things get tangled up pretty quickly.
Also, I could make a new single controller that wraps all of these
controller/action pairs. That wouldn’t be a bad idea, actually. I think
the only way to do that would be to use components. Aren’t those being
phased out?
Anyway, I don’t have the answer to all of this - but its an interesting
problem.