Mobile forms and themes and design

RLJB

Has anyone really "cracked" a great looking mobile design?

If so, please share what theme do you use and how do you design a mobile form?

We 'kinda' have a good design, it's ok, I'd love to see how how someone does this really well (using Aware constraints).

(I will post a few screenshots and ideas about what we do, would love to hear feedback)

hpl123

Good initiative and I would also really like to see what others have done so sharing some screenshots from one of the apps I have done for a B&B business.

Some general thoughts about this:
Mobile Aware is today quite flexible and light years better/from where it was when I started using Aware in 2012/2013. It has really come a long way and today I would say it is possible to create quite good mobile apps in Aware. I have played around some (not a lot) with it and use it in a couple of different apps and the main thought/feeling I have when it comes to mobile Aware is, most things are possible but it will require quite a lot of tinkering IF you want to really do it well and make it work well (+ you ideally need to either have a graphical designer who knows Aware well restyle the entire mobile UI i.e override the Aware/Kendo UI with own stuff AND/OR integrate a professionally designed admin mobile template that has a lot of premade mobile "widgets", styles etc. that you after integration drop into you mobile app design). IMO the "default" Aware stuff looks/feels and works a bit "halfbuggy" / "semi-professional" and ideally I would rewamp the entire mobile app (like explained above) before presenting it to customers AND/BUT I have very high standards about these types of things so is in no way a comment to reflect badly on AwareIM, Awaresoft etc.. I understand (think I do at least) Awaresofts focus on stuff relevant for enterprises where functionality and reliability (i.e it should be able to do various things and do the things it does realiably) are the most important things and if that is the main focus, other things like UI/UX, design etc., meticulousness in ALL things like design, features, UI/UX etc. are not as important and/but if you are productoriented like I am i.e I try to use Aware for SaaS products and things like that, then I think unfortunately default Aware mobile (i.e without a lot of tinkering etc.) is not "good enough". Difficult to formulate exactly how I see it but I hope the description makes sense. NB: I do also use mobile Aware for various business things as well where I don´t do the things above and where implementing a "process" or getting some particular job done is what matters and the app I am sharing screenshots from here is one example i.e I have not done the full rewamp / integrate mobile template like above (mainly because it takes so much time and effort. I am working on a real rewamp like explained above but unfortunately don´t have any screenshots to share from that as it´s not that far along yet. I have done "proof of concept" though about a lot of the mobile design things so know it is possibe to create UI/UX wise really nice/professional mobile apps). The mobile app shown in the screenshots use the default bootstrap theme and is overridden here and there via a custom CSS file (+ some additional HTML widgets and stiff integrated) and the theme is not that important IMO, it is only the starting point so select the theme that is graphically similar to the "main app", company brand etc. and then override and customise it to your needs.

Another thing worth mentioning here is responsiveness and mobile/tablet design. The way Aware works today with it´s various features to differentiate between mobile, tablet and desktop is starting to become a bit obselete and not work any more because of the way newer smartphones work and to give you one example. I have a Samsung Note 8 and Aware interprets that as a tablet which it is not which causes problems if you for example design one VP for mobile and one for tablet (i.e Aware will present the tablet VP and not the mobile VP) and this problem will only increase as newer smartphones have other/better resolutions etc. so Aware needs to be able to determine device type in a better and more reliable way if we are to continue using the current feature set where we develop different VP´s for different devices. The way I solved it was to create a mobile/tablet view i.e 1 VP for mobile and tablet which works for both but that as you can imagine has a lot of drawbacks (limited in what one can develop as many things that can work/fit on a tablet, wont work/fit on a mobile etc.) + takes a lot more time. This approach also requires you do various hacks like for example "limit" the responsiveness design of HTML e.g in a mobile app you want a "widget" to expand fully horisontally (width) but that may not work on a tablet that has a lot more resolution real estate (on a tablet it might look like shit if you do that, just take a mobile Aware app and open it up on a desktop device and you will understand what I mean) so you have to design/hack it so it works well and looks good no matter the device and resolution. This and various other challenges makes the process slow so also in this regard, if you want to do it well, have it work well and look good you have to do a lot of tinkering.

