Workbook, Worksheet :↔: Calcbook, Calcsheet ?

[Lupp]

It’s a recurrent experience, that questions concerning Calc may be misunderstood due to an unclear terminology.
Some users don’t clearly distinguish between spreadsheets (one or more within the same component) and spreadsheet documents (2 of them e.g. between which they want to link or make any transfer).

Some being aware ot the problem then resort, if nothing else, to the terms worksheet and workbook. On the one hand this avoids the overlong “spreadsheet document”. On the other hand it introduces specific Excel-speak, and is sometimes actually related to the usage of alien formats or even VBA / VB…

Do you think, my suggestion to introduce the terms Calcsheet and Calcbook with the obvious meaning might be accepted by many in the long run?

(BTW: I wouldn’t explicitly object against workbook / worksheet if general acceptance is achievable. Easy disambiguation is necessary, however.)

[Lupp]

Should also mention that some (many) use Tab as a surrogate for spreadsheet trying to disambiguate - and that’s really bad.
Should also mention that English UI in LibO uses (e.g.) Documents meaning Text documents and similar or even worse as-if-synonym-monsters.
One thing :: One term, well considered, should generally be the concept.
UI, Help, API and its documentation, Dialogs, Object editors … urgently need a tidy-up of the terminology.

[ajlittoz]

Not a bad idea

[gabix]

Some users don’t clearly distinguish between spreadsheets and spreadsheet documents
…
my suggestion to introduce the terms Calcsheet and Calcbook

Do you really think that idiots can’t distinguish two terms will be able to distinguish two other (and new) terms? Then, you’re a dreamer. I think, this has never happened in the human history, let alone the history of computing.

P. S. The idea sounds good. Good for humans with functioning brains. I like the terms.

[erAck]

A sheet is a sheet, a calcbook is nothing. Note that the terms Workbook and Worksheet stem from Lotus-1-2-3 / Multiplan times where each sheet was stored as one file and a workbook somehow lumped them together. The term workbook alone is confusing enough, coming up with yet different …sheet and …book terms doesn’t help anything. Calcbook? That’s the book about Calc, isn’t it?

A spreadsheet document is a collection of one or more (spread)sheets stored in one file.

[Lupp]

A spreadsheet document is a collection of one or more (spread)sheets stored in one file

Well, I don’t think I needed this explained. However, do you think there is no problem at all concerning terminology? Will everybody be ready to use the long “spredsheet document” where appropriate? Is, on the other hand, “document” acceptable if used by the Template manager e.g. as a synonym for “text (Writer) document”? Is “Additional information” a sufficiently clear synonym for “Tag”? …
I wouldn’t claim to know the solution. This doesn’t mean there is no problem.

[gabix]

The problem is not about the terminology. It is about lusers that do not need any education, just quick answers.

[erAck]

@gabix, please, refrain from insulting users. Thanks.

@Lupp, I know I don’t need to explain to you but what I wrote was more general thoughts. I don’t think that coining an artificially madeup/merged/derivated term like Calcbook would solve misunderstandings. Rather consistently using exact terms will.

No, I don’t consider document acceptable as a synonym for text document if the context doesn’t indicate what type of document is meant (in the example of the drop down list in the template manager it’s bearable though because the other types are also listed); I don’t recall the reason why that was even changed (I think it was). The paths of UX and/or users requesting changes are sometimes a mystery to me…

Additional information as a synonym for Tag sounds somewhat funny to me, but not comprehensible (if the context is really tags like, well, tags…).

Computer terminology is hard for non-technical users, but avoiding technical terms at all cost may make it harder and worse.

[Lupp]

The .Tags remark is about the respective property of FormControls. There are similar cases. Something explicitly named in a technical context should also be addressed by this name in the UI. Nobody will be interested in using the “Additional information” without knowing that and how he can acces the value with user code, will he?
One thing - one term (name). However, this concept will not solve every problem…
Anyway we may try to help users to accept an unambiguous nomenclature. It should be as simple and handy then as reconcilable with technical requirements.