Substance Composer Alpha 1 is ready

[Michael Aufreiter]

Very happy to be able to demo the new Substance Composer as an alpha version.

http://substance.io/composer-alpha1/

Feedback is welcome! :)

Cheers,

Team Substance

[Jeremy Taylor]

Great job Team Substance, it definitely looks very nice!

Is the document history functionality implemented in the data model but just not exposed as a user interface yet?

[Oliver Buchtala]

Hey Jeremy,

that's right. The Versioning/Operation stuff is already in place. However, we have not developed a good UI for that yet.
Also, currently we do not serialize the index (i.e., the history graph) when saving the document. I.e., currently the history is bound to the current session.

Beside of creating a good UI, there are some things to be discussed about document histories.

- Currently every change, e.g., typing a single character, creates something like a version, i.e. a node in the history graph.
  This would be too detailed for a UI.
  Maybe we would add a concept to 'tag' the current version. Something like bundling session changes into a tagged composite change.
  Then, how should Undo at the boundary of that behave?
- When passing a document to another person the document history should not be available - could be embarrassing ;)
  However, if you send it to yourself you would like to have it...

I don't have a clear vision yet....

Would be great to hear what you would expect from such an UI.

Cheers,
Oliver

--
You received this message because you are subscribed to the Google Groups "Substance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to substance_+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

-- 
Oliver Buchtala
Substance Software GmbH
Harrachstrasse 28
4020 Linz

Email: oli...@substance.io
Tel: +43 680 2365909
Firmensitz: Linz
Firmenbuchgericht: Landesgericht Linz
Firmenbuchnummer: FN408728X

[Randall Leeds]

Super cool.

I noticed it requires safari or chrome, though. What are the particular issues blocking Firefox support?

--

[Oliver Buchtala]

Hey,

We currently are (ab)using contenteditable only for cursor rendering and for handling multi-character input as `-a.
For that there are some bad hacks using DOM mutation observers necessary.
And on that evil way I lost Firefox.

However that is not for ever... I just need to do proper keyboard handling instead of those DOM mutation bla..
As soon as we are heading towards a web-component that is one of the first things I will address.

Cheers,
Oliver

[Florian Dorfbauer]

Michael: pretty neat.

however, I was a little bit confused and had some real issues while typing (cursor position)

http://www.snapbugz.com/result/substance.io/927e6ea6-9099-46d2-84ed-6ad0bbf89317

best, flo

[Oliver Buchtala]

Hello Flo,

thanks for pointing out this issue.
I will fix it.

Cheers,
Oliver

--

[anilg]

- Currently every change, e.g., typing a single character, creates something like a version, i.e. a node in the history graph.
  This would be too detailed for a UI.
  Maybe we would add a concept to 'tag' the current version. Something like bundling session changes into a tagged composite change.
  Then, how should Undo at the boundary of that behave?
- When passing a document to another person the document history should not be available - could be embarrassing ;)
  However, if you send it to yourself you would like to have it...

I don't have a clear vision yet....

Would be great to hear what you would expect from such an UI.

Hi,

I ran across substance via days of googling around the topics of contenteditable, and designmode. What you guys have built is exciting! I also came across this topic, and have some experience building undo stack for Trelby (www.trelby.org). Here's some inputs on Undo points, some from experience, and some from how I think a good UI should behave:

• Do not do character by character stack -- it's annoying to do Ctrl-Z multiple times just to clear the last word.
• I are more about recent changes when undoing than old changes. (More granularity in what I was just typing, and less/none in what I was typing yesterday).
• Allow tagging, so I can manually manage which points on the stack are node of interest.

These three constraints make up for the following undo policy:

• Define points of action. a word entered, a word modified, newline entered, something cut, something pasted, some formatting applied.
• Create undo points at all points of action.
• A pre-created point of action becomes available for removal after a set time/count since most recent, or a function of these two. For eg., a PoA created 200 undo points ago. At this stage it'll be rare that a user will care about the exact difference between undo points 199 and 200. Or an undo point just 5 points ago, but created yesterday. The context between points 5 and 6 is long forgotten. These constants (200, a day, etc) are placeholders.
• With points of action that are available for removal, they are removed (as in rebased) in an exponential index. Removing node 200 would mean applying it's changes into 201, so pressing undo at 199 will set the state to 201. Once 201 is removed, the next to be removed is 2^1 away, i.e., 203. Next is 2^2 away.. 207. The exact formula of which node to remove could be chosen a little differently. But as a user what I'd see is early in my undo process the changes would be words apart, but past a point (200) the changes would be lines apart, and then paragraphs. (Of course our rebasing logic would take care to see that the diffs were split at linguistically logical places). This satisfied my need that my recent changes are more atomic on the undo stack, than changes in the past.
• If at any time a point of interest is tagged by the consumer, it becomes ineligible for removal. Easy object versioning comes in :)
• Finally, once an undo is branched, Do not discard all the poped stack elements! Just add all the changes up, and create a new item on the stack which reverts these changes. So the earlier undo stack is still intact! (i've been bit by this, and lost close to an hour of changes).
  

If the devs are interested, I'm more than happy to discuss this more on this (offline, here, phone, skype, however). I have a bit of interest in using surface for a pet project, which none of the web RTE editors seem to be in a position to solve in an elegant way.

Thanks

Anil

PS: as to the question, should the history of a document be made available later -- If I own the doc, I would like to retain the history. If this is shared with someone else, I'd like that to be purged.

[Michael Aufreiter]

A good way to work around the current bugs is regularly saving the doc to localStorage (cmd+s) and reloading the page. Most errors we have are visually, since we switched to incremental view updates, however the doc model itself is fine and if you save and reload you should see those changes reflected. Cheers, Michael

[Michael Aufreiter]

Hi Anil!

Thanks a lot for your response on undo behavior! That's great input. It's high up on our prioritylist, so it would be great if we could get back to you in a week or two. :)

Also, good to know Trelby exists. I was talking to an independent film director the other day about how an editor like substance could be used for screenswriting. I'll forward the link to him.

-- Michael

[Anil Gulecha]

On Tue, Feb 18, 2014 at 7:17 PM, Michael Aufreiter <mic...@substance.io> wrote:

Hi Anil!

Thanks a lot for your response on undo behavior! That's great input. It's high up on our prioritylist, so it would be great if we could get back to you in a week or two. :)

Also, good to know Trelby exists. I was talking to an independent film director the other day about how an editor like substance could be used for screenswriting. I'll forward the link to him.

-- Michael

Well, the "pet project" I was talking about was a small screenwriting software :) Js has come a long way, and can now make for a very good platform to create multi-platform apps. If the director expresses interest in this, do connect him with me so we can chat a little about the state of screenwriting software.

And I'm happy to answer any questions you may have on my proposed policy/anything you implement. The idea is I'd like an editor component that's external to my purpose of building a software over it.. but the current crop of RTEs don't fit in completely (but could be make done with). The only two options that remained were Google's doc's editor (which is closed), and Substance, which seems to have the awesome separation of the document model, and it's representation on DOM. That's when the "Aha" moment hit, and makes Substance so promising.

Anil