App Browser versus Project Browser

classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

AW: App Browser versus Project Browser

Tiemo Hollmann TB
+1

-----Urspr√ľngliche Nachricht-----
Von: use-livecode [mailto:[hidden email]] Im Auftrag
von J. Landman Gay
Gesendet: Mittwoch, 7. Oktober 2015 21:58
An: How to use LiveCode <[hidden email]>
Betreff: Re: App Browser versus Project Browser

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         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

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


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Roger Eller
In reply to this post by Monte Goulding
I'm going to abandon AB and PB as soon as RB (Rossi Browser) is ready!  ;-D
On Oct 8, 2015 3:07 AM, "Monte Goulding" <[hidden email]>
wrote:

>
> > On 8 Oct 2015, at 5:37 pm, Scott Rossi <[hidden email]> wrote:
> >
> > Anyway, I posted an example here that illustrates the desired options in
> > LiveCode terms: good (single axis distortion) and best (irregular
> > distortion).  http://tactilemedia.com/download/image_distortion.jpg <
> http://tactilemedia.com/download/image_distortion.jpg>
> I think will affine transformations you can skew on both axes but I think
> projective is a step up. The engine has functions for affine skew already
> so it sould be relatively easy to add skewX skewY properties to an image.
> The projective stuff would need investigation on whether Skia supports it.
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

BNig
In reply to this post by Mark Waddingham-2
I am following this discussion and I have the impression that Project Browser refers to the one in LC 7.

Ali posted in a different thread (that is why I quote him here)

There may not be many immediately obvious advantages to the new property
inspector, but there are two extraordinarily significant related ones:

1) Widget properties would not work with the old inspector. You would
perhaps have to create individual stacks for each widget and have its card
copied to the inspector. This is really not practical or viable in the long
term.

The new inspector just requires a few lines of metadata in the widget file
specifying what type of editor to use for a given property. Everything else
happens automatically.

2) The new inspector is *really* flexible for the classic objects. Have a
look at this fix for bug 16118 (no way to change a scrollbar's tooltip in
the property inspector):
https://github.com/livecode/livecode-ide/pull/562/files


We'd like to make it as good and useful as possible. If the worst you can
say is you can't see any advantages, then I think the non-obvious ones
above make it well worth it ;-) Otherwise it would be great to hear
constructive criticism and suggestions for improvement.

Ali
and he speaks of the LC 8 Project Browser.

Looking at the set up of the IDE including the Project Browser I find the structure of the IDE in LC 8 much clearer and it is easier to grasp what is going on and on top of it using widgets is fantastic.

Just turn on "Show IDE Stacks in Lists" and have a look at it in the Project Browser.

The whole thing is in a state of flux/unfinished and I think that is why there is soliciting for usability/interface opinions.

I don't think the developers are trying to force anything on the users, instead they clean up the convoluted structure of the IDE by modularizing it to a finer degree using Widgets and scriptified stacks.
As that is a work in progress and I am confident that everybody will be profiting from it.
I consider the LC8 Project browser unfinished.

In LC8 changes to the IDE will be a lot easier and reorganisation of e.g. Project Browser too. And once the clean-up of the IDE will settle it will be a lot easier for user contributions.

So in my view a lot of shortcomings of the Project Browser (LC7 and LC8) have been clearly shown but that is why this discussion is important.

And remember: the engineers are not trying to hurt the feelings of anybody. But the sooner more people try LC8 and report feedback/bugs the sooner LC8 will be a fully usable version of LC plus a lot more.

in case anybody is wondering what the engineers are doing
https://github.com/livecode/livecode/pulse

Kind regards
Bernd
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Martin Koob
In reply to this post by J. Landman Gay
J. Landman Gay wrote
On 10/7/2015 6:20 PM, Scott Rossi 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).

You can choose to sort layers from top to bottom, or bottom to top in
Preferences, but there's no option to sort by anything other than layers.

Suppose the project browser had a slide-out left panel that listed the
stacks and cards, like the app browser does now? Maybe it could be a
preference, and if it's turned off, the PB works the way it currently
does. If the panel option is turned on, it would keep its selection but
get out of the way if you need the screen space. People could choose if
they wanted to view by stack/card/object hierarchy with a panel, or just
single-list as it is now.

I definitely need card numbers and object IDs.
I use the project browser exclusively but the main stack in my project has only 3 cards but with lots of objects on the cards many of which are in nested groups so the ability to drill down into nested groups is why I like project browser. So having all the cards in view is not really an issue for me. However,  Jacque's post encouraged me to look at AB to see how that would work for me and I can see the benefits she points out.

The other feature I like about PB is the filter.  Sometimes in a script there is a reference to an object that I need to manipulate using the property inspector or edit the script of as I use lots of dispatches and sends.  To find the object and open its script I can quickly enter it in the filter and find it and open the property inspector.  In the application browser I don't see a find or filter function.  I also use filter if I am trying to go from memory to find an object and typing the partial name of the object allows me to find it.  

The one thing I dislike about filter feature is that once an object is selected from the filtered list you can't then see the objects that are above it and below it in the hierarchy.  If I remove the search term from the filter then the object that I selected from the filtered list is no longer visible in the pane. There should be a way to turn off the filter and then all objects are visible again but the object that you selected from the filtered list stays where it is in the pane so you can then see where it is in the hierarchy and access its children or parent.

