XWiki Platform
  1. XWiki Platform
  2. XWIKI-7679

Separate Message Stream input from Activity Stream

    Details

    • Difficulty:
      Unknown
    • Documentation:
      N/A
    • Similar issues:

      Description

      Adding and viewing are two separate actions. Would be nice to be able to separate the two functionalities and choose:

      • if you want to have both on the Homepage (by keeping both gadgets in the WebHome's Dashboard)
        or
      • keep just the Activity Stream on the Homepage (and have the input only in User Profile)
      • have the Message Stream input on any other Dashboard that contains the gadget
      1. after.png
        49 kB
      2. before.png
        55 kB

        Issue Links

          Activity

          Show
          Eduard Moraru added a comment - - edited Pull requests available at: https://github.com/xwiki/xwiki-enterprise/pull/22 https://github.com/xwiki/xwiki-platform/pull/48
          Hide
          Vincent Massol added a comment -

          One small comment: I'm not sure i'd call "Message stream" the widget about sending a message. Maybe just "Send Message" or "Message". It's not a stream. The message stream is viewed in the Activity stream AFAIK.

          Show
          Vincent Massol added a comment - One small comment: I'm not sure i'd call "Message stream" the widget about sending a message. Maybe just "Send Message" or "Message". It's not a stream. The message stream is viewed in the Activity stream AFAIK.
          Hide
          Eduard Moraru added a comment -

          Well, compared to the current commit, the attached images are slightly misleading.

          What I have done is to create a new

          {{messageSender/}}

          macro that allows for the "after" use case described in this issue to happen.

          • By default, the activity macro uses the new messageSender macro so the user sees the same thing as "before".
          • If you want the "after" use case, you call in the top gadget:
            {{messageSender/}}

            and in the bottom gadget:

            {{activity messageSender='false'/}}

          I hope it's clearer now.

          Show
          Eduard Moraru added a comment - Well, compared to the current commit, the attached images are slightly misleading. What I have done is to create a new {{messageSender/}} macro that allows for the "after" use case described in this issue to happen. By default, the activity macro uses the new messageSender macro so the user sees the same thing as "before". If you want the "after" use case, you call in the top gadget: {{messageSender/}} and in the bottom gadget: {{activity messageSender='false'/}} I hope it's clearer now.
          Hide
          Vincent Massol added a comment -

          Ok, I understand you did this to support backward compatibility. IMO this is not fully warranted and we could completely remove the notion of message sending from the activity macro. At the very least we could deprecate it if you really think we need to preserve backward compatibility. Maybe I missed a discussion/vote about this on the list?

          IMO this still makes it hard for a casual user to remove the ability to send messages on the home page so this issue is not fully finished. It would be nice to finish it for 4.1 final by adding a new widget and using the new macro in it and remove it from within the activity macro. You've done the hard work already so that should be a breeze if we agree about it

          Also on both the parameter name and the macro name I think it would be nice to agree/propose/vote on the names since they become API and they're hard to change thereafter.

          For example I'd personally prefer message or sendMessage or userMessage than messageSender.

          Show
          Vincent Massol added a comment - Ok, I understand you did this to support backward compatibility. IMO this is not fully warranted and we could completely remove the notion of message sending from the activity macro. At the very least we could deprecate it if you really think we need to preserve backward compatibility. Maybe I missed a discussion/vote about this on the list? IMO this still makes it hard for a casual user to remove the ability to send messages on the home page so this issue is not fully finished. It would be nice to finish it for 4.1 final by adding a new widget and using the new macro in it and remove it from within the activity macro. You've done the hard work already so that should be a breeze if we agree about it Also on both the parameter name and the macro name I think it would be nice to agree/propose/vote on the names since they become API and they're hard to change thereafter. For example I'd personally prefer message or sendMessage or userMessage than messageSender .
          Hide
          Eduard Moraru added a comment -

          This is the mail that I sent on Friday (May 29th) to the list http://markmail.org/thread/mxpkpqfplbznfgbd

          Yes, I was thinking about backwards compatibility for now and not about changing the way we do things, though I do agree with you on the direction.

          For the name, I followed the direction that the "attachmentSelector" macro introduced: "<object><personified-action>" (messageSender). The macro is action oriented, as opposed to the other macros that are display oriented ("spaces", "documents", etc.), so the name felt natural. Otherwise we need to rename "attachmentSelector" to "selectAttachment" to fit the "<action><object>" naming you propose.

          Also, the phrases "attachmentSelector macro" and "messageSender macro" sounds better to me in english than "selectAttachment macro" or "sendMessage macro" , but we can discuss it on the list.

          Will send 2 mails to the list.

          Show
          Eduard Moraru added a comment - This is the mail that I sent on Friday (May 29th) to the list http://markmail.org/thread/mxpkpqfplbznfgbd Yes, I was thinking about backwards compatibility for now and not about changing the way we do things, though I do agree with you on the direction. For the name, I followed the direction that the "attachmentSelector" macro introduced: "<object><personified-action>" (messageSender). The macro is action oriented, as opposed to the other macros that are display oriented ("spaces", "documents", etc.), so the name felt natural. Otherwise we need to rename "attachmentSelector" to "selectAttachment" to fit the "<action><object>" naming you propose. Also, the phrases "attachmentSelector macro" and "messageSender macro" sounds better to me in english than "selectAttachment macro" or "sendMessage macro" , but we can discuss it on the list. Will send 2 mails to the list.
          Hide
          Anca Luca added a comment - - edited

          About the gadget title, I just saw a snapshot now and I am not sure I would call it Send Message either. I would see it a bit more catchy and more guided towards a usecase, something like "What are you working on?", which would emphasise more the "status update" usecase than the "messaging system" usecase. Now we could discuss about which one is the main usecase but, from my pov, the rest of the UI provided for this feature guides towards the "status update" usecase (the fact that is displayed in the activity stream and not in an "inbox", the fact that there are "followers" rather than "to: cc: and bcc: " fields).

          Show
          Anca Luca added a comment - - edited About the gadget title, I just saw a snapshot now and I am not sure I would call it Send Message either. I would see it a bit more catchy and more guided towards a usecase, something like "What are you working on?", which would emphasise more the "status update" usecase than the "messaging system" usecase. Now we could discuss about which one is the main usecase but, from my pov, the rest of the UI provided for this feature guides towards the "status update" usecase (the fact that is displayed in the activity stream and not in an "inbox", the fact that there are "followers" rather than "to: cc: and bcc: " fields).

            People

            • Assignee:
              Eduard Moraru
              Reporter:
              Ecaterina Moraru (Valica)
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Date of First Response: