On 3/6/21 2:01 am, Don Y wrote:
> On 6/2/2021 5:39 AM, Clifford Heath wrote:
>> No-one. Certainly not me. But you've said you're effectively retiring.
>> To me that means you don't have to "deliver a result" any more.

> OTOH, if "everyone" was expressing designs in some particular
> structured form, then it would have value to THEM (and thus, to me)
> if I invested the time to learn enough to be able to translate
> my existing designs into such form.

See my comment on SysML at the bottom.

> My "legacy" is the products that I've defined and the people I've
> influenced.  I have no desire to immortalize myself in any of these
> things; the *things* are the legacy, not my role in their creation.

Good for you. You have my respect for your work.

For myself, I feel that demonstrating *how* I worked is potentially more
beneficial, even though many fewer people are directly impacted. I hold
the principle that it is more beneficial to invent a better shovel than
to dig another hole. So to talk with those few about *how* I did what I
did (and to ruminate on how I might have done better) is a worthwhile
activity. Not valuable to me of course, but to them and those who will
benefit from the things they create.

> E.g., I am hoping that demonstrating how you can approach a (UI) design
> differently can eliminate "ability-bias" in the way those interfaces
> are designed.

Without knowing anything about how you've done that, I suspect a lot of
it was already studied in UIMS work and implemented in products like
Apollo's "Dialog Manager" during the 1970s and 80s. We implemented many
of these ideas (along with many of my own) in our startup product OpenUI
in the 1990's... ideas which still haven't been widely adopted. Yes,
novel user interface technology was the most productive decade of my
life so far. There's plenty of room for improvement still!

It's good to explore "new" territory, but it's also good to firstly plan
the journey by studying the prior art - just in case it's not new
territory after all.

>  I have no desire to go on a "speaking circuit" to
> pitch the approach.  Few people will actually see/interact with
> my end result.

I did the speaking circuit for a few years, and I think that might be
enough for me. I don't have the motivation to become an industry
fashionista (which is all that most such people are). However, the
result is that hundreds of people are implementing some of my ideas and
spreading them to other people, especially in Europe.

> No, that's all part of *THIS* project.  Note the sheer number of "new"
> techniques/technologies that I listed.  Then, tell me I have no desire to
> explore!

Ok, fair enough! Formal methods are probably a step too far. You might
get some benefit from a brief look at SysML, which I believe is very
closely aligned to your needs. I believe SysML v2.0 was released just today.

Clifford Heath.

On 6/2/2021 6:54 PM, Clifford Heath wrote:
> On 3/6/21 2:01 am, Don Y wrote:
>> On 6/2/2021 5:39 AM, Clifford Heath wrote:
>>> No-one. Certainly not me. But you've said you're effectively retiring.
>>> To me that means you don't have to "deliver a result" any more.
>
>> OTOH, if "everyone" was expressing designs in some particular
>> structured form, then it would have value to THEM (and thus, to me)
>> if I invested the time to learn enough to be able to translate
>> my existing designs into such form.
>
> See my comment on SysML at the bottom.
>
>> My "legacy" is the products that I've defined and the people I've
>> influenced. I have no desire to immortalize myself in any of these
>> things; the *things* are the legacy, not my role in their creation.
>
> Good for you. You have my respect for your work.
>
> For myself, I feel that demonstrating *how* I worked is potentially more
> beneficial, even though many fewer people are directly impacted. I hold the
> principle that it is more beneficial to invent a better shovel than to dig
> another hole. So to talk with those few about *how* I did what I did (and to
> ruminate on how I might have done better) is a worthwhile activity. Not
> valuable to me of course, but to them and those who will benefit from the
> things they create.

I share my approaches with my colleagues -- but don't "evangelize".
They know that my "style" tends to evolve with each new project so,
possibly, they see every "discovery" as just a "latest fad"?

I let my work do the preaching. People reviewing it will likely be paying far
more attention to it than they would to an "opinion piece". And, it's
a /fait acomplis/, of sorts; there's no question as to whether it works
or how well it works -- it is concrete evidence of both.

I bumped into a colleague from a previous employer some years after I'd
left. He mentioned that he'd taken on the manufacturing support for
one of my designs. (<shrug> "OK, someone had to do so!") He went on to
offer that he was initially overwhelmed at the complexity of the circuit.
Then, quickly added, "But once I realized HOW you did things, everything
was crystal clear!" No doubt because I tend to be very consistent in
how I approach a solution (understand what I've done in one place and it
directly translates into how I did something else, elsewhere).

I try to "coerce" people following up on my efforts to adopt the same
style -- by building mechanisms that make it easier to do things LIKE
I did than to have to build something from scratch. Sometimes there's
so much "structure" in my design that it makes it impractical to "lift"
it, intact, and use it in another application without a fair bit
of rework.

