Practical Maximum number of fields on a card

[Richard MacLemale]

On 7/28/02 12:07 PM, Richard Gaskin wrote:

> 2000?  It's hard to imagine a UI that needs that many editable text regions.
> What are you making?
> The downsides to high object counts are RAM and hit testing. And of course
> depending on what's in those fields it may take a while to redraw.   Can't
> say I've ever put 2000 fields on a card, so I can't say for sure how
> gracefully MC would handle it.  It seems easy enough to test with a repeat
> loop creating new fields in a test stack.  Please let us know how that comes
> out.
> 
> Offhand my first hunch would be to think of a solution which would allow a
> lower object count if possible....

I'm making a gradebook.

Figure it this way - with a maximum of 50 students in a class, and a maximum
number of 50 assignments per quarter, that's 2,500 possible individual
grades.  My idea is to have those fields grouped and then add scrollbars to
scroll the group.  I've done a prototype and this approach works fine - even
with a grade entered in all 2,500 fields, and with 2,500 fields on each of
50 cards!  Scroll speed is good and it seems stable.  This is under OS X.
Essentially what I'm doing is an imitation spreadsheet with each cell being
a field.

I agree that this is an extreme number of fields for a card, which is why I
wanted to see if there were some magical number of fields per card that
should not be exceeded.

I looked at other approaches to this and I haven't thought of anything
better.  You can simulate a spreadsheet with a locked field with the lines
showing, but I wanted users to be able to easily and instantly click on any
"cell" and edit the info there.  That feature is mandatory.

Another approach would be to only show 5 or 10 columns of the "spreadsheet",
and have the user view the assignments that way, using the "page" metaphor
(this page has 10 columns, turn the page, the next page has 10 columns,
etc.)  The data could then be stored on separate cards, or in a separate
stack, or in a text file, or even right there in the fields, but then the
user has to "page" through their gradebook.  I really wanted to stick to the
idea of being able to see and scroll through a whole quarter in one
scrollable field.  Other gradebooks can do it and it is expected.

Like I said, the prototype is working fine under OS X.  I have launched it
under Classic, and it runs fine there, too, but I can't tell how much RAM
it's using until I try it out on an actual OS 9 Mac.

If MetaCard had a spreadsheet object, I'd just use that.  But using a field
to pretend it's a spreadsheet is not the same because you can't interact
with it in the exact same way.  This prototype is working fine, but I wanted
to know if there were theoretical maximums I was ignoring...


-- 
:)
Richard MacLemale
Network Administrator
J. W. Mitchell High School