← Back to Cadsoft Community

Unambiguate “Left” and “Right”

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #13269
    JRVJRV
    Participant

    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.

    #13272
    cpittsChantale
    Keymaster

    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.

    #13274
    SDSSDS
    Participant

    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.

    #13276
    JRVJRV
    Participant

    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.

    #13285
    FynrDzynrFynrDzynr
    Participant

    Firstly that screenshot is incorrect.

    2y, how hard is it to drag a dialogue box away from the wall?

    #13286
    SDSSDS
    Participant

    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.

    #13288
    JRVJRV
    Participant

    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!

    QED.

    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.

    User first.

    P.S. The word I was looking for in the subject was ‘disambiguate’!

    • This reply was modified 3 years, 4 months ago by JRVJRV.
    • This reply was modified 3 years, 4 months ago by JRVJRV.
Viewing 7 posts - 1 through 7 (of 7 total)

You have to log in or sign up in order to use our community forum.