Uh Oh! It appears you're not connected to the internet!
Sorry! We currently have more users than we can cope with. You can either wait until a space becomes available or come back later. We will be upgrading our servers to cope with this soon!
You got the boot! Click to connect back up...
Please contact an administrator, You are not authorised to login via this IP address
Already have an account?
Click here to login
Don't have an account?
Click here to sign up
Go check your email!
Oops! We don't know your email address, We can't send you a new password! Contact an Admin
Set Profile Picture
Select An Image
Confirm End Of Friendship
Chat To Us
Prefer to chat anonymously?
Read all about it, See what the good people at Project Peach have to say
We wanted to use ALL our own code in our framework. Mmmm...
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.
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
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
Our Text Input Control
The Move to Relative Positioning
Doing it differently since 2012. We're simply 10 years ahead. Our software is designed, coded, maintained, supported & hosted in the United Kingdom.