App Browser versus Project Browser
Scott Rossi
scott at tactilemedia.com
Wed Oct 7 19:20:05 EDT 2015
IMO, Jacque makes a number of valid points. In the Project Browser,
because stacks and cards are contained in the single view, a long list of
controls will remove any stack and card references from view, while in the
Application Browser, stacks and cards are always visible. It seems like
applying an Application Browser layout to the Project Browser could make
it more useful: move stack/card references to a left pane that is always
visible.
For myself, I also often rely on numerical references: card numbers, layer
numbers, etc. Filtering in the Project Browser is great, but it's not the
same as sorting offered by the Application Browser (AFAICT the Project
Browser doesn't offer sorting that I can see).
Regards,
Scott Rossi
Creative Director
Tactile Media, UX/UI Design
On 10/7/15, 12:58 PM, "use-livecode on behalf of J. Landman Gay"
<use-livecode-bounces at lists.runrev.com on behalf of
jacque at hyperactivesw.com> wrote:
>On 10/7/2015 1:22 PM, Mark Waddingham wrote:
>> Far more useful would be constructive criticism of both the Project
>> Browser and the Application Browser. It does seem a little 'silly' to
>> maintain two things which serve essentially the same purpose - so Ali's
>> idea is perhaps the best way forward - what is it that is good and bad
>> about both and is it possible to design something which everybody would
>> be happy with?
>
>The issues would probably become clear if you open, say, 10 large
>stacks, each with 50 cards or more, containing dozens of controls per
>card. Since my primary project for the last 2 years uses that setup, I
>haven't been able to use the Project Browser because it isn't practical.
>
>1. The hierarchical organization of the App Browser (AB) is
>indispensable and is the main reason I stay with it. I can see at a
>glance how to drill down to the single object I am looking for and how
>objects are organized on each card by group and layer order. It is by
>far the fastest way to understand how a set of stacks is internally
>structured. The long, scrolling list in the Project Browser (PB) can't
>display the structure as clearly because it is all linear. Multiple
>cards with many objects will run off the top and bottom of the PB window
>and you can't see the overall organization.
>
>2. It is difficult in the PB to quickly find a specific object. If you
>want to know the name of an object on some other card, you have to
>collapse the current card, scroll through 50 cards to find the one
>you're looking for (and if you didn't collapse those already, the
>scrolling is interminable,) expand it, scroll through the objects to
>find the one you want (note the name because it's going to be a long
>trip to find it again,) collapse that card, scroll (forever) again to
>find the card you started with, expand it, find the original object
>again, and continue. In AB, I can just look at the left-hand pane and
>see the name of the target card, click it, note the name of the object,
>then click back where I was. If the AB is sized tall enough to hold 50
>lines of text, I don't have to do much scrolling at all. If I do need to
>scroll, it's minimal because at least 25-30 cards are always visible at
>once.
>
>2. In the AB I can click on any header to view the organization in many
>ways, and I have a choice of which columns I want to display. If I want
>to work only with images, or fields, I can bunch them together in the
>list by type and they are quickly accessible while still allowing me to
>see the other objects on the card. I frequently require info on layering
>order, one click and I have that. I use the ID column extensively. In PB
>I have to type in a filter string to isolate by object type, and then I
>can no longer see any other objects, so if I need some other info I have
>to remove the filter, find what I want, then reinstate the original
>filter. PB does not offer a way to identify an object ID at all, as far
>as I can see, and I need that all the time. (But you could turn off
>those distracting ID tooltips for sure.)
>
>3. Visually, the PB is too cluttered to be quickly scanned. The
>checkmarks in the AB are more useful. In the AB is very easy to see, for
>example, which objects are invisible by simply looking for "gaps" in the
>checkmark column. In the PB I have to examine each object individually
>because the visual difference between the enabled and disabled "eye"
>image is not distinct enough, and even if it were, there's that
>scrolling issue again to see all the objects. Also, there is no single
>column to scan -- the lock icon is interspersed so you have to mentally
>learn to skip over every other icon.
>
>4. I have turned off thumbnails in the PB because with hundreds of
>objects or more, the time required for it to constantly update is (or at
>least, was) unacceptable. Even without thumbnails, it performs much
>slower than the AB. There is also the issue of visual clutter (see
>below) which is main reason I turned off thumbnails on day one.
>Thumbnails also double the amount of scrolling you have to do to find
>things.
>
>5. In the PB there is no clear delineation between cards and substacks.
>Both are left-aligned at the same visual depth. In the AB, all stacks
>are in the left pane, with substacks indented under their mainstack.
>Also, in the PB, the stack you are inspecting scrolls off the top of the
>window, so you are never sure which stack owns the cards that are
>currently displayed. This is a big issue in my project, because all the
>stacks are clones of each other and cards have the same names (usually
>just IDs.) In the AB I can immediately see which stack owns the card
>because the card is highlighted in the left-pane list under its
>easily-viewable owner. Even if I have to scroll to see the stack name,
>the card I'm working with remains selected and its objects remain visible.
>
>6. The icons at the bottom of the PB are so tiny on my screen that they
>are difficult to recognize (and my eyesight isn't great anyway.) I have
>to use the tooltips. That takes too long, so I just open the property
>inspector or use the menu items instead. I suppose with some use I'd
>memorize what each icon does, but the other issues have prevented me
>from becoming familiar enough with it.
>
>That's just what I remember from the few days I tried to work with it.
>I'm not convinced that the current design can accomodate my work style
>unless it can at least be revised to show a columnar view rather than a
>linear one. What I would have preferred is an update for the few
>glitches in the AB (mainly it doesn't always refresh automatically, and
>those blinking tooltips are positively aggressive) and give it a new
>coat of paint if you think it looks too dated. Its plain text layout
>with clear checkmarks is much easier for me to work with. I do like how
>you can change layering order by dragging in the PB, that would be a
>nice addition to the AB.
>
>--
>Jacqueline Landman Gay | jacque at hyperactivesw.com
>HyperActive Software | http://www.hyperactivesw.com
>
>_______________________________________________
>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