What should I do if my browser doesn’t support customElements?

Our platforms rely on customElements. Some versions of browsers do not support this by default (i.e. Firefox v59-62 and others listed here).

You can enable this by going to about:config in your browser’s URL box and enabling the following:

  • Enabled through the dom.webcomponents.enabled preference in about:config.
  • Enabled through the dom.webcomponents.customelements.enabled preference in about:config.

What if my test object is not accessible for testers?

If your website, Android, or iOS app is not accessible from outside, we recommend white-listing the Applause proxy, so that testers can access your test object for the project’s duration.

Please configure your firewall, or security settings, to permit the following IPs for the Applause testers to access your test object: 100.26.65.148

If you do this, please make sure to let your Applause Delivery team know, as instructions will need to be provided to testers.

Mobile Surveys

Important: 

In order for your apps to receive and display mobile surveys please integrate with the latest mobile sdks (released late June 2016). Survey support starts on versions 3.7.0 (both iOS and Android). Once you’ve updated you’re ready to start using Mobile Surveys!

Surveys are set up via the web panel and presented to a participant while they’re using your app.

Setting up a survey

survey1

In the left hand menu click on “Surveys” and then on “Create survey”

survey2

You can set the survey Title and Introduction message. These are displayed at the top of the survey.

surveytitle

Plus the prompt that will ask the participant to take the survey.

surveysprompt

Now add some questions

survey3

You can choose from three options:

Single selection – participants can choose one of several options.

survey4

The participant will the following:

surveyssingle

Multiple choice – participants can choose more than one option.

survey5

The participant will see something like:

surveymultiplechoices

Free form – participants can give textual feedback based on the question.

survey7

Mandatory Questions

By checking the “Mandatory” check box it is possible to ensure that participants answer that specific question.

Targeting Groups

If “All participants” is selected then all participant added to your application will be prompted to take the survey.

survey-targetgroups

Alternatively it is possible to narrow down the participants by group (see above)

survey-groups

Triggers

It’s possible that to add a trigger delay based on current session time (session starts when the participant logs in to the Applause SDK).

surveys-trigger

In the coming months we will be adding more and more sophisticated triggers.

Publishing

Finally clicking on ‘Publish Survey’ will open up the survey to your participants!

surveypublish

What can I change after publishing?

It is possible to change anything that might break the logic of the survey.

  • Triggers (currently session time)
  • Targeted groups

You cannot edit question or choice texts. As you might imagine changing the question text in the middle of a survey from “Do you like cats?” to “Do you like dogs?” would invalidate the survey results.

Closing your survey

In the “Publish” tab you can close the survey by clicking on “Close Survey”. Once a survey has been closed no more results will be accepted or presented to participants.

What Features Are Lost When An iOS App Is Re-Signed to the Applause Enterprise License?

In addition to Push Notifications€, the following is a comprehensive list of which entitlements/extensions work (and don’€t work) after re-signing to the Applause Enterprise license.More information for developers… iOS-Resigning.

Extension/Entitlement Will Functionality work after resign Comment/Explanation
Access WiFi Information capability NO The Access WiFi Info capability won’t work when signed with Wildcard profile. To maintain the functionality the enterprise profile with explicit App ID must be used.
App Extension YES Resigning removes the specific entitlements keys from both the main app and its extensions (extensions are stored in the app’s Plugins folder). We have implemented an app resigning flow for apps with extensions to use the explicit App ID in order to preserve functionality provided by App Extension capabilities.

To preserve entitlements Applause must use a non-wildcard provisioning profile, which requires that you modify the bundle identifier of the app. For more information, see [Workaround].

