I got stumbled upon this issue once and I guess I need some expertise in getting through this .." some links that one likes to bookmark ." I tried browsing and got confused. is bookmarking just means the use of CTRL + D. Or is ti something like the one in this link .
"Bookmarking" comes from marking a page in a book with a bookmark, i.e. a piece of paper or something you put between pages to remember that page. In the same way you can mark web pages to return to them later. This usually just means saving the URL of the page in the browser.
So called social bookmarking is a technique where the URL is not saved in the user's local browser, but on a service such as del.icio.us, so others can see what you have bookmarked.
The basic idea is to remember a page you were on for later reference, that's all it means.
Bookmarking is storing the links somewhere. It can be a bookmark on your browser or even online something like StumbleUpen or Read It Later or even social bookmarking like sharethis.com
It can mean both, bookmarking generally means to add it to your favorites. Although, times they are a changing!
It is same as with "plain old bookmarks": You somehow keep a reference to a certain page. But instead using some physical indicator (what is obviously not possible with the computer ;)) you store the URL somewhere for fast access (in a way it is writing down the page number of a book).
Related
I like them more and wonder why they are not more common. Explanations involving caching or SEO make sense to me, but I don't see them as directly driven by user experience considerations. In which way are traditional sites with page reloads better for the user?
Personally I think the best argument for normal page reloads from a user's perspective is that when you do that it's much harder to break many basic browser functions. In general the back/forward buttons work, bookmarking works, copying and pasting links works, history works, page titles work, getting an error page when a server call fails works, everything just works as expected. For free.
I have seen single page application implemented in a way that breaks one or more of the above more times than I can count.
It's naturally not a problem if you get it just right (and then it will in general be nicer to use), but not all sites do.
Just as an example here's a screenshot how a site that is a SPA and justifiedly so (they have a music player that you don't want to interrupt with page loads), broke a basic browser function in a way they might not even have thought of. I was trying to find a song I recently listened to but couldn't remember the exact title... but because of the SPAness the page titles weren't properly reflected in my browser history.
I've read quite some post about the angularjs html5Mode including this one and I'm still puzzled:
What is it good for? I can see that I can use http://example.com/home instead of http://example.com/#/home, but the two chars saved are not worth mentioning, are they?
How is this related to HTML5?
The answers links to a page showing how to configure a server. It seems like the purpose of this rewriting to make the server return always the same page, no matter what the URL looks like. But doesn't it read to needlessly increased traffic?
Update after Peter Lyons's answer
I started to react in a comment, but it grew too long. His long and valuable answer raises some more questions of mine.
option of rendering the actual "/home"
Yes, but that means a lot of work.
crazy escaped fragment hacks
Yes, but this hack is easy to implement (I did it just a few hours ago). I actually don't know what I should do for in case of the html5mode (as I haven't finished reading this seo article yet.
Here's a demo
It works neither in my Chromium 25 nor in my Firefox 20. Sure, they're both ancient, but everything else I needed works in both of them.
Nope, it's the opposite. The server ONLY gets a full page request when the user first clicks
But the same holds for the hashbang, too. Moreover, a user following an external link to http://example.com/#!/home and then another link to http://example.com/#!/foreign will be always served the same page via the same URL, while in the html5mode they'll be served the same page (unless the burdensome optimization you mentioned gets done) via a different URL (which means it has to be loaded again).
but the two chars saved are not worth mentioning, are they?
Many people consider the URL without the hash considerably more "pretty" or "user friendly". Also, a very big difference is when you browse to a URL with a hash (a "fragment"), the browser does NOT include the fragment in it's request to the server, which means the server has a lot less information available to deliver the right content immediately. As compared to a regular URL without any fragment, where the full path "/home" IS including in the HTTP GET request to the server, thus the server has the option of rendering the actual "/home" content directly instead of sending the generic "index.html" content and waiting for javascript on the browser to update it once it loads and sees the fragment is "#home".
HTML5 mode is also better suited for search engine optimization without any crazy escaped fragment hacks. My guess is this is probably the largest contributing factor to the push for HTML5 mode.
How is this related to HTML5?
HTML5 introduced the necessary javascript APIs to change the browser's location bar URL without reloading the page and without just using the fragment portion of the URL. Here's a demo
It seems like the purpose of this rewriting to make the server return always the same page, no matter what the URL looks like. But doesn't it read to needlessly increased traffic?
Nope, it's the opposite. The server ONLY gets a full page request when the user first clicks a link onto the site OR does a manual browser reload. Otherwise, the user can navigate around the app clicking like mad and in some cases the server will see ZERO traffic from that. More commonly, each click will make at least one AJAX request to an API to get JSON data, but overall the approach serves to reduce browser<->server traffic. If you see an app responding instantly to clicks and the URL is changing, you have HTML5 to thank for that, as compared to a traditional app, where every click includes a certain minimum latency, a flicker as the full page reloads, input forms losing focus, etc.
It works neither in my Chromium 25 nor in my Firefox 20. Sure, they're both ancient, but everything else I needed works in both of them.
A good implementation will use HTML5 when available and fall back to fragments otherwise, but work fine in any browser. But in any case, the web is a moving target. At one point, everything was full page loads. Then there was AJAX and single page apps with fragments. Now HTML5 can do single page apps with fragmentless URLs. These are not overwhelmingly different approaches.
My feeling from this back and forth is like you want someone to declare for you one of these is canonically more appropriate than the other, and it's just not like that. It depends on the app, the users, their devices, etc. Twitter was all about fragments for a good long while and then they realized their mobile users were seeing too much latency and "time to first tweet" was too long, so they went back to server-side rendering of HTML with real data in it.
To your other point about rendering on the server being "a lot of work", it's true but some consider it the "holy grail" of web app development. Look at what airbnb has done with their
rendr framework. See also Derby JS. My point being, if you decide you want rendering in both the browser and the server, you pick a framework that offers that. Not that you have a lot of options to choose from at the moment, granted, but I wouldn't advise hacking together your own.
The reason I am keen to do this is that we have a wiki which works great, but I would like to store help pages for an internal application in the wiki and link to those pages direct from the app. Although we wouldn't have concerns with people seeing the non-article stuff (i.e. the help pages) when viewing the pages from the rest of the wiki, for it to be streamlined when viewed from the application I thought it would be ideal if I gave it a simplified skin which I would design.
I have already found out that URLs can have the useskin= added (e.g. as is done in the Preview Skin page within the User Preferences pages), but following the links will revert you to your normal chosen skin.
Is there perhaps some way to adjust the skin, so that all the links contain useskin=? (I think this might have issues, since you appear to need the full pagename for useskin to work (e.g. ..../w/index.php?title=blah....&useskin=cologneblue as opposed to the short URLs).
If this isn't a smart way to go, I could consider different approaches (I run the box the wiki is on and could create a distinct wiki perhaps, although there might be disadvantages to this, such as needing to combine the user tables and maybe this would still pick up the user's preferred skin unless I re-coded things).
Any sensible suggestions gratefully received! Let me know if there's any more info you might need or if I need to clarify any points about my objective.
[I did submit this on the MediaWiki.org Support Desk page, but it got no response... I hope my question isn't that bad!!]
You could put all your content in its own namespace, then set the skin for that namespace using this extension (I've used it, it works well enough):
http://www.mediawiki.org/wiki/Extension:SkinPerNamespace
If you don't want to lock them all into a single namespace, you can also use the SkinPerPage extension to mark the pages individually.
Why not change the default skin to the skin you want?
When are appropriate situations to use the target="_blank" attribute on your hyperlinks?
Edit:
To clarify, I know the syntax will open a new browser window. What I am asking is when is it appropriate to do so?
Whenever you want to annoy users.
More seriously, since this opens a new window/tab, it should be used sparingly, in my opinion.
Most modern browsers have some option (ie: middle-click on hyperlink) to do this for you, so I personally prefer allowing the user to handle this themselves.
However, if you are working on something where there is a non-technical reason for this, such as a sales-oriented site, it's often desirable to open a product brochure in a new window, or something along those lines. However, just be aware that overdoing this leads to my pseudo-joke response above....
When ever you want to leave the current page as-is.
I've got a feeling your question should be 'When is it appropriate to open a new tab or browser window?'
If so, the answer might be :
The current form may be in edit mode, and you want to be able to open
another page without either
disregarding or saving the current
one.
You have a data stream like Twitter which you want to leave active while
you go off and look at X.
There is a specific business requirement to do so.
Your users have weak navigation abilities and won't find their way back to the main page.
It is most appropriate when you're linking to outside resources that people may want to go to for additional information, reference, etc.
It lets them leave your site without losing their place on your page or have to use the back button.
It also makes sure they have to look at it one more time if they want to close it ;-)
(that last one is a joke and I don't advocate such despicable practices of course...)
Generally I avoid it like the plague. However, perhaps a good example of why you'd want to use that would be if you're building a cart module or something, and you have the "click for bigger picture" link. I think it's ok in that sense.
Keep in mind that whenever you do it, you're assuming you know the user's workflow better than they do (they can always open the link in a new window without you forcing it). In the case of the "bigger picture" link, you'd most likely be correct in assuming that's what they want, but in most cases I wouldn't jump to conclusions.
When you want the link to open in a new window, I would assume. I think the time to use this is when people might click on a link that'd destroy what they were doing on the page currently, such as a "help" link on a form.
Though some would argue that you should never use target="_blank".
One thing to be aware of here is accessibility. Built in features to help blind users (text to speech for example) may act weird (or just in a way that's confusing to the user) when you open a new window or tab.
Also, you're breaking the most used feature of every browser...the back button.
Only if it, with outmost certainty, prevents the user from having to repeat something.
I think that you should probably not ask a user experience question in a developer forum, because you will get developer answers.
That said, and as a developer, I open new Windows when I expect (or want) the user to come back and continue working on the site where the link originated.
The only time I would consider it is if you have multimedia on the page.
Best example I can think of - the StackOverflow podcast... I can't tell you how many times I've rushed to click a link in the blog post only to take me off the podcast page!
Also, on YouTube when I click "View Comments", it takes me away from the video page.
Whatever you do, don't use JavaScript to open a new window. That's definitely the worst. Nothing worse than a middle-click only to open a new tab with javascript::garbage in the address bar.
The target="_blank" is deprecated in XHTML 1.0 strict, and since I only write in strict I use JS if I really want to open a new page (or tab) and I only do that for external links (like a wiki or so).
More info:
http://www.ajaxblender.com/open-links-new-window-w3c-valid-target-blank.html
NOTE: Although it is deprecated in XHTML 1.0 strict, target="_blank" been brought back in HTML 5.
Stydying your audience will help you decide on this. Casual websurfers will appreciate target=_blank while tech-savvy people are more likely to get annoyed.
As for XHTML 1.0 strict, it is never appropriate. The target-attribute is deprecated in XHTML 1.0 strict.
Never. If I want to open your link in a new window I will do so.
When you open the link in a new window.
There exists practice to open in new window links that refer another/external domain (wiki for example).
I use it for product brochures and the like as I think it is useful for the customer to stay on the product page. I always indicate [new window] next to the link to keep the customer informed. Often the product brochure is a PDF, so I also note that the link will open a PDF.
Use it as you need it, but keep your users informed so as not to annoy/confuse them.
I prefer to avoid it, because most users can figure out on their own how to open a link in a new window, even if unsophisticated. My preference is to use an explicitly named destination, e.g. target="somename" if you have a good reason for opening a new window on your own.
I only use it when the client insists.
Otherwise I prefer to let the user decide.
I might be in the minority here but I like using target="_blank" for my links ONLY when they're meant to be reference links. In most cases, you shouldn't be using it for regular links around a website.
I really don't like it when I click on a link in a blog post or an article and it loads on the same page and I need to navigate back to the original source page.
When you are creating an email for mobile users and are linking to external content. That way, when they click on the link they will open the page in their browser.
When you want to open any particular link in new tab on current window then you can use target="_blank" in html.
<div class="restrunt-menu-list">
<ul>
<li>
<span>
<a target="_blank" href="www.example.com">View Menu</a></span>
</li>
</ul>
</div>
But It might affect your system performance because all browsers takes a lot of memory when it open a new tab or new window.
So less opened tab means less memory uses, less memory uses means better performance.
You can also see that which tab using how mach memory in chrome:
Press shift+Esc , Then you can see Task Manager- Chrome with list currently using memory by each tabs ( in chorme ).
For all external links...
Why on sites like Stack Overflow, Techcrunch, Smashing Magazine, etc. are the page titles (i.e. the text at the top of the page) clickable URLs that redirect to the same page that the user is on?
Some examples:
I believe that this does not effect SEO as search engines ignore internal links.
Is it for usability purposes?
It allows you to right-click on it and choose Copy link location (or equivalent) so that you can easily paste it in an email for example. This requires less time than copying it from the location bar, and some people run their browser without a visible location bar to save previous screen space.
More than anything, it provides a link to the default state of the page.
For example, for this very stack overflow page it is a user can get here through any of the following non-default links:
Why are Page Titles on some websites (including Stack Overflow) Clickable URLs?
https://stackoverflow.com/questions/904381#foobar
https://stackoverflow.com/questions/904381?sort=date
While the default link is actually:
Why are Page Titles on some websites (including Stack Overflow) Clickable URLs?
If users are unable to get to the default state, they end up bookmarking or emailing the non-default link which propagates to new users and the problem just multiplies.
Clicking on the title link of the post will restore the default state and strip off any query parameters (?sort=date), named anchors (#foobar) and fix the story slug (/why-are-page-titles/...).
I use it to refresh the page (yes, I could press F5 too).
Yes Jakob Nielsen has stated that linking to yourself is a web design mistake (nr 10). And I agree.
More reading info here. (nr 10)
The URL redirects to the beginning of the page, in case you arrived on the page via a specific answer (all answers are also clickable URLs). This way, you get the URL of the question, not of an answer.
Not sure if this is why they did it, but I find it useful to siphon off tabs:
If I look at something briefly and think "I'd like to read this thoroughly in a minute but continue with what I was doing before", I can do this:
I can right click the link, click "open in a new tab" and then click "back" and continue nicely.
It's called a Permalink... The name implies what it is, a permanent link.
It's the same reason that each answer on SO has a link you can copy.
I think it inherits the behavior from CMS where each question is a node, which has 0<= answered question. Now think you go for a search on apache questions.
The result are displayed one after another.
In terms of CMS this is called a teaser. You get a full page with lots of questions where the question's title link to the full article(question + answers)
Its not a must, but you'll find it on most sites which uses a CMS.
As long as it does not harm anyone why would people be against it?
I prefer to have those links available as hitting refresh would reload all elements of the page instead of just following the direct link (to the same page) that uses cached elements.
Makes sense to me, I find it useful! I have a lot of tabs open so I just right click the link and go back.
To me this makes perfect sense, from a SEO view this is also good! It forces it to read the page because it's linked.
UX-wise clickable titles which don't bring the user anywhere may seem unusable though that leads us into the realm of Affordance Theory and whether or not the affordance is perceptible to users.
For example, clickable page titles may provide:
A simple method for bookmarking a page to the desktop from a browser window.
A context menu with additional choices allowing users to share a blog post or article.
A method for updating the location bar so it's pointing at the canonical URL of the page.
For the sites you mentioned, however, it seems more likely the page titles were turned into hyperlinks using absolute URLs so analytics tooling could pick up inbound link clicks – those sending the referer info – resulting in DCMA takedown notices when people copied work and didn't update the URLs.
You'd be surprised what people do when they're being incentivized to produce work contractually.