Good Wiki Practices

, ,
#4

I don’t think there are absolutes or easy quick guides, it’s a matter of experience and discovering what you want out of it.

I agree :100:. As I mentioned above, these are opinionated rules that I have come up with after more than 4 years of using TW5 almost everyday at work and for personal use. I would like to evolve them into something we could use for new users because from my own user research, new users struggle a great deal when they’re asked to explore TW5’s capabilities. This holds back the platform. Some hand holding is essential and that’s what we should strive to offer. From those wiki practice essentials, a reasonably guided user should be able to take-off and discover other idiosyncratic possibilities that may suite their needs.

I think most of the “as much as possible” statements are questionable - tagging should be done intelligently - you don’t want a soup.

Agreed. Tagging should be done lightly BUT deliberately. Start with a broader, generic category tag (like Content), then progress to finer, more descriptive tags allows for more flexible indexing and resurfacing of old knowledge IMHO. I’m open to hear what others have to say in this regard.

…your idea of “right” may change as you progress.

Correct. I came up with these suggestions for good wiki practices purely out 4 years of trial and error. Many users simply do not have that much time to evolve their own practices. They have too much on their plate as it is. This is an attempt to bootstrap their wiki practice so they can just focus on their work.

#5

Thanks for pointing this out @twMat. I have clarified in the original post that I’m looking for fundamental practices (how to) rather than concepts (what is). Think of it as a userflow onboarding demonstrating fundamental features of TW5 and how to use them effectively without being too opinionated. Does that make sense?

#6

Yes @twMat. Every industry and domain has good practices that are recommended for all to follow. For example, in medicine and medical research in general, we have good clinical practices. In accounting, we have Generally Accepted Accounting Principles. So we should have Good Wiki Practices that are generally acceptable that can guide new users to maximize the utility of their wiki.

#7

Why do you recommend this as a good practice? I haven’t set this on any of my wikis and maybe just don’t know what I’m missing.

#8

If you link, those links will break when a title changes. So my rule has been to link as little as possible. If you install the relink plugin, then links become viable and useful. I would be more comfortable if relinking was part of the core, though.

Coming up with good titles is time-consuming. If you’re trying to take notes in a hurry, you will probably need to go back to your original titles many times. If you come up with an over-all strategy for how you will be using TW, it helps creating good titles the first time. Guess I should write-up the various strategies some time.

There are actually, AFAIK, only two officially recommended best practices:

Semantically meaningful units

The first rule of TiddlyWiki

I think every thing else will end up being dependent on use-case.

#9

There is a point that I don’t understand. You are talking about new user and you give these practices to them, but there are practices for advanced users. I think it can be counterproductive.

1 Like
#10

Yes, relinking should definitely be part of core I think. I admit, breaking links is unavoidable without it. This is why I prefer using tags more often than links because that affords you more flexibility.

#11

Yes, but if there is anything worth getting right the first time, it’s titles. Coming up with descriptive titles on the fly is not easy, but if you write small tiddlers, it’s easier than one might think.

1 Like
#12

How could I forget these two :sweat_smile: very important ones. Yes, IMO we need to expand on this list.

#13

That’s an interesting thought, but I find camelCase linking quite nice as a quick means of linking. I can’t see this becoming a generally accepted practice.

1 Like
#14

OK, it’s not the most critical practice, but it simplifies drag’n dropping tiddlers between wikis. It also lets you more easily get the tiddler to the top of viewport (if it is mid viewport) because you can click the title directly on the tiddler.

2 Likes
#15

Fair enough. I find it causes problems like “links inside links” or “links inside buttons” etc. And if you turn it off, then what were links are no long er such both for you and for some who imported your tiddler. Besides, for people who are not used to it, i.e the majority of the world, it is weird to ReadThis (“Can he not spell? Is it some unhinged autocorrect?”)

1 Like
#16

I’m focusing on new users yes, but we should probably expand further to include power user recommendations. For now, these are just notes from brainstorming.

1 Like
#17

You’re probably right yes. I wonder how many in this forum use camelCase linking. We should probably do a poll in the future.

#18

If you plan on having a lot of definitions + additional content, make heavy use of a summary field.

You can have the basic definition of a term in the field and use that field in lists or transclusions:

<dl>
<$list filter="[tag[vocab]]">
<dt>{{!!title}}</dt>
<dd>{{!!summary}} <$link>&hellip;</$link></dd>
</$list>
</dl>

Don't forget about the concept of [[vocabTerm]] ({{vocabTerm!!summary}}) it is very relevant to the current topic of discussion...

The text field can then be used to hold additional information, examples of the term in use, or any other related info: including transclusions of its own summary field and any other tiddlers.

1 Like
#19

If you’re trying to produce documents that will later be shared with others, either you will look like one of those crazed internet conspiracy theorists who coincidentally never learned to spell, or you will have to take the time to go through the doc and meticulously fix everything.

#20

Yes, it seemed like a really cool idea in 1996. But it turned out to cause more problems than it solved. With TW, it’s better to create the link in situ and then go back and populate the new tiddler later.

#21

Same for me @twMat. Good advice!

1 Like
#22
  1. Link to tabs plugin so that tabs are also links. Saves a lot of hunting around.
  2. Reduce the animation amount in the control panel. I am drastic and use 20 instead of 400. Probably others will want at least a little bit of animation.
  3. Reduce the wasted space above the sidebar
  4. Mileage may vary on this one: Learn some basic CSS rules, learn how to add a stylesheet, add one with your favorite styles, and then learn how to add a span class editortoolbar button so you can format text, add text boxes, indent, etc, with the click of a button.
  5. Practice clicking the advanced search button until it become second nature. Avoid learning to open the systems or shadows tab and scroll up and down.
2 Likes
#23

I will provide a few pointers to add to this discussion however others and myself have published a lot in a similar way in this forum and google groups (older content). To find you content search about the subject you are documenting and you will find content here far better than just what we all come up with in this thread.

In my view my settings below do form part of how I see Best Practice.

See the development of a standard edition for inspiration https://standard.tiddlyhost.com/

  • I Set the sidebar layout to Fluid story, fixed sidebar for desktop use.
  • I “second” the use of “Display tiddler titles as links”
  • I Always setup the contents tab
  • I always install an update to the new journal buttons to populate the journal-date field, for created date and title independence from the journal-date

and much much more posted in the forums.