>>What we have found is that even the most complex forms are best rendered in a way that they could, in fact, be rendered on a phablet or larger, and most functions can fit on a >phone. In fact, we have been redesigning the VFP forms to work in this manner -- because the users like them better.
>
>Would take the time and explain how you are designing the VFP forms to work on all three devices. Maybe an example.
>
>Johnf
Hi John,

Attached is a reworked form.

Each Circled section would become a collapsible section on a grid. The top (Sku information) would remain uncollapsed. All this is done by setting attributes, including setting a height at which the sections would appear initially all collapsed, whether only one section at a time is uncollapsed, etc.

The grid, on a small device, is getting a new control in the current beta: this would be the only issue I can see. If the new phone-size grid becomes cards, which is the standard, then no extra work would have to be done. Otherwise, we might have to create an alternative "page" marked for Phone Use that accommodated a Card type of display from jQuery mobile. Hmm... having an alternative "section" in a page would be nice: I'll go add that as an ER. :)

The hyperlinks would likely become a jQuery button footer menu (which is also done by setting attributes in the Section UI Attributes page). With a few lines of code a "page" saved as a library (reusable) page would, with one command (from the menu button event delegate), fly in (animation settable in attributes) for use, fly out when done.

If the form had been designed wider, the sections in Lianja would be created with invisible "columns" -- these would resize based on screen size, without additional programming. So, for example, the product section could be created with two columns of information, making that section shorter. When on a device size that couldn't fit both, the right column would slide under the left, etc.

If the "grid" section needed to be redone manually in a webview, Lianja would still handle all the ajax calls transparently. A call to getCursor() (made in JavaScript in the section) would get the object reference to the remote view (or table), and that object would then be connected to the columns in the normal way for whatever library you are using for the control(s). So we have the freedom to design as we want, while still getting the benefit of the data-oriented Lianja framework integration with the Cloud Server.

Frankly, it's a lot of new stuff to learn. It seems, though, to be a lot of learning at the point of producing a product, rather than working out details at the infrastructure level.

hth,

Hank