Latest Content Display
Document Actions
At the last meeting we discussed the idea of a new display of "Latest Content". The two places we currently display this information are 1) a non-linked location (/weeklySubmits/ -- somebody let me know if that's too secret to post here) that Charlet uses to see the past week's additions/revisions, and 2) the right-hand sidebar of /content/, where the last 5 content objects to have been published or revised are displayed (and linked).
The purpose of a new display would be to:
- Let Charlet and Chuck see what the latest content is, especially so they can spot new authors and any incorrect uses they are making of the site (either in terms of the content of their material or things like mark-up)
- Let all users see what the latest content is beyond the 5 links we currently provide. A new display could potentially provide a listing going back to the earliest module publication/revision dates. Motives could range from simple curiosity to ego-browsing.
- Provide, if possible, a single place that both of these above uses could take place, instead of duplicating efforts.
After discussion with Chuck, a few issues came up regarding what exactly we would want to display:
- latest published vs. latest revision
- list each revision vs. list only latest revision
- list content going back a week vs. month vs. forever
I also told him that I had envisioned this listing looking similar to the "Popular Content" listings, and linking in the same way (from the sidebar and a new "By ..." box in /content/). We came to the conclusion that we can address the first issue (latest published vs. latest revision) by having two listings, similar to the the "Popular Content"'s listings of last week vs. all time.
I don't think we came up with any agreement on how to deal with the issue of listing each revision vs. listing only latest revision (though I think we agreed that publication could be considered the "1st revision"). My personal preference is just to include the latest revision (with a link to the "Version History" section of the content_info page), but that wouldn't give a complete view of the history of all content revision. It's possible to have 3 top-level listings ("newly published," "latest revised (latest revision)," and "latest revised (all revisions)"), but they would need better titles.
I believe we also agreed that it shouldn't be a problem to list "latestness" going all the way back in time. IIRC, the idea of going back for a limited time, e.g. a week, was meant to reflect what Charlet does with weeklySubmits, but the problems with this are a) it doesn't allow fulfillment of goal 2 above; b) as discussed below, we will probably have to have separate listings for Charlet vs. regular users anyway, and c) it will look bad if, for a particular week, we have very little activity.
When looking at ways in mock-ups (see below) to incorporate all the information that Charlet needs from weeklySubmits (which includes module/course ID, number of submits that week, title, author ID(s), ID of submitting maintainer, full time stamp, and submission message(s)) into a general listing for public view, I found myself wanting to make compromises that both a) make things more time-consuming for Charlet and b) provide extraneous information for the general user that made the display seem rather cumbersome.
One of these things was linking to the module so that Charlet could hover over the link to find the module ID and follow the link to find the authors. Charlet needs to know who the authors are upfront, however, whereas this probably isn't much of a concern for general users. Another idea was to show the submitter name and comment, while allowing the user to toggle this information on and off with radio buttons in order not to clog the display. However, just the radio buttons themselves might be considered an unnecessary distraction, when something similar like a link to the "Version History" section of content_info might be enough for users who really want to see that info.
Considering that Charlet doesn't want anything taken away from weeklySubmits, and actually wants one more thing (e-mail addresses of authors, to see where entirely new content is coming from), I think it will be best to scrap goal 3 above and have two separate listings, one for Charlet (and Chuck if he finds it easier) (i.e. weeklySubmitts-cum-emails), and another for general users who want to browse by latest more casually.
Mock-ups
Note 1: These are better viewed in Firefox. Note 2: Browse the different links in the table, and also use the radio buttons to see some differnet effects. Remember that most of these different features/layouts/effects can be mixed and matched (i.e. we don't have to go w/ a specific mock-up).
- Browse by Recently Revised (last revision only) 1
- Browse by Recently Revised (last revision only, kinda) 2
- Browse by Recently Revised (last revision only) 3
- Browse by Recently Revised (all revisions) 1
- Browse by Recently Revised (all revisions) 2
- Browse by Newly Published 1
- Browse by Newly Published 2
Personally, my most preferred of these are 3 and 7, though the toggling of submission information is mostly a remnant of trying to incorporate info that Charlet would need, so it may be wasteful to include it at all anymore.
Re: Latest Content Display
Re: Re: Latest Content Display
The benefit of the radio buttons is that they open all those rows at once, but it's hard for me to imagine that somebody would really want to see submission details for all modules/courses and not just a particular few. If there is a need for this case, though, perhaps the radio buttons could be relocated to the bottom.
As for how far back to go, my personal vote is not to limit the listing to a week or so, but to catalog the whole repository. The problem with limiting the listing to a week is that it, if there is a week with very little activity, then the new listing doesn't buy us much more than the 5 links in the sidebar currently in /content/. One of my pet peeves with those 5 links is that I will sometimes see something of interest there, then return later only to find that it's been bumped down into oblivion by newer content, and my only way to find it again is to manually type in module numbers until I find it again (if I don't remember what it was called). Letting users go back for as long as Connexions has been around (or if there are historical problems, then at least up to some cut-off date) would eliminate that problem.
Regarding weeklySubmits, would it be at all useful for you to have features such as linking the title to the module, or having those user IDs link to their profiles, or do you just prefer plain ol' text?
Re: Latest Content Display
The full history that shows up in view 2 is neat! It may very well be TMI, though, as has been pointed out. I'd say, just list a given module multiple times if it's been revised more than once within the display window, and forget about deciding how much to display at once -- just display the last 50 or 100 or something, with chunking so people can dig backwards if they really want to.
So, my vote: include the parenthetical "new!"/"history" links from 1/3/4, the single-revision history data with master toggle from 1, and the timestamp info from 6. I don't think we need a separate "newly published" page -- maybe just a "show only new submissions" filter on the recently-revised page. Yes, I know that's more recoding than simply doing hidden content -- it would require a fresh load of data. But I think it would be the most flexible option. I'd really hate to see a huge proliferation of this kind of page; it makes it hard to go through and make global changes when necessary.
Re: Re: Latest Content Display
I agree that the full history report is probably TMI, especially if that would be essentially duplicated in the "new!"/"history" links to the "Version History" section of the content_info page.
My personal opinion is that chunking should be of the same number as the Popularity listing, which I believe is 25 per page, just for consistency's sake. Or if you think that's too little, then raise the chunking count on the Popularity listing to match whatever it would be for Latest.
Is it fair to say that your concern regarding having a "newly published" listing in addition to a "recently revised" one stems more from the fear of creating a new page template than whether or not that information is actually presented? If that's the case, couldn't we just make it appear to be two (or three) separate "pages", as we do with now with the Popularity listings (where the "last week" one is really just created by a value passed into the URL of the same page template, from what I can tell)?
I would still like to see a "newly published" listing, especially since I just realized that a listing that only included the latest of revision or publication to a module/course would eventually hide the publication event of most modules/courses (unless they were never revised after initial publication). So that the "new!" marker wouldn't cut it in terms of showing the pace of that event (publication), unless the listing included all events. The problem I foresee with listing all a module's/course's events would be that some modules/courses would be listed multiple times in a row (see #5 and #6) which a) is kinda ugly, and b) could lead to somebody spamming the system just to have their course/module show up all over that Latest listing (by revising over and over and over). Of course, a "latest of revision/publication" could also be an invitation to such a spammer, but at least their content would only show up once at the top.
Re: Latest Content Display
1. Latest NEW or REV for each module only;
2. Latest NEW for each module only;
3. All events for each module (NEW or REV)
As long as we provide at least a link from each listing to the full revision history for that object, then I could live without #3. However, I think #2 is important: for instance you might want to look at the rate at which new content is being added to the repository. The rate of all NEW or REV events doesn't really tell you much about how the project is (or isn't) growing. So I think both #1 and #2 are the bare minimum of data selections.
I think it is essential to make a clear visual difference between new publications and revisions. Perhaps the "New!" keyword is adequate. While we know that version 1.1 is a new publication, I don't think this is adequate for the general user.
For showing and hiding the publication details, I agree that a link toggle is better than radio buttons. If we have to decide between a global toggle and toggles for each row, I prefer show/hide toggles for individual rows. I suspect I'll want to scan the listings quickly (when I don't want details showing) and then show the details without having to travel to the top or bottom of the list to do so. However, even better is both global and by-row.
As for which details to show, I prefer three states:
1. details hidden;
2. details for this revision shown;
3. full revision history shown.
However, this creates an interface problem: how well do three-way toggles work? I wouldn't mind it, but I'm probably weird. Perhaps this is desirable but not feasible interface-wise. #1 and #2 are the bare minimum. Perhaps the way to handle detail state #3 is just to link to the module's metadata page (as Max's versions 1, 3, and 4 do).
I don't think the list should be limited chronologically. It should be a browse listing in reverse chronological order, with the most recent X events showing (where X might be 20 or 25 or 50 or something). Those who don't want to go back more than X events don't have to, and no harm's done. But those who do (those, say, who want to look at the publication history at particular times in the project history) could.
I think object ID and list of authors are important bits of information, but I'm not sure how to work them in. They would be especially important, I think, to Charlet and me.
What info should be included in the non-details display? Object title, version, and event date are obvious. Should we try to work in object ID or author info here?
Re: Re: Latest Content Display
I definitely agree with your 2nd paragraph, and I don't think I had thought much about this problem up till now in terms of measuring pace, which I agree, could be lost without listing NEW by itself (though that would probably be even better shown if we chunked by month or something (not to mention graphs)).
I also agree that 1.1 isn't enough for general users (or me for that matter) who might not know if that's later than 0.0 or what. Also, I've seem some modules published at version 2.0, if I'm not mistaken.
Another vote for link toggles, but I think what you're wanting is not a 3-way toggle, but rather 3 separate toggles, which I think is too much. I think it's pretty much agreed that the "new!"/"latest" links are the best way to eliminate one of those toggles, and also that a "show/hide" link is the preferred method (as opposed to radio buttons) for showing or hiding the last revisions of all 25 at once, but I don't think there's an agreed best way to toggle individual module's/course's submission info yet.
As for object IDs and author listings, I was actually going to try to incorporate authors into one of the mock-ups until I quickly remembered that some modules have several authors, which I think would just cram things. I don't think object IDs are that important to the general user (we don't include them in browse_popularity, browse_titles, or browse_keywords, for example) and can still be gleaned by hovering over the link to the module/course. I think my best response to your need for object ID and author info is to say that you should then use weeklySubmits along w/ Charlet (unless you need something that's more like "foreverSubmits").
-Kyle
I'm assuming that I've confused you by what I meant w/ latest revisions vs. all revisions. By latest revisions, I meant listing the last revision to a module or course, no matter when it occured (a week ago, a year ago, whatever). By all revisions, I meant that the listing would include each instance of a revision (i.e. you would see version 1.4 of a module, then 1.3 later down in the listing, 1.2 perhaps as its next neighbor, etc.).
The above two listings would create entirely different HTML outputs ("all revisions" would be several times longer than "last revision only"), so I would prefer to use a link instead of a select menu, since I think that select menus more imply a change to the page you're currently on rather than a change to a new page.
But let me know whether I've completely misunderstood your suggestion.