Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-4010

Make news posts simply labelled pages and allow all pages to be accessed by date

    • We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.

      At present, you can only really get to a news page by it's date. The fact that news pages are so different to normal pages can be confusing for many users (eg. the question keeps getting asked: "how to i create a link to my news page") - people expect linking to a news page to be the same as linking to a normal page (eg. via title).

      Could news pages be perfectly normal pages but with a label of "news" in 1.5?

      If so, you could then choose which labels would show the calendar - eg. you might want "annoucements" and "news" to show the calendar.

      News pages, now being normal pages with a set label, could be linked to like everything else.

      When putting in a date URL it would simply list all pages who's label is set to associate them with a calendar (unless specifying a specific label in the URL in which case it would list all pages with that label on that date regardless of whether they are associated with a calendar).

      This would, for example, allow you to browse changes to a site using the calendar - you'd see on the calendar when pages where changed, click the date and it would show or list the pages for that date.

      Although this idea is embryonic, I tink it would help standardise the way everything works and add lots of flexibility if further developed.

      Any comments?

            [CONFSERVER-4010] Make news posts simply labelled pages and allow all pages to be accessed by date

            BillA added a comment -

            Thank you for raising this issue. While I can see how this feature would be useful, we have no plans to implement it in the foreseeable future. In order to set expectations, we're closing this request now. Thanks again for your idea.

            BillA added a comment - Thank you for raising this issue. While I can see how this feature would be useful, we have no plans to implement it in the foreseeable future. In order to set expectations, we're closing this request now. Thanks again for your idea.

            This improvement also enable users to have blikis in confluence (http://en.wikipedia.org/wiki/Bliki).

            Ricardo Mayerhofer added a comment - This improvement also enable users to have blikis in confluence ( http://en.wikipedia.org/wiki/Bliki ).

            Ricardo Mayerhofer added a comment - - edited

            Confluence is a great tool, but is increasing in complexity as more and more features are added.
            This feature is a great deal in order to simplify its use.

            Ricardo Mayerhofer added a comment - - edited Confluence is a great tool, but is increasing in complexity as more and more features are added. This feature is a great deal in order to simplify its use.

            AudraA added a comment -

            We have a long term goal to make our content use the same infrastructure internally, and that would make this feature easier to implement. We would like to simplify content, however this is quite a large amount of work. We will review this feature for a future release.

            If you're interested to know how we decide on which features to implement, please read this:
            http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements

            AudraA added a comment - We have a long term goal to make our content use the same infrastructure internally, and that would make this feature easier to implement. We would like to simplify content, however this is quite a large amount of work. We will review this feature for a future release. If you're interested to know how we decide on which features to implement, please read this: http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements

            Yup, a good example of the issues of having news and pages seperate. You should already be able to edit news posts (although not rename them) and add labels to them in Confluence 2.1.2.

            If news was simply just pages with a "news" label, then you could do everything you can do to pages and easily add additional labels to further categoriese the news. You'd be able to add news where it's logical to do so within the hierarchy of your space content (ie. add news as child pages directly to the project it relates to). A generic chronological browser would still allow date-based browsing of news, but would also then allow any other content to be included if desired.

            If you want to take the red pill, this will make interesting reading: http://confluence.atlassian.com/display/DISC/Guy%27s+Wishlist+for+Confluence+3

            Guy Fraser [Adaptavist.com] added a comment - Yup, a good example of the issues of having news and pages seperate. You should already be able to edit news posts (although not rename them) and add labels to them in Confluence 2.1.2. If news was simply just pages with a "news" label, then you could do everything you can do to pages and easily add additional labels to further categoriese the news. You'd be able to add news where it's logical to do so within the hierarchy of your space content (ie. add news as child pages directly to the project it relates to). A generic chronological browser would still allow date-based browsing of news, but would also then allow any other content to be included if desired. If you want to take the red pill, this will make interesting reading: http://confluence.atlassian.com/display/DISC/Guy%27s+Wishlist+for+Confluence+3

            We have started writing up all meeting notes on our Wiki and we very quickly got stuck in the 'is this news or a page' debate. If it was created as news then we could browse meeting notes through the calendar. However, news has all the limitations described in this issue:

            • we like to collaborate on meeting notes, but a news article cannot be edited
            • similarly what happens when an important thought was left out and needs to be added later...
            • we'd like to be able to easily link to meeting notes
            • news articles can't be children of a page

            What I'd really like is to have a 'meetingnotes' label that I can attach to any meeting notes (or better still done automatically in a 'meeting note' template). When the notes are 'done' they would then be posted as a news article. Finally, at any time anyone can browse the content using a calendar to find the meeting notes for a given day (i.e. the day of the meeting, not the last modified date).

            Andy Armstrong added a comment - We have started writing up all meeting notes on our Wiki and we very quickly got stuck in the 'is this news or a page' debate. If it was created as news then we could browse meeting notes through the calendar. However, news has all the limitations described in this issue: we like to collaborate on meeting notes, but a news article cannot be edited similarly what happens when an important thought was left out and needs to be added later... we'd like to be able to easily link to meeting notes news articles can't be children of a page What I'd really like is to have a 'meetingnotes' label that I can attach to any meeting notes (or better still done automatically in a 'meeting note' template). When the notes are 'done' they would then be posted as a news article. Finally, at any time anyone can browse the content using a calendar to find the meeting notes for a given day (i.e. the day of the meeting, not the last modified date).

            Making news = pages would facilitate any future development along these lines:

            http://confluence.atlassian.com/display/DISC/Confluence+as+a+Forum

            Guy Fraser [Adaptavist.com] added a comment - Making news = pages would facilitate any future development along these lines: http://confluence.atlassian.com/display/DISC/Confluence+as+a+Forum

            Wow. Thanks for that huge write-up, Guy. We'll mull over it and see how we go!

            Jeremy

            Jeremy Higgs added a comment - Wow. Thanks for that huge write-up, Guy. We'll mull over it and see how we go! Jeremy

            CONF-3773 - why have podcasting just for news?

            Guy Fraser [Adaptavist.com] added a comment - CONF-3773 - why have podcasting just for news?

            CONF-1062 = Email a page = probably wanted for news items as well = why do it twice?

            Guy Fraser [Adaptavist.com] added a comment - CONF-1062 = Email a page = probably wanted for news items as well = why do it twice?

            Ok, I've had some more time to think about this and also had some feedback from additional confluence users (both staff, clients and people on the list). I've also had a quick trawl through JIRA and the conf-user archive to gather related issues, URL's and ideas.

            Benefits:

            • Make things easier to understand for the end user - As programmers we can sometimes consider something too difficult and in making coding easier for ourselves pass our problem on to the peope who we are actually coding for - the end user.
            • Easily link to news item (although you would no longer be able to have duplicate news item names, I think being able to link to news more easily would be very useful) - note: see CONF-5186 and also notes and URL's below.
            • Be able to rename a news item (rather than realise you've made a typo and have to copy the content, delete the item, create a new item with correct title, moan about the date not being the same and having no way to change that, pasting the content, saving the item, explaining why a week old news item has suddenly jumped to the top of the list, etc., etc.)
            • Being able to move/copy news items just as you can with pages.
            • Use templates in news items - a very common requirement.
            • Use the vast array of "page" related macros to also get at news.
            • Place news anywhere in the page hierarchy yet still be able to see a list of all news items by simply looking at a list of pages with the "news" tag.
            • Re: Above, that means news can be placed where it's relevant within a space (because you can still get central news lists) so people who frequent that place are more likely to encounter it
            • You could turn things in to news (or not news) at a whim - I might add a really important documentation page to answer a current common question or problem, and want it to appear as news for a few weeks. Once it's no longer relevant as news (it's merely just content that people will use occasionally after the initial rush), I can remove the news label.
            • Much cleaner documentation - remove the whole news section apart from one page: How to create news/blogs: Just add the "news" label and if you want categories, add additional labels as desired. = Less for new user to learn, quicker, simpler, easier.
            • Use macros like {add-page}

              and

              {link-page}

              for working with news items (they'd only need a new "labels" param for setting initial labels and they could then be used for all kinds of additional things).

            • Much cleaner internal codebase - news and pages are essentially the same thing so why have all that duplicated code and a mis-match on what can be done in news vs. pages that makes no sense to the end-user?
            • Less debugging as a result - if pages work, then you are sorted. Bugs like this would not exist (or be much quicker to fix): http://confluence.atlassian.com/display/DOC/mail/120566 - No need to worry about trying to wire in similar functionality in to news and dealing with the bugs (and new ones) all over again. So, more time to spend making pages even better. More time to spend adding label support to macros as you no longer need to worry about news objects.....

            Disadvantages:

            • Lots of extra work for Atlassian - but long term benefits due to simplified code base and macros
            • Problems with news articles with same name (see later and also possibly CONF-5186)
            • Some community macros would be affected (especially many of David Peterson's macros)

            Backwards Compatibility:

            • blog-posts macro would be maintained merely for backwards compatibility and be re-wired behind the scenes to look for pages with the "news" label
            • the news rss (blogrss.action) would do the same - simply list pages with a "news" label
            • same goes for viewrecentblogposts.action
            • Putting in a date URL would simply show the chronological page browser for that date/month/year
            • existing news items would be converted to pages (with "news" label added) - any with duplicate names would have to have the date appended to the title (at the start "yyyy-mm-dd" so a simple alpha sort would sort them by date order)?
            • Any macros that deal with news would now have to deal with pages + "news" label. Any macros that deal with news permissions would be tweaked to look at page permissions instead.
            • There will be others that I've not thought of, but all should be simple to deal with (if timeconsuming), especially if a helper is created to simplify things.

            Side Effects:

            • Macro developers have become used to the extra coding required for news vs. pages and probably don't see it as a chore any more and may initially resist dropping the seperate news concept. Once news = pages, however, everyone can spend more time incorporating labels support (and in some cases would be driven to do so due to the need to accomodate news)
            • It would prompt a seperate chronological browser under "browse space > pages" - the ability to filter the content by label (eg. "news" or "faq support", etc) would then result in a great feature. You'd be able to see what happened on a given date (or range, etc) and filter the browser down to what you are specifically interested in using labels. Why can't pages currently be viewed in chronological order - or comments - or attachments - etc?
            • It would finally merge the worlds of Wiki's and Blog's in to a CMS that beautifully incorporates both, and more
            • It would simplify any future task of adding some sort of "set date" feature (eg. back-dating or future-dating a page) and/or "expiry date" feature (eg. making a page move to the trash on a given date). Why would you want to do this task twice (news + pages) when you could just do it on pages?

            Some other related URL's on the subject:

            From Guy Fraser (me!) - a possibly more concise argument for news = pages: http://confluence.atlassian.com/display/DOC/mail/152172

            From David Peterson: http://confluence.atlassian.com/display/DOC/mail/131671

            A question that's asked all too often: http://confluence.atlassian.com/display/DOC/mail/130318

            More ramble and thoughts: http://confluence.atlassian.com/display/DOC/mail/131680

            Nested spaces: http://confluence.atlassian.com/display/DISC/Nested+Spaces

            Chronological browser: http://confluence.atlassian.com/display/DISC/Calendar+Integration

            There will be loads more, but my future first wife is threatening not to be unless I turn off the computer.

            Guy Fraser [Adaptavist.com] added a comment - Ok, I've had some more time to think about this and also had some feedback from additional confluence users (both staff, clients and people on the list). I've also had a quick trawl through JIRA and the conf-user archive to gather related issues, URL's and ideas. Benefits: Make things easier to understand for the end user - As programmers we can sometimes consider something too difficult and in making coding easier for ourselves pass our problem on to the peope who we are actually coding for - the end user. Easily link to news item (although you would no longer be able to have duplicate news item names, I think being able to link to news more easily would be very useful) - note: see CONF-5186 and also notes and URL's below. Be able to rename a news item (rather than realise you've made a typo and have to copy the content, delete the item, create a new item with correct title, moan about the date not being the same and having no way to change that, pasting the content, saving the item, explaining why a week old news item has suddenly jumped to the top of the list, etc., etc.) Being able to move/copy news items just as you can with pages. Use templates in news items - a very common requirement. Use the vast array of "page" related macros to also get at news. Place news anywhere in the page hierarchy yet still be able to see a list of all news items by simply looking at a list of pages with the "news" tag. Re: Above, that means news can be placed where it's relevant within a space (because you can still get central news lists) so people who frequent that place are more likely to encounter it You could turn things in to news (or not news) at a whim - I might add a really important documentation page to answer a current common question or problem, and want it to appear as news for a few weeks. Once it's no longer relevant as news (it's merely just content that people will use occasionally after the initial rush), I can remove the news label. Much cleaner documentation - remove the whole news section apart from one page: How to create news/blogs: Just add the "news" label and if you want categories, add additional labels as desired. = Less for new user to learn, quicker, simpler, easier. Use macros like {add-page} and {link-page} for working with news items (they'd only need a new "labels" param for setting initial labels and they could then be used for all kinds of additional things). Much cleaner internal codebase - news and pages are essentially the same thing so why have all that duplicated code and a mis-match on what can be done in news vs. pages that makes no sense to the end-user? Less debugging as a result - if pages work, then you are sorted. Bugs like this would not exist (or be much quicker to fix): http://confluence.atlassian.com/display/DOC/mail/120566 - No need to worry about trying to wire in similar functionality in to news and dealing with the bugs (and new ones) all over again. So, more time to spend making pages even better. More time to spend adding label support to macros as you no longer need to worry about news objects..... Disadvantages: Lots of extra work for Atlassian - but long term benefits due to simplified code base and macros Problems with news articles with same name (see later and also possibly CONF-5186 ) Some community macros would be affected (especially many of David Peterson's macros) Backwards Compatibility: blog-posts macro would be maintained merely for backwards compatibility and be re-wired behind the scenes to look for pages with the "news" label the news rss (blogrss.action) would do the same - simply list pages with a "news" label same goes for viewrecentblogposts.action Putting in a date URL would simply show the chronological page browser for that date/month/year existing news items would be converted to pages (with "news" label added) - any with duplicate names would have to have the date appended to the title (at the start "yyyy-mm-dd" so a simple alpha sort would sort them by date order)? Any macros that deal with news would now have to deal with pages + "news" label. Any macros that deal with news permissions would be tweaked to look at page permissions instead. There will be others that I've not thought of, but all should be simple to deal with (if timeconsuming), especially if a helper is created to simplify things. Side Effects: Macro developers have become used to the extra coding required for news vs. pages and probably don't see it as a chore any more and may initially resist dropping the seperate news concept. Once news = pages, however, everyone can spend more time incorporating labels support (and in some cases would be driven to do so due to the need to accomodate news) It would prompt a seperate chronological browser under "browse space > pages" - the ability to filter the content by label (eg. "news" or "faq support", etc) would then result in a great feature. You'd be able to see what happened on a given date (or range, etc) and filter the browser down to what you are specifically interested in using labels. Why can't pages currently be viewed in chronological order - or comments - or attachments - etc? It would finally merge the worlds of Wiki's and Blog's in to a CMS that beautifully incorporates both, and more It would simplify any future task of adding some sort of "set date" feature (eg. back-dating or future-dating a page) and/or "expiry date" feature (eg. making a page move to the trash on a given date). Why would you want to do this task twice (news + pages) when you could just do it on pages? Some other related URL's on the subject: From Guy Fraser (me!) - a possibly more concise argument for news = pages: http://confluence.atlassian.com/display/DOC/mail/152172 From David Peterson: http://confluence.atlassian.com/display/DOC/mail/131671 A question that's asked all too often: http://confluence.atlassian.com/display/DOC/mail/130318 More ramble and thoughts: http://confluence.atlassian.com/display/DOC/mail/131680 Nested spaces: http://confluence.atlassian.com/display/DISC/Nested+Spaces Chronological browser: http://confluence.atlassian.com/display/DISC/Calendar+Integration There will be loads more, but my future first wife is threatening not to be unless I turn off the computer.

            If the templating system could control the title of the page, you could automatically generate datestamped titles. Removing the need for the 'blog-posts' concept as a way of dealing with pages that cant really have much more of a title than 'Weekly Meeting'.

            Alain Moran added a comment - If the templating system could control the title of the page, you could automatically generate datestamped titles. Removing the need for the 'blog-posts' concept as a way of dealing with pages that cant really have much more of a title than 'Weekly Meeting'.

            And in relation to CONF-2524, it's more a discussion on unique page names not being possible - the date example is merely showing two page names with the same date: "20050105 Meeting"

            The solution being some sort of "if a page has the same name, show a list including the parent page, but don't allow two pages with the same name and the same parent"

            Guy Fraser [Adaptavist.com] added a comment - And in relation to CONF-2524 , it's more a discussion on unique page names not being possible - the date example is merely showing two page names with the same date: "20050105 Meeting" The solution being some sort of "if a page has the same name, show a list including the parent page, but don't allow two pages with the same name and the same parent"

            While on the subject, here's another link: http://forums.atlassian.com/thread.jspa?forumID=96&threadID=8681

            Guy Fraser [Adaptavist.com] added a comment - While on the subject, here's another link: http://forums.atlassian.com/thread.jspa?forumID=96&threadID=8681

            "The main gripe I have with News is that it's a pain to link to because of that date in the link location. I can never remember the date for common news items and always have to go searching for them, ofthen by date which is a real pain, just so I can create a link to them. "

            Now go tell everyone that on CONF-2524

            Charles Miller (Inactive) added a comment - "The main gripe I have with News is that it's a pain to link to because of that date in the link location. I can never remember the date for common news items and always have to go searching for them, ofthen by date which is a real pain, just so I can create a link to them. " Now go tell everyone that on CONF-2524

            We store meeting notes also, but had always used pages with titles in the format: yyyy MM dd - Meeting: <title>

            I've heard several discussions regarding some sort of quality control process being made available in Confluence - this non-mandatory feature, if added, will allow pages to be marked as "final" verison etc. In addition, page permissions can be used to restrict further edits to pages.

            Guy Fraser [Adaptavist.com] added a comment - We store meeting notes also, but had always used pages with titles in the format: yyyy MM dd - Meeting: <title> I've heard several discussions regarding some sort of quality control process being made available in Confluence - this non-mandatory feature, if added, will allow pages to be marked as "final" verison etc. In addition, page permissions can be used to restrict further edits to pages.

            Eric Jain added a comment -

            One thing we frequently use news items for (or would like to use them for...) is for reporting on regular meetings. The only way to get unique titles for these to be unique (without being overly creative) is to include the date in the title somehow. The news item mechanism seems like an effective way to ensure that dates are represented in a consistent way across spaces.

            It's also nice to have a mechanism to distinguish pages that are meant to be edited and further developed from pages that are not meant to be changed (though this could probably also be accomplished by having some kind of "state" associated with each page).

            Eric Jain added a comment - One thing we frequently use news items for (or would like to use them for...) is for reporting on regular meetings. The only way to get unique titles for these to be unique (without being overly creative) is to include the date in the title somehow. The news item mechanism seems like an effective way to ensure that dates are represented in a consistent way across spaces. It's also nice to have a mechanism to distinguish pages that are meant to be edited and further developed from pages that are not meant to be changed (though this could probably also be accomplished by having some kind of "state" associated with each page).

            How often will news items have the same title? Being generally less frequent than pages, the problem of duplicate titles is more often experienced with pages than with news. To date, I've never seen a single news site that has the exact same title used more than once - ever. There will obviously be some cases where this will happen, but I would venture that they are the distinct minority.

            As for back-dating and date ranges, I know David Peterson was working on a "Temporal Plugin" for Confluence but requires some alterations to the internal API's, etc., to get it all working properly. This plugin would allow back-dating, future dating, and end-dating, etc.

            The main gripe I have with News is that it's a pain to link to because of that date in the link location. I can never remember the date for common news items and always have to go searching for them, ofthen by date which is a real pain, just so I can create a link to them.

            It would be relatively straight forward to create a chronological browser in the "Pages" tab that would allow you to browse content by date. Being able to specify a filter, eg. "news" label, would allow you to just scan the news by date.

            Guy Fraser [Adaptavist.com] added a comment - How often will news items have the same title? Being generally less frequent than pages, the problem of duplicate titles is more often experienced with pages than with news. To date, I've never seen a single news site that has the exact same title used more than once - ever. There will obviously be some cases where this will happen, but I would venture that they are the distinct minority. As for back-dating and date ranges, I know David Peterson was working on a "Temporal Plugin" for Confluence but requires some alterations to the internal API's, etc., to get it all working properly. This plugin would allow back-dating, future dating, and end-dating, etc. The main gripe I have with News is that it's a pain to link to because of that date in the link location. I can never remember the date for common news items and always have to go searching for them, ofthen by date which is a real pain, just so I can create a link to them. It would be relatively straight forward to create a chronological browser in the "Pages" tab that would allow you to browse content by date. Being able to specify a filter, eg. "news" label, would allow you to just scan the news by date.

            Eric Jain added a comment -

            One of the useful aspects of news items is that you don't need to worry about unique titles. So you can simply post your "Meeting Report" rather than "2005-12-01 Meeting Report". The problem with latter is that everyone comes up with different solutions for indicating the date. Confluence standardizes this by enforcing "/2005/12/01/Meeting Report", which in my opinion is a good thing. The only big issue at the moment is that you can't backdate news items.

            It would of course also be useful if Confluence had an extensible metadata system that allowed one or more different kinds of dates – or even date ranges – to be associated with individual pages.

            Eric Jain added a comment - One of the useful aspects of news items is that you don't need to worry about unique titles. So you can simply post your "Meeting Report" rather than "2005-12-01 Meeting Report". The problem with latter is that everyone comes up with different solutions for indicating the date. Confluence standardizes this by enforcing "/2005/12/01/Meeting Report", which in my opinion is a good thing. The only big issue at the moment is that you can't backdate news items. It would of course also be useful if Confluence had an extensible metadata system that allowed one or more different kinds of dates – or even date ranges – to be associated with individual pages.

            Both news and pages are updatable - the frequency of updates for some pages is less than that of some news and vice versa.

            In many respects, a page is relevant at the time it is added, but quickly becomes out of date. The only minor difference is that people often decide to update pages whereas they choose not to update news items. Still, there are many pages that in themselves are static - take user guides for example, the Confluence 1.4 user guide will not get updated that much more because it's been superceeded by the Confluence 2.0 user guide.

            Being able to access pages and news by date would allow the user to say "what happened on this date" or even "what happened last week" or "what happened between these two dates" in a much more logical fashion because it would be more obvious that both items are linked to time.

            Being able to link to news by page title is also critical IMHO - the fact that you have two types of information in the exact same format yet one is linked to by title and the other is linked to by the title prefixed by a date, is confusing to say the least.

            Why can't news be linked to by it's title (just like pages)? Why is the date so important? It's the news story that people are after, they don't necessarily care or remember what date it was on.

            To me the major aspect of the chronological element of news items is to set an order - "news item A came before news item B". That's all. When people are browsing news, they rarely interact with the calendar - they just use the next/prev buttons to get from one news item to the next. I'm guessing they'd like an "up" button so they could see the list of related news items (like a

            {children} macro on a parent page).

            A special news label would also allow duality of something that's a page and a news item - for example, Adaptavist would like to be able to temporarily make the documentation for a new plugin an announcement in our news area - we could do this by adding the "news" label for a week or two, then removing it.

            The "Add news" link could simply create a new page with a pre-defined "news" label.

            The only key downsides I can think of are:

            1. How do you set the permission as to who can add news to a space? Then again, does this permission matter - how often is there a user with "add news" and NOT "add page" privs?

            2. The calendar - would it just simply dissapear OR would there be a new "Chronological" section in Browse Space > Pages? You go in and you can browse all content by date

            3. How are news items ordered? This is merely a portion of the bigger question as to "how are pages ordered" - for example, I create a feature tour and I want the {scrollbar} to navigate through those pages in a custom order set by me ({children}

            , and other similar macros would also see this custom order)... etc.

            Guy Fraser [Adaptavist.com] added a comment - Both news and pages are updatable - the frequency of updates for some pages is less than that of some news and vice versa. In many respects, a page is relevant at the time it is added, but quickly becomes out of date. The only minor difference is that people often decide to update pages whereas they choose not to update news items. Still, there are many pages that in themselves are static - take user guides for example, the Confluence 1.4 user guide will not get updated that much more because it's been superceeded by the Confluence 2.0 user guide. Being able to access pages and news by date would allow the user to say "what happened on this date" or even "what happened last week" or "what happened between these two dates" in a much more logical fashion because it would be more obvious that both items are linked to time. Being able to link to news by page title is also critical IMHO - the fact that you have two types of information in the exact same format yet one is linked to by title and the other is linked to by the title prefixed by a date, is confusing to say the least. Why can't news be linked to by it's title (just like pages)? Why is the date so important? It's the news story that people are after, they don't necessarily care or remember what date it was on. To me the major aspect of the chronological element of news items is to set an order - "news item A came before news item B". That's all. When people are browsing news, they rarely interact with the calendar - they just use the next/prev buttons to get from one news item to the next. I'm guessing they'd like an "up" button so they could see the list of related news items (like a {children} macro on a parent page). A special news label would also allow duality of something that's a page and a news item - for example, Adaptavist would like to be able to temporarily make the documentation for a new plugin an announcement in our news area - we could do this by adding the "news" label for a week or two, then removing it. The "Add news" link could simply create a new page with a pre-defined "news" label. The only key downsides I can think of are: 1. How do you set the permission as to who can add news to a space? Then again, does this permission matter - how often is there a user with "add news" and NOT "add page" privs? 2. The calendar - would it just simply dissapear OR would there be a new "Chronological" section in Browse Space > Pages? You go in and you can browse all content by date 3. How are news items ordered? This is merely a portion of the bigger question as to "how are pages ordered" - for example, I create a feature tour and I want the {scrollbar} to navigate through those pages in a custom order set by me ({children} , and other similar macros would also see this custom order)... etc.

            The main issue I see is that a page can be changed from a regular page to a news item at a whim. Now, it may just be me, but IMHO a news item is of a different nature to a page. A news item is relevant at the time it is posted and rarely changes afterwards. A page is 'up-to-date' and is constantly updated (or at least, is updatable - how well it is actually kept current is another issue). As such, I'm not really comfortable with being able to casually turn one into the other...

            David Peterson added a comment - The main issue I see is that a page can be changed from a regular page to a news item at a whim. Now, it may just be me, but IMHO a news item is of a different nature to a page. A news item is relevant at the time it is posted and rarely changes afterwards. A page is 'up-to-date' and is constantly updated (or at least, is updatable - how well it is actually kept current is another issue). As such, I'm not really comfortable with being able to casually turn one into the other...

            The more I think about this issue, the more I'm convinced it's a good idea.

            Charles Miller (Inactive) added a comment - The more I think about this issue, the more I'm convinced it's a good idea.

            I am excited by this line of thought, seems to me it is likely to blossom into some very cool new capability in Confluence. I just posted some similar thoughts: http://confluence.atlassian.com/display/DISC/Calendar+Integration

            Larry Talley added a comment - I am excited by this line of thought, seems to me it is likely to blossom into some very cool new capability in Confluence. I just posted some similar thoughts: http://confluence.atlassian.com/display/DISC/Calendar+Integration

              Unassigned Unassigned
              gfraser@adaptavist.com Guy Fraser [Adaptavist.com]
              Votes:
              45 Vote for this issue
              Watchers:
              30 Start watching this issue

                Created:
                Updated:
                Resolved: