On Jul 21, 2008, at 1:33 PM, [EMAIL PROTECTED] wrote: >> Hi, >> >> I've read the proposal and I like it in general. Nice work! >> >> <roadmap/general ideas> >> Stepping back a little and talking about roadmaps I think we should >> eat more our own dogfood, meaning we should use XWatch internally for >> our needs and find out what's useful for us first. This would be a >> good process to define what's useful for others too. Personally I'm >> not using any of the Watch UI right now. All I use is the resulting >> RSS feed >> (this one: >> http://watch.xwiki.com/xwiki/bin/view/WatchCode/PressReviewRss?space=XWikiSAS&flagged=0&trashed=-1&read=0&group=XWikiSAS.GroupXWikiNews&xpage=rdf&basicauth=1) >> >> I don't know how others in XWiki are using XWatch but I have the >> feeling we could learn a lot from that. > > I agree. > >> >> I think there needs to be some incentive for users to use the tool >> (the filtering/categorizing part) they'll just use it as a basic RSS >> aggregator (as I do). I don't have the full answer to that but I can >> think of several ideas: >> >> 1) Its scope could be extended so that it supports different input >> sources (as discussed previously and also by Guillaume in this >> thread): >> a) Mails from mailing lists (this would require difference actions, >> like "closed discussion", "associate jira issue", etc. >> b) Documents in a WebDAV store >> c) XWiki Documents (pages) - This could be a nice way for people to >> classify/navigate in a wiki. > > Still, I would not go for such a high degree of specificity for the > various data sources. > I would prefer a more universal approach without data source specific > handling (potentially not even being aware, at watch application > level, > about the provenience of an item) and rather design the system as > highly > customizable (so that these specific actions could be implemented > easily > as custom extensions).
Definitely. We're talking about the same thing. I'm talking about it at the user level and you're talking about it at the implementation level :) >> 2) Integration with external tools. For example if I could flag >> articles directly from my favorite RSS feed readers without having to >> open XWiki Watch I'd definitely start tagging/filtering. I think this >> could be done easily by adding HTML at the beginning or end of feeds >> provided by XWiki Watch. We could add some Flag/Comment links there >> that would open inline (Javascript - I think most feed readers would >> support that). > > One of these integrations that would enhance the accessibility and > operability of watch data is in plan for 1.1 (m1): > http://jira.xwiki.org/jira/browse/XWATCH-162 . I don't think this is the same thing. In that issue it says: "She goes to the XWatch reader and clicks on the "Add Web Bookmark button"". My point is to remove the need to go Watch and still be able to filter/ tag/comment. Thanks -Vincent >> </roadmap/general ideas> >> >> WDYT? >> >> Thanks >> -Vincent >> >> Note that solution 1) a), if done correctly could potentially solve >> our need for a forum. What I'd like right now from a forum is 2 >> things: the ability to extract some statistics (namely to list the >> top >> 10 contributors) and to tell when a thread is closed or not (it's not >> closed if the question asked has not been satisfactorily answered). I >> know we're getting a bit away from the initial Watch idea but I think >> it could broaden its usage and it would definitely fit in the >> "organize and categorize information" domain. >> >> On Jul 14, 2008, at 9:29 AM, ★Ecaterina Valica wrote: >> >>> Hi, >>> >>> The new XWatch User Interface Proposal is available at: >>> >>> http://watch.xwiki.org/xwiki/bin/view/Design/NewUIProposal >>> >>> I'd be glad to get some feedback either on the list or in comments >>> right on >>> the page. >>> I would also like to thank Anca, Guillaume and Eduard for their >>> feedback and >>> help given so far :) >>> >>> Thanks, >>> Ecaterina Valica _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
