You mean like this? http://n2.nabble.com/XWiki-Watch---Support-for-non-RSS--tp516351p516355.html
On Thu, Jul 17, 2008 at 9:42 AM, Vincent Massol <[EMAIL PROTECTED]> wrote: > > On Jul 17, 2008, at 4:37 PM, [EMAIL PROTECTED] wrote: > > > > > Actually, > > > > while writing the roadmap for 1.1 and daydreaming about XWatch's > > future, I > > realized, once again, that Watch is not a feed reader. Potentially an > > article (let's call it "item") could be created from any source: any > > webpage (see http://jira.xwiki.org/jira/browse/XWATCH-162 ), written > > by > > the user from it's own sources (by filling in title, content, > > description) > > and, ideally, created from almost any other sources (office > > documents, pdf > > documents, emails, various markup formats (newsML, docbooks, etc), > > feel-free-to-imagine-whatever) such that XWatch becomes a complete > > watching tool. > > Because of this, we could redirect the data sources interface > > towards a > > more "sources management" approach rather than "feed reading > > approach". > > > > WDYT? > > > > Particularly, marketers & client project managers: what do you think > > about > > this approach for Watch? (_complete_ collaborative watch tool vs _rss > > feeds_ based collaborative watch tool) > > I completely agree and had the same thought some time back. > > -Vincent > > >> Hi Cati and devs, > >> > >> sorry for the late response, here are some of my thoughts: > >> * First of all, I particularly like the solution you found with the > >> in-place forms (the add feed form, the tags, comments, etc). Keep > >> in mind > >> that, if needed, we can devise a way of disabling one or more of the > >> panels (feeds panel, articles or filters) to simulate a modal > >> dialog with > >> an in-place form, so feel free to dream on about this kind of > >> solutions, > >> even if you need modal behaviour. > >> * Second, I have some observations to make regarding the > >> scalability of > >> your proposal: > >> - keep in mind that it needs to be perfectly internationalizable: > >> all > >> the text should be displayable in different languages and should > >> fit (I > >> am thinking here at the tab names in the filters panel, for example, > >> about the small space you would have to fit the add-edit feed / add- > >> edit > >> group forms). By the way, are you thinking about keeping the current > >> design with fixed column sizes (200px side columns) and article panel > >> expandable or are you thinking about percent scaling, à la Google > >> reader? > >> - the tags and keywords in the text analysis can be any word and > >> potentially any size, so I seriously doubt they will fit properly > >> in 2 > >> columns as you printed them (via Marta) > >> * Third, you should study the possibility of keeping icons > >> consistency > >> with XWiki (e.g. edit, delete icons) (via Marta) > >> * Speaking of icons, I have a personal problem with the "go to > >> original > >> article" icon. It's really hard to tell what it represents > >> (although it is > >> suggestive enough, once you figure it out) and it's very hard to > >> describe > >> in a manual / guide / tutorial, otherwise then showing it. > >> * Potentially, at one point, there will be some actions that only an > >> administrator of XWatch could do: articles archiving setup, > >> parameters > >> setup (no. of articles in the list, no. of tags in the tag cloud, > >> etc), > >> and others. Besides this, client customizations would potentially > >> need > >> such admin actions too. I would like to see your opinion about an > >> administration panel/placeholder in your interface proposal (that > >> would > >> contain some activities and would easily admit other activities to be > >> added "transparently"). In particular, where do you see this kind of > >> "control panel" placed? In the reader interface or in a wiki page, > >> accessible from both the reader interface and the portal? > >> > >> * For article "deletion": we (me and Cati and Guillaume) had a > >> somewhat > >> long fight on the chat about naming this action "delete" or not. > >> Currently, the name of this action is "trash" and it is more of a > >> "vote-against" than a delete: it is the complementary action of > >> "flag" and > >> its result is that the article is no longer displayed in the list by > >> default, this must be explicitly requested by the user from the > >> filters. > >> But the article (wiki doc & object containing the data) is not at all > >> deleted from the wiki. In contrast, the feeds deletion, groups > >> deletion, > >> keywords deletion do delete the corresponding objects from the > >> wiki. I > >> would prefer a "vote-against" like name for the article action, > >> rather > >> than a name that would suggest deletion. WDYT? As a side note, we > >> could > >> think about integrating the xwiki trash bin in watch, to have > >> recoverable > >> data. > >> > >> Cati, thanks for your work > >> xwikiers, thanks for your feedback > >> > >> Happy coding, > >> Anca Luca > >> > >>> 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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
