App Browser versus Project Browser

Wed Oct 7 21:12:04 EDT 2015

Agreed that satisfying everybody will never happen, but I would argue that
the dual-pane approach of the Application Browser can display more
information in a single view than the Project Browser.  IMO, accessing
multiple stacks is more efficient using this approach compared to using a
single scrolling list.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design

On 10/7/15, 5:31 PM, "use-livecode on behalf of Peter Haworth"
<use-livecode-bounces at lists.runrev.com on behalf of pete at lcsql.com> wrote:

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