I like the suggestion about a two pane approach with the Left pane being the AB and right Pane being the PB or the right pane being able to toggle between a PB or AB approach to viewing the hierarchy.

In another part of this thread there is a discussion of merging the AB/PB with the script editor.  I think that is an interesting idea.  One feature I think would be useful would be the ability to right click on the name of an object in the script editor and have a contextual menu come up with a 'go to object' menu item that would hilite the object in the PB/AB just as when right clicking on a handler you get the 'go to definition' menu item.  There could also be a 'go to object script' menu item.  This would be useful with send or dispatch commands to be able to jump to the script of the object that it was being dispatched to.

One question though  Jacque says she uses the object IDs in the AB.  I don't see a column for object IDs in the AB.  Is it a preference to choose which columns are shown?

Martin
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Martin Koob
In reply to this post by Monte Goulding
Monte Goulding wrote

Direct integration between the project browser and the script editor would be very nice too. Some kind of context mode in the script editor that would switch the script in the script editor to the selected obhect with some indication of unsaved or unset scripts on the project browser.. Extra bonus points if you can include the project browser directly into the script editor as a pane… Very much like how the inspector will change when you select an object. It seems reasonable that the script editor could have such a mode that would update with object selection via project browser or other means.
I like the idea of integrating the PB/AB with the script editor. One feature I think would be useful as part of this integration would be the ability to right click on the name of an object in the script editor and have a contextual menu come up with a 'go to object' menu item that would hilite the object in the PB/AB pane of the script editor just as when right clicking on a handler you get the 'go to definition' menu item.  There could also be a 'go to object script' menu item that would open the script of the object in the editor.  This would be useful with send or dispatch commands to be able to jump to the script of the object that it was being dispatched to.

Martin
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Paul_Hibbert
In reply to this post by Martin Koob

> On 8 Oct 2015, at 06:47, Martin Koob <[hidden email]> wrote:
>
> One question though  Jacque says she uses the object IDs in the AB.  I don't
> see a column for object IDs in the AB.  Is it a preference to choose which
> columns are shown?

Right-click on the column headers in the of the AB and you should see a contextual menu for the options available in the headers, you can choose to show/hide each one.

Paul
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Martin Koob
Ah!  Ok thanks Paul.

Martin
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

J. Landman Gay
In reply to this post by Martin Koob
Right click on any header in the app browser to toggle visibility of the columns you want to display.

On October 8, 2015 8:47:03 AM CDT, Martin Koob <[hidden email]> wrote:

>
>One question though  Jacque says she uses the object IDs in the AB.  I
>don't
>see a column for object IDs in the AB.  Is it a preference to choose
>which
>columns are shown?

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Bob Sneidar-2
In reply to this post by J. Landman Gay
+50

That about "sums it up" Jacque. ;-)

Bob S


> On Oct 7, 2015, at 12:58 , J. Landman Gay <[hidden email]> 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         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Dr. Hawkins
In reply to this post by mwieder
On Wed, Oct 7, 2015 at 8:25 PM, Mark Wieder <[hidden email]> wrote:

> On 10/07/2015 11:54 AM, Mark Waddingham wrote:
>
>> So if we had deleted the app browser stack from the build, would your
>> point of view have changed and would you have started to use the project
>> browser? ;)
>>
>
> Wow. I step away for a day and look what happens.
> Interesting question.
>
> I'd probably stay with previous builds and cut my ties with a company
> that's out of touch with its user base.
>

I, too, would probably go searching again.

The whole IDE is degrading fast enough without taking pieces that do
sort-of work and forcing new things on us . . .


--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Dr. Hawkins
In reply to this post by Mark Waddingham-2
On Wed, Oct 7, 2015 at 11:51 PM, Mark Waddingham <[hidden email]> wrote:

>
> i.e. There is was a strong hint that continued usage of the Application
> Browser was related to its presence, rather than fondness.
>
> Essentially I was trying to determine whether it was familiarity or like
> which was the issue here.
>

The project browser displays far less in the same vertical space, even
without considering the left pane.

On top of that, it is more effort, scrolling, and clicks to display.

Kind of like why I'm so disappointed with my new Tivo . . .  (I counted the
other night, and it was about six taps of navigation for a season pass, or
whatever they call it, compared to two on the same button.  And large types
of searches [e.g., "season premier" ]no longer work --quite similar to what
we're complaining about here)
--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Mark Waddingham-2
In reply to this post by Dr. Hawkins
On 2015-10-08 17:58, Dr. Hawkins wrote:

>> Wow. I step away for a day and look what happens.
>> Interesting question.
>>
>> I'd probably stay with previous builds and cut my ties with a company
>> that's out of touch with its user base.
>>
>
> I, too, would probably go searching again.
>
> The whole IDE is degrading fast enough without taking pieces that do
> sort-of work and forcing new things on us . . .

As I said in another post (in reply to the original reply), this wasn't
the intent of my post - so apologies for any mis-inference that has been
took.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

mwieder
On 10/08/2015 09:05 AM, Mark Waddingham wrote:

> As I said in another post (in reply to the original reply), this wasn't
> the intent of my post - so apologies for any mis-inference that has been
> took.

Hee. no mis-inference here. You posted a hypothetical question, and I
took the bait. No worries from my end.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
 Mark Wieder
 ahsoftware@gmail.com
123