Windows startup issue
Richard Gaskin
ambassador at fourthworld.com
Tue Nov 10 16:28:55 EST 2020
Yes, I had my part of the code handy from my custom error handling.
But at the time it seemed to me the tool was for edge cases where one
might encounter raw error data with no UI. It never occurred to me to
ship an application without error handling, and back then I'd never used
LC's so I just assumed it was at least as good as my own.
Since then I've learned that providing any UI for error handling at all
is turned OFF by default.
Off.
As in, "Let's make providing a near-useless solution the thing we guide
new developers to deliver to their customers."
I was brainstorming with Mark Wieder a few weeks ago about adding static
analysis to IDE error reporting, aiming for something closer to the
helpful guidance Clang provides. Even if we did little more than show
the var values causing something to trip up, it would save tremendous
time. Aiming higher seems useful. Other tools are getting better all the
time.
And that's for just the IDE. If LC devs are comfortable with
state-of-the-art-circa-2003, what we have in the IDE is at least adequate.
For end-users, though, that's where we really want to shine. It's where
we NEED to shine.
We want new devs picking up LC to look like heroes, and to deliver that
high-quality experience with less effort than they'd put in with other
tools.
That's the point. That's why we use LC.
If we can't do that, why are we here?
Everything is undergoing perpetual change. With products there's new
customer acquisition on the one side, and attrition on the other. As
long as change is happening, why not direct some of it? Why not aim a
little higher, to reduce attrition while attracting new users? Sure,
we'd all like to see that happen, but a hundred paper cuts unattended
undermine that goal.
And as paper cuts go, error handling cuts deep. It only happen when
something went wrong. It's an especially sensitive moment in the user
journey. We can either lose the user's trust, or retain it. So much
about the confidence end-users have in our work hinges on how we handle
when things go wrong.
Why not aim higher than the least useful experience?
Or to put this more clearly:
254,11,34
301,2,43
262,67,1
12,22,1
132,1,44
73,68,1
241,67,1
353,0,0
433,2,0
201,0,0
88,3,22
322,4,20
568,22,0
--
Richard Gaskin
Fourth World Systems
J. Landman Gay wrote:
> On 11/10/20 1:14 AM, Richard Gaskin via use-livecode wrote:
>> J. Landman Gay wrote:
>>
>> > On 11/9/20 3:54 PM, Richard Gaskin via use-livecode wrote:
>> >> And WTH happened to LC's error reporting dialog?
>> >
>> > Standalones have always reported this way on both desktop and mobile.
>> > It is up to the developer to include the translated references if
>> > they want to see those. Generally I don't bother, I provide the
>> > optional built-in ability to send email to support or save a file.
>> > I can translate the numbers myself since the meanings usually mean
>> > nothing to the end-user anyway.
>>
>> I've been using my own error-reporting for so long I can't recall seeing the default standalone
>> handling.
>>
>> I have made a couple of quickies where I just used LC's error reporting, but clumsy as that
>> design is at least the output from the "Send Report" button is more useful than the raw list of
>> triplet integers. >
>> How has such ungraceful error handling become acceptable?
>>
>> Why is the least useful thing the easiest for new developers to do?
>>
>> Shouldn't it be easy for LC devs to deliver a great application experience?
>>
>
> I can't remember a time when it *didn't* report the triplets outside of the IDE. That's why you
> and I wrote the Error Lookup stack. ;)
>
> --
> Jacqueline Landman Gay | jacque at hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
More information about the use-livecode
mailing list