Ben Langhinrichs

Photograph of Ben Langhinrichs

E-mail address - Ben Langhinrichs






August, 2019
SMTWTFS
    01 02 03
04 05 06 07 08 09 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

Search the weblog





























Genii Weblog


Civility in critiquing the ideas of others is no vice. Rudeness in defending your own ideas is no virtue.


Fri 16 Aug 2019, 09:50 AM
Fifteen years ago, I started a campaign to convince IBM to at least fix the very easiest of rendering issues, the point size of text. I wrote about it on forums and brought it up with IBMers, but nobody seemed to care. It was part of my motivation for writing CoexEdit, which is now AppsFidelity. A memorable post from early 2005 is Selling a 9 year old on CoexEdit, and when CoexEdit was a Beacon Award finalist in January 2006, I thought maybe the point had been made.
 
Well, not quite. Not only was the point problem not fixed in version 9.0.1 or its many fixpacks, but it remained inconsistent. A couple examples. Pay attention to where the small sizes change.
 
Notes/Domino 9.0.1 MIME rendering (sending as email whether rendered by client or server)
Inline GIF image
 
Domino 9.0.1 HTTP rendering (viewing on web page)
Inline GIF image
 
There are other renderings as well, such as when the form saves the rich text field as MIME, when Domino Access Services renders the document to MIME. Sometime 9pt is <font size=1> and sometimes it is <font size=2>. While 10pt and 11pt appear about the same in all, sometimes the size is explicit, as in this from the rich text saved as MIME:
 
<font size=1 face="Times New Roman">Text in 6 pt</font>
<br><font size=1 face="Times New Roman">Text in 7 pt</font>
<br><font size=1 face="Times New Roman">Text in 8 pt</font>
<br><font size=1 face="Times New Roman">Text in 9 pt</font>
<br><font size=2 face="Times New Roman">Text in 10 pt</font>
<br><font size=2 face="Times New Roman">Text in 11 pt</font>
<br><font size=3 face="Times New Roman">Text in 12 pt</font>
<br><font size=3 face="Times New Roman">Text in 13 pt</font>
<br><font size=4 face="Times New Roman">Text in 14 pt</font>
<br><font size=4 face="Times New Roman">Text in 15 pt</font>
<br><font size=4 face="Times New Roman">Text in 16 pt</font>
<br><font size=4 face="Times New Roman">Text in 17 pt</font>
<br><font size=5 face="Times New Roman">Text in 18 pt</font>
<br><font size=5 face="Times New Roman">Text in 19 pt</font>
<br><font size=5 face="Times New Roman">Text in 20 pt</font>
 
and other times it is implicit such as this from the Domino HTTP:
 
<font size="1" face="Times New Roman">Text in 6 pt</font><br>
<font size="1" face="Times New Roman">Text in 7 pt</font><br>
<font size="2" face="Times New Roman">Text in 8 pt</font><br>
<font size="2" face="Times New Roman">Text in 9 pt</font><br>
<font face="Times New Roman">Text in 10 pt</font><br>
<font face="Times New Roman">Text in 11 pt</font><br>
<font size="4" face="Times New Roman">Text in 12 pt</font><br>
<font size="4" face="Times New Roman">Text in 13 pt</font><br>
<font size="5" face="Times New Roman">Text in 14 pt</font><br>
<font size="5" face="Times New Roman">Text in 15 pt</font><br>
<font size="5" face="Times New Roman">Text in 16 pt</font><br>
<font size="5" face="Times New Roman">Text in 17 pt</font><br>
<font size="6" face="Times New Roman">Text in 18 pt</font><br>
<font size="6" face="Times New Roman">Text in 19 pt</font><br>
<font size="6" face="Times New Roman">Text in 20 pt</font><br>
 
While that seems an innocent difference, remember that CSS will override a missing size differently than an explicit size, so you can have a magnified text page where the 10pt and 11pt are larger than the 14pt, 15pt, 16pt, and 17pt.
 
All of these issues ignore the extremely easy to implement CSS style that will use point sizes, as our products have done since late 2004.
 
But while IBM did not pay attention, HCL is aware of the issue and making some progress. If you look at the Notes client MIME rendering (email sent when location document specifies sending MIME), you will see:
 
Notes 10.0.1 MIME rendering (sending as email rendered by client)
Inline GIF image
 
Finally, CSS styling to get exact point sizes! This is implemented as well in places where the form saves the rich text field as MIME. It is not fixed when the Domino server renders the MIME, as in:
 
Domino 10.0.1 MIME rendering (sending as email rendered by server)
Inline GIF image
 
It is also not fixed in Domino 10.0.1 HTTP or Domino Access Services:
 
Domino 10.0.1 HTTP rendering (viewing on web page)
Inline GIF image
 
But HCL gets that this is an issue. They mentioned fixing rich text as a major bullet item in their AppDev roadmap at the Factory Tour, and this is one of many fixes necessary and (as far as I can tell) planned.
 
The point is consistency, accuracy, and fidelity. HCL gets it. Hopefully, soon we will all get there.
 

Copyright © 2019 Genii Software Ltd.

Tags:

Thu 15 Aug 2019, 01:11 PM
Inline JPEG image
 
Yesterday, Genii Software released Version 5.60 of the Midas LSX and the Midas C++ API. Both are available for download from the Genii Software website at http://geniisoft.com. While a number of customers have been running for months with pre-release versions, this wraps up the features and bug fixes included in those and adds more. Version 5.60 supports Notes/Domino 6.5.x to 10.x for Windows 32-bit and 64-bit. Support for Linux 32-bit and 64-bit coming next week.
 
A few highlights:
 
  1. Expanded support for active elements in generated HTML/MIME/etc.

    As with tabbed tables and sections, caption table and AdvanceOnClick tables now have support for both full JavaScript and pseudo-class JavaScript renderings so that they will act on the web the way they do in Notes. See the short video at the bottom of the post 
    When low code is no code - saving space for mobile for an example showing AdvanceOnClick tables.
  2. Enhanced support for keyword and other form element rendering to HTML/MIME/etc.

    Whether rendering a form or a forwarded email, keyword fields such as radio buttons and combo boxes and checkboxes will render looking the way they did in Notes.
  3. Support for rendering language tagging in text.

    Whether a word or phrase or multiple paragraphs, when text is tagged with a language, rendered HTML/MIME/etc. will include that language tagging so that screen readers can pronounce it properly and discovery tools that use language can find and identify it properly.
  4. Custom replacement engine for Notes/Domino rendering to rich text

    Due to various bugs and deficiencies, we have incorporated a new internal engine to render a form and its fields to rich text faster, with greater fidelity, and with greater stability. This is largeley hidden, but is most obvious in places such as the Export to CSV used by so many customers to render full documents with their forms to HTML or MIME.
 
New version will work with existing Midas Version 5.x licenses except those no longer under maintenance.

Copyright © 2019 Genii Software Ltd.

Tags:

Wed 14 Aug 2019, 10:15 AM
This is the second in an occasional series on what you can do right now with Notes/Domino, and some ways our products can help. As before, the top half is general and non-commercial, while the bottom half is where I mention how our products enhance the situation, so you can skip that if you want.
 
A number of enhancements that were made in the earlier days of Notes popularity had to do with saving space. As laptops were coming into vogue, and as companies were packing more and more functionality into an application, they wanted ways to conserve space. These features include tabbed tables, collapsible sections and more. Now, with HCL introducing those Notes apps including the rich text features to mobile devices, the space saving features take on a new importance. Real estate is at a premium even on a larger iPad, and once you are talking phones, anything you can do to use your space more wisely is worth it.
 
