Watching as HCL has taken over development of the ICS products, it has been encouraging to see signs of a focus not just on new features, but on follow-through with features that are already there. Sometimes, that is a commitment to fixing bugs, but sometimes it goes deeper. If HCL really wants to make these products a success again, that commitment and focus must continue. Because the fact is, IBM did just fine adding features. They listened to customers and added features for years. Where they lost their focus was on the follow-through to make sure each feature was complete and fully integrated.
Let me show an example. IBM has strongly espoused a commitment to standards, accessibility, and internationalization. Hardly surprising given its strong international customer base as well as the burgeoning regional and international requirements for accommodation of those with different disabilities. But in recent years, IBM has often added the appropriate feature but not followed through.
I) Here's the feature (language tagging for accessibility and search)
Take a look at the following seemingly identical lines:
L'eau monte au fur et à mesure de la fonte des nieges. <-- Untagged, so defaults to English as the post is in English
L'eau monte au fur et à mesure de la fonte des nieges. <-- Language tagged as 'French' using the text properties
IBM added language tagging several versions ago, and it solved a customer problem with Notes content and accessibility. Watch the video below to see the difference in how a screen reader would read this line depending on whether it is tagged as English (or defaults to it because the page is English) or tagged as French:
II) But where's the follow-through?
So, IBM has added the feature and it works well in the Notes client. But what if that same content is displayed on the web or a mobile device or sent through email? Domino completely ignores the language tagging.
Rendered by Domino HTTP. Note that there is no lang attribute on the <font> tag:
Rendered by the Midas LSX. Note the lang attribute on the second <span> tag where it belows.
But that is not the only way that IBM failed to follow through. This language tagging is only available on text inside a rich text field. You can't set it on text in a simple text field such as the subject. You can't set in anywhere in the form design. You can't even set it in the field properties so that an entire field is tagged. A very useful feature, but without the follow-through, it just leads to aggravation and workarounds and people abandoning the product.
III) Will HCL do better?
That is the multi-billion dollar question. I see positive signs, and the HCL people I talk to very much want to do better, but there are a lot of holes left and a lot of follow-through unfollowed. It is encouraging to see efforts such as the Redesigning Templates project, because that is another area where follow-through has been lacking, It is also encouraging to see HCL work with business partners and ISVs, as IBM sometimes resisted that, and this is too much to do alone.
For now, I'd encourage other business partners and developers and admins to submit ideas to HCL that are not simply new features or bug fixes, but also follow-through enhancements on accessibility, privacy, spit-and-polish, etc.
IV) Can Genii products help?
Yes and no. Language tagging support has been added to all our products, so if language is tagged it will be rendered in email by CoexLinks Fidelity, in applications by AppsFidelity, and in exports by the Midas LSX and CoexLinks Migrate. But while we can provide workarounds for some form issues, we can't add tagging to design. We can't change interface issues or make it easier to set the language for an entire document or rich text field or text field. Those things are up to HCL and up to customers and partners to request.
By the way, there are many, many other issues with accessibility. This is just an example to give an idea of where a feature is there, but with a little extra effort could be far more useful.
I don't know whether that language feature was added before HTTP and the feature was missed when HTTP was added; or whether it was added for Notes Client and HTTP was not included at the same time and never followed through. The best solution is a thorough request or a thorough impact analysis before go-ahead that considers the request from all possible angles of the platform. Unfortunately, looking at many of the feature requests on the Aha site, the former is not happening. Most are one-liners and, where they're not, some I've seen recently consider the feature from a narrow focus, not from all users. This means those investigating the feature requests need to be *extremely* knowledgeable and skilled. Maybe there is scope for a community panel. Certainly I think some requests should be fired back to the individual to give more consideration and detail before any work is done.
1106.2. Ben Langhinrichs (06/27/2019 10:16 AM)
Paul - I tend to agree that while the Aha site has a role, there needs to be a second layer of consideration which probably requires participation and feedback from experienced partners, internal developers, and some customers. Of course, all that takes time and money. It would probably be best if some major topic (e.g., accessibility) were considered as a whole by a group, and the various ideas and features were addressed together. That is one reason I like the Redesigning Templates effort. It involves the various parties and is not focused too narrowly.
