Rename "Views Bookmark" module to "Flag"

"Flag" could be confused with the flagging module that enables users to mark bad content. Wouldn't "add to favorites" not be more descriptive?

I very much agree here, views_bookmark is a bad name. The first thing most people think is it is used for bookmarking views. That's clearly not the case :(

It was named views_bookmark originally because it was a proof of concept to demonstrate the power of views (it was the first module to include views integration). The prefix views_ was used to differentiate it from the existing bookmark module.

"Add to favorites" seems too limiting, as favorites may be the most common use case it doesn't describe that any number of bookmarks is allowed. What do you guys think about names like custom_flags or custom_bookmarks?

+1 to "Custom Flags"

Very much agreeing with #2!

Custom flags sounds very 'picturesque' (vivid), at least for a frenchy :) _{Other froggies agreeing?}

I would not like people to think that the module has the kind of feature taxonomy_image has.
That is to say that people may think that with Custom flag they will be able to arbitrary/customly display images of flags somewhere (against contextualy for taxo_image).

Well, I know "image" stands for itself whereas it might just be a language ubiquity for "flags"... Yet this is why Custom bookmarks "looks" more appropriate to me.

Q? Is it just a very "geographically localized" remark? Does "flags" stand well enough to proper English speakers for this feature? Should the language be taken in account at this point?

+1 to "Custom bookmarks"!

+1 to custom flags

- you create any number of custom links to *flag* content.

- flag inappropriate content, flag favorite content...

From the documentation, "A bookmark is really just a flag that is set on a node, to mark it." -- It is said that a bookmark is a flag. :D

PS. I have never tried Views Bookmarks because of its name... I completely skipped it for other modules.

FWIW, I think the current name is as bad as the proposed ones, including custom_flags which looks like the a promo for the banner store down the road from my house. I would vote for no change, but this is not a strongly held belief.

How about custom_attributes?

This provides additional attributes to nodes. Or other suggestion is to call custom_node_attributes to make it clear.

