We are currently using a meta refresh to initiate a download on a page, I read on Wikipedia that using this is not UX (user experience) friendly. So what is the way to have a download start after a few seconds when landing on a download page.
User interface-friendly way would:
Not spring an unannounced surprise to the user. So postpone the download by X seconds and clearly announce that.
This is done by setting up JavaScript logic to display a changing countdown to download. See below for details on implementation.
Allow user to control this by allowing immediate download
This is done by having the download timer announcement provide a widget (button or a link) to download immediately.
Keep the current page, by opening the download in a new window/tab.
The "kick off the download" logic should preferably be - instead of the obvious setting of window.location.href - something which opens a new window for the download. This way you allow the user to keep the main download landing page intact.
If possible, present a nice download widget
Instead of just pushing the URL of the download target, consider using custom download wisget like jQuery's jDownload plugin
To implement the changing countdown, do something like this:
Set up a variable for how long till download starts:
var DownloadIn = 10;
Set up a timer in JavaScript using setTimeout()`:
setTimeout("shouldWeDownload()", DownloadIn * 1000);
Subroutine shouldWeDownload() called from a timer will:
check if time period (stored in DownloadIn variable) is greater than zero.
If the time is NOT up (greater than zero), it will:
a. Check if a special "AlreadyDownloading" variable is set to true - this variable will be explained later. If true, simply exit.
b. print to a special DIV on the page - something very obvious and visible to the user - a message "XXX seconds left till the start of download. Click on this link to start the download".
c. Decrement DownloadIn variable
d. Set the timer again using the same setTimeout
If the time's up, kick off the download.
In addition, the "this link" link in the message would also immediately kick off the download. To make things clean, the "immediate dowload" onClick JS handler should set a special "AlreadyDownloading" variable which is checked in the logic above should be set to true, so we don't start a second download due to minor race conditions.
I don’t know of any research on what users expect, but I’d suggest mentioning that it’s a download in your initial download link, e.g.
Download my awesome track
(Maybe style that link like a big button, maybe even with an arrow pointing downwards in it: e.g. something like this.)
And then set your server to return that file with the Content-disposition header set to 'attachment' and the name of the file, so that the browser immediately lets the user know they’re downloading something:
Content-disposition: attachment; filename=kiss_from_a_rose__dubstep_remix.mp3
That way you don’t open a new page just to make the file download. The file downloads, the user’s still on the page where they were when it’s downloaded, everyone’s happy.
Fewer steps = fewer things for users to be confused by.
Using the browser’s UI = more chance that the user will have seen it before, and thus know what’s going on
unix user freindly? Depends entirely on the browser, and last time I checked, most/all linux browsers and safari worked fine with meta refresh.
Which is why most websites offer meta refresh with a download link.
Related
I am developing a web site where users can change settings which they have to confirm before taking effect.
The confirmation is done by a link I send them via E-Mail. In the HTML of the website I use this little snippet:
<script type="text/javascript">window.name="mysite";</script>
And in the HTML emails I use
Click me
But Chrome is always opening new tabs instead of opening them all in one.
Is this even possible or is it forbidden for some reasons?
Webmail platforms such as Gmail tend to modify some of the HTML code of an email due to security reasons.
They obviously remove any javascript code the email could have. But they also change (or add if none) the target property of every anchor element and set them to target="_blank" in order to avoid the user to be taken out of Gmail (in this case).
Unfortunately every webmail platform has their own behavior, therefore, what you want to do is not gonna work on every webmail platform.
If what you want to do is prevent the user from having multiple tabs of the same page opened, (*please refer to Update 1) it comes to mind you could use web sockets to close the previous tab once the user enters in the URL sent by email. Have a look at socket.io for example.
Update 1
There's no way to do this using WebSockets. There's no possible way to close a window that wasn't opened using javascript, and it can only be closed by it's parents.
That is a very interesting idea. I like it. Alas, it appears that, in modern browsers, you can no longer close a window you didn't open through javascript. So if you aren't allowed to run javascript in the email, the best you can do is to redirect the original page to a "thank you" page and leave it hanging around in the browser's tab (but no longer waiting on conformation). Like this:
PleaseConfirm.html:
window.name="need_redirected";
Confirm.html:
var w = window.open("", "need_redirected");
if (w)
w.location="ThankYou.html";
Of course, for old IE, I'd still try to close the old window in ThankYou.html:
window.top.close();
You can still try to set the target, of course, just in case it works, and you can always try putting an onclick attribute on your tag for the same reason:
click here
But that seems to be the best you can do. Bummer.
Neither of the other two answers work, but this one probably will:
In the initial tab, listen for an onstorage event, with a certain key being created, e.g. "userHasConfirmedEmail". When the event occurs, window.top.close().
In the new tab, create that key.
Credit goes to Tomas and his answer.
Is there any way to completely duplicate the state of a current tab in Google Chrome? I want an exact copy of the current state of the page without having to reload the page in another tab.
An example use case:
While browsing a "slideshow" on a news website, I want to preserve the current slide that I'm on, but create a duplicate so that I can continue viewing the next slide. If I simply Right-Click and "Duplicate" the tab, the new page will completely Reload, reprocessing all of the Javascript and running the pre-slideshow advertisement again.
In short "NO" you can't.
I am not expert on this
but a similar behavior can be achieved in some ways i know :
Dump the whole DOM
Never tried this though. You can convert the DOM to a string, pass it to the new window and then parse it as a document. This will let you lose your DOM events and State manipulation javascript. (But that's good for your case)
var dtab = window.open('about:blank', 'duplicate_a_tab');
dtab.document.open();
dtab.document.write("... yout html string ..");
dtab.document.close();
Develop an extension
Let the users continue on the current tab with the current state, your extension should be able to capture the screenshot of that area and open that screenshot in new tab. There are plenty of screenshot taking extensions are available in the market.
If that website is your own
You can develop your services that uses state locally like progressive web apps. Give a link separately to 'duplicate' which will eventually open the same URL in different tab with the same local state and with the flag do-not-sync.
This will not work when the user uses browser inbuilt duplicate
feature.
A recurring problem with modern web design can be summed up as "too much sh** all over the place". There're two problems with this: one, it takes up memory and takes longer to load, and two, it visually clutters the webpage.
If I just wanted to solve the second problem, I wouldn't need help. JavaScript can delete DOM nodes and CSS can hide them, so there're already a few visible ways to simply hide parts of a webpage. What I want to do is solve the first problem - make a webpage load faster by not loading certain elements.
I'm pretty sure it's impossible to selectively download certain parts of an HTML file. But once the source is downloaded, the browser doesn't have to actually parse and display all of it, does it?
Of course, if this is done after it's already been parsed and displayed, it would be pointless. So I need a way to tell Chrome what to do before it begins parsing the HTML. Is this possible, and do you think it would significantly reduce load time/memory usage?
Yeah, unfortunately Ive never seen a way of changing the html before Chrome renders it.
But as far as blocking things that that page gets to display then Id recommend just using AdBlock https://chrome.google.com/webstore/detail/gighmmpiobklfepjocnamgkkbiglidom
AdBlock can be used to stop resources (js,images,css,xmlhttprequest) from ever being downloaded (it blocks them in the background using the webRequest api) and can also hide elements using css...its rather effective (just remember to select advanced options in its option page and then when you click the AdBlock button you get "Show the resource list"). Also installing Flashblock can help...or disable plugins in Chromes settings, doing this will make them not load but will still show on the page and then you can make them load.
Totally possible! Meet the newest Chrome API: webRequest, finalized in the current version of Chrome - 17.
Docs for webRequest: http://code.google.com/chrome/extensions/webRequest.html#event-onBeforeRequest
I'm trying to think of a solid way to do this... one suggestion I have is using the 'sub_frame' filter, and watching if it's a like/tweet/social button url
You could also block known analytics stuff... and the list goes on! Have fun! Do you have an email list I can sub to for when you launch? If not, get one and drop me a comment!
(From the comments, here is how a innerHTML hack could work)
//This modLoop constantly peers into and modifies the innerHTML in attempt to modify the html before it's fully processed.
var modLoop = function modLoop(){
var html = document.documentElement.innerHTML
//modify the page html before it's processed!
//like: html = html.replace('//google'sCDN.com/jquery/1.7.1/', chrome.extension.getURL('localjQuery.1.7.1.js'));
//I just pulled that ^ out of nowhere, you'll want to put careful thought into it.
//Then, mod the innerHTML:
document.documentElement.innerHTML = html;
setTimeout(modLoop, 1);
};
var starter = function starter(){
if (document.documentElement.innerHTML && document.documentElement.innerHTML.lengh > 0) {
modLoop();
} else {
setTimeout(starter, 1);
}
};
starter();
I've been working on a new website and practicing my JS/jQuery/AJaxy skills. Last night I wanted to take a look at how long the page was taking to render and see if there were any areas I could clean up to increase speed. While the page loads in about 200 - 300 ms every time, I'm seeing a large amount of blank space between resource loads under the network inspector.
http://i.imgur.com/7ng6m.jpg
Has anyone else seen this or know what I can do to minimize that time (talking about the blank space between like the html and the first css file)?
Quite possibly it is caused by the extensions you have installed. AdBlock, LastPass and Google quick scroll took altogether about 200 ms on my machine.
Unfortunately, these extensions are invoked on every site and block loading the additional resources.
Try it with out of the box browser setup, the loading time will increase tremendously.
You've got a bunch of images loaded just after the page has been loaded (the load and DOMContentLoaded events have fired - the blue and red vertical lines across the Timeline). I can see that the images are loaded by the JQuery library (the Initiator column), perhaps to build a gallery or something.
So, the case is that JQuery loads the images after the page load, presumably in the onload handler (this can look like $(document).ready(handler) in your code, but other options are possible, too).
The delay between the initial page load and requesting the first resources is almost certainly caused by Chrome extensions. To find the culprit: Record a timeline in the Timeline tab in Chrome Developer Tools; Identify the scripts that are running during the Parse HTML phase; Work out which extensions they're from.
To record a timeline:
Open the timeline tab and click record.
Reload the page and then stop the recording. (A couple of seconds should be enough.)
To find the culprit:
Find the first main Parse HTML block on the timeline. On the row below you will probably see one or more Evaluate Script blocks. These are the culprits.
Click on one of the Evaluate Script blocks and find the script name in the bottom pane. Mouse-over the script name. The tooltip will have the URL of the script, which should be of the form chrome-extension://{long_identifier}/{path}
Memorise the first few letters of the identifier and search for it in the chrome://extensions/ page. This tells you which extension is causing the problem. Try disabling it - you should see a difference.
Repeat for the other Evaluate Script blocks.
In my case, I have 20 extensions installed but only two were causing a delay: LastPass and Fauxbar. I've chosen to leave them enabled because for me the productivity benefit of these extensions outweighs the downside of the added latency.
If I don't implement any updateready event handler and don't call swapCache(), does that mean that the browser will always use the first (oldest) downloaded version of the application?
If no, then why is the swapCache() method needed?
Swapcache makes sure that "subsequent" calls to cached resources are taken from the new cache.
Subsequent meaning after swapcache.
To see this in action try setting the src property of an img dynamically after the
swapcache call in the updateready event (so that the browser loads it at that particular
time). Make sure this image is not already loaded elsewhere in the page since that will
distort this test.
Now change the image and change the manifest files (to force reloading the cached files).
Reload the page in your browser.
You should now see the new version of the image in your rendered page.
Now comment out the call to swapcache.
Make a change to the manifest file and reload the page and thus all resources.
Refresh the page again (to make sure you have a version from the new cache).
Now change the image again and change the manifest.
Again reload the page: now you see the old version of the image.
In the last case, the browser finished loading the new versions in cache, but since
swapcache was not called, the image was still taken from the old cache.
If you do not do any dynamic loading of resources in your page, the swapcache has no effect.
In particular, if you reload the page in the updateready event handler calling swapcache
first has no effect since reloading the page will get it from the new cache anyway.
I have an app with a pretty large cache (>100mb). This takes a particularly long time to swap the cache in (and pretty much locks the browser while this is happening). So I display a message indicating that the app is updating (please wait...), then call swapCache(), then display a new message when it's done indicating completion.
Not sure if this answers your question (as to why it's necessarily needed), but I think it provides a valid use case for swapCache() at least.
Let's imagine 2 different scenarios.
You call location.reload() when the new content is available. The page will reload using its all-new content. applicationCache.swapCache() is not needed in this case.
Your user continues to interact with your page, without any reload. This interaction causes an asset to load dynamically. For the sake of argument, let's imagine that it's a rollover image, and let's imagine that you have just updated this rollover image. Without applicationCache.swapCache(), your user will continue to see the old rollover image. After applicationCache.swapCache(), s/he will see the new rollover image.
So applicationCache.swapCache() without a reload says: "Keep the page looking the way it was when it was loaded, but use any new assets now, as soon as the page asks for them".
The SwapCache method provides a mechanism for the application to be in control of how an when updates are applied. In regular HTML apps, it can be difficult to determine if the correct JS is present on the clients browser.
Also browser implementations vary on when a cache would be updated, I found the iPhone particularly stubborn. swapCache put me back in control of how my app is updated i.e. I could choose to automatically apply the patch or let the user choose when to apply etc.
I was wondering the same thing. I seem to be able to trigger a successful update by just calling "window.applicationCache.update()". If the manifest file has been modified, the 'download' event is triggered, then eventually the "update ready".
When I reload it, it appears to have been applied. I don't seem to need to call swapCache(). I have provision for calling it from the app, but so far have not noticed any effect on the update process.
Calling update() basically eliminates one reload, AFAICS.
swapCache will switch from the previous set of resources listed in the cache manifest (when the running webapp was loaded) to the new set. You are doing this in response to an updateready after all, which signals that a new manifest has been loaded.
This is not to be confused with loading individual resources, for which the usual browser caching policies still apply. In other words you will swap set of resources, but individual resources need their own cache management to ensure they're reloaded when you need them to.
I haven't tried this yet, but it would seem to suggest structuring the code as an "update controller" javascript file that handles the update process, and javascript sources with a versioned filename (or URL) with known entry points.