more and more i come across the need to show my webapp in mobile.
my problem is that i have many forms with big grids, and it looks very bad and different on mobile (tablets and phones).

how can we overcome this problem?
anybody care to share some tips on how to make an IW app that was built for desktop browsers, look good on mobile, and as close to desktop browsers as possible please?

more and more i come across the need to show my webapp in mobile. my
problem is that i have many forms with big grids, and it looks very
bad and different on mobile (tablets and phones).

how can we overcome this problem? anybody care to share some tips on
how to make an IW app that was built for desktop browsers, look good
on mobile, and as close to desktop browsers as possible please?

17 will have much better mobile support, but you can do mobile now. For
grids and such though you probably need some comps from TMS or CG to do
what you want.

Steven is exactly right! I had to reach that conclusion after banging my head against the wall in many attempts to put grids in a mobile application. I think we get caught up in the "responsive design" school of thought. It's much easier to make static pages responsive to desktop and mobile. Presenting large amounts of data does not always make sense in a mobile application. I always remind myself that the mobile interface does not have to be an exact copy of the full screen version. It can't ever be that!

I would also advise using the CGDev mobile controls for the entire interface. I was using TMS iPhone Controls (poorly named) because they work in any Webkit browser, which is every mobile browser. I resisted the CGDev Mobile stuff because it was so different. I forced myself to watch the YouTube videos over and over until it made sense. I then forced myself to create a simple project with a few pages. Once I understood how it worked I started switching every form in the first project to CGDev. They give you a much more mobile friendly interface, and you can use the Themes to control styling. It was well worth the few days I put into research and development.

Go back to the CGDev Mobile demo and look at all of the controls you can utilize. They give you ways to do more in the tiny mobile screen space. It went so well that I even created tablet specific pages in some instances.

I plan to do the same type of deep dive into IWBootstrap so I can have another option as well. There have to be instances where its responsiveness can handle the whole project.

so basically you're saying that i should DOUBLE the whole project (desktop AND mobile forms) with all it's 150+ forms and frames...?
damn...

ok, so i will use ListViews as "grids", but what about the menu?
i didn't see any component that can behave proprly as a menu with sub\sub\menus

and i know i shouldn't blast the forms with tones of information like i did in the desktop version(which i had to...), but should i "educate" my users to use only tablets for that?
there are still many forms with quite a lot of info to show or input (like big tax invoice receipts with reminders).

so basically you're saying that i should DOUBLE the whole project
(desktop AND mobile forms) with all it's 150+ forms and frames...?
damn...

I'm not saying you should. I'm saying its one approach and its the one
that for my needs I've found to be the best approach.

An easier approach may be to do only some forms and share others that
may work ok on mobile.

ok, so i will use ListViews as "grids", but what about the menu? i
didn't see any component that can behave proprly as a menu with
sub\sub\menus

You could also use frames and swap them in and out on the fly on a form.
You could even make it a component.

"educate" my users to use only tablets for that? there are still many
forms with quite a lot of info to show or input (like big tax invoice
receipts with reminders).

One desktop page often becomes several separate pages for mobile.

Mobile screens are smaller, and even if you use a responsive layout you
will have similar issues in many cases. Responsive layout in my
experience tends to dumb down the desktop experience or only work on the
simpler forms.

This is why for my use I prefer 2 sets of forms. I find it works better,
but every situation is different.

In the few apps I have added mobile support to it has been to provide specific features and not try and replicate my entire app. I have a specialized inventory management system for large outdoor storage yards. The client does not want process orders on their phone, but planners and managers do want summary information that is updated and workers in the field want to be able to locate specific parts and mark them to be ordered.

One thing I try to do is make sure my desktop app looks okay on a tablet in landscape mode , as some users will want the full experience, but they realize that requires more screen real estate.

Cheers!

- Lou

Eitan Arbel wrote:
so basically you're saying that i should DOUBLE the whole project (desktop AND mobile forms) with all it's 150+ forms and frames...?
damn...

ok, so i will use ListViews as "grids", but what about the menu?
i didn't see any component that can behave proprly as a menu with sub\sub\menus

and i know i shouldn't blast the forms with tones of information like i did in the desktop version(which i had to...), but should i "educate" my users to use only tablets for that?
there are still many forms with quite a lot of info to show or input (like big tax invoice receipts with reminders).

