Selectable "Roles" on the Work Page

How do we configure MicroStation so that we can use Selectable "Roles" on the Work Page with MicroStation or OpenRoad/Rail Designer?

It was shown in the MicroStation SIG All About the DGNWS.

Parents
  • I have set the variable _USTN_ROLECFG and it seems to load, but the Role menu om the Work Page does not show up.

  • setting up workflows in not much different than the pulldown menus in V8i - where a user would scroll down thru a hierarchy of options to get to their needed tool. So I don't see how this is more annoying.

    So for you -  instead - the user needs to close the current file they are in and select a different "role" to load their needed tools, etc... ?

    Henry Ford said  “If I had asked people what they wanted, they would have said ‘faster horses." and Bentley is simply giving you a faster horse instead of an automobile.

    Just be careful what you wish for. I believe there can be a better more efficient way of loading various UI situations.

    Timothy Hickman

    CADD Manager | CADD Department

    timothy.hickman@colliersengineering.com

    Main: 877 627 3772| 

    1000 Waterview Drive Suite 201 | Hamilton, New Jersey 08691

  • Sorry, it seems we live in different realities ... which is possible because of difference between US and Europe engineering workflows and requirements, styles how projects are structured and created etc. I wrote what I have seen in my customers, that's all.

    setting up workflows in not much different than the pulldown menus in V8i

    I did not tell anything about pulldown menus.

    My perspective is about to optimize GUI (especially ribbon) for user's task and to minimize - what I hear often - "I cannot find that tool. Ohhh .. I am in wrong workflow ... Let's re-focus eyes from graphic/icons to this small text menu and try to find the right one."

    So for you -  instead - the user needs to close the current file they are in and select a different "role" to load their needed tools, etc... ?

    Again, you assume something I did not write. If a user will switch roles often, maybe you are right. But what I see is that a use works for hours or days on one project in his role, and when he changes the role, it's often because he need to do something on another project or object (in the same project), which requires to close the design file anyway and to change the workspace configuration.

    I believe there can be a better more efficient way of loading various UI situations.

    When you believe, please show us.

    But what Fredrik wrote does make sense to me, because it's what I experienced too, and also what I remember from former discussions about "what roles in MicroStation are for". I am aware it's subjective, but for many users seems to be idea of "role" (as a replacement of removed workspace "user" configuration, available in V8) better than switching workflows in ribbon.

    With regards,

      Jan

  • My perspective is about to optimize GUI (especially ribbon) for user's task and to minimize - what I hear often - "I cannot find that tool. Ohhh .. I am in wrong workflow ... Let's re-focus eyes from graphic/icons to this small text menu and try to find the right one."

    but if they are in the wrong "role" they won't find the the tool either and will need to exit the file and pick the correct one with the needed tool(s) .

    Timothy Hickman

    CADD Manager | CADD Department

    timothy.hickman@colliersengineering.com

    Main: 877 627 3772| 

    1000 Waterview Drive Suite 201 | Hamilton, New Jersey 08691

  • @Jan - like you mentioned earlier, the role was never clearly defined. So in your case is it merely to drive the UI ?

    Timothy Hickman

    CADD Manager | CADD Department

    timothy.hickman@colliersengineering.com

    Main: 877 627 3772| 

    1000 Waterview Drive Suite 201 | Hamilton, New Jersey 08691

  • but if they are in the wrong "role" they won't find the the tool either and will need to exit the file and pick the correct one with the needed tool(s) .

    It sounds a bit like artificial problem. Of course it can happen, but when we have used this solution in V8 products ("user" is not "named user", but "type of user"), it did not happen too often.

    @Jan - like you mentioned earlier, the role was never clearly defined. So in your case is it merely to drive the UI ?

    Primarily yes, but not only. It should involve also redefinition of configuration variables (that support GUI or tools configuration consequently).

    Unfortunately I have not enough time to write a detail explanation, but simplified example (to highlight some issues), why "start MicroStation with role selected" is better than "to choose from workflows" in my opinion:

    In the example, MicroStation workspace is used to represent a project, and a workset represents building object (every project consists from one or more objects).

    There always will betools available for everybody, tools available only for specific role(s) and tools similar in all roles, but with different configurations (e.g "place equipment" can be the same tool, but providing different content). It leads to structure (when talking about ribbon) with one or common workflows (e.g. defined MicroStation) and "per role" workflows with some tabs shared and some tabs unique.

    GUI simplification:

    • Only defined set of workflows (with optimized content) should be available. Can be done easily based on variable visibility test, defined for every workflow. [selected role changes variables]

    Customization simplification:

    • When there will be "place equipment" tool, in the simplest case it can be controlled by MS_DGNLIBLIST or other variables. [selected role changes variables]
      When there will be more workflows, every tool have to contain own key-in e.g. to attach the right cell library before the tool is started.

    Navigation simplification:

    • When there are only tools, allowed for active role, available, no problem to use F4 (search).
      But when there are several "per role" workflows ready to be seleted, the search can return several "nearly the same" tools, not clear what belonging to what role. It would require to distinguish them somehow by name, which can be very complicated in some languages (terminology, too long names polluting GUI...).
    • Settings like Element templates, build on top of organization/project data standards, can offer only a filtered selections, that makes sense for the role. [selected role changes variables]

    When

Reply
  • but if they are in the wrong "role" they won't find the the tool either and will need to exit the file and pick the correct one with the needed tool(s) .

    It sounds a bit like artificial problem. Of course it can happen, but when we have used this solution in V8 products ("user" is not "named user", but "type of user"), it did not happen too often.

    @Jan - like you mentioned earlier, the role was never clearly defined. So in your case is it merely to drive the UI ?

    Primarily yes, but not only. It should involve also redefinition of configuration variables (that support GUI or tools configuration consequently).

    Unfortunately I have not enough time to write a detail explanation, but simplified example (to highlight some issues), why "start MicroStation with role selected" is better than "to choose from workflows" in my opinion:

    In the example, MicroStation workspace is used to represent a project, and a workset represents building object (every project consists from one or more objects).

    There always will betools available for everybody, tools available only for specific role(s) and tools similar in all roles, but with different configurations (e.g "place equipment" can be the same tool, but providing different content). It leads to structure (when talking about ribbon) with one or common workflows (e.g. defined MicroStation) and "per role" workflows with some tabs shared and some tabs unique.

    GUI simplification:

    • Only defined set of workflows (with optimized content) should be available. Can be done easily based on variable visibility test, defined for every workflow. [selected role changes variables]

    Customization simplification:

    • When there will be "place equipment" tool, in the simplest case it can be controlled by MS_DGNLIBLIST or other variables. [selected role changes variables]
      When there will be more workflows, every tool have to contain own key-in e.g. to attach the right cell library before the tool is started.

    Navigation simplification:

    • When there are only tools, allowed for active role, available, no problem to use F4 (search).
      But when there are several "per role" workflows ready to be seleted, the search can return several "nearly the same" tools, not clear what belonging to what role. It would require to distinguish them somehow by name, which can be very complicated in some languages (terminology, too long names polluting GUI...).
    • Settings like Element templates, build on top of organization/project data standards, can offer only a filtered selections, that makes sense for the role. [selected role changes variables]

    When

Children