Tags:
create new tag
view all tags

Tagging Related Topics

Feature: Some way to easily collect topic titles to create a Related topics: list.

Scenario: You browse Codev, looking for references to a particular subject, using WebSearch, WebIndex, reading topics and following WikiWord links in topic text and in existing Related topic: lists. You want to collect these quickly in a new topic. You have to cut and paste. This doesn't sound too difficult now, but it can get confusing doing it manually if you're reading, jumping between multiple topics, keeping more and more windows open as you follow inline links...

-- MikeMannix - 04 Oct 2001

For MasterRefactor, I started a temporary manual system of TaggingRelatedTopics. It goes with an arbitrary division of TWiki functions in four sections, each with a topic:

These are placed as %INCLUDE{"%BASEWEB%.ChangesThread"}% at the top of topics. If they must, topics can fit in more than one Thread. Feel free to add topics!

-- MikeMannix - 01 Nov 2001

Mike,

With your Master Refactor project, it's not surprising you'd run into this problem. The first thought that comes to my mind (and which I've used) is to edit each such page and put a special phrase or tag on it that you can search for.

You could be verbose, like MikeMannixBookmarkForRefactoringRelatedTopics (with spaces or without), or cryptic, like MMBFRRT. You can even put that in HTML comment delimiters (<!-- and -->) to make it invisible, but still search for it -- for example you might enter: <Please do not delete -- MMBFRRT>. Just to confirm that this really works, I've hidden such a marker here, it is MMBFRRT with R1 concatenated to it -- I don't show it concatenated here so you can search for it and confirm that this works.

Anyway, I assume you thought of something like that but were looking for a better idea -- editing each found page would be cumbersome. I guess I can dream of an extra button labeled something like "Add Marker Tag" with a place to enter your suggested marker (like MMBFRRT), in a hidden string like suggested above -- <Please do not delete -- MMBFRRT>. This button could appear on the view page so that you don't have to go through a edit - preview - save cycle to mark a page, but, it might have an "Are you sure" type dialog.

Then, I suppose we'd need to think about a way to remove markers -- a program that searched the database for every instance of a marker and removed it.

I guess this would inherently support a hierarchical approach. By that I mean that you could use a lot of different markers all of which started with MMB (MikeMannixBookmark) and then had different extensions for different purposes. As long as the "master delete program" searched for and deleted only whole words, we would not accidentally delete the wrong markers. What I'm trying to say is, imagine that you have marked pages with MMB, MMBA, MMBAB, and MMBB. If you asked for MMBA to be deleted, but the search also found partial words, it would delete MMBA (as desired) and MMBAB (not desired). Of course, there may be times when you want to use a wild card character to delete all of your markers.

And, we'd have to think about what happens when Max Milquetoast joins TWiki and starts using the MMB marker. Maybe everyone who is a registered user should get a special numeric code that is used for his markers, plus any custom suffix he adds.

Hmm, does that make it meta data? I'm not sure -- more for me to learn. And, if it is meta data, does that imply we should handle it in some special way that I have not described here. What is meta data -- I guess it's data that's stored in the .txt file between HTML comment markers (like <!-- TWiki Meta Data-->), and, because of the way TWiki handles meta data, it is not displayed in the "normal" TEXTAREA. I guess it could certainly be handled as meta data.

Anyway, not sure how far you were looking to carry this, and, of course, there may be other better ideas -- this is just one quick thought off the top of my head.

PS: I guess I should have created a topic and moved this stuff there, but I'm not sure what we want to call it -- some possibilities:

  • Tagging Related Topics
  • Automatic Topic Tagging
  • Automatic Bookmarks
  • ???

-- RandyKramer - 05 Oct 2001

Yeah, this should move - it's already bigger than a lot separate topics! I think what triggered this tag idea, and the BrainstormScratchPad itself, was enabling HierarchicalNavigation by parent topic just a couple of days ago, on this music timeline TWiki I'm working on. In [More], I used the set parent feature, and have the search to generate child links in the view template. (There's a comment in the template saying hierarch nav is expensive - but it works well so far!)

Also, the Wiki:CategoryWiki for c2 Wiki is a cool feature that originally hooked me into Wiki.

  • "Press the title to see a list of pages that fit into this category. (Pressing the title of any page invokes a search for all references to the page name through the entire database.)"

I'll play with it more with META parent on my site. I didn't check, but I imagine it also marks the topic as changed. Figuring out ways to log and indicate topic changes seems to be a central issue, touching on a lot of areas, from trivial changes in DevOpinionPoll, to over-and-underkill in WordDiffs as markers for tracking topic changes, etc. Lots of roads seem to lead there! A separate topic...

If HierarchicalNavigation with the META parent data works, maybe this topic should be:

-- MikeMannix - 05 Oct 2001

Yeah, this is getting long. I'll leave it to you to pick a new topic name and move it. wink

I've never played with the parent feature -- it sounds helpful but has the limitation that only one parent can be assigned (AFAIK).

The categories in Ward's wiki is basically where the idea for markers originated.

-- RandyKramer - 06 Oct 2001

Sounds like it would be enough to have a button on every page that said 'bookmark this page', i.e. adds the page's WikiWord to a specified page (unique to the user), or perhaps a selectable page. This would be like the 'knapsack' used in some Unix shells (stuff some files in your knapsack, move elsewhere and dump them out - actually the Adventure shell smile ), or the Copy and Paste of files in Windows Explorer. I think a single 'knapsack' page would be enough for most people.

Alternatively, you can use software such as ClipMate, which remembers all text copied using your OS's copy-and-paste mechanism. Not as neat as a TWiki solution, but it is very useful and does avoid creeping featurism.

A minor point - please don't plan on putting any non-HTML/XHTML markup in angle brackets, as this messes up certain browsers (e.g. Mozilla, see MozillaNOPIssues). It will also cause problems with ConvertToXHTML10.

-- RichardDonkin - 07 Oct 2001

Richard,

Good point about the angle brackets -- I changed my text above to refer to HTML comment markers (<!-- and -->) which I presume will not cause a problem for Mozilla.

I like the "bookmark this page" button that adds the bookmark to a designated page, I would like the ability to choose different pages for that purpose.

I'll have to look up ClipMate -- that might be what I've been looking for (if it works in Linux).

-- RandyKramer - 07 Oct 2001

If you use KDE on Linux, have a look at Klipper, it's similar to ClipMate, and sits on the KDE tray (or whatever it's called!)

-- RichardDonkin - 15 Nov 2001

Thanks! I use Klipper in KDE -- it's nice, but not everything I'd hoped for. Some problems off the top of my head (why I'm writing this here, I don't know -- should send it to the KDE people -- I'll have to do that):

  • (one is a "generic" problem with the default Cut and Paste method in Linux) -- every time I select some new text, it "scrolls" the selections in Klipper -- too often, by the time I'm ready to paste, the selection I wanted to paste is either out of the buffer altogether, or not at the top of the stack, so I have to switch to klipper, reselect the selection I want to paste, and then paste. Three things would help:

    • A means to (optionally) require that I do something besides select text to have it placed in the Klipper buffer.
    • Keyboard shortcuts automatically assigned to the different "buffers" in Klipper, so I could select (and paste) the text from different buffers with a single keyboard shortcut (<alt><1>, 2, 3, ..., for example)
    • The ability (or a different utility) to assign arbitrary strings of text to a keyboard shortcut to be entered into any application. I made a halfhearted effort to see if I could do this with the built in Linux "utilities" (keymodmap or some such things), but could not find a way to assign strings (multiple characters) to a single keystroke (clearly, I could assign "commands" (in one of the KDE utilities) or alternate keystrokes (in what ever it was, the keymod thingie), but not strings to be entered into applications.

Anyway, thanks, didn't mean to make this sound like a rant. Guess I'll go to KDE, try to check their bug database, see if these things are already entered, and if not add them. (Unless they're already implemented in KDE 2.2.) At least I've already got the text of my request(s) written out.

I did think about trying to do this with dcop, but, at the time, I couldn't learn enough about dcop to see how to do this (or even be sure it could be done), and, I think dcop would limit the use to just kde applications (or other applications written to utilize dcop.

-- RandyKramer - 15 Nov 2001

UPDATE re Klipper: I did send these comments off in an email to the Klipper maintainer (developer? -- don't have his name at my fingertips) and got back a nice reply indicating he would attempt some of these things. I've seen a blurb in the KDE 3.0 Beta release notices that indicates perhaps one or more of these suggestions have been implemented. Now I have to wait until I install KDE 3 and see what is there wink

-- RandyKramer - 06 Jan 2002


UPDATE:

The specific motivation behind TaggingRelatedTopics was my effort in MasterRefactor to classify most of the 800 (not 900+) Codev topics in a few categories, as a step toward some sort of organizing and editing.

  1. I started with a simple manual cut'n'paste approach, partly described above, with a special list topic per category, where I'd paste relevant topic titles. That wasn't too bad, since there were only four-five categories.
  2. Now, with 20-30 topics per, enough to reasonably validate the original categories, I've switched to using a WebForm category - ProjectGroup - a checkbox field (some topics fit in multiple cats) for five areas, plus catch-all (to make it fully usable on all Codev pages). I'm now tagging the manually grouped pages. People have started to categorize existing and new pages. And the endless SEARCH formatting options make the results easy to use for anything.

In this case, an all-round good solution - provided the ProjectGroups are generally accepted, therefore, universally useful. the form field isn't obtrusive (in most personal TaggingRelatedTopics situations, though, a form or even just a new field would probably be an imposition on others, and relatively a lot of work to start up).

So that's the update. Still, the core functionality remains valuable and unsolved. The two direct suggestions above are basically:

  • manual - mark pages with a unique, searchable tag
  • bookmark feature - a built-in mechanism

The latter, as in, Sounds like it would be enough to have a button on every page that said 'bookmark this page', i.e. adds the page's WikiWord to a specified page (unique to the user), or perhaps a selectable page. RichardDonkin - 07 Oct 2001, sounds great. Seems simple enough for single-person use, maybe it could get complicated/costly if lots of people used it simultaneously...not likely, though.

A big plus of the bookmark idea is that it wouldn't do what both the personal category WebForm and manual tagging methods would: mark the bookmarked topic as modified. (My earlier cut'n't paste approach avoided that also. Tagging the few hundred remaining Codev pages will create that as a one-time annoyance/problem.)

Seems like sorting out WebChanges - how to clearly separate your basic edited page modification, from other "technical" mods - touches many related, core collab areas - basic ChangesProject and CollaborationProject stuff. Pages ineffectively marked as updated undermine a major area of TWiki functionality: being able to keep up with changes.

BTW: ClipMate - probably for Win only - is one of those GREAT tools. There are lots of clipboard enhancers, but ClipMate stands out. Kind of like TWiki - easy to use and great as is, but also with TONS of all-good features and settings that you can use to keep adding to its powers if/when you get around to them!

-- MikeMannix - 31 Dec 2001

Most content from here moved to all-new AlternativeTWikiTargets page... But some of it will be editing back!

Edit | Attach | Watch | Print version | History: r28 < r27 < r26 < r25 < r24 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r28 - 2004-03-10 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.