Mobilizing Google Slides – or rather, not.

I was particulary excited to see the release of the Google Sildes App for Android the other week. It timed nicely with a trial I’m running with suppling our senior sales staff with Nexus 440x330-nexus-angle110 tablets for field presentations, rather than their clunky (although modern) laptops. As our sales staff are fully ‘Google’ (we use Drive and Apps for all of their collateral, documents and email), it seemed a far more sensible choice to go for the Nexus than iPads, as each account is already there, as are the documents, chat and email.  Also, I really don’t fancy running corporate iTunes accounts.

Before the release of the Slides app, our staff were creating their presentations, then saving them locally to the Nexus from the Drive menu. This was allowing them to present the presentation from PDF format, using Quickoffice, in case their client had no wifi connection. The issue here is that all of their funky transitions and animations were now flattened into the PDF – ‘Less flashy, less cashy’ was a delightful term I’d heard bandied around. Sales pitches love an animation.

Naturally, with the Slides app, we got a bit excited over the prospect of streamlining the whole ordeal. We’d hoped the process would now be:

  1. Create presentation on Laptop in Slides, in Drive
  2. Open in app, on Nexus
  3. Save it to device
  4. Present from in the app, even if there is no wifi.
  5. Make massive sale.
  6. Have party.

So, it comes as somewhat of a surprise to discover that you cannot present in the app if you’re offline. Sure, you can create, edit and muck around with it – but present it? No way! You instead get a wonderful ‘Presentation mode is unavailable Offline’ message. No matter how many times you hammer the present button, it resists your endeavours to get it to use the local copy you just saved RIGHT THERE.

We were so surprised that we assumed we were somehow being stupid – as all the release material states you *can* present offline. We must have made a mistake, surely? So, I have a quick search for anyone else suffering this issue. Nope. No one. Lots of people announcing how awesome the app is, but no one suffering our issue. In fact, it loosk like everyone is talking about using the app… without actually using it.

In our desperation and between bouts of thumping the Nexus against our foreheads, we decided to ask someone who should know. Our Google supplier. Google expert suppliers to the rescue then, surely? Well, no. They’d also not tried it and seemed somewhat surprised when they too encountered the infuriating message. They’ve promised to get back to us as it makes as little sense to them as it does to us.

We’re continuing to hammer away, hoping that this is caused by some weird setting in the Google Apps admin panel, but as it stands, it actually looks like the biggest feature of the Google Slides App for us, is in fact, a dud.

I would say it’s a poor show but I can’t tell, as the show is offline and unavailable.






Chromeboxes – What could possibly go wrong?

  So, after a year of supporting our enterprise deployed Chromeboxes, it’s probably a good time to gaze back over the year and see what has worked and to admit what hasn’t from an Operational point of view.Samsung Chromebox It’s been a great year for us and Chrome appears to have really picked up too, with some very healthy sales figures. But is it still the right choice? What could (and possibly did) go wrong?

“What could go wrong?” is a real loaded question. After all, if I said this about Windows machines, like the Intel NUC we had considered, this would be a very different article. After all, we know what to expect with a Windows machine (better the enemy you know is a term that was bandied about) – Chrome devices, however, were a dive into the unknown, when we chose to deploy them we didn’t know of any other businesses in the UK who had done so. There have been plenty of education deployments, but nothing too ‘enterprisey’, so we literally went into it blind. We could only trial and test so much before we had to decide to take the plunge.

Eventually we decided to use the Samsung Chromebox Series 3 for our deployment – mainly as it was the only option available to us. Also, a bit of a bug-bear for us, was the switch between the black model and the white model when ordering from Google. We couldn’t dictate which ones we recieved, so the idea of a clincal looking all gloss white equipment set up was quickly dashed as we got one box of the black model and one of the white – and there was no room to switch any around. Not a deal breaker and not an issue with Chrome, but as an Enterprise supplier, Google have some work to do with their hardware provisioning.

