HTML5 and RDP (and tablets)
|
|
|
|
|
For quite a long time, we thought that using HTML5 technology and solutions on a Client, would be a great idea. It would be great because "soon" all devices, PC's, tablets, mobile phones, etc, would support HTML5 in the browser, and from every type of device it will be possible to do a RDP session to a Terminal Server, using HTML5 in the browser.
So, we did some initial work, some prototyping. The result of that work is the conclusion that HTML5 is not a great idea:
First we should start with an "external" reference from a company and a person who knows a few things about user interfaces, design, etc. Think of Apple and the (late) Steve Jobs. They made it clear: the iPhone and MAC are 2 different devices, 2 different user interfaces and will not be merged into 1 OS. The MAC and the iPhone/iPad will each have its own OS.
This might be a statement from the past now that Steve Jobs is not directing Apple anymore, but for the most of it, Apple still seems to follow this mantra: Devices with a mouse and keyboard need different software then devices that are controlled with touch.
Another "external" proof of this mantra is Windows 10. Microsoft has chosen to do what Apple does not do: 1 device, 1 operating system, suitable for both keyboard/mouse and touch. Despite all the effort from Microsoft, we think Windows 10 has a clumsy and for the most of it an inconsistent user interface.
We think it is not realistic to aspire 1 solution suitable for both PC's and touch devices. A simple example of the statement that 1 device, 1 operating system, suitable for both keyboard/mouse and touch, is not realistic, is working with something like EXCEL. Try to work with EXCEL as it runs on a PC. You will need a mouse. You need to do drag-and-drop. Resize columns. Left-mouse-click. Right-mouse-click. Double-click. There are numerous small user interface elements, so small that when you attempt to use touch, it becomes clumsy.
It is theoretically possible to re-design all existing software in the world, such that all user interface elements are bigger and remove all non-left-mouse clicks but realistically this is not happening on any scale by third party software developers or Microsoft itself.
And you need a keyboard for EXCEL with proper Cursor-keys.
Touch interfaces are suitable for devices that are laying down, or are hold in a horizontal position. Keyboard/mouse devices are positioned in a vertical position. That is why manufacturers for Windows 10 laptops are building laptops where the screen can be folded all the way around, such to achieve both horizontal and vertical position. However, go back to the EXCEL example. Just try it. Try to work with EXCEL on a Windows 10 laptop with touch for 1 day and do not use the mouse. You will be tired, quite quickly, because either the screen is in the wrong position for working, in the horizontal position, such to be able to do touch. Or your arms are tired because of touching a vertical screen. Working like this for 8 hours in an office day is just not realistic.
Why talking about HTML5 and RDP? Because of tablets...because the thought behind it is having a Windows desktop or Application on a tablet. Just give it a try: download the Microsoft RDP client from the Google or Apple Store and work for 1 day with an application that is designed for being used with a mouse and keyboard. That is what we did. And it is just inconvenient, clumsy, slow, or not workable at all.
On this day that you attempt to work with a tablet, working with some PC application like EXCEL that needs a mouse/keyboard interface, using the Microsoft RDP client for Android/IOS, you should mark for yourself the moments that you attempt to do typical PC-mouse actions on the tablet. Think of drag-and-drop, double-click, right-mouse-click, or holding the CTRL-KEY and mouse-click such to select multiple items. Or mouse-down-click and select an area on the screen, followed by mouse-up-click. While using the Microsoft RDP client for OSX or Android, you will notice that a lot of those typical PC-mouse actions will give you trouble. For example the obvious right-click-mouse. Or attempts to select an area on the screen, because a touch interface does interpreted that action as a left- or right swipe. After this 1 day of inconvenience and clumsiness, try to think of doing the same thing with a HTML5 browser. We did do this while prototyping. And the few PC-mouse actions that do work when using the Microsoft RDP
client, are now not working any more because either the browser or Android / IOS does interpreted the touch action.
It is not only the lack of mouse on a tablet that makes working with a PC application a clumsy experience. The virtual keyboard on a tablet does also not improve the experience while working with a PC Desktop Application. Usually the cursor-keys are missing on the virtual keyboard; try to work with EXCEL while not using the cursor-keys...And the virtual keyboard takes space from the already small tablet screen.
We came to the conclusion that software that needs a PC mouse and keyboard is quite difficult to use on a tablet. Inconvenient. Clumsy. Not suitable for 8 hours of office work.
And HTML5 + the browser makes it more clumsy and inconvenient, close to un-usable.
There are applications, software, solutions out there which enable already the PC desktop on a tablet. Think of POS (point of sales) systems. They exist already for a long time, and they do not need a solution from Microsoft or AADS; they do not need Windows 10 and UWP or HTML5 because POS vendors develop their own PC application with a user interface such that the POS application can be used on a touch device.
What remains are some details why we also think we should not do HTML5 and support tablets. We get requests for an AADS client on Android and IOS because of our SSL Gateway. Android is available in roughly 200 up till 500 different form factors, devices, screen sizes, etc. All of them have different Android versions. Most of them are not maintained or updated. HTML5 in the default browser is poor or absent. Customers would need to install either Chrome or Firefox on those Android devices. It would be an endless amount of support for us and most of it we could not do. It is not feasible for us to test our product on so many different Android devices.
Apple policies do conflict with our software (or vice versa...) Our client software does update itself if the AADServer is updated. Apple does not allow for IOS software that updates itself. All updates need to go thru the Apple store. Currently AADS customers are using all builds we have between 2013 and 2019. The Apple IOS store does not really facilitate different versions of the same software. We would need to redo work in AADS, the IOS client, starting with designing some kind of solution where the IOS client is updated thru the Apple store, but the AADServer is not updated, or vice versa, and still everything should work... An IOS client would be a difficult job. And we also think that Apple is not really committed to a proper HTML5 implementation. Apple is selling iPhones and that is important for them; that is where they make their money. They are not selling browsers with a proper HTML5 implementation.
Whenever the browser on Android/IOS is failing for whatever reason, while attempting to do a RDP session to an AADServer, and while using our AADS SSL Android/IOS Client, off course the support case lands on our helpdesk, and not on the desk of Samsung, Google, HTC, Firefox, Chrome, Apple, etc, etc.
Suppose we would support somehow HTML5 in a browser, it is expected that a customer would certainly try it, but would be disappointed and "dump" it within a couple of hours. And quite possible the customer would blame AADS for this poor experience...
|
© 2012-2023 AADS WorldWide. Terminal Server | Application Server | Remote Desktop solutions | Firewall |
|
|
|