While getting my brand new Chromebook up and running, I began to ask myself the typical questions. Mainly, I wanted to know what the capabilities of the machine were. I wanted to know where to find the productivity software, games and files.
Productivity software lives as extensions of the Chrome browser, and I've already discovered many of my preferences in that regard, so I was well set.
Games are spread across two separate ecosystems within Google's larger structure. Some of the games live as Chrome extensions and the rest live as Android apps.
Files were a bit more of a mystery to solve. There is no explorer interface built into the basic computing experience. File browsing is a separate activity with a dedicated application to handle it. This isn't necessarily a bad thing, but it is fairly far removed from the Windows experience. ChromeOS views the computer as a web-first machine. Windows views the computer as a files-first machine. There are a lot of logical reasons for this difference, but the upshot is a difficulty in my learned behavior. I tend to think about computers as file systems which have tools built atop them. ChromeOS feels more like thinking of computers as mechanical UI components. There really isn't any focus on file systems or the underlying architecture supporting my on-screen activities.
I have a lot of thoughts about this difference. I can see some benefit in both. I don't think just because the Windows way is the old way, it is necessarily bad. I understand the idea behind an experience-first UI. It is sensible in its own right. However, a files-first UI is pragmatic. After all, the experiences offered by a computer are all ultimately file dependent. Either way, I decided to simply accept the ChromeOS approach and see where it took me.
It took me nowhere, really. ChromeOS seems to pretend files don't exist, so I pretended right alongside it. For the most part, this worked. All of the basic and native experiences offered by the Chromebook are uninterrupted by the relative lack of file interaction. I can name documents and I can even save them locally, if I so choose. There is no real indication of where I have saved them locally and no effort to present an accessible container where I can locate these local files.
In many ways this is beginning to elucidate Google's approach to storage and particularly external storage sources like Flash drives and memory cards. Some people have posited that Google doesn't want to become encumbered with concerns over the relative value of external storage sources. Which is to say, some memory cards work better than others, but Google can't police what you put into your phone. I think there is validity to this suspicion, but I think the approach goes much deeper than this. ChromeOS wants me to ignore files and storage altogether. It gives no place for me to worry about whether I need to upgrade my USB drive or insert a better memory card. The impact of these decision is opaque in the user experience.
I think there is some brilliance in this approach. In terms of differentiation, not needing to worry about whether or not I have the space to accomplish a task feels freeing. It is an interesting vision of the computing experience. Perhaps a less distracted version of interaction. I like the idea. However, practically speaking, it doesn't completely work. I do still run out of space. I do still need to find my files. I need to, because I still want to do things differently.
Strictly in terms of my experience as a writer, learning to operate in the way ChromeOS is asking me to is probably beneficial. Stop worry about where my files are and how to manage them. Focus instead on the project I am working on. Chrome will make sure the files I need are at my fingertips when I need them. I have yet to encounter a circumstance where this version of computing isn't working as intended with ChromeOS. I haven't encountered a lot of circumstances yet, so I can't judge ChromeOS on things I don't know.
Google Drive makes my writing platform agnostic in a compelling way. It is a first party experience on the Chromebook and it is easily available everywhere else I do any computing.
Outside of writing I ran into some walls fairly quickly, though. For instance, I have a series of video files I've captured from a project I worked on. I haven't finalized the files yet, because I want to review the video conversion to ensure there are no obvious flaws or defects due to compression or trimming. I don't want to add these files to my server until they are finished, but I need to be able to watch them in order to finish them. I wanted to toss them onto my Chromebook so I would be able to review the files wherever I might happen to be that I could find some time to watch.
Chromebooks have a file browser built in. It isn't the main thrust of the operating system, but this video project is the type of project which demands an interface like that. Which is to say, I won't simply plug the files into my Plex server, where they don't really belong. They have to properly finished, named and categorized before I would feel comfortable doing what I would think of as "publishing" them to my server. My media server is no testing ground. I don't currently have a second server, though this is potentially a work-around I could use by setting up a testing server where I can share unfinished files for review. It's not a bad idea either, but it isn't something I am ready to commit to yet. Therefore it isn't relevant to this project. This leaves me with the basic and familiar file handling approach to the need. And this is something ChromeOS doesn't excel at.
Opening the file browser is straightforward. It shows a simple interface which displays my Google Drive, local downloads and SD card. Perfect. If I insert a USB drive, it shows up immediately in the window. Now that I know I can use a USB device to transport files, I know I will be able to transfer my videos for review, so I know the issue is addressed. However, using a USB device isn't the ideal method. If possible, I'd like to simply access my file server directly and copy the files to my SD card. Accessing a networked file system is something even Windows has struggled with in different versions. Not any more, of course. File sharing in Windows 10 is as simple and straightforward as I can think it should be. Simply create a homegroup, share folders to it, join it and you're set. I don't know how it could be easier without sacrificing any sense of security.
So, does ChromeOS replicate this ease of use? Not natively. Not at all, actually. There is no method built into the file browser to explore a network or a file system. The ChromeOS file browser shows only the locations it thinks are accessible file storage devices. These entities can be explored, but new entities cannot be discovered. I decided to Google the problem and immediately discovered Google had addressed this shortcoming. It is not native to ChromeOS, but a Chrome app called "Network File Sharing for ChromeOS" has been provided to support my need. Wonderful. I installed this app, connected to the samba server share for my video project drive, selected the files I wanted to review, copied them, selected my SD card and pasted the files. All was exactly as simple as I had hoped.
The problem is, the file copy procedure was painfully slow. Then it stalled and cancelled itself. Annoyed, I tried again, but with a single file. This time it worked as expected. I continued, copying files one at a time with success. I think this is an odd limitation, but I can work with it if needed. Then some files refused to copy at all. Then the shares reported as disconnected. I couldn't get them to reconnect. I turned the Chromebook off and then back on and the shares reconnected. I tried copying a file again. The share immediately disconnected.
Now, I hesitate to say this is the fault of ChromeOS. I've only set these shares up for a Windows to Windows transfer, so there may be issues with the way the directories are shared that have been invisible to me because Windows is working so hard to make everything easy. It may be that ChromeOS is perfectly capable of communicating with network shares in exactly the way I am expecting. I haven't seen it yet, but I am not discounting it.
The problem I see here is that Windows is files-first. Everything about the interface is offering me tools to dig into problems like these, should they arise. ChromeOS is not concerned with files. There is a way to access files, but nothing else. It is presuming the heavy lifting will be done elsewhere. Strictly in terms of my Chromebook experience, I feel completely powerless to address the problems I am having with the network shares. I opted to copy the files via USB drive. That worked perfectly and that is the extent of what I can do with my Chromebook.
On the other hand, the server is running Windows. So, Windows is the ideal interface for solving what I might presume are Windows problems. This could run no deeper than two ostensibly competitive operating systems not working very hard to support each other. But in this paradigm, Google is asking me to use their ecosystem exclusively. So, where is my alternative to a 15TB file server in the Google ecosystem? It is Google Drive, and a very expensive monthly fee ($199.99/month works out to $2399.88/year). If that's where I am supposed to go with the problem, then Windows is suddenly no longer the more expensive option. Running my own home server is vastly cheaper than paying Google for the privilege (My file server costs average out to about $400/year). Therefore, I still think the onus is on Google to find a better way to deal with problems like these. Providing me a cheap computer is great. I am interested in it because I don't have money. I'd just like to see the proposition stay inexpensive.
No comments:
Post a Comment