This month’s webinar is about the Experience API Version 1.0.0 that was released on 26 April. Presenter Nikolaus Hruska will explain the open source approach that facilitated the process, highlight key features of the resultant spec, and share examples of formal, informal, and social learning tools. He’ll also illustrate the benefits of the Experience API through several examples. For background, read the blog post about the spec development process.

Title: Experience API Version 1.0.0 Release
Date: Thursday, 23 May 2013
Time: 2:00-3:00 PM EDT (UTC−4 hr)

After you register, you will receive a confirmation email containing information about joining the Webinar. (We will provide an option to view the webinar via Defense Connect Online (DCO); the link for DCO will be provided in your registration confirmation email.)

Future topics in ADL’s 2013 Webinar series include a session in June on “Transmedia Learning (Part 2)” presented Dr. Elaine Raybourn. In July, Dr. Damon Regan will talk about “Making Reuse Real: Standardized Services and Open Source Software.” Details will be announced here.

Two weeks ago, ADL shipped a version 1.0 software specification on time – a community-backed approach with working production systems from many eLearning industry vendors already in place on launch day. As a leader in Government-sponsored open source projects, ADL leveraged its collective experience with open source efforts to steer the specification development process as a distributed, open and collaborative effort across fields of expertise, types of organizations, and even nations. Strong design vision, community management, facilitation, and open source practices were the success factors that drove election of the ideas that made it into the final product. ADL released the specification on 26 April 2013 with adoption pledged by over 30 vendors.

The specification working group’s use of free, open source tools was key to achieving this success. Some highlights of what made this process work are illustrated here.

The Evolution of an Application Programming Interface (API)

The Experience API (xAPI) is the latest incarnation of almost 15 years of API work at ADL, built on emerging knowledge and specifications. The work started in 1999 with the Sharable Content Object Reference Model (SCORM®), which has been widely adopted around the globe by governments, academia, and industry. The xAPI development, started around 2008, represented the eLearning industry’s move to a modern, web service API model. The community rallied around the ideas and capabilities to create a new API specification using the open source development model.

Transition out of Government – early and often

Transition of technology from government to industry and academia is critical to prevent long, costly operations and maintenance cycles. From the start, ADL stressed that it would NOT OWN the xAPI specification once it was completed and would let the market and community drive the process. About 60 individuals and 15 specification authors leveraged the distributed open source site GitHub.com to build a specification that the community owned. Gathering those who will use the technology and letting them define the specification was a new concept that would enable a smooth transition.

How did we get here?

Why would all of these vendors, who are by nature competitors, come together to build a new API again? During the late 1990s, the Services and Government agencies started migration of many classroom learning materials to web-based courses. A problem soon surfaced: courses contracted from different vendors could not be reused by other agencies. For example, a training course developed for the Army was not compatible with the Navy’s Learning Management System (LMS). An Executive Order in 1999 enabled the Department of Defense (DoD) to create the ADL Initiative to develop and release a common API to prevent vendor lock-in for LMSs and content. The reference model that is now known simply as “SCORM” was the result. The SCORM model met the requirements for what is was designed to do, but a new landscape of devices and non-web applications dictated a new set of requirements.

What’s the problem we’re solving?

The SCORM API and specification allow creation of reusable web content in ‘packages,’ which are played on a SCORM-conformant LMS. SCORM defines how to serve learning content and track learner data for a single user in a desktop browser. The API handles all of the communication between learning content packages and LMSs – similar to a client-server infrastructure.

The SCORM ecosystem encompasses a large market of LMS vendors, authoring tools, and learning content developers. The LMSs handle everything – user management, display of page branding and navigation, and reporting. Unfortunately, SCORM never established a reporting API: each LMS vendor creates their own reporting tools. Third-party custom tools do not have an API to display, assess, report, etc. from the data. Also, sharing data across domains is difficult due to the JavaScript security model, which can affect enterprise deployments. Meanwhile, smartphones and mobile devices have taken over – and native apps rule these devices. SCORM was developed for web delivery in the desktop browser and wasn’t meant to support apps, virtual worlds, games, and simulations. These new use cases tested the limits of the SCORM API as different devices and platforms became ubiquitous.

Listen to the community

