App Browser versus Project Browser

Peter Haworth pete at lcsql.com
Wed Oct 7 20:31:19 EDT 2015


I think this thread illustrates the problem the team have trying to figure
out what type of browser to implement.  Everyone has their own ways of
working and it's practically impossible to come up with a solution that
will keep everyone happy.

Perhaps the biggest divide is between the horizontal and vertical layout
fans.  My preference is for a vertical layout but I recognize that can
cause a large amount of scrolling.  I tried a few things to alleviate that
in lcStackbrowser, for example, tabs with only one main stack in each tab
and the ability to hide a specific stack or all except a specific stack.

I find myself using a lot of groups in my designs and that helps a lot with
the scrolling issue too, assuming groups are expandable/collapsible of
course.

A lot of the other PB  problems fall into the missing functionality
bucket.  You should be able to sort objects in whatever way suits your mode
of operation.  lcStackBrowser allows sorting of cards by name, id, or
number; controls by layer, id, type or name; with a default preference
setting for each one.  You can sort cards and controls differently for each
stack/card.

I do like the snapshot feature in the PB but not as an ever present
thumbnail.  In lcstackbrowser, you can display a snapshot of a specific,
group, or control with either a contextual menu option or a keyboard
shortcut.

I also wanted access to properties without opening a property inspector
window and lcStackbrowser has various ways to do that.  You can edit an
object's name, label, and (for simple text fields) its contents. Right
click on an object and you will have access to all of its boolean
properties.  Finally, you can expand an object to show an editable list of
properties, grouped the way that suits the way you work in preferences,
with full type-specific editors, including an array editor.

You can also customize just about every element of the display, reorganize
the contextual menu items and add your own to them, and create/rollback to
commented checkpoints of your stack.

I don't pretend lcStackbrowser will be the ideal solution for everyone but
I think the key to a successful implementation is a high degree of
flexibility so users can customize it to suit their way of working.





On Wed, Oct 7, 2015 at 4:21 PM Scott Rossi <scott at tactilemedia.com> wrote:

> 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
>
>
>
> _______________________________________________
> 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