I'm aware of the general strategies for hiding the address bar, e.g. encouraging installation as home screen app and/or sometimes scrollTo hacks. In my case, however I am fine with the default behaviors. As the user navigates my app, the browser tends to eventually hide the scroll bar and that's fine.
My problem is, users need to do a lot of text editing in my app. When this happens, especially in landscape mode, the soft keyboard can take up tons of the visible screen but to make matters worse, the bar tends to re-appear! On top of over half the screen getting taken up by the keyboard itself, an additional 1/5th or so gets suddenly eaten back up by the address/tab interface even if it had gone away.
So I'm left with a tiny strip that the user can see, for no apparent reason.
I suspect this is a long shot, but is there any way to discourage these tabs from re-appearing? To be clear, the user is not trying to edit the URL, but has simply focused in an <input>/<textarea> to edit that.
Related
The problem: I'm working hard to implement a responsive UI in my app. But the keyboard IME on Android squishes my entire page layout into a frame that's about 96 pixels high when in landscape orientation. Typically this means that the input control being edited is not visible in the space above the IME. And one cannot edit a value that's not visible in Chromium. I'm assuming iOS has the same problem.
Setting a minimum height for the page helps. But the Chromium scroll-into-view implementation is not robust enough to keep up with some of the more complex page rewrites that are triggered by a change in window size in my app.
Ideally, I'd like to run the keyboard IME in "extract" mode, where the page is entirely hidden, and only the value being edited is displayed in the space above the IME. But as far as I can tell, there's no way to do that, even in Android native apps. Chromium never runs the keyboard IME in "extract" mode, even in landscape orientation.
The solution I'm current implementing: simulate "extract" IME mode by perform editing of values in a full-screen dialog that contains nothing but a single dedicated <input>.
The question is: how should I detect when to use this solution. it's easy enough to check the browser's navigator.userAgent. The Mozilla foundation recommends checking for /Mobi|Android/ (although I've seen solutions that have 40 or 50 patterns). But I'm wondering whether there's a feature-driven way to check for this instead -- something more along the lines of if ("geolocation" in navigator) ....
But as far as I can tell, there are no features related to whether and how a keyboard IME will change the layout of a page. If there are, I'd like to know. The "feature" I'm looking for is something along the lines of "Will this browser lay out my entire page in a frame that's 96 pixels high (in landscape) whenever an input control gets focus". But "does this browser uses a keyboard IME" would be satisfactory.
Any ideas appreciated.
That's quite a mouthful! I'm testing some things regarding web apps, so my test page goes fullscreen using webkitRequestFullscreen
I then decided to test how an <input type="text" /> would affect the fullscreen-ness. Sure enough the keyboard comes up just fine, but the content of the page is hidden behind it... including the input field the user would be typing in. Typing blind isn't fun.
I'm trying to figure out the screen size after the keyboard takes some of the space, so that I can adjust the page in such a way that the field becomes visible. However, properties like screen.height, window.innerWidth and the like all show full-screen values (360x640) regardless of the keyboard being present or not.
Are there any other ways of getting the screen size, while in fullscreen, and factoring in the virtual keyboard's presence?
Here's a demo, try in Chrome on mobile: link
Durandal provides a modal dialog facility which works great on desktop devices, and it allows you to control the presentation of the dialog via the "dialog context".
The default dialog context will, among other things, "display your dialog's view centered on the screen." Observationally, I can see that this means centering the dialog in the viewport--which means that as you scroll up and down, it remains in the same location, in the middle of your viewport.
This works fine a screen large enough to see the entire dialog; but on mobile devices, particularly phones, the dialog may be larger than the screen, especially if the user zooms in. When this happens, it is impossible for the user to pan around the dialog.
I would like to change this behavior by using a custom dialog context that positions the dialog in the center of the viewport initially, but then leaves it anchored to a fixed spot on the page, so the user can pan around.
So far I have been unable to figure out how to setup a custom dialog that observes the regular Durandal defaults, except for the "center in the viewport" rule. I'm not even positive I want or need to do this as a custom context; there may be a CSS rule that will accomplish this? Any help would be greatly appreciated.
As suggested by Abhinav Gauniyal and PW Kad (thank you!), a CSS solution turned out to be much simpler than a custom context.
After some digging, I found that by changing position: fixed to position: absolute in durandal.css, on the .modalHost rule, I was able to get the behavior I was looking for.
Better would be a completely separate UX for mobile devices that was tailored to their screen size, and that's definitely the direction we want to head--but today I wanted to at least make it possible for existing users to pan around and see the entire modal dialog, instead of leaving them with something completely unusable until we've got a "complete" mobile UX in place.
I have a full-screen game in HTML+JavaScript, which uses the arrow keys as primary controls. This cannot be used on keyboardless Android devices (I haven't tested on iOS), and even if the soft keyboard had arrow keys it would take up unnecessary space. Therefore, I have added onscreen control buttons. However, the buttons are unnecessary (and absurdly large) on desktop browsers, so I would like them to not pop up unless they are needed.
What heuristics can I use to decide whether they are needed — that is, whether it is impossible or awkward for the user to input arrow-key events — other than recognizing specific User-Agents (which is straightforward, but not future-proof)?
I will of course allow the user to hide/show the buttons; I am looking for useful heuristics for choosing the default setting.
No need for any user-agent sniffing, config options or any kind of guessing. Just do this:
Have a title screen which says "press to continue".
On click or key press, hide touch controls and start game.
On touch, show touch controls and start game.
You never even needed to mention the option to the user and you auto-detected their preferred control perfectly.
Use feature detection with Modernizr: http://www.modernizr.com/docs/#touch
While this is not a reliable way to check if the user has a keyboard it is definitely reliable to see if the browser is capable of touch.
Instead of trying to guess, make it a config option for the user to choose.
If you have only arrows (left/right/up/down) you might consider adding touch-events inside the game field? This would not take up space obviously as it is layered on top of the game, so it could be 'always on'.
A computer user would not even know it is there, though he/she could use them to play your game with a mouse I guess.
The touch-device user on the other hand can much more easily use the "areas" (mid top, mid left, mid bottom and mid right for instance) because of .. well.. touching instead of using a mouse.
This might need some explaining, as you probably would not want the points to be visible to the user, but it feels like a valid option.
Even if you have 4 buttons and a 'fire', you could do this, for instance by adding a 'middle' section.
look for touch specific events such as touchstart or gesturestart and show the onscreen controls if detected.
http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/HandlingEvents/HandlingEvents.html
I am not sure if the system-info api has been implemented by any browsers:
http://www.w3.org/TR/system-info-api/
rather than displaying the on-screen keyboard by default, add a button to toggle the display of the on-screen keyboard.
It might also be prudent to give the on-screen keyboard the ability to be resized.
Edit to answer question:
Keyboard should be hidden by default if most of your users are going to be on a computer,
Visible by default if most of your users are going to be on a mobile device.
You can consider checking the display size. If the display size is smaller than a certain size, you can assume that it is a mobile device and can display the Arrow Buttons. Other wise use keyboard buttons.
You can also keep an option so that user can set this manually if needed.
You could use javascript to find out the height of the windows view port and then us an if statement saying:
if ($(window).height() <= "960")) {
//Your code to display keyboard controls
//P.S. 960 is height of iPhone 4+ screen
}
Edit: Left out ) at end of $(window).height() <= "960"
I've found some wierd behaviour related to scrolling and rendering and javascript.
How to make it happen:
On any webpage that is long enough to scroll on. Start to scroll pretty fast (fling the page). then release the touch.
Now while the page is still scrolling because of the momentum. Tap the screen to stop the scroll.
This make the browser enter a wierd mode.
On the nexus one it behaves like this:
The updating of what's shown on the screen stops, you can still click on links and the go to where they are supposed to but what's shown on the screen stays the same.
If you then scroll the screen a bit the update of the screen kicks in again and what you you where suppsed to see all the time is shown.
On all phones with HTC Sense I've tried (Hero, Desire, Legend) this happens:
The updating of the screen is stopped just like on the nexus one, but also the execution of any javascript is stopped.
If you click on a link that takes you to another page however things return to normal again.
The way I tested this was I created a page like this:
http://pastebin.ca/1881620
The changeColor function simply changed the background color of 'container' to a few different colors.
So before the error what happens is that when you click any link the color changes.
after the error this happens:
Nexus one:
when you click on the links nothing happens (except the "orange link selected rounded corner box thing" is shown as if the link is clicked). Then when you scroll abit.
You can see the color has changed (and equal amount of times to the number of times I clicked the link).
On Sense:
The links take me to google.com
Has anyone else noticed this problem? Is there anyway to work around it?
Thanks.
You could try using a plugin that manipulates the browser's scrolling process, such as iScroll4.
iScroll4 let us do some pretty cool stuff (like fixed headers/footers), but it did have some performance problems in some of the older/crappier Android phones...
I can't guarantee that it'd fix your problem, and it'd be kind of a last resort, but it might be worth trying if you're interested in iScroll's other features, or if you've hit a dead end with your bug, and it's a show-stopper for your app.