Problem

Based on the ideas presented in hm://z6MkuBbsB1HbSNXLvJCRCrPhimY6g7tzhr4qvcYKPuSZzhno/projects/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.

TESTING

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.

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

here are some high level notes on the work I'm doing with the editor

Project Plan

Unified Editor Migration — Macro Plan

qa-review

Here, we should list all the noticeable issues we need to fix to ensure a smoother transition between the old and new document renderers. Please review the code in both the electron app and https://dailyplanet.io Desktop Done Out of Scope