← Back to branch summary

~ubuntu-branches/ubuntu/karmic/zim/karmic

« back to all changes in this revision

Viewing changes to share/zim/doc/Zim/Usage/strategies.txt

  • Committer: Bazaar Package Importer
  • Author(s): Raphael Hertzog
  • Date: 2007-12-01 20:50:34 UTC
  • mfrom: (1.1.9 upstream)
  • Revision ID: james.westby@ubuntu.com-20071201205034-bpweecgj7wtt9ze2
Tags: 0.23-1
http://bugs.debian.org/452999
http://bugs.debian.org/446870
* New upstream version. Closes: #452999
  * Now handles symlinks properly. Closes: #446870
* Add myself to Uploaders.
* Updated dependencies to match new requirements: libfile-basedir-perl 
  (>= 0.03), libfile-desktopentry-perl (>= 0.04)
* Add Vcs-Svn and Vcs-Browser fields to document the SVN repository now used
  to co-maintain the package.
* Add an Homepage field pointing to the upstream website.
* Moved libmodule-build-perl to Build-Depends-Indep as it's needed for the
  clean target.
* Fix some bad permissions detected by lintian.
* Updated debian/menu file to conform to the new menu policy and added an
  icon.

Show diffs side-by-side

added added

removed removed

Lines of Context:
share/zim/doc/Zim/Usage/strategies.txt
 
1
====== Strategies ======
 
2
 
 
3
This page tries to gather some usage strategies for zim. Not every style of working works for everybody so these are just suggestions, not enforced use cases or something like that.
 
4
 
 
5
=== Bullet lists ===
 
6
The way to keep a TODO list tor something similar is to make a bullet lists with the items you need to to. You can add deadlines in the list but do not add descriptions of the tasks. Keep each item on one line, so you have a good overview over the list. To add descriptions etc. just make the name of the task a link. On the corresponding page you can keep notes on the details of the task, links to files etc.
 
7
 
 
8
=== Bold and italic ===
 
9
We implemented the styles "bold" and "italic" purely because most users expect them in a rich text editor. But the problem with these elements is that they only define markup information but no structure information. Therefor it might have been better to implement an "emphasis" and "strong emphasis" style instead. When structuring your text it is best to use italic for emphasis to stress words in a sentence, while using bold for strong emphasis, for example for keywords that should be indexed by a search engine.
 
10
 
 
11
Underline is traditionally used on typewriters where italic is not available to put emphasis. In personal note underline is often used for stressing the most important sentences, for this it would be better to have a "highlight" or "mark" function. Also underline is often used for titles of books etc. These are also set in italic in printed bibliographies. Of course in a wiki titles should be links :)
 
12
 
 
13
=== Logbook ===
 
14
**Zim** has a way to map dates to pages. This can be used through the calendar dialog, or by using the "//Go//->//Today//" menu item. This feature is //not// very well suited to keep your agenda together - you will probably need another kind of program for that - but it can be used very effectively when keeping a logbook. For example when working on a large project just write each day a few lines about what you did, which problems you encountered and how you solved them. Add relevant files, images or graphs using drag and drop. 
 
15
 
 
16
===== Maintaining overview =====
 
17
One of the main problems with large data sets is maintaining overview. 
 
18
 
 
19
=== Searching ===
 
20
The brute-force method to solve this is a powerful search function. The problem with searching, however, is that although potentially you can find everything, in reality you will only find the things you are looking for. This sounds like a good thing, but when you think about it it doesn't create overview. A search function is like a flashlight in a forest at night - you only see the things you point it at, but you'll never see the thing just outside the light circle.
 
21
 
 
22
=== Structuring ===
 
23
So we need to look for a more structured way of keeping overview. The best way to do this is by dividing your data into eatable chunks. This means having a hierarchical structure with pages instead of one long list. If the page list get so long you can't visually scan it at once you need to structure it in smaller categories; in practice it works best when you have between 5 and 25 items per category, but your mileage may vary.
 
24
 
 
25
The same goes for pages. Especially when brainstorming one tends to get long pages with unrelated or half-related thoughts, this needs to be avoided. Try to keep pages strongly topicalized and try to keep them shorter then about 3 times the length that fits on the screen. One can not visually scan text while scrolling so the first few paragraphs should clearly state the topic of the page.
 
26
 
 
27
=== Tags ===
 
28
FIXME
 
29
 
 
30
=== Archiving ===
 
31
FIXME
 
32
 
 
33
Refactoring - refactoring is the key to come from a collection of random thoughts to a structured text
 
34
 
 
35
Multiple ways of using namespaces .. categories .. collection managers .. topics
 
36
 
 
37
outlining - dub zim as a multi-page outliner