Hello I am not a developer. I have a project that I plan to have developed (in RoR) for a web-application to offer as a SaaS, and have spoken with several developers, but, until I have confirmed interest in the project, I cannot have it written. In the meantime, I am preparing a presentation (slideshow and website) about the possible application.
One portion of the project was easy for me to create screenshots for; I realize that the final project may not be exactly what I have designed, but close enough to not make a difference to my prospective users. The next part is more complicated for me, and I would like the community's feedback on which of the following ways of handling the task might be the most feasible in order for me to have the output that I want/need. As I have not made my final selection yet for a developer, it would be inappropriate for me to ask them. The subject is tracking nuances about contracts. The details tend to want to divide themselves into broad categories (such as compensation, royalties, advance against royalty, preliminary fee, fixed royalty, favored nations, merchandising, cast album, etc etc etc). Each broad category may have one or more terms associated with it (eg, ROYALTY sub-categories would be: pre-recoupment, pre-recoupment with amortization, post-recoupment, guarantee). Some of the terms are 'stock clauses' which are used frequently. In my head, I have several ways of approaching this, all of which would lend themselves to different UI. I would like to know if RoR lends itself more to one than another - AND WHICH WILL YIELD THE EASIEST way for me to have the online or printed report/view that I need (see bottom) 1. simple table, along the lines of an entity-attribute-value model. I know this is widely discouraged, so I'll pass on this. 2. Finite here, I would have to think of every conceivable term that might appear in a contract, and create a field for it. The field value could be a picklist/valuelist of the stock clauses, with the user able to add one on the fly. I have dismissed this option, as it would be virtually impossible for me to think of every single term that might appear. But, as I write this, I am second-guessing myself. Perhaps it FEELS like an unlimited # of terms, but perhaps they really do fall into a defined list, and I could do it this way..... 3a. what I think of as an exploding star. each broad category would have its own 'table', with basically 2 fields (one for sub-category and one for description of terms). I envision the interface to have the contract table info at the top of the screen, with separate tables underneath which expand/collapse 3b. A hybrid between option 2 and option 3 Little tables for each category, but each little table has specific fields for each possible term type 4. Category and tag Here, the UI would be such that the user selects a Broad Category, enters a description (perhaps from a picklist), and then assigns 'tags' - and the tags would be, in effect, the sub-categories. I think I would have to restrict which users are permitted to 'create' categories or tags, to ensure data integrity and all that jazz. They all have benefits, but the user interface for them would be quite different..... I envision 2 styles of output: a. 1st column is the entity - the person the contract is with; subsequent columns need to be selected by user from the associated tables... I think this is pretty easy and straightforward. It's fine, but means we can only view a handful of terms at a time before it becomes unwieldy from left-to-right. b. this is my premier output and a primary selling point of my application. This is what I think of as an n-up report, or a textual- pivot, or a 'compare these cameras' style. In this output, I'd like the user to be able to select a finite number of contracts (let's say 5), and have the info from the parent table be the columns (ie, people's names), and have the rows be the associated values - preferably with each broad category of items being able to open/ collapse... and/or have the user be able to specify which associated values to include/exclude. These 2 reporting styles are so important to me that I am willing to do whatever UI for getting the information into the database is necessary, in order to have the desired output, without causing extensive pain to my developer or to my bank account. Advice? Suggestions? thank you - Marion --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---