Nintex Mobile – Runtime Rules Work on Android but not on iOS, Windows or Windows Phone

We get this question a lot that why some Runtime Rules work on Android but no on iOS, Windows or Windows Phone. So if you have created a validation rule or formatting rule in Nintex Form which works on Android but not the other mobile devices, most probably the issue is that you have used a custom JavaScript syntax instead of Nintex Form functions somewhere in your rule.

In most of the cases we have seen, users use == instead of equals(), > instead of greaterThan or < instead of smallerThan functions.

For example if you are writing a function to check age which is entered in AgeTextBox control you have to write it like this “greaterThan(18,AgeTextBox)”. This would work on all platforms but if you write it as “AgeTextBox > 18″ it would NOT work and is basically not supported.

To make sure your Rules work properly on all platform use the functions provided in by Nintex Form and avoid writing any custom JavaScript function in your Rules.

NF Rules Correct

 

Your Product Reflects Your Team(s)

Yes, I truly believe that a product is pretty much reflects the team(s) working on it, their standard and their work culture.

In the software industry we keep talking about getting closer to customers and hearing their feedback, validating features/products, market testing etc.. which are all very valid tasks and we should do them in most scenarios.

I think we sometime miss the point that instead of blindly listening to user’s feedback, we need to listen to them and then start working on providing the best solution considering all possibilities and constraints and this is something which has to come from the team, not the team manger, not the UX and not the product manager but the team which includes all of the above plus engineers and testers. Fair enough I have always been saying that one person should have the final say and I still believe in that but the point is that you cannot/should not expect one person to cover all the possible requirements,  quality measures and failure points. I dare saying that’s very, very unlikely that one person can cover everything and not miss one. If you are in a team which operates like that I bet yourself in situations where something has gone wrong and the engineers or QA would say “It was not part of acceptance criteria” and the product manager would say “We did not get that from the user testing UX team conducted” and the same sort of “excuses” from different people. This kind of team/culture would reflect in the product as either poor quality or missed deadlines.

In contrast, when every team member feels as equally responsible as the top manager, everyone feels like an owner of the product, is involved and would not close her eyes on something missed by another team member/process. For example an engineer would not only think about what is written in the user story but will also think about what is not written or how it could be improved and share it with the team.  The same with product manager and testers. They would look at the product as a whole rather than just doing what is written somewhere be it a user story or user testing result.  They’d challenge requirements, decisions and processes (in a positive way) and when a decision is made everyone moves on. This kind of teams/culture, reflects itself as high quality product which gets delivered on-time, because if UX or product manager misses something, it would be picked up by the developers or testers or someone else from the team. Well this does not mean that the team would absolutely miss nothing. They will but it will be much less and when it happens you won’t hear “it was not part of acceptance criteria” anymore but everyone would rather say “Yeah, I missed it (sorry)”.  As a result of this work culture, you find team members taking pride in their work and motivated to deliver a better product/feature each and every time.  why? because it’s their product, they are the owner and they are being heard when they give a feedback.

I am very lucky to work with teams like this which makes my job even more enjoyable. I’ll write another blog post on some of the techniques which have helped us setting such a culture in the teams.