Content Notes and Revisions — MWD Essays
Editorial History
Revision history and technical notes
WordPress and Grammarly interaction nightmare.
WordPress design flaws.
Revision History
1993-1998 Hand-written essay drafts transcribed into Microsoft Word 2.0.
2000 Original Word 2.0 document partially converted to Microsoft FrontPage 98.
2008-2009 Converted to W3C XHTML compliant Microsoft ASP.NET website.
2009 Several previously unpublished stories, primarily about the Dial family, were added to the website.
2015 Website converted from Windows Server 2012 hosting to Linux Apache hosting.
2019 Converted to WordPress blog.
2022 Blog migrated to HostGator with extensive internal design improvements.
Gutenberg and Grammarly—The Perfect Storm
This is a story about how not to build and market a software product. The new WordPress Gutenberg editor and the Grammarly syntax and diction correction software have interactions that produce a perfect storm because WordPress can blame its Gutenberg editor’s problems on Grammarly and Grammarly can blame WordPress for Grammarly’s user-hostile design deficiencies.
Grammarly Problem Environment
Primarily Linux Mint and FireFox, with the occasional use of Win 10/11 and other browsers.
Grammarly Problem Description as of 2018
This situation is apparently attributable to both companies entrusting the navigation of their software development ships to hit-and-run, drive-by marketing geniuses. Shame on WordPress and triple shame on Grammarly for the situation described below. I hope this article will provide food for thought and shame both Grammarly and WordPress into doing some cleanup on their respective acts.
Yours truly has been converting a series of articles from an old website into WordPress blog posts and using Grammarly to polish posts containing many punctuation errors.
Naively, I had bought into WordPress’s marketing hype about how wonderful the new Gutenberg block editor was and used it for the task. Gutenberg appeared to be working quite well with Grammarly – until I looked closely at the results.
The WordPress Update button was regularly clicked while revising posts. Unfortunately, this was approaching the task far too logically. Some of my approved changes were saved in the WordPress posts, but most were not. Many of the accepted changes were later replaced with the original error – again and again and again! Dealing with this inexcusable incompatibility between WordPress and Grammarly tripled the time needed to edit each of the new posts.
A strategy for outsmarting Grammarly and Gutenberg was needed. Users should not need to create methodologies for outsmarting program bugs that never should have happened in the first place.
The solution for this mess is as fubar as the situation itself. After my reverse-engineering of the thought processes of the Gutenberg and Grammarly designers was complete, I loaded the text for the next post into Gutenberg, saved the post into WordPress, and closed Gutenberg. Then I opened the post in the WordPress Classic Editor in HTML view and re-edited and applied the botched Grammarly suggestions.
I find it appalling that the only way to get Grammarly to work tolerably in the WordPress environment was to directly feed the post’s HTML to Grammarly by pasting the post’s HTML directly into the Grammarly editor. Needless to say, the level of technical skill needed for this task is not present in most Grammarly and WordPress Gutenberg users, nor should it be. Surprisingly, Grammarly likes HTML better than it likes plain English. Loving HTML is not bad for a utility intended to analyze English syntax and diction. Is this linguistic accomplishment a triumph of artificial intelligence, or is it a triumph of artificial stupidity?
One would hope that the Gutenberg and Grammarly marketing people would stop wallowing in their product-aggrandizing hype long enough to take a deep breath and look at the absurdity of the often author-hostile garbage that they have asked their respective software people to build.
It seems that when accepting Grammarly’s suggestions in Gutenberg, Grammarly would sometimes take the erroneous text and enclose it in an HTML <g> block, which preserved the error text while keeping the corrected text out of the underlying HTML. Cute. HTML <g> tags are for defining vector graphics, which are not used in any of my WordPress posts. Here is an example of Grammarly’s insane error preservation code:
<g class="gr_ gr_118 gr-alert gr_gramm gr_inline_cards gr_run_anim Style multiReplace" id="118" data-gr-id="118">to use</g>Grammarly often navigates from correction to correction in a random order rather than sequentially. Editing is a sequential process and having Grammarly constantly jump around in the document disrupts an editor’s train of thought. This is no different from interrupting a programmer’s thinking even though Grammarly’s designers are unable to see the relevance of the analogy. Grammarly’s top management lacks the real-world experience needed to know that bad ergonomics hurts Grammarly’s usability. “simple” when applied to a complex product by simpletons is anything but “simple.” Where is Grammarly’s top management? At the bar, or just asleep on the job?
Grammarly’s designers apparently make multiple passes through a document when presenting possible errors to the user. This keeps it “simple” for the software builder by dealing with errors on a category-by-category basis. Such an approach creates a nightmare for an author/editor that is attempting to use the product. A convenient design from a software construction point of view has created a nightmarishly tangled product for an author/editor to use for serious editing.
One app development truth that this old head learned long ago is that quality user applications are the result of programmers having the authority to take rough edges off the apps they are building. Moreover, there is no substitute for having the programmer use his/her software to do real production work in a production environment. The rough edges that no one thought of in the design phase get fixed this way. It can make the difference between a truly great app and a piece of garbage ware.
BTW, another cute feature in Gutenberg is creating nested paragraphs within a Gutenberg block. Gutenberg is supposed to be “simple” to use, but asking an inexperienced author to delve into an HTML editor to straighten out nested paragraphs is absurd. Consider how absurd — not at all simple to deal with — the following HTML for a Gutenberg nested paragraph block is:
<!-- wp:paragraph -->
<p><p>Hello world! I am a nested paragraph, and I cannot exist in a three dimensional world — but in the WordPress world I do exist!</p></p>
<!-- /wp:paragraph -->Solution
Apply the universal solution to all badly behaving software, which is to blame Microsoft and Google because they deserve it.
Gutenberg and Grammarly Conclusion
Authors beware when using Gutenberg and Grammarly together. Make sure you have as good a command of HTML as English. Gutenberg is not fully ready for prime time as of 2020, and Grammarly has had an ongoing insensitivity to editing ergonomics, as well as an immunity to customer input on issues as basic as the ergonomics of the editing process.
Grammarly’s idea of keeping its use “simple” means making its analysis so feeble-minded that Grammarly is a nightmare to use. There is a limit to how far one can go in “simplifying” a complex app without making the product useless.
Using Grammarly to do an editing task is like riding in a self-driving car remotely controlled by a hacker. The people at Grammarly get the year’s marketing award for figuring out how to simplify their product to a point approaching worthlessness. So many marketing people think that if all the user can do is press a single button once, the world’s problems will be solved. Sorry, but some things cannot be made that simple and still have usefulness.
WordPress design flaws.
The user will occasionally find some things in the blog to be rather clunky at best due to the appallingly bad software engineering in the heart of WordPress. This bad design has made building a nicely behaved website far more difficult on occasion than it would have been had the original designers known what they were doing.
For instance, related code and settings are fragmented and scattered everywhere. Also, all links appear to use absolute addressing across the board categorically, even in cases where relative links would make the blog far easier to maintain, stage, and migrate. Worse yet, the penchant for absolute addressing results in developmental copies of blogs cross-linking into each other in insidious and hard-to-spot ways that can leave the website appearing to work in development mode but fail in production.
Moreover, using PHP as the programming language introduces additional booby traps because that language does not strictly type its variables. This “feature” can allow some programming bugs to go undetected. PHP claims to be object-oriented but lacks the greater level of “goofproof” object definition strictness found in C# or java. Corner cutting at the language design level can make application building expensive and tedious. In short, the core of WordPress has been designed by second-rate auto mechanics who fancy themselves to be first-rate automotive engineers.