Google Lemonade: New Software Version

Google Lemonade posts are where I recoup some of my time doing free testing for Google by using their new software version. Specifically, I document my testing as a "living history" of the computer industry. (As Google throws me lemons, I make lemonade.)

I've noticed that they have released a new test version because I've seen some changes. So I did some more testing.

The good:

They have fixed their horrible performance issue concerning photo uploads by going back to their old upload software. Unfortunately, the first time I included some photos, they were inserted at the bottom instead of where I had placed the cursor. (An old reported bug that evidently still exists.)  The second time I inserted photos, they went where the cursor was placed. So this bug is still intermittent. Another unfortunate result was that the "Add caption" text is still not auto selected.

The bad:

I can't figure out how to edit the HTML. The HTML toggle icon that I finally found in the previous new version has disappeared. (Their asking us to do free Beta testing, but I can't find a version code anywhere. So we have terminology like "previous new version.")

The formatting icon layout that I didn't like is now even worse. But I'm not going to bother to describe that issue because it is painfully obvious that Google doesn't care about the human interface.

They need to copy my New I-74 post and try typing something near the "<update cursor/>" text. The delay of what I was typing was so bad that I hadn't seen performance that bad since the 1970s when I was using an overloaded Unix system on a PDP 11/70. In fact it was worse. I noticed that I would not see any text appear until after I stopped typing, and then everything I typed (eventually) appeared at once in the window. Below is the number of x's sent while I held down the x-key while I count up to 2 Mississippi.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

This is what I saw when I did this test at the <update cursor/> in the New I-74 post using the legacy version.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The length of the string is not important. The important thing is that I saw each x appear in rapid succession. And here is the string I see when I hold down the x-key for about two seconds in the new version:

x

I used a stopwatch app to time when the rest of the string would finally appear. 12 seconds later! Google has an impressively bad performance problem! It appears that they have been testing with just "toy" sized posts.

They still can't handle the embedded HTML generated by their own product, YouTube.

The ugly:

I thought another showstopper bug may have been fixed. In the past, I've noticed that the content of a URL would get changed to a www.blogger.com URL. Since this bug destroys my user content, this is one of the reason's why I have avoided using the new version. One way I could recreate the bug was to select text with a URL in it in one post and then paste it into another post. When I did that test today, it worked. But then I realized that the source and destination posts were both using the new version. When I used the legacy version for the destination post, the bug appeared again.
>

The domain should be www.facebook.com instead of www.blogger.com. This blew my mind, but it does explain why Google hasn't found this bug because they are probably testing with just the new version. The reason why it blew my mind is that I was assuming that the new version was changing the URL when I copied the text to the clipboard. My old debugging technique of using Notepad or Wordpad to see what was in the clipboard doesn't work because the URL information disappears completely! (Has Notepad and Wordpad changed?) So I pasted test lines into a temporary new blog post using the legacy version so that I could then display the HTML. In the following test, the first line was sourced by the new version and the second line was sourced by the legacy version.

The fonts are of a different size because the first line was from the body whereas the second was from a caption. This is the resulting HTML.

<br />

I-74 River Bridge&nbsp;<a data-original-attrs="{&quot;data-original-href&quot;:&quot;https://www.facebook.com/I74RiverBridge/posts/937121236809316&quot;}" href="https://www.blogger.com/blog/post/edit/7577633936396294153/137323103592482990#" target="_blank">posted&nbsp;</a>three photos with the comment:<br />

<br />

<span style="font-size: 12.8px; text-align: center;">One of 36 photos&nbsp;</span><a href="https://www.facebook.com/groups/Manitowoccraneenthusiasts/permalink/3053171341433762/" style="font-size: 12.8px; text-align: center;" target="_blank">shared&nbsp;</a><span style="font-size: 12.8px; text-align: center;">by Ben Stalvey</span><br />

<br />

The new version puts HTML on the clipboard that will not play nice with other software products, including their own previous version! They should use the real URL in the href tag and put the edit numbers in a new tag in the anchor element. What are they doing with the edit so that they can no longer use the industry "style" standard? 

Below is a draft I wrote July 7 about the URL content going bad. I never published it because I kept finding more interesting topics to publish. Now, fortunately, it is obsolete since I discovered that the problem is the design of the HTML that is put on the clipboard. I include this because it shows how debugging software is typically a matter of guessing and goofing your ways towards the root cause. My first round of characterizing this bug was "URL links are still being destroyed."


A reminder: Google Lemonade posts are an effort to recover time wasted by Google's request that we try their new blog writing interface. They are kind of a living history of the software industry. Also, using the blog helps me cope with the tiny text window they use in their feedback popup.

With thousands of posts written in my main two blogs, I spend quite a bit of my time editing what I have already written. Sometimes it is rearranging the content of a post. For example, I rewrote my State Street Bridge notes to organize the photos by bridge. Another heavy use of cut&paste is when I write some new notes by consolidating information that is in existing note files. For example, I moved the content:

from Aurora, Elgin & Fox River Interurban to Fox River Trolley Museum. Unfortunately, I did the cut out of the AE&FR notes using the new version. When I used the pasted text in the new notes, I saw:

That link should be facebook.com, not blogger.com!!!! FORTUNATELY, I had not clicked the "Update" button for the old notes, so I was able to retrieve the original text.

All of those links should be to facebook.com. I switched to HTML-edit mode to verify that they all got destroyed by the blogger.com nonsense.

I reported bugs concerning URL content getting changed to nonsense over a month ago. But their feedback has no feedback so I don't know if they even read it, let alone when they think they have fixed it. Asking people to use a product with a much worse user interface is one thing, but asking them to use something that will KNOWINGLY destroy their content is a whole new level of "beta" testing.

So why was I even using the new version since I knew it to be bogus. Since the author's keyword search function broke in the old version last April 3, 2018, I keep one window open with the new version to do searches. And I do "simple" edits with the new version rather than find the same post with the old version to do edits. And now I know I have to find a post with the old version in order to copy text from it. And I have no idea how long I will have to avoid using the new version to avoid creaming the contents of my URLs.