As the computing landscape evolved, the eLearning community began to demand a web service approach to meet the new use cases. Meanwhile, ADL awarded a Broad Agency Announcement (BAA) contract to Rustici Software, a company in the eLearning industry, to propose a web service API – this time with a reporting API. “Project Tin Can” included a requirements-gathering phase to review over 100 eLearning whitepapers, interview industry leaders to understand their needs, and use a crowdsourced, use case gathering tool (UserVoice.com) to hear the voices of the users and take the pulse of the community.

Define a new approach

While the BAA-funded research project was being conducted, ADL engineers built and presented prototypes to illustrate the advantages of a web service-based architecture approach at ADL’s iFest conference in 2011. The examples included a Unity-powered executable file, an XBox Kinect game, a native Android tablet application, and content from a remote web domain displayed on a smartphone – all of which established two-way communication with the same backend learning system. These scenarios were the very uses that the community had difficulty supporting consistently due to the SCORM model – the same use cases that everyone had been discussing and asking how SCORM would support them in this new landscape! It was clear that the community and the technology were ready for an effort to support new features that SCORM wasn’t originally intended to cover.

Use industry knowledge to kickstart your effort

The result of the BAA project (“Project Tin Can”) was a draft API specification, a REST-style NoSQL server using the Node.js programming language, and three sample client applications. The prototypes show modern, tested software development techniques. They also show enterprise architecture can be achieved by viewing the LMS as a suite of components that could be composed according to the organization’s needs. The draft specification was chosen as the starting point for the community effort. ADL’s requirements and knowledge were already baked into the draft from the starting point since our stakeholders’ use cases were used to build the requirements. The ADL team just had to attract the community into participating!

Help facilitate collaboration

A few times per year, eLearning industry conferences enable the community to share new ideas, products, and vision. Twitter is instrumental in enabling learning professionals to continue the conversation between (and especially during) industry events. These collaboration opportunities allow a common vision to permeate through the industry thought leaders. ADL took on the task of organizing the interested parties into a cohesive force to draft an API, create code samples, and evangelize the new approach.

Provide the community with OWNERSHIP of the process

ADL designed the specification development process to be public and open to all vendors and interested individuals, which allowed the entire community to take ownership of the effort. Launched with a public announcement via webinar to over 200 interested parties in April 2012, the xAPI specification development effort eventually would have over 60 contributors participating in drafting the final version 1.0 document.

Choose your collaboration tools

The use of Wikispaces, Google Groups, Google Docs, MarkdownPad, and GitHub, allowed zero barrier to entry for anyone who wished to participate in the process. The working group initially started at Wikispaces so anyone could contribute ideas and proposals with no barrier to entry. Google Groups provided a simple discussion forum to flesh out discussion and proposals for incorporation into the specification. GitHub handled all configuration management and issue resolution. All of these tools are web-based and most importantly – free. Since the tools weren’t a Government acquisition, everyone involved in the process enjoyed the sense of ownership.

Allow differing levels of collaboration and participation

ADL created three different Google Groups (i.e., listservs) – for adopters, specification technical writers, and stakeholders – to allow varying levels of technical discussions and participation. ADL hosted weekly webinar meetings (which started in April 2012 directly after the project launch) to drive conversations, discussions, and decision-making while the groups and GitHub provided forums to discuss issues during the periods between the weekly webinar meetings. These groups and meetings continue to meet as we work on the next release of the xAPI.

How do you author a document with 60+ contributors?

While about 60 individuals overall contributed to the document, there were 15 actual specification authors. How do you compose a document with 15 authors? Since the ADL Tech Team and the community of contributors were composed primarily of software and IT professionals, configuration management practices are second nature. The working group made the decision to move from Wikispaces to GitHub as concepts in the specification were solidified and a push to author different technical sections was about to begin.

Enter GitHub.com – distributed source control

ADL converted the text to Markdown and moved the specification to the ADL GitHub site, along with all of our other code-based repositories. All specification authors now had to fork the specification document and make pull requests (PRs) to draft or update sections. ADL engineers still authored parts of the spec, but were mainly able to review and merge PRs from the community participants.

Drive the process

PRs are tied to GitHub ‘issues’ where behavior and wording were discussed in detail, while the weekly calls tackled high priority issues in the GitHub Issue list. The GitHub workflow truly democratized the process and allowed any vendor or individual to step up and lead the efforts. ADL had a community of individuals from industry, Government and academia drafting the specification and developing prototypes against version 0.9. The group subsequently released a version 0.95 with more tools created, and now stands at a version 1.0. When possible, each release was scheduled near an industry conference so that vendors could show off their new tools and capabilities. The xAPI opens up a new market for enterprise architecture components that support new types of learning experiences (content), analytics, and reporting tools for use in a variety of customizable solutions.

