Don't Fight the Establishment. A Lesson Learned.
In the beginning there was nothing. Bob said 'Let there be code!' And there was code...
When we started out at Project Peach we wanted to own ALL our code (to a certain point, we didn't want to code a browser or an operating system). We wanted our own UX for keyboard, scrolling, windowing system in a modern browser and our own cloud hosted libraries to support our cloud hosted, native code webapps. Noble indeed. The underlying ethos being full transportability across devices and operating systems. The UX on apple, android and laptop should be exactly the same for the end user experience. We built it, struggled with it, constantly refined it, worked around browser fixes that we'd done fixes around and eventually in the last framework release completely refractored it. Success, failure or a learning curve? You decide.
Our original UX was based all around absolute positioning of page elements in the browser. Remember we are trying to prove that webapps are more closely related to true applications rather than websites. We wanted to create windowing components like frames, dialogs, buttons, etc. just like a conventional WIMP (Windowing Icons Menus Pointer) user interface. This is the basis for our cloud hosted webapp UX. This theoretically fits on a single, no scrolling, desktop which is the client area of the user's browser. Modern browsers however are built around a different paradigm and optimised for scrolling websites which are more suited to relative positioning of page elements in a browser. Follow our 5 year journey from absolute to relative positioning...
The Event Horizon
Implementing an absolute positioning solution is much less problematic when the keyboard is OFF the screen. Mobile browsers on-screen keyboards present a multitude of problems with gracefully handling obscured parts of UX forms and controls. Follow the rules with conventional HTML Inputs, relative positioning, native device keyboard and tabbing and it's a relative breeze. Go your own way and you get sucked over the event horizon of writing realms of code just to make your WIMP system work. 'Absolute' Hell. So we start to build our own keyboard just to control the marriage of keyboard, windows, controls, forms and their interaction together. Oh, and we need to handle the scrolling of longer than a page forms, tabbing between controls, text editor controls bigger than one page. Tomes of code just to replicate what already exists in a browser already. We're already sucked into a coding black hole.
An excercise in mental masturbation? Probably. Fun, perhaps! Lots of problems to solve like click delays and making the on-screen, none native, keyboards as responsive as possible. We built a templated systems that allowed full customisation with simple text files and unicode characters. We made it easy to build new language keyboards, indeed we had but two. UK of course and a European keyboard. We could also skin the keyboard to look like android or apple or any other CSS'ed look we desired. A masterpiece but not without it's problems, some self inflicted, some browser vendor inflicted. Perhaps our biggest accolade is that most users didn't notice the difference.
Total consistency across all devices. Same across Apple and AndroidWe control the functionality and marriage of the keyboard and our own forms and controlsCan add new features to enhance user interaction with our webappsPerfect page positioning controlled by our code