The new Surface Pro tablet finally went on
sale in the UK on 23 May 2013 and we were quick to order the 128GB model for Implied
Logic so that we could test STEM for compatibility with the touch interface and
Windows 8. The device arrived from Microsoft within
48 hours and, within a week, I was using it as a full-time replacement for my previous
and most reliable and powerful laptop to date (a Sony VAIO
Z-series).
We quickly established that the Surface Pro not
only does everything an executive laptop does (and actually faster as it’s
2.5 years younger), but it also works very nicely as a tablet away from the sit-up
desktop environment. Unplug the peripherals (we recommend a USB 3.0 hub), pull off
the lightweight Type Cover keyboard, and sit back
and relax with the slowly growing universe of Metro
apps. You can draw directly with the standard pen accessory and even hand-write
your emails with amazing accuracy.
The existing STEM 7.3b system ran without any modification whatsoever
– that’s what you expect on the Windows platform.
As well as signalling a vote of confidence in the new device and operating system
combination, I am embracing the touch environment in order to see what STEM already
does well, and where it could work better with some touch-sympathetic refinements.
STEM is well suited to a touch environment
STEM is very much at home in a workshop situation where it can act as a focus
for discussion around the structure and evolution of a model, and where it will
directly inform and update the audience as changes are made with its visual editing
metaphor. Just like a family, planning its holiday activities around the standard
Microsoft Maps app, it will be a big plus for everyone
in a small-team, round-table situation to be able to interact directly with a STEM
model when there is broader support for the touch interface.
Already touch works well for creating elements from the toolbar, and even using
the Connect tool to add relationships (by tapping
the respective icons in turn). However, it is clear that the current interface was
built for a mouse as the toolbar buttons are rather small for an adult-male finger!
Actions like running a model or deleting an element would be easier with dedicated
buttons on the toolbar (or even an Office-style ribbon).
The menus are generally a fiddle and we might seek to explore a
Metro selection action (short swipe down or across) and then swiping
in from the top or bottom of the screen to access finger-friendly options for the
selected icon or icons. Comparing with other Metro
designs we have seen, type-specific data-dialog options might be presented at the
top of the screen, with more generic commands (including Delete)
at the bottom. Moving an icon would be straightforward once the selection mechanism
was more touch friendly.
Moving around within a view is fiddly if your fingers are too big for the scroll
bars. The expectation from other apps is to be able to drag the view background
directly, whereas currently this action is used to ‘rubber band’ a selection.
Moving around in data dialogs is OK once you get the hang of swiping sideways to
select a button ‘without pressing it’, but selecting a choice from a
drop-down menu is again challenging if your fingers are not petite.
It would also be easier if you could draw results graphs from a toolbar or ribbon
with buttons for the most common actions. The current dialog ‘wizard’
process for drawing a graph actually works quite well via touch, once you get the
hang of selecting items from a list box. The trick is to swipe sideways to mark
one item, before proceeding to swipe up or down the list to extend the selection
to multiple graphs, scenarios or elements (as opposed to simply scrolling the list).
At the time of writing, we have not figured out how (if it is possible) to make
a non-contiguous selection without the
key!
Plenty more to do
To be clear, we have not developed a Metro app
for STEM (for either Windows 8 or the sublime and
very consistent experience of Windows Phone 8),
nor is there yet any compelling reason to do so – unless it emerges that operating-system
support for the touch gestures alluded to above is only available in a
Metro app. But the central point about Windows 8
(in our view) is that it brings the option and opportunity of the touch experience
to any conventional desktop application. (Actually, it is better engineered and
generally optimised compared to Windows 7, but
that is another story.)
So we will be compiling a list of specific touch ‘no goes’ in the current
interface and looking to prioritise a short list of the most valuable small changes
we could make to enable a better touch experience without significantly derailing
our core feature development.
One possibility we might explore in the future would be an option to export a Metro app to access an existing model hosted on an
eSTEM server as an alternative to the current HTML 5 and Flash options.
Suggestions are welcome for other interesting possibilities or compelling
reasons to consider developing a Metro app (or
apps) for STEM.
Remarkable continuity for how software runs on successive versions
Just like the earlier Windows 7 platform, we had
clients in other territories using STEM on Windows 8
before we had even tested it ourselves, but this was never a concern for us. Successive
versions of STEM have run on every version of Windows
from 2.0 onwards, if not even the earlier 1.* versions, partly due to good design
and practice on our side. Microsoft’s dedication to backwards compatibility
in order to maintain the PC-application software eco-system is such that we have
had to make remarkably few source-code modifications along the way (the principal
one being the switch to the 32-bit environment in Windows
95). In most cases it was typically an isolated bit of functionality
which might need to be addressed; in some cases no changes were required at all.
Currently there is a lot of noise about the wealth of (mostly lightweight) apps
for iOS and Android
platforms, but this hardly compares with two decades of rich PC application software
which may still be required and would be very hard to replace for many companies
and users. The software you use today will typically run on the
Surface Pro if it runs on Windows 7.
Note: this is not the case with the Surface RT and its current
Nvidia Tegra 3 processor.
There is also much debate about the demise of the Start
menu in Windows 8 where it is superseded by the
flatter and much simpler to navigate Start screen.
Personally I can’t say I have missed the Start
menu for a moment, so I hope that its reported reincarnation in
Windows 8.1 is optional!
Just to prove that I am not an unconditional sycophant, here are two specific bug
bears:
- A 128GB SSD isn’t quite big enough when you fulfil multiple job functions,
so we followed Microsoft’s recommendation to buy a 64GB SD XC card to provide
additional storage for nice-to-haves like one’s ever growing media collections.
Unfortunately Windows 8 still refuses to add content
from this kind of device to libraries for the standard music and photo apps, even
though apparently it will from the more inevitably detachable alternative of a USB
HDD!
- You are required to connect at least one Microsoft account before several core apps
will work at all which in my view is totally unacceptable for an enterprise machine.
Our Surface Pro devices are attached to a domain
and, in general terms, there is no specific Microsoft account which is appropriate
for more than one company employee to use. The Calendar,
Mail and People
apps all integrate nicely with Exchange if you also
attach at least one Microsoft account, so why on earth should they not be used with
Exchange without one?
Microsoft may not regard these issues as bugs, but from the perspective of either
a personal user or a corporate buyer, they certainly come across that way. We have
seen that some early gripes with Surface Pro and
Windows 8 had already been addressed by the time
we got our hands on ours, so we can only hope that Microsoft is still listening.