Basic Text Editor

[bmann]

Include basic text editing functionality in Drive.

Edit Plaintext, Markdown, YAML, HTML, JSON, etc.

Anything more basic should be an external "app".

Goal of including this is to enable various scenarios which already have permission. For instance -- you now have live editing of HTML files in a public folder.

• open source
• integrates nicely with Elm / Drive

[bmann]

This looks good: https://github.com/mweiss/elm-rte-toolkit

[matheus23]

If the goal is this:

Edit Plaintext, Markdown, YAML, HTML, JSON, etc.

I don't think we'd need a rich-text editor.

RTEs in the browser are extremely complex (I've been reworking the home-grown RTE for https://zenkit.com).
I don't want to be the pessimistic kind of guy. I'm just agreeing strongly with this sentiment:

Anything more basic should be an external "app".

So, I guess there are two separate goals here:

1. A plaintext editor integrated into drive
2. Apps for rich text editing. So maybe a 'Codemirror' app or a 'Prosemirror' app.

What is the main goal in this issue?

[bmann]

Of course, "anything more basic" should actually be "anything more complex".

Yes, basic text editor should not be an RTE -- "plain text" editing of text files is the goal for this.

This basic capability added to Drive means that a user can edit a CSS file, YAML file, Markdown doc and any plain text format.

I shared the Elm thing as I was doing research.

Picking an existing editor and integrating it / loading the scripts only for editing is likely what we want to do.

CodeMirror https://codemirror.net is interesting because it has a companion ProseMirror RTE that could go in a full app.

I don't have any opinion on CM itself in terms of suitability.

Small code base, well maintained, easy to integrate, works on mobile, open source are key criteria I can think of.

[matheus23]

Of course, "anything more basic" should actually be "anything more complex".

Ha. Actually didn't notice :D I auto-corrected that somehow.

The RTE

Small code base, well maintained, easy to integrate, works on mobile, open source are key criteria I can think of.

Nice! That's useful.
I'd propose some more criteria:

• Does the editor support IMEs?
• Does the editor support mixed RTL and LTR text, as in Arabic mixed with English?

And maybe a non-goal:

• Extensibility: We don't necessarily need to be able to add custom things to inline into the text editor

The plain-text editor

Possible criteria:

• Syntax highlighting
• Non-monospace editing (?)
• Syntax errors & error highlighting (?)

I've heard good things about codemirror. It's codebase also seems fairly small.
There's also ace, but it's not exactly a small code base.

[bmann]

I think only syntax highlighting from the plain text list feels attractive — and even there it’s a nice to have.

Shall we try CodeMirror for now or do you want to do research some others?

Small code base: thinking about this some more — as long as it is well maintained and can easily be plugged in, this matters less. We can package / version this and host it once on IPFS / Fission’s infrastructure.

[matheus23]

I'm happy to go with codemirror.

I'd like to create some designs first, so I can better think through the UI flows/UX. That's what I'll focus on now. This elm codebase seems quite approachable to me (that's a huge bonus of elm :) )

[bmann]

Great. Yes, getting you into this codebase is another goal ;)

[matheus23]

I've started some design: https://www.figma.com/proto/wqJjBsfSAIWzwPsLdMkl1t/Fission-Drive?node-id=7%3A83&scaling=min-zoom
This could be how the very first version of a plaintext editor could look like. It's rough by design (no pun intended), so I can get early feedback. Let me know.

Also cc @icidasset, as you've been the creative director so far, I think?

EDIT: Implementation is not really blocked on your review, so no need to hurry. I just like having any design before working on code. Changing the design in response to feedback should be fine.

[icidasset]

@matheus23 Not sure I'd give myself that title, but yes 😅

I like the concept, putting the editor there seems like a good idea 👍
What would mode do exactly? Just highlighting, or more?

I would like to see:

• Not a white background
• Save button on the right
• Subtle cancel button
• (extra) spaces/tabs indicators (eg. like in editors, dot for space, » for tab)

Regarding libraries, there's https://package.elm-lang.org/packages/jxxcarlson/elm-editor/latest/ as well. Don't have a huge preference for either Elm or JS for this, but since we would need to interact quite a bit with the editor, Elm might be easier? What do you think?

PS. There's also this article on my reading list regarding editors: https://medium.com/content-uneditable/contenteditable-the-good-the-bad-and-the-ugly-261a38555e9c Still need to read this 👀

[bmann]

Do we want to use this as a viewer as well as an editor for plain text?

