Writing Experience improvement

[quirkt]

Thanks for weighing in; please see my response to chrillek, I hope that clarifies that I am, I think, taking the simplest approach possible, but why still “it’s complicated.” Apologies if I am overlooking something.

A while back when DT3 arrived, I worked really hard in the forum to clarify my problems with the disappearance of three-pane view. After describing, with quite a few others, at considerable length how that interface change was hampering my work, new capabilities were added to the sidebar that solved the problem. Very grateful for that! There are a number of us now who’ve been trying to describe our wishes for the visual experience of the text editor window in DT. The OP’s points above about column width and white space get to the core of the problem for me, and the screen shots demonstrate the problem well. If there was simply a way for us to adjust the default column width and the vertical spacing between lines in the text editor view, on both the computer and the iPad, it would be a vast improvement.

I say all of this as a huge, huge fan of DT as a general tool for writers—I have been using it for many years and recommend it to everyone—and I recognize that there is an aesthetic element to creative production that I’m describing that may not be relevant to others.

[BLUEFROG]

We appreciate the advocacy!

Remember, DEVONthink is not DEVONthink To Go and macOS is not iOS/iPadOS. Your experience on each platform is not necessarily going to be the same, especially with the different underlying filesystems.

That being said, iaWriter on mobile supports the file provider mechanism so you can open a Markdown document in a DEVONthink To Go database via the Share sheet or within iaWriter’s Library > From Other Apps.

Development would have to assess the feasibility of such changes. However, I do see how a bit of air would be good in dense text passages…

But again, remember iaWriter (like Ulysses, Typora, etc.) is a bespoke Markdown app. That’s its one trick, it’s raison d’être. So obviously it will have functions and features specific to writing.

[quirkt]

Thanks for listening! (Yes, on iPad my routine is to open DTTG, select MD file and open it via share sheet into iA Writer.)

[anon55513942]

@chrillek

expressing my surprise at the fact that seemingly all requests to modify the editor are related to visual effects.

I think the reasons for this are simple:

1. The editor is (largely) bug-free. So, few complaints there.
2. The editor is functionally adequate. So, few complaints there.
3. Support for (Apple-)scripting is robust. So, few complaints there.

These facts leave “visual effects” as a source of consternation for some. Not for all, but for some. As is to be expected.

For me, I wish that the cognitive dissonance that I experience in two very common scenarios could be ameliorated:

1. The current implementation of lists creates a visual mess (a form of “visual effect”) in documents of any complexity, because there’s no hanging indentation of items.
2. Why is blockquoted text styled with a thick blue left border and in italics? Simple indentation, relying on the "> " markdown as the visual cue of a blockquoted passage, would suffice, but again, with the hanging indentation consistent with the first line; that is to say that hanging indentation to be set at the point after the leading "> " in the first line. And the obtrusive blue border serves no purpose other than to distract, and the italics styling serve the purpose of … what is the purpose of this? Is it supposed to be quasi-WYSISYG? (which would of course depend on the CSS in effect for rendering the text…I am casting about for reasons). Whatever the reason, it makes me ask What the purpose of this? every time I look at it. And the visual editing behavior of typing Return causing the block quote to break and necessitate typing “>” to re-initiate, causing another spasm as the view updates, leaves a lot to be desired. This is especially distracting when editing within a blockquoted passage. (A smoother experience would be, when typing Return, for block quoting to continue, and be canceled upon typing Return twice.)

And, the editor is partially WYSIWYG-enabled in that struck through text is rendered as struck through. And emboldened text as emboldened, italicized…header text…except when included in a blockquote…inconsistencies, which, along with the exceptions noted above, induces more cognitive dissonance.

See the images (“as-is” and “suggested”) as illustration. These “visual effects” break flow and induce frustration. Simply because I have trouble reading what I’ve written. Yes, I could purchase some other editor, and go through gyrations to use it in concert with DEVONthink, but I have an editor, and I’d like it to be more accommodating, and for flow to be preserved, aided by not having to switch applications to edit text.

Of course, I could use RTF…except that RTF is not fully supported in DTTG (despite valiant efforts by the DEVON devs; Apple apparently is not cooperative with upkeep.) Or plain text, but there’s no formatting available for plain text (the point of plain text is to be plain, of course). Formatted Notes do not support lists, and the proposal that I write and maintain HTML is to me simply ludicrous.

This leaves…Markdown. Which I use, and wrestle with, every day.

(PS: would the DEVON team please consider my suggestions above as enhancement requests? (Please don’t take my mockup literally, but only as a mockup/illustration of concepts.) Thank you, and thank you for the great product that DEVONthink is.)

[chrillek]

@anon55513942

The editor is functionally adequate. So, few complaints there.

Not by a far cry (think search/replace with regular expressions). But then I’m coming from Emacs. And I don’t care what DT’s editor is missing – if I need a writing environment, I use one.

As to your suggestions: We’re going in circles here. Some people want DT to include an MD editor up to par with dedicated products. Others might want image processing capabilities, others still the possibility to modify PDFs or an editor suitable for programming languages.
Should the DT people prioritize MD over PDF or image editing? Why?
Or should DT users employ dedicated tools fulfilling their requirements?

Having said all that: i still think that more liberally used white space (left/right margins, line spacing) in the editor would be beneficial.

[chirurgean]

I think it all boils down to whether you want 1 program to rule them all, or to use the correct tools for the job. Option 1 leads to bloated programs such as MS Word.
When I am working, I want my favourite forceps and dissecting scissors for that particular situation. I could also say that I could hit a nail into wood with a heavy pair of pliers, but a hammer is much better.

I use DT (actually mostly DTTG) as the repository, and link into Craft, iaWriter, Numbers etc … back and forth as required
I even achieve my preferred formatting of my book annotations by moving from my epub in Marvin to Craft, then to Drafts and back to Craft by means of iaWriter.

Write once, keep the data safe (DT) and refer/use it in various formats in multiple apps

[anon55513942]

@chrillek

@anon55513942

The editor is functionally adequate. So, few complaints there.

