I sometimes miss comments in a thread that I'm involved in - this is probably one reason for TopicsThatDie
. Perhaps there could be a standard link in the
template that lists topics updated in the last N days where your name is mentioned, using an embedded search. This should really check for topics where you have commented in the last N days, but this may be hard to do without diving into RCS
. Mozilla users could perhaps check their current "conversations" in a MozillaSidebar
(which makes it quite easy to check TWiki - perhaps too easy!).
Most newsgroup reading tools have a "flag" feature that can be used for this, and the old DejaNews had a great option that would email you when a message was added to any of the threads you were tracking.
This sort of page tracking capability would also handle some of the requests for a more selective WebNotify
- ideally, you could either check your tracking page when you felt like it, or receive updates by email.
What do people think about this? Would it be useful, and if so would it be feasible?
- 12 Jan 2002
(Copied from the Support web)
This is another clear variation on the recurring better personalized changes tracking
theme. All suggestions neatly fit together should at least come up with one massive, detailed spec. WebChanges
simply tell you what topics have been changed within a certain period - if you don't remember every topic title that you've commented in, or just read and wanted to follow, in the last few days or weeks, you may never go back. They are also don't easily tell you if you've already read an indicated change, especially on a busy topic/web.
in place - some sort of easily set personal topic flag - you could zero in on pages, but then you'd still probably want to:
- be able to find the changes at a glance - easy for slower moving topics where comments are appended; harder if there have been many comments since last visit, and/or if changes were inserted somewhere in the existing text;
- see if inline links to related topics were also updated - you may have followed some of those links and decided whether or not to flag them (so that could get into another layer of personalization: changed inline-linked topic tracking...yikes), but it seems useful in any case.
And this ties quite closely into some sort of instant notification
- not always useful, but definitely so in cases where certain people want to know right away that an update has been made, in email back-and-forth discussion style - typically, an alert box or sound lets you know to check for changes.
These all have their own threads and related threads - now added below, scroll to .
- 12 Jan 2002
I am a database programmer, so, obviously, I am tempted to solve all problems using databases
. This one just cries for a database, IMO.
On each page, we can have special button "Watch this topic". It will add record (with keys: Web, Topicname, Username), and info what version it is. Then, we can have report of what watched topics changed (has higher version). And another button on watched topics: "Mark topic as read", to update watched version.
If we want to avoid databases, we can have for every user a companion topic Main.UsernameWatch, where TWiki will maintain all this info. Then, special report program can analyze this page, current topic's version, and report any changes.
I believe it is worth thinking about database, it can be used also in another issue: to save topic's metadata. For instance, if we have hundreds or thousands pages in a web, to run search using values from attached form (using only full text regexp serch) might be rather slow. But if form values are in database...
I know it raises TWiki requirements. For simple instalations, we may use simple storing techniques (CSV
flat files), using the same DBI calls as for bigger instalations.
- 13 Jan 2002
I think one solution to this is a completely different bulletin board system integrated into twiki. While the current method of editing pages is great for maintaining content, it really becomes confusing when a conversation is progressing. Currently the suggestions for managing this is to refactor when possible, but I think that is simply a workaround. I can see a bulletin board system which creates a new topic for each response. The response topics are then displayed on the original topic page in a threaded list. The downside of this is there would be a significant increase in the number of documents - but overall usability and management would be much improved.
If such a system was setup, you could then monitor changes to individual 'response topics' to improve conversation tracking. It also means the embeded list in the original topic could be formatted in various ways to improve usability. For example it could by default simply display with topic headings and author, but you could also then choose bookview and display the contents of each topic as well, or even display by date changed to see the latest responses at the top of the page.
I suppose in reality this could almost completely be done using currently available features (ie. formatted search, parent/child meta fields). The only thing I can think would need to be added would be a method of record the threading details (although this could be worked out by using the parent meta, but would probably be to slow).
- 13 Jan 2002
I agree. I think we should look for a perl-based BBS package and make them interoperable.
- 18 Jan 2002
I think this page has been diverted a bit - the actual requirement was simply for better tracking of existing conversations that you have contributed to, which TWiki is capable of doing with some extensions. Many threaded discussion systems don't have this feature, and in fact threading is an orthogonal requirement (although a nice thing to have). Adding a separate BBS subsystem would greatly change the character of TWiki, and IMO support for conversation tracking and/or threading should be done by extending TWiki rather than putting all discussions into a separate system.
Better support for discussions has been covered quite a lot on other Wikis, see MeatBall:WikiLog
- 19 Jan 2002
I had not actually meant to suggest putting in an external system into twiki (as might be concluded from my first line), but actually building the elements required as standard twiki features and methods.
- 20 Jan 2002
BBS integration sounds scary. Features, yeah. Anyhow, re way above comment, links collected S0 FAR in ChangesProject
, all somehow relating to the collab group/intranet version of this topic. (I think maybe big public T/Wikis would need separate BBS to avoid chaos; depends on audience, size...?)
- 23 Jan 2002
For what it's worth we have a very beta threaded message board running on EvEm
. A few gremlins to remove but basically it works. All 100% twiki (each posting is a new twiki topic). It's part of EvEm
plugin but we may move it to it's own and release if anyone is interested.
- 26 Jan 2002
There hasn't been any action on this very important (IMO) topic for a while so I thought I'd add a note simply to point to what I think is a pretty good ConversationTracking
mechanism in another wiki. I'm referring to the RegisterInterest option in the OrgPattern
wiki. When you click on this link at the bottom of every topic, you get the option to either receive email notifications of changes to that particular topic, or have changes appended to the end of a topic of your choosing. I like this mechanism because it:
- Allows tracking of individual topics.
- The option of appending change notifications to a topic offers the possibility of creating custom topics to track changes to groups of related topics.
- 17 Jul 2002
Could not perform search. Error was: Undefined subroutine &main:: called