Yes - to optimize your prototype files, try to reduce the number of high resolution images, data masters, or comments.
I have no data master or comments. All images are reduced as much as possible and the file size is around 30MB. Lag still occurs. I did a test file with just in-app wire frames and that also takes a while to load.
I'm just now trying out JIM and am experiencing that the published prototypes are very slow. When I say slow, I mean the time it takes to get from one screen to the next when an interaction event is triggered that loads a new page. I don't have any comments, data masters, or high resolution images in my prototype.
I've used many other prototyping applications and none of them are slow in this regard. Even the simulation is slow.
What's the word on this? Joseph's post was one month ago and no follow up reply from JIM?
We're so sorry you're running into this performance issue. Our development team is currently aware of this and is working to improve online performance. Meanwhile, if you don't need the commentaries feature, if you set your prototype as public it should work much better.
I tried making public and it's a bit faster but still HIGHLY problematic. And I really do need the comments on. This is a major problem, as we need to run usability testing and the responsiveness is poor enough that it is confusing people and making them click 2 or 3 times in the time it takes the next screen to load.
Our development team is working on fixing this issue as soon as possible however I can't provide you other solution at the moment. As soon as some changes have been applied I will inform you.
Sorry for any inconvenience.
Has there been any progress on this?
This performance completely ruins Justinmind as a tool.
You can't user test or even show work colleagues unless you are using your own computer and running a simulation straight from the Justinmind software.
Disappointing! Would be awesome if it can be fixed ASAP
It is already under consideration but unfortunately there is no set date. I have already informed to our development team to speed the process if possible.
Sorry for the inconvenience this may be caused.
Can you tell us if there's any progress on the prototype lag time issue?
Ten / eleven months ago you had reported that the "development team is working on fixing the issue as soon as possible..."
The lag issue is usually related to the prototype. It will depend on its complexity and the amount of elements that contains.
Things that can affect performance are: high number of elements per screen, high-resolution images (even if they are resized to a smaller size) and Data Grids showing Data Masters with large amount of instances (or Data Grids inside other Data Grids).
Also, a way to increase performance would be to split your prototype file into different prototypes.
Thanks for replying. I understand what you're saying, that the lag issue is usually related to the prototype's size and complexity. However, the test prototype I've made is pretty small. Here's the specs:
- 497 KB size of the .vp file
- 7 screens
- 6 variables
- 0 Data Masters
- 0 Data Grids
- 0 images (no linked images, no embedded images)
Pretty small file, yet there's still a bit of lag time when I run this prototype on an iPhone (via 'View on device' from the JustinMind Mac app). Every button/CTA has a lag time of about .50 seconds when they are tapped.
Is it possible to avoid this .50 second delay??
The 0.50 seconds is its the usual behaviour. However if you wish, send me your prototype and I can have a look into it and see if there is any other specific element that is causing this delay.
Here is the test file I've been building. It's not complete, but you should be able to see the 0.5 second delays when running this on a mobile phone.
Please take a look and see if you can find specific elements causing this delay. Thanks.
Your prototype contains lots of animations and many interactions associated, so this would be the main reason of your issue.
Another reason could be related with the fact that you have added some delays to the interactions with the " Time AFTER previous started" option with 1500/1000 seconds. Try to avoid this and use the option "AFTER previous" instead. That should improve the behavior a bit.
Kindly let me know how it goes.
Hi Sonia, thanks for looking at my file and getting back to me. You're correct that I do have some built-in delays in my interactions, eg. the 1500 and 1000 millisecond ones you found. However, the delay problem I'm talking about is the delays at the beginning of the interaction chain, the first thing that is supposed to happen immediately after the tap. (the delays you've identified delay the 5th and 7th event in the chain, while the delay I'm talking about is the first) Please see the attached version of the screenshot you sent, to see what I mean.
Should a 0.5 second delay be occurring before the first reaction starts happening after a tap?
Hi Justin Lui,
As mentioned the main reason is the big amount of animations and interactions. The more amount of interactions has the more the prototype will be delayed (between 0-0.5seconds) because Justinmind will need to process the information.
Comments have been locked on this page!