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
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
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) Happy coding, Anca Luca
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
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
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
You mean like this? http://n2.nabble.com/XWiki-Watch---Support-for-non-RSS--tp516351p516355.html
Yes, the idea has been in the air for a while (there are multiple mails talking about parts of it). And, to answer you: sort of but with a different nuance: the "folder creation from RSS feed" would be a feature of watch's "sources management component" rather than "adding random articles and own documents" a feature of the "feed reading component" (in a "special folder" with a "special treatment and storage"). What I'm talking about is that maybe we should try to redirect Watch a little away from the "collaborative RSS reader" description, therefore the changes in the interface and presentation. Thanks for your interest and feedback, Happy coding, Anca Luca
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
Hi there, as we found out while drawing the XWatch mindmap (you can see it here : http://watch.xwiki.org/xwiki/bin/view/Design/NewUIProposal ) the intelligence gathering & analysis process offered by XWiki Watch includes 4 steps : 1. Retrieve information 2. Sort & enrich information 3. Filter information 4. Export / Publish information Right now, XWiki Watch offers 2 major innovations (at least from my PoW) : 1. Articles can be sorted, commented, tagged (the "sort & enrich" part) by a community of users rather than by only 1 user (as in common feed readers such as Google Reader or Netvibes) 2. Information can then be aggregated using filters (say, "all articles matching a given tag that have been commented on") and exported towards information consumers so that they can benefit from the wisdom of the watch team (relying on human filtering rather than the automatic filtering offered by most intelligence software out there) A third, important point is that the wiki can be used as a portal to display information relevant to users (therefore making point 4) innovative as well). So as we can see the weakest point of XWiki Watch right now is indeed the first one : retrieve information, since it can only be done through RSS Feeds at this time. We can do this in a number of ways : 1. Allow more feed formats than only RSS (say, NewsML for instance) 2. Allow more formats than feeds (bring in a single webpage or a quote from a webpage) 3. Allow more formats than only pre-existing content (an fresh idea coming from someone within the organization) Therefore we need to decide which one is the most important and how it could be implemented : Anca lists a number of ways this can be done, for instance providing an interface in the portal where users could contribute articles using the title / summary / content template, that would then be displayed in the reader interface. I will start working with Anca (and all of you guys) to organize this discussion and transform it into roadmap & milestones as soon as I get back from holiday :-) Guillaume On Thu, Jul 17, 2008 at 5:07 PM, <[email protected]> wrote:
You mean like this?
http://n2.nabble.com/XWiki-Watch---Support-for-non-RSS--tp516351p516355.html
Yes, the idea has been in the air for a while (there are multiple mails talking about parts of it).
And, to answer you: sort of but with a different nuance: the "folder creation from RSS feed" would be a feature of watch's "sources management component" rather than "adding random articles and own documents" a feature of the "feed reading component" (in a "special folder" with a "special treatment and storage").
What I'm talking about is that maybe we should try to redirect Watch a little away from the "collaborative RSS reader" description, therefore the changes in the interface and presentation.
Thanks for your interest and feedback, Happy coding, Anca Luca
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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=XWikiSA...) I don't know how others in XWiki are using XWatch but I have the feeling we could learn a lot from that. 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. 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). </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
On Jul 21, 2008, at 10:00 AM, Vincent Massol 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=XWikiSA...)
I don't know how others in XWiki are using XWatch but I have the feeling we could learn a lot from that.
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.
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). </roadmap/general ideas>
WDYT?
BTW this is starting to remind me of Omea... See http://www.jetbrains.com/omea/ and http://blogs.codehaus.org/people/vmassol/archives/000869_omea_pro_review.htm... -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
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=XWikiSA...)
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 .
</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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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=XWikiSA...)
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
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=XWikiSA...)
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.
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.
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (5)
-
ancapaula.luca＠xwiki.com -
Guillaume Lerouge -
Squirrel -
Vincent Massol -
★Ecaterina Valica