Complete the transition phase

In true open source spirit, many contributors maintain their own projects with software libraries and tools to support the xAPI. These vendors developed tools to prove the soundness of the specification as it was evolving. With limited resources, ADL was able to get a specification written with associated software working on multiple platforms. While ADL remains as the steward of the specification because the architecture and vision originated at ADL, the larger ADL community shares ownership of the specification. They own the open source libraries. They own and market the tools they’ve built around it.

Reflect and plan next steps

The xAPI is an open source success story. The clear winner is the Government and the industry/academic community that supports and uses the specification. Both ADL stakeholders AND customers got their needs incorporated into the xAPI through our requirements gathering and community management efforts. Crowdsourcing allowed prioritization of use cases for the next generation API. Software developers from industry and academia composed most of the specification while ADL facilitated the efforts of the contributors. The result is greater than what ADL resources alone could produce, has the backing of a community of industry vendors who will be using the technology, and was completed in a fraction of the time usually required for an effort of this magnitude.

The eLearning industry now has a stake in the game to make the specification better with time. ADL is currently looking for a standards body to continue evolving the specification to meet the community’s needs. Once an organization is chosen to proceed with the work, ADL will be sitting at the table, no longer as the facilitator, but as a participant – just like the vendors and other community members.

For more information, please visit http://xapi.adlnet.gov.

Challenge winners will be selected by a panel of experts who will evaluate the Apps on these criteria: Provides a learning solution to a stated problem; Technical quality of the App; Usability; and Innovativeness. Winners will be invited to demonstrate their entry during the Interagency Mobile Learning Webinar Series to be held 16-18 July 2013.

The Challenge will open for submissions 1 May and will remain open until 16 June. There is no cost for entering. For additional information, visit the Learning App Challenge page.

Over 60 developers, designers, engineers, standards veterans, stakeholders and vendors from around the world representing industry, academia and government contributed to an open and collective effort to meet this goal in just over 12 months.

The Experience API specification Version 1.0.0 marks the first major release of the technology, built on requirements and design considerations going back to late 2008 and research and development (commonly known as “Project Tin Can”) that began in 2010.

In the spec, Dr. Kristy Murray, Director of the ADL Initiative, writes,

“My thanks to everyone who contributed to the Experience API project. Many of you have called into the weekly meetings and helped to shape the specification into something that is useful for the entire distributed learning community. Many of you assisted in releasing code samples, products, and documentation to aid those who are creating and adopting the specification. I’d also like to thank all of those who were involved in supplying useful, honest information about your organization’s use of SCORM and other learning best practices. Through the use-cases, shared experiences, and knowledge you have shared, ADL and the community clearly identified the first step in creating the Training and Learning Architecture–the Experience API. You are truly the community leaders on which we depend to make our training and education the very best.”

The work on the Experience API resumes in mid-May as the working group prepares for specification refinements based on how people use the API over the next year. (A PDF file that represents a formatted “snapshot” of the authoritative specification as of April 26 is available for download. PDF, 1.6 MB)

In the meantime, it’s time for celebration. On Wednesday, May 1, from 2:30-3:30pm Eastern, a “launch party” will occur on Twitter. Follow the hashtag #xAPI.

The 3-day format will allow you to participate in the sessions that are most relevant to your needs and interests. Our plans for the webinar series include having invited experts discuss their successfully deployed projects, learning and performance support, designing for mobile, mobile policy updates and other mobile learning hot topics. Mark your calendar now and keep watching this site for more details.

Questions? Email adlmobile@adlnet.gov

To make sure you receive the latest updates about the Interagency Mobile Learning Webinar Series, subscribe to our ADL Insights or ADL Mobile newsletter.

Procedure

Advanced Training & Learning Technology, LLC (AT&LT) followed a research approach that leveraged existing and ongoing development of their educational math game intended to teach a Pre-Algebra curriculum. The R&D activities consisted of the development of a generalized and modular software library consisting of an Intelligent Tutoring Agent (ITA) and associated Application Programming Interface (API) to integrate tutoring algorithms and data with the AT&LT Math Game. The intended use of the ITA and math game was for 6th-8th grade middle school students. The research objectives also included research to assess the efficacy of deployment of the math game and tutoring technology within DoDEA.