App Groups capabilities NO The App Groups capabilities won’t work when signed with the Wildcard profile. Although an option exists to sign using a profile with explicit App ID with App Groups enabled, it is not possible to provide the same group ID as the original app; therefore, the app cannot use this functionality.
Apple Pay capability NO Apple Pay won’t work with the resigned app
Associated Domains capability NO The functionality won’t work because we remove the key to code sign the app
AutoFill Credential Provider capability NO The AutoFill Credential Provider capability won’t work when signed with Wildcard profile. When using the Wildcard profile the key is deleted, which removes the AutoFill Credential Provider functionality. To maintain the functionality the enterprise profile with explicit App ID with AutoFill Credential Provider capability enabled must be used.
Background Modes capability YES Background Modes capability
CarPlay capability NO The CarPlay capability won’t work because we cannot resign an app using the profile containing the original entitlement key. It requires a special entitlement issued by Apple.
ClassKit capability NO The ClassKit capability won’t work when signed with Wildcard profile. To maintain the functionality the enterprise profile with explicit App ID with ClassKit capability enabled must be used.
Data Protection capabilities NO The Data Protection capability won’t work when signed with the Wildcard profile. There is an option to sign using a profile with explicit App ID with Data Protection enabled.
Game Center NO Game Center functionality won’t work when signed with the Wildcard profile.
HealthKit capabilities NO The HealthKit won’t work when signed with Wild Card profile. There’s an option to sign with explicit App ID with HealthKit enabled
HomeKit capabilities NO The HomeKit capabilities won’t work when signed with the Wildcard profile. To maintain the functionality the enterprise profile with explicit App ID with HomeKit capability enabled must be used. There is an option to sign using a profile with explicit App ID with HomeKit enabled.
Hotspot capability NO The Hotspot capability won’t work when signed with Wildcard profile. To maintain the functionality the enterprise profile with explicit App ID with Hotspot capability enabled must be used.
iCloud capability NO The iCloud storage area won’t work between apps since we change the container identifiers
In-App Purchase capability NO The In-App Purchase capability won’t work when signed with the Wildcard profile.
Inter-App Audio capability YES
Keychain Sharing capability NO To resign the app with access groups specified, we replace the access group values with our own team value; therefore, the resigned app cannot access the original access group data as signed by the developer.
Maps capability YES
Multipath capability NO The Multipath capability won’t work when signed with Wildcard profile. To maintain the functionality the enterprise profile with explicit App ID with Multipath capability enabled must be used.
MusicKit capability YES
Network Extensions capability YES
NFC Tag Reading capability NO The NFC Tag Reading capability won’t work when signed with Wildcard profile. To maintain the functionality the enterprise profile with explicit App ID with NFC Tag Reading capability enabled must be used.
Personal VPN NO The Personal VPN capability won’t work when signed with the Wildcard profile. To maintain the functionality the enterprise profile with explicit App ID with Personal VPN capability enabled must be used.
SiriKit capability YES
Wallet (formerly Passbook) capability NO The Wallet (formerly Passbook) capability won’t work when signed with Wildcard profile. To maintain the functionality the enterprise profile with explicit App ID with Wallet capability enabled must be used.
Wireless Accessory Config capabilities NO The Wireless Accessory won’t work when signed with Wild Card profile. There’s an option to sign with explicit App ID with Wireless Accessory enabled.

To learn more about the two types of Apple developers licenses, please go here.

How To Manually Create A Jira WebHook

  1. Login to your Jira instance with an admin account.
  2. Press on the gear on the top-right corner and choose ‘System’.

1a

 

 

 

 

 

 

 

  1. Choose ‘WebHooks’ on the left menu (under ‘Advanced’).
  2. Click on ‘Create a WebHook’.
  3. Fill the field as follow:

Name: “Applause Notification Hook for ” and your product name.

URL:  “https://bts.applause.com/api/applause/v1/jira?apikey=” and set the apikey you get on the WebHook creation dialog when saving an Applause product with 2-way integration enabled.

Events:  1. check the issue updated event.

  1. In the text box enter a JQL for filtering by your project and issue type.

It should be like: “project = YOUR_PROJECT_KEY_HERE & issueType = YOUR_ISSUE_TYPE_HERE”

For most our customers the issue type is ‘Bug’.

