On 1/18/2022 3:18 AM, Martin Brown wrote:
> On 18/01/2022 00:35, Don Y wrote:
>> [Not exactly, but close enough, semantically.]
>>
>> I'm starting to design the application to "read" programs to
>> visually impaired users/authors (legally blind, macular
>> degeneration, diabetic retinopathy, etc.). In general, it's
>> a simple problem (given a formal grammar for the language).
>
> There are some interesting gotchas lurking in the undergrowth. Back in the bad
> old days when variable names had very limited length it was not uncommon to zap
> the vowels out of variable names. This works OK in your own native language but
> gets confusing when it isn't.
As there are no rules for how a developer (note that YOU may not have written
the applet that you are trying to read/comprehend/maintain) picks variable
names, it seems silly to give much flexibility, in this regard. Imagine
having to hear "pUID" spelled out, each time it is encountered in a code
snippet. Or, worse, hear it *pronounced* ("What the hell is a 'pewid'?")
Finally, consider the effort of having to *type* it each time -- and ensure
you haven't MIStyped it. (e.g., my "keyboard" loves to type "teh", for "the")
As applets are intended to be short ("page"), I question the need for many
variables/identifiers; if you want to do something "bigger", write two
or more and let them talk to each other (in some meaningful way).
If you intentionally limit the number of identifier, then you can "regress"
to the days of single character names which makes typing and reading easier.
(you can add a dictionary that maps those single characters to more meaningful
names IN A SINGLE PLACE; this makes it easier to understand what you've written
as those meaningful names could automagically be substituted for the
abbreviations when the text is read back to you)
[Yes, it's not ideal but the thing about *all* AT is that none of it is ideal!]
> I first ran into it in French where stars were abbreviated TL. (eToiLe)
>
> Variable names that are essentially unpronouceable will be an issue and the
> more awkward ones might have to be spelt out.
>
>> The problem is deciding how much detail to convey, audibly.
>> Remembering that the user/author needs to be able to determine
>> how the compiler will treat (or *has* treated) his code.
>>
>> E.g., the simplest approach is to read all identifiers
>> (deciding on an algorithm to make those unpronounceable
>> ones pronounceable!) and punctuation. This provides *all*
>> of the information that the compiler will see (act on) so a
>> practiced user can recognize incorrect/missing/absent syntax.
>
> Punctuation like ";", ",", ".", and ":" have significance beyond being mere
> punctuation in some computer languages. Likewise other escape sequences and
> operators "||" vs "|", "*" and "&" in C for example.
Yes. So, you eliminate them or replace them with alternatives.
How often do you use '|' and '&' in a high-level application vs.
'||' and '&&'? Is "||" that much more "efficient" than "or"? :>
One gets the impression that language designers are lazy typists.
[Amusing to look at SQL vs. common "programming languages". I
can recall writing queries under Janus that ate up whole lines
on 132 column paper!]
I let the user define voice characteristics appropriate to their
preferences and hearing abilities. Folks with *one* disability often
have *many*. Older folks tend to have a harder time with "small heads"
as the voice manifests in a higher register (listening to a 3 yo)
There are many factors/characteristics beyond just pitch (breathiness,
tempo, etc.) that affect comprehension and "listenability".
[Listening to synthetic speech for any length of time -- regardless of
how "good" you think it is -- leaves your ears "tired" (unfortunately, I
can't think of a better word to describe it)]
>> As I suspect damn near everyone reading this is using their eyes
>> and likely has *zero* experience with a screen reader, my
>> question relies on *imagination*; imagine having someone read
>> their code to you over the phone (a common metric for readability).
>> What would make this easiest/most expeditious/least prone to
>> error/misunderstanding?
>
> I know someone who uses one. It is very clunky especially on Usenet posts where
> it reads quite a bit of eg. quotation junk. It would drive me crazy not to be
> able to flash read whole chunks at a time.
Exactly. A screen reader needs to understand the content that it
is "consuming".
How often do you encounter posts with missing attributions? Or,
mangled quote indications? Plus, folks like me who rely on *emphasis*
and /italics/ and _underline_ attributes... (what does an underline
sound like?)
>> Another option is to allow the user to selectively invoke
>> a "spell that" mode (I use this elsewhere to address sequences
>> of letters/symbols that aren't prnncbl)
>
>> Keep in mind that writing code is already tedious for such
>> a user; reading what he's written shouldn't make this (much)
>> worse!
>
> I think the next generation of personal assistants might be going in the other
> direction allowing a natural language interface to let people describe what
> they want their assistant to do for them rather than having to code in a
> primitive text based language or IFTTT.
That work for simple tasks. Imagine describing a sequence of operations
for your assistant: "When I go to bed, verify the garage door is closed.
If not, close it. Then, make sure all of the windows are secured and
blinds drawn. Finally, turn down the heat and turn off the lights -- except
for the guest bathroom if we have a guest on hand. And, if you have a problem
with any of these things, tell me -- but continue with the other items listed
(instead of stopping at the first error)"
Now, *edit* this set of instructions.
> Think a slightly more upmarket version of Alexa or Siri. Already some of the
> apps for that can be quite potent in chosen domains. Ours remembers which bins
> to put out this week far better than I can.
My approach to repetitive actions is just to let the system learn by
observation. E.g., Send all calls from Bob, after 9PM, to voice mail.
Open the curtains just prior to the time that I normally arise.
Turn on the bathroom light if you see me get out of bed to visit
the head; turn it off when I return to bed. If I took a sh*t, turn
on the exhaust fan for 5 minutes -- and remember to turn it off,
thereafter.