Yes, but Google is exceptionally good at fragmentation and confusion in regards to products. How many gmail apps do they have? Inbox, gmail, android mail (though this got deprecated), web interface, etc. Youtube now has 2 apps, a web interface.
They seem to like to make new stuff, rather then upgrade their existing stuff. Then every second year they just go through their stack and deprecate 30% of it.
> Inbox, gmail, android mail (though this got deprecated)
Don't forget the cleanest, best-performing one: the classic "Basic HTML" interface. Which manages to be much faster for most operations than Inbox or the AJAXified normal version despited having to reload the whole page.
You just have to love that classic approach to web development, right?
JavaScript is great for improving the user experience, but it's often vastly overused and just makes me scream for simpler times such as the classic web app.
I'm increasingly convinced that much better solutions to most of the problems Javascript and AJAX solve ("solve") would have been better frames and improved HTML forms.
Exactly! I use Bootstrap for the auto-scaling to the device, and AlpacaJS for the dynamically generated and adjustable forms... but that's it. That's all I want from JS: form management and validation, and responsive design (and I believe the latter is done in pure CSS anyway?)
YouTube Creator Studio of course is a different app for managing your channel - which is great - I think it's a fantastic separation of concerns. One app for consuming, another for moderation/management.
But then yes, you've got:
* YouTube (proper)
* YouTube Kids
* YouTube Music
* YouTube Gaming
* YouTube GO
While I agree fragmentation can be bad, YouTube is one area where I think this makes sense. What a gamer wants in an app is going to be very different to what someone seeking educational content is going to want.
Similarly, a kids app is very useful given how many kids are growing up using cheap tablets to stream videos, and I know from watching my nephews that the way they use YouTube is very different from how I use it.
> I don't understand why a new app if this could just be an additional feature in the current app.
Its a ground-up rewrite of the app with a very different experience focus and for a different audience. It wouldn't make much sense as a feature of the existing app.
Because the UX focus is different, the assumed technical infrastructure context is different, and, well, basically everything except the backend service consumed is different. Youtube Go is more distinct in role from the core Youtube app than the other break out apps (which mostly are distinguished by content focus on UX tweaks around the focal content) like Youtube Kids, Youtube Music, and Youtube Gaming.
I guess we have to agree to disagree. I don't think adding a button or two is some fundamental change that requires 10 meetings with 2 designers and 5 developers. They're already streaming the video data, just save it to a file in addition/option to rendering it. They can already play video data, just play it from the file instead of streaming it.
There's probably a lot more changes than you realize. I can only assume given your comments you've never worked on problems like this. There's so many benefits you can get from writing an app specifically for low-end Android devices with poor data connectivity.
>There's probably a lot more changes than you realize.
Do you know what those are or did you just assume that because its Google and so "there must be reason"?
> I can only assume given your comments you've never worked on problems like this.
You may assume it. The alternative explanation is I don't think its all that hard because its not all that hard.
> There's so many benefits you can get from writing an app specifically for low-end Android devices with poor data connectivity.
IMO, all that should be part of the base app. If your app can't handle different workloads (especially as basic as intermittent network connectivity for a video streaming application), its pretty much a huge design fail there.
I get the impression you haven't tried to refactor a large code base to change core functionality before. Any system architecture is built with, inevitably, certain assumptions on how the data is going to come through the app and where it's going to come from. Something as low-level as the source of video files in an app that is no doubt optimized for that is undoubtedly a fundamental change, and one that is going to be easier to fork and rewrite than try to shoehorn into existing code.
Your impression notwithstanding, the fact is that dozens of applications already exist that can play network streams, play files from your hdd, and even record streams to your hard disk (VLC for one), means that its a known solved problem. If, as you say, a video streaming app, at its core, cannot handle something so basic as saving the stream to disk, or playing the video from disk, then I would count that as a major design failure.
Also I don't get where the "undoubtedly", "fundamental change", "going to be easier to X" comes from. What is your basis for those statements?
In my opinion, default offline vs default online is a HUGE architectural difference. You could probably try to hack it into the existing player, but it wouldn't work well.
A ground-up rewrite wouldn't surprise me at all for such a change.
From the screenshots, it looks to be trivial functionality that could be baked into the existing app. Besides the ability to download and play files is not something I consider to be a "HUGE" architectural change.
It’s a step in the right direction supporting offline first, encouraging to see this.
But I’m also a little disappointed it’s a separate app, and country specific from what I can determine. It would be great to see this rolled into the current app without restriction.
IMO, that's because YouTube Go is an app with experimental features. They're not sure whether these features make complete sense for adding all of them blindly to YouTube app itself.
