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 performance

ForeUI 4.4: Significantly Improve Performance

Recently we made some important optimisations on performance, and the newly released V4.4 includes all those changes and gets much lower CPU usage and shorter response time. The difference is very significant, especially when editing bigger plot with a lot behaviors defined. Using newer version of Java Runtime could get even better performance, although we haven’t included the newer JRE into the installation bundle yet.

Since this version, the GroupFrame element becomes a container, which allows you to embed other elements into it. Although in the major of cases, GroupFrame doesn’t have to work as container and other elements can just float on it, it is still more intuitive to put those element into GroupFrame.

EmbedIntoGroupFrameWe also made some enhancements on opacity adjusting in either the tools panel and the behavior editor. In previous versions, you can input the opacity value as 0~255 integer, and when you define the action to change the opacity, you will input a percentage. It is not comfortable that they use different system, while they are actually setting the same thing. However we prefer to keep both systems as they are all useful. Adjusting number between 0 and 255 is more accurate, while displaying % is more intuitive. So we finally implement it like this:


The input box on the left allows you to input number between 0 to 255, while the one on the right allows you to input 0~100%. The slider between them allows you to adjust the value with drag and drop. They are all linked, so if you change one value, other two controls will reflect that quickly. You will find the same implementation in the behavior editor, when you try to change the opacity with action.

We also enhance the Button element a little bit, and now it will automatically use grey icon when it becomes disabled. This is very convenient and it is available in both editing mode and the simulation mode. As shown in the animation below:

EnableDisableButtonEnjoy 🙂

How to Make Your ForeUI Plot Smaller?

The design/development of ForeUI V3.0 is just started, and I have some time to write something.  I plan to write a series of articles to introduce some advanced tricks of ForeUI usage, which will be very useful for all ForeUI users.

Today’s topic is: how to make your ForeUI plot smaller?  The “plot” here means both the saved .4ui file and the exported DHTML simulation files.  The benefits to make plot smaller is obvious:  smaller plot can be loaded/saved faster for editing, and smaller simulation files can be launched quickly in your (and reviewers’) web browser.  Here are some tricks to minimize your plot size:

Use Master Page to Avoid Duplication

Usually there will be some common parts between pages in your plot.  Although you could duplicate elements or even the entire page to make every page have the common parts, you are encouraged to move the common parts to a master page, which can be shared by other pages.

This trick is frequently used for pages that have the same header, footer or side bar.  For example, all pages in your plot has the same header, footer and side bar.  So you can place them in a page, and all other pages use this page as the master page.  Thus you can just manage the center content on other pages, the figure below shows the details.

What if some pages have different side bars, while they have the same header and footer?  In this case you can use this master hierachy:

There are 3 pages are used as master pages.  Master Page 1 is shared by Master Page 2 and 3, while Master Page 2 is shared by two pages (Page 4 and 5) and Master Page 3 is shared by another two pages (Page 6 and Page 7).  This hierarchy should meet the requirements for most web site/app prototyping.

By using master pages, you can avoid duplicating content in the plot, and significantly reduce your plot size.

Optimise Image Usage

Experiments show that using images is the best way to enlarge your plot.  So if you wish your plot become smaller, make sure your plot only includes the images that are necessary.  It seems superfluous words, who would like to include unnecessary images in the plot?  But sometimes you may do this unconsciously, consider this case:  you add an Image Box element and specify an external image file for it, after a while you delete that Image Box and forget it.  But the image is still stay in the Image Dock, and will be saved to plot file even it is not referenced anymore.  If you did this a lot, your plot will be quite big, although most of the images in Image Dock are not used actually.

Shouldn’t ForeUI just take care of this situation and optimize it automatically?  I can’t agree more, so we will have it in V3.0, but we still have to do the optimization manually before 3.0 is out.  How to know if an image is referenced then?  You can click on the image in Image Dock, then you will see a pop-up menu like this:

You can see how many elements are referencing this image.  If an image is not used by any element (used by 0 elements), you can just click the  button to remove it safely.  Remarks: you will need to update to V2.802+ to have the correct image reference number (fixed Bug_0309).

Besides removing the unused images, you can also merge the duplicated images in Image Dock, which will also reduce your plot size.  Again ForeUI V3 will provide this feature, but we need to do it manually for now.  For example, say you have two images (img0 and img1) in Image Dock, they are duplicated and any of them are used by other elements, how could you merge them?

You can choose one image to keep, and click the button for another image to change all references to the one will be kept.  For example, you like to keep img0 (merge img1 to img0), you can click the button for img1, then you will see this window:

After you click the “Ok” button, all references to img1 will be changed to img0.  So nobody is using img1 now, and you can safely remove img1.

By removing unused images and merging duplicated images, your plot will become much smaller.  You don’t have to do this kind of optimization all the time, but you’d better do it once before exporting the plot to DHTML.

Use Text Box to Replace Big Rectangle

Rectangle is a very frequently used element in prototyping.  However when you want to add a big Rectangle into your plot (e.g. make it as background), you can consider using a Text Box (with border shown, background filled) instead.

