View New Content enhancement

[KT Walrus]

Since my suggestion to have all content (for all apps) stored into a single topics/posts table for better searching and tighter integration of the forum and other apps is not going to be acted on, I'd like to make another suggestion in this area.

As a user, I don't like the way View New Content is presented to the user. You have to click on the individual tabs for each app to see if there is new content for the content that the app manages. Obviously, the forum is probably the most frequently updated area, but since other areas, are less so frequently updated, I rarely think to click on these area tabs. This results in missed content.

At the risk of slower performance, I'd like to see all the new content for each app fetched when the View New Content page is first loaded and cached. Then, the tabs could at least show the new content counts in each tab. Ajax (or even full page subsequent loads) could be used to fetch the cached content for an app and display it. The cache would be refreshed if the user clicks on the original View New Content link again, otherwise, the content of the page doesn't need to change (maybe update the unread topics markers).

Anyway, I'm not advocating any specific implementation. Rather, that the page the user sees for View New Content should have new content counts for each tab as well as the list of new content in the active tab.

[bfarber]

We really wanted to do this. Fundamentally, as a user, you are right. However on a large site, you even noted "at the risk of slower performance" - it's simply not a reality to perform x number of search queries on one page load.

Sometimes, the environment of the application limits what an application can realistically do, I'm afraid.

[KT Walrus]

[quote name='bfarber' date='07 August 2009 - 04:20 PM' timestamp='1249676449' post='1840138']
Sometimes, the environment of the application limits what an application can realistically do, I'm afraid.


Well, I'd just put it on a switch (an Optimization Switch) then. The result of the search queries could be cached so that they are done only once on initial load of the View New Content page. Most users probably wouldn't refresh this page that often and if they did, you could place a limit on the number of seconds before they can check for new content again (and just use the cached data in the meantime).

Also, I bet most of these queries are pretty fast since they are just using the thread's last update times (which I think is an index). So, doing 5 or 6 of these might not be too bad. If you did them using AJAX (so there were 5 or 6 AJAX calls fetching the data for the tabs that are hidden and update the New Counts through the AJAX), you could spread out the queries with a few seconds delay between them so they don't monopolize the server.

One other approach would be to only ask the app whether there is newer content and not return the count or the actual data. Such a query should be even faster due to being an index query and the case of "no new data" might even be faster by checking already cached data for the area.

Anyway, there are all sorts of ways to implement this in a fashion that the user gets the best information and the server load can be "managed".

Still, the default action in situations like this is usually to put the feature on a switch so it can be disabled if there aren't enough resources available for the feature.

I just hate having to go clicking on all those tabs! So much so, that I don't think I will do it very often.

[Teddy Rogers]

I also want to see this feature, even suggested having a marker stuck on the other tabs to signify new content was present in that area.

There must be a less intensive and server consuming method of retrieving some basic indication that new content exists even if it means sacrificing detail until the tab is clicked on?

Ted.