On Thu, Nov 25, 2010 at 1:41 PM, Fabio Mancinelli < [email protected]> wrote:
> On Wed, Nov 24, 2010 at 10:42 PM, Sergiu Dumitriu <[email protected]> > 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. > > > Yes, this was a pretty trivial use case :) > > >> 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 > > > Yes... > Or something like > > Fabio: I need to prepare a technical presentation about XWiki, could > you tell me where I can find material about the architecture? > Sergiu: You can look here: > http://platform.xwiki.org/xwiki/bin/view/DevGuide/Architecture or here > ... > > >> 1.3) Interesting material dissemination > > > > You mean link sharing? > > > Yes. > > >> 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). > > > I see your point and actually I agree. > When I thought about focused discussions I was thinking about a topic > that doesn't need a wiki page but still needs feedback. > But in this case we might be in the use case of "quick information > gathering" > > >> 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? > > > Yes, but imagine that a project manager wants to communicate his > statuses to the client he is working with. > > > Do you mean closed group messages, visible only in a given space? > > > Yes, finally this boils down to be able to target a specific group of > users, what I called "neighbourhood", which in this case they are > client that somehow have access to a restricted part of the system > (provided that this is feasible and that can be handled at the > platform level) > > >> 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. > > > As Gregory said, we don't have to copy chatter. > However I have always thought that user statuses implied a certain > degree of communication, unless we are talking of a very simple usage > where users, for example, only updates statuses with messages like > "Today the weather is good!" > > If we think about the "Interesting material dissemination" use case, I > see an interaction of this kind > > Fabio: I've find a very interesting paper about Semantic technologies. > Check it out: http:... > +-> Sergiu: You might also be interested in this: ... > +-> Vincent: Nice. Let's create a page and collect these links: > Drafts.InterestingSemanticTechnologies > > >> 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. > > > Well, this was more an indirect reply to Caty's remark where she was > asking if "it is it worth it to make our own status casting or can we > use directly the > Twitter API?" > > >> 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? > > > I don't think that the full WYSIWYG should be available, that would be > a little heavyweight from my point of view. > I would say that a text area providing a completion mechanism for > linking entities would be enough. > Same. Actually I think I would -1 having the WYSIWYG as status input. Status aren't documents, or something you would want to format. Plus you want to paste your links. Not go through the menu + dialog etc. The default box should be very simple. Just a box in my opinion, and maybe a link to show more options (targets, links, etc.) Like Fabio I think a textarea with some JS magic on top is enough. Linking entities, but also detect http:// links and automatically associate the detected link to the status (a la facebook). Jerome. > >> 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. > > > Yes, nice idea > > >> 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. > > > When I talk about neighborhoods I mean something that can also be > defined by the connections users establlish and that are orthogonal to > groups or workspaces. > If we take the twitter model, this neighborhood is defined by the > "users following me". > > What are you saying is actually what will happen in a context of a > workspace where every status sent in the "Say something" widget of the > Workspace is shown to all the members of the workspace (which, btw, is > a (sub)wiki) > > The neighborhood I was talking about here was more a personal social > network defined at the user level. > > > 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). > > > Yep. > > Just a little remark, when you talk about "group of users" this can be > by default the "users following me". And it could also be the default > if not overridden. > > The point here is if we want to implement the "following/follower" > mechanism or if we just say that every status update is broadcasted to > all the users. > The "following/follower" is a feature that allows the user to define > his/her own social network that is orthogonal to existing groups and > workspaces. > > Quick question: When you say that the target of the post is a page, > wdym exactly? I understand quite well the other items, but what > happens whey I send a status update to a page? > > > 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. > > > Definitely. I agree. > > >> 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? > > > Well, unless I am missing something, this is the idea. > I see replies appear à la Facebook though. > > >> 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. > > > 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. > > > I think that this needed only if we want to go to the > "following/followers" way or if we want to target wiki-groups. > If we think to workspaces, for example, they will be stand-alone > (sub)wikis so every message sent in the context of a workspace will be > broadcasted globally (i.e., to all the users of the workspace). > > On the other hand, why not creating a new component/API that exposes > this kind of information and that can be used by the activity stream > instead of putting it directly in the activity stream plugin? > > >> 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 think that the we should definitely start with the "simple" version > that can be a version > where everything is broadcasted globally and where the user can be > helped with an auto-completion mechanism when posting references to > pages. > > I think also that the user status reply is a very important feature > that should be taken into account. > > > 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 was thinking more about neighbourhoods (global wiki, groups, users, > or "followers") > > Thanks, > Fabio > > >> > >> 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 > > > > > > -- > > Sergiu Dumitriu > > http://purl.org/net/sergiu/ > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
