Page MenuHomePhabricator

Remove "room" vs "message" distinction
Closed, ResolvedPublic

Description

Currently in Conpherence there is a hard UI distinction about rooms vs messages. Its roughly

  • Rooms have
    • mandatory title
    • explicit policy controls
    • create is buried behind room search (T8469)
  • Messages have
    • optional title, where title is inferred otherwise (see D13220 for latest update on how that works)
      • create workflows like "send message" on a user profile don't have them
    • policy is inferred via "participants"; basically anyone can do anything once they are a participant

There's been some issues I think would be alleviated if the distinction were removed:

  • T8469 - hard to find "create room" - should just be "create room" everywhere
  • T8485 - "conpherence makes it hard to see all active conversations" - a single list without splitting messages vs rooms would be more clear implicitly methinks

Proposal is

  • keep "send message" on a person's profile as is. infer sensible policy defaults and don't require title for that workflow.
    • this is the only place it says "send message" as the action for creating a ConpherenceThread
  • change "Messages" every else to rooms.
  • change left hand column UI to just be N most recent rooms
    • some T7589 starring should come into effect

Challenge is the isRoom() distinction is quite helpful in policy. Not immediately clear to me how the edit policy control would work in this case if non-rooms had it exposed.

Event Timeline

btrahan raised the priority of this task from to Needs Triage.
btrahan updated the task description. (Show Details)
btrahan added a project: Conpherence.
btrahan added subscribers: btrahan, chad, epriestley.

Submitted that a bit early. Basically I think the distinction here is adding some confusion. Very very open for discussion. :D

Folding this entire distinction into a modal choice at creation time seems reasonable to me.

We might need T6860 first in order to do this, so the "Edit Policy" can be set to "members of this thread" by default, but I think that's reasonable (not too hard to build, has other use cases in other applications).

(And likewise for View Policy.)

Oh, I guess T5681 is the better fit, although the two are closely related.

btrahan triaged this task as Normal priority.Jun 9 2015, 6:53 PM
btrahan moved this task from Backlog to v3 on the Conpherence board.

One issue I hadn't thought about with using T5681 for this is that (without further changes) we'd have to create a new custom Policy object for every private thread, and they'd each be "different policies" with their own PHIDs. This would be OK for the most part, but feels a little icky.

I'm going to see if I can go a little further and let applications define "standard application policies" or something, so threads could just use some ConpherencePolicies::THREAD_MEMBERS sort of thing, similar to the existing ADMIN, USER, PUBLIC and NOONE policies.

btrahan moved this task from Backlog to v3 on the Conpherence board.
btrahan lowered the priority of this task from Normal to Low.Jun 25 2015, 10:53 PM

This is shipped from the user perspective and I didn't leave much crud around, but I hope to reduce said crud to 0 so leaving open for now.

I'm just going to close this out for now, we'll clean up any remaining crud in the next iteration.