(good?) Idea for improving Views

[stevenheidel]

I had an idea for solving some of the problems that people experience over views: View Groups.

Sort of like export groups and types. Let me give you an example:

On one of my forms I have 21 views. I could split them into three groups:

1 view is for me the admin, sees everything
10 views are for my 10 clients, each seeing a subset of data
10 views are for my website, which display a subset of data

The only thing that's different about each of the views in the groups of ten is the filter. The problem is that when I go to change something, (like add one field, make a field editable, etc) I have to go through and do that 10 times.

My idea: have an option when you create a form if you want a view group or a single view. Single view is just as it is now.

View Group would have common settings for the first three tabs (Main, Fields, Tabs). The filters page would be different. On this page, you could add additional views with different filters. I imagine it like a long list of fields:

Name of View
Filter
Client(s)

Name of View
Filter
Client(s)

Name of View
Filter
Client(s)

That way, changing a setting would be a snap, same with adding another view.

All the people who talk about the one client one filter scenario would benefit too. All they have to do is add all their clients, make one view group how they like it, then go through and type in filter, select client, type in filter, select client.

Anyways, just my thoughts. Hope this helps.

[Ben]

Hi Steven,

Excellent stuff. I've been mulling over your View Groups idea this entire afternoon - it's really very good! Where to start...

It seems to me there are two main problems with Views. Neither are functional - they currently do everything that's needed, it just that dealing with the whole mechanism is too cumbersome a process for many cases.

I'd say the problems boil down to these (feel free to disagree!):
(1) the speed of initial View creation and assignment to client accounts,
(2) maintainability of the Views (duplicate settings spread amongst multiple Views)

#1 is a little tricky. I'll leave that alone for the moment.

#2 is solved by your View Groups solution as well as I think it can be solved - only perhaps with a few modifications. Let me just rephrase your idea a bit then jot down some of my concerns.

It seems to me that what you're really suggesting is adding some sort of "inheritance" to the Views; you can create a View Group that defines all the settings (main settings, fields, tabs & filters), then create sub-Views / Child Views (or whatever) which inherit all the settings of the parent, except with the option to override whatever you want.

I'd definitely expand it to allow overriding ANYTHING - not just the filters and permissions - though I do agree that that would amount to 95% of the use-cases.

From a UI perspective, I picture the Add/Edit Child View page as identical to the existing Add/Edit View page - with the same four tab layout (main, fields, tabs and filters), except that all fields are just text - not editable fields. For each field, there'd be a "customize" button (or whatever), which would let you customize that setting for the Child View. Then, when you chose to edit the main View Group (or "Parent View" or whatever) it would change those settings for all Child Views, except those that override the changed fields.

[ Obviously I'm not settled on the terminology yet, but we're getting there. ]

The upshot to all this is that maintainability of the Views is FAR better. I quite agree.

Impressions?

My worry is the UI. My worry is ALWAYS the UI... We have to keep everything as user-friendly as it possibly can be. I think the existing form Views page that lists all the Views for the form would need to be expanded a little for this information:
- a new "Type" column with values "parent" / "child'
- a search row added at the top of the tab that would let you only display Parent Views, or a specific Parent View and all of its children. This would be necessary to let the administrator keep track of what Views will be affected when they change the Parent View values.

Also, I think I'd only allow a single level of inheritance. So a Child View couldn't have Child-Views of its own. I think it'll be powerful enough without having to add that extra level of complexity.

------------

Okay, now to return to #1: "(1) the speed of initial View creation and assignment to client accounts". This is another bottleneck.

Right now, when the administrator creates a new account, if the account needs to view a specific subset of the data, the administrator needs to create a custom View and assign them to it. This is slow. But some scenarios seem like they could be done automatically.

For example, imagine the form contains a "company" dropdown field. When the administrator creates the new client account, there is the option to add a company name. What's really needed is to allow the administrator to define a single View with a placeholder in the View Filters section, like:

Code:

show submission iff [company field] == [current logged in user -> company name]

(where "current logged in user -> company name" is the placeholder).

Then, the admin would only need a single View with "public" permissions. As the clients are added, they'll automatically only see those form submissions with the appropriate values in the "company" field.

To generalize this idea, the Filters mechanism needs to allow for comparison with any client account field data - including new fields specified by the Extended Client Fields module.

My intuition is that seems like this particular issue (#1) needs to be approached separately from issue #2 discussion above - which is solved by your View Groups idea.

Anyway, sorry - kind of blathered on a bit. Your post really helps hammering out the details - we're definitely approaching a solution. Any comments will be VERY welcome! (from anyone!)

- Ben

[stevenheidel]

You realize that your second solution solves the first as well? Somewhat?

My 10 views in the for my 10 clients could be reduced to one dynamic view. (That's what I'm going to call it) This would eliminate the need for a view group in that situation.

As for my second group of 10, the 10 subsets I show on my website, this could also be reduced to one view. If you could pass variables through the api on show submissions then I would only need one view there as well!

Ex. under the $options paramater allow like
[region_field] => "Canada", OR [submission_date] < 2009-01-01

That would reduce my 21 views into 3.

[Ben]

You realize that your second solution solves the first as well? Somewhat?

Absolutely! But not fully. I'll keep thinking this over.

- Ben