In recent months, while this blog has been quiet, I've been spending a lot of time exploring the quirks of Kilgray's memoQ cloud service for a group project with challenging data volumes and other factors that make me thank the gods for doum palm tea. Expanded capacity at the secure data center in Germany early this year largely eliminated intermittent response time difficulties for memoQ cloud, so that I was able to work well during the week at my office with its outstanding Internet bandwidth. On weekends, however, work was a little more difficult.
I have an excellent 4G modem which I take with me around town and on trips within Portugal, and it allows me to work nearly as well as I can in my office with its 100/30 Mbps capacity. As luck would have it, however, at the home of a friend I visit on weekends, my provider has very little signal, usually middling 3G reception on a good day. While this might be considered normal in the heart of darkest Brandenburg, it is unusual for the technologically advanced country I now live in, but so it goes.
I had been dealing with the bandwidth difficulty by downloading the server project resources and using them in a completely local project, because 8 seconds to confirm a translation segment in the server-based is really not a good thing. I must emphasize this is not the fault of the server technology used or the capacity leased by Kilgray at the data center (any more), but rather my lousy bandwidth and probably also the fact that I travel with a crappy, low-end, low-RAM, disposable Asus laptop that isn't really good for much more than clicking through PowerPoint slides in a lecture. However, it still performs adequately for my purposes working in local memoQ projects as long as I don't do anything exotic like try to open a web browser at the same time.
Or so it was until something got corrupted and memoQ displayed its new "cascading error" feature, which causes a continuous loop of modal error dialogs in every open project and requires the Windows Task Manager to shoot down the application and make my escape. Not a good thing with impending deadlines.
Fortunately I usually leave TeamViewer running on my main working machine in the office in case I want to check mail on accounts I don't have set up in the mail client of my miserable road laptop or if I need to retrieve files or other small tasks. I do occasionally perform serious application work on the office machine from a remote system, but I am not in the habit of translating that way. This time, however, it was necessary to do so, because I really did not have time to troubleshoot the problems of my local CAT tool installation.
One reason I don't like to work on the remote office computer is that the resolution of the two screens on my work desk in the office is much higher than the screen resolution of my laptop. This means that even with good glasses I squint to make out details a lot. However, by changing the screen resolution in the Windows Control Panel of my remote system and setting it to more or less the same value as my laptop's resolution, the display of the remote system becomes much more comfortable to use.
After a few minutes in my new work mode, I was regretting not doing this before. My Internet bandwidth was entirely adequate for the remote connection, with no delays perceived for screen refreshes. And the remote system, with its excellent bandwidth in the office and better hardware (faster processor, eight times as much RAM and SSD drives for storage), performed far better than my laptop working with locally installed software. I finished my work in half the time I expected to.
This should be no surprise to the many people who work in a similar way with remote access tools. I've been aware of the possibilities myself for years and shown this way of working more than a few times in demonstrations, but it is still hard sometimes to overcome the feeling that "local is better", though in this case it clearly was not.
This same method can also be useful here for work in the summer, when outdoor temperatures near 50°C can render the office environment unfit for human activity; I can retreat to the cooler rooms of the house with a laptop and still enjoy the full power of my main working machine.
Something like this might be worth considering if you travel often and miss the power of a desktop system you leave behind, or if you prefer to use such a system from various locations. There are many remote connection alternatives to TeamViewer, such as the free Chrome Remote Desktop, with which I have also had very satisfactory experiences in tests of remote input by speech recognition in many languages on Android devices, for example. Explore the possibilities.
*******
A further note on bandwidth: I spent a few days in the Algarve recently, at a location with the most miserable bandwidth I have seen in years. My 4G modem, which has performed well in many locations in the country where I live and even on travels in Spain and France, could do no better than a pokey 2G connection much of the time. Most web pages timed out with the attempt to view them. TeamViewer's screen refresh was slow - like a fade effect in a PowerPoint presentation - and the keyboard input lagged a bit, but it was still adequate for checking the status of various things on my computer back at the office.
