Renaming "add-ons"

I know we've had this discussion before but I think it is worth revisiting given that we are writing the book.

I don't really like "add-on" as it implies to me something that is bolted on after the fact rather than the many add-ons which are currently delivered and maintained as part of the ocPortal distribution. We may even need a distinction between these two: those developed and maintained by ocPortal and those who rely on third-party maintainers.

I kind of like the name "add-ins" as it implies to me that these are something that can just be stirred into the mix. I really want to stress the importance of these optional additions, probably providing an appendix that lists and describes the various options (we will cover some of these in prior chapters - for instance, the Facebook add-on will be discussed in adding social media).

I know many have weighed in previously but I would really appreciate your thoughts on this matter in the context of what works best for a book that will be a primary source for new ocPortal users.

Bob

… the importance of these optional additions …

​add-on = extension

extension
noun
Definition: enlargement, continuation

The terminology won't be changing in the mid-term.

Chris Graham said

The terminology won't be changing in the mid-term.

Well, that answers that. But I do hope we can find something other than "add-on" to describe those options which are maintained by ocPortal developers. It should sound like they are part of the package rather than something added after the fact.

Bob

BobS said

Chris Graham said

The terminology won't be changing in the mid-term.

Well, that answers that. But I do hope we can find something other than "add-on" to describe those options which are maintained by ocPortal developers. It should sound like they are part of the package rather than something added after the fact.

Bob

I don't see this as a major hurdle, Bob.

In the book, probably at the very beginning (your intro?), a brief explanation can be inserted, perhaps something along these lines …

The term 'add-on' has been retained for consistency when making comparison with other software. However, in ocPortal this term is used to describe core features of ocPortal that can be switched 'on' and 'off' depending on the user's requirements, and not something additional that you need to hunt for elsewhere.

… or something similar!

 

BobS said

Chris Graham said

The terminology won't be changing in the mid-term.

Well, that answers that. But I do hope we can find something other than "add-on" to describe those options which are maintained by ocPortal developers. It should sound like they are part of the package rather than something added after the fact.

Bob

Enhancements?

I think I will  follow Fletch's recommendation and just address it briefly in the introduction. I just want to make sure that we cover the fact that ocPortal comes with all this functionality built-in rather than tacked on.

Bob

BobS said

Chris Graham said

The terminology won't be changing in the mid-term.

Well, that answers that. But I do hope we can find something other than "add-on" to describe those options which are maintained by ocPortal developers. It should sound like they are part of the package rather than something added after the fact.

Nothing particularly wrong with add-on, and ocp ones can be referred to as bundled/included/pre-installed/official/etc add-ons.

temp1024 said

Nothing particularly wrong with add-on, and ocp ones can be referred to as bundled/included/pre-installed/official/etc add-ons.

I just always feel that the term add-on sounds like something is tacked on as an afterthought. I rather like add-ins as it conveys that something is included but just needs to be turned on.

It's probably just me and it's not going to change in the near-term anyways but I do hope we can settle on something other than add-on for those pieces of code maintained by ocProducts.

Bob

Changing ocP's official word for adding extra functionality to the cms just for the sake of the book will just add more confusion to someone new to ocPortal.

If you start arbitrarily changing "official" names in the book because you personally don't think it should be called by that name, the reader will learn it by the unofficial name and when he visits these forums or is searching this site for addons and uses the term he learned in the book it will cause additional problems for everyone involved. Do we need more confusion?

Personally, I like the word "enhancements" instead of addons because it states exactly what is being done; you are enhancing the capabilities of the base structure of the install. Do I think it should be used in the book as a replacement/substitution for "addons"? No, because it could create confusion.

sholzy said

Changing ocP's official word for adding extra functionality to the cms just for the sake of the book will just add more confusion to someone new to ocPortal.

If you start arbitrarily changing "official" names in the book because you personally don't think it should be called by that name, the reader will learn it by the unofficial name and when he visits these forums or is searching this site for addons and uses the term he learned in the book it will cause additional problems for everyone involved. Do we need more confusion?

Personally, I like the word "enhancements" instead of addons because it states exactly what is being done; you are enhancing the capabilities of the base structure of the install. Do I think it should be used in the book as a replacement/substitution for "addons"? No, because it could create confusion.

