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
