This might seem like a really dumb question, but I am writing an application and I have come across where my mouse-over, mouse-click and mouse-hover need different events bound to them. Now on Internet Explorer, Firefox, and Safari. It all works as expected.
However, on my iPhone the actions will not trigger. Now my question is are their any specific ways I can have the Mouse-Over essentially be fired when I hold my finger down and trigger an event?
An example where this doesn't work is right on this website when you hover over a comment it is supposed to display the +1 or flag icon.
I am using jQuery.
The answer is in the documentation that Remus posted. If you add an onclick = "void(0)" declaration, you will instruct Mobile Safari that the element is clickable, and you will gain access to the mouseover event on that element.
More info here
I think you need to reconsider your design for the iPhone (and any mobile for that matter). iPhone web interfaces shouldn't depend on mouse-overs and hovers, as they just complicate the interface significantly.
I strongly recommend that you design a new interface that is optimized for mobile viewing, that don't require clicking on small tiny arrows just to show more options.
Mobile Safari has no mouse and hover events (at least not in the usual accepted sense), they are explicitly called out in Creating Compatible Web Content Unsupported iPhone OS Technologies:
Mouse-over events The user cannot “mouse-over” a
nonclickable element on iPhone OS. The
element must be clickable for a
mouseover event to occur as described
in “One-Finger Events.”
Hover styles Since a mouseover event is sent only
before a mousedown event, hover styles
are displayed only if the user touches
and holds a clickable element with a
hover style. Read “Handling Events”
for all the events generated by
gestures on iPhone OS.
Yeah...I don't think anyone posing the question actually expected the device to "sense" a hover or mouseover. Actually you'd have to be pretty arrogant to assume someone actually meant that. Some method of triggering those event handlers is what is desired. I can definitely see a use for them in "hint" text appearing above items.
And whomever said not using mouse events makes a cleaner, simpler experience is taking their own opinion a bit too seriously. Those can greatly enhance a web page/application experience or make them worse. It's a matter of prudent usage.
The only answer anyone provided here worthwhile is whomever said it is best to have an alternate site optimized for mobile. Or possibly use a content management system that generates the page based on the browser type (similar to how Wikipedia works).
Congratulations on discovering the first thing about touch screen UI design. The bad news, is that what you want just is not going to happen.
The good news is that this will force you to make a much easier interface, for both iphone users and regular web users.
You simply cannot have a mouseover or hover functionality on touch screen devices, unless you can move a virtual pointer (though no touch UI offer that kind of functionality), but that would defeat the point of a touch screen UI.
Touch screen UI's are a paradigm shift and retro-fitting mouse-pointer UI interfaces back into touch UI design only limits and damages your solution.
Writing a mousehandler in javascript seems fairly straightforward, although I can imagine it being easy to get a lot of edge cases wrong.
The good news is, someone wrote a javascript mouse-handler/emulator whatever -- as a bookmarklet. It's called iCursor (not to be confused with the pointless mac app of the same name).
The bad news is, the guy's site (icursor.mobi) has gone off the air, and I can't find a copy, so I can't tell you how well it works. Here's a review (because I can only post one link):
What apple should have done for the iPhone/iPad was make one-finger panning move a virtual mouse pointer, and two-finger panning move within the viewport (as one-finger does now).
Two finger panning is easy; the only reason I can imagine for Apple not doing this is that they actually wanted to break 50% of the websites in the world. Seriously. It's right up there with the evil manipulative attempts to break standards that Microsoft has been doing all these years.
You're a web developer. What do you hate most? Internet Explorer. Because of all the extra headaches it causes you. Well, Stevie had to have his "me too" moment, and you're going to pay for it.
Related
Is there an industry standard or W3 recommendation for converting touchpad/fingerpad events to mouseevents? (Ffor javascript use)
Background: I have written my own html-application, running fine on my notebook where I don't have a mouse, but use the touchpad. (I always thought it is called fingerpad.)
The events from the touchpad show up nicely converted to mouse-events in the Firefox javascript event handling.
Now I'm trying to run my web-app on a tablet, and have to handle the touch-events: That mostly works very well, except for the doubleclick or click. (And the not wanted simultaneneously happening page scrolling, but I know how to handle the latter.)
Because physically I can't see any difference between my touchpad and the tablet surface, and before I will change the event handling in my app any further therefore my question, if there is a industry standard or W3 recommendation for converting those touchpad/fingerpad events to those mouseevents that show up in my Firefox javascript event handling.
I simply don't want to reinvent the wheel. (And I have seen many questions here and in other forums around the touch-event handling, that would mostly be solved by such a converting standard.)
Hello to everyone.
This is my first question ever, and I know it could be a little tricky, but I'll try.
I'm currently working on an accessible web app, and I wanted to build a "Direct touch area", just like some native apps for iOS, in which the accessibility assistant is disabled, when the user is focused on it.
I'm using HTML, Javascript and CSS in frontend developing.
When the accessibility tools (TalkBack for Android, VoiceOver for iOS) are switched on, if you touch the screen with one finger, you cannot interact with the DOM, because you are into an "explore by touch" mode.
I'd need to bypass this particular behaviour, but just for a precise area.
I struggled a lot with various ARIA attributes, roles, etc, but didn't find a way yet.
For istance, there's an HTML attribute named aria-disabled (true|false), which makes the screen reader simply ignore the area content, so it's not useful in my case.
Something similar happens with "aria-hidden" attribute.
Perhaps someone has already encountered this problem and solved it, somehow?
Any help would be veeeery appreciated!
I don't quite understand what is meant by the question, but maybe "Aria-Disabled" will help?
Aria-Disabled Reference
role="application" is how you get events passed directly to an element without the screen reader capturing the event first. But be very careful with this role. It should be used sparingly.
Note that this role will not turn off VoiceOver for that element. The user still needs to be able to explore the screen. You could implement double-tap-and-hold to go into a mode where the user interacts directly with your object then implement the two-finger 'Z' swipe to escape out of that mode.
first of all bypassing the explore by touch mode won't be possible since it is handled by voiceover or talkback. More important: doing so would make harm since that behaviour would catch the user and he or she won't be able to swipe through the elements. Being a born blind and daily user of such screen readers myself: a blocked swiping through the controls of an app makes me wipe it immediately and leaving me frustrated. Keep in mind that a screen reader user will not be able to touch your input area before he or she found it by swiping. He or she could leaarn the exact position and size but thats more like spinning wheels of fortune.
ARIA 1.1 at https://www.w3.org/TR/wai-aria-practices states in the chapter on mobile and touch support that there is currently no standard on this and there is no ARIA role for that.
You could switch to aria-disabled after your user activates the area after locating it by "explore by touch", but I don't know how the user will get back to the other controls.
Using the application element seems to be the best way, but users have to remember a special key for their screenreaders to leave the application since e.g. NVDA or JAWS will box their reading the apllication until this magic key is pressed. This way I have been trapped in office documents when using office365 many times!
There is an idea which I have been toying with for the past few weeks. I am extremely serious to realise this concept, but I totally lack any know how about the implementation. I have some thoughts which I'll be sharing as I explain what the idea is.
We have websites. Most of them are responsive.
What is responsive web design?
By and large, responsive web design means that design and development should respond to the user’s behaviour and environment based on screen size, platform and orientation. If I change my window size, my website to should change its dimensions accordingly.
If I scale some object on the screen, then the website should rearrange/ rescale accordingly.
This is good, but nothing exciting (nowadays!).
I am again so damnfully limited by a screen and to whatever happening inside it that what I do outside seems still very external and not seamless. Except my contact with the mouse/ keyboard, I do not know any other way to communicate with the things that happen inside the screen. My screen experience is still a very external feature, not seamless with my cognition. I think this is also a reason why my computer always remains a computer and does not behave a natural extension of the human body.
I was toying with a idea which I have no clue how to realize. I have a basic idea, but I need some some technical/ design help from those who are fascinated by this as much as I am.
The idea is simple: Make the screen more responsive, but this time without use of a mouse or any such input device. All laptops and most desktops have a microphone. How about using this small device for input?
Let me explain:
Imagine, a website in which screen icons repopulate when you blow a whiff onto the screen. The song on your favourite playlist changes when you whistle to the screen.
Say you have an animated tree on the screen. That tree sheds its leaves when you blow air to it. The shedding depends on how fast you blow. Getting a small idea?
Let me put some graphics (see the hyperlink after this paragraph) which I think will make it better. I plan to make a website/ API in which there is a person with long hair staring at you. If you blow air from the right side of your screen, her hair moves to the left. If you blow air from the left, her hair blows to the right. If you blow faint, her hair suffers faint scattering. Some naughty stuff, say you whistle: The character on the screen winks, or say throws a disgusting expression- whatever.
The whole concept is that every element of the web must have a direct relation with the user who is sitting outside the screen. It gives a whole lot of realism to the website architecture if things like my whistle, whiff or say even my sneeze can do something to the website! I am not tied to the mouse or the keyboard for my response to be noted. Doesn’t that reduce a hell of a lot of cognitive load on the user?
See this image: http://imgur.com/mg4Whua
Now coming to the technical aspect that I need guidance on.
If I was building a regular responsive website in JavaScript, I'd use addeventhandler("Click", Animate) or addeventhandler("resize", Animate) - something like that. Here I want my event handler to be the audio input that is coming from the microphone. Also, I need to know the place from where the audio is originating that I can decide which side the hair must fall and play that animation.
So in the span of 180/360 degree of the microphone, I need to not just catch the audio, but also its angle that the right animation can be played. It'd be a crashing fail if the same animation is played where-ever I blow air. It needs to have that element of realism.
I have asked around and some people suggested to me that I try WebRTC of HTML5. I am still seeing if that works, but otherwise are there any more options? I guess Processing is one. Has anyone handled its audio features?
I want to build a simple prototype first before I delve into the immense possibilities this idea could have. But if you have some really awesome thing in mind, please let me know about it. Exciting ideas are one thing, and exciting implementation totally another. We want both.
Are there such websites already? Any work happening in this side?
Any small guidance counts!
There are plenty of ways to create your own events. Most libraries have some built-in way of doing so. Basically you're talking about the observer pattern and here's a nice article to explain it in greater detail: https://dottedsquirrel.com/javascript/observer-pattern/
Also as far as listening to audio goes, using an analyzer-node (AnalyserNode) on the input signal and some ingenious code to determine that the sound is what you want to listen to, firing the event is a piece of cake using aforementioned custom events.
But, before diving into those, determining the angle of the sound? I do not think that is even possible. You might be able to determine the angle of the origin of the sound in a '2d' scope, but that certainly won't give you an angle. I think you'd need something rather more ingenious than a simple stereo mic setup to determine the angle.
Seems that with handheld devices on the rise, one has to start taking them into account more and drop IE6 instead.
With that in mind, it has come to my attention that certain things don't work as well as can be or at all on say, my iphone.
what seems to break includes (but not limited to):
mouseover/mouseout events (can break almost anything)
CSS pseudos :hover as well, naturally (breaks nav CSS-only menus, for instance)
DOUBLE CLICKS - it zooms instead of the event handler
CSS-related issues (minute, it seems to work just like in Chrome w/o the gradients + some font-size issues)
the real question is: do you have any guidelines, articles or whatever that can cover things below or any advice you can give.
where do you start in order to transliterate the experience for desktop users over to mobile ones? do you try to make a separate skin for mobile devices or do you alter / fix your site to work as best as possible - how much maintenance and work is involved in either approach
are there any frameworks (CSS or JS) that can abstract that and do the graceful degradation where required? boilerplate comes to mind, jquery-mobile mootools-mobile (power tools)?
what do you replace things like the ones above with, click events?
how do you incorporate swipes into a web app? can you handle and respond to finger zooms? should you?
additional events like shake, tilt - do they bubble to the browser window?
do you do anything to accommodate awkward OS elements like select, checkbox and radio?
resource management - do you use a detection layer that will only send whatever files are particular to the device as opposed to generic js libs that can deal with both?
as for device support, I am interested in droid and ios only so javascript support will be pretty good - would you drop your main framework and go with a micro js lib instead?
and finally - do you have any impressions on how viable handheld devices are for e-commerce and monetisation (currently and in the near future). I would like to make sure from a business standpoint that the dev work will be worth the expenditure and we're not going to go after buzzword gimmick like '#socialmedia'. any data on conversion values in comparison to the desktop ones? this can help me gauge if these are used as a quick browsing instrument or can actually do the full monty.
any examples of a site that does a great job of working in mobile and desktop at the same time or through different designs, I would like to see them and find what's even possible.
thanks in advance.
You've just asked a lot of questions I've been asking myself recently. I can't give great answers yet as I'm still researching and exploring. but here are some useful links.
Rethinking the mobile web
Mobile emulators
How to build a mobile site
I hope this is at least a little helpful.
I can answer the conversion rate/business viability part of your question.
I had the chance to see Omniture numbers for some very, very big ecommerce interests and the answer is that conversion can be somewhat less, somewhat more, or about the same. There was a pretty good amount of variance depending on the device and the seller's site.
It's what you'd expect though, I think. The quality of the mobile/tablet experience varies a lot right now depending on how well each business optimized for mobile (and for which mobile devices). I think conversion varies a lot as a result.
following link should help. To make website like a nativeapp, jQuery plays amazing role
http://blog.2partsmagic.com/2012/07/developing-web-application-ipad-android-tablet/
On a touch device like iPhone/iPad/Android it can be difficult to hit a small button with your finger. There is no cross-browser way to detect touch devices with CSS media queries that I know of. So I check if the browser has support for Javascript touch events. Until now, other browsers haven't supported them, but the latest Google Chrome on dev channel enabled touch events (even for non touch devices). And I suspect other browser makers will follow, since laptops with touch screens are coming. Update: It was a bug in Chrome, so now the JavaScript detection works again.
This is the test I use:
function isTouchDevice() {
return "ontouchstart" in window;
}
The problem is that this only tests if the browser has support for touch events, not the device.
Does anyone know of The Correct[tm] way of giving touch devices better user experience? Other than sniffing user agent.
Mozilla has a media query for touch devices. But I haven't seen anything like it in any other browser:
https://developer.mozilla.org/En/CSS/Media_queries#-moz-touch-enabled
Update: I want to avoid using a separate page/site for mobile/touch devices. The solution has to detect touch devices with object detection or similar from JavaScript, or include a custom touch-CSS without user agent sniffing! The main reason I asked, was to make sure it's not possible today, before I contact the css3 working group. So please don't answer if you can't follow the requirements in the question ;)
It sounds to me like you want to have a touch-screen-friendly option, to cover the following scenarios:
iPhone-like devices: small screen, touch only
Small screens, no touch (you didn't mention this one)
Large screens, no touch (i.e. conventional computers)
Touch-screen-enabled large screens such as iPad, notebooks/pcs with touch screens.
For case 1 and 2 you will probably need a separate site or a CSS file that eliminates lots of unnecessary content and makes things larger and easier to read/navigate. If you care about case #2 then as long as the links/buttons on the page are keyboard-navigable then case 1 and 2 are equivalent.
For case 3 you have your normal website. For case 4 it sounds like you want clickable things to be bigger or easier to touch. If it's not possible to simply make everything bigger for all users, an alternate style-sheet can provide you with the touch-friendly layout changes.
The easiest thing to do is provide a link to the touch-screen-version of the site somewhere on the page. For well-known touch devices such as iPad you can sniff the user agent and set the touch stylesheet as the default. However I'd consider making this the default for everyone; if your design looks good on the iPad it should look acceptably good on any notebook. Your mouse users with less-than-stellar clicking skills will be pleased to find bigger click targets, especially if you add appropriate :hover or mouseover effects to let users know that things are clickable.
I know you said you don't want to sniff user-agents. But I'd contend that at this time the state of browser support for this is in too much flux to worry about the "Correct" way to do it. Browsers will eventually provide the information that you need, but you will probably find that it will be years before this information is ubiquitous.
Good news! The editor draft of CSS4 Media Queries have included a new media feature 'pointer'.
Typical examples of a ‘fine’ pointing system are a mouse, a track-pad or a stylus-based touch screen. Finger-based touch screens would qualify as ‘coarse’.
/* Make radio buttons and check boxes larger if we
have an inaccurate pointing device */
#media (pointer:coarse) {
input[type="checkbox"], input[type="radio"] {
min-width:30px;
min-height:40px;
background:transparent;
}
}
It's also possible to test the media query from JavaScript:
var isCoarsePointer = (window.matchMedia &&
matchMedia("(pointer: coarse)").matches);
Updated Feb. 11th. 2013 On Windows 8 recent versions of Chrome (version 24+) detect touch-hardware when launching the application and expose touch events. Unfortunately if "pointer:coarse" returns false, there is no way to know if it's because pointer media queries are not implemented or because there is a fine pointer. WebKit haven't implemented "pointer:fine" yet, so we can't check that either.
Update Sept. 26th. 2012
Tested in Safari on iOS6 and Chrome on Android 4.1.1 and it's not there yet. 'pointer' and 'hover' media-queries landed in WebKit May 30th. According to the User-Agent, Safari uses WebKit branch 536.26 from April 25th, and Chrome on Android uses and even older one (535.19). Not sure WebKit branches from User-Agent strings are to be trusted, but my test page is not able to detect pointer media queries either.
The implementation from May only implements the pointer media query for touch devices, so pointer: fine won't work for devices with a mouse.
I don't know if a standardized media query like Mozilla's will solve the problem by itself. Like one of the Chromium developers said in that discussion you linked, the presence of touch event support in the browser doesn't mean touch events can or will fire, or even if they do, that the user will only want to interact via touch input. Likewise, the presence of touch input support in the device doesn't mean the user will use that method of input - perhaps the device supports mouse, keyboard, and touch input and the user prefers the mouse or some combination of the three input types.
I agree with the Chromium developer that supporting touch events was not a bug in the browser. A good browser should support touch events because it might be installed on a device that supports touch input. It's the website developer's fault that he took the event support to mean the user would be interacting via touch.
It seems we need to know two things:
(1) What are all the supported input types on the device
(2) What are all the supported event types in the browser
Since we don't know #1 right now, there is one approach proposed by PPK of quirksmode that I like. He talks about it here: http://www.quirksmode.org/blog/archives/2010/02/do_we_need_touc.html#link4
Basically, listen for touch events and mouse events, and when they happen, set up the UI accordingly. Obviously that's limiting to the developer. I don't think it's a valid approach to your problem with link size because you don't want to wait for interaction to alter the UI. The whole point is to present a different UI (a larger/smaller link) before any interaction occurs.
I hope you make your proposal and it gets included in CSS3. Until then, as much as it pains me to say it, user agent sniffing looks like the best approach.
p.s. I hope hope hope someone comes here and proves me wrong
Google Chrome has a command line switch for enabling touch events. Disabled by default. So until they enable them for everyone again (hopefully they won't), it's possible to detect touch with the help of javascript like I described in the question..
Update jun 3 2010: This actually got into the stable version on 25th of May 2010 :( Don't know it it was a mistake or not.
Have discussed the issue on the w3c mailing list, but I doubt anything will happen very soon. http://lists.w3.org/Archives/Public/www-style/2010May/0411.html
They might discuss this during TPAC in November.
Update sep 30 2010: Supposedly fixed in Chrome 6. Haven't had time to downgrade to stable yet to verify. Since Chrome upgrade automatically this problem should already be gone :)
Read this if you're considering using media queries:
http://www.cloudfour.com/css-media-query-for-mobile-is-fools-gold/
and http://www.quirksmode.org/blog/archives/2010/09/more_about_medi.html
Update may 16th 2011: W3C is now working on a Touch Events specification, but more or less refused to hide touch events for terminals without touch hardware. So don't expect the touch event detection to work for long.
Update june 6th 2012: The W3C CSS4 Media Queries (Editors Draft) spec have something very interesting. See my separate answer about this.
No, there is no such thing.
CSS has the screen size option, which will allow you to optimize layout, but that's all.
There is also media="handheld" but that also doesn't apply to your requirements.
Feature detection might work using javascript, however, there are issues with different events for different devices. PPK (the man behind quirksmode.org) is doing a huge amount of work checking what javascript is possible for each mobile/handheld device, and it's proving that nothing seems to be standard with these devices and yet this STILL doesn't apply to your requirement for touch laptop devices.
(honestly I dont know why you are concerned about a device that isn't even out yet, be pragmatic and worry about it once it's here and you can test it)
PPK's work on mobile browser and touch events, will save you hours. Check it out here
Apple has TouchEvents defined only for iPhone OS FWIW
Not a complete solution, but you might want to simply outright avoid any small buttons. While small buttons are more of a usability problem on touch devices, they are always hard to use, even with a big screen & mouse.
If you just pay attention to using suitably big buttons with enough space between them, everyone will benefit. Plus, it will force you not to clutter your interface with too many small buttons :-).
try using tables and make a full cell to be a link...
i'm working on that in my website...
it's not working well so far...
but you might find a way...
on this way, no need to overload your website with javascript and functionality detection...
you can give it a relative size instread of a fixed size...
and in this way, your website can be viewed in a desktop as is viewed in a iphone...
think about this idea...
any sugestion is apreciated...
See http://crbug.com/136119 for support for adding pointer:fine in Chrome. It is actually possible to detect whether pointer:coarse is supported (to distinguish unset from not supported) - just create the media query yourself and test in javascript whether it parsed properly.
Eg., today "#media (pointer:coarse)" in Chrome shows up:
> document.styleSheets[0].rules[5].media[0]
"(pointer: coarse)"
But unsupported bogus values like "#media (pointer:other)" don't:
> document.styleSheets[0].rules[8].media[0]
"not all"
You won't have any control over detecting touches, and even if you did the logic steps to figure out what exactly the user is trying to touch is complex and best handled by the device itself.
Your best bet is to create a mobile version of the site or an alternate stylesheet that is loaded when you detect a mobile device with Javascript.
If you are using PHP, this is a good solution:
http://chrisschuld.com/projects/browser-php-detecting-a-users-browser-from-php/
You can detect whether the browser is a phone from the serverside by sniffing the browser request details, and if so, display alternative/extra stylesheets/js/html