I have 2 user types, "instructor" and "studio"
I want the "studio" to be able to put "instructors" onto a schedule, but only with the approved relationship of "studio -> instructor"
So basically, I want "studios" to request a relationship with an "instructor" and both should be able to review and cancel that relationship at any time. This works well in User Relationships, however the wording is strange in some places.
- I've given the relationship a name of 'scheduler'
- I've branded it as 'instructors scheduled at this studio'
- The "one-way reverse" is "studio that can place me on a schedule"
I've marked each with a comment (e.g. [perfect]) about how the labeling works out in practice.
Requester "studio" user messages:
- Become Trevor Instructor's scheduler [perfect]
- Are you sure you want to send a new scheduler request to Trevor Instructor? [perfect]
- Your scheduler request has been sent to Trevor Instructor [perfect].
- You have sent a new scheduler request to this user. [perfect]
- "My relationships" tables "Relationships" column: "scheduler" [awkward]
- "My relationships" page tab for this kind of relationship: "Instructors scheduled at this studio" [perfect]
Receiver "instructor" user messages:
- Are you sure you want to approve the scheduler relationship request from Trevor Studio? [perfect]
- Trevor Studio's scheduler request has been approved. [perfect]
- "My relationships" page tab for this kind of relationship: "Instructors scheduled at this studio" [wrong]
- Relationships labeled: "studio that can place me on a schedule" [perfect]
- "My relationships" tables "Relationships" column: "studio that can place me on a schedule" [perfect]
1) The page tab on the "instructor" user type (receiver of request) is mis-labeled
I have this above as item #3 under 'Receiver "instructor" user messages'
The "Captialized name" for the One-way reversed branding I have configured is "Studio that can place me on a schedule"
But, the page tab here is using the "Capitalized name" set in the primary Branding.
This works on the "studio" page perfectly, but on the "instructor" page it's backwards. This is the most striking of issues and seems like a true bug. In all other instances, the "instructor" sees the "One-way reversed branding"
Replace the page tab title on the "Receiver/instructor" user with the "One-way reversed branding Capitalized name"
2) The Branding name should be different than the relationship name
I have this above as item #5 under 'Requester "studio" user messages'
This one is a bit more complex, involves a need for slightly more drastic modifications and requires a hell of a lot of explanation...
Because the relationship name "scheduler" is presented to both users, it separates itself from the concept of a one-way relationship. See #1 - #5 in "Requester/studio" above and #1 and #2 in "Receiver/instructor" above for examples of where "relationship name" is presented to both users. If this were a one-way term, it would be presented one way to the "Requester/studio" and another way to the "Receiver/instructor."
To solve this, You can't simply replace the "relationship name" with the "One-way reverse branding name" on the "reciever/instructor" messages because these messages wouldn't make sense:
- Are you sure you want to approve the studio that can place me on a schedule relationship request from Trevor Studio?
- Trevor Studio's studio that can place me on a schedule request has been approved.
These 2 messages require a name for the relationship as the relational pertains to itself and describes itself as a relationship. There are other places, like #3 - #5 above where the relationship needs be described as a relationship that pertains to me and describes my involvement in the relationship. The difference in this case is: a) The relationship is a "scheduling relationship" while b) the relationship to me is a "studio that can schedule me"
The possessives in the titles allow for a much better user understanding of the relationship. These possessives are not possible in the current framework.
- Allow the current required "Name" field to describe the "relationship"
- Create a new "name" field under "Branding" that describes "the relationship as it pertains to a user viewing the relationship"
- Alter code to segregate usage of old name and new name
- Provide better help text on each field
- Provide examples of messages in help text of each field
Patch coming soon... I'll try to illustrate this with some screenshots.