--- Begin Message ---
Hi,
A separate editor is needed when the markup has little resemblance with the
output, which is the case for HTML. In this case, bidirectional editing, as
shown in Sketch-n-Sketch, is indeed a very nice thing.
However, in the case of Documenter and the Pillar markup the output is closely
related to the sources part. In this case, having the two worlds be supported
seamlessly in the same experience is a huge advantage, especially for
non-technical people. The interface from Documenter is not trivially possible
(I for now never saw one like that, and I looked specifically for it) because
of the prerequisites it needs from underlying graphical framework, but I do
think it’s a significant step forward in the notebooks space.
Cheers,
Doru
> On Jan 1, 2019, at 8:01 PM, Konrad Hinsen <konrad.hin...@fastmail.net> wrote:
>
> Hi Offray and Doru,
>
> allow me to chirp in on a topic that I have been thinking about for a
> while:
>
>>> Interesting observation. The linked tools as all other notebook
>>> technologies I saw rely on two distinct modes for edit and view that
>>> reside in two distinct widgets (editor and viewer). They do that
>>> because they simply cannot have it in one. Because of the design of
>>> Bloc we are not constrained to that. Instead, we build a seamless
>>> interface that is both optimized for viewing, and for editing with
>>> live preview that does not rely on an explicit render button. This
>>> approach enables direct manipulation without friction, and we think
>>> this is a significant advancement in this space.
>
>> I don't think is only because other editors can't do it, but because
>> some (most) times you don't want "to conflate two tasks that are
>> /conceptually/ distinct and that, to ensure that people's time is used
>> most effectively and that the final communication is most effective,
>> ought also to be kept /practically/ distinct"[1] which are Composition
>> and typesetting.
>
> Two remarks.
>
> First, this is a special case of the more general issue of having
> multiple views and even multiple editors for a single object. No matter
> what you believe to be the best approach to editing text with markup, in
> many other situations it is clearly desirable to have multiple
> views/editors side by side, and I have regretted more than once that
> this doesn't seem to be possible in Pharo's inspector.
>
> For multiple editors the need to have them side by side is probably more
> obvious than for mere views, so it may be useful to look at practical
> examples and see how one would realize them in Pharo and/or in GT. One
> of my favorite applications is graphics that are generated by program
> code but can also be edited graphically, as implemented in
> Sketch-n-Sketch (https://ravichugh.github.io/sketch-n-sketch/).
> You definitely want the two panes, code and graphics, side by side.
>
> Second, the example of editing text with markup also illustrates that it
> matters if views are complete (i.e. show all the available data) or
> partial, and if they are invertible, i.e. if a change in an editable
> view can be translated unambiguously into a change in the underlying
> data. Markup with comments, as mentioned by Offray, is a case in which
> the rendered view is partial but nevertheless invertible, so it makes
> sense to have two types of editors, one for the raw markup text and one
> for the rendered version. Some people may want both side by side,
> whereas others may prefer a single one with the possibility to switch,
> depending on how important the non-rendered information is.
>
> Scientific data visualization provides plenty of interesting examples by
> the way, often with the additional challenge of significant
> computational cost in rendering.
>
> Konrad.
>
--
www.feenk.com
"Innovation comes in the least expected form.
That is, if it is expected, it already happened."
--- End Message ---
