This is a help article about Kanbani – a freeware task planner for Android
Most of Kanbani configuration is hierarchical:
Per-board and Per-list configuration is bundled with synchronization data meaning that teams can specify preferred configuration for their board(s) without disturbing (and relying on) each particular user’s normal preferences. After the initial sync, users may change them without affecting other users (for example, different sort modes can perfectly co-exist).
By default (Newly created on bottom), Kanbani does not specifically order the cards in your lists. When you create a card, it’s placed in the end of the list, but you can also reorder it into another position in this or a different list (or board).
The Newly created on top sort order is the same but newly created cards are put into the beginning of the list.
Other modes enable “forced sort order”. You cannot change order of cards in the list as it is maintained by Kanbani.
This configuration can be set per-board and per-list. For example, some boards may hold a list of tasks to be done in no specific order (where Due Date is just a relaxed indication of its priority) and so the default manual sorting is sufficient. However, a particular list (e.g. “Tasks for today”) may require strict automatic order by Due Date. Yet other boards (team boards) will benefit from sorting by time changed so that you cannot miss recently updated cards (even if they would be normally at the end of the list).
Card’s extended Description may be used for different purposes (which may even vary per team, board or list). For example, if it maintains a journal (e.g. things done in scope of that card’s task on specific dates and times) then new entries would be normally appended to the end – in this case you would configure Description to display lines from the end to see latest activities right in the list view.
You will also want to enable Join Mode so that if last few lines are short Kanbani can fold them and fill the remaining space with more lines. The list becomes slightly harder to read but now it packs more information.
Other boards, such as Kanbani’s “Welcome Board”, use cards as if they were sections in a text document, with Titles being the headings and Descriptions – the actual text. In this case Join Mode is disabled while the number of lines is set to a high value so that the user can “read the document” without entering each card’s form to view the text.
To avoid clutter in card lists, snippets ignore Rich Description formatting, displaying text as authored.
This preference is useful when a board is shared among several devices (such as in a team). It sets the default value for the Related Name input of the card’s form. It’s also used in some internal fields for synchronization and logging purposes (e.g. when you create a card current Author value is stored in its CreatingUser field).
Note: changing this value does not affect existing cards – their Related Name remains as it was; it is not renamed automatically. This is because Kanbani does not know if those cards are truly yours.
This number makes a counter displayed on a tab “highlighted” (red) whenever that list receives this number of non-archived cards or more.
This is useful for methodologies that recommend limiting the number of tasks in a certain state (e.g. to avoid overcapacity in lists equivalent to “Doing”/“In progress”). Kanbani does not enforce this limit, it’s only advisory.
This is a destructive preference. It specifies when cards become automatically “archived”.
As the time goes by, your “Done” list will accumulate a good number of cards that you no longer care about. Instead of remembering to archive them by hand, you may set this preference so that when a list receives new card(s) and its length (excluding archived cards) exceeds this number – old cards are archived without your intervention.
Archived cards are never permanently deleted automatically so you can undo this operation later.
For the purpose of this option:
Generally, Kanbani offers two-level “Recycle Bin” or “Trash” (like on desktops): non-archived cards in the “Done” list (for quick access to recently completed tasks) and archived cards (hidden from normal views, candidates for permanent deletion).
Allows seeing all cards without explicitly assigned Color as if the configured color was indeed assigned to them.
For example, as this preference is hierarchical, you can use “red” for cards under work-related boards without picking it for every card manually.
This is an advanced preference controlling the interaction with the card’s menu. Lower values allow invoking menu command faster by holding the finger to call the menu and releasing it over a button.
See this section for details.