(long) Transparent IDE elements and other problems

[Frank Leahy]

On Saturday, March 27, 2004, at 01:26  PM, 
use-revolution-request at lists.runrev.com wrote:

>
>> Anyway, the biggest problem I've come across so far is that a group
>> can be at most 32000 pixels high, which effectively limits my "slides
>> plus EXIF" template to 137 templates stacked vertically.  Really
>> there's no reason RunRev shouldn't be able to support multi-thousands
>> of images on screen simultaneously so that one need not resort to
>> hokey hacks to display large amounts of data.
>
> FWIW- I don't really want to argue for either method here, but it's not
> really a hokey hack. Most modern list managers, spreadsheets, and
> anything else that wants to display a lot of data pages the data
> through a fixed number of elements in some fashion: you'd be in a lot
> of trouble if your database manager loaded 2 millions rows to be
> prepared for your scrolling... so while it may work for your
> application, paging data and "faking out" the user is actually more
> like standard memory-saving practice.
>
> - Brian
>

There's really no reason why this couldn't be handled by Revolution as 
it currently exists.  Imagine being able to create a scrolling group of 
very lightweight objects (probably just id and rect are all you need).  
Then as objects are scrolled into and out of view, Revolution would 
tell you to render them or de-render them.  It already knows which of 
my groups are on and off screen, and if there were "Render()"  and a 
"De-render()" methods (or Show() and Hide() or whatever you want to 
call them...) that I could override then I could do what you're 
suggesting without having to resort to hokey hacks.

> And with respect to interface design, what is the limit of information
> to be presented to the user?  Sooner or later, the number of images is
> going to reach a point that interferes with usability, on several
> fronts: the thumbnails will be too small to be recognizable, the number
> of images will confuse and overwhelm the user, etc.  The development
> and design questions we ask ourselves (or should ask ourselves, anyway)
> every day address these issues.  How do we balance the power of the
> application with the usability of the interface?
>
> J.

I see no reason to create an artificial barrier to someone who wants to 
add 1000 or more photos to an album in my product (and what max would 
you pick if it were your product?).  As it is I have an iPhoto library 
with 3000 pictures in it, and I find it very usable.  And the only 
reason it doesn't have more is that iPhoto bogs down with about 3000 
pictures and I haven't sprung for the next version in which the problem 
is apparently fixed.

But speaking of numbers and UI problems:  Is there a problem with a 
Word document with 200 pages in it?  Or an email program with 10,000 
saved messages in it?  Or a weblog with 100 entries?  Or a HyperCard 
stack with 10,000 cards in it?  Or an address book with 600 addresses?  
I have all those things and have no problems with the UI of any of 
those programs.  And I hope I've done a reasonable job with the UI of 
this photo album product such that large numbers of photos in an album 
are also not going to be a problem.

Now if there weren't that 32000 pixel limit on scrolling groups...

-- Frank