Why?  Because the Rectangle element will be converted to an image file when you export the plot to DHTML, bigger Rectangle will generate bigger image file.  While the Text Box will be converted to just a snippet of HTML code, its size will not change when you enlarge the element.  So if you need a big rectangle, consider using a Text Box with border and background first, as long as you don’t need the radius corner feature provided by Rectangle element.

If your plot has many big rectangles and you replace them to Text Box elements, your exported DHTML files will become much smaller.


In this article I introduced three approaches to reduce your plot’s size.  It is not just about saving the space in your hard drive, it can also significantly reduce the DHTML files generated by ForeUI.  If you upload the DHTML files to the Internet for people to review, smaller file size is bandwidth and time saver.  I would suggest all ForeUI users to try using this approaches, and create small and powerful prototypes.

ForeUI V2.45: Optimize DHTML Generating and More


Hello everyone, ForeUI V2.45 is out today as scheduled.  This version is focusing quality and performance.  Enhancements cover DHTML generating optimization, new id allocate algorithm, popup tool windows management and much more.

DHTML Generating Optimization

This is an exciting enhancement as it decrease the file number and total file size, thus reduce the time for simulation loading.  How did we do achieve this?  It’s simple and straightforward: we merged the script files and images files for each elements, thus the file number can be decreased and the space for image file headers can be saved.  The effect of this kind of optimization will be quite significant when plot become big and complex.

Here are some testing results against V2.45 and V2.42, which use the “Fwitter.4ui” plot as testing sample.  We exported the plot to DHTML simulation using V2.42 and V2.45 respectively.  The file number and total file size are measured.  We open the native simulation in different web browsers to measure the local loading time, and then upload the DHTML simulations to web server and open the remote simulation in different web browsers to measure the remote loading time.

V2.42 V2.45
Number of DHTML files
Total size of DHTML files (bytes)
V2.42 V2.45
Time to load simulation locally (seconds)
IE 6.0
Firefox 3.6
Chrome 6.0
Safari 5.0
Opera 6.2
V2.42 V2.45
Time to load simulation from web server (seconds)
IE 6.0
Firefox 3.6
Chrome 6.0
Safari 5.0
Opera 6.2

It is not a strict testing, however the result can still give us a rough idea of the effect.  The good news is that the effect will be enlarged as the plot become bigger and more complex.  You may notice that the loading time on IE (and Opera for remote loading) is much longer than that on other browsers.  After optimize the loading performance on IE is improved a lot and the difference is much smaller now.

New Algorithm for Id Allocation

In this version we introduce a new new algorithm for id allocation, I bet you will like it 🙂

Before V2.45, if you copy an element with id “Button_1”, and paste into the same plot, the newly pasted element will have an id like “Button_1_1”.  If you repeat the steps several times, you may get an element with a very long id like “Button_1_1_1_1_1_1_1_1_1_1”.  That’s very bad thing as you can not count out how many “1” in the id by first glance, the ids are long and not readable.

Now in V2.45, if you copy and paste an element with id “Button_1”, the newly pasted element will have an id like “Button_2”.  After several repeats, you will get an element with id like “Button_18”, this is much better, isn’t it?

What’s more, the new algorithm will try to keep the additional info in ids.  e.g. if you copy and paste an element with id “CheckBox_Option_1”, you can get the new element with id “CheckBox_Option_2”.  That can help you to understand the new element is similar with the source element.

We are quite excited about the new algorithm as it can significantly reduce the average length of element ids, and make ids more readable.  We should really make it earlier 😛

Tool Windows Management

There are some tool windows in ForeUI, such as element selector, page manage window, category manage window etc.  Usually these window will be closed when focus is lost, however you can pin the window to keep it in the screen.  Before V2.45, if a tool window is pinned on screen, it will be placed at top and all popup stuffs like message box, popup menu, element editor etc. will be covered by the tool window.  Now we have enhanced this situation, see comparison below:

Another enhancement is that when minimizing the window of ForeUI, all opened tool windows will be hidden as well, thus you can work on other applications without interference.  When you restore ForeUI window, these tool windows will be restored too.

Avoid Negative Z Value

It is recommended not to use negative Z value, because in web browsers other than IE, the element with negative Z value can not receive any mouse event.  So we make some enhancements to avoid the negative Z value being used.

Now the and buttons on floating tool pane can only reduce the Z value down to zero.  If you are sure you need a negative Z value, you can input it directly, like this

Also the Auto Adjust Z Value feature will not set a negative Z value anymore.

Other Enhancements:

  • Validate path before saving the plot file.
  • Highlight the editable part of id when element id editor window shown up.
  • Allow setting z value for embedded element.

Fixed Bugs:

  • Bug_0236: Double clicking embedded element can not open its editor.
  • Bug_0237: Disabled Spinner element should not be able to spin.
  • Bug_0238: Can not disable Tabs/Vertical Tabs element in simulation.
  • Bug_0239: Button text is not correctly align with icon when icon is on top/bottom of text, and text width is less than icon, and using center alignment.