Looking forward to see and hear what others have done.

Screenshots (only 3 screenshots a a time):

hpl123

Additional screenshots:

hpl123

Additional screenshot:

RLJB

Thanks for sharing Henrik, good insights and I agree with most of it.

Here is what we do: (had to turn this into a slide pack as the pics were too annoying to upload here)

https://docs.google.com/presentation/d/e/2PACX-1vQWY7QN2nl-ufDXH6Xwi1ssD8880vOhZ2oVgoP4Y--Lqyd1K76mZPKDe7maEDvXE3UpAIaoJSAG8iII/pub?start=false&loop=false&delayms=60000

There's some screenshot in the above of what our mobile apps look like, I'm not saying this is the best idea, so please tell us how to improve, please share some more of your screen designs too pls.

Also - if you have some tips please add to this thread.

hpl123

Thanks for sharing you too Rod and will probably only be us two that showcase and take part in this post lol. Your app looks nice as well and pretty straight forward i.e not a lot of custom stuff and/but looks like it gets the job done and is exactly my point from previous post. It is easy to make a app that gets a job done but doing an extraordinary mobile app and experience is another thing and/but still possible if you take the time to do it (and have some skills).

When it comes to tips etc. and sharing best practises. I am faily new to mobile apps in Aware so don´t have a lot of tips really but here are some stuff/thoughts from my experience with mobile Aware:

I am always trying to think good UI/UX and I am currently doing a "systematic" approach to menu etc. and is kind of a frame I try to always use to achieve better UX. The frame is left menu button to the top left that opens up a default Aware slide in menu. Logo to the right of left menu buttton and then a "Home" buttom in the top right and I have this frame for all pages in my app to simplify navigation and get a better UX. I also have a startpage that has all operations but with large buttons instead (i.e same operations as in the left menu) so if a user press an operation, they can use the operation result/layout etc. and then quickly get back to start pressing the "Home" button. I also have various alerts on the startpage and I have 3 different types of alert (info, alert or error) and all 3 show on the top above the startpage operation buttons (you see 1 alert in the screenshot above). I find this works and is easy for users to understand and use.
I have as you can see used the custom template quite a bit and is very powerful for data presentation but takes some time to actually design etc. it and is to be expected and I am glad Aware has the option to do it so we are not locked down like in the old Aware days. I usually find HTML snippets of different kinds for the thing I want to present and then hack it into something that works in a custom query.
The scrolling is a bit buggy/jumpy here and there as you also point out and the CSS tip I shared with you on some other occasion helps but it is still not 100% ideal.
Form design is tricky. I have found a form design etc. that works and removes kinks from the current mobile Aware setup and is the last screenshot you see above (PS: This particular form is "public" hence the language buttons and no left menu etc.). I have a instruction at the top followed by the attributes, toggles and buttons used in the form (all these things are HTML elements/snippets so I basically hide the "real" form header and buttons and then just use the form area to implement whatever it is I need to do. I am also as I wrote above doing a mobile/tablet layout so the form works equally well on mobile and tablet and it doesn´t take up the entire screen for tablets etc. but rather show a reasonable sized tablet form. The problem with this form design etc. is it is a bit limited in what I can do but no matter the attribute I add etc., I do custom CSS changes to basically all of then to adapt it to the rest of the app and form design i.e I try to go into as much detail as possible for all parts of the form. When I need to use images or references etc. on a mobile app "page", I almost always use a Aware form as the "backbone" and use the same design as described above and then just style the form which makes UI/UX easier/ better but does create some more work and is what it is. When working with forms there are also some various bugs or things that makes forms in Aware difficult to use e.g one thing is, if you have a long form i.e a form with many attributes where the user has to scroll, when the virtual keyboard pops up, on some mobile devices Aware "shifts" the entire content upwards and off screen (and it is not moved back when the users collapse the keyboard again). This and other things can be solved via HTML/CSS changes (and the odd JS function) and/but what exactly to do is not something I can share here but it is possible to "fix" it (the problem with this particular thing is some divs Aware has as part of the main html document that mess up the margins etc. for other HTML parts when the keyboard is expanded). It takes a whole lot of tinkering unfortunately to do a really good form. I like your form design and the label up top of attribute and is also something I tried but decided not to do for some reason (can´t remember what lol).
Custom CSS. I use A LOT of custom CSS all over the place and is in most cases to make small adjustments of margins, move things around, "fix" bugs etc. or just add new cool stuff and most things can be adjusted and changed which is awesome and it works. I usually as I wrote above select a theme as a starting point and have it somewhat match the brand or main app and then I create a new custom theme which I style until I am pleased. After that I try to use various HTML widgets and things and I always try to use the same style (and UX) throughout the app to do what I can to create the best UX for the end user. I also use jQuery here and there to change things in Aware frontend that we cannot change ourselves.
"Install" on home screen. I use a custom login form that has all logo icons and specific configurations in place to enable the user to add the mobile app to their home screen and get a nice app logo, app/brand colors eg. in top status bar (where the clock is displayed) etc.. I have also done a proof of concept of a real PWA installer for Aware apps (not sure you how familiar you are with a PWA installer but is a very simple and professional way users can "install" a mobile app to their homescreens. I think you were part of the other post where we discussed PWA and I showed some examples. Look at that post for an example of a PWA installer) and I might offer this as a "plugin" for Aware developers in the future as it really is a good alternative to having a native app and as I wrote in the other post, I think PWA is in and native is out so I am aiming at doing all my apps PWA instead of native i.e when I offer a SaaS app or similar I implement the PWA installer and that is it and the way the user can access the mobile app. I do of course hope Aware gets better native in the future for there are uses for it and functionality a webapp and PWA can´t do but until then, I am pleased with the setup I have.
I am working on a complete rewamp of mobile Aware (like described in my initial post above) and is basically an integration of a mobile admin template and that really takes the mobile app to the next level as all things basically available in the mobile app template, will be available to use in the mobile Aware app and then you can do any mobile app you want basically (design wise at least, we are still limited to that Aware can do featurewise and/but the beauty with Aware is we can integrate other things as well if we want but takes the complexity ot mobile apps to a new level as well). This is a slow and tedious process though so not ideal to use in most cases and for most apps as it takes so much time and effort but there are uses for it if you for example want to really develop/release a high quality (UI/UX wise primarily) product/app where mobile and tablet of course has to match the desktop app in UI/UX etc.. I have very high standards so I would IDEALLY do this for all mobile apps and if I have unlimited time and resources I would 🙂.

RLJB

Good followup post Henrik.

It's kind of interesting that no one else posts here, I guess this is because no one else has focussed on mobile (?). There are definitely some major show stoppers in Aware that if you can't work around you are not going to deliver a very good mobile experience.

I agree that it seems that custom CSS is the only way to make it fly. We still have two issues, one you have pointed out:

1.
if you have a long form i.e a form with many attributes where the user has to scroll, when the virtual keyboard pops up, on some mobile devices Aware "shifts" the entire content upwards and off screen (and it is not moved back when the users collapse the keyboard again). This and other things can be solved via HTML/CSS changes (and the odd JS function)

This one is a major issue, it basically stops the form being usable on some devices (iPads suffer bad form this). We have never figured out a way to fix it.

the other is horizontal scrolling, the forms can slide left and right and it isn't a great experience, I guess some further CSS is the answer

Henrik have you used the Custom HTML forms at all for mobile? While it would be a lot of work I was thinking this approach might deliver a top user experience. (we used them once on a desktop form and it worked nice but there are some limitations to it so it is only suitable in certain use-cases)

hpl123

Yes, too bad no others share and participate, I am not suprised 🙂. It might also be as you say nobody else is digging into these things or using mobile much.

Regarding both of these issues, they are solvable via CSS and as both of these are no "just do this" problems and also I think depends a bit on app layout and theme used, I have no "formula" but here are some tidbits from my head and notes on these things if it helps:

The first one is something I struggled a lot with and is a combination of many different things, adjustments in CSS etc. and the main thing that got me on the path to finding a solution was doing changes to the CSS overflow properties for the entire body + for the layout where I use a form + adding some small CSS adjustments here and there. Try doing the following:
Override the overflow set for html/body by Aware to (do the override ONLY for mobile VP´s as it messes up things in the desktop VP so have the override for example in a HTML content panel at the top of your mobile VP using a <style></style> tag):
```
html,
body
{
    overflow:unset !important;
}
```

Create a custom class in your custom CSS file for the app where you add:

.mycustommobileformclass
{
height: 100%;
overflow: visible !important;
}

Add the new custom class as a class used by the content panel (i.e set "CSS class" in the VP configuration for the content panel) that displays your form in your mobile VP.
Add the following CSS style override to your mobile form. I use it with a <style></style> tag in the form header:
```
.k-scrollable
{
overflow: auto !important;
}
```
Test form on a mobile, the keyboard problem etc. and make small adjustments to margins etc. if needed. The form height and content panel height has to be UNSET i.e not set if I remember correctly.

I am not sure if I have made other changes via custom CSS files, startup.html or forms that contributes to it being solved for me (I also have various other configuration parts related to this to enable my mobile/tablet uniform design which may contribute) but try it (I THINK it will work for you) and report back if it does and if so, we can maybe report to Vlad and he can look at a real fix for this for core Aware IM.

The second one (if I understand you correctly) is also a bit tricky. I have no horisontal scroll issues at all (after tinkering) so is entirely solvable via CSS as well. In Aware mobile the setup of the different divs etc. and it´s CSS creates some inconsistencies (mostly related to CSS margins + Aware having many many container divs. If you look at the DOM of an Aware form for example you see a very long tree of things that affect the actual form end result) and there and a 2 parts of this particular problem I have changed via CSS: Manipulate overflow-x (hide if in most cases if horisontal scroll is not needed) + change margin for rows (.row classes) where Aware adds a margin of 13px I think it is in different places (or if it is Bootstrap that messes it up with the row CSS, I can´t remember which). Aware also adds 20px to some left side margins and 10px to others and this also creates problems.

Regarding the custom HTML forms, I have actually not used these and great as they are, I was concerned about performance and also to some extent with security. I am not sure how Awaresoft solved it and if they hacked up some solution to make it work (no offense Awaresoft 🙂 ) so felt a bit icky to me 🙂 + I have managed (via a lot of tinkering) to do what I want with the existing Aware forms. I also use forms in many places instead of queries to deliver a uniform UI/UX (form with references thing I wrote about in my last post). I might look into it some more in the future though and what you did looks really nice so I understand it is a powerful/nice feature and might be the easier path compared to how I do it BUT it has it´s limitations so isn´t fix all solution to form problems either.

hpl123

hpl123 wrote
Yes, too bad no others share and participate, I am not suprised 🙂. It might also be as you say nobody else is digging into these things or using mobile much.

Regarding both of these issues, they are solvable via CSS and as both of these are no "just do this" problems and also I think depends a bit on app layout and theme used, I have no "formula" but here are some tidbits from my head and notes on these things if it helps:
The first one is something I struggled a lot with and is a combination of many different things, adjustments in CSS etc. and the main thing that got me on the path to finding a solution was doing changes to the CSS overflow properties for the entire body + for the layout where I use a form + adding some small CSS adjustments here and there. Try doing the following:
Override the overflow set for html/body by Aware to (do the override ONLY for mobile VP´s as it messes up things in the desktop VP so have the override for example in a HTML content panel at the top of your mobile VP using a <style></style> tag):
html,
body
{
 overflow:unset !important;
}
Create a custom class in your custom CSS file for the app where you add:
.mycustommobileformclass
{
height: 100%;
overflow: visible !important;
}
Add the new custom class as a class used by the content panel (i.e set "CSS class" in the VP configuration for the content panel) that displays your form in your mobile VP.
Add the following CSS style override to your mobile form. I use it with a <style></style> tag in the form header:
.k-scrollable
{
overflow: auto !important;
}
Test form on a mobile, the keyboard problem etc. and make small adjustments to margins etc. if needed. The form height and content panel height has to be UNSET i.e not set if I remember correctly.
I am not sure if I have made other changes via custom CSS files, startup.html or forms that contributes to it being solved for me (I also have various other configuration parts related to this to enable my mobile/tablet uniform design which may contribute) but try it (I THINK it will work for you) and report back if it does and if so, we can maybe report to Vlad and he can look at a real fix for this for core Aware IM.

The second one (if I understand you correctly) is also a bit tricky. I have no horisontal scroll issues at all (after tinkering) so is entirely solvable via CSS as well. In Aware mobile the setup of the different divs etc. and it´s CSS creates some inconsistencies (mostly related to CSS margins + Aware having many many container divs. If you look at the DOM of an Aware form for example you see a very long tree of things that affect the actual form end result) and there and a 2 parts of this particular problem I have changed via CSS: Manipulate overflow-x (hide if in most cases if horisontal scroll is not needed) + change margin for rows (.row classes) where Aware adds a margin of 13px I think it is in different places (or if it is Bootstrap that messes it up with the row CSS, I can´t remember which). Aware also adds 20px to some left side margins and 10px to others and this also creates problems.

Regarding the custom HTML forms, I have actually not used these and great as they are, I was concerned about performance and also to some extent with security. I am not sure how Awaresoft solved it and if they hacked up some solution to make it work (no offense Awaresoft 🙂 ) so felt a bit icky to me 🙂 + I have managed (via a lot of tinkering) to do what I want with the existing Aware forms. I also use forms in many places instead of queries to deliver a uniform UI/UX (form with references thing I wrote about in my last post). I might look into it some more in the future though and what you did looks really nice so I understand it is a powerful/nice feature and might be the easier path compared to how I do it BUT it has it´s limitations so isn´t fix all solution to form problems either.

Aaarrrggh, I found some issues related to IOS today with the described above approach where it doesn´t work and instead freese scrolling in queries. Back to tinkering 🙁. Shit problem this to have, it has to be able to be solved in some way.

hpl123

hpl123 wrote
hpl123 wrote
Yes, too bad no others share and participate, I am not suprised 🙂. It might also be as you say nobody else is digging into these things or using mobile much.

Regarding both of these issues, they are solvable via CSS and as both of these are no "just do this" problems and also I think depends a bit on app layout and theme used, I have no "formula" but here are some tidbits from my head and notes on these things if it helps:
The first one is something I struggled a lot with and is a combination of many different things, adjustments in CSS etc. and the main thing that got me on the path to finding a solution was doing changes to the CSS overflow properties for the entire body + for the layout where I use a form + adding some small CSS adjustments here and there. Try doing the following:
Override the overflow set for html/body by Aware to (do the override ONLY for mobile VP´s as it messes up things in the desktop VP so have the override for example in a HTML content panel at the top of your mobile VP using a <style></style> tag):
html,
body
{
 overflow:unset !important;
}
Create a custom class in your custom CSS file for the app where you add:
.mycustommobileformclass
{
height: 100%;
overflow: visible !important;
}
Add the new custom class as a class used by the content panel (i.e set "CSS class" in the VP configuration for the content panel) that displays your form in your mobile VP.
Add the following CSS style override to your mobile form. I use it with a <style></style> tag in the form header:
.k-scrollable
{
overflow: auto !important;
}
Test form on a mobile, the keyboard problem etc. and make small adjustments to margins etc. if needed. The form height and content panel height has to be UNSET i.e not set if I remember correctly.
I am not sure if I have made other changes via custom CSS files, startup.html or forms that contributes to it being solved for me (I also have various other configuration parts related to this to enable my mobile/tablet uniform design which may contribute) but try it (I THINK it will work for you) and report back if it does and if so, we can maybe report to Vlad and he can look at a real fix for this for core Aware IM.

The second one (if I understand you correctly) is also a bit tricky. I have no horisontal scroll issues at all (after tinkering) so is entirely solvable via CSS as well. In Aware mobile the setup of the different divs etc. and it´s CSS creates some inconsistencies (mostly related to CSS margins + Aware having many many container divs. If you look at the DOM of an Aware form for example you see a very long tree of things that affect the actual form end result) and there and a 2 parts of this particular problem I have changed via CSS: Manipulate overflow-x (hide if in most cases if horisontal scroll is not needed) + change margin for rows (.row classes) where Aware adds a margin of 13px I think it is in different places (or if it is Bootstrap that messes it up with the row CSS, I can´t remember which). Aware also adds 20px to some left side margins and 10px to others and this also creates problems.

Regarding the custom HTML forms, I have actually not used these and great as they are, I was concerned about performance and also to some extent with security. I am not sure how Awaresoft solved it and if they hacked up some solution to make it work (no offense Awaresoft 🙂 ) so felt a bit icky to me 🙂 + I have managed (via a lot of tinkering) to do what I want with the existing Aware forms. I also use forms in many places instead of queries to deliver a uniform UI/UX (form with references thing I wrote about in my last post). I might look into it some more in the future though and what you did looks really nice so I understand it is a powerful/nice feature and might be the easier path compared to how I do it BUT it has it´s limitations so isn´t fix all solution to form problems either.
Aaarrrggh, I found some issues related to IOS today with the described above approach where it doesn´t work and instead freese scrolling in queries. Back to tinkering 🙁. Shit problem this to have, it has to be able to be solved in some way.

It seems the solution above works for the keyboard popup shift problem on IOS as well but what doesn´t work is a particular custom query where scroll doesn´t work and might be unrelated when looking further into it so the solution above should still be SOMEWHAT ok (still a messy hack and we need a real fix for this).

hpl123

hpl123 wrote
hpl123 wrote
hpl123 wrote
Yes, too bad no others share and participate, I am not suprised 🙂. It might also be as you say nobody else is digging into these things or using mobile much.

Regarding both of these issues, they are solvable via CSS and as both of these are no "just do this" problems and also I think depends a bit on app layout and theme used, I have no "formula" but here are some tidbits from my head and notes on these things if it helps:
The first one is something I struggled a lot with and is a combination of many different things, adjustments in CSS etc. and the main thing that got me on the path to finding a solution was doing changes to the CSS overflow properties for the entire body + for the layout where I use a form + adding some small CSS adjustments here and there. Try doing the following:
Override the overflow set for html/body by Aware to (do the override ONLY for mobile VP´s as it messes up things in the desktop VP so have the override for example in a HTML content panel at the top of your mobile VP using a <style></style> tag):
html,
body
{
 overflow:unset !important;
}
Create a custom class in your custom CSS file for the app where you add:
.mycustommobileformclass
{
height: 100%;
overflow: visible !important;
}
Add the new custom class as a class used by the content panel (i.e set "CSS class" in the VP configuration for the content panel) that displays your form in your mobile VP.
Add the following CSS style override to your mobile form. I use it with a <style></style> tag in the form header:
.k-scrollable
{
overflow: auto !important;
}
Test form on a mobile, the keyboard problem etc. and make small adjustments to margins etc. if needed. The form height and content panel height has to be UNSET i.e not set if I remember correctly.
I am not sure if I have made other changes via custom CSS files, startup.html or forms that contributes to it being solved for me (I also have various other configuration parts related to this to enable my mobile/tablet uniform design which may contribute) but try it (I THINK it will work for you) and report back if it does and if so, we can maybe report to Vlad and he can look at a real fix for this for core Aware IM.

The second one (if I understand you correctly) is also a bit tricky. I have no horisontal scroll issues at all (after tinkering) so is entirely solvable via CSS as well. In Aware mobile the setup of the different divs etc. and it´s CSS creates some inconsistencies (mostly related to CSS margins + Aware having many many container divs. If you look at the DOM of an Aware form for example you see a very long tree of things that affect the actual form end result) and there and a 2 parts of this particular problem I have changed via CSS: Manipulate overflow-x (hide if in most cases if horisontal scroll is not needed) + change margin for rows (.row classes) where Aware adds a margin of 13px I think it is in different places (or if it is Bootstrap that messes it up with the row CSS, I can´t remember which). Aware also adds 20px to some left side margins and 10px to others and this also creates problems.

Regarding the custom HTML forms, I have actually not used these and great as they are, I was concerned about performance and also to some extent with security. I am not sure how Awaresoft solved it and if they hacked up some solution to make it work (no offense Awaresoft 🙂 ) so felt a bit icky to me 🙂 + I have managed (via a lot of tinkering) to do what I want with the existing Aware forms. I also use forms in many places instead of queries to deliver a uniform UI/UX (form with references thing I wrote about in my last post). I might look into it some more in the future though and what you did looks really nice so I understand it is a powerful/nice feature and might be the easier path compared to how I do it BUT it has it´s limitations so isn´t fix all solution to form problems either.
Aaarrrggh, I found some issues related to IOS today with the described above approach where it doesn´t work and instead freese scrolling in queries. Back to tinkering 🙁. Shit problem this to have, it has to be able to be solved in some way.
It seems the solution above works for the keyboard popup shift problem on IOS as well but what doesn´t work is a particular custom query where scroll doesn´t work and might be unrelated when looking further into it so the solution above should still be SOMEWHAT ok (still a messy hack and we need a real fix for this).

I can confirm the issue I wrote about above is unrelated to the hack/fix with keyboard shifting layout i e the above solution fully works/solves the keyboard shift problem on all devices.

aware_support

We cannot reproduce the keyboard problem, unfortunately. But maybe this solution will fix it - please let us know if it makes any difference and if it does we'll integrate it in the product.

Go to the properties of the form that exhibits the problem in the Configuration Tool
Open the Scripts property of the FORM (note - the form, not form section!!)
Add the following Initialisation script:
widgets.push ({
type: "mobileScroller",
id: parser.m_formId,
config: {}
});
Add the following "render script"
$("#" + parser.m_formId).addClass ("km-content").attr("data-role", "content").parent ().addClass ("km-view");

aware_support

Another possible solution is to add user-scalable=no to the <meta viewport ..> tag in the startup.html:

<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">

Could you please try that as well?

hpl123

Support,
Here is error report and how to reproduce or did you try this? Mobile form bug, virtual keyboard popup>

No matter what phone I try I get this problem. I will test the workarounds you have (the first one is new, the second one I am pretty sure I have tested and don´t work).

hpl123

hpl123 wrote
Support,
Here is error report and how to reproduce or did you try this? Mobile form bug, virtual keyboard popup>

No matter what phone I try I get this problem. I will test the workarounds you have (the first one is new, the second one I am pretty sure I have tested and don´t work).

I have not added the suggested workarounds and very strange, the BSV I created and posted (link above) in June does NOT present the same issue now i.e everything works as it should now when I try it (and it didn´t a month ago). I have a new phone (but use the same browser) and/so not sure if that is the thing. This has been an issue for years so either something has changed somewhere or this new phone handles this in another way. I have had this issue on ALL Iphone and Android phones I have tested it on in the past.

Can someone else that experiences this issue try it? Rod? Someone else? I will also try some additional things to see if it really is working fully or just works for the sample BSV I posted.

hpl123

hpl123 wrote
hpl123 wrote
Support,
Here is error report and how to reproduce or did you try this? Mobile form bug, virtual keyboard popup>

No matter what phone I try I get this problem. I will test the workarounds you have (the first one is new, the second one I am pretty sure I have tested and don´t work).

I have not added the suggested workarounds and very strange, the BSV I created and posted (link above) in June does NOT present the same issue now i.e everything works as it should now when I try it (and it didn´t a month ago). I have a new phone (but use the same browser) and/so not sure if that is the thing. This has been an issue for years so either something has changed somewhere or this new phone handles this in another way. I have had this issue on ALL Iphone and Android phones I have tested it on in the past.

Can someone else that experiences this issue try it? Rod? Someone else? I will also try some additional things to see if it really is working fully or just works for the sample BSV I posted.

Well, I am officially mindboggled. All works now also in a live app and the main app I had issues with and where I tinkered to the solution I wrote about above. Something has changed and I hope it´s permanent. Other experiencing this issue please confirm and I have no other phones ATTM I can try it on and/but I hope this is "global" and not just my new phone.

Jaymer

i have 2 diff iphones, + android + iPad.
will try it

rocketman

I'm just starting to tinker .... But before I do, I have just one question to ask if anyone knows the answer.

My App is a full blown back office admin system for gliding clubs with a number of VP's depending whether the member is part of the Office, finance or Operations team - or just a mere mortal member.

The mobile app I want to design is just a partial subset of what the desktop app can do - primarily for members to view certain things like their flying log books, their balances and let people know they are coming to fly.

So my question is - do I have to convert the entire app for mobile use or can I just recreate one VP as a mobile app. At the moment I have a VP optimised for phones but I'm finding that whilst it works well for iPhone users, not all Android phones are recognised as phones so the user gets the full blown desktop version. The technique I've been trying to use is by recognising the screen size - but with modern high res smartphone screens, that technique is not as reliable as it used to be.

I get round it by constructing a special url using the "mobile_platform=Phone" trick - but try trying to explain to a 65 year old glider pilot how to do that

hpl123

rocketman wrote
I'm just starting to tinker .... But before I do, I have just one question to ask if anyone knows the answer.

My App is a full blown back office admin system for gliding clubs with a number of VP's depending whether the member is part of the Office, finance or Operations team - or just a mere mortal member.

The mobile app I want to design is just a partial subset of what the desktop app can do - primarily for members to view certain things like their flying log books, their balances and let people know they are coming to fly.

So my question is - do I have to convert the entire app for mobile use or can I just recreate one VP as a mobile app. At the moment I have a VP optimised for phones but I'm finding that whilst it works well for iPhone users, not all Android phones are recognised as phones so the user gets the full blown desktop version. The technique I've been trying to use is by recognising the screen size - but with modern high res smartphone screens, that technique is not as reliable as it used to be.

I get round it by constructing a special url using the "mobile_platform=Phone" trick - but try trying to explain to a 65 year old glider pilot how to do that

A couple of things / thoughts:

Yes, you can/should create a separate VP for mobile and only include parts of your main app and one thing I did was to then build on it over time i.e start with essentials and keep adding features to the mobile VP.
Yes, the current Aware resolution solution i.e recognising which device is used e.g desktop, mobile etc. is not working fully any longer and I have gotten around this in 2 different ways:
- Create 1 VP for mobiles and tablets and that works with the current Aware device recognition but means you have to make sure the app layout works fully on phones and tablets.
- Create a separate mobile login form which has the hidden mobile platform parameter in it which means you don´t have to add it to the url. Just add the following to your form code for the mobile login form:
```
<input name="mobile_platform" type="hidden" value="Phone">
```
  You can also then if you want create a non Aware login form "launcher" with some JS code in it that accurately determines platform and then redirects the user to the "right" logon form for them. This is fairly easy to do and works and means you will always have 1 URL only for all users to use when logging into your app and then the form/code under that URL then determine platform and redirects.

Happy tinkering 🙂

hpl123

Jaymer wrote
i have 2 diff iphones, + android + iPad.
will try it

How did it go Jaymer, did you test this on your phones? We are still testing this (Rod, Vlad and myself) to try to find a solution and/but more tests is needed. I still get all working strangely enough from no additional changes i.e I have removed all my custom fixes and all works now :?: 😮 .