The more descriptive we get the more daunting the module sounds. The most descriptive names would probably be something like arbitrary_node_flags or similar. However, a name like that is sure to cause users to shy away (and it just doesn't have the appeal of a short name).

custom_attributes is a little vague towards it's meaning. Node attributes could be thought of as something similar to what CCK provides.

I'm still most in favor of custom_flags, I think put in the context of Drupal, it's unlikely to be thought of as a product for assembling banners. Flag has become a common term for various actions, such as Craigslist's "miscategorized", "prohibited", "spam/overpost", "best of craigslist". Naturally there's also the most common "Flag as offensive". I think "flag" is a good fit for this module because it has a similar functionality to these sort of actions.

Your arguments finally make sense to me! Why not Flag then?

There's an English problem in the current name of the module --a problem which the name 'flag' may not necessarily solve.

It's easy to explain the problem by having NodeQueue in mind:

There are _two_ entities in our system:

(1) the flag --or 'mark'-- itself; and:
(2) the set --or 'queue'-- to which it belongs.

Currently, we use a single term, 'bookmark', to refer to these two different entities; We use the word 'bookmark' to refer to either the mark or the mark-type (see? I've just invented two new terms, for lack of terms of our own; this too demonstrates the gravity of the problem).

This makes the source-code, and the documentation, confusing.

NodeQueue solved the problem by introducing a clear word for the set: 'queue'. No room for confusion.

Now,

We need decide on the two terms we're going to use. Suppose with choose the name 'flag' for our module. Will we use the single term 'flag' to refer to both of the two entities? We need to examine the titles in our UI and judge whether this will be acceptable.

I should also mention the complexity of renaming a module:

We'll need to provide an upgrade path. But it's actually worse: we'll need to provide _two_ upgrade paths, because our data may come either from the deceased bookmark module, or from the new flag module.

That's not going to be very trivial. And what about Views? We'll have to convert existing views as well.

That's one good reason to stick with the current name.

A possible solution:

(1) Instead of an upgrade path we'll provide an import utility.

(2) We'll not provide a Views upgrade path. That would make things simpler.

(3) Our 'flag' module will be for D6. We won't provide a D5 version of it. And we won't make a D6 version of the 'bookmark' module; we'll let it die.

(1) Instead of an upgrade path we'll provide an import utility.

[...]

(3) Our 'flag' module will be for D6. We won't provide a D5 version of it. And we won't make a D6 version of the 'bookmark' module; we'll let it die.

So sum it up:

In effect, we're going to start a new module. This new module will have an 'import' utility (which won't import views).

The big question: does the term 'flag' solve our English problem? Does it make the UI clear? In other words: would 'flag' justify the headache?

I think the term 'flag' is worse than 'bookmark'. Sure, in programming, 'flag' usually denotes a variable that can take one of two values. But it wouldn't expect this meaning in the context of module names. I'd rather understand that a module with the 'flag' in its name is something that deals with national flags to switch the current language.

lets change the name to custom flagmarks or just flagmarks :P

I think the solution to create a new module for D6 would be the best thing.

I've branded it 'stuff i like' on my site.

The solution outlined in #12 is the way to go forward, IMO.

The current name simply doesn't do this module justice, in terms of what it can do.

While "custom flags" is not perfect, its a hell of a lot better than "views bookmarks", in that it gives you some idea of what the module can do.
No title is perfect, as no two words title could get across the potential of this module.

Many people will simply scan down through a list of module titles, I myself watch the RSS feed of new modules.
In both cases, this module would be better served by "custom flags" than the current title.

It was only when I saw the issue with plans to port to D6, than I realised how important the change is made now, rather than moving forward with the current name.

So Moofie and quicksketch, I encourage you to claim the namespace for the 'new' module, and move forward to D6.

Regards
Alan

"Markable Lists" or something... :P

Is the 6.x version in development? (Don't mind the name, a "Replace all" can be used at the last minute, can not?)

Don't mind the name, a "Replace all" can be used at the last minute,
can not?

Not really. We'll have to provide code that renames things in Views' structures, the db tables and columns, drupal variables. A great bother.

Don't mind the name

Perhaps you're right here.

Perhaps we should just leave the name as is.

Perhaps "views bookmark" isn't that bad.

This renaming issue only served to hinder the development of this module.

My only concern with "bookmark" was of human language: we use the term for both the boolean the user sets on a node and the name of this boolean. So we have a get_bookmark() API function that doesn't actually return a bookmark but a 'bookmark type'. And it makes the wording in the user interface confusing.

But perhaps I was wrong on this "human language" thing. Perhaps with a little shift in philosophy the term can serve both purposes. It can be both a 'singleton' and an 'object'. Yep, I think I'm starting to see the Light now ;-)

I'm voting to keep the name. (The "views" part doesn't really bother me.) I'm with Moshe's #7.

I'm only a little co-maintainer. Nate, what are your thoughts on this?

The "views" part doesn't really bother me.

I have a little idea:

I see that the bookmarks module is not really maintained (it's for Drupal 4.7). Perhaps we could claim that space, after some negotiations. Our module would still be named "views_bookmarks" internally --no change will be made to the source code itself-- but the name of the package, and of the project, will simply be 'bookmarks'.

I see that the bookmarks module is not really maintained (it's for Drupal 4.7). Perhaps we could claim that space, after some negotiations.

That's a brilliant idea. Big +1 from me. The only other issue I can think of is that the Bookmarks2 module is based on Bookmarks and the reference to the original Bookmarks module on that project page would need to updated.

Alright folks! Verdict is in. The new module has claimed the namespace "flag", which will be the project URL, module file name, and function name prefix. However, on Drupal.org, and in places where the module needs a title, it will be referred to as "Custom Flags". Fortunately, we can change this at a later time, but the module namespace "flag" is pretty well set.

The short name "flag" allows us to have short CSS classes ("flag" and "unflag") as well as short URLs (admin/build/flags), and a nice set of API functions (flag_get_counts, flag_get_flags, etc).

http://drupal.org/project/flag

I moved this issue over there where we can continue discussion.

:-)

Good one!

My apologies in advance if these comments are thought to be a damper.

From my previous experiences I certainly understand the difficulty in finding the right word for an item, especially in the English language where the same word can have different meanings depending on the context, and it is quite common during development to have a concept working before the best word to describe it is found.

As a newbie to Drupal, I find the choice of the name "Flag" to be confusing partly because it is such a general word and also because of the existing use of it in the flag_content module. Even the use of the word in that module is not intuitive to ordinary users and when they see content on the web site with the option to "Flag content" it is not clear what that means.

I think this discussion raises more important issues such as how to best manage emerging simplification of modularity as development progresses, the need to integrate with other similar modules, and finding names that end users can identify with.

I noticed that the word "mark" is not used as a project name and wonder if that would be less confusing although it too is a very general word. Nonetheless with work on projects such as Bookmarks, Bookmark2, and Flag_content already underway it is clearly going to require some effort to co-ordinate the efforts.

My two cents,

Izzy

this discussion raises more important issues such as [...] finding names that end users can identify with.
[...]
when they see content on the web site with the option to "Flag content" it is not clear what that means.

End-users aren't going to see the word 'flag', unless the administrator explicitly types it into link labels etc. Administrators have free choice here; they can name their links 'mark', 'bookmark', whatever.

I think the word 'flag' is good enough. We'll never find a 'perfect' name. Kudos for Nate for being decisive here.

Nonetheless with work on projects such as Bookmarks, Bookmark2, and Flag_content already underway it is [...]

I had a quick look into each of these modules. 'flag_content' is a tiny subset of this module. 'bookmarks' and 'bookmark2' are nice, but this module focuses on flagging, not on menus or annotating URLs. You mention 'the need to integrate with other similar modules', but 'similarity' can be found between any module to any other module. This module serves as a relatively small building block --that strives to integrate with other building blocks-- and I think there's a merit in keeping it as such.

also because of the existing use of it in the flag_content module

I'm already familiar with the flag_content module, but it's abilities are way below that of Views Bookmark (er, Flag). Once Flag gains actions support (which it will very soon), Flag will completely super-set content_flag. Regardless, the name has been chosen, and if nothing else, I think we can agree that Flag is better than "Views Bookmark".

Thanks mooffie for the information in your reply. Knowing that "flag_content" is a subset of this module is very helpful and I can see how these are good small building blocks. Now I can fully understand the choice of the name "flag" for the module. You are also right in pointing out that what the end user sees is not dependent on the module name and can be designed to be as intuitive as possible.

Izzy

Closing out old Issue.