The User Experience (UX) team has developed resources for usability and workflow testing using a ‘sandbox’ area provisioned by the Infrastructure team. This allows for tightly controlled testing on a real GitLab instance without the risk of critical data loss or a security breach to gitlab.com. This page details the steps needed to access the sandbox and guidelines on how to structure a study within the sandbox.
The UX Cloud Sandbox is a reserved instance of GitLab running in its own ‘private’ space. Essentially, it acts as a completely separate installation of GitLab, similar to that of a self-managed client. That space is currently at https://ux.gitlabdemo.cloud/.
The UX team uses this space for usability testing, workflow studies, and usability benchmarking. The sandbox solves two problems: 1) it creates a safe environment for external participants to be able to share their screens without violating security or privacy concerns, and 2) it allows us to test Admin and Ultimate plan features not easily accessible through gitlab.com.
You may wish to use the UX Cloud Sandbox if you are interested in:
To gain access to the UX Cloud Sandbox, the first step is to generate credentials. You can self-serve on that by following the steps on this handbook page under ‘Access Shared Omnibus Instances’.
Once you have generated credentials and accessed the sandbox instance, you will be automatically granted your own group space with your name on it (see picture below). This group is like any other group in GitLab, it just has your name on it, and will act as the container for all of the work you do in the sandbox.
Again, everything you do should be within your own group. Your group will have your name on it, and it lives at the ‘root’ of all of your work. To preserve this structure, please try to avoid creating any other top-level group (at the same level as the group with your name) on the shared instance.
Within your group, you can structure sub-groups and projects however you see fit. One good way to think about it is as a file system: groups are ‘folders’ and projects are ‘files’. Your structure may end up looking something like this:
If you find that you need to make adjustments to the group/subgroup structure, you can move subgroups around by following these steps:
There are several reasons you might wish to generate sample data within your group or projects. These projects are empty by default, and testing user behavior on an empty project is not very accurate or realistic. It can be time consuming and tedious to handcraft an entire project’s worth of sample data, so we’ve created a few options to populate your projects with sample data through Ruby scripts.
Note: Not every type of data can be generated, especially in more complex setups. To get an idea of what is and isn’t possible, check the Gitlab Ruby gem documentation.
For questions or troubleshooting, reach out to @leducmills on Slack.
Note: It is easier to create a project and populate it with sample data than to populate an already existing project. However, you can edit the sample data ruby scripts (linked below), if you feel comfortable.
$ gem install gitlab faker #this sets up our connection to our gitlab instance
client = Gitlab.client(
endpoint: 'Add the endpoint URL here',
private_token: 'Add your token here'
)
# Global Variables for instance setup (probably around line 95 or so)ruby your_file_name.rb. You will see a number of status messages print to the terminal informing you of the status. Once the script stops, the data creation is complete.If everything has worked properly, you should see your imported project, with all of the sample data intact, within the sandbox.
Important: Forking a project is the quickest way to copy a project to a new space (or create your ‘session’ projects). However, it does not copy over data like merge requests, labels, or issues. It does copy branches, commits, files, and commit messages, though, so if that’s all you need, fork away.
If you do need MR, issue, and label data, you must repeat the import process for each session you wish to run by creating a new project, selecting import, importing from gitlab export, and selecting your .tar.gz file for each upload.
If you would like a project (or projects) with sample data to be created for you, please create a new UX Research issue using the 'Sample Data Request' template. Note: It is easier for the team if you do not create your project before opening the issue, as it is easier to create and populate the project at the same time.
The following information is required to fulfill a request to create these projects:
Example defaults for the various content types can be found in this sample project.
Please note, the following items are NOT exported when a test project is created and imported into the research sandbox:
While you can create users and user credentials through the scripts, it is generally discouraged, as we do not want the sandbox to be bloated with fake user accounts. Luckily, the UX Research team has a set of user accounts specifically for testing that you can use.
Once you are logged into the sandbox, navigate to a group called User Test Accounts. There is a project in that group named testing accounts. On the main branch of this project is a file called accounts.md. This file contains the credentials for all the user test accounts, as well as instructions on how to create more accounts if needed.
When using test accounts for your study you will be responsible for changing the password after each participant session to protect our environment. The last updated password (after your final user) will need to be recorded in the accounts.md file for the next person to use.
Do:
Don't:
Q: How how do you change the user password in the UX sandbox so that you can use a different password for each participant in a usability study?
A: Follow the steps on how to change the passwords on user profiles outlined in this video