[xwiki-devs] terminology rumble: Applications vs. Extensions vs. Plugins
Hey, Yesterday, Vincent introduced a "Modules" section on code.xwiki.org to host XWiki components documentation. From that we had a conversation on IRC about terminology of categories on code.xwiki.org. My observation was that we have some applications that are not really such since they do not offer features to users, but only to developers. Take the date picker application (http://code.xwiki.org/xwiki/bin/view/Applications/DatePickerApplication) : it is not self-standing, this is just for developers that needs a date picker in their apps. I proposed we add an "Extensions" category that would host Skin eXtensions (JSX and SSX) and applications such as the datepicker would fit in there. But as Vincent remarked, we already have an extension category for "an application or script that integrates or interacts with XWiki". In the end, I'll come here with Vincent's idea of merging such extensions with plugins, and then have the following categories : * Plugins: A plugin is everything that brings new functionality to the wiki, but that does not necessarily expose it to end users. There will be two main kinds of plugins: Front-end plugins (that will mostly come under the form of SX), as the date picker will be for example, and Back-end plugins, which can be of various form, such as an old fashioned xwiki plugin (grand'ma style), or a xwiki component with a velocity bridge, etc. To sum up, plugins bring *functionalities to developers*. * Applications: An application will stay what it is today : something an administrator can install on its wiki and that provides functionality to end-users, directly visible/exploitable without the need of more programming. This mean a SX that do such is an application, for instance this is how the Ratings application (http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-application-ratings/) is made. To sum up, applications bring *functionalities to the end users*. Conclusions: Skin eXtensions will remain only a technical term to designate what they are as platform feature. This is for us, the knowledgeable gurus ; on code.xwiki.org we will offer only plugins and applications. As for icons to represent those two ideas (both on code.xwiki.org and in the future in XE) - since this is what matters in the end, icons :) - I propose we use application.gif for Applications and plugin.gif for Plugins from the silk set. Pretty straightforward, eh ;) WDYT ? Jerome.
Jerome Velociter wrote:
Hey,
Yesterday, Vincent introduced a "Modules" section on code.xwiki.org to host XWiki components documentation. From that we had a conversation on IRC about terminology of categories on code.xwiki.org. My observation was that we have some applications that are not really such since they do not offer features to users, but only to developers. Take the date picker application (http://code.xwiki.org/xwiki/bin/view/Applications/DatePickerApplication) : it is not self-standing, this is just for developers that needs a date picker in their apps. I proposed we add an "Extensions" category that would host Skin eXtensions (JSX and SSX) and applications such as the datepicker would fit in there. But as Vincent remarked, we already have an extension category for "an application or script that integrates or interacts with XWiki". In the end, I'll come here with Vincent's idea of merging such extensions with plugins, and then have the following categories :
* Plugins: A plugin is everything that brings new functionality to the wiki, but that does not necessarily expose it to end users. There will be two main kinds of plugins: Front-end plugins (that will mostly come under the form of SX), as the date picker will be for example, and Back-end plugins, which can be of various form, such as an old fashioned xwiki plugin (grand'ma style), or a xwiki component with a velocity bridge, etc. To sum up, plugins bring *functionalities to developers*.
* Applications: An application will stay what it is today : something an administrator can install on its wiki and that provides functionality to end-users, directly visible/exploitable without the need of more programming. This mean a SX that do such is an application, for instance this is how the Ratings application (http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-application-ratings/) is made. To sum up, applications bring *functionalities to the end users*.
Conclusions: Skin eXtensions will remain only a technical term to designate what they are as platform feature. This is for us, the knowledgeable gurus ; on code.xwiki.org we will offer only plugins and applications.
As for icons to represent those two ideas (both on code.xwiki.org and in the future in XE) - since this is what matters in the end, icons :) - I propose we use application.gif for Applications and plugin.gif for Plugins from the silk set. Pretty straightforward, eh ;)
WDYT ?
From a user perspective, having less names and categories is good. However, given that so many different types of things will go under "plugins", it will be more confusing IMO. There's a huge difference between a calendar sx and a kerberos auth class, or the SVG plugin, or the localization component. Another name I've been suggesting for a while for interface extensions that add new components is, well, "UI components". And another thing I just noticed: we provide GIFs?! GIFs are evil. GIFs are deprecated. GIFs are very limited. It's true that the Burn All Gifs campaign was started a very long time ago, but it is still valid. http://burnallgifs.org/archives/ -- Sergiu Dumitriu http://purl.org/net/sergiu/
Regarding GIFs (a bit off topic). The main advantage GIFs provide is animation. (transparency is already done by regular PNG). Check out APNG (Animated PNG). Some samples are at http://animatedpng.com/index.php/category/samples/ I tested some APNGs from the samples (.png extensions) and they run well on Linux and Vista, so it seems to have good support. This could be a nice alternative to the evil GIFs. Sergiu Dumitriu wrote:
Jerome Velociter wrote:
Hey,
Yesterday, Vincent introduced a "Modules" section on code.xwiki.org to host XWiki components documentation. From that we had a conversation on IRC about terminology of categories on code.xwiki.org. My observation was that we have some applications that are not really such since they do not offer features to users, but only to developers. Take the date picker application (http://code.xwiki.org/xwiki/bin/view/Applications/DatePickerApplication) : it is not self-standing, this is just for developers that needs a date picker in their apps. I proposed we add an "Extensions" category that would host Skin eXtensions (JSX and SSX) and applications such as the datepicker would fit in there. But as Vincent remarked, we already have an extension category for "an application or script that integrates or interacts with XWiki". In the end, I'll come here with Vincent's idea of merging such extensions with plugins, and then have the following categories :
* Plugins: A plugin is everything that brings new functionality to the wiki, but that does not necessarily expose it to end users. There will be two main kinds of plugins: Front-end plugins (that will mostly come under the form of SX), as the date picker will be for example, and Back-end plugins, which can be of various form, such as an old fashioned xwiki plugin (grand'ma style), or a xwiki component with a velocity bridge, etc. To sum up, plugins bring *functionalities to developers*.
* Applications: An application will stay what it is today : something an administrator can install on its wiki and that provides functionality to end-users, directly visible/exploitable without the need of more programming. This mean a SX that do such is an application, for instance this is how the Ratings application (http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-application-ratings/) is made. To sum up, applications bring *functionalities to the end users*.
Conclusions: Skin eXtensions will remain only a technical term to designate what they are as platform feature. This is for us, the knowledgeable gurus ; on code.xwiki.org we will offer only plugins and applications.
As for icons to represent those two ideas (both on code.xwiki.org and in the future in XE) - since this is what matters in the end, icons :) - I propose we use application.gif for Applications and plugin.gif for Plugins from the silk set. Pretty straightforward, eh ;)
WDYT ?
From a user perspective, having less names and categories is good. However, given that so many different types of things will go under "plugins", it will be more confusing IMO. There's a huge difference between a calendar sx and a kerberos auth class, or the SVG plugin, or the localization component.
Another name I've been suggesting for a while for interface extensions that add new components is, well, "UI components".
And another thing I just noticed: we provide GIFs?! GIFs are evil. GIFs are deprecated. GIFs are very limited. It's true that the Burn All Gifs campaign was started a very long time ago, but it is still valid. http://burnallgifs.org/archives/
Eduard Moraru wrote:
Regarding GIFs (a bit off topic).
The main advantage GIFs provide is animation. (transparency is already done by regular PNG).
Internet Explorer 6 does not support PNG transparency natively (http://support.microsoft.com/kb/294714). Jerome. PS: reminder: this has been voted on the list couple of months ago : http://tinyurl.com/dee3j6
Check out APNG (Animated PNG). Some samples are at http://animatedpng.com/index.php/category/samples/ I tested some APNGs from the samples (.png extensions) and they run well on Linux and Vista, so it seems to have good support.
This could be a nice alternative to the evil GIFs.
Sergiu Dumitriu wrote:
Jerome Velociter wrote:
Hey,
Yesterday, Vincent introduced a "Modules" section on code.xwiki.org to host XWiki components documentation. From that we had a conversation on IRC about terminology of categories on code.xwiki.org. My observation was that we have some applications that are not really such since they do not offer features to users, but only to developers. Take the date picker application (http://code.xwiki.org/xwiki/bin/view/Applications/DatePickerApplication) : it is not self-standing, this is just for developers that needs a date picker in their apps. I proposed we add an "Extensions" category that would host Skin eXtensions (JSX and SSX) and applications such as the datepicker would fit in there. But as Vincent remarked, we already have an extension category for "an application or script that integrates or interacts with XWiki". In the end, I'll come here with Vincent's idea of merging such extensions with plugins, and then have the following categories :
* Plugins: A plugin is everything that brings new functionality to the wiki, but that does not necessarily expose it to end users. There will be two main kinds of plugins: Front-end plugins (that will mostly come under the form of SX), as the date picker will be for example, and Back-end plugins, which can be of various form, such as an old fashioned xwiki plugin (grand'ma style), or a xwiki component with a velocity bridge, etc. To sum up, plugins bring *functionalities to developers*.
* Applications: An application will stay what it is today : something an administrator can install on its wiki and that provides functionality to end-users, directly visible/exploitable without the need of more programming. This mean a SX that do such is an application, for instance this is how the Ratings application (http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-application-ratings/) is made. To sum up, applications bring *functionalities to the end users*.
Conclusions: Skin eXtensions will remain only a technical term to designate what they are as platform feature. This is for us, the knowledgeable gurus ; on code.xwiki.org we will offer only plugins and applications.
As for icons to represent those two ideas (both on code.xwiki.org and in the future in XE) - since this is what matters in the end, icons :) - I propose we use application.gif for Applications and plugin.gif for Plugins from the silk set. Pretty straightforward, eh ;)
WDYT ?
From a user perspective, having less names and categories is good. However, given that so many different types of things will go under "plugins", it will be more confusing IMO. There's a huge difference between a calendar sx and a kerberos auth class, or the SVG plugin, or the localization component.
Another name I've been suggesting for a while for interface extensions that add new components is, well, "UI components".
And another thing I just noticed: we provide GIFs?! GIFs are evil. GIFs are deprecated. GIFs are very limited. It's true that the Burn All Gifs campaign was started a very long time ago, but it is still valid. http://burnallgifs.org/archives/
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Jerome Velociter wrote:
Eduard Moraru wrote:
Regarding GIFs (a bit off topic).
The main advantage GIFs provide is animation. (transparency is already done by regular PNG).
We don't use animations, so this is not a requirement.
Internet Explorer 6 does not support PNG transparency natively (http://support.microsoft.com/kb/294714).
No, they don't support alpha transparency. Neither do GIFs. Simple true/false transparency is supported.
PS: reminder: this has been voted on the list couple of months ago : http://tinyurl.com/dee3j6
No, the vote was about using the Silk icon set, from a graphical point of view, there was no vote on the format.
Check out APNG (Animated PNG). Some samples are at http://animatedpng.com/index.php/category/samples/ I tested some APNGs from the samples (.png extensions) and they run well on Linux and Vista, so it seems to have good support.
This could be a nice alternative to the evil GIFs.
Sergiu Dumitriu wrote:
Jerome Velociter wrote:
Hey,
Yesterday, Vincent introduced a "Modules" section on code.xwiki.org to host XWiki components documentation. From that we had a conversation on IRC about terminology of categories on code.xwiki.org. My observation was that we have some applications that are not really such since they do not offer features to users, but only to developers. Take the date picker application (http://code.xwiki.org/xwiki/bin/view/Applications/DatePickerApplication) : it is not self-standing, this is just for developers that needs a date picker in their apps. I proposed we add an "Extensions" category that would host Skin eXtensions (JSX and SSX) and applications such as the datepicker would fit in there. But as Vincent remarked, we already have an extension category for "an application or script that integrates or interacts with XWiki". In the end, I'll come here with Vincent's idea of merging such extensions with plugins, and then have the following categories :
* Plugins: A plugin is everything that brings new functionality to the wiki, but that does not necessarily expose it to end users. There will be two main kinds of plugins: Front-end plugins (that will mostly come under the form of SX), as the date picker will be for example, and Back-end plugins, which can be of various form, such as an old fashioned xwiki plugin (grand'ma style), or a xwiki component with a velocity bridge, etc. To sum up, plugins bring *functionalities to developers*.
* Applications: An application will stay what it is today : something an administrator can install on its wiki and that provides functionality to end-users, directly visible/exploitable without the need of more programming. This mean a SX that do such is an application, for instance this is how the Ratings application (http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-application-ratings/) is made. To sum up, applications bring *functionalities to the end users*.
Conclusions: Skin eXtensions will remain only a technical term to designate what they are as platform feature. This is for us, the knowledgeable gurus ; on code.xwiki.org we will offer only plugins and applications.
As for icons to represent those two ideas (both on code.xwiki.org and in the future in XE) - since this is what matters in the end, icons :) - I propose we use application.gif for Applications and plugin.gif for Plugins from the silk set. Pretty straightforward, eh ;)
WDYT ?
From a user perspective, having less names and categories is good. However, given that so many different types of things will go under "plugins", it will be more confusing IMO. There's a huge difference between a calendar sx and a kerberos auth class, or the SVG plugin, or the localization component.
Another name I've been suggesting for a while for interface extensions that add new components is, well, "UI components".
And another thing I just noticed: we provide GIFs?! GIFs are evil. GIFs are deprecated. GIFs are very limited. It's true that the Burn All Gifs campaign was started a very long time ago, but it is still valid. http://burnallgifs.org/archives/
-- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (3)
-
Eduard Moraru -
Jerome Velociter -
Sergiu Dumitriu