[My speech synthesizers are a perfect example of this. As they have
LOTS of "const" data driving their algorithms, they load that data
from the RDBMS at runtime. And, as the RDBMS may be updated some
time (hours, days, months?) later -- WHILE THEY ARE STILL RUNNING -- they
install a trigger in the RDBMS that effectively initiates an upcall
to the synthesizer whenever those table entries are altered.
("The data on which you rely has been altered -- by SOMETHING. When
it is convenient for you to do so, you may want to refresh your
local sense of that data...") As other folks likely don't have a
similar mechanism in their applications, all of the related code has
to be elided and the appropriate const data installed in the binary
(via the source).]

Whether any of this wears off, long term, is unknown. But, I do notice an
increased use of finite automata among my colleagues, more structure
(inefficiency?) in their code, more synchronous hardware designs, etc.
So, maybe they've "matured" on their own -- or, silently taken up
some of the design approaches that I've championed, over the years.

>> E.g., I am hoping that demonstrating how you can approach a (UI) design
>> differently can eliminate "ability-bias" in the way those interfaces
>> are designed.
>
> Without knowing anything about how you've done that, I suspect a lot of it was
> already studied in UIMS work and implemented in products like Apollo's "Dialog
> Manager" during the 1970s and 80s. We implemented many of these ideas (along
> with many of my own) in our startup product OpenUI in the 1990's... ideas which
> still haven't been widely adopted. Yes, novel user interface technology was the
> most productive decade of my life so far. There's plenty of room for
> improvement still!

Most "electronic" UI's tend to rely heavily on vision. And, some sort
of dexterity (to manipulate controls). There have been numerous (bad)
attempts to retrofit assistive technology interfaces to interfaces
originally designed for "able-bodied" users. But, this after-the-fact
approach tends to be readily apparent to anyone using same.

Imagine how you'd enter text with a sip-n-puff/mouth stick. Then,
step back and ask, "Why are we asking for TEXT, here? Is there some
other way to get the information we want without resorting to that
'obvious' implementation choice?"

For example, prior to bedtime (here, my current project), the
user needs to be apprised of anything that my system can't
AUTOMATICALLY "fix" on his behalf. (e.g., I can adjust the
thermostat without his intervention -- once I realize that he
is retiring; but, I can't turn off the stovetop if he forgot to
do so, earlier... or, close any open windows, etc.)

The "obvious" way to convey this information to the user (given
that there are MANY "things" that *could* potentially need
attention, even though few actually *will*) is to display a
graphic rendering of the floorplan with "red" highlights
in those areas that need attention. A user can then just glance
at such a display and assure himself that all is well (or,
discover WHAT needs attention).

This won't work for a blind user. And, an alternative "display"
might need to be available for someone confined to a wheelchair
(e.g., I've located three such "display panels" around the house...
intended for STANDING sighted users -- out of sight/reach of
anyone wheelchair bound).

Reading off a list of "issues" could work for a blind (but *hearing*)
user. But, what order to present that list -- given that the
user is likely NOT going to be taking "written" notes? Surely,
any FIXED order has significant downsides as it would suggest the
user visit those issues in the PHYSICAL order enumerated instead
of taking into account his present location.

And, as he's not consulting a VISUAL display panel, it's silly
to assume he is located near one!

A friendlier presentation would inform him of the items needing
addressing in relationship to his current location (so, your
implementation should determine that before creating a presentation).
And, as he likely can access that information without being
present in a fixed location (which you can determine by HOW he
is accessing it -- via a fixed "display AUDIO station" or via
a wireless PORTABLE earpiece), you should "bundle" the items
needing attention into groups and summarize the AREAS needing
attention and rely on the user to move to an area that he finds
convenient, before expanding on the report that you have
for THAT area.

And, you wouldn't want to bother *either* user with "conditions"
that you've grown to know are "normal" for THEIR usage (e.g.,
we sleep with windows open most of the year so don't alarm on
those issues).

You can't effectively "bolt on" this sort of interface to
one that was originally designed for sighted users; it's a
significant chore (and would have to be done for EVERY
"visual presentation) which means it simply doesn't get done.

Or, is done in some kludgey manner ("Let's let the user
scan the visual display and INSPECT each area...")

The developer who thinks in visual terms won't even consider
these other options in the design of his implementation.

And, an implementation that expects to tackle it with
*explicit*, developer defined mechanisms like:

case (interface_type) {
visual =>
video->display(annotated_floor_plan());
audible =>
audio->display(list_problem_areas());
haptic =>
haptic->display(problems());
* =>
// panic
}

just invites folks to skimp on some implementations ("interface_types")
as well as omit those that they can't sort out (easily) at design time.

> It's good to explore "new" territory, but it's also good to firstly plan the
> journey by studying the prior art - just in case it's not new territory after all.
>
>> I have no desire to go on a "speaking circuit" to
>> pitch the approach. Few people will actually see/interact with
>> my end result.
>
> I did the speaking circuit for a few years, and I think that might be enough
> for me. I don't have the motivation to become an industry fashionista (which is
> all that most such people are). However, the result is that hundreds of people
> are implementing some of my ideas and spreading them to other people,
> especially in Europe.