I’ve waffled back and forth on Android thin clients over the years. At first I thought they would be the next evolution of thin clients (which, in thin clients, even an evolution is revolutionary), but after I got my hands on an Android mini-PC, I changed my tune. This was around the same time as Dell announced Project Ophelia, and my optimism for its success was pretty low.
There are two reasons for the attitude shift. First, Andriod was not made to be a desktop OS controlled by a mouse and keyboard. It was made to be run on mobile devices where the primary interface is touch, soft keyboards abound, and the concept of a mouse is non-existent. Today’s Android is defined by these walls no matter what anyone says, so to have a viable desktop solution you have to take away Android’s Androidness. That is no easy task.
The other reason is that the applications themselves are written for the same devices Android is intended to be used on. Sure, there are some oddball clients out there that have weird hardware and peripherals associated with them, but the bulk of the apps are written for the bulk of the devices–phones and tablets. Android app developers have a lot of fragmentation to deal with, too, given all the different combinations of hardware, screen sizes, and capabilities each of the devices can have.
I’ve actually swayed back towards the pro-Android thin client side of the fence lately because of the focus on making Android devices that are pretty much only designed to act as thin clients. I love the idea of managing them with regular EMM tools, though I’m not a huge fan of bundling them with specific platforms (like ViewSonic has done with Citrix XenMobile). I have two requirements that I’m trying to satisfy:
- I shouldn’t have to know that I’m using Android
- It has to work at least as well as a comparatively priced non-Android solution
Enter Ophelia, now called Wyse Cloud Connect
I once wrote that for Dell to succeed with Wyse Cloud Connect (and satisfy my two requirements), they would have to not only solve the OS issue, which is in their wheelhouse, but also find a way to deal with the application issue that I mentioned earlier. In some aspects, I think they’ve succeeded (or at least dealt with some of the issues), but the end result still isn’t what I’d like to see from an Android thin client.
First, I want to look at it from the OS perspective. Keep in mind that I’m only looking at this as an Android thin client and not as a kiosk solution or a hybrid work/play solution or anything else.
The very first thing I did was to open a browser. I checked email, it was fine, but I wanted to cut and paste in a URL that for some reason didn’t come across as a URL (I’m blaming OWA 2007 for that). I tried to select text, but nothing happened. After several tries, I remembered I was using Android, and that I bet if I hold down the button I’ll see something. Sure enough, the native text selection functionality turned on and I was able to select text. Did cut & paste work? Yes. Did it work the way a person using a desktop would expect it to work? No.
Before you say “Well, this is Android, you should just know better,” “You’d get used to that,” or something along those lines, keep in mind that even though I know this is an Android device, my brain still expected it to behave like a desktop or a traditional thin client because that’s how I was using it. I wasn’t trying to see if text selection worked one way or another, it was just a natural process baked into my brain stem to try to select text by clicking and dragging. I should have known better, but I didn’t. Imagine what user would do.
For this first release, I just don’t think Dell did enough to remove the Android from the device. I know that’s tough, but to really succeed, a lot has to go. Clicking and dragging the lock to “unlock” the device at startup? That’s awkward. That Android black bar at the bottom of the screen? Feels weird, although you need it because you have to have soft buttons for “back” because you have to navigate it like it was a tablet.
Even the mouse and keyboard didn’t work as expected. The mouse was jerky and over sensitive, especially when the CPU was working hard while launching an app, and the keyboard being bluetooth would fall asleep. When asleep, it takes a few keystrokes to wake up, by which time I’m halfway into a sentence and the first half is missing. Oh, and when the keyboard is asleep, Android thinks it’s on a tablet so it pops up a soft keyboard when needed. Fun.
I ran all of this by Dell, and they are aware that they need to make this more friendly. They have committed to creating a more desktop-like experience. Frankly, I’m sure they spent a lot of development time just getting it to this point since they, too would fall victim to the fact that this isn’t your typical mobile device.
From the application side, Dell is both suffering from the existing Android ecosystem and wrestling with their own challenges. For instance, the version of PocketCloud that comes with Cloud Connect is not the pro version, so when you try to establish a connection to a remote desktop you’re only allowed to use certain features. Additionally, you can’t use a full screen connection. You have to choose from one of three “default” resolutions, none of which are normal screen resolutions of modern monitors.
The reason for this, which is not really mentioned anywhere, is that since that’s a feature of PocketCloud Pro, and since PocketCloud Pro is an app you have to pay for through the Google Play store, Dell can’t just give it away on some of their down devices. So, if I want to create my own connections, I’m stuck with odd resolutions and a limited feature set. However, if I publish a connection from Cloud Client Manager (Dell’s EMM solution), that connection is treated as if I had PocketCloud Pro. It may not be Dell’s fault, but it is indicative of the challenge of using Android to do anything other than run on a mobile device. At least there’s a solution.
I also had a hard time getting any good performance from test RDP or PCoIP connections (I didn’t have a Citrix rig to test on at the time I did the eval). I tested connections to cloud providers and to a machine on my LAN, neither of which had results that I would want to use as a daily solution. I even tried Ericom’s AccessNow solution to see if pure HTML5 through Chrome would work better, but it didn’t. The CPU on this thing is just not powerful enough to shoulder the load all by itself.
It turns out that to receive the best possible experience, you need to use a remote desktop protocol that leverages h.264. This makes sense since the device has an h.264 decoder in it, but what about the vast majority of platforms that don’t have h.264-based protocols? The list of things that have to fall into place for this to be a viable solution continues to grow.
To recap, that list includes:
- MHL port on monitor (or, failing that, an HDMI port + a USB power source)
- A user who is aware of and OK with the fact that they are using Android with a keyboard and mouse
- A bluetooth keyboard and mouse with you at all times (plus all the cables to connect the device to the monitor and power)
- If using Pocketcloud, must have corporate deployed desktops or applications
- Must be using something with an h.264 protocol to get a good experience
What Dell got right
It’s not all doom and gloom, and while I think there is a lot of room for improvement, Dell did do some nice things. The integration with Cloud Client Manager is excellent. Using CCM, it is possible to hide the Android “desktop” from users who just need access to a few resources. The LaunchPad mode that is aimed for task workers strips the interface of anything except for what IT decides the user needs to see. That’s an important step, for sure.
Dell also came up with a way to get around another issue: the fact that apps in Google Play aren’t familiar with this new form factor. When an app is registered in Google Play, there are requirement flags that dictate what each application needs to run. This list is automatically populated with things like touchscreen, h.264 decoder, camera, processor generation, memory, etc… In many cases, this list includes things that aren’t necessary to function, but that are just assumed. For instance, the VMware View client in Google Play will not install on Cloud Connect because it fails the touchscreen validation.
Dell is currently working with Google and app developers to accommodate the new form factor, but this is no easy task. According to Dell, the developers are appreciative of the notification because their apps can be used on more platforms. That’s is a slow process, and one that will probably never be fully complete, so Dell created its own software updater for core apps like the View Client. Yes, you have to wait for Dell to update the software on their end (or create your own packages and deploy them yourself), but it’s better than having to wait for Google and the developers to change their ways.
To be honest, I can’t think of a situation today where I would recommend the use of Cloud Connect as a thin client, however Dell has assured me that they’re putting a lot of effort into making this a better overall solution. I’m concerned that they don’t have much to work with in terms of hardware, but we’ll see what they come up with in future updates before writing it off altogether. They way it integrates with Cloud Client Manager is impressive, so if they can work out the device/OS side, it could be a really great solution. Cloud Client Manager is worth a review all by itself.
For more information, El Reg did a very thorough review of the Cloud Connect a few weeks ago, and noted several of the same issues I’ve seen.