So we deployed the Chromeboxes with a little fanfare and got our staff up and running. Initial deployment and training was easy enough – although you will always encounter the odd naysayer, these we’re quickly overshone by our Google Champions (an idea Google themselves suggested). The idea behind the champions is easy,  empower several users throughout the business early on by giving them early access to the new system. Spend time ensuring they’re up to speed and get all the help they could possibly need from your support function. Then, naturally these users will start to champion your cause for you, from within the business. After all, they’ve seen the improvements the new systems have brought and they’ve had the correct training and support to ensure they can then tell others and share their knowledge, making your job as a deployer much easier.

I’ll write another article soon about the deployment itself (and what resistances and issues you may encounter), but for now, lets get back to the task at hand. What are the Chromeboxes like to run Operationally.

So, to give some metrics, here are some headline Chromeified stats:

Total number of deployed Chrome devices: 132

Chrome Device failures (wherein a device ceases function) : 1

Chrome Device failures (wherein a device had to be swapped out and be opened up and repaired, then resumed function): 1

Chrome Device failures (wherein a device required a wipe and rebuild): 22

Total Chrome failures: 24

Now, it is worth pointing out the wipe and rebuild of these devices takes around 15 minutes and is entirely automated – meaning that for 22 devices, it took roughly 6 hours of Tech Ops time to rebuild them all, and during that time, you’re only ever going to be actively working on the unit for 2-3 minutes, so it’s more like an hour of your team’s time, total  – and that’s being generous.

So, before we go too hog wild with analysis, lets compare it to some Windows machine stats, taken over the same time period:

Total Windows devices: 138

Windows device failures (wherein a device ceases function): 2

Windows Device failures (wherein a device had to be swapped out and be opened up and repaired, then resumed function): 3

Windows Device failures (wherein a device required a wipe and rebuild): 14

Total Windows failures: 19

Now, the initial impression here is that the Chrome devices fail more frequently. However, quite often we discovered that our Windows users would encounter an error and attempt to fix the issue themselves, due to the associated time they’d have to wait for a rebuild of a machine, this led to less recorded issues. Chrome users, by comparison, would simply ask for a switch at the first sign of an issue. However, for the sake of fairness, we kept a record of only what we had to fix ourselves.

So, to address that big issue we touched on earlier – time taken fixing issues and rebuilds. Given the 15 minute maximum time to perform a Chrome rebuild versus the 55 minutes to rebuild and re-image a windows machine and get it back into action, we should add up the totals and see where we stand:

Total Technical Operations team time taken up by actively rebuilding or repairing machines (estimated)

Windows: 17 Hours 40 Minutes

Chrome devices: 6 Hours

This is where the Chromeboxes start to shine. Nearly the same amount of devices, but under half the amount of the Tech Op’s team’s time is spent working on them. This is also assuming your staff will sit and watch the Chrome OS rebuild for 15 minutes, as opposed to switching to dev mode, kicking off the process and doing something else important, like having a coffee. Or a beer. With Windows, you can do something similar, but it takes far longer, especially if you’re running rebuilds on a case by case basis for custom machines, like we have.

That’s the real bonus we’ve found by going Chrome – we can now run a very lean and agile support function with only two staff supporting hundreds. If a Chrome devices fails, we pop to the user’s desk, unplug the faulty unit and plug in a new one. Coupled with Google apps and a lack of local storage (hooray for cloud), the user is back up and running in uder 30 seconds. This frees up your support staff to concentrate on the bigger tasks and ensure that time isn’t wasted trying to get a driver working or backing up the 67GB someone’s saved to their hard drive.

With development and product teams becoming more flexible and IT moving towards a more agile and reactive environment, surely it’s wortwhile to make sure your support teams can do it too?

I’ll leave it here for now, but next time I’ll cover common Chrome faults that we’ve encountered and how we’ve dealt with them. After all, the road isn’t always perfect!