Ask your questions for Eli and the rest of the Silicon Discourse community here.  Build your reputation by giving advice to others too!


My client is an investment adviser, who wants to visit his clients with a mobile application (basic form and a chart generator for the most part) which helps selecting best investment plan. As someone who stayed as a backend developer for many years this is not my comfort zone, yet I have to adapt because backend coding jobs are disappearing due to web-browser advancement. What I am unsure of is, what are user expectations on mobile devices vs an always connected desktop when dealing with form wizard navigation and data submission? He operates in Ontario Canada so cell service is usually not an issue. Should I still make provisions for app to be able to enter data on slow connection or even offline and submit the result whenever signal becomes active again, or is it OK for the app to gracefully exit with appropriate message?

My client says offline fallback is not high priority, however, I have my doubts because clients too often do not understand implications of what they are requesting, and I do not want to give him frustrating experience. Or is this not a question for a province with good infrastructure? Problem is, getting offline fallback working is more time consuming, do not want to keep him waiting, but do not want to compromise too much on reliability.


If offline fallback isn’t high priority I would release an app to do what is needed as soon as you can. The other stuff can come later as a update, or a added bonus. The faster release and then adding functionality is what I see with the developers at my job and is more accepted than trying to do everything at once resulting in more time without what is wanted. It makes the user give you feedback like thought it would do this or this and then you can add it, or it could even be there is too much going on in areas.  It can have a added effect of field testing options that are absolutely needed, and making those great.