I'm building a mobile app that lives inside of a UIWebView and is written in sencha.
Right now, I have a page that has a ext.list containing <textarea> element inside of the rows.
When the user clicks on the text area, the soft keyboard comes up and pushes the screen as expected. However, if you try to scroll the list while the keyboard is up, the list will dart all the way down to the bottom. At this point, you can try to scroll the list back up to see the <textarea> (keyboard still up), but whenever you're done scrolling and remove your finger it will immediately stick you down at the bottom of the list again.
Once you dismiss the soft keyboard, the problem goes away. We want scrolling with the keyboard up, unfortunately.
Things I've tried:
*Use the scrollstart event to unfocus the <textarea> and dismiss the keyboard when scrolling begins works, but like I said, we want scrolling with the keyboard up
*Put the <textarea> on a toolbar, or just plain fix it to the middle of the screen. It doesn't seem to care where the <textarea> is. The main problem seems to be the keyboard + scrolling interactions.
I've looked around for some time now and cannot find anything on this. It seems most people are complaining about Android, which I haven't even explored yet. I feel like this has got to be something people are incorporating into their apps, though (like a search that displays results while you type and you can browse those results), so I must just be missing something? Does Sencha 2 fix this?
Thanks in advance. I can post code and/or a demo as per request.
Related
My website sometimes bugs, making it impossible to scroll the page using the mouse wheel, touchpad or finger. Dragging the scrollbar, pressing space or pressing page-up/down does work.
Any suggestions on what it could be, or how one would go about fixing such a bug?
There dosn't seem to be any specific action or page connected to the bug, it only happens about once every other day, and has happened on several devices, OS-es and browsers (even iPads and Android, IE11 and firefox).
Even hard-refreshing the page, or browsing to another page on the same domain dosn't fix the bug.
I've tried disabling Javascript in my browser, clearing all site data, scrolling with the touchpad instead of mouse, have checked the "html" and "body" elements for CSS rules that might block scrolling and even removed all html from the page and replaced it with mockup html.
I know the question is vague, with no example code, and I can't give an URL.
If anyone can point me in a direction, or have any tips, please help.
I do face the same situation, and what I do in such situations is:
Press the mouse wheel.
Move the cursor up and down on the page, still holding the wheel, till the page scrolls.
Let go of the mouse wheel.
You will now be able to scroll using the mouse wheel.
P.S: I'll edit this answer after some time with pictures and more explainations, till then, this should work.
EDIT: I've uploaded a video to youtube demonstrating the bug here: http://www.youtube.com/watch?v=zkDYlgtX5Hk
I've got a really weird bug that I found testing my new web application on a Samsung Galaxy S2 running Android 4.03 ICS.
What happens is that when you load a form in the default web browser and then scroll down the page, the hitbox/touchable area seems to stay where it was on screen when the page first loaded, even though the form element itself has scrolled up the screen.
As far as I can tell with the few testing devices I have available, I think this only happens on the Samsung Galaxy S2 as I have tried it in the Android simulator with the same version of android and was unable to replicate the problem. I know this makes it a very specific user base that haves the problem however last I checked the Galaxy s2 was the most popular Android handset in my country (Australia) so it would be nice to find a fix.
I have created a very simple page to demonstrate this at http://users.tpg.com.au/geoffica/test.html
You can replicate the problem by doing the following:
Load the page on a Galaxy S2
Scroll the browser so that page completely fills the screen and the address bar is just off the top of the screen.
Where the select box is, place your finger to the side of the screen as a marker of where the select list was.
Scroll down the page any distance, (while still keeping the select list on screen) then touch the whitespace where the select list used to be and the options should come up on the screen. It may take a few attempts to get it but it will happen.
Now I know you are thinking this is quite tricky to replicate and likely rare that it will happen, but on a form I built for a client because of where the elements were positioned, the hitbox always overlapped the submit button of the form, making it very difficult to hit the submit button. Select lists will also steal touches from other select lists if the hitboxes overlap, making the wrong options appear when touched.
I've tried many things but the only workaround I've found so far is to use the touchstart event to trigger my submit button instead of the click event. This seems to happen before the click event of the select lists and prevents it from getting in first, but this is far from ideal and doesn't stop the select lists from stealing clicks from other elements on the page.
I've also thought about rolling my own jquery plugin to maybe place the select lists offscreen and then trigger their click events by touching a link or something. If it's a mobile device then the options will come up on screen regardless of the position of the select list. This would be quite cumbersome however and I would need to factor in the effect this would have on users coming from a pc or iPad for example which shows the options in a dropdown list instead. It sounds pretty problematic to me. May even require some Galaxy s2 specific browser/device sniffing.
Does anyone have a real workaround for this, apart from just not using select lists?
Are you by any chance using absolute positioning for it? this will fix to a certain area on the screen not the page.
First, I would update the document header to a proper HTML5 header:
<!DOCTYPE html>
I think this might be a problem you can fix With Jquery-mobile
Just simple because when you do not use it , you website look very weird on mobile Browsers
May be this is the solution and this is just a hint :)
quick question regarding the TextEvent:LINK.
It stopped working recently when I switched my interface and I'm not quite sure why or how to fix it.
I have a movie clip which contains a text area and a scroll handler. 3 of these are added to my interface, although only 1 at a time is active in the display, depending on which tab you click.
All of that works fine, but once I change the chat object (textfield and scrollbar) in the display, it seems to stop working, and I'm not quite sure why. I'm not creating new instances all together, just adding and removing from a parent clip upon clicking different tabs.
Any idea what would be or could be causing this? As far as I can tell nothing is over or obstructing the clip containing the text field and scroll bar. The scroll bar actions work fine, which is next to the text field, however there seems to be no action going on as far as clicking links in the text field. I can select text in this text field as well, so I'm a bit confused :<
Thanks for your help.
Edit - Textfield is selectable, I know they need to be for the event to work.
I'm not entirely sure about the layout and the behavior of the project, but from my own bitter experience with TextEvents I learned that the less you mess around with the textfield, the better.
Maybe you should consider hiding the textfield instead of adding/removing it, i.e. changing the way the UI works without actually touching the affected elements in any way whatsoever.
If that's not possible, I'd try "rewriting" the text in the field and reattaching the event listener once the object is made visible again.
Hope you solve it quickly, texts are a pain in Flash.
I am currently attempting to make my application be more user friendly to those with difficulty seeing. As one would expect, I am using JAWS to test my application. Most of the issues I have run in were relatively easy to fix, except I am stumped on one.
In my application, I have advertisements injected via an iframe and I want JAWS to ignore them, but I still want them to display (display:none is out of the question). Is there any way to have JAWS completely ignore an element and all of its children?
I saw a few posts leading towards speak:none, but that does not work. It does seems to ignore the parent div, but it will instead reads the content of the iframe child.
Any tips would be greatly appreciated.
Thank you.
Good for you for testing your web application for accessibility.
JAWS already has the feature built-in to ignore ads by temporarily or permanently ignoring inline iframes.
Testing that your site works nicely with that feature toggled should represent the typical experience for a JAWS user.
Banner Ads
If you want JAWS to temporarily ignore banner ads on a page, do the following:
Press INSERT+V.
Press I until you select "Inline Frames Show - On."
Press the SPACEBAR to choose "Inline Frames Show - Off."
Press ENTER.
To have JAWS permanently ignore all inline frames, including banner ads that you might encounter:
In Internet Explorer, press INSERT+F2.
Select Settings Center, and press ENTER.
Focus is in the Search edit box. Type in "ignore inline" without the quotes.
Press DOWN ARROW to move to Ignore Inline Frames in the filtered results of the tree view in Settings Center.
Press SPACEBAR to check or uncheck the check box.
Press TAB to move to the OK button and activate it with the SPACEBAR. The changes are made and saved. Settings Center closes.
http://www.freedomscientific.com/Training/Surfs-up/difficult_pages.htm
The other points mentioned on the above link will give you a good idea of additional bad practices to avoid.
Give the ARIA attribute aria-hidden="true" to the outer div of the iframe. This should ideally hide the the content from JAWS.
Give the aria attribute role="presentation" to any element you want ignored. Jaws will not read them.
I like to display more info on certain keywords in a web page. I don't want to send the visitor to another page and I prefer to show the extra info on top of the current page.
The keywords are in an html list. It's basically a list of features and I want to offer more info about the features. So I have two ideas based on having 'More Info' or '?' hyperlinks.
The user hovers on the link and a popup window shows up with the info and goes away when they hover away.
They click on the link, a popup window with an 'X' shows up and they click on the X to close.
Which one offers a better friendlier user experience?
I like #1 because they don't have to click to open and click to close but the disadvantage is that windows might open inadvertently while they are mousing over the page.
Both are pretty annoying, but if I had to pick the lesser of two evils, I'd go with properly done mouseovers.
You can setup Javascript on the page to handle the accidental mouse over, and instead wait for a few seconds before displaying the popup window.
What would your users expect? Try not to break those expectations.
Maybe try a hallway usability study, grabbing a handful of users as they walk past the office, and just ask them to tell you what they would expect. :)
Asking Stack Overflow is a good idea too, but you won't get the advantage of context, which is very important with usability testing.
As a user myself, I find it annoying when I move a mouse and something pops up unexpectedly. Even with a javascript delay (which is better), I still think it's unexpected that something would pop up when I didn't explicitly click on it.
But, that might vary depending on the context of your application.
Personally, I'd go with the click option. There's a standard Way Things Work on the web which says that hovers are for information about the link itself and what action clicking on it will do ("See more comments", "Click for help", etc.), whereas clicking is what actually performs the action.
If you do decide to go with the hover option, make sure that you code it such that users can select the text in the popup. It's really annoying when you just want to copy some useful information somewhere and the GUI hides it before you can reach it.
Adding to what the others have said, I would also prefer the click option.
The problem I have with the hover option is that, and maybe this is just me, if the hoverable area is on the small side, I have a hard time keeping my mouse still enough to keep hovering. The cursor tends to move off the link in the middle of reading and my nice help text disappears.
People don't expect a pop-up on hover - I'd definitely go with the click.
Edit / addition: think about the website you visit every day - text and pictures are (generally) static, and hovering, at most, changes the colour or add underline to a link, or displays a small menu of clickable links.
When clicking on a link, you expect something to happen - a redirect to another page, a pop-up box with information, a form being submitted, etc.
I'm not saying this is the best way to do things, but it is the way 99% of the web works, and asking users to deal with pop-up boxes on hovers or the like is a good way to turn them away. I know I personally don't read any pages with double-underlined links; it's a good indication that an accidental break in scrolling to read the content might end up with my mouse over a link with an advertisement tied to it.
Having a little graphic beside clickable text, or otherwise denoting that clicking will lead to more information is a great way of providing contextual information without frustrating people. For most of the world, pop-ups without clicking still == advertisements or spyware.
Edit / clarification: I don't mean a pop-up in the new window sense, just a lightbox-style javascript pop-up. Don't take the user away from the page, and give them a very visible button to click to close the pop-up. I guess what I'm saying is that people don't expect something to happen without clicking, especially not if it's going to take up more space on the screen.
As a couple of additional precedents to consider, you might want to consider the functionality of the acronym and abbr HTML tags. Both allow you to provide extra information on a particular piece of text in the page, and both work on the "hover" principle.
Points to ponder:
If items are so dense that everywhere you move the mouse something pops up on hover then do NOT do hover!
Can you make hover show very brief info, and have click show more detail? This may be the best of both worlds if it works for you.
Can you have a dedicated box that displays info when you hover? This may be better than any pop-up. Opinions vary...
In the end it's what works for your app, from your users' point of view.