You mean, other than having a textual record that hyperlinks?
I keep a wiki for each of my projects I work on, as well as a general wiki for just putting in my own journaling into (I used to break apart general - personal and general - work, but since I often have things cross over between the two, I now just have them together in one "general" wiki).
Let's look at the project wiki usage...
Advantages of using the wiki: I can quickly hyperlink items (wiki base feature), I can easily search my wiki for what I'm interested in (most wikis), I have full control over what happens to my entries (any personal documents).
Any time I get a customer call or email about a software app/system I support, I journal it.
Any time I spot a bug, I journal it.
Any time I see something unusual with one of my apps or systems, I journal it.
Whenever I need to leave myself a note to the future, I journal it.
Whenever I do work on that app or system, I journal it.
For instance: Customer call/email me, asking to change her user profile and requesting a new feature for the app.
At the time I do the work, I use the wiki entry to help track the work I've done, what I am doing, what I should next do (all very useful when you get interrupted mutliple times per day), and related important bits of info. So its a scratchpad of doing, to do, and done.
- If I don't have a "day" entry open, I create it. (Trivial to do in many wiki apps)
- I create a bullet entry that "customer" has contacted me (phone/email), and summarize what it is she wants. Note that I "wikiword" the customer. If I need to make notes about the customer herself, I can. Common examples: Customer is listed in the email system as "Marideth Smith", but is in the app as "Juli Smith" because she prefers "Juli". I'll just open up her wiki page, and include that. Also, include her actual email address, which would be "firstname.lastname@example.org" (not a real person nor address--- so no worries except for spammers) rather then a more standard named government email account. Telephone number will be tossed in, if she contacted me by telephone, so I can always find it quickly to call her back (rather then look it up in one of the many telephone apps or web sites we use at work).
- Journal what I actually do to resolve her issue.
- Journal her change request, so it will be easy to find when I next assemble my "Users Requests To Consider".
The long term value is the record of what was done, for whom, and why. The journaling will be the important things in the future. If I have to come back to this information, it will be important to know what it was she actually told me, and what I did to resolve it. If "Juli" complains that she is messed up and can't do her work to her new boss after sending me a "change me" request, I've got a record of what she said to me at the time. If it was email, I'll then know what date it was on she sent it to, under what name, and what the actual email is I'm hunting to show she actually asked to have her boss cut off from the system, and that it was okayed by her boss's boss, who also decided to cut her out at that time. When it's been many months (or even years) since you worked something or made a change, it is often important to have these details if you get called back to it for some reason--- or to review a collection of what work is common (so you might break that out for someone to take over as part of a standard "account manager" position for a group of apps, for instance).
By being able to track which user asked for what feature, (or what do I noticed that something could be improved if I made a change,) I know who to talk to get more info on what they might have meant (or what I was thinking when I jotted down the idea if I made it myself--- but was too busy with other things to go worry about right then).
We have a lot of different systems to do all this for us where I work. And every few years, management chunks the current stuff, and has us start using new apps and systems, either due to political decisions (ie, someone in the WH or HQ wants everyone to use the new stuff), price point (vendor is just charging too much for licenses), technology goes obsolete (software is too old to run on current hardware, hardware is too old to get support for, etc). By having my OWN actual record, I don't lose my older bits of work.
For work issues, once I'm done working the item, I can then turn around and quickly enter that info into our various work systems--- as I copy out the bits from the wiki entry into our required work capture systems.Wikis are great for textual information, particular dense or free form. You can link between items easily, and search the information. Another example: I can record which people at our help desk is having difficulty understanding when they should pass on a customer onto me to handle them, and go down and train them so they can handle the customers that call in to them more easily.
The trick with this is that the more info you put into your entries, the more you can get back later, when you've forgotten the details. The problem is--- what should go in? Only you can know how much detail you need. And a lot of that will be based on your past experiences. It can be trivial and tedious to put in such details as I've described above, but when 3 levels of your managers above you are down in your office, wanting to know why "this" happened, and what your part was or was not, having such information available is invaluable.
Another example: I give a monthly training class on one of my systems. I've got it's project wiki set up so I create a new entry for each class. I list the date, time, and place for the class (and update it as I get bounced between rooms or have to shorten it if a big boss decides they need some of my scheduled time). I use that entry to track who has reserved a spot in the room (which I use at class time as a roster to make sure those who reserved a spot has a place in my class, since seating is limited). I also note who actually shows up (I maintain a sign in sheet as is the custom of our work culture, and I copy that info over after class), and who cancels. I also have entries in that work journal about things like: Parking being rough for a particular class (so if there is a trend over several classes due to building over-booking, I'll know to show up even earlier than usual, and can warn the students), tracking questions asked by students (if there is a trend, then I probably need to review related bits of the course and what I'm actually saying/presenting to make it clearer), and any other thoughts or observations from the class. Again, with that information recorded (put down), I can review it in the future for anything I might need (like, number of students that need a repeat of the course).
Now, you could journal non-work things, if you like. I actually track a lot of things other than work in them. Personal observations, family matters, what work I've had done to my car, etc etc etc. Some of that is just because I have my journal there, open and ready for work journaling. Some of it is actually important stuff I want to track for my own reasons. Some of it is trivial, but I still like to have it written down to look back at later for my own amusements.
When journaling something, it is important to put it somewhere you'd expect to look for it in the future (is this in my general wiki or project X wiki?), and to capture enough details to be useful in the future without wasting your entire day with recording minutia that will never be needed. (So again, experience will help on how much and what to put down.)
Anything else you are curious about?