With that in mind, let me remind you of a demo I first did at Lotusphere in 2003 on Progressive Disclosure. (I must admit, I didn't know anybody was paying attention, but last year a customer showed me an application where they use this technique for hints on training material.) This is a no code (absolutely none) approach to providing extended information on successive clicks.
 
Inline GIF image
 
The trick is to use a "programmatic" table which shows one line at a time and advances when it is clicked. See below for the document in edit mode. Each of the bullet items has two or three rows. It is important that the early part is duplicated, but you could add images or links or anything as you go on.
 
Inline JPEG image
 
In case that still isn't clear enough, I turned the cell borders on for that first table and showed the properties where you set the AdvanceOnClick.
 
Inline JPEG image
 
There are a lot of ways to use this technique, such as having information in three or four languages and letting people switch through. Anybody can create one without designer or anything else, just a bit of patience and effort and creativity. No code is involved, so nothing needs to be signed and ACLs don't come into play. and yes, it will work on all those mobile device that support Nomad or whatever it is called these days. Anybody can use it in read mode.
 
Of course, there's always a gotcha.
 
*** NOTE: This is where the Genii Software stuff comes in, so if you just want the ideas above, you can stop reading now.
 
While it is great that this works on mobile devices using Notes code, that doesn't help the rest of the world when it comes to a normal web browser. Sadly, this logic doesn't transfer through if you use Domino HTPP. Worse, it doesn't even flatten out the table so you can see all the rows, it just shows the first. But that is where our Midas engine helps.
 
Inline GIF image
 
 
The Midas engine that supports this works in the Midas LSX, the Midas C++ API, AppsFidelity, as well as CoexLinks Migrate and AppsFidelity Migrate. So you can have your fancy no code solution and take it on the road as well.

Copyright © 2019 Genii Software Ltd.

Tags:

Mon 12 Aug 2019, 06:13 PM
Over the next few posts, I hope to show some different features of Notes/Domino which actual customers use, both to suggest things you may not have thought of, and to highlight (after the fold) where our software is important even with these native applications.
 
This first comes from an application a customer developed with the lowest of low code. They created a form and a view to show a visual representation of various gauges and settings. They used a combination of numeric fields driven by @DbLookup and computed color fields.
 
Color fields? Yeah, I don't use them often myself, but if you create them as editable, they allow you to select a color and then show the color. They store the value as an eight character text value with the first two character always 00 and the next six a hex color string as used on the web. So, red would be "00FF0000". Well, these clever people decided to use calculations about how far these gauges were from whatever normal was, and showed the value as a color by shifting up and down the red and green values. Simple formula langauge. No LotusScript even. On a good day, the results might look like this. (I can't show what their actual gauges are measuring, so I pretended it was high water measured at various places.
 
Inline JPEG image
 
 
The bottom color is somehow calculated from the average differential. The field definition looks like this. They just played with the size of the field to make it stand out.
 
Inline JPEG image
 
So, yes, a series of color fields. You could do something similar with a table and computed table cell images, but there are two reasons they didn't. The first is that they would have need a whole slew of images since there are technically 510 possible values (255 for red and 255 for green, though it turns out there are only really 256 rational possibilities). The second is that when the gauges look bad, they email them. Imagine that one day, they saw this. 
 
Inline JPEG image
 
Well, that doesn't look very good, so they just do Action - Forward and send the results and a note to the relevant people. Mind you, there might be other ways, but this is a very low code system that works in Notes right now, and would work even on the iPad or whatever if that is where you wanted to run it. The low code you already know.
 
So, anyway, they email it like this:
 
Inline JPEG image
 
For a while, this worked perfectly. But then one of the people they sent it to went on vacation and forwarded her email.
 
*** NOTE: This is where the Genii Software stuff comes in, so if you just want the ideas above, you can stop reading now.
 
Let's assume that her mail was forwarded to a Gmail account. The results were less than ideal.
 
Inline JPEG image
 
That doesn't exactly communicate the same way, does it? It perhaps makes the point that this isn't an accessible solution, but that's a different topic. Anyway, perhaps the mail could have been forwarded to Outlook365 instead. Then she would have seen:
 
Inline JPEG image
 
Which is no better.  This is where our CoexLinks Fidelity software comes in. Let's send the same email with CoexLinks Fidelity enabled on the server. First, to Gmail:
 
Inline JPEG image 
 
That gets the point across! It even includes the background waves, though they aren't particularly important. So, next to Outlook 365:
 
Inline JPEG image
 
As often happens, Outlook doesn't support even as much as Gmail does, and both support less than Notes/Domino does. But still, the only loss is the background image.
 
The take away is that we have a powerful low code system already in place. But that means you don't know what applications are out there creating content and using email. You don't have to know. And if you (as a system administrator) don't want to hear complaints, you'll get CoexLinks Fidelity to handle whatever weird low code creations there are so you can stay busy with more important stuff.
 
 
 

Copyright © 2019 Genii Software Ltd.

Tags: