Skip to main content

Our Adventures into Creating a Secure MVC Framework - Part 2 - Design Requirements


When we created iPhora Touch version 2, it was a multiple page application that utilized Dojo 1.53 and Bootstrap 2.32.  The interface worked well on desktops but broke down when used on tablets. It was totally unusable in a phone environment.  Since it was a multiple page solution each page needed to reload Dojo as you jump from page to page. Since we wanted a secured environment, pages could not be cached. However, this slowed down the loading and response of each page.  Since we were using Dojo 1.53 at the time we did not benefit from any form of AMD.


iPhora Touch V2 Community Home Page

We wanted to redesign the interface to work well with mobile devices and desktops, have better performance, but at the same time to be a secured environment.

Though our iPhora Touch solution is a social community-based solution, we designed it to be a closed environment by default and it is assumed that you are not allowed access to anything, which is contrary to how most social collaboration platform are designed.  Social collaboration no matter how any analyst or others spin it, is all about data. Who has access to this data needs to be securely controlled. Being openly social and with no control leads to data breaches. Security is not just about SSL, firewalls, and encryption.

So for any community you may have access to one piece of information at any given state, but in another one you may have no access or limited access.  This holds true not only within a community but all the way down to individual web containers and components part of a community.

So the challenge was to create an infrastructure and interface that met these requirements. Over the course of many months, we looked at many interfaces and did not find anything that we thought was appropriate. I asked my oldest son who is an industrial designer on design, but that was of no avail.  So it was a struggle to find something that would work.

My youngest son is a big user of Pandora and was listening to music when I noticed their application on his iPad.  I thought to myself this is a nice and simple interface, but very powerful. So I borrowed his iPad and played with Pandora for hours trying to understand its functionality. Unfortunately, there was a number of things that I thought was not usable for us, but it was a good starting point, a design inspiration. The multiple pane approach is what we needed, but how in the heck do we implement something like that. Many of the cool things it did we did not need or I was not sure we could even do on a web browser-based interface.

So using my favorite mockup tool, Balsamiq, I moved forward in laying out what the next version of iPhora Touch would might look like.  So we came up with a multiple pane environment that is shown below.  Depending on the state of the application some panes would be hidden and some not.  Many application used a similar approach including applications like Facebook on the phone.

This was the easiest part.  The challenge was to create a multi-pane single page application framework and make it work.

So we came up with our design requirements and they were as follows:
  • The JavaScript library that would be used to drive iPhora Touch need to utilize AMD to reduce the loading process
  • The JavaScript library components needed to only load once during a session and when needed.
  • Each pane needed to have its own independent security environment but at the same time could be dependent on the state of a different pane and controlled by the application developer
  • The content of each pane had to handle multi-state of existence:
    • Fully Cached, where both the view and scope is cached
    • View Cached, where only the view is cached and scope is destroyed after use
    • No Cached, where both the view and scope are destroyed after use.
    • Defined Cached, where the existence of view and scope is programmatically controlled by the application developer or the server
  • No data can be stored locally on the client, but create the illusion that data is local
  • The MVC framework had to handle not only the defined pane structure shown above, but needed to function in any multiple pane layout that one can come up with. For example, it should easily function in a three pane environment shown below.
  • All web container and components had to inhere to iPhora multiple level state environment. What this means is that for any web component there is a number of possible state of existence and the state in which it exist varies depending on the level of user access at any given time within its parent.
  • The MVC framework had to use dynamic routing. Since the state of any content within a pane is dynamic and ever changing, routing needed to be dynamic so static hash tag routing was totally out.
  • Data binding for components needed to be controlled by the application designer rather than being automatically performed by the system.
  • Web containers and components within a pane had to inherit the security of its parent container
  • All web containers and components needed to be generated dynamically and can not pre-exist since it is dependent on what a user is doing as it interacts with the application.
  • The MVC framework had to function with the iPhora RESTful APIs controlled by the Gatekeeper on the server.
  • The framework had to be lightweight and as small as possible
  • It needed to function in all favors of web browsers, both desktop and mobile devices (modern versions)
  • It needed a responsive UI.


Alternative Multi-pane layouts



So these were the design requirements and which there are many.

Coming next time, Part 3 - The Experiments

Comments

Popular posts from this blog

Creating Twitter Bootstrap Widgets - Part II - Let's Assemble

Creating Twitter Bootstrap Widgets - Part I - Anatomy of a Widget Creating Twitter Bootstrap Widgets - Part II - Let's Assemble Creating Twitter Bootstrap Widgets - Part IIIA - Using Dojo To Bring It Together This is two part of my five part series "Creating Twitter Bootstrap Widgets".   As I mentioned in part one of this series, Twitter Bootstrap widgets are built from a collection standard HTML elements, styled, and programmed to function as a single unit. The goal of this series is to teach you how to create a Bootstrap widget that utilizes the Bootstrap CSS and Dojo. The use of Dojo with Bootstrap is very limited with the exception of Kevin Armstrong who did an incredible job with his Dojo Bootstrap, http://dojobootstrap.com. Our example is a combo box that we are building to replace the standard Bootstrap combo box. In part one, we built a widget that looks like a combo box but did not have a drop down menu associated with it to allow the user to make a select

The iPhora Journey - Part 8 - Flow-based Programming

After my last post in this series -- way back in September 2022, several things happened that prevented any further installments. First came CollabSphere 2022 and then CollabSphere 2023, and organizing international conferences can easily consume all of one's spare time. Throughout this same time period, our product development efforts continued at full speed and are just now coming to fruition, which means it is finally time to continue our blog series. So let's get started... As developers, most of us create applications through the conscious act of programming, either procedural, as many of us old-timers grew up with, or object-oriented, which we grudgingly had to admit was better. This is true whether we are using Java, LotusScript, C++ or Rust on Domino. (By the way, does anyone remember Pascal? When I was in school, I remember being told it was the language of the future, but for some reason it didn't seem to survive past the MTV era).  But in the last decade, there a

The iPhora Journey - Part 4 - JSON is King - The How

  The iPhora Journey - Part 1 - Reimagining Domino The iPhora Journey - Part 2 - Domino, the Little Engine that Could The iPhora Journey - Part 3 - Creating an Integrated UI Framework The iPhora Journey - Part 4 - JSON is King - The Why The iPhora Journey - Part 4 - JSON is King - The How As we mentioned yesterday, in reimagining Domino, we wanted Domino to be a modern web application server, one that utilized a JSON-based NoSQL database and be more secure compared to other JSON-based NoSQL platforms. A Domino document existing within a Domino database is the foundational data record used in iPhora, just as it is with traditional Domino applications. But instead of just storing data into individual fields, we wanted to store and process the JSON in a Domino document.  However, text fields (AKA summary fields) in Domino documents are limited to only 64 KBytes, and that is a serious limitation. 64 KBytes of JSON data does not even touch what the real world typically transfers back and fo