Designing a Timeline for Mobile Video Editing(img.ly)
img.ly
Designing a Timeline for Mobile Video Editing
https://img.ly/blog/designing-a-timeline-for-mobile-video-editing/
15 comments
Quick Questions out of curiosity: What ideas have been rejected during the design process?
There were a ton of different design variations! The differences were mostly in the details. The main requirement was to build a video editor that does everything that a video editor does, but as well as possible. And because this editor is designed to work within third-party apps that license the SDK, we wanted it to be well-designed but neutral, as easy to use as possible.
One example of a rejected idea: We had played around with the idea of collapsing and expanding the clips when you scroll vertically in the timeline, like an accordion, but it turned out that traditional vertical iOS-native scrolling felt better.
Overall, I love it! I tried to import an MP3 from OneDrive into the video editor; it showed that it imported, but on playback, there was no sound. However, I could clearly hear the sound in the import preview window. Then, I tried replacing it with a sound already included, and then replacing it back with my MP3 to see if that would work, but the app crashed.
Thanks for sharing! We will have a look and try to reproduce the issue you’re seeing.
I have not used this video editor. Are there specific UI innovations over other mobile videos editors like CapCut?
Great question! The most important difference is probably that this is an SDK, which means that it can be built into all kinds of apps by other companies that want to offer video functionality.
There is a demo app on the iOS app store, check out the link in the article if you want to give it a spin!
There is a demo app on the iOS app store, check out the link in the article if you want to give it a spin!
Great insight for everyone who wants to design more complex UIs.
Wish I knew some of these takeaways before I had to come up with a mobile timeline concept myself — nice article!
By the way, the Samsung gallery has a nice video editor with a timeline built in.
The phone form factor is yelling something at us and UX designers just can’t hear it.
Hint: We don’t spend our days scrolling horizontally
Hint: We don’t spend our days scrolling horizontally
Valid point! I agree in general. For timelines though, I believe that most people expect timeline user interfaces to be horizontal. Vertical scrolling may be more comfortable, but it clashes with existing mental models for video editing.
You’re right, it may be worth exploring a vertical timeline though, especially for more experimental video editing concepts! It would definitely be possible to implement with the IMG.LY SDK.
You’re right, it may be worth exploring a vertical timeline though, especially for more experimental video editing concepts! It would definitely be possible to implement with the IMG.LY SDK.
I’m curious why they chose SwiftUI. In my experience, this kind of highly responsive editor UIs are best implemented using immediate mode GUI techniques. A declarative layer like SwiftUI or React is often a hindrance.
The article alludes to these issues:
”All these gestures must behave as expected and not interfere with each other. We found it unexpectedly difficult to fine-tune and harmonize these interactions with pure SwiftUI, so we used some proven legacy iOS techniques to get it right.”
The use of the word “legacy” kind of sounds like they went with SwiftUI simply because it’s the newest thing rather than through an evaluation of implementation strategies…
The article alludes to these issues:
”All these gestures must behave as expected and not interfere with each other. We found it unexpectedly difficult to fine-tune and harmonize these interactions with pure SwiftUI, so we used some proven legacy iOS techniques to get it right.”
The use of the word “legacy” kind of sounds like they went with SwiftUI simply because it’s the newest thing rather than through an evaluation of implementation strategies…
> they went with SwiftUI simply because it’s the newest thing rather than through an evaluation of implementation strategies
Not that it applies to this project, but in my experience, this is one of the plagues of the lower-paid engineering team.
On the books it looks like the company is saving money by hiring on the low end of the salary scale. In practice the budget is spent inching away at minor upgrades, while enthusiastically adopting new techs for experimentation and resume-padding purposes.
Not that it applies to this project, but in my experience, this is one of the plagues of the lower-paid engineering team.
On the books it looks like the company is saving money by hiring on the low end of the salary scale. In practice the budget is spent inching away at minor upgrades, while enthusiastically adopting new techs for experimentation and resume-padding purposes.
Hi! I wrote the article.
Excellent question! You are right, we definitely did not choose to implement it in SwiftUI because it’s easier than it would have been with UIKit.
Our main concern was to build a future-proof solution for our SDK customers. Apple has repeatedly made clear that they consider SwiftUI the future of UI development for their platforms.
Even though we were not able to implement the whole timeline experience without falling back to UIKit techniques, we think the result was worth the extra effort. For example, it is very flexible in terms of appearance and theming, including sizes, colors, animations, and behavior.
Excellent question! You are right, we definitely did not choose to implement it in SwiftUI because it’s easier than it would have been with UIKit.
Our main concern was to build a future-proof solution for our SDK customers. Apple has repeatedly made clear that they consider SwiftUI the future of UI development for their platforms.
Even though we were not able to implement the whole timeline experience without falling back to UIKit techniques, we think the result was worth the extra effort. For example, it is very flexible in terms of appearance and theming, including sizes, colors, animations, and behavior.
[deleted]