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 -~----------~----~----~----~------~----~------~--~---
Don Miguel de los Platanos
2006-Oct-04 15:15 UTC
Re: Enterprise Software is all about wizards
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 -~----------~----~----~----~------~----~------~--~---
Julian ''Julik'' Tarkhanov
2006-Oct-04 16:00 UTC
Re: Enterprise Software is all about wizards
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 -~----------~----~----~----~------~----~------~--~---