The tree

Quote from: smashingred at May 30, 2013, 09:17 AM

To sum up, it sounds like the basic interaction experience, inconsistencies and unexpected or almost erratic behaviour of the tree rather than the existence of the tree.

The fact that you use the word sometimes indicates just how inconsistent the tree behaviour is. So even if you wanted to get used to the idiosyncratic nature, there's no predictability or rhythm.

Yes, exactly. There seems to be very little rhyme or reason to the quirkiness. Especially things like "suddenly the 'chunks' icon is just a non-clickable, non-expandable icon". I'm not sure if I could pinpoint what conditions cause that even if I devoted 40 hours a week to it.

Quote from: smashingred at May 30, 2013, 09:17 AM

• You want to be able to be logged into the manager in multiple browsers/tabs.
• You want the refresh button to work every single time

Definitely.

Quote from: smashingred at May 30, 2013, 09:17 AM

• You want the active resource on login/launch to retain the last used state or, if you session just expired (browser close) to the collapsed tree.

I really don't care or need the tree to retain the last used state from an expired session - I would just like it to make sense and be consistent within a given session!

It seems like the tree is attempting to preserve state across concurrent sessions (when I move from my desktop to my laptop - and sometimes it is a laptop session that was open from last week because I haven't shut down, for example) - and this just makes things more confusing. It would be better if each browser session - even if a user is logged in many times concurrently - was treated as unique. Ideally, I'd even like to be able to have multiple tabs not try to preserve tree state... but I have to think more about that.

It sounds like there are some pretty concrete FRs/Enahancements in this thread that could be incorporated into 2.3. They just need to get into the tracker now.

I agree it can be a little confusing when you edit one element or resource in one tab and one in another, and the tree focuses on the one last edited independant on which tab it was in. But I can absolutely live with that, especially since it doesn't seem to be build with multi tab editing in mind – which brings me to my first independant suggestion:

How about an 'Edit in new tab' option in the right click menu of the tree? It's probably the one thing I find most cumbersome to do, and I really want to do just that most of the time.


My other suggestions are somewhat bugs, but I'm not sure how or where to submit the bug reports:

• If an element is in a subcategory, but none of the same type is in the parent category, the parent category will show up as an empty category (e.g. in my current project, I have 5 TVs I can't reach from the tree)
• If somehow a category is deleted while elements are still assigned to it, the elements can become orphans and won't show up in the tree

UPDATE:
Ohh, I found out, so I've added them to the tracker now. [ed. note: flygenring last edited this post 13 years, 4 months ago.]

Keep great feedback like this coming folks. The more concrete and repeatable the identify behavior, the easier it will be to rectify.

Quote from: rethrash at May 30, 2013, 01:19 PM

Keep great feedback like this coming folks. The more concrete and repeatable the identify behavior, the easier it will be to rectify.

The one piece of weirdness (IMO) that I've been able to reliably recreate and reproduce is this:

When a resource, element, or file is saved, after the refresh happens, the tree panel that gets displayed depends not on whether you just saved a resource, element, or file, but on which of the tree panels you last clicked on - in any tab. So if I am editing a resource, then open a new tab, edit an element, save it, tab back to the resource and save the resource, when the resource page refreshes it will display the element tree. Grrrr. If I just saved a resource, I want the resource tree. If I just saved an element, I want the element tree. I can't imagine a scenario where someone would want otherwise.

There are probably similar logical reasons for some of the other weird behaviors, but I have yet to wrap my head around any of them.

That's because the last one you clicked on gets saved in the cookie, so that's what will be opened when the page re-loads.

Quote from: sottwell at May 30, 2013, 01:34 PM

That's because the last one you clicked on gets saved in the cookie, so that's what will be opened when the page re-loads.

Yep. I understand the why/how of how this particular behavior works. I just think it is a fundamentally wrong way to solve the problem, since it can easily produce an undesirable/confusing outcome. It seems like a solution that was not built with "working in multiple tabs" in mind, so it does not meet the requirements for that kind of work scenario.

It's also possible to use the "quick update" and "quick create" features in the Tree context menus without moving from whatever you are doing; I haven't opened multiple tabs for working in Revo for a long time.

Quote from: sottwell at May 30, 2013, 01:47 PM

It's also possible to use the "quick update" and "quick create" features in the Tree context menus without moving from whatever you are doing; I haven't opened multiple tabs for working in Revo for a long time.

I do use the quick update quite a bit too. But sometimes I need the line numbering, or the wysiwyg, or access to a resources TVs, and need to open a new tab.

I also freely admit that I don't have the cleanest coding or browsing habits. I have about 40 tabs open across two 20 inch monitors as I write this! But... that's how I work.