I'ts not a coding question so apologies if this is in the wrong forum, but how do sites such as https://lightsaber.withgoogle.com/ work? How does the site know the user is on the page with their phone? I've seen a few of these as of late and I'm at a loss as too how they're built...
It's not a coding question, you pointed it right.
But this is just what we can call Real time web, featuring technologies as NodeJS, Socket.io, etc. I played with this for fun, but I don't know any other technologies that offers the same features (there are some, it's just I don't know).
How does it work ?
Let's consider a webpage with 2 views : desktop and mobile (whatever the way the "mobile version" is rendered)
You connect your mobile to it (on the same url, or nearly the same, with some params to identify the mobile as current user's one). On the light saber game, note that it generates a custom URL to identify the user on desktop and the user on mobile as the same user.
When you visit the page with your mobile with that URL, Web API lets you use some features like Device Orientation (so the page can see how your mobile is positionned, for example)
Then, the mobile viewsend those events (mobile orientation) to the desktop view to update the way its rendered (light saber more on left, or whatever).
To go a bit deeper :
Mobile view emits events containing the current mobile x,y,z (this coordinates are relative to the event start. e.g. On page load, x = 0, y = 0, z = 0, whatever the device position) each time the device position changes, captured by the server.
The server is listening for those events, and each time it gets one, emit another event (with some trasformation, why not ?) which this time is captured by the desktop view which apply the changes with new values.
So basically, the Google light saber exeprience can be see like this :
Mobile (send position x,y,z) --> Server (get mobile position and broadcast it) --> Desktop (get mobile position from server and apply changes on the view)
I talked about Node and Socket.io because it makes this kind of experience really simple. I mean: really.
This has to do with the link that the page offers. The first person who navigates to the generated link with their mobile phone is the one the site is going to "connect" with.
When you visit the generated link with your phone, that (mobile) page sends a signal to the original page (by some means, like with websockets or just database fiddling) which generated the link, that someone has navigated to the generated link with their phone. After that it's just the matter of what to do next.
Simplified:
Have some page A generate a link to a page B
Make page A wait until generated page B signals that someone has navigated to it
Make page A (and B) do something
Related
I have a website which contains links to external websites, for example amazon product links. The links work just fine, but when I test my website on mobile (iOS in this case), I noticed that clicking the links in the mobile browsers would force open the Amazon app rather than just opening a new tab.
The links in my html are as follows:
I want to have these links open in the browser only, not in their respective apps. Is there any way in to prevent this behavior using html / javascript? Thanks!
No, you can't.
The reason is: you should not be able to impose your choice on the user. Maybe the user prefers the app? That's why iOS 9 introduced the app switcher on the top left hand corner if you switch apps.
Also, let's look from the other side of things if you are the app developer: If you go so far as to build an app and allow universal links (or generally deep links), you obviously would like the user to use that feature and rather open the site in the app. But again, you cannot force the user into opening that link in the app. That's a good thing, because it all depends on what the user wants to do and how he wants to do it.
Having the user choose is the best way to handle this from a UX point of view.
I'm creating a virtual reality website and was wondering how could one make visitors browse from one VR website (A) in full screen stereoscopic view to another VR website (B), without exiting full screen stereoscopic view ? Is it even possible ?
This is how I imagine the "VR" web would look like, but I might be wrong.
Thank you.
In current experimental implementations of the webvr API (https://webvr.info), any website can always call requestPresent to enter VR mode if a headset is available. This is still far from providing a good link traversal experience. A website needs to know what headset was previously used to push the content appropriatley. A set of events have been recently defined for this purpose but are not still completely implemented by browsers. Additional specifications might be needed to define how browsers should behave when traversing links: How do you communicate the user you changed URL? How are content or HTTP errors notified? What is it displayed in the headset when you leave a site and the new one is still loading? Some discusion is happening here: https://github.com/w3c/webvr/issues/69
I'm getting a trouble while running JS code in a browser.
I've got a small web page which uses HTML5 location API for tracking a user.
User opens my website, logs in, and goes to a certain page on which I'm using location API to track user's location. Everything works fine until user's phone goes to sleep or user presses "home" button to minimize browser. The same thing happens on both Android and iPhone.
Is there any way to prevent the phone from going to sleep and let JS code work while browser is minimized?
one of the way I found is using video on a page where all JS located. but another problem is - screen became always ON, which can cause battery to discharge too fast (if I turn off screen manually using power button everything stops working)..
still looking for some ideas...
I've checked various related questions already posted about detecting mobile devices for websites, but my method is a bit different to anything i've seen and wanted to know if anyone can see any issues with it.
What I'm doing is...
I have a httpmodule that does a server.transfer(); to a blank html page on the first request of a user visit.
On this blank html page is some javascript that detects the viewport
width/height and touch capability. The js then saves this info to a
client cookie and then redirects (via window.location) to the
originally requested page.
When the httpmodule gets hit again, it reads the viewport
and touch screen details from the client cookie. If touch is
available or the viewport width is less than say 480px then the
httpmodule will redirect (via Response.Redirect()) to the mobile
version of the website.
Is there any stumbling block I will likely encounter by doing this?
I should note that the tablet version of the site is the same as the mobile, which is why I want to redirect to this version if touch is available.
any issues with it
Is not SEO friendly for sure.
Its not working if the user did not have javascript enable
Its have flickering if the cookie is not saved, or is disabled.
With the server transfer if you make any post, and any of the cookie or javascript fail, then the will also lose the post data.
Its nice idea general, but I think that you also need to check this thinks before the first server transfer. With your method you can avoid to keep an updated database with all the browser info's, I think that sounds good, but its need to be tested if its work smoothly in real world, and also make some more tests before the first server-trasnfer .
Two issues I can see: latency and touch event availability.
Round trip times are enormously extended over mobile networks: you're looking at about 500ms over 3G for an empty page request. Therefore request - redirect - redirect is about a second of extra latency before the user sees anything. I don't think you'll see flicker - as some commenters suggest - you'll just see nothing for a second, which doesn't seem like a positive experience.
Regarding touch: not all mobile devices are touch based and some that are (Windows Mobile 7) don't have the ontouch* events. You'll need to track these separately.
Viewports are slippery things too: if you aren't forcing the viewport width though a meta tag you'll find a large number of your target devices are missed by a viewport test because they'll claim to be 1024px.
As the touch-enabled devices (iOS, Android etc) all support CSS media queries wouldn't this be a better way to go?
It might be worth taking a look at the RESS (REsponsive design with Server Side components) approach championed by people like Luke Wroblewski: http://www.lukew.com/ff/entry.asp?1392
Try to use Media Queries which is CSS based and should sort website accordingly.
You can detect screen size on the fly and change css accordingly.
http://webdesignerwall.com/tutorials/css3-media-queries
http://www.w3.org/TR/css3-mediaqueries/
I am running Firefox as a non-interactive kiosk type application that iterates through several web pages on different sites. For implementation, I have a page that uses JavaScript to iterate through an array of location.hrefs.
I want my kiosk page to be able to auto-recover when there is a network outage between my kiosk application and my web server. Currently, the application has to be restarted if there is an outage. Is there any way to implement this in ANY browser?
It really depends. If the application is non-interactive it should be pretty simple. Just use two frames, load your application in one and have it change the URL in the other frame periodically. This way, the first frame never refreshes, so in case of a network outage it will keep cycling through the pages (although they will appear as errors) until the network is back (at which point the app will be back to normal on the next refresh).
Note that you don't have to show two frames. The first frame that only contains the required JavaScript to cycle through your pages can easily be invisible.
You could probably do more complicated stuff, such as polling with Ajax before a page change to see if you have a connection, but it's up to you to decide whether that is necessary.
Set your page as home page and add Firefox to the Autostart folder.
For the kiosk mode, I found an addon that claims to be helpful of this. Haven't tested it myself though...
EDIT (Thought it was your site that should restart)
For the problem with sites in your switcher that stops responding I would do something like doing an ajax call to the page first and checking the http status. If it's ok - load the page in the content area (iframe?), if not, move on to the next page. The pages will be checked every time in the loop, which means a down page will be displayed when it comes back up.
Quite sketchy, but I hope you get the point?
I have a similiar setup. I used Tab slideshow ( https://addons.mozilla.org/sv-se/firefox/addon/tab-slideshow/ ) in combination with ScrollyFox ( https://addons.mozilla.org/sv-se/firefox/addon/scrollyfox/ )
I have Slideshow setup so that it reloads the tabs every 30 second or so. I have one tab for each site that I want to demonstrate, and tab slideshow will cycle through them at a certain interval. Upside with this approach is that they will usually be fully loaded all the time.
For fullscreen in firefox 4, just F11 and then Alt + F4 and it will start up in full screen the next time it will load. I used Full Fullscreen for this before, but it hasn't been upgraded to support FF4 yet. It works in 3.6 though.