The Webhook form should look like:

jira_webhook

  1. Click on ‘Create’ button.

How To Integrate With JIRA

For basic integration information, please see:  ‘Integrating With Third-Party Bug Tracking Systems’.

Applause supports the following versions of JIRA:

  • JIRA (REST API) Versions 5.0 or later

Integration with JIRA Implementation

Select the ‘JIRA v5+‘ option in the ‘Connector Type‘ menu.

Helpful Hint:  For easier tracking, create a new user within your user system with Applause in the name. This will help you quickly locate bugs exported from Applause into JIRA. It is important to assign project visibility in JIRA to the account being used for the connection in order for bugs to appear.

After selecting JIRA for your new connector, you will be presented with a number of fields.

  • URL:  Configure your web-based access to JIRA.
  • User:  Case sensitive. Requires the username to have create and save permissions within the JIRA system.
    • PLEASE NOTE: If using an Atlassian API token for authentication, you must use the associated email address for the user.
    • PLEASE NOTE: Newer JIRA instances may be using ATLASSIAN accounts, instead of JIRA ones. The username for that is typically the email address minus the “@###.com”. If still not working, go to your JIRA profile page and look for it there. JIRA usernames are seldom an email address.
  • Password/API Token: Case sensitive.
    • Customers using JIRA Cloud will need to provide an API Token in this field. All other JIRA users will use a password.
  • Jira Project Key (v5+):  Case sensitive, and needs to exist within the JIRA system prior to seeing up a new connector.  Assign where you would like Applause SDK-exported bugs to be located in the JIRA system.
  • Issue Type:  The default issue type for bugs sent from the Applause platform.

‘Labels‘ JIRA field: If you’d like to export particular labels for a product, simply write the label(s) (space-separated —- therefore 2-word labels are not possible) in the ‘Labels’ field mapping field on the product’s BTS connector setup screen.

 

[highlight]Please Note: Jira’s new view (2019) encodes URLs with special characters. This will affect many Applause bug attachment URL links and cause an error upon clicking the link from within your Jira’s new view of an exported bug. There are 2 workaround options you can do … 1.) Go back to the old Jira view. – OR – 2.) Copy/paste the attachment URL in the bug to a new browser tab w/o directly clicking on the link.[/highlight]

 

Lastly, if your BTS server uses the TLS SNI (Server Name Indication) extension and you run into errors, enable this setting on your product’s BTS connector setup and test/refresh your connection.

Next: Instructions for setting up Two-way Jira Integration.

For information on further customizing your BTS integration, please see: “Working With Bug Tracking System (BTS) Integration Connectors”

 

How To Integrate With Asana

Applause no longer supports a native Asana BTS integration; instead issues can easily be exported by integrating with Asana ticket creation through email.

For more information on setting Asana up for task creation via email, please read here.

For information on further customizing your BTS integration, please see: “Working With Bug Tracking System (BTS) Integration Connectors”

How To Integrate DX With JIRA

This page is specific to the Applause DX platform. If you are looking for Jira integration steps using our Applause In-The-Wild platform, please refer to this documentation.

Overview

The Applause DX Bug Tracking System integration offers users the ability to turn the Applause platform into a direct extension of their own backend BTS. Applause DX supports JIRA (REST API) Versions 5.0 or later.

Customers can access the BTS settings page from the settings drop-down menu, locating in the top-right corner.

An Applause BTS Connector is a configuration that allows Issues to be exported to your Jira server.

Supported Operations

  • Test/Refresh Connection: After entering all the required fields for a new connector, or, if you’ve updated information about a previous connector:  (e.g. URL, Username, Password, Project Key), click the ‘Test Connection’ button. For a pre-existing connector, click the ‘Refresh Connection’ button. This will allow Applause to (re)test the connection and pull in any custom fields and custom values that may exist within your BTS implementation.
  • To enable/disable a pre-existing connector: click on the ‘Enable’ or ‘Disable’ button.
  • To edit a connector: click on the ‘Edit Credentials’ button for a newly added or pre-existing connector.
  • Required vs Optional Fields: For a newly added connector if the connection has been tested, or for a pre-existing connector, Applause will populate the ‘JIRA Field Mapping’ section with all required/optional fields for JIRA. Required fields can NOT be removed. Option fields can be removed by clicking on the ‘x‘ icon to the right of that field.

