aframevr / aframe-inspector

:mag: Visual inspector tool for A-Frame. Hit *<ctrl> + <alt> + i* on any A-Frame scene.
https://aframe.io/aframe-inspector/examples/
MIT License
654 stars 201 forks source link

Faulty visual hierarchy in components panel #316

Closed feiss closed 7 years ago

feiss commented 8 years ago

Disclaimer: I'm new in town, so please bear with me about all these suggestions I'm throwing. I'm not familiar with all the discussions, prototypes, past versions and motivations of this topics regarding the editor, I'm just giving my naive opinion on what I see in current version.

Folowing @cvans 's issue on #311 , I feel the hierarchy of the headers in the components panel could be better.

Now:

image

Issues:

I did other minor tweaks too, but not for discussion in this issue I guess. The main topic I wanted to arise is the faulty visual hierarchy in the elements of the panel and the use of the section headers.

image

fernandojsg commented 8 years ago

We love feedback so don't need to be worried about it, it's so cool and useful to have an open conversation about the app :+1:

is almost unseen, and really is the main character here! The whole panel is about this guy, and should be H1

Yep totally right something bigger and brighter should be used for that.

Since all entities will have the "common" section, I find it useless. Also, "common" is not a name of an actual component, so it's a bit misleading. I'd just remove it, leaving the common properties just below of the entity header.

We added the Common header mainly to be able to toggle that panel as most of the time you'll transform the entity using the transform tools in the viewport instead of entering them by hand, and things like ID or visible is not something that you edit all the time, and as this is the first panel of the sidebar and could end up taking a lot of space the users probably would need to scroll every time they select an entity to access the components data. Do you think we could add some toggle functionality in the title maybe? Don't know, open to suggestions here.

The same header and style is used for adding a new component ("Components") and the actual component, when the semantics of both are completely different. I propose removing the "Components" header and replace the select for a button (that opens a floating list of components, or the components gallery)

Yes this is something we were thinking also about, as it wasn't clear, in fact there's a issue opened about it. https://github.com/aframevr/aframe-inspector/issues/17 We were discussing if could be a good idea or not to follow a similar approach as 3dsmax with the properties panels, where you have a list of modifiers (should be in the "common" sections) and once you click one of them its properties will show up below that list (just one at a time) instead of showing them all like we have right now. In any case we agree that we need to get rid of this "components/add component" panel, so probably we could include your suggestion of the Add component button and then decide about the 3dsmax`s style.

Two different 'copy html' buttons

Yes, I agree with that too, I like you proposal (https://github.com/aframevr/aframe-inspector/issues/311) of using these icons.

Some properties have help button and others don't. This could be another issue itself, but I suggest removing all these buttons and use a more subtle help system, like: The actual property name is a link to its doc (simple implementation), or A main help button that changes the mouse pointer and allows the user clicking any header/title/property/field of the editor and open the help/spec/doc link associated to it (not quite simple).

I don't like the idea of clicking on the component or attribute titles as you can click by mistake when you want to collapse the panel for example and it will just open a new tab in the browser. I was thinking also to implement something like Unity where you use the attribute name to click&drag to modify some values and just leave the inputbox itself for enter values with the keyboard: parameters So we could discuss about your second option where you can over one component and you'll get the icon of help. Although I'm not big fan of this kind dynamic behaviour as modifying the UI while moving the mouse could looks weird depending on the number of icons we have there. I'll open another issue with this and we'll discuss!

There's no clear meaning in the use of colors: some user entry fields are in blue, and other (text) in gray. Also, some buttons are grey and others are blue. It would be nice to have a clear relationship between colors and function, for example, blue for user entry fields, and gray (or pink/magenta, like the "Back to Scene" button) for the buttons.

I agree too, currently we need to style the widgets properly, for example the checkboxes still looks completely out of place within the rest of controls.

Overall I like the changes proposed and the mockup that you did, maybe using a brighter color for the component and/or the toggle arrow icon could make it looks less greyish as it looks on your mockup?

fernandojsg commented 8 years ago

Sorry I didn't notice the toggle arrow in the <A-ENTITY> panel, so this one should collapse the "common" properties right?

feiss commented 8 years ago

Sorry I didn't notice the toggle arrow in the panel, so this one should collapse the "common" properties right?

Yup! Same behaviour like the 'common' header. And the add component button would stay always visible

I like the idea of having a list with the names of the components a la 3dsmax. It would be much clear and friendlier for newcomers. For users that want to edit multiple components at once, the selectbox could allow multiple selection, so you have the best of both worlds. And there's another good thing: in just one glance you see all the components that the entity has, without the need of scrolling down :+1:

fernandojsg commented 8 years ago

WIP: sidebarwip

dmarcos commented 8 years ago

The collapse button on the entity for the common attributes makes the a-entity look like another element at the same level as the components. It does not convey that the components are part of the entity. What I propose is to make the a-entity attributes non collapsible.

cvan commented 8 years ago

What I propose is to make the a-entity attributes non collapsible.

I agree that this would help a ton.

I won't comment on the other nits that have issues filed for them, but otherwise these changes feel good.

fernandojsg commented 7 years ago

All the functionality described here is already implemented