On 16/5/21 5:35 pm, Don Y wrote:
> On 5/15/2021 6:41 PM, Clifford Heath wrote:
>> On 16/5/21 5:26 am, Don Y wrote:
>>> On 5/15/2021 3:54 AM, Clifford Heath wrote:
>>>> On 15/5/21 7:10 pm, Don Y wrote:
>>>>> Unfortunately, use in such a document is not suited for "general
>>>>> audiences"
>>>>
>>>> The goal of CQL is to make the formal model suitable for (and
>>>> expressed in the language of) anyone generally familiar with the
>>>> domain being modelled.
>>>> Actually rationale is seldom needed. What is needed is an example of
>>>> the scenario that is allowed or disallowed by each definition. The
>>>> example is almost always an adequate rationalisation.
>>>
>>> I disagree.  I find many cases where I need to resort to prose to
>>> explain why THIS implementation choice is better than THAT.
>>
>> Yes, where that is needed, CQL provides context-notes too. In fact I
>> select four specific categories of rationale ("so that", "because",
>> "as opposed to" and "to avoid"), with optional annotations saying who
>> agreed and when.
>
> I present my descriptions in "multimedia prose" so I can illustrate
> (and animate) to better convey the intent.

All that is needed is to allow the viewer to get to the "Aha!" moment
where they see why the alternative will fail. Do whatever you have to do
to achieve that, and you have your rationale. It will vary with the
situation, and with the audience.

>> Even without verification, the model must only make rules that are *in
>> principle* machine-verifiable. If a rule is not verifiable, it's just
>> waffle with no single logical meaning. If it has a single logical
>> meaning, it is in principle machine-verifiable.
>
> Yes.  But *getting* such a tool (or requiring its existence before adopting
> a model strategy) can be prohibitive.
>> There's always a possibility for more detail in any real-world system.

>>>>> Again, why the resistance to adopting such a "codified" approach?
>>>> Hubris, mostly. People genuinely don't see the need until enough
>>>> experience has humbled them, and by then, their accumulated caution
>>>> and tentativeness mean their industry sees them as dinosaurs.
>>>
>>> "Hubris" suggests overconfidence (in their abilities).  I'm not sure
>>> that's the case.
>>>
>>> I started looking for a "common ground" in which I could express my
>>> current design when I "discovered" that, not only is there no such thing,
>
> You've missed the point.  I was addressing the point that modeling, itself,
> is relatively uncommon (at least in "these circles").  So, trying to find
> some common subset that everyone (most practitioners) were using was
> pointless.
>
> If no one speaks Esperanto, then it is foolish to present your
> documentation *in* Esperanto!

In relation to software, at least, every modeling language has been a
private language shared only (or mainly) by systems architects. They're
all Esperanto, of one kind or another. (ER diagramming has sometimes
been useful, and occasionally even UML, but usually not)

As such, it serves only for documenting the system *as designed*, and
can provide no help to a non-expert in identifying flaws where the
result would not match the need (as opposed to not working correctly
within its own frame of reference).

Because "modelling" has always been subject to this failure, it is seen
as a pointless exercise. Delivered software is likely to work "as
designed" yet still mis-match the problem because the design was
mis-targeted, whether it was modelled or was not.

The solution to this is good modelling tools that can communicate to
*everyone*, not just to programmers. And that's what I spent a decade
trying to build.

> When I approached my colleagues re: this topic, no one tried to
> defend their current practices.  I think they all realize they
> *could* be doing things "better".  This led to my contemplation of
> why they *aren't* moving in those directions.

It's easier to "stay in town" where it's comfortable, than to go
exploring in the wilderness. It's wilderness because there is no
adoption, and there's no adoption not because no-one has been there, but
because they didn't build roads and towns there yet.

>> I know a number of companies that implement "10% time",
> Yes, but 10% of 40 hours isn't a helluvalot of time.

Half a day a week seems like quite a lot to me. If an employee doing
that can't prove to me that they've discovered something worthy of a
bigger investment, then I don't believe they have.

At one company, I spent 18 months trying to evangelise the business need
for a new technology I'd envisaged. Eventually someone told my manager
"just give him 2 weeks to prototype it!", and I did. The effect was
astounding - the entire company (110 people) dropped everything else
they were doing to work on producing a new product based on my idea.
That product brought in well over a hundred million dollars over the
next decade.

>> I look forward to hearing of your experiences with TLA+, Alloy, or CQL.
>> I promise that it will be worth your effort.
>
> It's unlikely that I will try any of them!  This is my last "electronics"
> project (50 years in a field seems like "enough"; time to pursue OTHER
> interests!)