What if my Bug Tracking System is behind a firewall?

If your BTS sits behind a firewall, please configure your firewall or security settings to permit the following IPs for the Applause platform to access your bug tracking system remotely:

  • 73.216.29
  • 21.127.192/28 (CIDR notation) OR 23.21.127.192 to€“ 23.21.127.206 (range notation)

Getting Started: Creating a BTS Connector

To create a new BTS connector, first enter the Jira URL, Jira credentials, and Jira Project information. Then, click “Test Connection” to verify that Applause can reach your Jira server. Once a connection is successful, any mandatory Jira fields will be displayed for you to configure. Finally, click “Save” to persist the connector so it can be used to export issues.

Helpful Hint:  For easier tracking, create a new user within your user system with Applause in the name. This will help you quickly locate bugs exported from Applause into JIRA. It is important to assign project visibility in JIRA to the account being used for the connection in order for bugs to appear.

  • URL: Configure your web-based access to JIRA, less than 200 characters.
  • User: Case sensitive. Requires the username to have create and save permissions within the JIRA system.
  • Password: Case sensitive.
  • Project Key: Case sensitive, and needs to exist within the JIRA system prior to seeing up a new connector.  Assign where you would like Applause SDK-exported bugs to be located in the JIRA system. For example, if your Jira tickets appear as ABC-123, then ABC is your project key.
  • Issue Type: Case sensitive, the default issue type for bugs sent from the Applause platform.
  • Enable SNI: Enables SNI (Server Name Indication) for JIRA server. Use this option if your BTS server has TLS SNI enabled.

Add/Update JIRA Field Mappings

For a newly added connector if the connection has been tested, or for a pre-existing connector, Applause will populate the ‘JIRA Field Mapping’ section with all required/optional fields for JIRA.

Adding Fields

Adding fields is very easy. Simply click on the ‘+ Add Field’ button, and select from a list of available fields.

Note:  If you have recently added new fields  to your JIRA implementation but do not see them listed as options, you may need to refresh the connector’s database by clicking the ‘Refresh Connector’  button.

Note:  As a reminder, any fields that have an ‘x‘ icon to the right of them are optional and can be deleted. Fields with star in the name or lacking the icon are required and can not be removed.

Setting Values

To send a static value for a particular field, simply click on the drop down menu and select the static value you would like to post to that field.

Note that this value will be sent for ALL bugs sent from Applause.

Note:  If you have recently added new value options to your JIRA implementation but do not see them listed as options for a particular field, you may need to refresh the connector’s database by clicking the ‘Refresh Connector’  button.

 

Updating an Existing BTS Connector

If your Jira project has changed, such as you’ve added new fields or new hires, you can “Refresh” your connection to get the new fields and/or options. Then, you can edit the appropriate field mappings. Finally, “Save” the connector to persist your changes.

 

Exporting your DX Issues

There are two ways to export issues to Jira:

  1. From the project results “Issues” tab, you can select one to many issues at a time (use checkboxes to select), click the Actions menu, and choose “Send selected to BTS”

You will get a confirmation screen:

Once you click OK, the status of those Issues will update to “Queued”, and then ultimately will update to reflect the Jira ticket ID in the bug tracking system (e.g., UDU-142 below). That ID will be a link to the actual Jira ticket.

 

  1. The other way to export an issue to Jira, is from the individual issue detail view. From the issues list, click on any Issue you want to view detail for.  Then, from the Actions menu at top right, click “Send to BTS”.  The “Export Status” will update to “Queued” and ultimately to the Jira ticket ID when it’s successfully exported. Note: You may have to refresh you page to see the status updated.

