rvdleun / aframe-presentation-component Goto Github PK

Goal
Add swipe navigation

Description
At the moment, the only way to move through the slides is by pressing left or right on the keyboard. For touch devices, there should be support to move back and forth by swiping to the left and right.

Deliverables

• Add support for swiping left or right in the presentation component to navigate through the slides.
• Add option in the schema to turn this feature on or off.

To make things as easy to understand and readable, I've wrapped all the components into primitives. However, the original setup I had was that the developer would need to attach a slide-action to every slide. Because the slide component fires off the events on itself as well, this is still possible.

So, for example, the cameras example can also be rewritten from...

      <a-presentation>
        <a-slide>
          <a-slide-camera position="0 3 0"></a-slide-camera>
        </a-slide>
        <a-slide>
          <a-slide-camera position="6 3 0"></a-slide-camera>
        </a-slide>
        <a-slide>
          <a-slide-camera position="12 3 0"></a-slide-camera>
        </a-slide>
        <a-slide>
          <a-slide-camera position="6 3 0" rotation="0 -180 0" duration="2500"></a-slide-camera>
        </a-slide>
      </a-presentation>

to...

    <a-presentation>
        <a-slide slide-camera position="0 3 0"></a-slide>
        <a-slide slide-camera position="6 3 0"></a-slide>
        <a-slide slide-camera position="12 3 0"></a-slide>
        <a-slide slide-camera="duration: 2500" position="6 3 0" rotation="0 -180 0"></a-slide>
    </a-presentation>

To keep the documentation as concise as possible, I'm only using the first example. Do you think that the second approach could also be interesting to have in the documentation?

My goal is to make this toolkit as modular as possible, so that it could be used for multiple projects. At the moment, there are some things hardcoded in the presentation component, like...

• Hash tags for navigation
• Using keyboard shortcuts to move back and forth
• The progress bar

... and I'm wondering if it could be interesting to move these functionality into separate components instead. This way, it would be interesting to add more modular features to a presentation when needed.

With this in mind, this would mean that the following would change from...

<a-presentation progress-bar="true" shortcuts="true" useHash="true">
  <a-slide></a-slide>
  <a-slide></a-slide>
  <a-slide></a-slide>
</a-presentation>

to...

<a-presentation>
  <a-presentation-progress-bar></a-presentation-progress-bar>
  <a-presentation-shortcuts></a-presentation-shortcuts>
  <a-presentation-use-hash></a-presentation-use-hash>
  
  <a-slide></a-slide>
  <a-slide></a-slide>
  <a-slide></a-slide>
</a-presentation>

While I think this would be a neat thing to do to make it easier to add features, I'm also afraid that it can unnecessarily complicate things. Plus, it also means that these features will need to be added manually instead of being activated by default, which I think is great for newcomers.

Goal
Add support to set an aspect ratio

Description
To make sure that the slides can work on any device, there should be an option force a certain aspect ratio. If the user is on a device that has a different width / height(or the user is using a different orientation, like portrait when the aspect ratio is 16:9), then a method should be used to ensure that the user can still see the relevant parts of the environment.

I will admit that I'm not certain yet what the best approach here is. My gut feeling is either with the FOV of the camera, zooming in or out, or by changing the canvas' size (and adding black bars or something).

It might also help to have a debug mode where the developer can see via borders what part of the screen will always be viewable.

Deliverables

• Add an aspect ratio attribute to the presentation component where the user can set a custom width / height(16:9, 4:3), or disable it altogether.
• (optional) Add a debug attribute to let the developer see what part of the screen will always be seen.

issue: using aspect-ratio property prevents inspector from displaying anything when loaded
workaround: don't use this property when you need to use the inspector

issue: when using aspect-ratio property and resizing a canvas to be larger, the scene is pixelated (the rendering dimensions of the resized canvas don't seem to adjust)
workarounds: reload the page after resizing canvas, or just don't use this property