Findings

AT&LT followed a R&D schedule that consisted of ITA development concurrent with a series of three phases of formative evaluations to assess the quality and necessary improvements to both the tutoring technology and the math game as used by 6th-8th grade students. The research included the successful development of an ITA Software Library (ISL) consisting of the ITA, the API, and associated software documentation and support tools. The initial version of the ITA provides basic tutoring functions for asset management, visual and auditory feedback, forced interventions, and time-based monitoring and assessment, among other features and capabilities. The functionality of the ITA coexisted as an embedded tutoring capability and set of features in a version of the math game that was successfully used in a series of formative evaluations. The project culminated in student math camps that included the successful use of the game by the student population targeted for this research. The math game was also successfully deployed and used in an informal setting by DoDEA during a summer enrichment program at Ramstein AFB.

Resources

• Final Report
• Evaluation Information Paper
• GitHub Repository for ITA Agent Software

The prerequisite for this tutorial is a basic-to-intermediate understanding of 3D mesh creation and the principles of animation with industry tools such as Autodesk’s 3D Max, Maya, Softimage and the free open source Blender 3D creation tool. This tutorial will focus on a pipeline that uses Softimage import into Blender. However, the principles for importing models into Blender are the same for other 3D software.

Figure 1

Sources of 3D Models and Tools

If you are not an artist, fear not. There are many free resources available. Sites such as www.TurboSquid.com (Figure 1) have many items free for use and quite a few models that make great attachments and / or models that serve as complete avatars. Sites such as the ADL 3D Repository 3dr.adlnet.gov, 3D Exchange www.3dexchange.com, and Flat Pyramid www.flatpyramid.com are several other resources that provide free models and models for purchase.

Figure 2

Autodesk’s Softimage (Figure 2) is a free full animation suite offered to game developers for use in creating collaborative design activity (COLLADA) models. This tool is excellent for building, adjusting and texturing meshes and exports to Blender with ease. You can download the software at http://usa.autodesk.com/adsk/servlet/pc/item?siteID=123112&id=13571320.

Figure 3

The Second Life and Open Simulator communities have long embraced Blender.org (Figure 3) and the free 3D creation tool. Benefits of using Blender include several direct plugins that export to Second Life and Open Simulator. You can download and install Blender 2.65 at http://www.blender.org/download/get-blender.

Figure 4

The main file needed for mesh manipulation is conveniently available on the Machinimatrix website (Figure 4). The file is the avatar-workbench-265.blend file found at http://blog.machinimatrix.org/avatar-workbench.

Setting up the Blender Rig

The first step in the process is to start Blender 2.65 and open the avatar-workbench-265 file (Figure 5).

Figure 5

This armature will be used for all avatar mesh manipulations. The avatar is a scaled version of the avatar mesh found inside of the Second Life or Open Simulator client. If you are not familiar with Blender, the manual has documentation concerning moving and selecting objects in the main viewport. This tutorial assumes a base knowledge of Blender use.

Exporting the Rig for use in Softimage XSI Mod Tool

Three parts of the avatar mesh are to be exported into Softimage XSI Mod Tool. XSI Mod Tool will allow proper adjustment of the clothing mesh that was downloaded from Turbosquid.com. If you have more experience with other 3D programs, this export will work equally well for this process.

Right click each of the three parts while holding down the “Shift” key (Figure 6). Select “File-Export-Wavefront (.obj)” and save the .obj on your computer. This process is specifically for those individuals who have experience working with a particular 3D package of their choosing. If you have experience with Blender, the same steps shown for XSI Mod Tool can be done with Blender.

Figure 6

Figure 7

Figure 8

Import the Mesh into Softimage XSI Mod Tool

Open the XSI Mod Tool and import the mesh dress (Figure 7). Turbosquid offers this mesh as a Wavefront .obj file. Other file formats such as COLLADA .dae files are acceptable as well. Align the mesh dress to the avatar body by translating, scaling and moving vertices on the mesh surface.

The goal is to form the dress over the body as close as possible while keeping the avatar surface from protruding through the mesh of the dress. The example above (Figure 8) shows a lattice deformation that moves vertices into the proper places. Depending on the 3D program used, various techniques can accomplish the process.

Once the positioning is completed, freeze the dress model’s state as shown in (Figure 9). This makes all the modifications permanent and collapses the operator stack. We are now ready for export back to Blender for avatar mesh weighting. This critical process makes the mesh stick precisely to the avatar when applied in Second Life or Open Simulator.

Figure 9

Figure 10

Export the dress mesh from “File-Crosswalk-Export” in the top menu (Figure 10). Choose COLLADA from the “Crosswalk File Type” block and under the “Settings” tab, match the checked blocks shown at the right hand side of the dialogue block. In the “File Name” block, select the save location in the same file folder as the location of the dress mesh texture and name the mesh. The final step is to click the “Export” button.

Figure 11

Importing the Mesh Dress into Blender

Return to Blender and reopen the avatar-workbench-265.blend file. From the main menu select “File-Import-Collada (Default) (.dae)” and select the adjusted COLLADA dress model exported from the XSI Mod Tool. Use the “S” key to scale the dress to the avatar body. Keep the avatar mesh from showing through the dress (Figure 11).

Figure 12

The parenting or enveloping to the armature is accomplished by selecting the dress and armature. Hold down “Ctrl+P” and choose from the dropdown “With Automatic Weights” (Figure 12). This associates the vertices of the mesh dress to the bones by proximity. Blender averages the influence of each of the vertices and how much movement each bone controls. This procedure is not precise. If you select the bones influencing the mesh dress at this point and rotate in any direction you will see how many of the vertices pull and deform poorly. The program does not understand the visual aesthetics of the weighting process. This is why the artist needs to tweak and adjust by a process called Weight Painting.

Weight Painting the Vertices of the Mesh

The dress mesh is ready to be weight painted for proper deformation. Select the dress by right clicking and from the “Mode” panel (Figure 13) select “Weight Paint”. The dress mesh will display a blue surface color indicating the Weight Paint mode. The “T” key will open the tool panel on the left-hand side of the 3D viewport. The weight paint controls will display.

Figure 13

The armature must be set to the “Pose Mode” from the Mode panel in order to move the avatar around and see how the dress deforms. Right click on the armature.

The armature is represented as the skeleton framework shown inside the avatar mesh (Figure 14). Once highlighted in orange, select the “Pose Mode” and the armature will now change to an active blue color.

Each bone that makes up the armature is selectable and movable. Rotation will be the only movement used to check mesh deformation. The dress is now ready to have vertices adjusted or re-weighted to the appropriate bone of the armature.

Figure 14

Figure 15

Select the dress mesh and ensure that the “Mode” panel shows “Weight Paint”. Right click any of the bones and you will see the weight influence of the bone. In this mode, the cursor will represent a paintbrush. The weight panel control displays weight, radius of the brush and strength of the brush. The “Blend” box switches the brush to different paint states. The predominant “Blend” states used will be “Add”, “Subtract” and “Blur” (Figure 15).

Begin painting the weight influence per bone. Using the “Z” key will toggle the mesh back and forth between a solid surface and a wireframe view. It is easier to see the progress of painting in the wireframe view. The wireframe view eliminates lighting and shadows making the surface color more visible on sides facing away from the light source.

Figure 16

As the brush adds and subtracts from the bone influence, use the “R” key or “Rotation” to move the bones. This will show how the dress is stretching per the bone’s influence (Figure 16). The weighting process requires testing of each bone to see how the mesh is responding to the bone movement. Subtract bones that have no influence on the mesh dress entirely. Every bone in the armature may have some weight assigned. Individual rotation of each bone will show if there is influence.

The process of painting weights can be a tedious process. Patience will assure a proper blend between the individual bone influences.

Preparing Mesh for Export to Second Life or Open Simulator

When all weight painting is complete, the mesh is ready for export to use in Second Life or Open Simulator. Select the dress and return the mode back to “Object Mode” (Figure 17). Next, select the armature and change the mode to “Object Mode” as well. The head, upper torso and lower torso meshes of the avatar are not needed for export. The dress is the only mesh we are concerned with in this example.

Select both dress mesh and armature by right clicking while holding “Shift” down.

Figure 17

Figure 18

Under “File” on the top menu bar, select “Export-Collada (Default) (.dae). On the left-hand “Export COLLADA” panel, check the “Selection Only” block (Figure 18). This ensures that the dress mesh is the only thing exported and not other elements in the scene. Under “Texture Options”, make sure that “Only Active UV layer”, “Include UV Textures” and “Include Material Textures” are selected as well. This keeps proper UV information.