Customer Help

What’s new?

Applause has always offered ways to get customer feedback on apps, yet in some ways this has been limited. Our new offering greatly enhances our capabilities by allowing you to:

  • Send participants on a real-world journey. Much more than a simple test case, you can define specific tasks for users to conduct while interacting in the real world (e.g., order something, go pick it up, take a picture, etc.) and solicit their feedback while they are using your app, mockups, website, iOT device, etc.):
    • Define questions for each task of your journey, which participants respond to, as they are doing the task.
    • Request/require screen pictures or screen recordings of participants’ experience, so you can see what they see.
  • Get feedback from real end-users (not just professional testers).
  • Add your own users. Invite your own fan club, product/engineering teams, colleagues, friends, close circles, etc. to experience your app and give you honest feedback.

…and so much more.

Terminology

Project:

  • A project has a name, start/end dates, an app build/url, participants, and a defined journey.
  • It’s a container for what you want get feedback on, when you want it by, and from whom you want feedback.  
  • It defines the specific path & questions you want participants to respond to.

Journey:

  • A journey is a set of tasks you define, that you want participants to perform using, or in conjunction with using, your app/website/mockup/iOT device.
  • It’s the overall end-to-end, real-world user experience you want to get feedback on.  
  • You can specify each task description, add questions on each task, and indicate if you’d like participants to add pictures/screenshots/screen-recordings.

 

Workflow – Creating a Project:

Step 1: Define the Project

  • Use a name that is simple but descriptive. (eg. Pizza Delivery App V.2.4 – April 2017) 
  • Select start and end dates – these are your desired dates/times,
    • Share with your Project Manager, who will work with you to finalize.
  • Provide a description for your project. This is for internal viewing, and will not be visible to participants.

Step 2: Add Participants

  • Add your own project participants, and/or leverage Applause’s community.
    • Invite your own customers, product/engineering teams, colleagues, friends, close circles, etc. to experience your app and give you honest feedback.
    • Simply copy and paste in any email addresses of those you want to be invited to your project.
  • Add Applause Community
    • Indicate demographic, device, or other criteria that you would like participants to match. Your Project Manager will work to find participants who meet this criteria.
    • This information will be passed along to your Project Manager who will work to find participants who meet this criteria, so you can get feedback from those who matter most to you.

Step 3: Provide Access to the App

  • Upload a build or a pre-production app (Android or iOS)
  • Or provide a URL to your app, website, or mockup (e.g., invision prototype)

Step 4: Define a Journey

  • Name and describe your Journey. Participants will see this information and use this to help them determine if they want participate.
  • Add Tasks. Tasks are things you want participants to do, in or outside of your app/site/mockup/etc.
    • Participants will be prompted to conduct each task you define.
    • Instructions should be short and clear.  
    • Tasks can be dragged around to order how you wish, and can be copied or deleted as needed.    
    • You can ask/require participants to provide an image and/or screen recording for each task. This allows you to see and hear (screen recording) what participants experience, and also verify they completed the task.
    • Add any questions you’d like participants to respond to. Choose from single-choice, multiple-choice, or free-text questions. This can be done for each task. 

Activating a Project

When you’re finished creating your project, you can “Request Activation”, which means you’re ready to invite participants to participate.

  • Requesting Activation notifies your Project Manager that you are ready to go. The Project Manager will review your project, work with you to make an necessary modifications.  Then they will Activate the Project.
  • When the PM activates the project, participants will receive email invitations to join.
  • Participants will be instructed to download the Applause app and create an Applause account. (or log in) 
  • Once they login, they will see the Project/Journey you created, including a brief description of the project and expectations. They can then start the journey to conduct the tasks you’ve defined.
  • Your Project Manager will ensure you are getting the number and quality results you’re looking for.

Viewing Results

