Tablet App best practices and standardization

[Zetaphor]

I'd like to start a discussion around developing best practices and standardizing the code structure and UX of tablet apps.

While digging through the examples avaialble from community scripts I found a number of implementation patterns, including this page from the docs which is listed as outdated.

I don't have enough experience yet with the UX to start identifying and defining UI primitives, but I can speak to the frontend libraries. I'm personally partial to using Tailwind CSS as it allows simple style composition in markup. For something simple that isn't reactive where I'm not going to bring in Vue (my reactive framework of choice), I prefer Cash.js.

Pinging @Armored-Dragon and @AnotherFoxGuy per our discussion in-world. Also pinging @AleziaKurdis as they've created a nice tablet app template that 74 pointed out earlier today.

[Armored-Dragon]

Some additional topics I think would be good to discuss:

• Theming & colors
• Library folder for common resources for apps
• Consistency between HTML and QML
  • Actual app frames as well.

I would also like to discuss not only Tablet apps, but the whole tablet as a whole. In order for a unified experience I think the whole tablet should be brought into the mix, not only on the app side. There is not much I think needs to change, if anything, about the tablet itself as the actual structure of it is fine, the most we may need to discuss is colors, padding, and spacing.

[Armored-Dragon]

Colors and basic style I think we should get knocked out first. Some things we may have to consider are the needs of visually impaired people. We should have some nice way to allow users to switch the current font displayed in the tablet ecosystem to one easier for them to read. we'll also have to look at color blindness. This won't be a massive issue here and now but this is something I think we should build into the core of the unified base.

I think the following colors would be a good starting point

(Can can view my live stylesheet here)

Fonts are going to be a little bit more tricky on my part.
I found OpenDyslexic, however it's licensed under a license I haven't seen before. It might be acceptable as I just briefly skimmed it, but another look will be needed.

[AleziaKurdis]

It's a good idea to have a reference chart defined for color and font. We should have done that before.
(The original logo color was #6667AB but I'm very fine with 505186, as it is well balanced.)

[Armored-Dragon]

Good catch! I did try using the actual Overte purple for the generic button, however I felt as though it made the white text too hard to read, so I darkened it just a touch.

[BLKZOR]

The OpenDyslexic licence is the same licence as the already adopted Fira Sans.

[Armored-Dragon]

I wonder if it would be more ideal if we handled font selection not in the Tablet ecosystem but the whole game. Maybe we have a setting in the Settings page that allows a font selection? This would make it easy on app developers and will make the whole game more consistent for the user.

[keeshii]

In my opinion the whole content of the "scripts" directory is messy. I would love to see it reorganized into something more modern approach.

Like having there a repo with the packages and each package has its own package.json. Then the packages could be depended of each other like in the monorepo.

I personally don't like the idea of using the scripts/styles from far away folder. It could happen that someone make a change, which breaks someone elses code and it will be hard to detect.

Also would love to see those scripts to be rewritten to typescript. I know this is quite a revolution, but better sooner than later.

[AleziaKurdis]

" I personally don't like the idea of using the scripts/styles from far away folder. It could happen that someone make a change, which breaks someone elses code and it will be hard to detect."

This is so true. At the point that everyone ends to add new CSS to not take any chances...

[Zetaphor]

This was something I was alluding to at the dev meeting today. I misunderstood the missing HiFi buckets to be something that the client is bundled with, when in fact they are just S3 buckets of assets for HiFi.

I was wondering if it would be worth exploring having either a dedicated host or even client side bundle that includes the recommended assets for app development. That way we could either be in control of our CDN and ensure caching, or skip the extra network request and just serve them from the client install.

[keeshii]

One more thing. IMO we shoud prefer qml over html for the simple apps. Having multiple webview windows running definityly will cause performance problems. Also take into account that many domain-servers are overusing web entities.

[AleziaKurdis]

Is QML limited compare to what HTML can do? That would explain why the create app is a painful mix of both.

[vegaslon]

QML is more powerful as far as linking into the c++ since it can use more functions then the JavaScript api. I think the layout elements are more limited then using css though.

[AleziaKurdis]

I wonder how the places app would look in qml.
For sure it seem harder to me to figure what qml can do.

[AleziaKurdis]

There are also other alternative... like not use a 2d window at all... It seems to break the brain of many people to envision 3d ui ;-)

[Zetaphor]

I want to revisit this conversation again since it's been a few days.

Are we proposing this for the system apps, or for any simple app?

I personally would prefer we move away from QML for everything except the "core" apps, and even consider rewriting those in standard HTML. I believe this would have the following advantages:

• Ecosystem uniformity - Seeing how the frontend is built with HTML/JS will help new users to better understand the platform internals. It also means it's easier to have a consistent visual style since HTML/CSS interfaces are more flexible and in my opinion generally look better.

