I was wondering if a blogs posts comments should be paginated or not and why? I did not know where to ask this question so I asked it here.
I like the way the NY Times paginates their blogs' comments (see e.g. http://freakonomics.blogs.nytimes.com/2010/09/15/the-magic-that-is-ted/). There are 25 comments to a page, and the pagination links are small and visually subtle so as not to overbear.
I think that it depends on the blog. Think about what the readers would prefer... if pagination makes comments more useful to them, then put in pagination.
Pagination is not the only way — and probably not the best way — to present blog comments. I prefer to see a small selection of the best comments rather than pages and pages of comments. I think that The Daily WTF does this very well: the author manually picks out two or three really good comments to appear on the main page, and the rest get pushed to a separate comments page.
For example: http://thedailywtf.com/Articles/Is-Your-PC-Frozen.aspx
Related
On the morning of May 6, 2016 the number of photos to find it was 4000+, the evening count was equal to 2800 and does not change, although the photos are laid out.
https://www.instagram.com/explore/tags/#tag/
With what may be related problem?
Why are people downvoting this? This is a legitimate (although poorly phrased) question.
I believe it has to do with the update Instagram released yesterday for their layout and search algorithm. The unfortunate side-effect is that tags seem to not include as many pictures as they used to. I'm running a test locally to see what exactly they changed but I suspect they no longer count tags in comments towards the tags of a picture for search purposes.
You used to be able to tag spam in the comments and hit a bunch of different tag "buckets". This behavior wasn't great and lead to a lot of spam, I suspect they only count tags in the original caption as part of the tags attributed to a post.
I chose phpbb3 for my forum. I want my user's post to be voted/rated by other members of my forum and also a user's reputation(ranking) should be changed according to his interaction with posts. Are there any built in features for these two tasks? If not what is the possibility to change the code according to my requirements? Any help is appreciated.
There aren't any built in features for reputation and ranking.
However, phpbb has a large database of user-built modifications which will definitely have what you need. See the mod database: http://www.phpbb.com/customise/db/modifications-1/?from=submenu&sid=b3bee6baf8411639512659054d6521c6
As for coding it yourself, you're certainly welcome to as far as licensing goes; but there will definitely be an existing modification which should suit your needs.
I would like to know if it's possible to paginate using cursors and keep those pages optimized for SEO at the same time.
/page/1
/page/2
Using offsets, gives to Google bot some information about the depth, that's not the case with curors:
/page/4wd3TsiqEIbc4QTcu9TIDQ
/page/5Qd3TvSUF6Xf4QSX14mdCQ
Should I just only use them as an parameter ?
/page?c=5Qd3TvSUF6Xf4QSX14mdCQ
Well, this question is really interesting and I'll try to answer your question thoroughly.
Introduction
A general (easy to solve) con
If you are using a pagination system, you're probably showing, for each page, a snippet of your items (news, articles, pages and so on). Thus, you're dealing with the famous duplicate content issue. In the page I've linked you'll find the solution to this problem too. In my opinion, this is one of the best thing you can do:
Use 301s: If you've restructured your site, use 301 redirects
("RedirectPermanent") in your .htaccess file to smartly redirect
users, Googlebot, and other spiders. (In Apache, you can do this with
an .htaccess file; in IIS, you can do this through the administrative
console.)
A little note to the general discussion: Since few weeks, Google has been introducing a "system" to help they recognise the relationship between pages as you can see here: Pagination with rel="next" and rel="prev"
Said that, now I can go to the core of the question. In each of the two solutions, there are pros and cons.
As subfolder (page/1)
Cons: You are losing link juice on the page "page" because every piece (page) of your pagination system, will be seen as an indipendent source because they have a different url (infact you are not using parameters).
Pros: If your whole system is doing using the '/' as separator between parameters (which is in a lot of case a good thing) this solution will give coninuity to your system.
As parameter (page?param=1)
Cons: Though Google and the other S.E.s manage the parameters without problems, you're letting them decide for you if a parameter is important or not and if they have to take care to manage them or ignore them. Obviously this is true unless you're not deciding how to manage them in their respective webmaster tool panel.
Pros: You're taking all the link juice on the page "page" but indeed this is not so important because you want to give the link juice to those pages which will show the detailed items.
An "alternative" to pagination
As you can see, I posted on this website a question which is related to your. To sum up, I wanted to know an alternative to pagination. Here is the question (read the accepter answer): How to avoid pagination in a website to have a flat architecture?
Well, I really hope I've answered your question thoroughly.
I am trying to build a related posts functionality like what we see here in stackoverflow on the bottom right corner. My main difficulty is that the related posts have to be determined at runtime when loading a particular post.
I am thinking to look for posts with similar or equal set of tags, also similar titles and possibly similar sets of keywords in the main post content, the problem is that the more signals you look for the slower the database will be to return data.
I have also thought about using Google Site Search (we have an account) as Google does understand the relationship between posts very well, but unfortunately the related: parameter is broken according to Google.
I am looking for ideas on how to best achieve this. Has any of you ever done something like this? What's the best way to achieve this type of thing?
I'm creating a Book store in Magento and am having trouble figuring out the best way to handle the Authors of a Book (which would be the product).
What I currently have is an Attribute called "authors" which is multi-select and a thousand [test] values. It's still manageable but does get a little slow when editing a product. Also, when adding an option/value to the authors attribute itself, a huge list is rendered in the HTML making this an inefficient solution.
Is there another approach I should take?
Is it possible to create an Author object (entity type?) which is associated to a product through a join table? If yes, can someone give me an explanation about how that is done or point me to some good documentation?
If I'd take the Author object approach, could that still be used in the layered navigation?
How would I show the list of all books for a single author?
Thanks in advance!
PS: I am aware of extensions like Improved Navigation but AFAIK it adds something like attributes to attributes themselves which is not what I'm looking for.
For Googlers: The same would apply for Artists of a music site or manufacturers.
If you create an author entity type, you'll just increase your work trying to add it to layered navigation, and I don't see a reason why it would be faster.
Your approach seems the best fit to the problem, given the way Magento is set up. How are you going to display 1,000 (which presumably pales in comparison to the actual list) authors in layered navigation?
Depending on the requirements, you could go the route of denormalizing the field and accepting text for it. That would still allow you to display it, search based on it, etc, but would eliminate the need to render every possible artist to manipulate the list. You could add a little code around selecting the proper artist (basically add an AJAX autocomplete to the backend field) to minimize typos as well.
Alternatively, you could write a simple utility to add a new artist to the system without some of the overhead of Magento's loading the list. To be honest, though, it seems that the lag that this has the potential to create on the frontend will probably outweigh the backend trouble.
Hope that helps!
Thanks,
Joe