I wasn't suggesting changing the name solely in the book but rather that the word be changed for  ocPortal. Chris had brought this subject up previously and the response was that most people were happy with add-ons and, so, it was not changed then (or scheduled for change). I just thought if a name change were to occur, it would be good to do it in conjunction with the book.

Bob

BobS said

I just thought if a name change were to occur, it would be good to do it in conjunction with the book.

Bob, to reiterate something you've already agreed would make sense, simply refer to the fact that 'add-ons' in ocPortal mostly come with the standard package, in your intro, and that where 3rd-party add-ons are offered, that they are scrutinised carefully by the staff, before inclusion in the add-ons section, for their stability and security.

One important name change to make a note of NOW is that CEDI has already been changed to Wiki+, but I still see reference to CEDI, even in these discussions!

 

Fletch said

BobS said

I just thought if a name change were to occur, it would be good to do it in conjunction with the book.

Bob, to reiterate something you've already agreed would make sense, simply refer to the fact that 'add-ons' in ocPortal mostly come with the standard package, in your intro, and that where 3rd-party add-ons are offered, that they are scrutinised carefully by the staff, before inclusion in the add-ons section, for their stability and security.

One important name change to make a note of NOW is that CEDI has already been changed to Wiki+, but I still see reference to CEDI, even in these discussions!

 

Fletch-

That is going to be the approach I use. I just wanted to respond to sholzy regarding that I understood the need to change more than just the book terminology. Since it's not going to change in the code in the near term, it is a moot point.

I've changed CEDI to Wiki+ in the book outline - View topic: Book structure/chapters - ocPortal.com

Bob

BobS said

I've changed CEDI to Wiki+ in the book outline …

 

I would suggest against referring to add-ons as built in options of ocPortal that can be turned on or off because A That is not entirely true. They are often installed from your admin zone but not actually in there to begin with. B You may end up giving it a bad reflection cause some will read that to mean there is a lot of Bloat in the software.

The Tterm Add-ons should stay as is and it should be discussed as INSTALLING add-ons.

As I understand it, all bundled add-ons are part of the distribution; you should only need to download unbundled add-ons. Chris has been or will be changing the status of some add-ons to unbundled but I don't think this is a significant issue one way or the other regarding "bloat".

My whole point is that ocPortal should be presented as a complete package with add-ons maintained by ocProduct that are consistent with and current to the current ocPortal distribution. This is a far cry from some other CMS packages where upgrading your core might not be possible because some add-on you rely on is not up-to-date. I see this as a major strength and don't think we should shy away from it. Unless Chris changes the way add-ons are packaged, it is what it is and I don't think we should fear turing a strength of ocPortal into a weakness.

Also, please note that my sole intention is to offer a list of all current add-ons with a brief description so that people can see the flexibility and power of ocPortal.

Bob

It was my understanding that Add-ons (like the Facebook one you mentioned) are not part of the core of the CMS but must be installed. I think some of the CORE FEATURES might also be installed (or rather turned on and off) via the Add-ons interface but they can (and probably should) be discussed as core features that have the ability to be turned on and off.

Not really keeping up with this topic, but I'd note the following non-bundled addons may be relevant to cover:

Generally very useful, but not bundled due to association/dependency on third party services:

• facebook_support (Facebook logins, admin Facebook syndication, Facebook blocks)
• twitter_support (Admin Twitter syndication)
• oc_data_map (Google maps for catalogues)
• oc_user_map (Google maps for members)

Generally useful, but not bundled for licensing reasons and/or to avoid bloat and/or very large external libraries not matching our coding standards (e.g. different PHP versioning requirements):

• getid3 (Upload more video formats with auto-detection of video length/width/height)
• admin_search_stemmer (Slightly better Admin Zone search)
• plupload (HTML5 uploader with progress bar, rather than the bundled choice between Flash or no-progress-bar)

(There are other popular ones, but mostly those are ones that one day will become bundled, and aren't now because they're not polished enough / not meeting our full set of standards)

In version 8, the Facebook add-on is delivered as a bundled add-on. I'm not sure about version 9.

Regarding the fact that some core features are really just being enabled instead of installed is further argues the point I am making about making a distinction between add-ins/enhancement/whatever-you-want-to-call-them and "add-ons" which is something that is added independently.

Bob

In version 8, the Facebook add-on is delivered as a bundled add-on.

No, it isn't . In v7 it was, but v8 pulled it out and merged it with the old non-bundled Facebook addon, to make a new complete non-bundled Facebook addon.