• Security - QML apps can only be used if they're in a whitelisted system directory because of the aforementioned levels of C++ access they offer.

• Opportunities to improve the script engine - Going from the previous point, if we find that certain functionalities cannot be created today in an HTML interface, then I would argue this is an opportunity to explore creating a binding to the scripting engine so that we can maintain consistent interface practices and enable users to develop their own personalized interfaces.

• Simpler documentation/implementation surface area - Supporting both QML and HTML means we'd have two different classes of application development, and thus best practices. This would require supporting templates and documentation for both implementation methods if the intent is to allow for new apps to be submitted for inclusion into the core apps rather than only the community repo.

[AleziaKurdis]

Library folder for common resources for apps...

The way I see it, there is like 3 kinds of applications:

So I would prefer a good predefined standard over already existing css that we try to share... to have tried to work with the soup that High Fidelity did in the interface folders, it's more a mess than a help. (That said, maybe you have a different approach for shared resources.
But having most of the app on the community-app repository, I think it would help to not have such big mess. Also the app repository is independent from the release. It's flexible.
I might be willing to have a common fonts folder in the community app repository, but maybe not for other things.

There is already some rule for that app repository. We try to not include anything having a dependency on a third party server.

I think there are many app/script that are in interface script folder that should be moved to the community-app repository (More App). It would help to de-complexified a bit.

Consistency between HTML and QML ...
Clearly, since Vircadia and now with Overte, the intention is to stop developing additional UI based on QML.
HTLM/CSS /Javascript is definitely do a good job, it's flexible and a lot of poeple know this compared to QML.

I'm personally very pro HTLM/CSS /Javascript.
I think it is shared with many people. Frameworks stuff like Vue or other kind of mega library to cut a hair in 4 pieces is overkill for small project like apps. (how to make a 40 kb app weights 10 mb... use Vue!) it's a bit absurd and very few people in the population are use to that)

Other points:

• Using jquery, only if necessary. Most of the time it is not.
• Watch out to licenses if components are used.

