Chrome OS Files app changing again to better integrate local, Android and Linux files
Google recently added both Android and Linux files to the native Chrome OS Files app but don’t get used to it if you have this feature. Looks like it’s changing again. Chrome Story noticed a code commit describing the redesign (or is it a re-redesign?) which will move local files higher in the application. Yes, Google Drive is getting moved down from the top spot.
Here’s a snippet of what the developers are working on:
“Add EntryList which implements interface FilesAppEntry to represent a list of entries. This will be used to implement “My Files” which will contain a list of VolumeEntry for the volumes: Downloads, Linux Files (Crostini) and Play Files (ARC++).”
And here’s they envision from a design standpoint, with this example showing the current and new look.
Since this design is still in development, it’s very possible that it changes before hitting the Stable Channel of Chrome OS. But I’m hoping it doesn’t, personally. As I continue to use Linux apps more and more on my Pixelbook, I like the idea of those files being treated more like a first-class citizen in the Files app.
What I see here doesn’t necessarily downplay Google Drive. It just places it next to where other cloud drives would be if the user has mounted other cloud drives. To me, it looks much more like an attempt to make the placement and grouping of drives more consistent, rational, and therefore predictable. Though it does suggest Google’s transparency about backing down from its original concept of CrBk usage, which was that they should nearly exclusively be Web client devices exclusively. Ever since they discovered containers, that boat has long ago sailed.
Is this just a reordering of a list of directories or is something further happening here? Google seemed to think people naturally lived in the cloud and evidently never thought it had any responsibility to protect local files i.e. in the “Downloads” directory. Maybe, that is changing. Syncing local files to a local network or device perhaps?
The hostility of Google’s “recovery procedure” – only ever invoked after a device failure – to local files has always been troubling to me. Blowing away stored user information – it certainly prevents access by unwarranted individuals to private data because it destroys that data – doesn’t cut it as sound security practice. It destroys the thing that it is meant to protect. Google could and should do more to protect and recover locally stored files and private materials where possible. I hope that Google is taking a step in that direction.