Official:Rebranding Guidelines: Difference between revisions

From Official Kodi Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
(One intermediate revision by the same user not shown)
Line 21: Line 21:
:* The default skin used by the product.
:* The default skin used by the product.
:* Remove the main splash screen or replace them with suitably rebranded ones.
:* Remove the main splash screen or replace them with suitably rebranded ones.
:* The name of the default update repository (although sync'ing with the XBMC Foundation official repo is acceptable).
:* The name of the default addon installation/update repository (although sync'ing with the XBMC Foundation official repo is acceptable).
:* Logos in Estuary or any other official skin if pre-installed.
:* Logos in Estuary or any other official skin if pre-installed.
:* The new brand should have its own distinct privacy policy.
:* The new brand should have its own distinct privacy policy.
Line 51: Line 51:
:* ios - https://github.com/xbmc/xbmc/tree/master/tools/darwin/packaging/media/ios
:* ios - https://github.com/xbmc/xbmc/tree/master/tools/darwin/packaging/media/ios
:* osx - https://github.com/xbmc/xbmc/tree/master/tools/darwin/packaging/media/osx
:* osx - https://github.com/xbmc/xbmc/tree/master/tools/darwin/packaging/media/osx
== Infrastructure and Back-End ==
It is also recommended that organisations intending to release a rebranded version of any XBMC Foundation product set up their own distribution and support infrastructure as well. This includes but is not limited to distribution servers for the package itself, support forums or other user communities, servers to host addons and repos linked to or required by the new product, and distributed mirroring to spread the network load related to downloads or other connections to the infrastructure.
There are a number of reasons behind this:
:* Having a dedicated infrastructure under your own control removes any risk of uncontrolled service interruption due to upstream issues (e.g. maintenance, network interruptions or even being targeted by malicious cyber-attacks).
:* Having a support site for user assistance and interaction will help to boost brand image and reputation and engender a positive community spirit.
:* Using distribution mirrors spreads the network load and minimises the risks from server availability or network connectivity issues.
:* The hosting of a dedicated addon repository will almost always be required anyway, which must be hosted somewhere.
::* This repository must be clearly named to ensure there is no confusion between it and the official XBMC Foundation repo, and that it is not hosted, controlled, overseen or guaranteed by the XBMC Foundation.
::* Syncing with the official XBMC Foundation is permitted and encouraged. If required the XBMC Foundation is willing to offer assistance to set this up.

Revision as of 10:18, 29 January 2020

Home icon grey.png   ▶ XBMC Foundation ▶ Trademarks ▶ Rebranding Guidelines


Referenced Pages and Further Reading


Guidelines

The rule of thumb for rebranding is to remove any XBMC Foundation trademark, wordmark or logo that is user-facing and visible during normal operations of the product.


A non-exhaustive list of suggested items are:

  • The default skin used by the product.
  • Remove the main splash screen or replace them with suitably rebranded ones.
  • The name of the default addon installation/update repository (although sync'ing with the XBMC Foundation official repo is acceptable).
  • Logos in Estuary or any other official skin if pre-installed.
  • The new brand should have its own distinct privacy policy.
  • Logos and marks (including favicons) for any pre-installed web interface(s).
  • The default system names used for identification to networked services such as AirPlay and Bonjour.


For a full rebrand to allow the new product to run side by side with and entirely independently of the XBMC Foundation product, the data in the version.txt file should also be modified to reflect the new product identity. There are some notes on this however:

  • Modifying the APP_NAME will also change the folder in which the product stores its user data and installed addons and repos.
  • This may require forking and modification of the binary addon set as well to ensure correct operation.
  • Situations where the new product would concurrently share the same user data files and storage area on the same device as the XBMC Foundation product must be avoided to prevent risks of errors and data corruption for both products.


All translations should also be included in these changes.


Building Rebranded Versions

To assist in the building of the rebranded versions, any 3rd party artwork placed into the special://xbmc/media/ folder will be used in place of the default XBMC Foundation logos.


Similarly the graphics in the following folders should be updated with vendor artwork, depending on which platform(s) are being built:


Infrastructure and Back-End

It is also recommended that organisations intending to release a rebranded version of any XBMC Foundation product set up their own distribution and support infrastructure as well. This includes but is not limited to distribution servers for the package itself, support forums or other user communities, servers to host addons and repos linked to or required by the new product, and distributed mirroring to spread the network load related to downloads or other connections to the infrastructure.

There are a number of reasons behind this:

  • Having a dedicated infrastructure under your own control removes any risk of uncontrolled service interruption due to upstream issues (e.g. maintenance, network interruptions or even being targeted by malicious cyber-attacks).
  • Having a support site for user assistance and interaction will help to boost brand image and reputation and engender a positive community spirit.
  • Using distribution mirrors spreads the network load and minimises the risks from server availability or network connectivity issues.
  • The hosting of a dedicated addon repository will almost always be required anyway, which must be hosted somewhere.
  • This repository must be clearly named to ensure there is no confusion between it and the official XBMC Foundation repo, and that it is not hosted, controlled, overseen or guaranteed by the XBMC Foundation.
  • Syncing with the official XBMC Foundation is permitted and encouraged. If required the XBMC Foundation is willing to offer assistance to set this up.