Rails - Oct 2006 - Enterprise Software is all about wizards

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.

(I know a wizard plugin exists)

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

I don''t see how this could be a constraint for Rails.

On 10/4/06, Chris
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
>
> 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.
>
> (I know a wizard plugin exists)
>
> --
> Posted via http://www.ruby-forum.com/.
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 10/4/06, Chris
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
> 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.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 4-okt-2006, at 17:09, Chris wrote:
> 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.

<flame>Never mentioning that wizards are terribly ugly and  
humiliating for the users, in the first place</flame>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

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.

Starr


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 10/4/06, Chris
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> 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.



-- 
Austin Govella
Thinking & Making: IA, UX, and IxD
http://thinkingandmaking.com
austin.govella-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 10/4/06, Starr <snhorne-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 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?)



-- 
Austin Govella
Thinking & Making: IA, UX, and IxD
http://thinkingandmaking.com
austin.govella-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Hi Austin,

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):

Full:  User.signup >> Billing.add_card >> Dashboard.index
Partial:  User.signup >> Subscription.confirm >> Project.show

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.

Cheers
Starr
---
www.thebootstrapnation.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---