Not by a far cry (think search/replace with regular expressions

Good point. Agree that this would be a significant and welcome enhancement.

@chrillek

And I don’t care what DT’s editor is missing

As you’ve made abundantly clear.

@chrillek

We’re going in circles here

My point is to simply describe my frustrations with the current state of MD support in the editor, to propose specific enhancements, and to add my voice to others’ in general support of enhancements to the editor.

@chrillek

Should the DT people prioritize MD over PDF or image editing? Why?

That, of course, is up to the DEVON team. And they clearly do listen to their user base, who are expressing their opinions here, indeed, as you have above with your observation that enhanced search would be useful.

@chrillek

Or should DT users employ dedicated tools fulfilling their requirements?

“should DT users employ dedicated tools…” is not exactly the question here: some users are in effect forced to employ additional apps to achieve their desired results. But, other than this, of course, it is up to individual users to make do without, or to employ additional of apps at additional cost and burdens (maintenance, compatibility,…) and inconveniences ranging from trivial to significant, to achieve their goals. For some, enhancements to the built-in editor are more supportive of their goals. as they have described.

Of course, all are free to agree or disagree, with any opinion, observation, or proposal. But to express surprise that such opinions exist, and to cast the question as a simple take-it-or-leave-it choice, is…surprising.

[kewms]

FWIW, I don’t try to maintain my research database in Scrivener, and I don’t try to write in DevonThink. Which naturally means that I’m a bit puzzled by people who do.

I can certainly see the appeal. But when, in the history of computing, has that kind of Swiss Army knife design actually worked? In my own experience, at least, there are far more examples of programs that became less stable and more difficult to use as they tried to satisfy more and more user requirements.

[FrankT]

@kewms

I don’t try to maintain my research database in Scrivener

Why not? Do you think Scrivener can’t do that?

@kewms

and I don’t try to write in DevonThink

Why not? You can write very well in DT. You can even write in TextEdit. If you can’t do that, you can’t write. This has nothing to do with software and is the eternal misunderstanding of those who can’t write.

@kewms

In my own experience, at least, there are far more examples of programs that became less stable and more difficult to use as they tried to satisfy more and more user requirements.

This is an excuse for doing nothing. The developers of DT make every effort to take into account the realizable wishes of the users. @BLUEFROG often writes “noted, but no promise” in this forum. Can you tell me the last time L&L implemented a suggestion from their users? Or more simply: Can you show me one (1) post in the Scrivener forum where something like this is written? You know why I’m asking you that

[NickLowe]

@anon55513942

Why is blockquoted text styled with a thick blue left border and in italics? Simple indentation, relying on the "> " markdown as the visual cue of a blockquoted passage, would suffice, but again, with the hanging indentation consistent with the first line; that is to say that hanging indentation to be set at the point after the leading "> " in the first line. And the obtrusive blue border serves no purpose other than to distract, and the italics styling serve the purpose of … what is the purpose of this? Is it supposed to be quasi-WYSISYG? (which would of course depend on the CSS in effect for rendering the text…I am casting about for reasons). Whatever the reason, it makes me ask What the purpose of this? every time I look at it.

This one is a relatively recent development, only introduced in 3.9. I don’t love it any more than you do, not least (though not only) because it no longer preserves formatting when you use Insert Quote in an Annotation. (In fairness, this is a consequence of and trade-off with the deep-linking functionality that was introduced as part of the same version, and it’s easily worked around by the small extra step of copying and pasting the original selected text over it.) But yes, it’s evidently supposed to be quasi-WYSIWYG, and possibly illustrates the hazards of trying to please the whitespace enthusiasts – of whom I’m pretty much the exact opposite, though I don’t think anyone was clamouring for a redesign of the blockquote display.

[BLUEFROG]

@NickLowe

though I don’t think anyone was clamouring for a redesign of the blockquote display.

We get input from more sources than these forums

[kewms]

@FrankT

Why not? Do you think Scrivener can’t do that?

Sure. DT does it better.

@FrankT

Why not? You can write very well in DT. You can even write in TextEdit. If you can’t do that, you can’t write. This has nothing to do with software and is the eternal misunderstanding of those who can’t write.

LOL. Making assumptions about the people you’re conversing with is an easy way to embarrass yourself. I’m sure the three different editors who’ve accepted work from me in the last week would be shocked to learn that I can’t write.

But I find that I write better and faster in Scrivener than in DT (or TextEdit, or Word, for that matter).

Since this is the DevonThink forum, I’m not sure how L&L’s responses to feature requests are relevant. You’re of course welcome to visit the L&L forums, too.

[amcawood]

I’m firmly in the “give it some air” camp re the Markdown editor. External editing is a perfectly adequate solution, and so is the customisable preview. But it would be easier for this user just to have options for more whitespace in the editor, so that dense text in Markdown notes can be reviewed and edited without resorting to other views.
Not necessary, not even important, but a nice option to have to eliminate a constant source of friction in an app that otherwise doesn’t have much friction.

[meowky]

@kewms

in the history of computing, has that kind of Swiss Army knife design actually worked

It depends on your understanding of what counts as “working”. Operating systems work. Microsoft Excel works. ChessBase, a professional chess database program which I use regularly, works. All these have been expanding their respective capabilities over the years, each becoming the Swiss Army knife of its field. It’s true that they …

@kewms

became less stable and more difficult to use as they tried to satisfy more and more user requirements

… But they still work, which I take to mean that they actually help users get things done. More often than not, the new features allow users to get things done quicker and better.

Imperfection is always there, and is never an excuse to not try. The distinct argument that octopus software takes too much pains to maintain would be another topic.

[anon55513942]

Maybe a better way of describing what I’m after is to speak in terms of “affordances” (though my use of the term may not be precise to its definition). For example, the editor:

• Displays a line of text preceded by header markdown in bolded text, at a relative size larger than the body text, and according to the header level.
• Displays text wrapped in asterisks italicized, text wrapped in pairs of asterisks emboldened, and text wrapped in three asterisks emboldened and italicized.
• Displays text wrapped in two ~ as struck through.

I would loosely call these behaviors affordances, and I appreciate them. They give visual cues as to the text’s formatting, and an implicit sense of context. Their implementations in the editor make sense: emboldened text is emboldened, not colored green. Italicized text is italicized, not subscripted.

But, the editor displays blockquoted text in a way that makes no sense. Instead of a thick blue border at the left that takes up far more vertical space than the enclosed text, the editor may just as well show a narrow (or wide, or wavy) vertical line of red (or yellow, or brown) dots (or triangles, or backslashes), that is crammed into the edit space with no top and no bottom padding (or with 150% padding, or 79% padding). Instead of displaying the enclosed text italicized, it may as well show it in a serif font (or shaded pink, or struck through, or in Comic Sans). None of these options, including the editor’s current behavior, make any sense at all that is related to a blockquote.

(OK, then what affordances make sense for a blockquote? Indentation according to the indentation of the “container” wherein the blockquote is placed, a visual cue indicating a blockquote, and a smooth way of working with the format. None of which, in my experience, exist today, in adequate forms.)

And the lack of hanging indents in lists just creates a visual mess that has as the only affordance one indented line and an asterisk (or dash, depending on what you like to use; or a number), per list item. This text more resembles mistakes made during editing, than conveying the ordered sense that lists implicitly lend. A hanging indent is an affordance that brings legibility, order, and context to these lists in the editor.

I’ve done what I reasonably can to change my writing habits to become more accommodating to the editor’s constraints (I don’t nest lists more than 2-3 levels, I break up large texts into smaller files that are transcluded, but there’s nothing at all I can do about blockquoting), but these do not fix any of the underlying problems. The editor is forcing me to comply. But end-user compliance (“making do”) is not a substitute for affordances. And I can’t customize or automate my way out of these conundrums. These behaviors are baked into the editor.

All this, taken together, is why I term the problem “cognitive dissonance.”

And just to be clear, I for one am not at all interested in DT implementing Scrivener’s (or any other app’s) suite of editing features.

I simply want to be able to more clearly see and make sense of what I’ve written in the DT editor, and to not have to dedicate time and energy and money into researching, testing, purchasing, and maintaining another, or maybe even more, apps, to replace the editor that DT has, or wondering at every turn, even after over a year and a half of using v3.x, for hours every day, “Why does it do this? What kind of sense does this make? I can’t make sense of what I’ve created.”

It’s very frustrating. More affordances, please.

[Grantst]

Hi Bluefrog, I would like to add my request to markdown editor enhancements, simple things like word wrap, line height would make a difference to me. Given all of the writing time is done in that view, it would be helpful for those who want a simple markdown editor but prefer to stay in the DT environment. And yes may be reconsider that blockquote

[BLUEFROG]

@anon55513942

But, the editor displays blockquoted text in a way that makes no sense.

I’m not sure where you’re getting this idea. Blockquote something in this thread and what do you see rendered?…

Also, search for blockquote css and you see a ton of examples showing this specific styling.

…etc. So it seems pretty logical to have it applied in WYSIWYG styling as its supposed to mimic the rendered view to some degree.

[davidsingerman]

EDITED TO READ: I’ll just say that I’d be grateful for a narrower writing column too.

[anon55513942]

I don’t understand your reply. You seem to be referring to the rendered view of markdown? I’m referring to the behavior of the editor. Maybe the attached screenshot / narrative will help illustrate the difficulties I’m having. You refer to CSS: is there some CSS that I’m not aware of that controls how things appear in the editor? Thanks.

[BLUEFROG]

No. I am referring to the WYSIWYG view of the source. You said it didn’t make sense why it appears the way it does. I showed the reasons why it appears that way.