And that is why I'm sometimes reluctant to engage in these conversations
with you, Don. You're the one asking "why does nobody try this", but
even now you have time to explore (without the demands of delivering a
result), you're unwilling to do more than talk about that.

Clifford Heath.

On 6/1/2021 7:03 PM, Clifford Heath wrote:
> On 16/5/21 5:35 pm, Don Y wrote:
>> On 5/15/2021 6:41 PM, Clifford Heath wrote:
>>> On 16/5/21 5:26 am, Don Y wrote:
>>>> On 5/15/2021 3:54 AM, Clifford Heath wrote:
>>>>> On 15/5/21 7:10 pm, Don Y wrote:
>>>>>> Unfortunately, use in such a document is not suited for "general audiences"
>>>>>
>>>>> The goal of CQL is to make the formal model suitable for (and expressed in
>>>>> the language of) anyone generally familiar with the domain being modelled.
>>>>> Actually rationale is seldom needed. What is needed is an example of the
>>>>> scenario that is allowed or disallowed by each definition. The example is
>>>>> almost always an adequate rationalisation.
>>>>
>>>> I disagree. I find many cases where I need to resort to prose to
>>>> explain why THIS implementation choice is better than THAT.
>>>
>>> Yes, where that is needed, CQL provides context-notes too. In fact I select
>>> four specific categories of rationale ("so that", "because", "as opposed to"
>>> and "to avoid"), with optional annotations saying who agreed and when.
>>
>> I present my descriptions in "multimedia prose" so I can illustrate
>> (and animate) to better convey the intent.
>
> All that is needed is to allow the viewer to get to the "Aha!" moment where
> they see why the alternative will fail. Do whatever you have to do to achieve
> that, and you have your rationale. It will vary with the situation, and with
> the audience.

I've found that people tend to "lack imagination" when it comes to
things in which they aren't DEEPLY invested. They often fail to
see ("go looking for") aspects of a design that aren't superficially
obvious. This evidenced by how many folks only test their designs
with inputs they EXPECT to encounter (instead of imagining the larger
set of inputs *possible*).

So, I try to develop "interactions" that let the "reader" see what
I'm trying to illustrate -- and, then, coach them into pondering
"what ifs" that they've NOT likely imagined and show how those
win/fail in different alternatives.

With interactive presentations, I can literally tell them to "do X"
and know that (if they do), the presentation will clearly show
the issue that I would, otherwise, find tedious to explain in prose.

>>>>>> Again, why the resistance to adopting such a "codified" approach?
>>>>> Hubris, mostly. People genuinely don't see the need until enough
>>>>> experience has humbled them, and by then, their accumulated caution and
>>>>> tentativeness mean their industry sees them as dinosaurs.
>>>>
>>>> "Hubris" suggests overconfidence (in their abilities). I'm not sure
>>>> that's the case.
>>>>
>>>> I started looking for a "common ground" in which I could express my current
>>>> design when I "discovered" that, not only is there no such thing,
>>
>> You've missed the point. I was addressing the point that modeling, itself,
>> is relatively uncommon (at least in "these circles"). So, trying to find
>> some common subset that everyone (most practitioners) were using was
>> pointless.
>>
>> If no one speaks Esperanto, then it is foolish to present your documentation
>> *in* Esperanto!
>
> In relation to software, at least, every modeling language has been a private
> language shared only (or mainly) by systems architects. They're all Esperanto,
> of one kind or another. (ER diagramming has sometimes been useful, and
> occasionally even UML, but usually not)
>
> As such, it serves only for documenting the system *as designed*, and can

That's exactly my goal. I'm looking to "translate" my design into
form(s) that may be more easily recognizable -- to some "significant"
group of readers.

For example, one can design a grammar with totally /ad hoc/ methods.
But, presenting it a BNF goes a long way to clarifying it to "new
readers" -- regardless of how it came about (or was implemented).

> provide no help to a non-expert in identifying flaws where the result would not
> match the need (as opposed to not working correctly within its own frame of
> reference).

Different goal.

A "non-expert" reading the BNF of a grammar wouldn't be able to glean
much about how it *could* be implemented or inconsistencies in any
potential implementation. But, he *could* construct a valid sentence
with just that BNF (and not worry about how it gets parsed).

> Because "modelling" has always been subject to this failure, it is seen as a
> pointless exercise. Delivered software is likely to work "as designed" yet
> still mis-match the problem because the design was mis-targeted, whether it was
> modelled or was not.
>
> The solution to this is good modelling tools that can communicate to
> *everyone*, not just to programmers. And that's what I spent a decade trying to
> build.

