Fantastic community you have here, onto my first question.
I'm creating a blog completely from scratch, and already know that I can load content on scrolling events using jquery and PHP (to save loading it all at once). For those of you who don't know how or what this is, you can find a tutorial link here:
http://www.9lessons.info/2009/07/load-data-while-scroll-with-jquery-php.html
However, this method relies on javascript requests. In the name of good practice and for the 1-2% of people that still load the yahoo homepage with java-script disabled. This could result in a user only loading a few posts, or loading the entire set of posts. I'd like to find the best progressive workaround that will allow me to:
If Javascript is enabled (load content using the above JQ/PHP scrolling method as normal)
If Javascript is disabled (Grayskull Forbid!?) fall back to a more html/css reliant method automatically, without me having to design for it separately.
Quite a complex question, I hope it makes sense. If I'm thinking along the right lines, the html/css fallback might be to break up the content with separate pages and page buttons, but I'm unsure how the two might translate together, for instance, what I design for the JQ/PHP scrolling method seems to be within one loading page, where the html alternative seems to be on separated pages.
I could use some advice.
To give you an idea: pseudo code:
<noscript>
<!-- Server-side language generated pagination -->
1
2
3
</noscript>
<content>
<article>
<article>
<article>
<article>
<!-- JS pushes new content on scroll with AJAX, otherwise...-->
</content>
<noscript>
1
2
3
</noscript>
Related
Example in code:
No page navigation:
<body>
<nav>
// Navigation links to the parts of the site.
// Clicking a link calls a javascript function to display the relevant <div>
</nav>
<section id="page1">
// Page 1 content
</section>
<section id="page2">
// Page 2 content
</section>
</body>
Page navigation:
// Page1.php:
<body>
<nav>
// Navigation links to parts of the site.
// Act as normal <a> tags, redirecting the browser to the new page
</nav>
<section>
// Page1 content
</section>
</body>
// Page2.php:
<body>
<nav>
// Navigation links to parts of the site.
// Act as normal <a> tags, redirecting the browser to the new page
</nav>
<section>
// Page2 content
</section>
</body>
Pros for link navigation:
The browser doesn't need to load the entire site all at once
No javascript needed to use the site
Provides direct URLs for easy navigation
Seems like the standard thing to do
Pros for javascript navigation:
For sites with heavy server-side scripting (like mine), minimizes page requests
No need for the same code in different places (the <nav> element, for example). Creating a echo_nav_html() function in PHP is not a good solution, as it makes coding in an IDE environment annoying
After initial load, site is superfast, as barely any new requests are sent to the server
Oh wise internets, any thoughts on this?
Or maybe more elegant solutions that provide the pros listed for javascript navigation?
The best solution is to do both.
Have valid links on the HREFs on your anchors, but include onClick actions that load the div and disable the progress to the HREF.
Read about graceful degradation and progressive enhancement.
There are lots of reasons to provide non-JavaScript code. Not all browsers support JavaScript. Lots of corporate networks still use ancient versions of IE that may behave unpredictably, or they may force configuration that disables JS entirely.
You want your site to be usable by everyone, but provide the best possible experience to those users who have the technology to support it.
If you are using a heavy dose of server side code (assuming that means dynamic content generation/population), I would probably use links to other pages as I can't imagine that loading all the content you could possibly access on the site on initial load is real resource efficient, especially assuming not every user will access ever section of the site.
You can still use javascript, but I'd only generate the content when it's actually requested; whether that be through an AJAX call (so the URL's being called there) or loading a new page. Seems kind of wasteful to me to load everything at run time...that's just me though.
I've created a website with only one page. On this page, i can click on images and i show or hide popup (with jquery).
It works fine.
All these popup contains text, images (i use php to generate this content).
<div id="pop_up_1>
<!-- content : text / images -->
<div/>
<div id="pop_up_2>
<!-- content : text / images -->
<div/>
and so on
It's like i have 10 pages inside one page. It's a lot of content.
Do you think it's better to load everything at the beginning or load the content with jquery ajax :
$("#myDiv").load("ajax/video-mur-images.php");
I've tested the 2 solutions and i'm not sure which one to choose.
The first one : everything is loaded and no more query after but a lot of source code and elements.
The 2nd one, less elements and less source code but i have to load the content when the user click on a button.
I guess it depends on how much data i need to load. So what is the limit i should consider ?
This is an interesting philosophical question. Often, as you do now, developers start with data volume, but in the end it's all about user experience.
Does your page load slowly? If so, have followed the best practices to speed up page loads? And what would annoy the user more -- initial load or to have to wait on each interaction?
Also note that while web crawlers for search engines are getting better, they do not load your AJAX content. When you decide to go on this path, use a framework that gives you bookmark capability and also makes internal links understandable to the crawlers.
It's definitely better to use AJAX (or even better PJAX) to load the content. Simply because you don't know how many pages there will be in the future. Serving all pages in a single request means that you might do 50 database queries, while the user only needed the page that does 0 queries.
What has been known for a while, is that a "fast navigation" works easily for http://example.com/#1 --> http://example.com/#2.
However, there is a new technique out there. It enables fast navigation between http://example.com/1 --> http://example.com/2.
EXAMPLE: http://rageslide.com/
As you can see in the example, the navigation between http://rageslide.com/1 and http://rageslide.com/2 etc. via swiping apparantly DOES NOT FORCE THE ENTIRE SITE TO RELOAD.
I'd like to do the same for my site, but I have no idea how to do this. All pages served by my site are dynamic (via PHP and MYSQL).
I have this idea:
Cache the generated output of a page (http://example.com/2) for 60 seconds.
When the user is on http://example.com/1 preload (http://example.com/2) via Javascript.
The user navigates from http://example.com/1 to http://example.com/2. Since the content is preloaded and cached, the content will be served to the user instantly.
Different idea:
Somehow, http://example.com/1 is being interpreted as http://example.com/content.php#1 through a .htaccess. But I have no idea if this is possible or not.
Will this work? Or what would be the best way to solve this problem?
No, the url you see there is not used to load another page. There are AJAX requests in the javascript code contained in the website, that load the new content to display and update the URL bar.
You can read more about it in this article and in the following questions asked in the past:
Modify the URL without reloading the page
Updating address bar with new URL without hash or reloading the page
i can think of two possible thing you can try out.
first is simply use iframes to load the next and previous page of each page, and when someone swipes to the next page load the next page to a new iframe or a div with ajax or any other html element for that matter.
the other is to use the rel attribute, here is an explanation about it.
hope this helps you out
you can get pretty close without scripting anything or degrading the site by letting the browser cache the expected navigation point resources
for caching images, put dummies at the end of the body
<img .... height="0" width="0">
and for pages
<link rel=”prefetch” href=”url” /> there is also a rel attribute for next and previous for slide viewer type pages
Note: the url can be a javascript resource
Note2: the transition may be slightly less clean than dynamically populating from javascript especially on larger complex pages, but will still work with noscript or javascript turned off, so maybe a good fallback
i have been building a jquery navigation based site without reloads ( using PHP and AJAX ) and have recently come across the problem of page "back", "forward", and "reload" features as well as SEO friendliness.
--skip this section to get straight to question--
my site is currently (not using AJAX but ) loading a single index.php which has several "content" divs, one of which is visible (class="active") while the others are not displayed. When the user clicks a navigation link, a nice animation switches between content divs.
I have apache rewrites to map things like
http://mysite.com/about
to
http://mysite.com/index.php?page=about
where the "about" section would be the one thats displayed by default (while the other "content" divs are hidden). based on this parameter, i include the proper meta tags for the pages. my sitemap has mysite.com/about, mysite.com/blog so that they get indexed as nice separate pages.
However, I've recently decided to make this ajax-based since i plan to incorporate a lot more content and its stupid to load all content on one page.
Note: I'm also now implementing Smarty templates.
I decided to implement hash tags, but saw the inherent SEO problems, then i discovered hashbangs (wth?!) and then found the new HTML5 stuff with history.pushState() and History.js and have decided to use it.
so here comes the main question
if i have just one page which loads page templates in a content div with ajax, using history.pushState() to modify URL and using mod_rewrite and a PHP back-end that can serve a default content template in the case of a direct request like "mysite.com/about" (mysite.com/index.php?page=about) (for basic useabilty and SEO), i cannot also set meta content for direct requests unless i have two templates - a content template - and a meta template? is there another way around this?
are tags like <title> and <meta name="description"> important enough to warrant having a template especially for them?
in summary, i want my nice mod_rewrite URLS to pull up on google with the correct title and meta description for a particular ajax-loaded page content template.
EDIT
i'm going for pretty much the same thing they have going on here at hypem.com. they have an event listener which changes the <title> tag when new content is listed. they also serve the correct <meta name="description"> tag, but only if it is a direct request to one of the main pages, like blogs - other pages, like http://hypem.com/blog/indie+today/10332, return the meta tag for the main blog page, and only when directly requested
I would first build the site to work with all direct links and no ajax, and then add the ajax. However, only include the code that adds the ajax/history functionality if the page is being requested by a browser. If a web crawler hits your site, don't include the ajax/history functionality.
I have some content I would like to share with other websites.
Currently I do this via an iframe:
<iframe width=“540”; height=“700” frameborder=“0” src=“http://www.energiekostencalculator.nl/forms/frame_tabs.php?first=yes&product=1&links=1&css=http://www.energiekostencalculator.nl/forms/susteen.css”></iframe>
This has two problems.
It is not SEO friendly. The links on the content of the iframes do not count as inbound links since they page is hosted on my server.
It is (on my server anyway) not possible to link outside css stylesheets to the content of the iframe. The objective is to allow other websites to easily link their stylesheet to my content.
Who has the solution to these issues?
Perhaps using jquery (see below), however I'm not sure Google would parse it and "see" the links...
<html>
<head>
<script src="/js/jquery.js" type="text/javascript">
</head>
<body>
<div id='include-from-outside'></div>
<script type='text/javascript'>
$('#include-from-outside').load('http://example.com/included.html');
</script>
</body>
</html>
Have a look at how TripAdvisor does it - a static link and then javascript to replace it once the page has loaded.
<div id="TA_rated459" class="TA_rated">
<ul id="JRrkXsd6H" class="TA_links GYO6Zcd">
<li id="IN1Gc4AMw8T" class="zQkgIs4xdv"><a href=http://www.tripadvisor.com/Hotel_Review-g294207-d501440-Reviews-Ngong_House-Nairobi.html>Ngong House</a></li>
</ul>
</div>
<script src="http://www.jscache.com/wejs?wtype=rated&uniq=459&locationId=501440&lang=en_US"></script>
There are some better alternatives to iframe but its really up to the "other websites" to make it crawlable by creating HTML snapshots, Making AJAX Applications Crawlable.
As for your code example, Its not possible to load content from external domains, due to the Same origin policy.
Other iframe alternatives maybe a script tag, which most widgets use, where you tell your content users to embed your widget (script tag) into a parent div which will hold the content, and when your script loads it will automatically fill its parent element, with content.
There is a more "advanced" way of doing this but it might be limited by certain shared servers. Any other way I don't think you could solve your issues either by AJAX or iFrames. Since it looks like it's all html and javascript other than what gets parsed via php prior to the displaying of the page you should be able to load the actual contents of the site directly from server to server via fsocketopen and then do anything with that content from the other server. You could pregenerate code that could be used by your clients or customers on their servers.
A collection of links with no context isn't going to be SEO friendly, period. Spreading a chunk of HTML that just has some links in it around the web is just going to trash the PR of people who embed them. If you want SEO benefits, then you need unique (relevant!) content containing the links on each site linking in (otherwise welcome to duplicate content penalties).
Given that, you might as well just continue to use an iframe (assuming there is a benefit to showing the links to visitors to the other sites).
I think you could probably have a DIV with overflow: auto; (and specify dimensions). Then the HTML can be inside the DIV (and so part of the page) rather than in a separate file.
Maybe you should create an API. This will definitely solve issue #2 - allowing publishers to style up your content any way they like.
And about issue #1 - SEO - I'm not sure. Don't understand the language of the site, but to my understanding you allow people to embed some kind of useful calculator to their own pages, while the content of their pages would generally stay unique, so this may or may not be SEO benefitial, I'd also like to know if any SEO experts read this.