complete document use case for Word workflow
Status
Development done; Testing blocked by #1178
Context
We currently have two 'submission types' that users see:
- wholebook: this maps to NCBI 'wholebook' processing and only applies to content submitted to the XML and PDF conversion workflows
- individual chapters: this maps to NCBI 'Chapter' processing and applies to all three conversion workflows -- XML, PDF, Word
The main differences, from the users' perspective, include:
- The Book manager for chapter-processed books allows bulk upload of many files, each becoming a distinct component in a book that can be placed in divisions (front, body and parts, back) and published on a table of contents; whereas the Book manager for wholebooks has no concept distinct components or building a TOC.
- Each component in a chapter-processed books has it's own metadata and the book has metadata; whereas wholebooks only have book metadata that a user engages with.
- Each component in a chapter-processed could have different team members if necessary whereas there is only a 'book' team for wholebooks.
Proposal
This proposal updates the current submission types to allow for a 'complete document' processing use case for Word that:
- Sends a single document to Word conversion (chapter-processed) as currently developed
- Excludes current Word WF functionality that is not relevant:
- TOC building and their related settings
- book component metadata
- book component team
- Meets NCBI's use case of displaying just a document on the landing page
- Does not introduce a new submission type for submitters
Workflow steps
- The user completes an NCBI Word template which meets the following requirements:
- the filename is
toc.doc
ortoc.docx
- the value
toc
is provided in the "Indicate chapter or appendix" column
- the filename is
- The user creates a book with options "Word WF" and "Complete books and document" and completes the relevant book metadata and settings.
- The user uploads the source file on the "Files" tab and selects submit
- The BCMS sends the file to Word conversion (chapter ingest)
- NCBI returns a converted xml file which meets the following requirements:
- the file returned has filename
TOC.xml
- ID:
id=toc
- Content type:
content-type=toc
- the file returned has filename
Design
Create
To create a "complete doc: book users select "Word WF" and "Complete books and documents"
After selecting "next", users see the the current Word WF settings (as below) excluding the entire table of contents settings section.
Book manager
The book manager, shown below, will look like the UI currently used for XML/PDF wholebooks with the following the following amendments:
- the metadata button: opens a modal showing the chapter-processed books meta form
- the settings button: opens a modal showing a version the Word chapter-processed books setting form which excludes the entire table of contents settings section.
- a Word WF icon to the left of the book icon
- the same tabs as a chapter in the Word WF, excluding the "Manage team" and "Metadata" tab.
Original issue history, Oct 15, 2020
Hi @lathrops1
I've outlined the book-level processing use case in #214 (closed). That's all fine I think.
The issue is that the 'Alternative Book Structure' is what should, logically, be used for the "hybrid" or "one-page document" you mention in #63 (closed) which also applies to the Word workflow -- but our scoping with NCBI to date only considers chapter-level processed books in the Word workflow. This would incur further development on our end, and as I understand NCBI systems don't yet have a way to support this use case either.
We spoke about ways to try support this in the chapter-level scenario, by having just one book component, but I don't think that's workable because it affects more than just the TOC. Here are some problems I can think of, there are likely more:
- As explained in #214 (closed), the book component 'metadata' and 'manage team' are not relevant for this use case so that would be confusing for users I think.
- We would need an additional setting like "No TOC" so users don't see irrelevant settings such as all the TOC ordering features and the TOC Preview.
- We create and send a toc.xml file when chapters are published, but that's not needed here.
- We expect converted word files in a
<book-part-wrapper>
not a<book>
.
You mentioned that the only use case is the Pubmed central guide. Is that right, or it is all books in the collection NCBI Help Manual? Please can you discuss with your team and let me know how you'd like to proceed.
@John.kopanas and @yannis -- can I get your opinion please.
Coko Dev tasks
-
Update submission type name from the Whole book
toComplete books and documents
,and enable it for word workflow. -
In step 2 and book settings remove (configure form not to show) Table of contents
section -
Update book manager to support this workflow tabs -
Show chapter UI tabs as in design -
Show book metadata as in chapter processed
NCBI integration task
-
allow toc
as accepted content type (see #215 (comment 80123)) -
write content from XML file into the preview (i.e. at the moment, content parts are shown in the converted XML file but are not shown in the preview, see screenshot below and attached XML file). Confirmed done in comment 87844
QA Steps
- Follow workflow steps 2 and 3 above using the sample file toc.docx
- wait for file to get Previewing status