Typescript: Ok for what is in the script folder. For the apps repository, optional.
(I just don't know at this point if I would like to use typescript.... should we compile this like the C++. (if yes, It might turn me a bit off.))

[Zetaphor]

The way I see it, there is like 3 kinds of applications:

I think the idea of having an uninstall button is great, that should be a feature on every app, even if it's hidden behind a few clicks. I was already considering building a form of app manager because I don't want to keep everything installed but I wanted it available in less clicks than opening more, clicking load more, filtering/scrolling, then clicking install. This will become more of an issue as the number of available apps grows.

I'm personally very pro HTLM/CSS /Javascript.

Agreed, I think we should be prioritizing developer accessibility as that makes it simpler to onboard people into the ecosystem. Because the API's are exposed over Javascript both alizard and I were able to jump in and start building apps on our first day here. A shorter on-ramp for developers means more/better content, which means better end user experiences.

There is already some rule for that app repository. We try to not include anything having a dependency on a third party server.

Please see my comment on another post above where I suggest bundling third party libraries and assets that are commonly used. A good example would be cash.js. jQuery is definitely overkill, but it's syntax does make a lot of complex DOM manipulations simpler which is why people still reach for it over vanilla JS.

Typescript: Ok for what is in the script folder. For the apps repository, optional.

I have mixed feelings about this. I like Typescript and what it enables for larger projects, but making it the default seems like overkill. Touching back on the point of developer accessibility, I believe prioritizing the path of least developer resistance should be the primary goal. I wouldn't be against some form of first party support for Typescript, but vanilla JS should always remain an option.

[AleziaKurdis]

Last week by moving the "Appreciate" app outside interface, I found that High Fidelity had another way to build apps using:
var AppUI = Script.require('appUi');

It can simplify some things.
But I add to read their library to figure how it works... basically, it do what my template do, but centralized.
Is this a good approach ? I don't know... To me, it just make thing less easy to understand. (Thing that you need to know anyway to not do a disfunctional thing)

[Zetaphor]

Can you please elaborate on how this works? I'm still relatively new so I don't understand what this may imply. What exactly is this importing?

I think that would be a great idea as I mentioned in other comments, having the ability to just include commonly used assets, but it would all need to be heavily documented. I'd love to see a proper update to the documentation that includes the conclusions we reach here on best practices app development along with a breakdown of a well designed starter app template (yours is excellent!).

[AleziaKurdis]

Basicall the app use the script "'appUi.js" that you can find in scripts/system
This script already have many of the mecanism to operate the app.
so it might simplify the code of your app. (but also make it a lot less intuitive to understand by unexprimented people.
The negative point about this is when you want to do thing that is outside the basic application mecanism, you have anyway to learn how thing are working, but on 2 separated files. Some people might like this. (I don't know)

[Armored-Dragon]

Frameworks stuff like Vue or other kind of mega library to cut a hair in 4 pieces is overkill for small project like apps.

I 100% agree. I would prefer we try and steer away from using libs or tools like jQuery, Vue, or any other similar app. I know I'm speaking from someone who has a long history with webdev, but libs like this are just not necessary.

Most examples of what I can find in the existing library of Overte apps just use jQuery for element selection. Node selectors on the webpage can be easily and effortlessly done with document.querySelector(). I usually build a helper function to just quickly get the element I want.
There was also this example I found from this pull that I thought was ridiculous.

[Zetaphor]

I agree we don't need jQuery, but I'd still like to see some support for a modern alternative like Cash.js. It can be genuinely useful even when you're well versed in vanilla JS.

The debugger tool I'm working on right now mostly relies on vanilla functions, but then I use the jQuery syntax provided by Cash.js for more complex DOM manipulation. Here's a contrived example:

$(.debug-info').hide() which is a lot simpler and easier to read than the vanilla alternative:

const debugElements = document.querySelectorAll(".debug-info");
debugElements.forEach(element => {
    element.style.display = "none";
});

I usually build a helper function to just quickly get the element I want.

This is what libraries like this bring to the table, we don't all need to reimplement our own helper functions to reduce the boilerplate of the most common operations.

[Armored-Dragon]

That's a fair point.
As long as we only have a single instance of something like cash.js all scripts can import as a lib, I suppose I could sleep at night.

[Zetaphor]

That's what I'd like to see, no point making an extra network request for something that's likely going to be heavily used. Same with any standardized CSS we devise here

[AleziaKurdis]

Please see my comment on another post above where I suggest bundling third party libraries and assets that are commonly used. A good example would be cash.js. jQuery is definitely overkill, but it's syntax does make a lot of complex DOM manipulations simpler which is why people still reach for it over vanilla JS.

If they are stored on our servers (as what is in the community-app repository) it would be fine. What we don't want ( I think) is using such file but stored on any server that we don't have control on it. (ex: fetch jquery or fonts directly at google)
Or any app using a service running on a private server that can be out of our control.
That said, in some app, we might be tempted to do exception... like for an avatar provider like ReadyPlayer.me. If one day they shutdown, we it's not very complicated to remove those app.

[Zetaphor]

What about bundling this with the client? Why have a network request at all?

[vegaslon]

I imagine they stopped putting everything on the client to cut down on download size, high fidelity used to update the client a lot since it was to them still in alpha

[AleziaKurdis]

Reasons are multiples... size, release independance, we could also have many different approach of a same tool. so people could choose the app they want. it was making less sense to have all that deployed with the product. For exemple, if someone build an alternate version of an editor it could be made available on the repository, instead to pack 2 editor with the product.
It was starting to be fat, and appealed to grow a lot. Why have averthing install if a user is going to use only a fraction of all that. (if you think longterm)
By the way the network request is just to read the script once. Like any other scripts in the world that you are visiting.
Of course it can be down. This is why the official and fundementals app need to be in the installation.

[Zetaphor]

I'd love to see us take some next steps on this. There are currently multiple topics in motion so I'm going to attempt to narrow things down and propose some action items and followups on areas I'm seeing some consensus:

Styling/Layout

It looks like there's an open conversation about fonts and accessibility. I like the suggestion of a system level option that signals to app developers that an accessibility-first font like OpenDyslexic should be used instead of Fira Sans. Accessibility should definitely be included in whatever design language guidelines we end up producing.

It looks like we have a great start on the CSS and app template if we were to combine @Armored-Dragon's CSS with @AleziaKurdis's app template. Maybe we could spin up a repo that combines these two? If you're both okay with that and don't beat me to it I can start something.

Script Organization

Both Alezia and @keeshii raise some good points about the organization of script files and directories. I also agree that the current included scripts directory could use some additional organization, as well as documentation. I believe it would be ideal to include either a small readme file or an inline comment that explains the purpose and functionality of each script.

We could also consider exploring moving some of the included scripts to the overte/overte-content repo.

My personal opinion is that the scripts folder shouldn't contain more than what is required for the system level applications, and then maybe some documentation on where to find additional content (I didn't know the overte-content repo existed until Vegas showed me).

Bundling scripts

Alezia makes some good arguments against bundling third party libraries, and I agree. Something I also didn't consider in that original thought was how this would affect the licensing of the platform.

Thanks to everyone who has contributed to the conversation so far, I'm looking forward to getting additional feedback so we can begin making strides towards implementing some of these changes.