Element tree improvements?

I love the groups feature! So so so handy.

Allowing users to search through the element list would be handy too. Abit like they do in Axure:

On click of the magnifying glass icon, a search field appears below the grey bar. (I use this search alot at work!)

I added the ability to reveal an element in the tree from the property editor and hiding when clicking twice on an entry in the list. We only hide elements that are hidden by default, otherwise we just unselect it.

Weā€™re getting close. I guess the few things left we could consider are:

  • a way to only show hidden elements (though Iā€™m not sure how I like that one)
  • a better color code for the eye
  • and maybe a search by name option.
2 Likes

Thanks this is all very great. Especially with the alphabetical order back.

ā€œ- a better color code for the eyeā€ -> maybe, for element that are visible by default the entire name could be bolded. then eyes would just indicate if they are visible in the editor right now.

ā€œ- and maybe a search by name option.ā€ -> maybe the element tree could be filtered based on the entry in the ā€˜search elementā€™ box. The fact that the search element box is not exactly on top of the element tree is actually a plus for it would allow to see both the existing dropdown of the element by type and a filtered element tree (displaying the searched element and their parents)

1 Like

@emmanuel, could there be a setting on the Apps Setting page to select between alphabetical and the logical position of the elements? I would hate to have to number all elements on my page to get them in the order I want them to show. Seems like a terribly inefficient way to manage the elements versus containerizing them into Header, Footer, Body, Left Sidebar, Right Sidebar, and other sections that follow normal web design patterns.

Unfortunately we donā€™t have such a place in the interface, but Iā€™ll think about it. It does make sense to do this by name I think though (at least before we offer a setting).

What about a section under the General tab?

Having to number everything is too time consuming for me. Itā€™s easy to understand where something is based on where it is on the page once itā€™s put into a group thatā€™s labeled properly with Header, Footer, et cetra. If multiple designers/developers are working on an app theyā€™re not going to know if items numbered 1,15, or 10,000 are in the header, body, footer or any other portion of the page.

The only option for me would be to prefix every element that appears in those sections with the section name.

Example

1 Like

The settings tab is for app settings, not for UI settings, which is quite different. Also, for your app, it shouldnā€™t be that huge of a change, on Friday morning it was alphabetic order (in the previous system).

Yes, itā€™s not a huge change at this point in my app, but thinking of the future it would require additional thought and a change in normal web design constructs. And frankly, it seems like a maintenance nightmare, but I digress. :slight_smile:

Sorry @emmanuel but the eye things makes very little sense to me.

I get the ā€œfocusā€ with the blue. But the eye of ā€œGroup Aā€ being greyed out ā€¦ what does that signify.

As it standsā€¦

Popup A is blue, Group A eye highlighted = only see the popup.
Group A is blue, Popup A eye highlighted = see the popup and the group.

What does the eye with a strikethrough mean ?

Why does the eye highlighted change as you select the groups ?

Sorry, but even with 3 elements on the page I havenā€™t got a clue what is going on.

Mostly what I care about is showing hidden elements on the page so I can work on them. And I donā€™t really see how this helps, as I canā€™t tell which are the hidden elements. They way it used to work was intuitive and this isnā€™t.

The problem were trying to solve here is that users with a lot of elements want to hide elements that are visible, so just enabling showing hidden elements wonā€™t be enough.

Well think about the color code. The idea here is just to distinguish elements that have been altered by the user and the ones that havenā€™t.

2 Likes

Iā€™m noticing that sometimes when I select a hidden element in the tree - the element will show - but it will also show a different, unrelated element alsoā€¦

For example:
if I click (Group 1) ----- Group 1 AND Group 3 would show > where I only wanted group 1 open

Rather than file a small bug report / thought I would mention here.

Well for that one please file a bug report actually because we need a specific situation that reproduces the issue.

Ok. Will do

My vote is for them to be ordered in the order they were placed on the page/group. That way you know what their visibility order is. I think I suggested this before, but it would be nice if you could then drag them around in the tree to change their position/order on the page. That way, if you forget to add a shape for a background, you donā€™t have to delete everything you want in front of it before adding the shape in. Proto.io does this nice as an example.

But what youā€™re referring to here is z-index, not the top position on the pageā€¦

Yes, thatā€™s probably the best way to describe it. Each element should be ordered in their group by their z-index. And then, it would be nice if we could drag and drop them around in the tree to change their z-index.

1 Like

I am surprised the element tree has become a big deal. I am still trying to get used to it so I want suggest something.

Not sure if this is already suggested but what if all the elements in the tree that are not visible on page load only had the blue eye icon and the rest didnā€™t have any icons, and when the title to the left of the icon is clicked itā€™s highlighted blue and the element in the editor becomes visible. So if the title is highlighted blue the elements are visible for editing.

Again there is a lot of comments and I am not sure if someone suggested this idea.

If you do this and want to hide an element that is visible on page load how do this do this? The point of the new box is also to make that people donā€™t have to temporarily hide an element just for edition.

Itā€™s not a ā€œbig dealā€, itā€™s just that weā€™re having a very social way to developing this features :stuck_out_tongue:

3 Likes

When the titles are grey all the elements are not visible for editing, only the blue highlighted titles are visible for editing. The ones with the eye/icons are the ones that are invisible on page load.

I like the element tree!

2 Likes