Most of the WebSocket examples out there are centered around a single web page, where the content updates with chat, financial or some other live metrics - makes sense for a single page.
However, given a news feed scroller, where that feed needs to exist on every page of the site, I would like to open the conversation up to some possibilities for this.
Currently the site is a classic ASP site, but will be eventually migrated to MVC/MVP.
Since we don't want to open/close the web socket every time a link is clicked on (currently loads a new page), I was thinking about an IFrame type of UI, which can be done with updatable DIV's and jQuery.
Given a simple containerized UI template with a header (c1) and footer (c2), content in the center (c3) with left (c4) and right (c5) bars, when clicking on a link on the header, where the main menu would reside, instead of updating the entire page, I could load a page into one of the containers (updatable div), preserving the WebSocket container's connection - avoiding needing to re-establish the connection.
What are some other options to consider to accomplish this?
Thanks.
UPDATE
If you take a look at FB's implementation, their status bar on the right and even chat, stay on the page across link clicks. How is that accomplished?
Using IFrames or otherwise modifying your page state (rather than full page loads) is probably the best direction right now but shared Workers may also do what you want. The idea is to allow multiple pages loaded simultaneously from the same origin to share a web worker. I suspect that the shared worker will persist even for page navigation within the same site. However, I have not actually tried it and the W3C spec is not clear to me on this issue. I would be interested to know if this is in fact true.
Note that Shared Workers are in Chrome, Safari and Opera but IE and Firefox have not committed to supporting shared workers yet:
http://dev.w3.org/html5/workers/#shared-workers-introduction
http://caniuse.com/#feat=sharedworkers
Related
The application checks when a certain websocket goes offline.
Whenever this happens, a few popups will be shown in order and each with their own functionality.
This is the only time these popups will be shown.
On some browsers, not all images will be shown on the popups
On other browsers, the 2nd popup will not be shown
I cannot prerender anything on the server side. Everything is hosted in an iframe by another party and I have no control over the parent framework or any of the servers.
I have no idea how to start tackling this issue.
Should I just render it anyway and hide it in css? (will the browser load / show it or is it optimized to now even download the images)
Should I create the component but update the z-index?
... a better solution?
I'm worrying that I won't get any reply from stack overflow, because I couldn't get any reply from previous question. You don't need to fully read previous question, but It could be helpful to understand my question.
Our company is on service that html document builder(windows application) and I'm a desktop s/w engineer. after build html document with our windows app, we export all things to html/js/css.
Consumer of our application is a designer who creates or edits contents via our windows app. and the end-user of contents which is created by designer see contents via browser(chrome, safari (iphone), samsung browser).
The Problem is, my superior (programmer) wants use java-script as a navigation, this is possible. but, he want to save all state of document state before navigation, so after navigation to any page and then comeback to origin page, all state - animation (contents may have animation) and all script state - should be same exactly before he leaving origin page.
More specifically, main html has a iframe, and iframe can shows all contents. Main.html have a navigation button so iframe can navigate all contents created by designer. If user interacted with page1.html inside iframe, then make iframe to change its content to page2.html by clicking navigation button (go to second page button implemented inside main.html but outside of iframe). and then back to page1.html, he get exactly same state as before he leaving page1.html.
At a glance, It seems quite possible just implement go-forward or go-backward, but dynamically paging navigation is impossible to me. I found some techniques - access browser visit history and window.history object, but It seems there isn't user-defined way.
I thought Electron app(desktop) will be fine for our solution, but my superior says It should be works well with just html/js/css. Our final product should be shown in desktop, iPad, mobile or any device that handle web browser.
I need technical advice to accomplish this issue, I'm fine there is no way to control navigation while saving document state. Help me please.
Document state can be saved by using localstorage object in javascript.
I'm looking for the best way to keep a WebRTC video stream + the stream controls (hang up, mute etc.) loaded and active, even if the user navigates to another subpage through the navigation menu.
I thought of the following way, however I don't know if this is the most practical one or if there's a better solution to this nowadays: I'd simply make a wrapper with the navigation menu and put an iFrame where currently the content is. The video stream itself would go in the menu bar itself (it's a sidebar which is wide enough to do something like this), when the user clicks on a menu item, the iFrame src is replaced with the new URL.
Is this the right way to do this? If so however, since I haven't used iFrames that much so far, I have a few more concerns:
Are there any drawbacks as for browser features when using iFrame? For example, I know that Chrome asks you to put several features into the allow attribute of the iFrame, for example when using the camera, microphone or location of the user. Is there anything I absolutely cannot do in iFrames?
Do iFrames share the (PHP) session and cookies with the "main" wrapper, or are those separate sessions?
And probably my biggest concern: How could the JavaScript codes of the wrapper and the iFrames communicate with each other? For example, how could I send a hangup-signal to the video stream in the wrapper from within the iFrame?
Thanks for any hints!
Iframes could work.
Are there any drawbacks as for browser features when using iFrame?
The main issue is that you don't really get control over the presentation of the page while that iframe loads. Users may see a brief moment of solid white, for example, while the previous page is torn down and replaced.
Is there anything I absolutely cannot do in iFrames?
Iframes are pretty flexible. Just keep in mind that they have their own JavaScript context so there is some extra code you need to write to shuffle data back and forth.
Do iFrames share the (PHP) session and cookies with the "main" wrapper
Yes
How could the JavaScript codes of the wrapper and the iFrames communicate with each other?
You can actually access the Document object for the iframe from the outer iframe. (Assuming they're on the same origin, of course.)
const iframe = document.querySlector('iframe');
iframe.contentDocument.querySelector('body').whateveryouwant
Probably the best way though is to use the postMessage API. This allows you send data back and forth as-needed, in a nice isolated way.
https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
Twitter has the following UI behaviour that I want to replicate:
a homepage https://twitter.com with an endless feed you can scroll down;
if you click on a tweet it opens up with a dedicated URL (e.g. https://twitter.com/TheTweetOfGod/status/635493904834412545);
this tweet appears to be an embedded page/section 'on top' of the original feed, which you can still see around the edges but shaded darker;
If you click off the embedded tweet element (i.e. on the shaded area) you revert to the original https://twitter.com feed at the same point (i.e. page has not refreshed).
Note that if the tweet URL is opened up in a fresh tab then the author's profile page forms the shaded backdrop instead of the main feed page. So the main feed backdrop is only inherited if the tweet page has been accessed from https://twitter.com.
In web design terms does this design approach have a formal name/definition that might help me identify a suitable solution? I'm assuming it has a server-side dimension.
There are three aspects to your question. Let's first dive into the technology needed to implement everything, and then briefly discuss how Twitter leverages that technology.
TL;DR? Twitter uses the history API combined with AJAX and DOM manipulation to work its magic.
The techniques, and a little bit of background
(a) Changing the URL without refreshing the page (2 and 4 on your list)
There is an API for that, implemented by modern browsers.
window.history.pushState(state, title, URL);
window.history.replaceState(state, title, URL);
window.addEventListener('popstate', (event) => { /* use event.state */ });
The first two functions allow you to simulate the user navigating to URL. The first adds an entry to the navigation history, while the second replaces the current entry. This impacts what will happen when users use the back and forward buttons in their browser.
When users navigate back, or you simulate this using history.back(), the popstate event is fired and the state that you passed into pushState can be accessed via event.sate. The state can be any object, so this is useful to store, say, the title of the page (to update the document.title), the scroll position, or whatever else you want.
(b) Loading content directly
Because the entry is saved in the browsing history, it is possible that users visit this URL directly after having closed the tab or even their browser. They may also share the URL and have others visit it directly. In those cases, there will be no popstate event, but simply a request to your web server for the URL you passed to pushState. The URL must hence be meaningful to the server.
Twitter apparently loads the poster profile as a backdrop in this case. It depends on your use case what you want the page to look like. Anything goes!
(c) Loading content asynchronously (3 on your list)
Back to (a) for a bit. Twitter not only changes the URL, but also loads the tweet, meta data of that tweet and replies to it. This is then displayed in a modal popup.
Again, there is an API1 to load content asynchronously: AJAX. In particular, the XMLHttpRequest object and its functions are of interest. This can be used to make requests to the server and fetch content without needing the page to reload completely.
It is worth mentioning that a new API is being developed: the Fetch API. At the time of writing, there is basic support in all modern major browsers, but it is still somewhat under development.
After having fetched the content, it can be displayed on the page in any which way you like. JavaScript can be used to create, delete and modify elements in the DOM at will.
An example from your question: Twitter
Now that all techniques are on the table, let's summarize what Twitter does.
When a user clicks a tweet in their feed.
Load tweet meta data and replies (as described under (c)).
Create a backdrop and modal and populate them with the loaded content.
This uses standard techniques: create, delete and modify page elements.
Update the URL (as described under (a)) to enable easy sharing, amongst others.
When a user dismisses the modal.
Delete the modal and backdrop.
Update the URL (as described under (a)).
When a user directly visits the URL to a specific tweet.
Let the server respond with the profile page of the tweet author, with the tweet details loaded in a modal on top of it. Thus, no JavaScript is required at all. Of course, the modal can be dismissed just like in the previously described use case.
Implementing this on your own web site
You correctly identified that there are both client side and server side dimensions to this technique. The beauty of it is that, when implemented correctly, it is completely transparent to users. The only thing they will (not) notice is that there are fewer full page loads.
The references sprinkled throughout this answer should provide good starting points for you!
Final notes
All of this is sometimes also used to create smooth transitions between pages of the same site. In those cases, full pages are loaded asynchronously (as per (c)) and then a smooth transition, usually involving animations, is performed. There are many, many, many, many examples, tutorials and libraries for this. You may want to search for PJAX to learn and find more.
__________
1Not really a single API maybe, but an approach or mindset. See the MDN reference for more details.
I think that what is happening in Twitter is that the popup tweet loads the same content as the tweet in its own unique page; not that the modal has an unique URL.
If you use Angular, you can inject the same content into html modal templates or into standalone pages using route provider, and you could link from the modal content to the standalone page using the ID of the specific data to load that content.
EDITED TO ADD:
Here is the source code of a tweet in a stream of tweets, before it pops up as a modal:
<div class="js-tweet-text-container">
<p class="TweetTextSize TweetTextSize--normal js-tweet-text tweet-text" lang="en" data-aria-label-part="0">
Does anyone remember a 1990s TV show about a folklore prof investigating urban legends, shown on weird night on channel 4 <s>#</s><b>folklorethursday</b></p>
</div>
Here is the URL of the tweet when it is shown as a modal in front of the twitter feed: https://twitter.com/vogelbeere/status/887996116549107713
There are so many event listeners on the tag that it's hard to see which one is the link to the tweet.
Is this even possible? To have an mp3 play where it left off when you navigate to a different page on the same website? I seriously don't even know where to begin. Kind of new to HTML, CSS, etc.
Any Ideas? Thanks.
Not across multiple page loads. But you can have a single page which plays audio and provides navigation therein for the user. A couple overarching structural options would include:
Create a Single Page Application (SPA). Here your one "page" would play the audio, and the site navigation would happen within this single page instance with JavaScript/AJAX. The browser would only ever load one "page", but the overall application would dynamically load/unload as elements of that page as you see fit.
(A very old method, but still works) Create a parent page with frames for navigation. The parent (frame) page would contain the audio, and the rest of the navigation through the application would be done in frames within that page.
I'd recommend the first approach, but either would work.
If you reload the entire page (and therefore the audio source), there is no way to provide a seamless playback. There will always be a very noticeable gap due to page load times, even if you try to keep track of the position within the audio track. Slow internet connections will make it worse.
Instead, you can embrace one of those four options:
Single Page App:
As also pointed out by David, my suggestion would be to create a single page application, i.e. a page that loads once, then loads/replaces all additional content dynamically. One the user clicks a navigation link, instead of loading a new page (or reloading the current page), you just replace the main content, using AJAX. The part that provides the audio stays in place.
Additional tab/popup/window
You could create an additional tab, popup window or window just for the sake of playing the audio. One example of this is the German radio station "radioeins". At the time of writing, their website provides an orange button in the top right that will open a popup window for their live stream, allowing the user to continue browsing their website with the music continuing to play uninterruptedly from the popup. I would only go down this route if the single page app is not an option, as popups or additional tabs are bad UX and popups might be blocked by browsers.
iframe
You could provide the main content of your page within an iframe, or the other way round, provide the audio from within an iframe. I would recommend against this, as there are several disadvantages to this approach.
Frames
Frames would provide a similar approach to iframes, but they are deprecated, so I strongly recommend against this one as well.
tl;dr
Make it a single page application if you can, otherwise resort to a popup-solution.