At any point in the project, you’ll be able to view and export participant responses. View information such as completion %, time to complete, and dive into detailed responses from everyone combined, or view results individually. 

  • View screenshots
  • Watch and listen to screen recordings
  • View pie charts, bar charts, and free text answers to questions you’ve asked.

Support

If this Help page doesn’t answer your question, click “Request Support” button at the top of this page.

Fill in the form which will create a ticket for the Applause Team. Choose the Category of “Digital Experience Alpha (DX)“. This ticket will go through our normal tiered support process, and escalated to product/engineering if needed.

Adding Statuses In My Jira For 2 Way Integration

For creating a 2-way bug tracking system integration between Applause and your Jira, you will need to provide the following statuses :

  1. Jira status that will mark the equivalent Applause bug as ‘Ready to verify’.
  2. Jira status that will resolve the equivalent Applause bug.
  3. Jira status that will be set on your Jira issue when the equivalent Applause bug verified successfully.
  4. Jira status that will be set on your Jira issue when the equivalent Applause bug failed verification.

2wayjira_flowdiagram

Editing Active Jira Workflows

If you are editing an existing, active Jira project, it is suggested that you copy or make a backup of the workflow.

Some versions of Jira may block adding outgoing transitions if the workflow is in “Draft” status (editing an active workflow). To add the transitions, you can make a copy of the workflow (under Jira Administration > Issues > Workflows). The newly copied workflow will be Inactive and will support adding the statuses and transitions described below.

Once you are done adding the transitions, you can set the Project’s Workflow to the new copy: Under Jira Administration > Projects, click the project name and to reach the Product Settings page. Then, click Add Workflow > Add Existing and select the new workflow name and the issue types (i.e. Bug). Then, Publish the changes.

 

Adding Statuses

For adding a new status in your Jira instance do the following:

  1. Login to Jira with an admin user.
  2. Press on the gear on the top-right corner and choose ‘Issues’.

1

  1. Choose ‘Statuses’ on the left menu.
  2. Click the ‘Add Status’ button.
  3. Fill the new status details in the dialog.

2

 

Adding Transitions

Now, you need to setup the transitions to/from these statuses as follows.

First, make sure that a transition exists that leads into the “Ready to Verify” status (or its equivalent in your system) from your usual workflow (i.e. “Code Merged” to “Ready to Verify”). If a transition does not exist, add it according to the directions below.

Second, add transitions between your “Ready to Verify” status (or equivalent) to the “Verify Passed” status (or its equivalent) and between your “Ready to Verify” status to the “Verify Failed” status if they are not specified. It is suggested that you disable the “Allow all statuses to transition to this one” option for both the “Verify Passed” and “Verify Failed” statuses in the workflow (so that you maintain control of when approved fix verification results trigger a transition).

Third, in case of a mismatch in the bug verification results (Passed for one tester, but then failed for a different tester), Applause will update your Jira issue status twice: once for the passed verification and second for the failed one. For supporting this functionality your Jira needs to have ‘Transitions’ between your Passed verification status and your Failed verification status.

To create a transitions between statuses, do the following:

  1. Login to Jira with an admin user.
  2. Press on the gear on the top-right corner and choose ‘Issues’.
  3. Choose ‘Workflows’ on the left menu.
  4. If you have a workflow for your project press on ‘Edit’ next to it, otherwise create a new workflow and then edit it.
  5. Click on the ‘Diagram’ button.
  6. Example: Add transition from Passed to Failed verification:
    1. Click on the ‘Add transition’ button.
    2. In the dialog, choose your verified passed Jira status as the ‘From status’ and the failed Jira status as the ‘To status’.
    3. Name the transition and press on ‘Add’.

3

  1. Example: Add transition from Failed to Passed verification:
    1. Click on the ‘Add transition’ button.
    2. In the dialog, choose your verified failed Jira status as the ‘From status’ and the passed Jira status as the ‘To status’.
    3. Name the transition and press on ‘Add’.

 

For instructions on how to set up 2 Way Jira Integration in the Applause Customer App see the help page: New Applause Platform