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.
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
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.
thank you -