Hi, Here is how I see this feature within XWiki :
Simple feature : * not theaded * for internal use * only limited length of text is the input (no category, neighboorhood, etc.) Also, 2000 caracters is way too much IMO. I would go more for 170 - 200 words. If this is more than that, it should be a page or something else, but this is not a status anymore. No need to share the status with a client. What is needed first is page sharing (edition by the client using a validation key in the URL for eg). Not integrated to twitter. That is an internal and enterprise oriented feature. To ease link publising we could have an autocomplete feature. Just a piece of JS, not the WYSIWYG. It would suggest links to pages an even attachments. Concerning Caty's proposal on the incubator: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/UserStatusScrap I like the consistency with current activity stream. I also think that instead of stressing the user or the application that published a status, actual status should be stressed (put in first position and other texts with smaller size and fader color) Thanks -- Thibaut On Mon, Dec 6, 2010 at 1:32 PM, Ricardo Rodriguez [eBioTIC.] < [email protected]> wrote: > > > Sergiu Dumitriu wrote: > > On 11/24/2010 04:12 PM, Fabio Mancinelli wrote: > > > >> Hi Caty, > >> > >> a mail to share my vision about the User Status feature. > >> > >> The main idea is to have a mechanism for users to broadcast messages > >> concerning their activities. > >> The key use cases for this are: > >> > >> 1) Fast communication between enterprise members which can replace IMs > >> and mails with user status > >> 1.1) Communicate what you are working on > >> > > > > Obvious, +1. > > > > > >> 1.2) Quick question answering and feedback gathering > >> > > > > You mean something like: > > > > BigBoss says: > > How do we get through the crisis? > > Jimmy says: > > @BigBoss reduce costs! > > Mike says: > > @BigBoss sell more! > > > > And: > > > > Jimmy says: > > @Timmy where can I get a W80 form? > > Timmy says: > > @Jimmy room 404 > > > > > >> 1.3) Interesting material dissemination > >> > > > > You mean link sharing? > > > > > >> 2) Focused discussions about a given topic > >> > > > > I'm not sure this is the best way to communicate. It might work if it > > behaves a bit like instant messaging, with updates being refreshed in > > real time. Also, for it to make sense as a discussion, it should be > > threaded. So this starts to look like Google Wave, which somehow failed. > > It might work in an intranet, but still it would diverge too much from a > > simple status update, and I'm not sure how it can be integrated nicely > > inside the current Activity UI (nor the implementation, but that's not > > critical). > > > > > >> 3) Fast communication with external clients to keep them up-to-date > >> > > > > I'm not sure I get this. Isn't an *intra*net supposed to be internal, > > inaccessible to external parties? > > > > Do you mean closed group messages, visible only in a given space? > > > > > >> In order to realize these use cases we need something that resembles > >> to Facebook's Wall or, if we look at more enterprise oriented > >> products, to SalesForce chatter (http://www.salesforce.com/chatter) > >> > > > > This is getting too far from the initial ideas. It was supposed to be > > integrated in the recent activity, as little user messages mixed among > > wiki activity. Now it looks like the main goal is user communication, > > with wiki activity on the second place. Going the Chatter way would > > imply many changes in the ActivityStream implementation, the > > {{activity}} macro, and the Recent Activity UI. > > > > I'm not saying we shouldn't try to go there, I'm only asking if we want > > to do it as the "User Statuses" sub-feature inside the Activity feature. > > > > > >> In particular: > >> > >> 1) The feature should be implemented as an internal subsystem that > >> takes advantage of the Wiki underlying model for exposing information > >> > > > > That's always the case. > > > > > >> 1.1) User status can contain reference to Wiki entities (i.e., page, > >> attachments, comments) and external links. As Jerome said in a > >> previous email, this is key. An autocompletion mechanism could help > >> making this feature more usable. > >> > > > > The full wiki syntax might be available, which includes links to > > documents/attachment. If we do that, then should the WYSIWYG be > > displayed as well? > > > > > >> 1.2) I am not sure that we need to provide an upload mechanism to > >> associate an artifact to a user status. Linking an attachment in a > >> Wiki page is sufficient in my opinion. > >> > > > > +1 for links to existing data only. We could provide a "notify this" > > checkbox in the edit/upload UI. > > > > > >> 2) It should be possible to define one or more "neighborhoods", i.e., > >> people that will receive our status updates > >> > > > > We could have activities for a space, and activities for a group. This > > means that in the group UI we could integrate a "say something" widget. > > > > Another idea is a panel which allows you to specify where to post the > > update: global (default), current space, specific space (with suggest), > > group of users (with suggest), specific user (with suggest). > > > > My fear is that the UI will be too complex, which increases the > > likelihood of users abandoning their update. If something takes too much > > to accomplish, or there are too many knobs to tinker with, then people > > will avoid that. > > > > > >> 2.1) This is something that is more powerful wrt to what we have in > >> Facebook because it would allow us to create different social-graphs > >> that can be targeted when a user status is updated > >> > >> 3) It should be possible to comment on a status update (e.g., quick > >> question answering and feedback gathering use case) > >> > > > > Is a simple "reply to this" enough? > > > > > >> 4) The user status are not tweets... I think that the number of > >> character should be limited to a reasonable high threshold (e.g., > >> 2048) > >> > > > > The current activity stream allows for 2000 characters (which usually is > > rounded to something more), so this should be OK. > > > > > >> 5) User statuses should be visible only to the users belonging to the > >> "neighborhood" targeted by the status > >> > > > > This can be done at the UI level, but it's going to be hard to protect > > it at the API level. We can do it if we change the activitystream plugin > > to expose more high level methods, like getEventsForCurrentSpace and > > getEventsForCurrentGroup, while keeping the generic methods protected > > (as they are now). I don't like this, since it introduces details about > > the high-level application inside the low-level platform. > > > > > >> 6) User statuses could be displayed using an activity stream in the > >> user's profile page and also on the home activity stream > >> 6.1) The user statuses should also appear in the Workspace home pages. > >> In this case they are configured to display the statuses of the > >> "neighborhood" implicitly defined by all the members of the workspace. > >> > >> Feedback is welcome. > >> > >> > > > > So, my two main questions: > > > > 1. Do we want to make the "User Statuses" this complex? Or do we > > separate into a simple "User Statuses" and a complex > > facebook/chatter/wave like application? > > > > I find this related with synchronous vs asynchronous communication. > Sometimes I think that it should be great to have a chat-like > application within XWiki. That way, users teaming around XWiki won't > need any other tool to establish a synchronous communication about a > work going on within XWiki or about any other topic they decide. For > instance, does it make sense to create such a service within XWiki to > allow devs use it instead of using Skype or IRC channels? Is it a matter > of decision to use this external applications or it is a matter of not > having man/woman power to create such an application within XWiki? > > I see User Statuses as an advanced asynchronous communication tool > within the XWiki environment. > > Thus, I'm more for splitting the applications are having a simple "User > Statuses" and a complex synchronous communication system. > > Thanks! > > > 2. What are the possible targets of a message? > > > > 2.1 Only neighborhoods == XWiki Groups and users > > - group:XWiki.XWikiAllGroup > > - group:XWiki.R&DGroup > > - user:XWiki.johndoe > > 2.2 Only Wiki, space or page > > 2.3 Entity references which can target different things, like: > > - somewiki > > - somewiki:somespace > > - somewiki:somespace.somepage > > - somewiki:XWiki.somegroup#XWiki.XWikiGroup > > - somewiki:XWiki.someuser#XWiki.XWikiUsers > > > > I do prefer 2.3 option. I'm thinking about XWiki pages representing > resources, a meeting room, for instance. I would like to broadcast > messages to this page on its own and/or an user or one/several groups > users concerned by them. > > > >> On Mon, Nov 22, 2010 at 2:20 PM, Ecaterina Moraru (Valica) > >> <[email protected]> wrote: > >> > >>> On Mon, Nov 22, 2010 at 15:19, Ecaterina Moraru (Valica) > >>> <[email protected]>wrote: > >>> > >>> > >>>> Hi, > >>>> > >>>> There are some features that need to be investigated during the XE 2.7 > >>>> timeframe in order to be able to integrate them in XE 3.0. > >>>> One of them is **User Statuses** and a main definition for it is: "On > top > >>>> of activity stream< > http://code.xwiki.org/xwiki/bin/view/Macros/ActivityMacro>, > >>>> create a User status& twitter integration feature" > >>>> > >>>> The question is what should we integrate and cover if we want to have > user > >>>> statuses in XE. > >>>> In order to deploy mockups I need to have some clear requirements and > uses > >>>> cases. > >>>> I create some pages on incubator that will gather this mail > discussions at: > >>>> Requirements: > >>>> > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/UserStatusRequirements > >>>> Use Cases: > >>>> > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/UserStatusUseCases > >>>> > >>>> While discussing Activity Stream design we had some design scraps for > the > >>>> status casting part > >>>> > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/UserStatusScrap > >>>> > >>>> Please share your vision. > >>>> > >>>> > >>>> > >>> Hi, > >>> > >>> Some questions I have: > >>> - is it worth it to make our own status casting or can we use directly > the > >>> Twitter API? > >>> -- do we plan to integrate other services beside Twitter in the > future? > >>> -- if we have our own service, do we plan to display Twitter logo > to > >>> identify Twitter entries? > >>> - what are the actions other users can make on a user status? > >>> -- They can comment/respond to it? right away or in the status > page? > >>> -- Can they like it? > >>> -- Can they attach something to it? > >>> - what actions should the casting box have? > >>> -- The user can enter just characters? > >>> -- How many chars? > >>> -- Can he upload a file? > >>> - what is the visibility of user statuses? > >>> -- are they available for anyone with view/edit right? > >>> - what is the location where we display the status? > >>> -- Home Activity Stream? > >>> -- User Profile? > >>> -- special gadget/macro? > >>> -- future: his vcard? > >>> > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/AvatarsProposal/vcard.png > >>> > >>> Thanks, > >>> Caty > >>> > > > > > > > > -- > Ricardo RodrÃguez > CTO > eBioTIC. > Life Sciences, Data Modeling and Information Management Systems > > _______________________________________________ > users mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/users > _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