You're trying to solve a different problem than I.

I agree with your points -- in *that* application domain.

>> When I approached my colleagues re: this topic, no one tried to
>> defend their current practices. I think they all realize they
>> *could* be doing things "better". This led to my contemplation of
>> why they *aren't* moving in those directions.
>
> It's easier to "stay in town" where it's comfortable, than to go exploring in
> the wilderness. It's wilderness because there is no adoption, and there's no
> adoption not because no-one has been there, but because they didn't build roads
> and towns there yet.

I don't think "ease" or "comfort" is the issue. Many of my colleagues
are involved with very novel designs and application domains. They
are almost always "treking in the wilderness".

But, they aren't likely to add additional uncertainty to their efforts
by tackling novel design techniques on top of a novel application
(or application domain). There's a limit as to how much "risk"
one can take on -- especially if you are answerable to "others"
(the folks who pay the bills).

I have historically taken on lots of "new experience" because it
was something I could fold into *my* time... I could decide to
"eat" the cost of learning a new technology "on my dime" as long
as I'd budgeted (timewise) to meat my completion estimates for
clients. *They* don't care if I move all of my development
tools to UN*X -- as long as they can support my completed
work with their *Windows* toolchains.

[I.e., I bear the cost of assuming both worlds work -- the UN*X
domain for me and the Windows domain for them]

But, others may see no point in moving to a different hosting
platform: "What's wrong with Windows?" Should I fault them for
"staying in town"?

>>> I know a number of companies that implement "10% time",
>> Yes, but 10% of 40 hours isn't a helluvalot of time.
>
> Half a day a week seems like quite a lot to me. If an employee doing that can't
> prove to me that they've discovered something worthy of a bigger investment,
> then I don't believe they have.

Four hours a week is nothing.

A colleague, many years ago, was assessing the effort for a particular
task. He made the off-hand comment: "You can't do ANYTHING in 8 hours!"
Which warranted a chuckle.

But, in hindsight, there's a sort of truism, there.

There are costs to starting and stopping activities. Folks who say
"10% of your time" are obviously TRACKING time. How much time am
I allotted to handle my daily correspondence (which may be distributed
across the day and not neatly bundled in a "lump")? How much time
for project meetings? How much time to browse trade magazines
to "keep current" with product offerings? Ditto published works?
Do I have a separate account to charge time to handle questions
from the manufacturing engineer re: my design? What if I need
to visit the toilet? Do I have an account against which to charge
my TIMEKEEPING time?

Four hours gets frittered away -- unless you start nickel and diming
your "real" projects with the time "lost" to these other incidentals.

Even with no one driving my time on a daily basis (self-employed),
it is still amazing how quickly a day "disappears". A piece of
test equipment needs repair/calibration/updating, ditto for a
piece of software, a battery in a UPS dies and a replacement needs
to be ordered -- and eventually installed. Etc.

On 2/6/21 3:23 pm, Don Y wrote:
> On 6/1/2021 7:03 PM, Clifford Heath wrote:
>> On 16/5/21 5:35 pm, Don Y wrote:
>>> On 5/15/2021 6:41 PM, Clifford Heath wrote:
>>>> Yes, where that is needed, CQL provides context-notes too >>> I present my descriptions in "multimedia prose" so I can illustrate
>>> (and animate) to better convey the intent.
>>
>> All that is needed is to allow the viewer to get to the "Aha!" moment
>> where they see why the alternative will fail. Do whatever you have to
>> do to achieve that, and you have your rationale. It will vary with the
>> situation, and with the audience.
>
> I've found that people tend to "lack imagination" when it comes to
> things in which they aren't DEEPLY invested.

It's almost always the case that a simple "if we have *that*, and *this*
happens, and we respond like *this*, this would be bad, yeah?" is enough
to cover 99% of such situations. But as I said, every case is different,
and I make no criticism of the way you do things. Anyhow, a minor point.

>> As such, it serves only for documenting the system *as designed*, and can
> That's exactly my goal.  I'm looking to "translate" my design into
> form(s) that may be more easily recognizable -- to some "significant"
> group of readers.

No worries. That's what systems architecture languages are for. They
only seem to get adopted where they're mandated though.

>> provide no help to a non-expert in identifying flaws where the result
>> would not match the need (as opposed to not working correctly within
>> its own frame of reference).
> Different goal.

