Sunday
Apr282013
Mobile Web, Part III
Sunday, April 28, 2013 at 08:10PM Mobil Web, Part III.
This is #3 article of 4 that I am writing about the importance of MOBILE WEB, in terms of online brand development.
If you’ve missed them, you can see the two previous articles.
Mobile Web, Part I.
Mobile Web, Part II.
All (PARENTHETICAL STATEMENTS) are mine. Ha!
Why have I been harping about Mobile Web? Well, it’s becoming an epidemic in the development news trade, and let's face it — most Americans (more than 50%) sleep with their smart phones.1 So, basically it’s the last thing they touch at night and the first thing they touch in the morning [ barring significant others ;-) ].
So, as Brad Frost (http://bradfrostweb.com/) says, “As web creators, we need to embrace these trends to create worthwhile experiences that respect user’s time, or risk getting tuned out.” 2
Sara Wachter-Boettcher (SWB) says, “The future is flexible, and we’re bending with it. From responsive web design to future friendly thinking, we’re moving quickly toward a web that’s more fluid, less fixed, and more easily accessed on a multitude of devices." 3 A multitude of devices, wow! How do we deal with that? Think about all of the devices that are out there that need to get this right. The good news is that we can break it down into four types of devices, or:
Desk top, laptop, tablet and smart phone. As SWB continues to say, “. . . you have to know what each type of content is intended to accomplish before you can make decisions about how you need to treat it in different contexts."4
We have to then ask the question: Do we need to hire a content strategist to help us “funnel” the right content to the right context? My answer to that, of course, is yes. You want to avoid “forking5” your content, or have “forking” content.
And it’s true that you have different needs in different contexts, for example: if I am at home on my desktop or laptop, and I Google “Tanglewood” — I may be presented with a variety of results, such as sponsored links, or a Wikipedia article about Tanglewood, or the main site for Tanglewood. If I go to search Tanglewood from my smart phone, you get a prompt asking you if you want to go to the Tanglewood mobile site? Makes sense, doesn’t it? Maybe I want to buy tickets on the fly, or get directions that I can automatically "click on" from the mobile site to my smart phone.
Different needs in different scenarios is nothing new, but the devices are. So context affecting content will be ruling the roost for a while. In the above “Tanglewood” scenario you could also add “ advertising sponsors” to the mix by having The Red Lion Inn, be the Tanglewood mobile sponsor, as this is a place many people go to before or after concerts.You just have to keep on thinking through the scenarios.
The options are endless and will obviously help the client get over the fact that they are paying even more money to you to develop a more involved process. The issue — all of this is unavoidable, like acid rain after a volcano — you have to do it.
So, how do you begin to do this? Well, you have to look at the the experts, and to date: it’s National Public Radio’s (NPR) COPE (Create Once, Publish Everywhere) Process.6 Think of content in a different way — more like expandable “info-chunks” rather than specific information that is placed in a specific place. NPR dices it up into four specific info-chunks: title, short slug, longer description, and date line.
One of the biggest projects that I ever worked on was the development ofHometownstores.com (now sold and defunct). It was based upon a Boston South Shore Ace hardware chain (See current shot in Figure 1). We had 56,000 products where we had two different product descriptions: short and long. We had to figure out how to use this as it came directly from Ace, and we also had to add product images, pricing and inventory into the mix. It was amazingly complex, but we did it without thinking too much about it. We did it because we had to and really didn’t know better.
I guess the point of all of this is that it is all hard work. But it matters. It matters very much.
As Cameron Koczon says, “...as users spend more time on consumption-oriented devices (another story) like iPads and mobile (smart) phones — new demands are being put on content.”7
You also may say that this is going to be a big pain in the butt, until we figure out which way is North. How can we do this? How can we add more time to the development cycle? Well, according to NPR they have “...a small staff and limited resources.”8 The below diagram represents NPR’s content management pipeline. It is a thing of beauty to study, like a Monet.
NPR states that the COPE method incorporates:
Integrating CMS
The purpose of a good CMS is to allow you to present content in variable presentations formats on-demand. WPT’s are often dependent upon plug-ins to the native code to allow for alternate platform destinations, which often don’t make them scalable the way you’d like. A true CMS should be able to be captured and delivered to any existing or future destination. (WordPress has issues with this with it’s ability to “granulate” information; Tumblr does it well.
Clearly Separate Content from Display
In separating content from display the presentation layer should know how to pull content from the content cache to where it is needed. “But to truly separate content from display, the content repository needs to also avoid storing “dirty” content. Dirty content is content that contains any presentation layer information embedded in it, including HTML, XML, character encoding, micro-formats and any other markup or rich formatting information.”9
Content Modularity
Content Modularity is more than just normalizing a database, it’s about ensuring that discreet data is stored in a distinct location to be retrieved for specific contexts. For a full description of this, go to http://blog.programmableweb.com/2009/10/21/content-modularity-more-than-just-data-normalization/.
Content Portability
Content Portability is crucial to this whole process as it often contains important markup language that allows it to relate to other content — but unfortunately, this makes it “dirty.” Daniel Jacobson says, “No matter how modular the content is in the database, if it is sullied (love that word) by markup, it is not truly portable.”10 Just building an application programming interface is not enough — it needs to be able to distribute the content to any platform in a way that each platform can understand it.
See (http://blog.programmableweb.com/2009/11/11/content-portability-building-an-api-is-not-enough/) for a full article about content portability. If you are a coder, you’ll enjoy this.
Stay tuned, folks, for Mobile Web, Part IV, the fourth and final entry to this subject matter.
__________________________
1 http://alistapart.com/article/for-a-future-friendly-web
2 Ibid.
3 http://alistapart.com/article/future-ready-content
4 Ibid.
5 McGrane, Karen. Mobile Web Content Strategy. A Book Apart Publishers, 2012, page
6 http://blog.programmableweb.com/2009/10/13/cope-create-once-publish-everywhere/
7 http://alistapart.com/article/orbital-content
8 http://blog.programmableweb.com/2009/10/13/cope-create-once-publish-everywhere/
9 Ibid.
10 Ibid.
If you’ve missed them, you can see the two previous articles.
Mobile Web, Part I.
Mobile Web, Part II.
All (PARENTHETICAL STATEMENTS) are mine. Ha!
Why have I been harping about Mobile Web? Well, it’s becoming an epidemic in the development news trade, and let's face it — most Americans (more than 50%) sleep with their smart phones.1 So, basically it’s the last thing they touch at night and the first thing they touch in the morning [ barring significant others ;-) ].
So, as Brad Frost (http://bradfrostweb.com/) says, “As web creators, we need to embrace these trends to create worthwhile experiences that respect user’s time, or risk getting tuned out.” 2
Sara Wachter-Boettcher (SWB) says, “The future is flexible, and we’re bending with it. From responsive web design to future friendly thinking, we’re moving quickly toward a web that’s more fluid, less fixed, and more easily accessed on a multitude of devices." 3 A multitude of devices, wow! How do we deal with that? Think about all of the devices that are out there that need to get this right. The good news is that we can break it down into four types of devices, or:
D_L_T_SP (pronounced "deltsop")
Desk top, laptop, tablet and smart phone. As SWB continues to say, “. . . you have to know what each type of content is intended to accomplish before you can make decisions about how you need to treat it in different contexts."4
Content x Context x DLTSP = Mobile Web
We have to then ask the question: Do we need to hire a content strategist to help us “funnel” the right content to the right context? My answer to that, of course, is yes. You want to avoid “forking5” your content, or have “forking” content.
And it’s true that you have different needs in different contexts, for example: if I am at home on my desktop or laptop, and I Google “Tanglewood” — I may be presented with a variety of results, such as sponsored links, or a Wikipedia article about Tanglewood, or the main site for Tanglewood. If I go to search Tanglewood from my smart phone, you get a prompt asking you if you want to go to the Tanglewood mobile site? Makes sense, doesn’t it? Maybe I want to buy tickets on the fly, or get directions that I can automatically "click on" from the mobile site to my smart phone.
It’s our job now to not only figure out WHO our target audience is, but we also have to figure out WHAT they are DOING.
Different needs in different scenarios is nothing new, but the devices are. So context affecting content will be ruling the roost for a while. In the above “Tanglewood” scenario you could also add “ advertising sponsors” to the mix by having The Red Lion Inn, be the Tanglewood mobile sponsor, as this is a place many people go to before or after concerts.You just have to keep on thinking through the scenarios.
The options are endless and will obviously help the client get over the fact that they are paying even more money to you to develop a more involved process. The issue — all of this is unavoidable, like acid rain after a volcano — you have to do it.
So, how do you begin to do this? Well, you have to look at the the experts, and to date: it’s National Public Radio’s (NPR) COPE (Create Once, Publish Everywhere) Process.6 Think of content in a different way — more like expandable “info-chunks” rather than specific information that is placed in a specific place. NPR dices it up into four specific info-chunks: title, short slug, longer description, and date line.
One of the biggest projects that I ever worked on was the development ofHometownstores.com (now sold and defunct). It was based upon a Boston South Shore Ace hardware chain (See current shot in Figure 1). We had 56,000 products where we had two different product descriptions: short and long. We had to figure out how to use this as it came directly from Ace, and we also had to add product images, pricing and inventory into the mix. It was amazingly complex, but we did it without thinking too much about it. We did it because we had to and really didn’t know better.
 |
| FIGURE 1 — Current Hometownstores.com derivative |
As Cameron Koczon says, “...as users spend more time on consumption-oriented devices (another story) like iPads and mobile (smart) phones — new demands are being put on content.”7
You betcha!
You also may say that this is going to be a big pain in the butt, until we figure out which way is North. How can we do this? How can we add more time to the development cycle? Well, according to NPR they have “...a small staff and limited resources.”8 The below diagram represents NPR’s content management pipeline. It is a thing of beauty to study, like a Monet.
NPR states that the COPE method incorporates:
- building or integrating CMS (content management systems), not WPT (web publishing tools)
- clearly separate content from display
- ensure content modularity
- ensure content portability
Integrating CMS
The purpose of a good CMS is to allow you to present content in variable presentations formats on-demand. WPT’s are often dependent upon plug-ins to the native code to allow for alternate platform destinations, which often don’t make them scalable the way you’d like. A true CMS should be able to be captured and delivered to any existing or future destination. (WordPress has issues with this with it’s ability to “granulate” information; Tumblr does it well.
Clearly Separate Content from Display
In separating content from display the presentation layer should know how to pull content from the content cache to where it is needed. “But to truly separate content from display, the content repository needs to also avoid storing “dirty” content. Dirty content is content that contains any presentation layer information embedded in it, including HTML, XML, character encoding, micro-formats and any other markup or rich formatting information.”9
Content Modularity
Content Modularity is more than just normalizing a database, it’s about ensuring that discreet data is stored in a distinct location to be retrieved for specific contexts. For a full description of this, go to http://blog.programmableweb.com/2009/10/21/content-modularity-more-than-just-data-normalization/.
Content Portability
Content Portability is crucial to this whole process as it often contains important markup language that allows it to relate to other content — but unfortunately, this makes it “dirty.” Daniel Jacobson says, “No matter how modular the content is in the database, if it is sullied (love that word) by markup, it is not truly portable.”10 Just building an application programming interface is not enough — it needs to be able to distribute the content to any platform in a way that each platform can understand it.
See (http://blog.programmableweb.com/2009/11/11/content-portability-building-an-api-is-not-enough/) for a full article about content portability. If you are a coder, you’ll enjoy this.
Stay tuned, folks, for Mobile Web, Part IV, the fourth and final entry to this subject matter.
__________________________
1 http://alistapart.com/article/for-a-future-friendly-web
2 Ibid.
3 http://alistapart.com/article/future-ready-content
4 Ibid.
5 McGrane, Karen. Mobile Web Content Strategy. A Book Apart Publishers, 2012, page
6 http://blog.programmableweb.com/2009/10/13/cope-create-once-publish-everywhere/
7 http://alistapart.com/article/orbital-content
8 http://blog.programmableweb.com/2009/10/13/cope-create-once-publish-everywhere/
9 Ibid.
10 Ibid.
No comments: