Should links to external sites set target=_blank? E.g. I am on www.acme.net and have a link to www.otherplace.net, should that link be:
<a href='http://www.otherplace.net' target='_blank'>otherplace's website</a>
or:
<a href='http://www.otherplace.net'>otherplace's website</a>
I was under the impression that using _blank to sites outside your domain was best practice, but now I am being told otherwise.
Some web idealists will state that you should allow the user to make their own choices when it comes to navigation - I have a lot of sympathy with this view. As web developers, we shouldn't be forcing such decisions on our visitors.
However, I also know that businesses often want to 'retain control' and so insist on spawning a new tab/window for external sites. An I understand this too - It's a very practical approach, particularly when you consider that how many users don't know how to control their own UA.
I often tend to steer a middle course between the two, by adding an image (I'm sure you will have seen many in your time) that indicates which links are external, and a note to indicate that external links will open in a new tab/window.
Not quite as 'pure' as the first option, but at least it is clear to the user how the site will behave.
found this on the w3c site
Checkpoints in this section:
•10.1 Until user agents allow users to
turn off spawned windows, do not cause
pop-ups or other windows to appear and
do not change the current window
without informing the user. [Priority
2] Content developers should avoid
specifying a new window as the target
of a frame with target="_blank".
More info here
the question you need to ask your client is "To what priority level are you aiming to achieve?"
I think it totally depends on your use case.
If you are opening a site in another domain and need to keep your site open, and I think in most cases you do, then use target='_blank'.
As a user, I find it annoying when I click on a link to another domain and it moves me from the original domain. Of course, using ctrl+click in most browsers is a way to defend against this - but why make the user do more work?
It might also be worth to mention that using target attribute is not xhtml valid. I do usually open links in external window or tab because I see that most regular users (not the advanced ones) want it that way so that they can always get back to the site they were on - usually they would go deep into the other site and then it become unfriendly for them having to click back multiple times.
So in terms of usability I think that there's more users that don't use special techniques to manually open links in new window/tab.
With regards to the xhtml validation, you might want to decorate your links with rel="external" or some similar word then use this JS function to handle new window open. I did it like this 99% of time in the last few years.
function externalLinks() {
if (!document.getElementsByTagName) return;
var anchors = document.getElementsByTagName("a");
for (var i = 0; i < anchors.length; i++) {
var anchor = anchors[i];
if (anchor.getAttribute("href") &&
anchor.getAttribute("rel") == "external")
anchor.target = "_blank";
}
}
/**
DOCUMENT LOAD
**/
$(document).ready(function () {
/**
external links
**/
externalLinks();
....
Just don't do it. Using target attributes with links presents complications for assistive technology users who may not know another tab has opened. It becomes a bad experience for these users when the back button does not work in the new tab to take them back to the page they started on. This practice can also be disorienting to people with cognitive disorders. It is best to let users decide where links will open.
You need to predict what your users want. Use target="_blank" if you expect your users will want to stay on the site.
For example if a blog post has a link in the middle of the post, it makes sense to open that link in a new tab since you are expecting the reader to return to the page and continue reading.
Some people argue that the reader could simply click "Back" when they wanted to come back to the page,
But new webpages will have more links to webpages that have more links, what happens is that the reader has to "Back" a couple of times to get back to your blog post. Either that, or he ends up "lost" in the myriad of linked pages and couldn't come back to your blogpost (you can be sure that no one wants to open History and find your page again when they are "lost", unless there is a big incentive to coming back to your page).
As it is a governmental website, this is a tricky question. I regularly see disclaimers for external sites on these type of sites. I don't know if this is a standard or not.
I think the answer is probably down to your own opinion, which should probably be based on usability and integrity.
Just make two buttons for your users: One to open in new tab, and another to abandon the current page in favor of the linked page.
[ www.google.com ]
[Open Google in place of THIS page]
Related
(I am developing a Node.js/Express web application.)
Is there a way to identify a tab and have its identifier saved locally in the browser so that the identifier is persistent across different pages of the same web site?
Example, my web application is opened by the user in two tabs of the same browser. I would like to know that they are opened in different tabs. Even if the user in tab A presses F5 to refresh the page, I (in the client Javascript) would like to know that the page is still in tab A.
Is there a property of window or another object in the DOM that identifies the browser tab?
Nothing simple. However, there are two interesting technologies that may help you solve your problem.
sessionStorage is the closest to what you described. It gives each tab a different Storage object that you can store random IDs in. It doesn't quite work though, because when you open a link in a new tab the second tab gets a copy of the parent page's sessionStorage object, including whatever you stored in the parent page's sessionStorage.
The storage event is probably what you want to use. You can have your tabs communicate directly with each other to coordinate unique IDs or detect multiple tabs being open. See this question which is focused on how to communicate across tabs in javascript.
Some combination of these two technologies will probably help you solve whatever you are trying to accomplish.
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.
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();
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.
Sometimes a user will click on a link on a page, and it seems that there is no reaction -- nothing is loaded. It turns out that all the links on that page is targeting a window name, such as "news_content". The user previously already clicked on a news headline, and so when the user now clicks on another news headline, that window (usually another tab nowadays) will load the news, but the original tab is still the one being shown. To the user, this seems like nothing is happening.
Are those websites using <a href=" ... " target="news_content"> ? Is it a good idea to use something like that, or can it be changed a little bit so that the focus will go to that tab instead of staying at the original tab?
(is it better that the browser always switch to the target tab? if so, then this problem looks like will be solved).
In my opinion the user should always be in control of whether a link opens in a new window or not - If they're anything like me with numerous tabs endless new windows links are a mess.
What you seem to be asking is why the browser stays at the original page when a tab is updated with content, its simple, it sees it as another webpage, say you had a page that had realtime updating, your browser would not switch to that as it sees you are on another page - for all it knows you could be reading an article, watching a video etc.
All it takes to realise a different tab/window has updated is a little bit of awareness. With windows they would generally open over the current content, however as tabs are in one window this is not possible an it remains closed, but updated.
EDIT: In response to the title... I believe it to be better practice than opening something brand new each time however feel it should be the users choice whether to load a single new tab or stay in the same one. Hope this helps.
One caveat to add to the conversation.
I only use target= when I know the content is destined to be in an iframe and I don't want the link click to stay in the small window.
For example the graphs I embed here : http://webnumbr.com/stackoverflow-questions
Link behaviour should generally be left to the user to control. In some situations, a case can be made for target="_blank" (especially now that Firefox, at least, has a "New pages should be opened in: A new tab" option), but setting all links to open in the same new window is just bad.
I, for example, hate waiting for pages to load, so I'll read down a page middle-clicking each link that interests me, which will queue them up in a series of new tabs. Five interesting links become five tabs, each loaded in the background while I'm reading the first article, so no waiting. If you make all five open in the same window/tab, though, then each one disappears when I call up the next and not only do I have to 'pick one, wait for it to load, read it, go back to the original article, repeat', but, if I don't notice that this is what's happening, then I'll also need to go back and make a second pass through the original page to re-find the links to the lost documents (or, more likely, just say "not worth my time" and never read them).
Forcing newly-opened tags to the front has a similar problem: I opened it in a new tab because I want it to load in the background while I continue reading the original document. Don't subvert my intention. I cleared the "When I open a new tab, switch to it immediately" checkbox for a reason.
Yes, these websites are using target. Well. I can't imagine in which set of circumstances using the target attribute may be useful. But perhaps there's one. I haven't come across it.
Look, always switching to another tab solves the problem you describe, but it creates others. The biggest one is that switching to another tab may come as a surprise. Usability is by and large about never surprising the user. By the way, I greatly enjoyed the book "Don't make me think."