LiveCode Forums.

I'm mulling over some UI design ideas which raise the question of application efficiency.

Does it introduce noticeable overhead (in terms of performance and reliability) to have hundreds of grouped elements on a single card?

There may be instances in my project where rather than jumping from card to card it makes more sense to just hide/unhide grouped objects. Just want to make sure I'm not pushing the app where it doesn't want to go if I'm intending to create cards containing literally hundreds of grouped objects.

Thanks for insight on this.

Bill

Hi Bill,

Most of the time, having hundreds of controls means that you need to re-think the design of your interface. Why do you need to many controls?

I haven't noticed any significant delays when showing and hiding groups with multiple objects. I don't expect this to be a big problem.

Best regards,

Mark

Mark wrote:Hi Bill,

Most of the time, having hundreds of controls means that you need to re-think the design of your interface. Why do you need to many controls?

Because I'm clearly "out of control"!

Seriously, the app I'm researching is visually and functionally quite rich. The parts about showing/hiding multiple groups is related to making panes of information visible/invisible as dynamically controlled by the user. And, there's lots of said panes. So, you just don't go to another card for the new layout with the new pane. It may be collapsed or expanded. It's really the concept of a card within a card, (which would be nice!) sort of how a card can work as a sheet. However, I need "sticky sheets" (that aren't modal). (Ooo this is sounding interesting...)

Anyway, thanks for the feedback.

Bill

Hi Bill,

If I understand you correctly, you have stored lots of pieces of information in objects and now you want to show and hide the objects to show and hide the information. Usually, this is not the preferred approach. Why don't you store the information in custom properties, files, or a database, and put the information into the right objects when needed? This way, you need much less controls and can edit information separately from the controls. Your stack will also probably much smaller and it will be easier to create standalones.

Best,

Mark

The issue doesn't have to do with storing lots of data, obviously a database is best for that. The issue has to do with placing the various different control objects themselves all on the same card. Groups of controls are much easier to manage when they exist on different cards, but, there's some interaction between objects (e.g. geometry controls) which operate just on objects on the same card. So, the concept is having lots of different groups on a single card and showing/hiding the controls.

The best way of explaining the concept is to imagine a large window which contains within it dozens of other mini-windows that area constrained by the main window (e.g. called panes). These panes can be collapsed/expanded and the state/size/location of each pane affects the size/position of other active panes.

Anyway, it just seems like I'll be managing lots of different groups. The Edit Group feature really helps with this. However, I wish it didn't cause the IDE to crash so frequently...

Mark wrote:Hi Bill,

If I understand you correctly, you have stored lots of pieces of information in objects and now you want to show and hide the objects to show and hide the information. Usually, this is not the preferred approach. Why don't you store the information in custom properties, files, or a database, and put the information into the right objects when needed? This way, you need much less controls and can edit information separately from the controls. Your stack will also probably much smaller and it will be easier to create standalones.

Best,

Mark

Hi Bill,

I still wonder why you need to many different controls...?

Mark

Bill, if you're "out of control" you're in good company: there seems to be a trend in recent years away from multiple windows to multiple panes within a single window, which in Rev terms means a lot more controls in a given stack.

For example, consider the evolution from Adobe Premier, in which the preview, media, and timeline views were each in separate windows, to Apple's iMovie which provides these same views as panes in a single window. In fact, Premier CS4 now uses panes itself. Similarly, Claris Emailer and AOL's mail interface used separate windows for message lists and message body, but Outlook and Thunderbird provide them all as panes. And of course there's the nearly-ubiquitous trend with browsers to avoid multiple windows through the use of tabs, carried over in the Rev world with Jerry Daniels' tabbed script editor.

So I expect we'll see ever more Rev apps follow this trend, and I'm in the process of doing that myself with a couple apps I'm working on.

In fact, we've been shipping WebMerge for many years, and while its main window is tabbed I'm using groups, rather than cards, to hold all the controls for a given tab. I started out using separate cards, but found that having to specify the card in each control reference was just more work than I felt like doing, and it was simple enough to just hide and show groups as needed. There are currently 195 controls in WebMerge's main window, and in the upgrade I'm working on that number will double; so far so good.

While it does complicate the development process to have such a long list of controls in the App Browser, and made a little more complicated when they live in nested groups as many of my designs require, I've seen no noticeable impairment of runtime performance for doing so.

Whenever you open any stack the whole stack file is loaded into RAM, so whether the controls are all on one card or across multiple substacks will have little difference in terms of memory usage.

We can expect three areas in which there may be a *measurable* (even if not noticeable) difference: initial load/rendering time of a stack, hit testing, and handling window resizing. More controls simply means more work for the engine to do, and with resizing that also means more work for your scripts to do.

But that's true with any app. Note how slow the resizing is in Apple's GarageBand. Lots of stuff to adjust will mean more time to adjust it. I haven't yet seen cases where resizing even complex layouts in Rev is any slower than we might expect with apps written in C++, but FWIW I tend to write my own resizeStack handlers, and have no clue about how well Rev's Geometry Manager performs under such a load.

So in short, I'd say go ahead and be "out of control". Up to a thousand objects or so (maybe more for all I know) you should be no worse off than in any other development system, and it may help your design feel more modern.

Hi Richard and Bill,

I can very well imagine that a programme may need many controls. The exact meaning of "many" probably depends on the kind of project. Naturally, there is no "right" number of controls.

Nonetheless, I believe that hundreds of controls, visible at the same time in one single window, simply imply that the interface designer needs to give the design a little more thought. It is important that a user doesn't lose her/himself in the abundance of controls.

Best,

Mark

I think the key there is "visible at the same time". Neither WebMerge nor Bill's proposal has all controls visible at the same time.

But I can imagine some that would. GarageBand, iMovie, or pretty much anything with a timeline or even just using groups as list elements will likely exceed a couple hundred.

Hi Richard,

I guess that's why I bought Melody, even though I had Garageband already.

Best,

Mark

Excellent response and just what I was hoping to hear. Thanks Richard.

FourthWorld wrote:
So in short, I'd say go ahead and be "out of control". Up to a thousand objects or so (maybe more for all I know) you should be no worse off than in any other development system, and it may help your design feel more modern.

I'm not sure Melody or any music authoring tool can go light on object count, esp. as a composition becomes more complex.

If this is the UI:
http://www.palette-mct.com/musical_pale ... een_1.html

...then I'd guess the object count isn't much lower than GarageBand's.

If its controls render noticeably faster that may be simply because GB's graphics are richer. Whether one is "better" than the other is subjective, but reviewers - and even many customers - respond favorably to good graphical treatments.

Either way, I'm not sure many choose their software based on redraw times when resizing windows.

As a benchmarking fiend, I tend to favor responsiveness, recognizing that while it doesn't get much conscious attention, it plays a strong role in the overall satisfaction the user can derive from a product.

But just as both Apple and Microsoft have abandoned rapid redraw for their OSes in favor of a richer, multi-layered rendering engine, I see good benefit to applying textures, gradients, and other graphical treatments to make an app feel more like a physical thing.

A good example in the Rev world is Scott Rossi's work, as shown at tactilemedia.com. To get the rich look he's after requires a lot more objects to make what might otherwise be done with a single control.

I don't go quite so far as Rossi in my own apps, since I have so many functional controls I need to keep merely decorative ones to a minimum. But even just relying on the engine's gradient properties will eat more rendering time than flat color. In many cases that's a price I'm willing to pay to get a nicer look.

i Richard,

Nope, that's not it.

Best,

Mark

Are screen shots available for the Melody software you're using?

If they've found a way to represent compositions with low object counts, it sounds like something we can learn from.