Mobile Swipe

[normakster]

On android, S8, scale is too small to be useful. I suggest using CSS to swipe between menus/panels/components.

[mrharpo]

What would the interaction / flow / experience look like?
e.g:
/ <--> /projects <--> /timeline

How should we visually present this functionality? Would these be selectable tabs as well? Would they be visible at the top/bottom? Are they hideable or constantly visible? Would these replace the current menu navigation, or exist side by side with it?

To clarify, the swiping capability would be a js function, provided through some library like https://hammerjs.github.io/ and the visual affordance of how we present the functionality is achieved through css.

We will also need to store the url arguments for these tabs somewhere. If you navigate to /timeline?edl=test.csv and swipe away, the returning swipe needs to know where to return.

I could see this being an entire component, that can generate and store a session of tabs.

Thoughts?

[normakster]

Problem to solve:

• On mobile, the GUI lacks the real-estate to display everything that a desktop version can.

Assumptions:

• The user, if using Alfred on mobile with the intending to field edit video, will know the standard mobile interaction points (swipe, long hold, double-tap, etc.).
• Per convo., the affordance icons need to be attached to a top banner and when clicked the respective panel will slide in from L|R.
• If very detailed editing needs to occurs, a user can open the project on desktop.

Suggestion:

I suggest breaking Alfred into three distinct panels or "views":

1. Project panel
   • Just shows the .edl contents.
2. Monitor panel
   • Monitor
   • Tools
   • Progress bar
3. Timeline
   • timeline
   • progress bar
   • scale bar

• Each view will be display:none when not in use.
• Engage hammer.js (per suggestion) to enable touch.

Final thoughts:

• we need to make Alfred "mobile first" since a large majority of use-cases revolve around field/mobile use.

[mrharpo]

I like your suggestions, but am unsure about your assumptions.

The user, if using Alfred on mobile with the intending to field edit video, will know the standard mobile interaction points (swipe, long hold, double-tap, etc.).

We need to create the mappings from action to function so all functions can be accessed from all platforms and available inputs (keyboard, touch, swipe, etc)

Per convo., the affordance icons need to be attached to a top banner and when clicked the respective panel will slide in from L|R.

Part of the problem is we have a number of different potential windows (components) we might need to access. A partial list includes:

• Project - text view of this project
• Projects - list of all projects available
• Timeline - drag/resort clip view, where clips are sized proportionately to the clip duration and stacked end to end (and reflowed if necessary).
• Bin - a list of available media for a project. This will need to be able to drag and drop media onto the Timeline component, so both will need to be visible simultaneously, or another action path will need to be established.
• Renders - a list of projects currently rendering

How should we make these views available? Side pull out? Toggleable button?
Can we have more than one open at a time? How many can we have open at a time?
What happens when things overlap? Will they resize other components that are open, or will they overlay on top of each other?

If very detailed editing needs to occurs, a user can open the project on desktop.

This sounds like it could be restated as:

Very detailed editing can not occur on mobile. Use desktop.

Obviously, we want to be capable of working effectively anywhere, even on small devices. Specifically, the scale bar allows clients to work at any size resolution (scale = pixels / second) that fits their environment.

---

In the spirit of mobile first I would be ok with establishing a default Monitor view, with toolbar and slider as outlined above, then selectable panels available somehow. We will need to work out a consistent navigation experience, and define some other possible panels we might need.

The flipside of mobile first is in trying to keep our options as expandable as possible for larger screens, where real estate is not an issue. Here, everything should be as customizable as possible, because no two setups will be the same, even for the same user in different environments.