App certification & changes to handling .JS files on Marketplace


#1

Greetings all!

We’re about to implement some new standards on the High Fidelity Marketplace which might affect the way you prepare your work. These standards are based on the kind of root file your product uses. If your product is essentially an entity, but is rezzed by Javascript (such as a .JS root file), this will affect you the most, as we are phasing out .JS root files for entities.

Apps (.app.json root file)

If your Marketplace item has an .app.JSON file as the root file, it is a considered an app, meaning it should work with the desktop toolbar or in-world tablet. This keeps apps in a common, manageable space. Like a real world application, it needs a launch button icon and UI that can pop up when you click the button. That UI can be as simple or complex as you like. We suggest you use it to add relevant functionality, like an on/off toggle, instructions, credits, or any other options your application needs. You can learn more about creating an app in our documentation.

The .app.json file is a basic JSON file which contains two key pieces of information: scriptURL and homeURL, for the application logic and UI in html, respectively. Here is an example .app.json root file, called hrtf.app.json:

{
“scriptURL”: “http://mpassets.highfidelity.com/db5a594c-ab7d-4276-a75b-234429817755-v1/HRTF.js”,
“homeURL”: “http://mpassets.highfidelity.com/db5a594c-ab7d-4276-a75b-234429817755-v1/HRTF.html
}

Entities (.json root files)

If your Marketplace item has a .JSON root file, it will continue to be handled the way it always has, and does not need a tablet button or UI.

What if my Entity is created (rezzed) by a .JS root file?
You’ll need to decide if you want it to be a tablet app or an entity… Some developers have created entities which are not delivered as .JSON files, but instead are rezzed in-world using a .JS script as the root file. If you’ve created such an entity, you’ll need to decide if you want to control rezzing it as a tablet app, which would require the button and UI mentioned above, or convert the final product into an entity and export that as a JSON file. An example of an “entity” which might better be distributed as an app would be a virtual pet, with a UI that can rez the pet, show its health and statistics, manage food, and customize its attributes (like its name) with a tablet UI. If it doesn’t need UI functionality, it needs to be a .json root file instead.

If it is important that your entity be rezzed by a script, and you don’t want it to be a app, you can implement an intermediate “unopened box” entity, which contains a rezzing script that can be triggered by an event (like clicking on it).

My entity has a .JSON root file but uses entity scripts. Do I need a tablet UI?
No. As long as the root file is .json, you do not need to add a tablet UI. This policy only affects items with an .app.JSON root file. Entities with scripts attached are just fine.

What’s the motivation for this change?
We are hard at work on making High Fidelity the Social Virtual Reality platform of choice for people across the world. This includes people across diverse cultures, different levels of education and access to technology. One of the core pieces of High Fidelity is the “Tablet/App bar” and we are always looking for ways to make it simpler and easier to use for everyone. This involves making improvements to visual design, consistent interactive elements and improving the discoverability of information. Previously, in order to move fast, we had allowed App buttons to either open a separate UI or act as a toggle button to change the state of the app between ON and OFF. As we mature as a platform and focus on improving the quality of the user experience, we found this to be a constant source of confusion for new users unfamiliar with the platform and existing users when they installed a new app. In an effort to reduce this confusion we are making the change that all top-level app launch buttons should lead to a separate screen for the app. It also provides a place for developers to surface new functionality to existing users with a familiar screen. We understand that this may lead to developer discomfort for those who have apps with the older app guidelines on the Marketplace. We do believe that making the “Tablet/App bar” less confusing and easy to use will reap greater benefits to our community and help us move forward towards the goal of a public Metaverse.

Where can I learn more?
This new functionality will appear in the documentation shortly. In the meantime, we’ve made a Google Doc with additional information on the new design, and architecture details, that you may find helpful, below. Feel free to come to our Monday Maker Meetup with any questions.


How to create app.json file?
#2

Read the app design guidelines presented. Very well thought-out and seems to be a target that typical web developers would be able to hit.

Question:

You’ve shown an .html file and a .js file as the needed minimum requirements. There is obviously the potential (as you mention in the doc) of loading external webapps. You mind much if I take that approach instead? I can cram multiple .js files into one giagantic file, and then hope Angular will AoT compile what needs to be done; but all of that is theory. My question is: can we get some form of UAT and High Fidelity Inc. sign-off for a multi-faceted full-service web based application? I certainly wouldn’t want to dump that on to your team for approval without an expected lead time for the approval process completion. What is the strategy there?


#3

Side note: anyone developing apps needs to know that standard select box elements in html, also know as ‘drop-down-menu’ do not render in full-screen and hence do not render in HMD. Here is a picture of me activating a drop down in full-screen mode versus doing it in ‘windowed’ mode. Technically, the options are shown in a container, but that container is anchored directly to the initial location of the app render page (tablet) at time of app state toggle = ON, this makes it not visible at when in fullscreen or HMD.

_fig 1. user opens the APP and does NOT move the tablet. _

fig 2. user chooses to populate ‘Blanc’ avatar with a different offering in window mode and the app window has NOT been moved. result: drop-down work OK.

fig 3. user chooses to change product again with a different offering in window mode and the app window HAS BEEN moved. result: drop-down placed ‘offscreen’ but functions OK.

As mentioned, the select box options do not show up at all when in full screen or HMD mode. Clearly this will halt development testing inside of an HMD. The select box is a standardized historic element in html. It’s been present since the beginning of the standard. Do fix this as soon as possible.

Thank you.


#4

Me again.

I went ahead and took the time to generate an APP that will guide you to an example of HTML5 elements so you can see what does and doesn’t work.

Running Scripts from URL: http://metaversestudios.com/images/APP_HTML5_FORMS.js

If your team is truly leaning on it’s agnostic nature of standards via HTML and JS, please ensure those users (and companies) developing APPS for your eco system have what they need to survive…

thaaaaaaaaaanks!!!


#5

Hey there Alpha,

First, thanks for taking the time to explain and document issues with drop down menus… we’ll take a closer look at that.

Regarding your app question and linking it out to external web apps, we definitely can see the reason why you’d want to do that, and there’s very good reason to do so.

In terms of putting an app on the Marketplace, we’re only just beginning to phase in this new design policy with our first officially compliant apps coming this month. Because of a multitude of unknowns that need to be accounted for… like privacy concerns, legal liabilities and other variables we have not yet explored, we’re not yet ready to do that before we take a microscope to the legalities involved in delivering a client for an external web service in the Marketplace. That being said, there are all kinds of amazing opportunities here, with a wealth of services and possibilities for both users and businesses who wish to serve them.

For that reason, we are definitely going to explore this. More likely than not, it will emerge, but needs a little time things to gel.

Cheers
Caitlyn


#6

This topic was automatically closed after 30 days. New replies are no longer allowed.