All posts in the topic Next and Previous Post (Short link)
Summary
- There are 4 posts — by 2 authors — in this topic.
- Latest post made by Michael JasonSmith at 2009 May 12 09:11 UTC
On the Post page, the Next and Previous post controls currently navigate within
the Topic. This task is easily supported by navigating to the topic, which is
easily done from the Post page.
Today, I wanted to find the previous post in the group, but couldn't. I suspect
this is a common task as, in many groups, topics change without reflecting a
break in the flow of conversation.
In my example of today, the author had quoted a previous post but not linked to
it.
Should the Next and Previous post navigate within the group, not the topic?
Changing the behaviour of the First Post, Previous Post, Next Post and Last Post is an interesting one — albeit a lot of thought for a relatively minor task. The current behaviour was created to help with debugging, rather than to assist normal users, so I am open to change. I would prefer that we went with one meaning for the links, rather than providing eight similar links. Having said that, I think it would be best to stick with our current semantic for external consistency — especially as your use case is a bit weird, Dan. Maybe a related-posts link would work? A fuller explanation, for those that can be bothered, follows ☺ The current behaviour of the Previous Post and Next Post links is not based on any study of user-tasks, and I do not think that the behaviour is necessaryly correct. I originally added the links as a debugging tool, as they allow me to figure out the post that crashes a topic. (I start at the most recent post and work my way through the topic, seeing if each post renders ok.) I could still debug topics on a per-post basis, so I am not too fussed about changing the semantics of the links. I dispute that the task of viewing individual posts in a group is common, Dan. Viewing a topic and posting to a topic are common; anything done on a per-post level pales into insignificance compared to these two tasks ☺ Rightly so, as GroupServer is designed to encourage people to use topics, which is why it takes so many clicks to get to the Latest Posts page. We get a lot of feedback that the topic-centric behaviour of our groups is good, and that they are better than email (no one actually seems to use threads, outside the tech community). I would like to avoid having too many links on one page. I would also like to avoid having two links that are close together spatially and conceptually, such as the "Next Post in List" and "Next Post in Thread" that I have seen in some places. Whenever I come across these I have to think quite a lot about the link I want to click, and I always choose the Next Post in Thread link. (I hate having to think about simple things…) If we go for external consistency, then keeping the links pointing to posts in the same topic gets a boost, as Mailman works this way <http://mail.zope.org/pipermail/zope3-users/2009-May/008564.html> Google Groups does not allow you to view an individual topic, so we cannot look there for any guidance. What does Yahoo! groups do, Dan? Your example does sound weird, Dan. The person changed the topic but did not change the topic‽ While we cannot make people stick to the topic (especially using email) we do a good job of organising the mess. There is only so much we can do, sadly. One possibility is to rely on the "References" header in the email message to create a link to posts that are not in the current topic. It would be quite a lot of work to create, as we would have to extract and index all external post-identifiers (which are crated by email clients) so we can map them to topics. Alternatively we could use our keyword-generating system to suggest other topics (or posts) that are like the current one. That would also require a fair bit of work and place strain on a component that is already doing a lot of work. And for a task that is how common? Na, stick with the current scheme ☺
I agree that the whole question relates to an uncommon way of viewing
posts (I'm not clear why you thought I didn't). My guess (we have little
or no data) is that the most common reason for viewing a post is when
following a short link to a post. This is itself uncommon.
I also entirely agree that supporting both types of post-navigation is
not worth considering (as I said, navigating in a topic is already
supported in the topic view). My proposal is to switch to next/previous
post in the group, if for no other reason than that this is not
supported elsewhere, so we don't know whether people would use it. It's
not an uncommon way of navigating beween posts (vis email).
My use case is not weird. I know from reliable anecdotes that some
groups do not thread one bit. They just post one after the other,
regardless of the subject line. Of course, these same foks don't much
use the web interface, but if one person in the group did, they may be
glad to find that there is actually a way to follow their group's
conversations. Even when people do usually use topics well, there is the
odd break in them. Likewise, in a group with topics that span a long
time, I may only want to read one or two posts in a topic, before
finding another recent post. This provides one case of the 'related
post' feature you mention, in a simple and recognisable way.
I said that the task was common, because I disagreed with your statement “I suspect this is a common task…“. <http://groupserver.org/r/post/20QVevWCNIigWEPlauP3yh> I am sorry if I misunderstood you I am unsure what you mean by “[viewing posts outside topics] is not supported elsewhere”. Viewing posts in a purely temporal context is supported by four interfaces: *Latest* *Posts* <http://groupserver.org/groups/development/messages/posts.html> *Latest* *Posts* *Summary* <http://groupserver.org/groups/development/messages/postsSummary.html?l=60> *Search* <http://groupserver.org/s/?g=development&t=0&p=1> *Web* *Feeds* <http://groupserver.org/s/search.atom?g=development&t=0&p=1> Even viewing individual posts in a temporal order is supported (sort of): <http://groupserver.org/groups/development/messages/posts.html?start=20&end=21> The URL for each post is always changing, however, so it is not that useful. The problem with anecdotes is that they are just little stories, reliable or not. Until we have real data we can just end up in anecdote-wars ☹ People saying that they like topics comes from large surveys, where people state they use the web interface as much as email. The surveys are backed up by posting statistics that show the web interface is used for posting and viewing statistics that show the topics are viewed. Data is more useful when making design decisions for a general audience than any anecdote. You state that your use case is not weird, but then state “these same folks don't much use the web interface”. This seems a little contradictory to me: if they do not use the web interface much then surely visiting a single post is actually weird? Even weirder, how did the user come to the single post view if he or she does not use the web much? The interface emphasises topics, rightly or wrongly. In the case of groups that do not follow topics I would love to have a group that ignored topics altogether: * No topics page * Latest Posts shown by default, and * Add to Group would replace Add to Topic (I would put it at the top of the Latest Posts page). That would actually be easier¹ than figuring out which Next and Previous links we should show, and implementing them. As for long-lived topics, we have on our horizon a scheme to fold old posts in a topic out of the way, making it easier to scan recent posts. I currently get around the problem by using the Latest Post link in a topic, scrolling up a little to check other posts (and get more context), before skipping to the next topic. (I actually use the Next and Previous links that are provided in the page metadata, but I suspect I am the only person to ever use those.) [1] Creating a new group type would be easier once we have our mythical group product written. Even with our current schedule I suspect the Group Product will pip an enhancement to the lowly post-view page.
This site is provided by OnlineGroups.Net, where you can start your own free online groups site, using the open source web-based mailing list manager GroupServer.