If you have questions or if you want to share your opinion about Aware IM post your message on this forum
#53999 by RLJB
Mon Jun 01, 2020 11:18 am
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)
#54002 by hpl123
Mon Jun 01, 2020 1:50 pm
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):
1.PNG
1.PNG (27.33 KiB) Viewed 902 times

2.PNG
2.PNG (47.8 KiB) Viewed 902 times

3.PNG
3.PNG (28.59 KiB) Viewed 902 times
Last edited by hpl123 on Mon Jun 01, 2020 2:16 pm, edited 3 times in total.
#54003 by hpl123
Mon Jun 01, 2020 1:51 pm
Additional screenshots:
4.PNG
4.PNG (22.72 KiB) Viewed 902 times

5.PNG
5.PNG (30.8 KiB) Viewed 902 times

6.PNG
6.PNG (48.08 KiB) Viewed 902 times
Last edited by hpl123 on Mon Jun 01, 2020 2:13 pm, edited 1 time in total.
#54009 by RLJB
Tue Jun 02, 2020 4:24 am
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/ ... ayms=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.
#54028 by hpl123
Thu Jun 04, 2020 7:12 pm
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 :).
#54078 by RLJB
Fri Jun 12, 2020 3:26 am
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.

2. 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)
#54084 by hpl123
Fri Jun 12, 2020 12:45 pm
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:

1. 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):
Code: Select allhtml,
body
{
    overflow:unset !important;
}


2. Create a custom class in your custom CSS file for the app where you add:
Code: Select all.mycustommobileformclass
{
height: 100%;
overflow: visible !important;
}


3. 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.

4. Add the following CSS style override to your mobile form. I use it with a <style></style> tag in the form header:
Code: Select all.k-scrollable
{
overflow: auto !important;
}


5. 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.
#54143 by hpl123
Fri Jun 19, 2020 8:57 am
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:

1. 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):
Code: Select allhtml,
body
{
 overflow:unset !important;
}


2. Create a custom class in your custom CSS file for the app where you add:
Code: Select all.mycustommobileformclass
{
height: 100%;
overflow: visible !important;
}


3. 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.

4. Add the following CSS style override to your mobile form. I use it with a <style></style> tag in the form header:
Code: Select all.k-scrollable
{
overflow: auto !important;
}


5. 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.
#54155 by hpl123
Sat Jun 20, 2020 7:56 am
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:

1. 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):
Code: Select allhtml,
body
{
 overflow:unset !important;
}


2. Create a custom class in your custom CSS file for the app where you add:
Code: Select all.mycustommobileformclass
{
height: 100%;
overflow: visible !important;
}


3. 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.

4. Add the following CSS style override to your mobile form. I use it with a <style></style> tag in the form header:
Code: Select all.k-scrollable
{
overflow: auto !important;
}


5. 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).
#54309 by hpl123
Thu Jul 09, 2020 4:16 pm
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:

1. 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):
Code: Select allhtml,
body
{
 overflow:unset !important;
}


2. Create a custom class in your custom CSS file for the app where you add:
Code: Select all.mycustommobileformclass
{
height: 100%;
overflow: visible !important;
}


3. 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.

4. Add the following CSS style override to your mobile form. I use it with a <style></style> tag in the form header:
Code: Select all.k-scrollable
{
overflow: auto !important;
}


5. 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.

Who is online

Users browsing this forum: No registered users and 29 guests