ForeUI is an easy-to-use UI prototyping tool, designed to create mockup / wireframe / prototypes for any application or website you have in mind.

All posts tagged html5

ForeUI V4.1: Local Storage Element

ForeUI V4.1 is released now. This update introduces a new element named “Local Storage”, which is a representative of the “local storage” concept in HTML5. As you may have already known that, in ForeUI we have the “Html” and “Script” elements, which could be used to access the local storage in HTML5 directly. However, the new local storage element still bring you some benefits.

The Local Storage Element

The local storage element is just like the “Html”, “Css” and “Script” elements, they could be dragged and dropped into the editing area but they are not visible in the simulation.

LocalStorage_Element

One advantage of using this Local Storage element is that it provides a namespace for each instance of this element. So you can use this element like a database table, and different instances of this element can store values with the same key. In the “Manipulate Elements…” window, you can choose the “Set Local Storage Data” action and then specify the data as a key-value pair.

set_value

As you may already know that, the local storage in HTML5 can only store data as text string. The local storage element in ForeUI however, can store any data type supported by ForeUI, which are number, string, array and object. You don’t need to worry about how they get stored, ForeUI will take care of that for you.

The data stored in the local storage could then be retrieved as an element property (associative array type).

get_value

Communication between Simulations

This is the most interesting part. The data stored in local storage are persisted even the browser window gets closed, and they could be retrieved and used later. This could be used as an approach for communication between ForeUI simulations!

By using this local storage element, multiple ForeUI simulations can talk to each other. Of course you can achieve the same effect by directly using the local storage in HTML5, but ForeUI’s local storage element has its own namespace, and can easily help you to make sure the simulations can (or can not) share certain data.

The video below shows an example, there are two ForeUI plots and we launch two instances of simulation for each. Thanks to the local storage, these simulations are sharing the same data (x and y positions of the object). As you can see, the object locations are synchronized between all simulations.

local_sync_550

You may wonder how this is achieved. The magic is that both plots have a local storage element named “LocalStorage_GreenBall” (so they share the same namespace), and both plots are using the values with the same key (“x” and “y”) in this local storage element.

If you are interested in these example plots, they could be downloaded from the ForeUI store, or you can run the simulation directly from here and here.

It can be a Game Changer

It is cool that ForeUI simulations can communicate to each other, it could be useful to simulate the interaction between two or more applications. But it is not just that, this local storage element can actually change the whole game.

Have you ever tried to design a huge plot with ForeUI? When the plot becomes very big and complex (let’s say 100 pages with full of elements and behavior), it will be much harder to manage. The application will eat a lot of memory and becomes much slower. What’s more, loading the simulation for such a huge plot will be extremely slow, and sometimes your browser just lose response forever.

In this case, our suggestion is to split your design into multiple plots. But there is a problem followed, after splitting the plot, how can they share data between each other? There was no easy way to solve the problem before, but now we have one. By putting the data into the local storage, they could be accessed by multiple plots, which will work together and behave like just one plot.

split_plot

There is more. ForeUI has “iFrame” element at the very beginning, so it is possible to embed a simulation in another. Now we can make it even better, the simulation within iFrame can communicate with the outer simulation via local storage. That actually provides a new idea to design your plot. Some heavy-weight, reusable content could be created as a separated plot, and get embedded (maybe multiple times) in another plot’s simulation.

embed_plot

What do you think? With this new local storage element, you can design your plot in new ways, and implement much more exciting things in ForeUI!

Lazy Loading of HTML5 Simulation

Since ForeUI V3.0, there is an “HTML5” tab in the settings window, and we can make some configurations for the HTML5 generation.  As shown in the figure below, there are two columns of configurations, and they have the same content.  The difference is that, the left column is for running HTML5 simulation (clicking the “Run Simulation” button in ForeUI), while the right column is for exporting HTML5 (clicking “Export HTML5” button in ForeUI). Most of the settings in this window explain themselves, except the “Lazy Loading”.  This option is turned off by default, which means all contents in the simulation have to be loaded by the web browser before showing the first page.  You will see the loading page before the entire loading process is done.  If the simulation is big and complex, you may have to wait for a long time, which is bad.  In this case, you can consider turning this “Lazy Loading” option on.  It will try to display the first page as soon as possible, and keep loading the rest part of simulation in the background.  If you load the simulation with a web browser that has status bar shown, you will see the loading progress like this: The first page of simulation will appear when all its content are loaded.  You can review and interact with the page and wait for the loading of other pages.  If reviewing the first page takes some time, the next page may have been loaded in the background before you switch to that page.  Thus we reduce the actual loading time for the simulation.

The figure below explains how the “lazy loading” option works:

What if the target page is not completely loaded when we try to show it?  This can happen if “Lazy Loading” option is turned on.  In this case we will see the loading page appears again and we have to wait for the loading of that page.

If the loading time of your simulation is acceptable, you don’t need to turn on the lazy loading.  If you want to shorten the loading time, you can try to turn the “Lazy Loading” option on.

I should mention that using a faster web browser (e.g. Chrome) will be a good solution to accelerate the simulation loading.  However it may not be acceptable in some cases.