Agreed. But the model I produce is *also* compilable to working code,
and can also be generated into a machine reasoning framework (program
prover or SAT solver) for formal analysis. My novel contribution is
doing that in a form of language which is comprehensible to "lay people"
without training.

>> The solution to this is good modelling tools that can communicate to
>> *everyone*, not just to programmers. And that's what I spent a decade
>> trying to build.
>
> You're trying to solve a different problem than I.
>
> I agree with your points -- in *that* application domain.

Every problem in every domain must be defined before it can be solved.
If the definition is not understood by those who have to live with the
solution, then it *will* be mis-defined. That is the sad fact behind the
software industry's dismal record.

> I don't think "ease" or "comfort" is the issue.  Many of my colleagues
> are involved with very novel designs and application domains.  They
> are almost always "treking in the wilderness".
>
> But, they aren't likely to add additional uncertainty to their efforts

And there's the nub. They see these "unproven" technologies as adding
uncertainty, where the reality is that they exist to *reduce
uncertainty. The truth? They're afraid the formal analysis will show
everyone how wrong they are, and have always been.

>>>> I look forward to hearing of your experiences with TLA+, Alloy, or CQL.
>>>> I promise that it will be worth your effort.
>>>
>>> It's unlikely that I will try any of them!  This is my last
>>> "electronics"
>>> project (50 years in a field seems like "enough"; time to pursue OTHER
>>> interests!)
>>
>> And that is why I'm sometimes reluctant to engage in these
>> conversations with you, Don. You're the one asking "why does nobody
>> try this", but even now you
>
> You've misread my intent.  I am not ACCUSING anyone.  Rather, I am
> trying to
> see how people have AVOIDED "doing this".  How are folks designing
> products if
> they aren't writing specifications, modeling behaviors, quantifying market
> requirements, etc.?  (if they ARE doing those things, then WHICH are they
> doing??)

Good question. I agree with your thoughts. But that has nothing to do
with what I was getting at.

>> have time to explore (without the demands of delivering a result), you're
> Who says I don't have to "deliver a result"?
>> unwilling to do more than talk about that.
> Who says I've not "ventured into the uncharted wilderness"?

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.
But it also means that you can take even more time to explore, if you
like to go even further from the well-trodden paths, so I suggested a
few interesting paths that you might like to explore in your dotage.
Perhaps learn something that you could communicate to help less
experienced folk. So I was a bit surprised when you said you were
unlikely to do that.

Instead you blather on about the many things in your past. Guess what?
Lots of us have many varied experiences in our past. You'd be surprised
how widely my interests have strayed off the beaten tracks - I'm also a
life-long explorer. But this is not about me, or about you, it's about
how the industries we work in could do even better than we could, and
what we could yet learn to help them do that. I'd still like to add to
my legacy, and I hope you would too.

Not just raise a long discussion leading to interesting areas to
explore, then announce that it was all useless because you don't intend
to explore any more.

> All of these are "wilderness" areas.  All of them took time to research,
> implement and evaluate.
>
> So, I guess I have a different idea of "having time to explore" than
> you do!

But that was all in the past. Apparently you no longer have the desire
to explore. That seems to be what you said anyhow. Correct me if I've
misread that:

