BP Doc save button returns users to doc directory instead of to group
Started a doc within the Test group - http://nycdh.org/groups/test-group/ . When I saved the doc, I was taken to a page on which I'm viewing the doc outside of the group ( http://nycdh.org/docs/test-2/ ) . Ideally, after saving the doc, I should be viewing it within the group interface, so that I still have the group vertical menu on the left side of the page.
#2 Updated by Matt Gold over 7 years ago
Interesting. I find it a bit confusing because one starts creating the doc in one place and then winds up in another once it is saved. It's a bit disconcerting, too, when one is creating a doc in a private group; even if the privacy is shown to be limited to that group in the new space, there is something about being in the particular space/locale of a private group that makes it feel distinct from the rest of the public site. Changing contexts from a private space to a semi-public one can be a bit jarring.
#3 Updated by Boone Gorges over 7 years ago
I agree somewhat. However, the change was made in order to make the appearance of Docs more consistent throughout an installation - ie, so that Docs created by individuals look the same as those created by groups, etc. This is important in part because Docs can be linked and unlinked with a given group, and in the future it may be possible to link a single Doc with more than one group. In any case, the plugin has been working like this for several major versions over the past year or so, with many thousands of downloads, and this is the first report I've heard like yours. That's not to dismiss it :) but only to suggest that your confusion may be idiosyncratic.
#4 Updated by Matt Gold over 7 years ago
- Status changed from Assigned to Rejected
- Assignee changed from Raymond Hoh to Boone Gorges
your confusion may be idiosyncratic.
Maybe. It's quite possible that we're seeing a difference between people whose first experience of BP Docs follows this workflow and people (like me) who have become conditioned to another workflow on the Commons. It will be interesting to consider all of this when we integrate the new version of BP Docs into the Commons, and I think we'll have to think carefully about these issues with lots of attention to UX.
Here's a question, though: since the act of saving a document changes the context in which the user is viewing it (going from a group space to a semi-public doc space), do you think that it's easy enough for users to find their way back to the group should they wish to return? Imagine a situation in which someone creates a doc and then wants to go back and write a forum post about the new doc. How easy is it for someone to do that?
FWIW, here is how I'd structure things:
Creating a doc within a group:
Doc creation: within group context
Doc save: stays within group context
Rationale: when working within a group, particularly a private group, it's important to preserve the sense of being within a private space within the larger public site; changing the context makes it harder to see the larger work of the group (what other docs it has created?) and confuses the sense of privacy (which docs are public, which ones aren't)
Creating a doc outside of a group:
I'd still have a space like the one you have where people can see all of the docs they've created (it would make sense for this to be associated with their profile)
Seems to me that this could be a space that is on the level of Blogs and Groups; or, this could be the wiki
#5 Updated by Boone Gorges over 7 years ago
I think we'll have to think carefully about these issues with lots of attention to UX.
I agree that we'll have to think carefully about it. See http://redmine.gc.cuny.edu/issues/2606
do you think that it's easy enough for users to find their way back to the group should they wish to return?
Yes. They are led to the single Doc view, which has a large, colored box at the top, which contains the group avatar and name, linked back to the group.
I can definitely see the rationale behind your proposed structure, but IMO it results in a new kind of confusion: a single kind of content (ie, Docs) can now be viewed in multiple different wrappers. This makes it far less clear that these are actually the same kinds of content, and masks the fact that they are mutable - group association is a piece of Doc metadata that can be changed, not an essential feature of the Doc.
There are also some technical reasons why things are set up the way they are. If Docs are inside of groups, it becomes impossible for a private group to have a public Doc, because BP protects the entire group wrapper. Likewise, a Doc inside of a group will have a group URL (example.com/groups/foo/docs/bar), but if the group association is ever broken or changed, the URL would have to change, and incoming links would break. Etc. None of these difficulties are impossible to overcome, but they all point toward the overall elegance of going with a unified UX for all Doc types.
#6 Updated by Matt Gold over 7 years ago
Thanks, Boone -- I appreciate the explanation and will continue to think on this. I'll also keep an ear out for thoughts from the nycdh community as it uses docs.
group association is a piece of Doc metadata that can be changed, not an essential feature of the Doc.
I hear you. I'm just not sure, though, that placing group-related docs within the group interface "masks the fact that they are mutable."
#7 Updated by Matt Gold about 7 years ago
Here's another report of confusion regarding this behavior. The report notes that "Some of our end users are getting lost and it would be terrific if they could return back to their group home page after creating a doc." I think we can take this as a sign that my confusion was not idiosyncratic and instead represents a UX issue we need to address. I'll open a ticket on Github.