...
Section | ||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Suppose you need to list some contact information about your team mates: Tina, Mike, and John. You create a new page in Confluence and put the currently relevant information into a table like this:
Next you realize that the skype ID and mobile phone number are also relevant. There for you add new columns to your table.
Next you learn that this information is relevant to freelancers that are also members of your team. So you decide to state the full phone number and the full name.
Now you can add more information for a team member by adding additional columns and more team members by adding additional lines to this table. This is quick and easy and is often fair enough. But processing this information or showing information for different contexts in different views is not easy to do. |
...
Section | ||
---|---|---|
| ||
There are usually some use cases that you encounter dealing with information for some of which the tabular form put some limitations. Here is just a short collection of a few:
|
...
Section | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
So what are the options to handle these requirements with the tabular approach and what is an alternative? The alternative is single sourcing: Instead of adding lines to a table we see each line as an entity for which we create a new page. Information form these pages, single sources of truth for a particular information like the connection information for a particular team member, can be accessed and compiled in different contexts. Each representation for such a context we call view. So in different contexts you may have different views on the same information.
Let's have a look at how we can engage the additional requirements we have listed above!
|
Section | ||
---|---|---|
| ||
Having each information on a separate page makes it referencable. Think of having a separate page for each line of the original table. You can add any number of views on this information and some information will be collected automatically. We have discussed briefly the many advantages to have a single source for each piece of information. On the other hand compiling a table with a couple of columns is very easy and can be conducted in an ad-hoc manner. Single sourcing requires some form of planning as to decide how such a page should look like by defining a blueprint (instead of . This is in contrast to instantly guessing the relevant columns )of a table. For many people it is often more cumbersome to create a new page than to add a new line to an existing table. So – as often – there is no right or wrong. |
...