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