Problem
Based on the ideas presented in New Publish mental model, Here's a first iteration moving towards this global view.
This project also aims to fix the "discard changes" modal issue some of us are having.
Solution
This solution does not change how users navigate between documents, but it changes what we render depending on the selected account's capabilities on any document.
Show the editor view if the selected account CAN EDIT
This means that we will show the current published document in the editor anytime the selected account can edit the rendered document. When the selected account CAN'T edit, we will show the editor too, but in "read-only" mode. this will prevent flickering or unnecessary jumps when the user changes the selected account.
What happens when a user is on an old version?
If the user navigate to an old version of the document, we can either prevent editing, or we can have a dialog appear the moment tries to edit the old version to make sure the user understand they are creating a "branch" or let the user actually create a new draft from it. the whole UX is TBD
What happens with Rebasing?
We technically are not handling rebases in the editor right now, but we need to do it if we do this change. what we need to do is:
keep track of the version we are basing our work when we load the draft.
if there's a new version found, we can update the editor content with it (TBD exactly how this will work)
If the user made changes and there's a new version found, we can try to actually check if the changes in the new version touch something the user has updated. if it does, we need to show a message to "rebase" (how exacly will be is TBD). If the changes in the new version DO NOT touch what was changed, we should be able to update the editor content with the new changes (how exacly will be is TBD).
Publish still happens PER-DOCUMENT, but we will show the Publish button ONLY when there are changes made to the published version
We will have the same behavior we have on drafts that we only create drafts when there are any changes in the document, but because we are showing the editor all the time, we will only show the publish/settings buttons when there are any changes.
Make the Editor view look EXACTLY the same as the published version
This is very important to make sure users have the best WYSIWYG experience. This is tricky because we need to make two DOM structures look the same. it will take time and a lot of detailed care.
Related: Improve styling in the editor view
Nice to have: Store current scroll/cursor position in drafts, so when users navigate back to documents they will land EXACTLY where they were before
This is not only important when the user was actually editing a document, but when the user navigates back to one.
User Flows
Create a Document
click on new document
card appears at the bottom of the current document opened with the name focused
user edits new document name and press enter
user navigates to empty draft
user press publish, publish dialog appears
finally user press publish and the document gets published. Nothing changes in the app. the user is still seeing the current document published and have the ability to edit anything (editor is loaded)
Edit a Document
User enters a document that can edit
user can select and start typing.
when the app detects a change in the document, then it will show the publish and preview button and also auto-saves any change.
when user finish editing and want to publish, continue with the normal publish workflow
Navigate to a document that the user have a draft for it (no more "resume editing" button)
user clicks a link that goes to the latest version of a document that has a draft for
we load the editor with the user's draft.
the user can read and also edit the current document.
Navigate to a old version of a document that the user can edit
here I believe I think we need to not let the user edit right away. I think the moment the user starts editing, we need to warn the user that it will create a "branch" or something and let the user choose what they want to do.
Scope
Hopefully 1-2 week.
I have doubts Claude can do the UI changes to make both publication and editor look the same by itself, so I will need to invest a lot of time there.
The hardest part here is handling with versions and rebasing; specially rebasing
Rabbit Holes
should we do the same with comments? (let users edit right away). I think we don't! comments should stay the same as now.
No Gos
rebase: I think support rebase can be complex. but achievable. I prefer to tackle rebase on a separate project.
Designs
Edit/publish/discard changes.
We need to contemplate the scenario where users are working on the document but don't want to publish right aways. That is why it is important that user do not feel trap during the flow, feeling their force to publish all the time.
Solution:
Put the first option exit editing when pressing the 3 dots and then document options
Send a asynchronous user test for feedback where users will download the app and start creating content.
Versions
When returning to a document, users are frequently caught in a versioning bug that disrupts the experience.
Solution
The expected behaviour is straightforward: always show the latest version of the document, but surface a non-intrusive notification when changes were made by someone else — giving the user awareness without blocking their flow.
Editor for Publications - Project Breakdown
Project Plan
Do you like what you are reading?. Subscribe to receive updates.
Unsubscribe anytime