On 1/2/2015 9:00 PM, Richard Gaskin wrote:

Can you recall offhand what sorts of tasks take you more steps in the
Project Browser?

I feel like a curmudgeon after writing what follows, but...I don't use the project browser because it's too slow and cumbersome for my project. It may be useful for small stacks with only a few controls, but if you have several open stacks with lots of cards, and lots of groups and controls on each card, finding anything is almost impossible. It's much easier in the app browser to just select a card from a list and immediately see what it contains. I often need to jump between cards in different stacks, and in the App Browser I can expand the card lists for the stacks and click back and forth between them to instantly see their controls and relative layering.

If there are a lot of controls on a card, a single card's content runs off the bottom of the project browser, which means you lose the relative relationships of the objects as their containers scroll off the top. When the browser window is only showing a portion of the controls, there is no easy way to see what card those controls are on or even what stack they belong to. You have to scroll up quite a long way to find out what you're looking at.

This is the reason I keep the Finder in column view too. You can see the breadcrumbs and you know where you are. The app browser provides the same thing and is, for what I do, a much clearer layout and much faster to work with.

Another blocker for me is that the project browser does not list the card number, only the card name. That's not useful for unnamed cards, or cards whose names you don't remember. But I can see the card number in the title bar (and in my stacks it's also displayed on the card.) In the app browser it's easy to find the card by its number; in the project browser you can't. And if your stacks contain same-named cards, then it's too easy to choose the wrong one in the project browser even if you do know the name. The same problem occurs with layer numbers. If I need to change the layers on one card to match a card elsewhere, there's no numerical reference unless you double-click every control to see its property inspector.

I'm working on stacks with 30-50 cards each, with anywhere from 40 to 1000 controls per card, nested in multiple groups. Since each stack was created from a master template, there are several identically-named groups and controls across all cards and stacks. I usually have about a dozen stacks open at a time, sometimes more. You just can't navigate through all that in the project browser, and if you do get where you want to be, you can't tell later what you're looking at because the card and stack references have scrolled off.

I could navigate to the card in the stack, click something, and the browser would update -- but if you're working on one card and just need to reference the contents of another, it's one of those cases that takes more clicks to accomplish. I often click over to a different card in the app browser to remember what I named a field, and I don't need to physically switch cards in the stack to do that.

Here's another thing: the app browser works with messages turned off. The project browser doesn't. I frequently work with messages off to avoid script consequences I don't want.

Finally, I can sort the app browser in all kinds of ways -- put all the images together, all the fields, all invisibles, sort alphabetically, so it's easy to find things. The project browser is in a fixed order. The filter feature is a step in the right direction, but the card or stack references can still scroll off the top, and there's quite a noticeable delay when filtering a thousand objects for "type:field". I don't see a way to display more than one type of object, to alphabetize the controls on a card, or to limit the results to a particular card. The app browser does all that, and clicking a header is easy, fast, and I always know where I am.

I may be able to make the switch for simpler projects, but for this one I need to stay with the app browser. I hate to say that because I know how much work went into the project browser, and it's a beautiful thing, but I think we need to keep both tools around to accomodate different work flows. If I had to use the project browser on this project, my development time would quadruple.

--
Jacqueline Landman Gay         |     jac...@hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to