horizontal and vertical scrolling

Timothy Miller gandalf at doctorTimothyMiller.com
Wed Jun 15 20:12:06 EDT 2011


Hi Bob,

I think I understand your arguments. I'm not convinced, though.

If you had a complicated nest of scrolling fields, scrolling cards, scrolling backgrounds and a scrolling stack, you'd really have a mess. Inexperienced authors (are they still called "authors"?) would have to be warned against making such messes.

LC sort of maintains the original "card" metaphor... And sort of doesn't.

I can think of cases where a scrolling card or a scrolling stack would be useful and rational. In many cases, these would be unnecessary or pointless. In the same way, a scrolling group is useful and rational sometimes, and sometimes not.

This doesn't need to be a big debate. It's probably not very important or interesting. I was just kind of wondering.

I'm guessing native scrollbars in groups -- but not cards or stacks, -- was an ad-hoc compromise made early in the hyperCard years, that just got carried along ever since. I've guessed wrong before, though.

Cheers,

Tim



On Jun 15, 2011, at 4:28 PM, Bob Sneidar wrote:

> I think there is. You can see how certain kinds of fields would need to scroll, where other fields do not. Fields are more akin to windows than any other LC object. I suppose you could think of a card that way, but the card and stack of cards allegory lends itself to some fixed size. If the whole world be an ocean, they why do I have legs? If everything can scroll, then why use cards at all? Why not just float a group of objects out there? 
> 
> Also, many applications have some kind of background that is a fixed size and/or pattern. Typically you want that whole background visible. Fixed discernible boundaries within which things can change is much more mentally comfortable to the human psyche in my opinion. We want a top and a bottom and sides. Everything else is negotiable. 
> 
> Have you ever read a report that had no header or footer, just data, or tried to view a large spreadsheet that was made that way? Put a fixed header and footer in a spreadsheet while the data in between scrolls, and your mind suddenly breathes a sigh of relief! 
> 
> Have you ever tried to remote into another computer whose monitor size was excessively small? It's irritating to constantly have to scroll the screen around to see everything. That would be annoying in an app. Web pages can be a pain that way too if improperly designed. Better to have a single frame that scrolls while everything else around it remains static, as opposed to a web page where everything scrolls, and you have to scroll all the way back up just to get to the buttons that take you somewhere else. 
> 
> A group that scrolls is the real odd duck if you ask me. But for certain kinds of interfaces, like side scrolling games, or mapping, it is really handy.
> 
> Finally, if something needs to be a fixed size, then ask yourself, if not the card, what? The card is the highest element in an interface. It's no good talking about the stack as if it were a single thing you could put other things on. The stack is just a bunch of cards. Something needs to be a fixed size upon which all other geometry can be based. Otherwise people would be tempted to make applications that were more like jello than a piece of bread. 
> 
> That is how I view it anyway. 
> 
> Bob
> 
> 
> On Jun 15, 2011, at 3:06 PM, Timothy Miller wrote:
> 
>> Hi,
>> 
>> I never thought about it before, but now I'm wondering. Is there any rational reason that native scrollbars can be enabled for fields and groups but not for cards or stacks?
>> 
>> Cheers,
>> 
>> Tim
>> 
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the use-livecode mailing list