> "It's unlikely that I will try any of them! This is my last
> "electronics" project (50 years in a field seems like "enough""

Clifford Heath

On 6/2/2021 5:39 AM, Clifford Heath wrote:

>> I don't think "ease" or "comfort" is the issue. Many of my colleagues
>> are involved with very novel designs and application domains. They
>> are almost always "treking in the wilderness".
>>
>> But, they aren't likely to add additional uncertainty to their efforts
>
> And there's the nub. They see these "unproven" technologies as adding
> uncertainty, where the reality is that they exist to *reduce uncertainty. The

They can only *potentially* "reduce uncertainty" after they are understood
and "mastered" (to whatever degree). A new language, for example, may
increase their coding efficiency or accuracy -- but, the effort to
become proficient with it is an added (and unknown) "cost".... that the
current project (and deadlines/commitments) will have to bear.

If you have "down time" (and motivation!) between projects, you can
explore new technologies. If, instead, you are moving from one
crunch to the next, you have to decide how much "risk" you want to
add to your current/next undertaking; your boss/client isn't
likely going to "give you credit" for taking on something that
*he* doesn't see as necessary.

> truth? They're afraid the formal analysis will show everyone how wrong they
> are, and have always been.
>
>>>>> I look forward to hearing of your experiences with TLA+, Alloy, or CQL.
>>>>> I promise that it will be worth your effort.
>>>>
>>>> It's unlikely that I will try any of them! This is my last "electronics"
>>>> project (50 years in a field seems like "enough"; time to pursue OTHER
>>>> interests!)
>>>
>>> And that is why I'm sometimes reluctant to engage in these conversations
>>> with you, Don. You're the one asking "why does nobody try this", but even
>>> now you
>>
>> You've misread my intent. I am not ACCUSING anyone. Rather, I am trying to
>> see how people have AVOIDED "doing this". How are folks designing products if
>> they aren't writing specifications, modeling behaviors, quantifying market
>> requirements, etc.? (if they ARE doing those things, then WHICH are they
>> doing??)
>
> Good question. I agree with your thoughts. But that has nothing to do with what
> I was getting at.
>
>>> have time to explore (without the demands of delivering a result), you're
>> Who says I don't have to "deliver a result"?
>>> unwilling to do more than talk about that.
>> Who says I've not "ventured into the uncharted wilderness"?
>
> 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.

I don't have to deliver a result *after* this project -- which I
consider to be my last in this area. But, I'd not have invested
a few hundred kilobucks in something just to piss away time and
money! If I just wanted to "entertain myself", I could watch
a helluvalot of movies for that kind of money!

> But it also means that you can take even more time to explore, if you like to
> go even further from the well-trodden paths, so I suggested a few interesting
> paths that you might like to explore in your dotage. Perhaps learn something
> that you could communicate to help less experienced folk. So I was a bit
> surprised when you said you were unlikely to do that.

For the "risk" reasons outlined above, I see no value (to me) in
taking on yet-another "wilderness" issue. I've added enough
uncertainty to my current effort (have I anticipated every way that
the hardware can be subverted? have I anticipated every way that a
malicious "program" can interfere with benign applications? Have
I chosen components that will STILL be available at the time it all
comes together? Should I have run CAT6 instead of CAT5e? Will
vision technology advance enough to make it more practical in
tracking subjects? ...) So, any additional risk has to yield
tangible short-term reward. E.g., developing the process migration
mechanism gives me an "out" if I find myself in need of more resources
(MIPS/memory) for some particular activity -- just power up another
node and move some of the load onto it!

And, design methodologies aren't likely to be of help to me AFTER
this project (as I want to pursue other interests) so it's an investment
with no LONG-term payoff.

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.

> Instead you blather on about the many things in your past.

I use examples from my past to explain/justify/rationalize
approaches I've used/avoided as well as constraints with
which I've had to live.

I suspect most of my colleagues use THEIR pasts similarly.

None of our FUTURES are known so pointless to "blather on"
about those!

> Guess what? Lots of
> us have many varied experiences in our past. You'd be surprised how widely my
> interests have strayed off the beaten tracks - I'm also a life-long explorer.
> But this is not about me, or about you, it's about how the industries we work
> in could do even better than we could, and what we could yet learn to help them
> do that. I'd still like to add to my legacy, and I hope you would too.

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.

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. I have no desire to go on a "speaking circuit" to
pitch the approach. Few people will actually see/interact with
my end result. But, if it causes them to think A LITTLE about
their UIs, then it will have made a mark (contribution).

> Not just raise a long discussion leading to interesting areas to explore, then
> announce that it was all useless because you don't intend to explore any more.
>
>> All of these are "wilderness" areas. All of them took time to research,
>> implement and evaluate.
>>
>> So, I guess I have a different idea of "having time to explore" than
>> you do!
>
> But that was all in the past. Apparently you no longer have the desire to
> explore. That seems to be what you said anyhow. Correct me if I've misread that:

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!

The verdict is still out as to how well my redundancy mechanisms will work
IN REAL LIFE. The verdict is still out as to how well my speech synthesizers
will perform when confronted with some yet-to-be-conceived string of
characters. Or, how well my hardware will survive a *real* "attack" -- ditto
for the software. How will my speaker identification software fare when it
encounters someone with a severe case of laryngitis? Or, as those voices
naturally "age"? Will others be able to get the information they need from
the documentation I've prepared?

So, while I have attempted to tackle each of these "wilderness issues",
I still have no idea as to which, if any, will work IN PRACTICE as
well as what the shortcomings of those that miss their mark will likely be.
I'll BEGIN to know that when all of the technologies have been implemented
and deployed. As with any project, those things only are truly understandable
AFTER the project is complete.

In *my* case, that will just be an intellectual exercise as my NEW
activities won't (likely) directly benefit from those past.

> > "It's unlikely that I will try any of them! This is my last
> > "electronics" project (50 years in a field seems like "enough""

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.