Android platform support

Apple platform support

Web platform support

Misc libraries

https://github.com/material-motion/indefinite-observable-swift

Should the original value be passed along, or should nothing be passed along? Should this be configurable?

Goal is to show how to build a fairly complex transition using a good amount of material motion. This will be targeted towards those with a decent amount of L2 knowledge already.

For example, we still link to specifications/serialization.html, specifications/runtime/scheduler.html, specifications/TweenBetween.html etc

I think the new radio button tool is breaking inline code annotations (e.g. pan$):

https://material-motion.github.io/material-motion/starmap/specifications/streams/operators/

https://material-motion.github.io/material-motion/documentation/L4/IndefiniteObservable

IndefiniteObservable

1. Introduction
2. Operators
3. makeOperator

Advanced topics

1. Producers and Sources: Connecting to existing event systems
2. Multicasting

People acquire knowledge through a variety of mediums including text, video, person-to-person, and teacher-to-person. We'll want to ensure that we cover at least these four mediums over time.

Prioritization

Phase 1: Text-based tutorials.

Phase 2: Video tutorials.

Phase 3: Classes and meetups.

Minimal content required for each medium

• Getting started with Material Motion on
• Contributing to Material Motion from
• Building your first Director.
• Building your first Motion Family.
• Overview of available Motion Families and when to use what.

TODO: prototype out a timeline/composition editing UI

• X axis is the root driver stream (e.g scroll position, drag distance, drag radius, etc)

  • units dependent on presence of normalize operator applied to stream
  • caps dependent on presence of min/max

• how to represent thresholds

  • maybe a pin, where the largest one is the last one activated?
  • ranges, from the current threshold to the next clobbering one?

• scrub targets (inc other compositions/timelines) drawn as layers

  • maybe an inner composition is drawn as a perforated box, so you can see the inner layers?

• what's the relationship between compositions and stream operators?

  • if there are some scrub targets driven by a stream with min and/or max
    terminators, some driven with a normalize operator, and some driven by a
    composition, those should all be able to appear on the same timeline

  • maybe min/max/normalize operators do all the calculation of range, and
    compositions are just a convenience to group scrub targets mounted on the
    same stream?

    • then you don't even need compositions; anything mounted on the same stream
      will be in effectively the same composition.
    • collapses down to runtime.addScrubTarget
      • how would you replace the driver of a scrub target, e.g. get it to
        listen to a different stream? this would help with encapsulation/
        grouping/reusability, though that might be an eventually (rather than a
        now) concern

Android

• Move public @interface MotionState closer to the const definitions.
• Delete public Subscription subscribe()
• Keep transform in MapOperation.
• Evaluate whether static abstract class Operation should be static abstract class NextOperation.
• abstract U transform(T value) rename to abstract U project(T value).
• Make class ScopedReadable and class ScopedWritable abstract types and not subclass Operation.
• Rename operator to nextOperator.
• Deprecate write operator.
• Move _nextOperator next value in callback to end.

JavaScript

• Rename project to transform.
• Test that MotionObservable subscribe method supports just a next function.
• Should Operation be NextOperation?

Swift

• Try ExtendableMotionObservable.T for disambig
• Make public class MotionObservable final.
• Can we make final class MotionObserver private?
• Typedef block types across all the things. Look at Java names as reference.
• Move _nextOperator next value in callback to end.
• make public class ScopedProperty final.

https://material-motion.github.io/material-motion/team/essentials/testing/javascript

I believe we now have a recommended testing solution for javascript. Let's update our team docs accordingly.

https://material-motion.gitbooks.io/material-motion-team/content/random.html
https://material-motion.gitbooks.io/material-motion-team/content/CONTRIBUTING.html

vs

https://material-motion.github.io/material-motion/team/random
https://material-motion.github.io/material-motion/team/CONTRIBUTING

Was this intentional, or should I paste the markdown in from GitBook?

From https://material-motion\.gitbooks\.io/material-motion-(starmap|team)/content(.*)
To https://material-motion.github.io/material-motion/$1$2

https://github.com/material-motion/indefinite-observable-android

The current gh-pages site is a bit undiscoverable unless you possess a link; material-motion.github.io 404s.

Potential solutions:

• Rename this repo to material-motion.github.io
• Create a new repo called material-motion.github.io with a single file: a simple HTML doc that redirects to material-motion.github.io/material-motion/, either via a <meta refresh /> tag, or a JS snippet
• File a bug with GitHub requesting the ability to set which repo controls the home page.

GitBook inserted a bunch of needless \s in our MD files. Let's find/replace them away!

https://github.com/material-motion/indefinite-observable-js

For example, we have life_of_a_plan.md and Performer-composition.md which are not consistent.

Will use this thread to jot down ideas for how the L2 content should look.

Recall that someone with an L2 understanding is creating their own Directors using Material Motion plans. This person is not creating custom plans yet.

Things that should be easily accessible:

• The language of motion with simple examples of their use. Likely hierarchically organized.
• How to add a plan to a project (e.g. pod 'MaterialMotionPop' to get SpringTo and PauseSpring).
• Links to the plan's documentation.
• Examples of Director implementations.

For example, team/roadmaps/directors.md

There is a large amount of documentation we need to write as a team that will be pretty similar across platforms.

I see two ways in which we can structure this common documentation:

1. each platform has its own document written specifically for that platform, or
2. one document, with in-line platform switching for code segments.

I think that we can do 2. by tagging platform-specific content in such a way that our website can filter out irrelevant content. E.g. there might be a platform picker that shows all elements tagged with that platform. This is similar to how the Milemarker website is designed. It's simple and works decently well.