HTML5 Development Environment Setup

    This document covers the setup of a development environment for the BigBlueButton HTML5 client.

    If you have not already done so, read through the Overview of HTML5 Client

    Initial setup

    Before you begin, you need install the HTML5 client on a BigBlueButton 2.0 (or later) server.

    Have a GitHub Account

    You need a GitHub account. Also, you need to be very familiar with how git works. Specifically, you need to know how to

    • clone a repository
    • create a branch
    • push changes back to a repository

    If you have not used git before, or if the terms clone, branch, and commit are unfamiliar to you, stop now. These are fundamental concepts to git that you need to become competent with before trying to develop on BigBlueButton. To become competent, a good place to start is this free book and GitHub Help pages.

    Using GitHub makes it easy for you to work on your own copy of the BigBlueButton source, store your updates to the source to your GitHub account, and make it easy for you to contribute to BigBlueButton.

    Subscribe to bigbluebutton-dev

    We recommend you subscribe to the bigbluebutton-dev mailing list to follow updates to the development of BigBlueButton and to collaborate with other developers.

    Checking out the Source

    The steps below assume you have cloned the BigBlueButton repository in the following directory (your home directory will likey be different than firstuser).


    Using your GitHub account, do the following

    1. Fork the BigBlueButton repository into your GitHub account.
    2. Clone your repository into your ~/dev folder.

    Note that you need just the master branch.

    $ git clone<YOUR_GITHUB_USERNAME>/bigbluebutton.git

    After cloning, you’ll have the following directory (make sure the bigbluebutton directory is within your dev directory).


    Confirm that you are working on the master branch.

    $ cd /home/firstuser/dev/bigbluebutton
    $ git status

    You should see

    # On branch master
    nothing to commit (working directory clean)

    Next, track changes to the upstream repository

    git pull v2.0.x-release

    Setup of the development environment

    First, shut down the packaged version of the HTML5 client so you are not running two copies in parallel.

    $ sudo service bbb-html5 stop

    Nginx configuration:

    If you do not have /etc/bigbluebutton/nginx/bbb-html5.nginx, please create it and make sure it contains the following:

    location /html5client {
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "Upgrade";
    location /_timesync {

    Save the file. Reload:

    $ sudo /etc/init.d/nginx reload

    Test the nginx configuration

    $ sudo nginx -t

    If the output from the above command contains errors check again the nginx configuration you just edited.


    You will need to download some files throughout these instructions using curl. If it is not installed on your server, you can install the package using the following command

    $ sudo apt-get install curl


    You need to install the 6.x version of nodejs:

    curl -sL | sudo -E bash -
    sudo apt-get install -y nodejs


    You will need to install Meteor.js.

    $ curl | sh


    You want to modify so that SVG images for the HTML5 client’s presentation are generated by default.

    $ sudo vi /var/lib/tomcat7/webapps/bigbluebutton/WEB-INF/classes/

    Set the field svgImagesRequired to true. Then restart tomcat7.

    $ sudo service tomcat7 restart


    Assuming that you cloned the repository in /home/firstuser/dev, navigate to

    $ cd /home/firstuser/dev/bigbluebutton/bigbluebutton-html5/

    Install the npm dependencies

    meteor npm install

    In order to run the server side of the HTML5 client you will need to execute the following:

    $ npm start

    By default, the client will run in development mode. Loading into production environment can be done by passing the value of NODE_ENV:

    $ NODE_ENV=production npm start

    Wait until the process starts and confirm that the configuration is valid by navigating to


    The result should be {"html5clientStatus":"running"}.


    Make sure you have the demos package installed: sudo apt install bbb-demos Go to http://<your_ip>/ in the browser. Select “API examples”. Navigate to “HTML5 Client Demo” and use the form. You will enter a meeting titled “Demo Meeting”.

    On a device that does not support Flash (for examaple Android devices) you can simply attempt to join a meeting from http://<your_ip>/. Since your device’s browser lacks Flash by default, you will be offered to navigate to the HTML5 client instead.

    Serve the client over HTTPS

    Make sure you follow the instructions for configuring https on BigBlueButton. Test your server using the Flash client. Make sure the audio works and the slides display properly. The HTML5 client does not require any additional configuration to run over https. If the rest of BigBlueButton is running fine as https, you are set!

    Localization with Transifex

    We use Transifex for crowdsourcing for BigBlueButton Internationalization(i18n). The following steps are not a part of the typical installation and are only required for bringing the language strings in github up to date. There are two ways to pull the translation files; using the script or the transifex client.


    The script aims to make retrieving translation files on the Transifex servers as simple as possible. In order to use the script, you must provide your Transifex credentials which have the appropriate authorization. The script can be used in the following ways.

    $ ./ all

    Using the all argument will tell the script to download all available translation files.

    $ ./ fr de pt-BR

    If you only need a specific set of translations, the script can be run with the required locales as argument.

    Setup & Configure Transifex Client

    This is an alternative method to using the and is essentially the manual process for retrieving translation files from the Transifex servers.

    1. Install Transifex Client

    To installation the Transifex client we use pip, a package management system designed to manage and install Python packages.

    $ sudo apt-get install python-pip

    Next we use Pip to install the Transifex client.

    $ sudo pip install transifex-client

    The following command is used to upgrade the client to the most current version.

    $ pip install --upgrade transifex-client

    2. Transifex Project Initialization

    The tx init command is used to initialize a project. Run from the root directory of the application.

    $ tx init
    Creating .tx folder. . .
    Transifex instance []:

    Press Enter (will be prompted for your Transifex username and password)

    Creating skeleton...
    Creating config file...

    This will create a Transifex project file in the current directory containing the project’s configuration file.

    3. Transifex Client configuration


    The Transifex client uses a per project configuration file. This is located in .tx/config of your project’s root directory and is generated on running the tx init command. It should be updated with the following configuration:

    host =
    file_filter = private/locales/<lang>.json
    source_file = private/locales/en_US.json
    source_lang = en_US

    4. Set a Project Remote

    tx set allows you to configure and edit Transifex project files on your local computer.

    The following command is used to initialize a local project for the remote project specified by the URL.

    $ tx set --auto-remote

    Next we can pull language files located on the Transifex server.

    5. Pull: Download Transifex Translations

    To pull all translation files from the Transifex server, the following command is used.

    $ tx pull -a bigbluebutton-html5.enjson

    In the event that there are a lot of translations, instead of pulling all, we can specify which translations we want to acquire.

    $ tx pull -r bigbluebutton-html5.enjson -l pt_BR

    Alternatively, simply download a ZIP archive of all languages in the project from the Transifex project page and unarchive it in the private/locales/ directory.



    In order to accommodate all of the users who may have one or a combination of impairments, we refer to the Web Content Accessibility Guidelines (WCAG) 2.0. This document outlines the standards expected to be included, where applicable, with all HTML markup on the web.

    When dealing with web accessibility there are a few key factors we must keep in mind while developing

    1. Tab Order
    2. Color Contrast
    3. Focus
    4. Semantics
    5. Testing

    Tab Order

    The goal when implementing the tab order is ensuring the elements in the tab sequence are logical and simple.

    When a user presses the tab key focus should move to the next interactable element. If the user continues to press the tab key, focus should move in a logical order through all the interactable elements on the page. The tab focus should be visually identified, currently the HTML5 client adds a thin border to the field, when tab is pressed focus is seen to visibly move.

    Note: A number of users including the following.

    • Those with visual impairments, who rely on screen readers or screen magnifiers.
    • Those with limited dexterity, who depend on the use of the keyboard to using a mouse.
    • Those who can only utilize a single switch to control a computer.

    will all navigate through a page by using the tab button.

    The order of elements in the DOM determine their place in the tab order, for elements that should receive focus. Elements that don’t natively receive focus can be inserted into the tab order by adding a tabindex=”0” property.

    Caution: When using the tabindex property, positive values should generally be avoided because it places elements outside of the natural tab order, this can present issues for screen reader users who rely on navigating the DOM through a linear manner.

    The following extension gives a visual representation of the tab order of a current web document.


    offered by ngzhian

    Contrast Ratio Calculator


    Color Contrast

    When dealing with color contrast we are talking about finding colors for a scheme that not only implement maximum contrast, but gives the appropriate contrast between the content and its background for those who experience low visual impairments, color deficiencies or the loss of contrast typically accompanied by aging.

    The HTML5 client ensures that all visual designs meet the minimum color-contrast ratio for both normal as well as large text on a background, described by the WCAG 2.0 AA standards. “Contrast (Minimum): Understanding Success Criterion 1.4.3.”

    To make sure that we have met these guidelines, there are numerous tools available online which allow the comparison of foreground and background colors using hex values, to see if they fall within the appropriate contrast ratio.

    Contrast Ratio Calculator

    Currently implemented colors:

    Currently implemented element colors Currently implemented typography colors

    • Blue - primary color - action buttons
    • Red - closing audio, indicators and error alerts
    • Green - audio indicator, success alert, check marks
    • Orange - warning alerts
    • Dark Blue - Headings
    • Grey - base typography color

    Note: The ChromeLense extension also provides the ability to view your browser using different personas of users who may view web content with various different visual impairments. This is particularly useful when deciding on appropriate color schemes to best suit a wider range of users.


    Users with visual disabilities can miss out on visual affordances. We need to make sure the information we are trying to express, is expressed in a way that flexible enough so assistive technology can pick up on it; creating an alternative interface for our users. we refer to this as expressing the semantics of an element.

    The HTML5 client uses the WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) to provide access to screen readers. The following list of commonly used aria attributes:

    • aria-role
    • aria-label
    • aria-labelledby
    • aria-describedby
    • aria-hidden
    • aria-live
    • aria-expanded
    • aria-haspopup

    #### Links

    HTML5 ARIA spec -

    ARIA spec -

    Roles -

    States and Properties -

    Design Patterns -


    Testing for accessibility can be a somewhat painful process, if you try to manually find and fix all the issues. While it is good practice to go through a checklist and ensure all elements in the HTML5 client meet their accessibility requirements, this process can be very slow and time consuming. For this reason it is suggested to use an automated accessibility auditor first.


    offered by Deque Systems


    Accessibility Developer Tools

    offered by Google Accessibility

    Accessibility Developer Tools

    Both of these extensions provide the ability to scan the DOM and report on any accessibility issues based on levels which can be set, weather AA or AAA standards. For the purposes of the HTML5 client we follow the AA guidelines. Any reported errors also come with a listing of potential fixes.

    Note: Once these extensions are installed to the browser they must be run from inside the console.


    The following is a free online accessibility course which can provide a very good understanding of the basics of dealing with web accessibility for both developers and designers.–ud891

    In the event you do not need to take the course but would still like access to the information as reference, the course is also found in full document form below. It is a live document which is updated by the developers over at Google.

    Coding Practices

    When making a new component there is a certain structure to implement and existing components to utilize to make your life easier.


    There is a standard button component we use in the client. It is located inside of /imports/ui/shared/Button.jsx. It should be used for every button.

    Font Size

    Inside of /client/stylesheets there is a stylesheet fontSizing.css.

    It will contain style classes such as extraSmallFont, smallFont, mediumFont, etc. Every piece of html with text to display to the client should be assigned one of these classes. This will allow text to scale responsively and still maintain relative size. You can set the class of an element to one of these classes, and have everything inside the container element inherit the font size rather than assign it to each individual child to save some work.


    The HTML5 client supports localizations by useing the React-Intl which allows the HTML5 client to have fully localized messages which are uploaded to Transifex for translating. As a result of this we have added the ability within the HTML5 client to switch the language of the application.

    The main language file is en.json. When there is a new field to localize, we update en.json, and then the new field string becomes available for crowdsourced translation on Transifex

    When declaring formatted messages we use defineMessages and injectIntl in place of FormattedMessage.

    Import { injectIntl } from ‘react-intl’;          //pass’s messages as prop to the component
    import { defineMessages } from 'react-intl';      //import so we can group together all messages inside a component.
    const intlMessages = defineMessages({             //all messages can be defined in intlMessages
      title: {
    	id: 'app.about.title', 	                        //id corresponds to the id in the locale file
    	description: 'About title label in Settings menu', //gives developers additional context about the element/item

    We omit the default message prop because it is the same as the string located in the locale file. By doing this we keep context of what the id’s mean while eliminating duplication. Once the messages are defined we then add the following to use the injectIntl:

    export default injectIntl(ComponentName);

    From this point we can use the messages directly as they are passed down as props.

    const { intl } = this.props;     //defined messages get passed as props
        label={intl.formatMessage(intlMessages.title)}   	  //gets rendered to the screen
        aria-label={intl.formatMessage(intlMessages.title)}    //voiced by screen reader

    If the browser is requesting a locale file that does not contain all the translations, all the available strings will be merged with the locale file set as the default. In this case all messages will be displayed but may have a mixture of languages.

    If message id’s are missing from the locale file set as the default, and the browser requests the default or another locale containing a portion of the translated strings; there is potential for the missing id’s to not render a message and in this care default to the id of the message. To ensure this does not occur we make sure that the locale specified as the default always contains 100% of the used messages.

    Server Calls

    To make a call to the server from the client, you should refer to the callServer function in /imports/ui/services/api/index.js.

    Always use this in favor of The callServer function should operate the same way in that you pass the name of the method to call as a string, and then the arguments just like normal.

    Project Structure

    This section covers the structure for the HTML5 project

    Meteor Structure

          index.js                      # import client startup through a single index entity
          routes.js                     # set up all routes in the app
          useraccounts-configuration.js # configure login templates
          fixtures.js                   # fill the DB with example data on startup
          index.js                      # import server startup through a single index entity
        lists/                          # a unit of domain logic
            publications.js             # all list-related publications
            publications.test.js        # tests for the lists publications
          lists.js                      # definition of the Lists collection
          lists.tests.js                # tests for the behavior of that collection
          methods.js                    # methods related to lists
          methods.tests.js              # tests for those methods
        components/                     # all reusable components in the application
                                        # can be split by domain if there are many
        layouts/                        # wrapper components for behavior and visuals
        pages/                          # entry points for rendering used by the router
      main.js                           # client entry point, import all client code
      main.js                           # server entry point, import all server code

    Taken from Meteor Structure

    Inside imports is where we store all units of functionality for the HTML5 client.

    Inside API is where we store the collection data that we use, sort of like a model.

    Inside UI is where we store what would be the view for the models.


    Located under /imports/api

    Each sub-directory here will either be a data collection, or some service we use in the client.

    The name of the subdirectory should be in lower-case representing the name of the Mongo collection, or following typical programming collection it will be PascalCased representing a class name.

    Differing from the Meteor Structure is that for security purposes we want the majority of our functionality in the /server directory, which keeps it from loading on the clients.

    The main export or class for the API component should be in index.js, which allows for easy importing. So to import the Polling collection for example, we can use the following code import Polls from 'imports/api/polls/'.

    Since it is index.js we don’t have to specify that file since it is default.

    Naming files this way can conflict with certain conventions where the file name is named after the main class inside it. To go about this we simply have a default export for the collections, and in the case of a collection we export the new instance.

    Inside the /server directory of every API component we have a named file named publications.js. This is where we put the Meteor publish callback for the collection.

    We now have 2 more sub-directories inside the /server directory– methods and modifiers.


    Inside /methods we have one file per method. These methods are where we declare the Meteor.Methods for the collection– which are Meteor server methods that can be invoked from the Meteor client. We have one file per method, and they are named in camelCase. They shouldn’t need an export because of how they are registered in Meteor. They will however have to be imported on the server (at startup) to execute the code.


    Inside /modifiers we have one file per method. These functions that go in here include the functions that modify the collection/data/class, from the server side. We have one file per method, and they are named in camelCase. There should be one export per file. And these will be imported wherever needed. These are almost all functions that will be called from Redis message listeners.


    Inside imports/api/<collection>/server/ we have a file called eventHandlers.js. This file will contain all the event handlers for the collection.


    Inside /ui we will have sub-directories for

    • components

    • services

    • stylesheets


    will have /api/index.js. Which is where we will store client-side-wide services and helpers. The functions and data in here will all be exported on the last line of the file in one export statement. This allows someone to just look at the last line of the file and easily see what the file exports.


    Inside this directory each sub-directory will represent a React Component. The name of the sub-directory is what the name of the component is. They are all lowercase, with dashes (-) between words. The standard file are

    • component.jsx

    • container.jsx

    • service.js

    • styles.scss


    -> /whiteboard

       -> component.jsx

       -> service.js

       -> container.js

       -> /slide/component.jsx

       -> /cursor/component.jsx

       -> /shape-factory/component.jsx

       -> /shapes

           -> /ellipse/component.jsx

           -> /triangle/component.jsx

           -> … <the rest of the shape components>


    All components will be React ES6 style classes (not React Classes). A component should only need to have one export and it should be the default export. Refer to the official React documentation on how to structure a component class. The component file will be named component.jsx.



    A container is a React ES6 class that will pass data to the component. The container will also be in control of whether or not the component should render. A container should retrieve data from the service and pass it into the container class.

    The container file will be named container.jsx. The file should have only one export and should be the default export. The export should be the result of the createContainer() function.


    The service file should be named service.js.

    The file can export as many function, objects, or other pieces of data as it needs. The service can interface with other collections as well. There should only be one export statement in the file. The last line of the file should export all the functions and pieces of data in an object. Restrain from wrapping everything inside a function and exporting the function wrapper.


    All styles should be written in SASS when possible.


    All configuration files are located in sub-directories within /private/config. The file configuration method utilizes .yaml notated file types.

    Default configuration files:


    The default configuration can be overloaded and their values changed based on the selected environment. These overloaded configuration files are located in sub-folders with their corresponding environment name.

    Development overload configuration files:


    Production overload configuration files:


    During Meteor.startup() the configuration files are loaded and can be accessed through the Meteor.settings.public object.

    As an example of it’s usage we can do:

    import { Meteor } from 'meteor/meteor';
    const APP_CONFIG =;
    if (APP_CONFIG.httpsConnection){
      baseConnection += ('S');