Remove Dynamic Default Views

I understand the motives (the main one is: we're stuck), and I'm for this change, but I think we should first ask some of our users what they think about this. (No, I don't say we should heed their advice ;-) but it could be insightful to hear their opinion.)

(Note that your patch doesn't update the documentation on the overview page ("Once a flag is defined, a new menu item will appear ..."). Without correct documentation, our users will suffer (And we as well, having to answer questions here).)

If users want to create a similar view, they can duplicate the default

Only for nodes. Not for users/comments.

(I'll comment shortly.)

(BTW, and I guess you already know this, it seems your D6's 'flag.install' is a bit out-of-date. Your patch cancels out the 'not null' => FALSE fix, among others.)

OK, I'm for this plan. I already stated so.

The text on the admin page needs updating. It's currently:

Once a flag is defined, a new menu item will appear leading to a page showing
for each user the items she has flagged by it. In case of /global/ flags, the items
flagged are shared by all users. These lists of flagged items are /views/, and
/are customizable/.

It could be changed to something along of:

Lists of flagged content can be generated by /views/. A /handful of views/[1] for
the /bookmarks/ flag are provided out-of-the-box.

But no views are provided out-of-the-box for your other flags. To easily create
such views, visit the /views/ page and "Duplicate" the existing /bookmarks/ ones.
Then proceed to /customize/ these views.

(I'm not an English speaker, this is only an example.)

[1] Here we should link to View's admin page and automatically filter by a "flag" tag. Views didn't have such a feature in my days but it should be trivial to add this.

Now, I understand you're spartan as to the UI documentation. I feel that clear UI documentation is very important to have. It'd be a usability regression to omit it.

Having said all this, I wish we could get our hands on some common user and ask him/her how he would cope with this new development. Have you considered this?

(I haven't minutely examined the views themselves, as I don't have access to Drupal.)

If users want to create a similar view, they can duplicate the default

Only for nodes. Not for users/comments.

Mmmm. This needs figuring out.

The text on the admin page needs updating. It's currently:
[...]
It could be changed to something along of:
[...]
Lists of flagged content can be generated by /views/. [...]

Maybe there's no choice but to use Advanced Help. Hey, I see there's a version for D5 too.

Picture 2.png

Ah, this help looks very good! (I was busy composing a comment suggesting to try out Advanced Help, but I think your version is alright.)

I'm thinking we only show the line about cloning the existing views if the bookmarks flag is still available (since it won't show up otherwise).

(Well, it isn't the user's "fault" that he deleted 'bookmarks' and thus became uneligible for the instructions... OTOH, I see the problem of speaking about 'bookmarks' when it isn't there.)

And I still think it's important to ask some "common user" about all this. Till now only you and I have discussed this. We don't yet know how users are going to feel about this.

(I sent a private invitation to two people asking them to chime in.)

I definitely like the idea of cutting out the dynamic views. It really clutters my views listing page, especially since the default views (in any module really) hardly ever cover all of my needs and I end up creating my own. However, I always assumed that the purpose of providing any sort of default view with any module was to outline, by example, how to utilize that particular module's views integration.

So I would actually rather see one view, per content type (a view that lists user flags, one for node flags, and one for comment flags) and have these disabled by default. That way, anyone using Flag can create their own views, but still have some working samples in order to have a guideline for creating their own, or they can just enable the default flag views.

Sirkitree wrote:

I always assumed that the purpose of providing any sort of default view with any module was to outline, by example, how to utilize that particular module's views integration.

So I would actually rather see one view, per content type (a view that lists user flags, one for node flags, and one for comment flags)

Default views for nodes:

Done. We provide default views for the 'bookmarks' flag. The user can "Duplicate" these.

Default views for users and comments:

It seems that providing default views for these two would return us back to square one. This issue (#333984) talks about not providing default views, and this as the ultimate solution to a bunch of issues related to default views. You're effectively suggesting to ditch this issue (#333984).

On the other hand, perhaps things aren't as bad as they seem:

We could provide a demonstrative "friends" flag, together with defaults views, couldn't we? But this would give our users a false impression they have a complete social networking solution. So perhaps a "users I like" flag is better as it sounds less pretentious.

For comments: it seems we can't provide a useful view for comments anyway (see #327901: Action: clearing a node's flaggings), so this problem is fortunately "sovled" for us.

Let's focus this discussion:

1. Should we provide a "users I like" flag, plus its default views?
2. The big question: Can the average admin tackle our Views integration? In other words, will he she/he be hopeless without default views for users and comments?

Should we provide a "users I like" flag, plus its default views?

I suspect I've been impolite here. My apologies. All the work falls on Nate alone, him being the sole maintainer, so it isn't friendly to say "we".

===

Should we provide a "users I like" flag, plus its default views?

Of course, it's alright to reply "No, we won't". Maybe I was blowing this issue out of proportions. After all, admins have duties too; They are supposed to study Drupal, and to study the modules they use.

I see your point.

My main concern then really happens to just be a matter of documentation. Personally I prefer to learn by example, but as long as it is documented somewhere, then that really takes care of anything I can argue for this.