Uncheck the block “Copy”. The final block selection is “Export for Second Life”. This selection is how Blender formats proper avatar weighting for Second Life and Open Simulator. Save the COLLADA file to the same folder as the dress texture. Second Life and Open Simulator will not find the texture unless it is in the same folder as the COLLADA mesh.

Figure 19

Importing the Dress Mesh into Second Life or Open Simulator

In this example, the mesh dress will be imported into the public Second Life grid. The process is identical for the versions of Open Simulator that support mesh.
Find a location that allows build rights. From the inventory window, select “Upload-Model” from the upload widget in the bottom left-hand corner (Figure 19).
Navigate to the folder with the Dress.dae file. Select the dress and it will open in the Upload Model panel.

Figure 20

First, name the mesh in the “Model name” block. The dropdown “This model represents” will tell Second Life or Open Simulator that the mesh being uploaded will function as an avatar shape (Figure 20).

Select “Use LoD above” in the Medium block under the “Level of Detail” tab. This step will ensure the model will retain the higher level of detail and not collapse when the client’s camera travels away from the avatar.

Figure 21

Under the “Upload options” tab, check the “Include textures”. This applies the texture based on the UV coordinates of the mesh as well as places a copy of the texture in your inventory with the same name as your mesh. Under the “For avatar models only”, check the “Include skin weight” and “Include joint positions”. This includes the weight deformation that was created in Blender.

Lastly, check “Calculate weights & fee”. This will calculate the land impact on the simulator and assess cost on the public Second Life grid. No cost is associated with upload in Open Simulator. Once calculations are complete, the “Upload” button will appear. Click “Upload” to import into the inventory (Figure 21).

Figure 22

The mesh dress is ready to be worn. Locate the dress in the inventory window. Right click the dress object and select “Wear” (Figure 22). The dress will automatically deform over the avatar. Additional adjustments may be required to tuck correctly into the dress. If the avatar’s shape varies greatly from the default shape, adjust the body sliders to fit the avatar skin within the contours of the dress.

Figure 23

There are some techniques used to better conceal the avatar shape beneath the dress. In this example (Figure 22), the avatar skin textures have alpha channels applied where the dress falls. This makes areas of the body invisible even if the body protrudes through the mesh dress.

In conclusion, this is just one of many things that you can do with these techniques. The same methods apply for an entire avatar mesh. With some practice and patience, you can create virtual environments with a great level of additional detail and creativity (Figure 24).

Figure 24

What this means is that with over 50 developers, designers, engineers, standards wonks, stakeholders and vendors, our Working Group has been focused on this spec for the last year. We’re pretty sure we got it covered, but a fresh set of eyes would help. If you’re up for it, we’d welcome your comments on how to make this specification even better.

First off, review the Experience API specification. At about 40 printed pages, it’s a far faster read than the 1700+ pages of SCORM® documentation. You may also want to take a look at the list of issues, clarifications and suggested improvements that are already raised about the specification.

Just a brief word about what kind of feedback we’re looking for. For the moment, we’re interested in making sure that using this specification to achieve the goals of the Experience API is clear, as concise as we can make it, and able to be replicated by any number of developers to help support interoperability for anyone who wants to use the spec. We appreciate the kudos (and, frankly, the concerns), but this isn’t a call for such feedback. If something can be better, we welcome your input on how to make it better.

To encourage as many people to participate in this open call for public comment, we’ve made it as straightforward as we can to share your feedback. You can simply send an email to tincanapi-spec@adlnet.gov with a subject line that briefly describes the issue or comment (you can post it to the Google Group from your web browser, alternatively) with your comments as the message.

You can get specific and target your feedback and share an issue through GitHub, where all the work on the Experience API specification is hosted.

If you choose the GitHub route and you don’t already have a GitHub account, you can set up a new GitHub account with four simple steps. From GitHub’s own help page, here’s how simple it is:

1. Select Signup and Pricing from the top of the GitHub homepage.
2. Select the appropriate account type and level that you want to create. For a free user account, select Create a free account.
3. Enter the requested information
   • Username
   • Email Address
   • Password (note that your password must contain one lowercase letter, one number, and be at least 7 characters long).
   • Confirm Password
4. Select Create an Account

If you want to address something about the Experience API specification that hasn’t already been raised in the issues, open up a new issue ticket and join the fun!