Follow / Friend Us
Welcome to part five in the series about managing your Office assets in a world of tablet computing. In part one I introduced the primary ways to consume Office with rich clients, remote rich clients, Office for Mac, Web Apps and Office on the phone. In part two I talked about consuming email on tablets using Exchange ActiveSync, compared the controls you get with other platforms to Group Policy and described options for configuring Office. In part three I wrote about the Office Web Applications as part of the SharePoint 2010 or Office 365 service. In part four I wrote about ways to differentiate resource access based on devices using IIS and UAG. The next major topic I'll discuss in this blog is how to tweak the user interfaces for remote access to Office environments running on Windows.
In part one of the blog series I referenced the phase “Post-PC Era” and discounted it a bit for those who still want to get real work done and for that need a pointing device and a keyboard. Applications developed for Windows over the years tend to assume that a keyboard and a pointing device exist and we will need to keep that in mind when I start to talk about optimizations we can make to Office and shell configurations for touch. I can say I know firsthand the challenges of using Office with touch navigation, as I use it that way about two hours per day in my car during my commute to and from Redmond.
While this is not an iPad, Android, or Windows slate, it presents the same challenges to be able to navigate a system with applications designed for keyboard and mouse. I’m going to relay some of my findings as I worked through configuring Office and Windows for primary touch use.
In this example, the remote desktop or server will be the target of our “touch-friendlier” configurations. Remote Desktop Services (RDS) can be used to access a full desktop or a remote application window of a Windows Server RDS role installed. In either case we can do a couple of things to make the experience better.
If you navigate to “Control Panel\Appearance and Personalization\Personalization\Window Color and Appearance” on a Windows machine and click on “Advanced appearance settings…” you will see this screen:
If you click on the “close” or “minimize” buttons it will toggle controls over to the Item called “Caption Buttons”. I will set the size at around 40, but it really depends on the resolution you run on the remote desktop or RDS server and the screen size and resolution of the consuming device, so you may need to experiment a bit to get the size right. Likewise, if you click on the scrollbar area, it will select the “Scrollbar” item and you can set that to a size matching the Caption Buttons. These minor tweaks are invaluable when you consider how small the standard buttons can be on a 7” Samsung Galaxy Tab for example:
These changes make scrolling and closing applications possible, even though they may look a bit unusual if you are not used to seeing these controls modified. One nice thing about these controls is that if you access the remote desktop or server session with these configurations, they will be respected by an iPad or Android device using Citrix XenApp for example. If you access this window from a Windows device, it will adjust the Caption Buttons and Scrollbars to the size of the connecting device.
In the picture above you can see a custom default Office tab I called “iPad” and in a previous blog in the series I showed a Word ribbon with a “Touch” tab. This isn’t some secret version of Office 2010 optimized for touch, but rather normal supported commands to customize the default Office ribbon. If you navigate in Word 2010 to “File\Options\Customize Ribbon” you will see a screen like this:
Here I have already produced a custom ribbon tab with larger controls. These will be more forgiving for touch use and the in this case Word will open with the “Touch” tab as the default tab. The result will look something like this:
Notice how each button is large enough for touch use and only a few core features are exposed. When we created the custom ribbon file, it saved an OFFICEUI file in the AppData folder for my user account:
The OFFICEUI file is comprised of basic XML and does not have an affinity to the user account where it was created, as seen below:
You can use this file as part of a default user profile and even copy these files into your Office installation media and use the Office Customization Tool (OCT) or config.xml as mentioned in part two of this blog series to copy this file into the correct location on your RDS server or standard remote desktop build.
Once all of these changes are in place and the iPad, Android or Windows device can access the remote desktop, the user experience should be better than the default configurations. There are still many areas in the application Window where a pointing device would outperform touch using a finger. Here is the resulting look from an iPad with our customizations highlighted in red:
While it doesn’t make every control and font optimal for the small screen touch experience, most common tasks are doable. These minor tweaks to the user interface will help save user frustration and help allow for the use of Win32 applications on non-Windows devices. Many organizations have thousands of customized line-of-business applications and rewriting the critical applications for a different platform may not be feasible.
I was honestly hoping to conclude the blog series with this fifth part, but soon realized that it would take another blog to describe how to configure the remote desktop environment. Part six will then be the final blog where I will discuss the common architectures to get a remote session on an iPad, Android or Windows device and show a few additional security configurations in the process.
Thanks for reading,
Senior Product Manager
Office IT Pro Team
UPDATE: Now that all of the blogs are complete in the series, here are links to all six completed blogs: