This is a link to age maps.
Thursday, December 28, 2006
Age Maps: Interesting
Yeah, I know this is hardly PR related, but it was cool enough to share.
This is a link to age maps.
This is a link to age maps.
Friday, December 15, 2006
The Power of Pause
I ran into this great blog entry from Signal & Noise entitled Apologies Bad, Pauses Good.
The article notes that pauses are a great way to bide some time while thinking of a meaningful response to questions. I might add that pauses can also be a great way to focus attention in a delivery. Silence is a very powerful aid. It causes people to become uncomfortable and uneasy. They will typically be looking for something to fill the void and as a result your next words will become even more attentively heard.
On a more ethereal note I think that many people forget pauses, or silence in life can be a wonderful rest in an otherwise busy world. We tend to neglect silence. As Desiderata says, "remember what peace there may be in silence." If we would simply turn the TV, radio, cell, podcasts, etc., off for just a brief moment we could attend to some much needed rest. I suppose many people are afraid of silence or think that it will be boring.
I suggest taking just a few minutes of the day to think for instance on the fact that you have food, water, shelter, and a warm bed. Many, many people in this world do not. They are forced to worry about these on a daily basis. Take a moment to pause, unplug and appreciate everything that you don't have to worry about.
The article notes that pauses are a great way to bide some time while thinking of a meaningful response to questions. I might add that pauses can also be a great way to focus attention in a delivery. Silence is a very powerful aid. It causes people to become uncomfortable and uneasy. They will typically be looking for something to fill the void and as a result your next words will become even more attentively heard.
On a more ethereal note I think that many people forget pauses, or silence in life can be a wonderful rest in an otherwise busy world. We tend to neglect silence. As Desiderata says, "remember what peace there may be in silence." If we would simply turn the TV, radio, cell, podcasts, etc., off for just a brief moment we could attend to some much needed rest. I suppose many people are afraid of silence or think that it will be boring.
I suggest taking just a few minutes of the day to think for instance on the fact that you have food, water, shelter, and a warm bed. Many, many people in this world do not. They are forced to worry about these on a daily basis. Take a moment to pause, unplug and appreciate everything that you don't have to worry about.
Thursday, December 14, 2006
Converting SMPR to hAtom
I have been working to try and convert my Widget SMPR (Social Media Press Release) to hAtom. It has proved to be very difficult.
Conceptually the SMPR is meant to present content in a PRE-distribution format. hAtom on the other hand is meant to present content in a POST-distribution format. As a result hAtom is far more simplistic in its specification since most of the content has already been aggregated into it's final form.
An SMPR spec in order to be a useful and standard specification needs to be able to describe a number of different elements in a standard way so that they may be easily distinguishable and identifiable by humans and computers in such a way that the industry can have a reliable structure.
hAtom probably would work well for the old fashioned press release which has already pieced together the various content. However, since the SMPR spec is meant more for providing prefabricated content rather than the glossy-finished-product, it seems like it would be useful to use a new spec.
For example, hAtom presumes that content is distributed in simple/non-descript groups of content (entry-content) called entries (hentry). There is no real way to distinguish (via hAtom) what the different types of content are (like New Facts, Podcasts, etc.). SMPR's however need to break down the content, like bullet points (Core News Facts) that can be used by journalists, or news fabricators, to create their own paragraphs to capture the story in their own way. hAtom does not provide a standard way to distinguish these content pieces. It is of course possible to extend hAtom by marking-up your SMPR with other formatting, but again, this is not in a standard format and so it becomes useless to the industry who is looking for a standard presentation.
The purpose of hAtom although great as a news post-distribution specification, does not seem to solve for the needs of the SMPR. Perhaps the hAtom people can lend a hand if I am missing something. For now I am leaning more toward the creation and adoption of an additional microformat, hRelease. Naturally it would be wise to incorporate (as per microformat best practices) other microformats like hcard, hcalendar, rel-tag, xoxo, xfn.
Conceptually the SMPR is meant to present content in a PRE-distribution format. hAtom on the other hand is meant to present content in a POST-distribution format. As a result hAtom is far more simplistic in its specification since most of the content has already been aggregated into it's final form.
An SMPR spec in order to be a useful and standard specification needs to be able to describe a number of different elements in a standard way so that they may be easily distinguishable and identifiable by humans and computers in such a way that the industry can have a reliable structure.
hAtom probably would work well for the old fashioned press release which has already pieced together the various content. However, since the SMPR spec is meant more for providing prefabricated content rather than the glossy-finished-product, it seems like it would be useful to use a new spec.
For example, hAtom presumes that content is distributed in simple/non-descript groups of content (entry-content) called entries (hentry). There is no real way to distinguish (via hAtom) what the different types of content are (like New Facts, Podcasts, etc.). SMPR's however need to break down the content, like bullet points (Core News Facts) that can be used by journalists, or news fabricators, to create their own paragraphs to capture the story in their own way. hAtom does not provide a standard way to distinguish these content pieces. It is of course possible to extend hAtom by marking-up your SMPR with other formatting, but again, this is not in a standard format and so it becomes useless to the industry who is looking for a standard presentation.
The purpose of hAtom although great as a news post-distribution specification, does not seem to solve for the needs of the SMPR. Perhaps the hAtom people can lend a hand if I am missing something. For now I am leaning more toward the creation and adoption of an additional microformat, hRelease. Naturally it would be wise to incorporate (as per microformat best practices) other microformats like hcard, hcalendar, rel-tag, xoxo, xfn.
Why Microformat a News Release?
Today's global society finds itself in a place where news, opinions, and information of any sort are no longer channeled through traditional media and news outlets, but are instead distributed through blogs, podcasts, vidcasts, and many other types of social media. Up till now the public relations and communications industries have been able to utilize the traditional press release to communicate their information. However they have quickly found it more and more complicated to find a means to package their information in a way that can best be utilized by all of these different types of media.
One clear answer to this dilemma is to create a standard format for packaging information so that it can be broken down into parts which can be presented to all forms of media. The media distributors can then review and choose those elements that they need to incorporate for their specific media distribution. For instance, let's say that Widget Inc. wants to announce that it just released a new Widget. If they practice traditional news release they will package their news information into a perfectly crafted text document. One problem, text doesn't work on a podcast. Now Widget Inc. will have to create a separate news release/recording for the podcast, and a video for youTube, a blog entry for their bloggers, etc. Why not create a format that they can use to package it all together in one place and let the distributors figure out those elements that they want?
One practical solution would be to develop an entire XML specification around all the elements that social media incorporates. This would certainly be the most thorough solution since information could traverse the internet without any concern for the platform it needs to communicate with. However, XML is a beast to learn. Implementing an industry-wide XML standard for a simple press release is a little like using an electron microscope to look at a fly's bum.
Instead, in true Microformat best practices, it makes greater sense to "pave the cow paths." In other words, since most press releases come in the form of a web page, blog entry, etc., rather than forcing an XML specification on the content, it would be much more simple to add a few less obtrusive tags into the content via Cascade Style Sheets and other XHTML elements. Most web savvy individuals out there can handle the task of adding specific CSS/XHTML formatting to their page content.
The beauty of Microformats is in their simplicity. Very little needs to be done for anyone to convert their news release into a (micro)format that is readable by media distributors/consumers as well as computers. In the rapidly changing world of the web it makes more sense to allow natural evolution to take place by incrementally and thoughtfully evolving the news release along with it. Grand slamming the news release with a full on XML stack is a recipe for frustration. Perhaps we will see a movement in that direction, but for now, let's not put the cart before the horse.
One clear answer to this dilemma is to create a standard format for packaging information so that it can be broken down into parts which can be presented to all forms of media. The media distributors can then review and choose those elements that they need to incorporate for their specific media distribution. For instance, let's say that Widget Inc. wants to announce that it just released a new Widget. If they practice traditional news release they will package their news information into a perfectly crafted text document. One problem, text doesn't work on a podcast. Now Widget Inc. will have to create a separate news release/recording for the podcast, and a video for youTube, a blog entry for their bloggers, etc. Why not create a format that they can use to package it all together in one place and let the distributors figure out those elements that they want?
One practical solution would be to develop an entire XML specification around all the elements that social media incorporates. This would certainly be the most thorough solution since information could traverse the internet without any concern for the platform it needs to communicate with. However, XML is a beast to learn. Implementing an industry-wide XML standard for a simple press release is a little like using an electron microscope to look at a fly's bum.
Instead, in true Microformat best practices, it makes greater sense to "pave the cow paths." In other words, since most press releases come in the form of a web page, blog entry, etc., rather than forcing an XML specification on the content, it would be much more simple to add a few less obtrusive tags into the content via Cascade Style Sheets and other XHTML elements. Most web savvy individuals out there can handle the task of adding specific CSS/XHTML formatting to their page content.
The beauty of Microformats is in their simplicity. Very little needs to be done for anyone to convert their news release into a (micro)format that is readable by media distributors/consumers as well as computers. In the rapidly changing world of the web it makes more sense to allow natural evolution to take place by incrementally and thoughtfully evolving the news release along with it. Grand slamming the news release with a full on XML stack is a recipe for frustration. Perhaps we will see a movement in that direction, but for now, let's not put the cart before the horse.
SMPR to hAtom Non Sequiturs
I have been working to try and convert my Widget SMPR (Social Media Press Release) to hAtom. It has proved to be very difficult.
Conceptually the SMPR is meant to present content in a PRE-distribution format. hAtom on the other hand is meant to present content in a POST-distribution format. As a result hAtom is far more simplistic in its specification since most of the content has already been aggregated into it's final form.
An SMPR spec in order to be a useful and standard specification needs to be able to describe a number of different elements in a standard way so that they may be easily distinguishable and identifiable by humans and computers in such a way that the industry can have a reliable structure.
hAtom probably would work well for the old fashioned press release which has already pieced together the various content. However, since the SMPR spec is meant more for providing prefabricated content rather than the glossy-finished-product, it seems like it would be useful to use a new spec.
For example, hAtom presumes that content is distributed in groups of content (entry-content) called entries (hentry). SMPR's however are in a completely different format. Rather than a few paragraphs capturing the story content, SMPR's break the content into bullet points (Core News Facts) that can be used by journalists, or news fabricators, to create their own paragraphs to capture the story in their own way. hAtom does not provide a standard way to distinguish these bullet points. It is of course possible to extend hAtom by marking-up your SMPR with other formatting, but again, this is not in a standard format and so it becomes useless to the industry who is looking for a standard presentation.
The purpose of hAtom as a news distribution specification does not seem to solve for the needs of the SMPR. I am leaning more toward the creation and adoption of an additional microformat, hRelease. Naturally it would be wise to incorporate (as per microformat best practices) other microformats like hcard, hcalendar, rel-tag, xoxo, xfn.
Conceptually the SMPR is meant to present content in a PRE-distribution format. hAtom on the other hand is meant to present content in a POST-distribution format. As a result hAtom is far more simplistic in its specification since most of the content has already been aggregated into it's final form.
An SMPR spec in order to be a useful and standard specification needs to be able to describe a number of different elements in a standard way so that they may be easily distinguishable and identifiable by humans and computers in such a way that the industry can have a reliable structure.
hAtom probably would work well for the old fashioned press release which has already pieced together the various content. However, since the SMPR spec is meant more for providing prefabricated content rather than the glossy-finished-product, it seems like it would be useful to use a new spec.
For example, hAtom presumes that content is distributed in groups of content (entry-content) called entries (hentry). SMPR's however are in a completely different format. Rather than a few paragraphs capturing the story content, SMPR's break the content into bullet points (Core News Facts) that can be used by journalists, or news fabricators, to create their own paragraphs to capture the story in their own way. hAtom does not provide a standard way to distinguish these bullet points. It is of course possible to extend hAtom by marking-up your SMPR with other formatting, but again, this is not in a standard format and so it becomes useless to the industry who is looking for a standard presentation.
The purpose of hAtom as a news distribution specification does not seem to solve for the needs of the SMPR. I am leaning more toward the creation and adoption of an additional microformat, hRelease. Naturally it would be wise to incorporate (as per microformat best practices) other microformats like hcard, hcalendar, rel-tag, xoxo, xfn.
Monday, December 04, 2006
Subscribe to:
Posts (Atom)