So, in a directory, loading text files in the right hand pane? And a switch to edit? Future feature, but may impact design - a clear “Editing” mode.

When editing, may want to show a “dirty” indicator, that the file hasn’t been saved.

[icidasset]

Do we want to use this as a viewer as well as an editor for plain text?

Yes. Otherwise we'd need to implement a viewer as well.

And a switch to edit?

I'd think so. Easy enough to add a edit action with the current content-viewing setup.
I imagine the "dirty" indicator would be lighting up the "save" button (eg. light grey -> purple)

[matheus23]

What would mode do exactly? Just highlighting, or more?

Forgot to remove that one. It was just for testing how adding some info add the footer would look like. It's not a feature planned for the first iteration, though. (Basically, there was not tangible plan for that :) )

Not a white background

Agree. I wanted to increase the contrast, but I think I'll just go with the grey-purple-ish background.

Save button on the right

Agree.

Subtle cancel button

Hm. What would it do? There's already a 'Close' button on the top-right.
Is the idea that 'Close' will save, but 'Cancel' doesn't?

(extra) spaces/tabs indicators (eg. like in editors, dot for space, » for tab)

Hm. That's interesting. I'll have a look at how editors would/could support that.

Don't have a huge preference for either Elm or JS for this, but since we would need to interact quite a bit with the editor, Elm might be easier?

This is an important issue to gain clarity of: What interaction are we planning to have with the editor? I think there's potential for a super-simple interface between the editor and the rest. String values down and string callbacks up from the editor.
If that's the case, then I'd suggest using codemirror with webcomponents.
If not, I'd recommend going with an elm solution and understanding what interactions we plan to do with the editor (maybe only roughly).

This has given me plenty enough ideas and improvements. I'll get going on a little more design and start implementation soon.

[icidasset]

Subtle cancel button
Hm. What would it do? There's already a 'Close' button on the top-right.
Is the idea that 'Close' will save, but 'Cancel' doesn't?

My reasoning here is that the functionality of the close button doesn't change depending on the contents of the "sidebar". So it always hides/closes the entire side. Cancel on the other hand, would go back to the default "non-editor view" without saving changes. Does that make sense? 🤔

What interaction are we planning to have with the editor?

Yeah, thinking more about this, let's just pick whatever works best.

[bmann]

Agree with @icidasset on close / cancel. Slowly coming up with a UI pattern for the preview pane!

And context for "Basic" is that we're not going to do previews or any other interactions other than open/close/edit/save.

Maybe we'll implement creating new text files too. That's it ;)

[matheus23]

I'm not entirely sold on the idea of having two modes, Editing and viewing. I wanted to compare both approaches, so I created two prototypes:

• Prototype with an editing and viewing mode
• Prototype with a combined viewing and editing mode

The instructional text in the lower left is obviously not meant to be part of the app.

I find the combined mode preferable, as it's simpler. The two-mode editor also doesn't have much visual indication for which mode you're in. That problem can be solved, but it's just more work to implement and additional hoops for the user, potentially.

There's a little fine-tuning left: What does 'Close' do when there's unsaved changes. Should it save? At the moment I'm leaning towards 'no'.
If that's the case, should there be a 'Cancel' button in the combined mode version? It seems redundant, as 'Close' does the same thing.

Anyway, I've definitely designed enough to start coding the viewer (for real this time! 😄 ).

[icidasset]

Nice job on the prototypes @matheus23 👏

---

Yeah sorry, should've been more clear, the non-editor view I had in mind was this:

We would change the primary action for text files to "EDIT" and move download to secondary-actions menu next to it.

---

But I guess seeing the text directly is more useful, so I would opt for the combined view as well @matheus23 👍

How I see it working:

• Selecting the file shows the editor
• When you make a change it shows "cancel" and "save" buttons
• Cancel would discard all changes, but not close the sidebar
• In addition to these buttons there should be a "secondary actions menu" button (three vertical dots on screen above ☝️ )
• Clicking "close", or any other action that moves away from editing this file, would need to show a modal asking the user if they want to discard or save the changes (open to other suggestions)

[bmann]

Yeah, we definitely want to see the text in Preview mode view. Yes @matheus23 I agree that a "modeless" view is better, I was using the word mode when I meant view.

And yes, "CANCEL" goes back to view mode is better than "CANCEL" closing the pane.

@icidasset a future feature might just be auto-saving like Discourse does, with like ~webpage.html or something, but that's going to need more design and research.

[matheus23]

Can we close this now that #65 is merged? I'll go ahead for now.