21 Jul
2008
21 Jul
'08
2:32 p.m.
On Jul 21, 2008, at 1:33 PM, ancapaula.luca(a)xwiki.com wrote:
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 :)
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.
Indeed, as it is described there is not the same thing. An extension to
that issue is to create a bookmarklet (à la gReader) and have the URLs
added without going to the watch page itself.
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=XWikiS…)
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). 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 .
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs