- I question this idea, not with the interface, but yes with the filenames.
I like the apparent readability of fieldnames containing spaces but when writing wiki text code a space is a common delimiter, which means you need to be carful and look more closely to stop or fix errors in your coding.
- Personally I reserve this broader naming feature in fields for when it really is necessary, such as to store a tiddler name as a fieldname. But I have not done this yet.
- In the meantime I am sticking with “fieldname-with-space” as it is not only clear and easy to read but it allows parameters such as fieldname=fieldname-with-space
However when it comes to building forms and user interfaces we may want it to look differently, more like common writing here are three approaches; Lets say we has the field short-name
- When ever displaying this field provide the label “Short name:”
- Create a macro to generate “Short name:” from short-name
- Create Field definition tiddlers that include a caption field you retrieve when needed.
I have built field definition solutions multiple times and believe we should look at making fields a first class citizen of tiddlywiki like we do tags, tags have tag tiddlers that can/do contain more information about the tag. But field definitions could take this further specifying field captions, values (filter) and a lot more.
- Each field should also be given a field-type which defines how to handle the field in view, edit, selection, search, picker etc… because there are a lot less field-types than possible fields and it becomes reusable for any new field.
The thing is any multiword fieldname is lowercase and hyphenated as a rule with its caption replacing hyphen with space, and sentence case, keeps things easy, safe, reliable.