Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Built-in, optional UI for end-user control over animations #425

Closed
cdata opened this issue Mar 12, 2019 · 5 comments
Closed

Built-in, optional UI for end-user control over animations #425

cdata opened this issue Mar 12, 2019 · 5 comments

Comments

@cdata
Copy link
Contributor

cdata commented Mar 12, 2019

As of #421 , we will have added support for animations. @yuinchien has mocked up some excellent default UI for end-user control over what animation is currently playing. We should implement it, and ensure that it is easy for content authors to customize.

@yuinchien
Copy link
Contributor

@cdata Thanks for filing a ticket for this!

@pushmatrix
Copy link
Contributor

pushmatrix commented Mar 27, 2019

@cdata I'm curious to hear your thoughts on how customizable this viewer should be going forward. If you can change stuff like the play / pause button, should you be able to change loading progress bar (#335) & the little spinning interaction animation?

@cdata
Copy link
Contributor Author

cdata commented Mar 27, 2019

@pushmatrix our current philosophy regarding customization is that for any given built-in UI you should always have two options:

  1. Customize built-in UI styles (to the extent that it makes sense) via CSS custom properties (and someday also CSS shadow parts)
  2. Bring your own UI via Shadow DOM content projection

With Option 1, we want to make it easy to rebrand the built-in UI by customizing details like color, font face, icons and perhaps paddings, margins and font sizes in some cases.

You can see an example of Option 2 in the PR description of #322 where we added the interaction prompt you mentioned.

Option 2 is a more robust approach to customization. It allows the content author to provide complex, bespoke alternatives to the built-in UI.

We want to make sure that providing custom UI via Option 2 does not require the content author to sacrifice UI capabilities. So, we aim to expose public, imperative APIs on <model-viewer> to ensure that custom UI has at least as many capabilities as whatever our built-in UIs have. Our recent change implementing animations and corresponding public, imperative control APIs (#421) is an example of this philosophy expressing itself.

To answer your question more directly, this philosophy applies equally to the animation controls, the progress bar, and any other built-in UI in <model-viewer>.

@cdata
Copy link
Contributor Author

cdata commented Mar 27, 2019

Also, to be straight forward, our execution of this philosophy is currently quite sparse. It's a statement of what we want, not necessarily what we have. Please do file issues or give us feedback if you think we need to backfill work to live up to what I'm saying here :)

@pushmatrix
Copy link
Contributor

Thanks @cdata , that was a fantastic response. Big 👏 👏 👏 to all of you for the quality of work and ambition going into this project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants