You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Design: Ability to move, copy, or link parts of books
Currently the book editor has a shelf/picker that facilitates copying content from one book to another. But the original design called for the ability to either move the content, copy it, or make a link such that two books share the same content. We orginally tried to determine likely scenarios and circumstances such that we could guess the most likely author intent and make move, copy, or link the default in that case. After much exploration, we decided that determining the best default and communicating that to the author so they could feel confident in predicting why things occurred was too difficult. So with one exception, we settled on asking the author every time. The exception is when moving content within a single book, which will always be a move. Because rearranging content from other books isn't that large a part of writing a textbook, we felt the additional ask was worth the simplification in the model.
Max worked on the wording of the choice, and we vetted with our group of teachers during a textbook sprint in South Africa. They felt that the options made sense and that they would use all three. Real testing with authors actively working on books may further refine the model in the future.
This should mostly be implemented in bookish, with all the saving and creating of new files occuring in github-bookeditor or atc and other book editor implementations. See also matching bookish issue: oerpub/bookish#13
Goals
Make moving content between books possible.
Make copying (or deriving copies) of content possible.
Make using existing content possible in multiple books.
Design: Ability to move, copy, or link parts of books
Currently the book editor has a shelf/picker that facilitates copying content from one book to another. But the original design called for the ability to either move the content, copy it, or make a link such that two books share the same content. We orginally tried to determine likely scenarios and circumstances such that we could guess the most likely author intent and make move, copy, or link the default in that case. After much exploration, we decided that determining the best default and communicating that to the author so they could feel confident in predicting why things occurred was too difficult. So with one exception, we settled on asking the author every time. The exception is when moving content within a single book, which will always be a move. Because rearranging content from other books isn't that large a part of writing a textbook, we felt the additional ask was worth the simplification in the model.
Max worked on the wording of the choice, and we vetted with our group of teachers during a textbook sprint in South Africa. They felt that the options made sense and that they would use all three. Real testing with authors actively working on books may further refine the model in the future.
This should mostly be implemented in bookish, with all the saving and creating of new files occuring in github-bookeditor or atc and other book editor implementations. See also matching bookish issue: oerpub/bookish#13
Goals
Mockup
w-editor-33.html: To see the action
Basic Design
Note that the mockup isn't exactly like the current editor, so details other than the copy dialog should be ignored.
Dragging content within a single book
Dragging content between books within the shelf/workspace or between the shelf and the TOC of an open book.
A. Choosing "Use this same module"
B. Choosing "Make a copy"
C. Choosing "Move module"
The text was updated successfully, but these errors were encountered: