We wanted to use ALL our own code in our framework. Mmmm...
May 2017
Don't Fight the Establishment. A Lesson Learned.
John Ince
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.
UX: Absolute or Relative Positioning?
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...
Absolute Positioning in Mobile Browsers
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.
Our Mobile Keyboard
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 Android
  • We control the functionality and marriage of the keyboard and our own forms and controls
  • Can add new features to enhance user interaction with our webapps
  • Perfect page positioning controlled by our code

  • Disadvantages
  • Users of Apple devices are used to and think that it's the native keyboard. It behaves differently but looks the same
  • Confusion over how to use something different, perhaps better, but no desire to learn. Users end up fighting the UX
  • Android and Apple users don't want a consistent UI, they want the device keyboard that they are used to
  • Have to create new keyboards per country when it already exists/built in
  • Vendor fixes and changes to browsers sometimes breaks our keyboard functionality
  • Being a JavaScript implementation within the browser it's never as responsive as a native keyboard
  • Our Scrolling
    Complimenting our keyboard we added our own JavaScript scrolling library. Our original single page paradigm needed to support occasions when the page length exceeded the vertical screen space available. We ended up with scrolling pages and multiple scrolling sub-regions just like a conventional operating windowing system GUI. With absolute postioning we could fix buttons at the bottom and scroll an inner viewport of a form or text. Our keyboard could seemlessly scroll positions and scroll through forms. It carried the same problems as our keyboard, we own the duplicated code and it's never as good as the browser's implementation. We need to code for differing mobile implementations and it somewhat lacks responsiveness being Javascript rather than native browser code. We stuck with 'absolute' dogma for four years before seeing the light and going relative positioning and converting to the native scroll bars. Remember our framework refactor to relative positioning affected all our UI components and their component interaction. The advantages and disadvantages are exactly the same as the keyboard highlighted above.
    Our Text Input Control
    Who needs the browser INPUT control. We want much more control over our data entry particularly regarding the multiuser aspects of our UX. We built a JavaScript edit control, and other controls mirroring GUI controls like lists, combos, etc. We used a humble < div > element at it's core, inherited from our base control and a whole heap of JavaScript glue to make it work like a GUI edit control. Oh, and of course we styled it all with CSS to add the beauty to the function. Ever tried building and recreating the function in just a standard edit, from highlighting to cursor movement we did it all. Again most were completely indifferent because they presumed we just used the browser native control. To that extent it's an acolade to our programming prowess. We hit a few problems over the years with changes to security in browsers particularly around the copy and paste APIs. We were vunerable to changes by browser vendors which broke our implementation, we constantly checked the canary version to get a head start, but we can't check every browser and often we'd get a JS error appearing in our centralised error logging tipping us off regarding a browser stopping working out of the blue. Again, we needed this to support our 'absolute' based windowing system and the marriage between the other GUI primatives, like scroll bar and keyboard. If we move to relative positioning and behave more like a web page then we can use and customise a standard INPUT with some CSS and create exactly what we currently have but using stock browser UI controls.
    The Move to Relative Positioning
    Probably the biggest refactor we've ever attempted in a single two week agile sprint. It's one of those changes, at such a low level, that there a just so many interdependencies. It all needs doing at once before the source code can be checked by in. We love deleting code here at Project Peach, one line deleted is one line we don't have to maintain. Cutting our obfuscated JavaScript library size helps reduce our loading times, nice side effect. We chip away at the code, we need to completely dismantle the engine and rebuild it using stock browser components. Two weeks later we pop out of the other side and wow! What a difference. It all feels so, so responsive! Smoother scrolling, faster keyboard, copy and paste to keyboard are just the tip of the iceberg. Perhaps the greatest asset is that Apple users and Android users experience a near native experience. We lose our cross platform common look and feel but the rewards beat our perfect UX world strategy. A total win. Try it for yourself on mobile, it's pretty amazing, just head to one of our realtime webapps via a portfolio link.
    Doing it differently since 2012. We're simply 10 years ahead. Our software is designed, coded, maintained, supported & hosted in the United Kingdom.
    Why Project Peach?
    The Hawthorn Gallery
    DBD International
    Knot 2b Missed
    Monero Mine
    About Us
    Contact Us
    Pay Us
    Copyright 2020 Project Peach