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 >> [email protected] >> Please visit this url to subscribe, unsubscribe and manage your subscription >> preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode > > > _______________________________________________ > use-livecode mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
