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-boun...@lists.runrev.com on behalf of p...@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 <sc...@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-boun...@lists.runrev.com on behalf of >> jac...@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 | 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 >> >> >> >> _______________________________________________ >> 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 >> >_______________________________________________ >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 _______________________________________________ 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