LO, especially Writer and Impress, have two options of prefixing list items / paragraphs with extra content: 1. Bullets - The same content for all items 2. Numbering - Different content for every item, automatic choice (by progression) I suggest a third kind of content prefixing: 3. Category indication - Fixed set of possible content, manual choice. (although, to be honest, it's more of a generalization of bullets.) Examples of use cases ----------------------- 1. Aligned list with "star"/"favorite" indication: You have a list of items (or paragraphs) which you want to all start at the same vertical position; and you want to mark some of them using, say, a star, before their start: Tomatoes Zucchini * Strawberries Cucumbers 2. Checklist: Every item is either unchecked or checked. The two states may be represented by the relevant Unicode characters. (Note the intention is not to use this as an interactive web form, where you would want actual controls.) An extension may be items that are somehow "off the list" and don't have a checkbox, but still need the same indentation; or items for which the checkbox is grayed-out, or has a question mark etc. 3. Group assignments: Suppose I have groups of people or items that I've defined, and have given them symbols, On a list of people, I want to be able to easily play with which group the person is part of, without having to manually keep inserting one of the four special characters all the time. 4. More generally - utilizing multi-characters sets within the Unicode standard: * Currency: ₤, ₹, €, $ * Circled letters: Ⓐ, Ⓑ, Ⓒ, Ⓓ etc. * Circled number characters: ①, ②, ③, ④, ⑤ etc. - but not in rising sequence * White circle, black disc: ○, ● * Checked box / unchecked box, empty box: ☒, ☑, ☐ * Checked (with no box) / unchecked: ✓, ✕ * Ditto but bold: ✔, ✖ * Female, male: ♀, ♂ * Sunny, cloudy: ☀, ☁ * Card suites: ♠, ♣, ♥, ♦ * Hollow card suites: ♡,♢,♤,♧ etc. How this would be implemented UI-wise ------------------------------------- One can think of category indicators as a generalization of bullets. * The rendered categorized list will have each item rendered just like a bulleted item, except that each item may have a different bullet from the set. * Double-clicking the category indicator switches it to the next category by some cyclic order. * If the user has indicated that "none" is a possible category, than that's part of the cycle as well (but the space is conserved, i.e. the paragraph is not un-indented). * The context menu may perhaps contain the set items, for a selection other than through multiple double-clicks. On the Bullets & Numbering dialog, the minimum necessary change to the dialog is a more complex custom-bullet dialog, where instead of a single character one can add to a set of characters. But one might want to separate the single-bullet controls from the category-set controls. Also, we might want to add a pane with some example category set lists, like we have for bulleted and for numbered lists. What people do today ----------------------- At the moment, people "implement" category indicators in one of two ways I can think of: 1. Using tabs: Each paragraph starts with a manually-inserted category indicator, then a tab. All paragraphs on the list have a relatively short tab stop set, so that the category indicator is not too far from the text. Alternative is tab+indicator+tab, and a centered tab stop - for the case of category indicators of non-uniform width. 2. Using tables: A narrow column for the indicators, then a column with the actual content. Note that these methods could also have been used to "implement" bulleted or numbered lists.
Likely not possible without changing the ODF spec. Regina, what do you think? The checkbox example is not far-fetched. Btw, Bullets are called now unordered lists and Numbers ordered lists (since it applies to letters as well).
(In reply to Heiko Tietze from comment #1) > Likely not possible without changing the ODF spec. Oh, yes, certainly. I should have mentioned that. Definitely asking for this to be directly representable in ODF files and part of the spec.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Eyal Rozenberg from comment #0) > Examples of use cases > ----------------------- > > 1. Aligned list with "star"/"favorite" indication: You have a list of items > (or paragraphs) which you want to all start at the same vertical position; > and you want to mark some of them using, say, a star, before their start: > > Tomatoes > Zucchini > * Strawberries > Cucumbers This definitely *logically* does not belong to any kind of "list indicator" concept, and the star is not a metadata (like position in the list), but a *data* of a corresponding entry; and for such data, the correct tool is *table*. > 2. Checklist: Every item is either unchecked or checked. The two states may > be represented by the relevant Unicode characters. (Note the intention is > not to use this as an interactive web form, where you would want actual > controls.) An extension may be items that are somehow "off the list" and > don't have a checkbox, but still need the same indentation; or items for > which the checkbox is grayed-out, or has a question mark etc. The same. > 3. Group assignments: Suppose I have groups of people or items that I've > defined, and have given them symbols, On a list of people, I want to be able > to easily play with which group the person is part of, without having to > manually keep inserting one of the four special characters all the time. The same. So IMO: mainly WF. The "What people do today" is *the* correct thing to do.
(In reply to Mike Kaganski from comment #4) By your logic, a table is the "right tool" for almost any list. Unordered list? You can either have the bullet on, or off if you type backspace at the beginning of the paragraph. That's essentially data. So you should have a two-column table, with one column being either empty or with a bullet. Numbered list? You can restart the numbering at every paragraph, and change the starting number, if you like, so - essentially you're storing a number for every value. So you should have a two-column table, with an index column. > So IMO: mainly WF. The "What people do today" is *the* correct thing to do. Degenerate tables which wrap paragraphs in rows, take up the entire text width, continue over multiple pages, have no borders, and are not perceived by the reader as tables - are generally a fallback alternative to, or an emulation of, a more refined mechanism. Come on, you should be excited about this! After four decades of GUI word processors, there aren't many opportunities to introduce fundamental features. This is one of those! This feature has the potential to be one of the staple text formatting features that any self-respecting office suite has. It will be a "D'oh, how did we not have this before?" kind of an obvious feature.
(In reply to Eyal Rozenberg from comment #5) > By your logic, a table is the "right tool" for almost any list. Unordered > list? You can either have the bullet on, or off if you type backspace at the > beginning of the paragraph. That's essentially data. So you should have a > two-column table, with one column being either empty or with a bullet. > Numbered list? You can restart the numbering at every paragraph, and change > the starting number, if you like, so - essentially you're storing a number > for every value. So you should have a two-column table, with an index column. Oh, you show a logical fallacy: you substitute my "this is a data, so should not be treated as metadata" with your "you can do that in a different way" ;) No, for any list, the fact that it is a list item (top-level element of a list) *automatically* produces the respective decoration. This can not be true for your example.
(In reply to Mike Kaganski from comment #6) > (In reply to Eyal Rozenberg from comment #5) > Oh, you show a logical fallacy: you substitute my "this is a data, so should > not be treated as metadata" with your "you can do that in a different way" ;) I argue that list indicator in unordered and in numbered lists also carry data. Typically, they carry less data - since people don't restart their lists very often - but they do carry it. > No, for any list, the fact that it is a list item (top-level element of a > list) *automatically* produces the respective decoration. This can not be > true for your example. Actually, that's not true. It produces the desired decoration usually, but not always: Not when you want to skip the bullet, or restart numbering. I'm suggesting a kind of list in which one injects data more frequently. Also, in at least one of my use cases, the appropriate decoration is produced by default: When you have a task list with not-yet-done and done (or unchecked and checked) - you start by writing the list of not-yet-done items, then over time, perhaps with more edits to the document, you'll mark more items as done. Your concern actually raises the possibility of offering a bit of GUI - when switching to a new paragraph, you might get a small tooltip-like window open up, making it convenient for you to change the category. As an optional feature of course. If I had a bit more time I'd try to sketch something for this with pen-pot.
(In reply to Eyal Rozenberg from comment #7) > (In reply to Mike Kaganski from comment #6) > > (In reply to Eyal Rozenberg from comment #5) > > Oh, you show a logical fallacy: you substitute my "this is a data, so should > > not be treated as metadata" with your "you can do that in a different way" ;) > > I argue that list indicator in unordered and in numbered lists also carry > data. Typically, they carry less data - since people don't restart their > lists very often - but they do carry it. Please let's be strict with definitions. We are not talking about the reader. We are talking about creator here. The reader might get the data printed, and have no clue which document markup was used for the printout, so the reader's perspective here is unimportant (and if you include those who parse documents to extract data into "reader" category, my following argumentation applies to them, too). 1. Restarting a list is not adding information. It is actually starting a new list, which happens to have the same formatting. Restarting is an artifact of an implementation, and brings no information itself. So no, this mention doesn't prove anything. 2. Later, you discuss unnumbered items. This example also is incorrect. Unfortunately, *in the UI* this is called as "unnumbered item", creating a false impression that this is *a list item* with some special properties. But this naming is completely misguiding. I advice you to create such a list (very simple, have a couple of "numbered" paragraphs, and one "unnumbered"), save to FODT, and inspect the XML. You will see, that there are only "numbered" (=normal) items in the list; but each *item* can contain *arbitrary number* of paragraphs. So basically, on UI level, it could be *more correct* (but unwanted by vast majority of users) to add selections of paragraphs as list items, so that users would understand the difference between paragraphs and list items. In a way, list item is like table cell: it can hold more that just a single paragraph. So - again, the argument is incorrect, since *every* list item is handles absolutely identically, which is "number its first line, and format the rest according to the formatting rules". 3. So the numbers/bullets get generated based on the fact that the *list* is rendered. Other than defining the list and its content, the user does not need to do anything to define the decorations. And levels are also part of this picture, with sub-items being *part* of higher-level items. Again, use FODT to inspect what ODF thinks about the respective document structure (and what I think about the mental model that should be used for this, incidentally). One defines a list item *content*, and then all decorations are applied automatically, uniformly. Now look at "Done" mark. To make this mark, you can't rely on the *list* properties. You only can define a specific item properties, which is the very difference between the "data" the you (as the writer) define for the specific element, vs. the formatting applied to a list structure. This has no place in the list ideology. It could be possibly implemented as a paragraph style, if one is allergic to tables (many people are, because they were taught that using tables for formatting is EVIL).
I am afraid that I can't express myself clearly. So let me try in this way, too. A list (in a text document) is *a hierarchy of data* (i.e., a number of elements, which can contain sub-elements), with applied rules how to represent that data. The content of the elements themselves does *not* affect how the rules work. This is the most important thing that I try to say; and as soon as you suggest to make the rules consider anything else than the items' hierarchy, this breaks the idea put into the list feature.
(In reply to Mike Kaganski from comment #9) > I am afraid that I can't express myself clearly. I can follow you. => WF