November 8, 2020 at 11:11 pm #13269
I don’t know if “unambiguate” is a word, but it seems like it oughta be.
I discovered wall panel tags tonight. It appears that as you build your model, walls are numbered serially. Presumably, that’s how Env keeps track of wall entities. Pretty interesting for reviewing the sequence in which I built my model. Not sure how I’d actually use that information in real life, except maybe when logging a support case.
What I COULD use, when applying Appearance parametrics, is an indication of “L” or “R” for walls. (Or any other entity for which L/R properties apply.) Ideally, where applicable, it would appear automagically when I open the Properties dialog.
That way, if (and I really mean when) I can’t remember if I drew this dang wall top-to-bottom or bottom-to-top, Env will tell me which side is which if I drag the dialog box out of the way of the wall so I can see the “L” and “R” overlay.
‘Cuz right now–and for all 14 versions that preceded v15–it’s been pretty much a 50-50 chance I’d get it right the first time.
Clearly, Envisioneer knows which side is which. Probably never gets it wrong. But, unlike wall panel serial numbers, it keeps L/R information close to its chest.November 10, 2020 at 3:01 pm #13272ChantaleKeymaster
Each wall has a green, red, and blue grip on it when you select it. Marking the start, midpoint and finish point of the wall.
When you need to determine Left side and Right side of a wall – applying trim, painting a wall etc. , use this tip to see it as Envisioneer does:
Pretend you are standing on the green dot (where you started drawing a wall) and look to the red dot (where you stopped drawing the wall), in that orientation you have your left and right-hand side of the wall.November 10, 2020 at 10:38 pm #13274SDSParticipant
Chantale, while the colored grips do work fine…they are clunky. It is very common that the wall properties dialog actually blocks the view of the wall you are editing…I’ve had to develop a habit of always checking grip color for direction PRIOR to opening the dialog for this very reason…it adds a redundant step to everything by having to select the wall check the grip then open the dialog…and if I forget to check first and cant see the wall with the dialog open…I have to close the dialog, check the grips then reopen it. Very clunky interface for something as simple as wall direction.
The obvious answer is to also include indicators within the dialog box.
But personally I’d prefer you guys make gables work properly before adding new stuff.November 10, 2020 at 11:25 pm #13276
Agreed, SDS, the grips are “clunky” but they do NOT work fine. There may be a more obtuse, user-hostile way of conveying this critical information…but I’m not sure what it would be.
While it’s helpful to know the grips trick since that’s all we’ve got, I should not have to “see it as Envisioneer does,” Chantale. Envisioneer should see it as I see it. Envisioneer’s UI’s only job is to accommodate me.
What I was suggesting was what’s in the attachment. (A picture is worth 1000 words. You’d think an architect would understand that!)
The “L” and “R” overlay would appear as the Properties dialog is opened and disappear when it closes. Provided the overlays were programmed to ALWAYS be in the viewport at the time the dialog is opened, and not necessarily at a fixed location of a wall (like centered), then I can drag the dialog out of the way for a quick peek when I need to see them.
Other than identifying Left and Right through your color code, is there any reason I’d ever care which direction I drew the wall in?
For my part, I don’t use framing. I vote for usability in modeling.
You must be logged in to access attached files.November 13, 2020 at 11:40 pm #13285FynrDzynrParticipant
Firstly that screenshot is incorrect.
2y, how hard is it to drag a dialogue box away from the wall?November 14, 2020 at 9:52 am #13286SDSParticipant
Firstly that screenshot is incorrect.
2y, how hard is it to drag a dialogue box away from the wall?
There are several reasons why I have chosen not to upgrade from v13, the clunky interface is just one.November 14, 2020 at 11:27 pm #13288
Firstly, you’re right, Merv!
As am I (he said, quoting himself, despite being raised better than to do that): “There may be a more obtuse, user-hostile way of conveying this critical information…but I’m not sure what it would be.”
And I can now present my errant bitmap as Exhibit A!
2y, it is not difficult to drag a dialog box out of the way. I don’t have a huge problem with that. I’m guessing you are responding to SDS’s comment, to which SDS would have to respond.
That said…I’d note that if you use Replace in a long Word document, and keep clicking Find, you’ll note the Replace dialog moves, ensuring that highlighted text about to be replaced is not obscured by the dialog box. Introduced, if I recall, in Winword 2.0, or maybe 6.0, back in the 1990s. A subtle, but elegant and thoughtful, user-first, usability feature I appreciate every time I use it, and which indicates a level of polish I’d then thought I’d see in all software by late 2020!
But, yes, I could drag the Replace dialog box out of the way in Winword. While I could, I just don’t have to. I would have to in 2020’s ProArchitect 15.0.
And because the Replace dialog is non-modal, I can also click on the document and type a correction if I note something that my Replace specifications don’t anticipate. Another topic for another time.
However, my tangentially-related comment was about a more fundamental issue: What if I drag the dialog box out of the way, and still don’t see the “L” and “R”?
If the wall I double-click is at the very edge of the display, I still need to be able to see “L” and “R”. My thinking at the time of my prior post was that the “L” and “R” should typically be centered on the wall, but would be automagically moved, like Winword’s Replace dialog, to ensure visibility if they’d otherwise be off-screen.
Another, maybe better (and certainly easier-to-code) approach is to overlay the “L” and “R” at each of the 3 nodes, thereby guaranteeing they’re visible when part of the wall is outside the viewport (attachment ending in 0), or even when all but one end of the wall is beyond the viewport (attachment ending in 1).
If you can overlay nodes and dimensions of selected walls, Cadsoft, you can just as easily overlay “L” and “R”.
Is there any significance to the user (as opposed to the software) about the direction in which the wall was drawn–beyond deducing which is the left and right side of a wall? From my perpetual-noob standpoint, I can’t see it. But I am sincerely open to learning something new, if it is in fact a useful insight or technique.
If yes, then keep green-blue-red and merely add “L” and “R” overlays to “unambiguate” them.
Although, arguably, there are more graphic ways to convey direction than a color code. Another topic for another thread, if it’s even necessary, and I’m not sure knowing direction is necessary.
If direction is only meaningful for deducing L/R faces, then green-blue-red is a total fail, and must be replaced with something meaningful.
Meaningful not to the program, which clearly keeps track of L/R by the direction in which the wall was drawn, just as it serially numbers the walls to keep track of those.
No, what is displayed must be meaningful and obvious to the user.
As with Winword, when it started graciously moving the Replace dialog box out of the way of the highlight, more than a quarter-century ago.
P.S. The word I was looking for in the subject was ‘disambiguate’!
You must be logged in to access attached files.
- You must be logged in to reply to this topic.