I have an app in which I look at the browser type (UserAGent) in TIWServerController.IWServerControllerBaseGetMainForm )and go from there by presenting mobile login form and user then gets mobile forms etc..... For phones, I start with iPhone6, unless the end user specifies larger phone as defeult. I find many times that my desktop forms display great on tablets and dont't have to adjust. I am working on a current project where user will primarily use iPhone6 with desktop being 2nd. I am using CGDevtools and will be checking out their mobile demo again to get better handle on using their components.

-Lou

S. Mahaux wrote:
How do you set that up and choose which form to display ?

Personally I've had a constant battle with mobile. I mostly use html, css, and javascript utilizing the TemplateProcessorHTML and less so much Intraweb itself. That being said I just use regular bootstrap when dealing with most things for my web applications.

If you are designing something from the start one thing I've found to work is figuring out a design that works for both your mobile and webpages at the same time. My latest project does this approach and with it's simplicity is just a single form with various IWregions linked to other TemplateProcessHTML to act as popups and such.

The other method is mentioned previously where you have two separate forms and depending if it is mobile or not you load the according form. This has worked well so far until I've started getting complaints from clients for the request desktop version setting on mobile phones not displaying the pages correctly. Currently I can't figure out which call to make in intraweb to have it switch forms like this. Maybe i'm missing some setting somewhere but currently that is the struggle with mobile at this point. Hoping IW 17 makes life easier for me to develop sleek responsive webpages that work on both pc and mobile.

Note: If anyone has a way to deal with the request desktop version from mobile I'm all ears.

What do you mean by "the request for desktop version from mobile users"? Do they want to use the full page version on their phones? That would mean a lot of pinching, zooming and scrolling. If that is the case, you could detect mobile and then present a form asking them which view they would like to see. You could record the preference so they only have to answer once. I have done this to distinguish a tablet from a PC interface. In one instance I had a desktop, phone and tablet version of each form.

You have to realize that you only make this mobile versus desktop decision for the first form. The forms themselves will keep the use in the selected interface. Your mobile forms will call other mobile forms, not their desktop equivalents.

Daniel Fields wrote:
What do you mean by "the request for desktop version from mobile users"? Do they want to use the full page version on their phones? That would mean a lot of pinching, zooming and scrolling. If that is the case, you could detect mobile and then present a form asking them which view they would like to see. You could record the preference so they only have to answer once. I have done this to distinguish a tablet from a PC interface. In one instance I had a desktop, phone and tablet version of each form.

You have to realize that you only make this mobile versus desktop decision for the first form. The forms themselves will keep the use in the selected interface. Your mobile forms will call other mobile forms, not their desktop equivalents.

That's kind of where my problem lies. I decide at the start whether they are going the mobile or desktop route but then after that first form they can't change their decision unless they log out and go back to that initial form.

The only solution I can think of in the future is rewriting everything to be based on screen resolution size and deciding how the page looks based on the page width therefore only needing to use 1 form and not separate forms for mobile and desktop browsers. Will take a lot more time but probably be worth it in the end. Sorry for late response been a hectic few weeks.

That's kind of where my problem lies. I decide at the start whether
they are going the mobile or desktop route but then after that first
form they can't change their decision unless they log out and go back
to that initial form.

You could do it on a form by form basis and even share some forms. That
way only certain forms are specially designed for one or the other,
while others may be shared. You can simply make a custom show method
which determines which one to show based on a flag you set in the user
session.

* IWBootstrap - a great system, but doesn't support BiDi\Right-To-Left languages.
i'm guessing it's because of the jQuery version it uses.

* CGDevTools Mobile - based on jQuery 1.3.2 that also doesn't support BiDi\Right-To-Left languages - NOTHING worked for me as it should have...

i received several proposals for my app, but of course all of them ask me to "finish" the mobile version\look
i almost finished my big (150~ forms) IW app, but since most people these days test\check\try through their mobile - i am REALLY desperate and need mobile forms, and don't know what else i can try

* IWBootstrap - a great system, but doesn't support BiDi\Right-To-Left languages.
i'm guessing it's because of the jQuery version it uses.

* CGDevTools Mobile - based on jQuery 1.3.2 that also doesn't support BiDi\Right-To-Left languages - NOTHING worked for me as it should have...

i received several proposals for my app, but of course all of them ask me to "finish" the mobile version\look
i almost finished my big (150~ forms) IW app, but since most people these days test\check\try through their mobile - i am REALLY desperate and need mobile forms, and don't know what else i can try

Mobile is still a challenge. 17 will support it much better, but I know
that doesn't help you right now. Users are however successfully
deploying apps using IntraWeb to mobile and maybe Alexandre or others
can chime in.