Geoff Canyon wrote:
> On Fri, Nov 23, 2018 at 4:38 PM Richard Gaskin wrote:
>
>> Geoff Canyon wrote:
>>
>> > It's not relevant to the current discussion, but waaaay back when,
>> > I worked with a guy who had created some monster spreadsheets in
>> > Excel with something like 9,000 columns. It was working, but it was
>> > incredibly slow -- this was running on 68k Macs. Not expecting
>> > success, I suggested he give FileMaker a shot. He did, and
>> > amazingly, not only did it happily handle database definitions with
>> > 9,000 fields, it was not just faster than Excel, it was actually
>> > speedy. It had zero problems, and he built out the entirety of his
>> > solution that way.
>>
>> Did he create a layout in FileMaker with 9,000 fields?
>>
>> If he had I suspect it would expose the root of the issue as being
>> not so much about internal handling of the data, but about rendering
>> it all.
>>
>> One more reason to remember that spreadsheets are not databases.
>> Very different tools with very different feature focuses and
>> tradeoffs.
>
> I don't remember what-all he did with it, but FileMaker proved to be
> remarkably resilient pretty much no matter what he threw at it.
Interesting, but alas missed what I was trying to convey which is
relevant for us LC folks:
Plenty of tools can put data in memory. Easy to do; most will do it well.
The challenge is in also *rendering* all of it on screen.
As we consider our options for work in LiveCode, it can be helpful to
think about the implications of rendering, both in technical terms and
for the user experience.
Technically, rendering is computationally expensive. Indeed, it's
infinitely more expensive than not rendering. :) So any time we have
more data than can be rendered efficiently, we might ask ourselves if we
really need to render all of it.
And this leads us to the user experience: we render data where doing so
has value to the user. Everything that doesn't benefit the user has no
place on the user's screen; it becomes just noise, effectively an
anti-feature.
What meaningful task is a user expected to perform with many thousands
of columns rendered on screen? How could it even be cognitively
possible for a human to perform such tasks with any useful efficiency?
The answer would of course depend on the task in question. But as a
general rule, it may be safe to consider that if the user has to scroll
horizontally more than the width of the room they're sitting in, it
might be time to explore a simpler design that culls the noise for them
and lets them see the smaller subset of data they're actually looking
for more easily.
Furthering awareness of both of these aspects, technical and UX, we come
back to the original issue cited in this thread, with LC sometimes not
correctly rendering uncommonly large numbers of columns.
This limitation may have been eliminated, or close to eliminated, with
the field object. And now that fields have column-independent
alignment, it's rare that there's ever a need to replace that one object
with a thousand-object DataGrid for simple list views.
The DataGrid is bound to a limitation within LC for group contents: the
formattedWidth and formattedHeight of a group cannot exceed 32765 px.
Attempting to go beyond that flips the signed bit internally and objects
will be rendered incorrectly.
I suppose it might be nice to see that extended, but in practice do we
really need it? How big should a group meaningfully be?
32,765 px is about 30 feet in size. That's a lot to ask a user to
scroll through, not to mention being a lot to ask LC to buffer so it can
handle the scroll efficiently.
When we're faced with such monstrous scrolling requirements imposed on
our users, a technical limitation in the engine may not be a bad thing
at all. It may turn out to be the prompting we need to re-think our
designs to deliver a more useful and fluid user experience.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
