Genii Weblog

All in a name: What should we call a "Lotus Documents" document?

Wed 18 Apr 2007, 12:19 PM



by Ben Langhinrichs
As I work more and more extensively with the productivity editors in Notes/Domino 8 (mostly for our OpenSesame tools), a linguistic obstacle keeps hampering my documentation and internal discussions.  It appears that the productivity editors have been renamed as Lotus Documents, Lotus Presentations and Lotus Spreadsheets, although inside Notes 8, they will still just appear as Documents, Presentations and Spreadsheets.  But what should we call the Documents document to prevent confusion with a Notes document?  If you saw a method entitled CopyDocument, would you assume a Notes document or a Lotus Documents document?  What about an EmbedSpreadsheetInDocument?

It is possible we could refer to these as ODF Documents, but nowhere is ODF mentioned in the Notes 8 product, in the productivity editor Help or anywhere else I can find.  In fact, OpenDocument format is not mentioned either.  Of course, there are lots of hits for "Open Document", but they all point back to the discussion at hand, as they have nothing to do with Lotus Documents.

Perhaps we should refer to these as Office Documents, but that might confuse people who are used to Microsoft Office being referred to as just "Office".  (It is nice being the dominant leader, isn't it?)  Similarly, we could use "WP Document", but only if we use it in menus and such, as otherwise it will still sound like something external, maybe even a "WordPerfect Document" or "WordPro Document", either of which would cause more confusion.

We can hardly say a "Lotus Document", as that could be used interchangeably with "Notes document".  I guess we could say "Productivity Editor Document", or just "Productivity Document", but that sounds pretty awkward, and will certainly blow up those method names.  Imagine EmbedProductivitySpreadsheetInProductivityDocument.  Ick!

So, what should we call these?  If we come up with a good enough name, I can pound on Mary Beth Raven and others and see if we can get them to use it, but it has to be reasonably short and reasonably clear.  Any ideas?

Copyright © 2007 Genii Software Ltd.

What has been said:


580.1. Richard Schwartz (04/18/2007 09:03 PM)

IBM Lotus Standards Compliant Productivity Editor Bit Streams Notes 8 Edition Express


580.2. Peter Herrmann (04/18/2007 10:00 PM)

Documents, Spreadsheets, Presentations, Notes Dcouments.


580.3. Ian Randall (04/19/2007 03:25 AM)

I prefer the term "Open Document".


580.4. Ben Langhinrichs (04/19/2007 03:44 AM)

Richard - I womder what the limit of a method name is.

Peter - But what of all the existing methods such as GetDocumentByID? It is going to be much harder to now make Document as a simple name stand for something else.

Ian - I like "Open Document", but am a little unsure since there is already an @Command([OpenDocument]...). Still, this would be usable for CopyOpenDocument or EmbedSpreadsheetInOpenDocument, so I may need to go with this, and it would follow along on the OpenDocument Format name for those "in the know".


580.5. Ben Langhinrichs (04/19/2007 06:16 AM)

In the public beta forum, Daniel Lehtihet suggested the term PEDocuments, at least for methods and such. That would work reasonably well with P.E. Documents in documentation, and methods such as EmbedSpreadsheetInPEDocument or possibly even EmbedPESpreadsheetInPEDocument. In other words, we could use P.E. Spreadsheets to distinguish between those and external spreadsheets (e.g., Excel), but P.E. Documents would be pretty easily distinguished from either Notes documents or just Documents. The term Productivity Editors is used fairly commonly in Notes/Domino 8, as well as in the Workplace editors, so it would make some sense. What do people think?


580.6. Richard Schwartz (04/19/2007 07:30 AM)

I think that Mike Midas needs to investigate the Case of the Overcrowded Namespace.

Apart from that, I think PEDocuments has a potential drawback. We've seen IBM's penchant for changing names of technologies enough times to wonder whether it's a good idea to base method names on something that a year from now could be banned from our vocabulary.


580.7. Ben Langhinrichs (04/19/2007 07:41 AM)

Richard - That is an excellent point, but I don't quite know what to do about it. We could go back to ODFDocument, since they can't easily change that fact about it, but then it would help if IBM agreed to mention ODF somewhere, or we are just avoiding possible issues by embracing definite ones.


580.8. Richard Schwartz (04/19/2007 08:03 AM)

If you call them IBMDocuments, you could at least be pretty sure that the prefix won't be obsolete next year. But you couldn't be sure that there won't also be some other completely different document technology from IBM.

You can't win.


580.9. Chr K (19.04.2007 10:23)

The OOo File - New menu is using the terms Text Document, Spreadsheet and Presentation (for a text document, a spreadsheet document and a presentation document respectively). I can't se what's wrong with this terminology.

- Why mess tings up by calling a text document something ambigious?


580.10. Milos Lapis (04/19/2007 12:35 PM)

I would like to have much more shorten names. Prefer what is important and effective for daily work and not cosmetics side efects.

So:

ODFd

ODFs

ODFp


580.11. Richard Schwartz (04/19/2007 01:01 PM)

Wow?! Is it really just a text document? I confess to not having tried the PE's yet, but I have to believe that it supports graphics.


580.12. Ben Langhinrihs (04/19/2007 01:12 PM)

Of course it is more than text. It is a rich document content much like rich text, with some stronger features and some weaker, but all saved in XML rather than CD records. That ought to count for something. They just call it "Text Document" to differentiate it (and confuse mere mortals, if possible).


580.13. Ben Langhinrichs (04/19/2007 01:16 PM)

Milos - While I understand what you mean, it would seem somewhat ironic to take the incredibly verbose XML format and refer to it in cryptic abbreviations. Yes, ODFs may seem clear to you, but embedodfsinodfd, or even EmbedODFsInODFd is going to seriously hamper somebody trying to read the code.


580.14. Milos Lapis (19.04.2007 15:22)

Ben, you are right :=) It was just a try to highlight that a final decision should respect the fact that it is not only an academic discussion. We will need to live with it.

As a maximum I vote for:

ODFdocument (the best ODFdoc), ODFsheet (maybe ODFspreadsheet), ODFpresentation (the problem -> too long) [ODFpre] ??