rahuldave + 2011_redux 11
How Storifying Occupy Wall Street Saved The News
december 2011 by rahuldave
In the dead of night on Monday, November 14, Zuccotti Park in New York City was raided by police. In the preceding days, there were crackdowns at several of the major Occupy protests around the country. The effort had apparently been coordinated between cities. Monday night's actions against the original Occupy Wall Street encampment were stern, heavy enough to bring a decisive end to the protest. But the raid only served to turn up the heat in New York and around the country.
As they have since the Occupation began, people on the ground fired up their smartphones to report the events as they happened, and curators around the Web gathered and retweeted the salient messages. But early on in the raid, mainstream media outlets began reporting that the police were barring their reporters from entering the park. The NYPD even grounded a CBS News helicopter. The night had chilling implications for freedom of the press. But the news got out anyway. The raw power of citizen media - and the future of news envisioned by a site called Storify - thwarted the media blackout.
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
Saving The News
This is a new media age. The news of the Occupation has countless reporters, and some of the Web's best curators have taken on the task of weaving the Occupy stories together. In particular, Xeni Jardin has been a machine on Twitter, providing a one-woman breaking news channel of so many successive Occupy confrontations.
But for the Monday night raid at Zuccotti Park, and indeed for much of the Occupation, Storify has come into its own as the social news curation tool par excellence. In fact, thanks to the media blackout Monday night, some of the most important news outlets in the country would not have had a story if not for Storify.
Josh Harkinson, a reporter for Mother Jones, crashed the barricades and reported from the scene, becoming a source for all the curators, including his own publication:
Storify's New Role: The Backbone of News
"Most of the content comes from the people on the ground, from the 99%."Storify is one of those companies that arrives at its point in history just in the nick of time. Its co-founders pitched the idea during the Green Revolution in Iran, one of the first popular uprisings driven by social media. "Now it's actually happening here, on the soil of America, with the Occupy movement," says co-founder Xavier Damman.
The world needed a shareable, embeddable way to gather the tweetstorm of breaking news and turn it into a lasting document. Storify has made that possible. After a closed beta period with professional journalists, Storify opened to the public in April.
In October, it rolled out a brand new editing interface making the tool vastly easier to use. And one week ago, just before the police raided Zuccotti Park, Storify made its move, redesigning its homepage as a destination featuring the most important stories on the social Web. Storify's vision is no less than a leveling of the media playing field. On the Storify homepage, lifelong and first-time journalists stand side by side.
"All news is social now," says Storify CEO and co-founder Burt Herman. Whoever's on the ground is the reporter, and whoever's curating on the Web is the editor. It doesn't matter who is whom. "We always talk about quoting from the original sources, from politicians, companies and everybody else, but now the journalists who are normally reporting are the sources."
From a Dorm Room to the Front Page
While career journalists were being removed from Zuccotti Park, Ben Doernberg was watching the Web from his dorm room at Wesleyan University in Middletown, Connecticut. Ben is a college junior, and journalism is not his major. But his Storify of the Occupy Wall Street raid reached tens of thousands of people and was embedded by the Washington Post.
"This is not actually my first Storify," he says, despite fun rumors to the contrary. "I was at Zuccotti Park about a month ago and happened to take a video that ended up getting on CNN, so this is kind of the second bizarre media day I've had in the last month."
Doernberg used Storify to track the reports of the media blackout. "I looked at Twitter around 1 o'clock, and everything was going insane," Doernberg says.
"By the time I decided to make a Storify, I had already read probably 100 tweets on this issue, so I tried to figure out what the overarching themes or the story seemed to be to me, and I went back through my memory of who tweeted what at what time." What resulted was a comprehensive document of tweets, links, photos and videos of instances of the NYPD suppressing the media presence in Zuccotti Park. The Washington Post ran it, and the post has been viewed more than 20,000 times.
The 99% Media
The founders of Storify couldn't be more delighted that students are making headlines using their platform. The day after the raid on Zuccotti Park, Storify shared two student stories from the raid on its blog. Doernberg's was one. The other was by Columbia journalism grad student XinHui Lim, whose Storify post captured the grisly details from the ground and included embedded live-streamed video. At one point in the night, that amateur video stream had 23,000 viewers.
Damman says this is the perfect demonstration of the Storify redesign. These social media documents are the real story, and the NYPD's obstruction of credentialed journalists only shows how out of touch the police are. "The police in New York don't realize that it doesn't matter to not have journalists on the scene," Damman says, "because everybody is a reporter. What happened last night shows that they don't get that."
"Most of the content comes from the people on the ground, from the 99%."
Herman agrees that Monday's events prove that the distinction between legacy media and new media is no longer important. During the raid, journalists became sources, regular people became journalists, and they traded places with each other throughout the night. It's all one medium now. "Let's not spite the Internet," Herman says. "Let's let the Internet be what it is."
The Gatekeepers
The NYPD's censorship efforts were thwarted by smartphones, Web technology and good, old-fashioned gumption. But authorities are working hard around the country to block journalists from covering the Occupation. Twenty six reporters have been arrested so far, ten of them in Zuccotti Park on Monday night.
Fortunately, those incidents are being captured on Storify, too, and the curator wants to make sure the free press is protected.
Next page: Josh Stearns of FreePress.net on new media, arrested journalists and the implications of the OWS blackout.
Josh Stearns, Associate Program Director at Free Press, has been storifying journalist arrests at Occupy protests since September. He's using Storify as a living page, updating each time another journalist is arrested. You can help him by sending tips and tweets to @jcstearns.
Free Press is also holding a petition for their Save The News campaign urging New York Mayor Michael Bloomberg and the U.S. Conference of Mayors to stop attacking freedom of the press.
Watching the Story Unfold
November 15 was a big night for journalist arrests, and Stearns was watching Twitter closely. "I think of Twitter as the place where I watch the story unfold," Stearns says, "but then I often look to a place like Storify or an article or liveblog where there's somebody intentionally trying to contextualize and weave things together."
One of the things Stearns struggled with during Monday's raids was "that reports were coming in at all different times. Trying to piece together when something happened" was a challenge, since both the events and tweets about the events were displaced in time.
"Twitter's so great for seeing the story unfold, but I think there's a lot of awesome work that can be done in contextualizing it." That's where Storify comes in. "I think Storify is a very flexible tool, being able to do that kind of rapid reporting or to bear witness over time."
Media Symbiosis
Stearns was impressed with Doernberg's work Monday night and how Storify enabled it. "His Storify wouldn't have been possible without people on the ground, and people on the ground weren't able to get their story out until his Storify collected those from all over the place and broadcasted it, and that story got into the Washington Post."
Storify provides the bridge between legacy and new media in situations like this. "I think there's really nice symbiosis between the two," Stearns says. "I think that's one thing Storify has done really well, positioning itself within a new media realm but making new media approachable for traditional organizations."
The Gatekeepers Are Changing
But legacy institutions aren't weathering the transition well. The Associated Press came down hard on its staff for tweeting too eagerly about their arrests in an email that feels awfully shy about new media participation. It warns AP reporters not to get "caught in the moment."
"If we're having people who are non-traditional journalists doing critical reporting, and they're getting thrown in jail because they don't have the right press credentials, we need to figure that out."And law enforcement agencies seem to have little conscience about arresting journalists, even ones who are waving press credentials at them. Doernberg's Storify captures two police o[…]
2011_Redux
from google
As they have since the Occupation began, people on the ground fired up their smartphones to report the events as they happened, and curators around the Web gathered and retweeted the salient messages. But early on in the raid, mainstream media outlets began reporting that the police were barring their reporters from entering the park. The NYPD even grounded a CBS News helicopter. The night had chilling implications for freedom of the press. But the news got out anyway. The raw power of citizen media - and the future of news envisioned by a site called Storify - thwarted the media blackout.
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
Saving The News
This is a new media age. The news of the Occupation has countless reporters, and some of the Web's best curators have taken on the task of weaving the Occupy stories together. In particular, Xeni Jardin has been a machine on Twitter, providing a one-woman breaking news channel of so many successive Occupy confrontations.
But for the Monday night raid at Zuccotti Park, and indeed for much of the Occupation, Storify has come into its own as the social news curation tool par excellence. In fact, thanks to the media blackout Monday night, some of the most important news outlets in the country would not have had a story if not for Storify.
Josh Harkinson, a reporter for Mother Jones, crashed the barricades and reported from the scene, becoming a source for all the curators, including his own publication:
Storify's New Role: The Backbone of News
"Most of the content comes from the people on the ground, from the 99%."Storify is one of those companies that arrives at its point in history just in the nick of time. Its co-founders pitched the idea during the Green Revolution in Iran, one of the first popular uprisings driven by social media. "Now it's actually happening here, on the soil of America, with the Occupy movement," says co-founder Xavier Damman.
The world needed a shareable, embeddable way to gather the tweetstorm of breaking news and turn it into a lasting document. Storify has made that possible. After a closed beta period with professional journalists, Storify opened to the public in April.
In October, it rolled out a brand new editing interface making the tool vastly easier to use. And one week ago, just before the police raided Zuccotti Park, Storify made its move, redesigning its homepage as a destination featuring the most important stories on the social Web. Storify's vision is no less than a leveling of the media playing field. On the Storify homepage, lifelong and first-time journalists stand side by side.
"All news is social now," says Storify CEO and co-founder Burt Herman. Whoever's on the ground is the reporter, and whoever's curating on the Web is the editor. It doesn't matter who is whom. "We always talk about quoting from the original sources, from politicians, companies and everybody else, but now the journalists who are normally reporting are the sources."
From a Dorm Room to the Front Page
While career journalists were being removed from Zuccotti Park, Ben Doernberg was watching the Web from his dorm room at Wesleyan University in Middletown, Connecticut. Ben is a college junior, and journalism is not his major. But his Storify of the Occupy Wall Street raid reached tens of thousands of people and was embedded by the Washington Post.
"This is not actually my first Storify," he says, despite fun rumors to the contrary. "I was at Zuccotti Park about a month ago and happened to take a video that ended up getting on CNN, so this is kind of the second bizarre media day I've had in the last month."
Doernberg used Storify to track the reports of the media blackout. "I looked at Twitter around 1 o'clock, and everything was going insane," Doernberg says.
"By the time I decided to make a Storify, I had already read probably 100 tweets on this issue, so I tried to figure out what the overarching themes or the story seemed to be to me, and I went back through my memory of who tweeted what at what time." What resulted was a comprehensive document of tweets, links, photos and videos of instances of the NYPD suppressing the media presence in Zuccotti Park. The Washington Post ran it, and the post has been viewed more than 20,000 times.
The 99% Media
The founders of Storify couldn't be more delighted that students are making headlines using their platform. The day after the raid on Zuccotti Park, Storify shared two student stories from the raid on its blog. Doernberg's was one. The other was by Columbia journalism grad student XinHui Lim, whose Storify post captured the grisly details from the ground and included embedded live-streamed video. At one point in the night, that amateur video stream had 23,000 viewers.
Damman says this is the perfect demonstration of the Storify redesign. These social media documents are the real story, and the NYPD's obstruction of credentialed journalists only shows how out of touch the police are. "The police in New York don't realize that it doesn't matter to not have journalists on the scene," Damman says, "because everybody is a reporter. What happened last night shows that they don't get that."
"Most of the content comes from the people on the ground, from the 99%."
Herman agrees that Monday's events prove that the distinction between legacy media and new media is no longer important. During the raid, journalists became sources, regular people became journalists, and they traded places with each other throughout the night. It's all one medium now. "Let's not spite the Internet," Herman says. "Let's let the Internet be what it is."
The Gatekeepers
The NYPD's censorship efforts were thwarted by smartphones, Web technology and good, old-fashioned gumption. But authorities are working hard around the country to block journalists from covering the Occupation. Twenty six reporters have been arrested so far, ten of them in Zuccotti Park on Monday night.
Fortunately, those incidents are being captured on Storify, too, and the curator wants to make sure the free press is protected.
Next page: Josh Stearns of FreePress.net on new media, arrested journalists and the implications of the OWS blackout.
Josh Stearns, Associate Program Director at Free Press, has been storifying journalist arrests at Occupy protests since September. He's using Storify as a living page, updating each time another journalist is arrested. You can help him by sending tips and tweets to @jcstearns.
Free Press is also holding a petition for their Save The News campaign urging New York Mayor Michael Bloomberg and the U.S. Conference of Mayors to stop attacking freedom of the press.
Watching the Story Unfold
November 15 was a big night for journalist arrests, and Stearns was watching Twitter closely. "I think of Twitter as the place where I watch the story unfold," Stearns says, "but then I often look to a place like Storify or an article or liveblog where there's somebody intentionally trying to contextualize and weave things together."
One of the things Stearns struggled with during Monday's raids was "that reports were coming in at all different times. Trying to piece together when something happened" was a challenge, since both the events and tweets about the events were displaced in time.
"Twitter's so great for seeing the story unfold, but I think there's a lot of awesome work that can be done in contextualizing it." That's where Storify comes in. "I think Storify is a very flexible tool, being able to do that kind of rapid reporting or to bear witness over time."
Media Symbiosis
Stearns was impressed with Doernberg's work Monday night and how Storify enabled it. "His Storify wouldn't have been possible without people on the ground, and people on the ground weren't able to get their story out until his Storify collected those from all over the place and broadcasted it, and that story got into the Washington Post."
Storify provides the bridge between legacy and new media in situations like this. "I think there's really nice symbiosis between the two," Stearns says. "I think that's one thing Storify has done really well, positioning itself within a new media realm but making new media approachable for traditional organizations."
The Gatekeepers Are Changing
But legacy institutions aren't weathering the transition well. The Associated Press came down hard on its staff for tweeting too eagerly about their arrests in an email that feels awfully shy about new media participation. It warns AP reporters not to get "caught in the moment."
"If we're having people who are non-traditional journalists doing critical reporting, and they're getting thrown in jail because they don't have the right press credentials, we need to figure that out."And law enforcement agencies seem to have little conscience about arresting journalists, even ones who are waving press credentials at them. Doernberg's Storify captures two police o[…]
december 2011 by rahuldave
How Storifying Occupy Wall Street Saved The News
december 2011 by rahuldave
In the dead of night on Monday, November 14, Zuccotti Park in New York City was raided by police. In the preceding days, there were crackdowns at several of the major Occupy protests around the country. The effort had apparently been coordinated between cities. Monday night's actions against the original Occupy Wall Street encampment were stern, heavy enough to bring a decisive end to the protest. But the raid only served to turn up the heat in New York and around the country.
As they have since the Occupation began, people on the ground fired up their smartphones to report the events as they happened, and curators around the Web gathered and retweeted the salient messages. But early on in the raid, mainstream media outlets began reporting that the police were barring their reporters from entering the park. The NYPD even grounded a CBS News helicopter. The night had chilling implications for freedom of the press. But the news got out anyway. The raw power of citizen media - and the future of news envisioned by a site called Storify - thwarted the media blackout.
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
Saving The News
This is a new media age. The news of the Occupation has countless reporters, and some of the Web's best curators have taken on the task of weaving the Occupy stories together. In particular, Xeni Jardin has been a machine on Twitter, providing a one-woman breaking news channel of so many successive Occupy confrontations.
But for the Monday night raid at Zuccotti Park, and indeed for much of the Occupation, Storify has come into its own as the social news curation tool par excellence. In fact, thanks to the media blackout Monday night, some of the most important news outlets in the country would not have had a story if not for Storify.
Josh Harkinson, a reporter for Mother Jones, crashed the barricades and reported from the scene, becoming a source for all the curators, including his own publication:
Storify's New Role: The Backbone of News
"Most of the content comes from the people on the ground, from the 99%."Storify is one of those companies that arrives at its point in history just in the nick of time. Its co-founders pitched the idea during the Green Revolution in Iran, one of the first popular uprisings driven by social media. "Now it's actually happening here, on the soil of America, with the Occupy movement," says co-founder Xavier Damman.
The world needed a shareable, embeddable way to gather the tweetstorm of breaking news and turn it into a lasting document. Storify has made that possible. After a closed beta period with professional journalists, Storify opened to the public in April.
In October, it rolled out a brand new editing interface making the tool vastly easier to use. And one week ago, just before the police raided Zuccotti Park, Storify made its move, redesigning its homepage as a destination featuring the most important stories on the social Web. Storify's vision is no less than a leveling of the media playing field. On the Storify homepage, lifelong and first-time journalists stand side by side.
"All news is social now," says Storify CEO and co-founder Burt Herman. Whoever's on the ground is the reporter, and whoever's curating on the Web is the editor. It doesn't matter who is whom. "We always talk about quoting from the original sources, from politicians, companies and everybody else, but now the journalists who are normally reporting are the sources."
From a Dorm Room to the Front Page
While career journalists were being removed from Zuccotti Park, Ben Doernberg was watching the Web from his dorm room at Wesleyan University in Middletown, Connecticut. Ben is a college junior, and journalism is not his major. But his Storify of the Occupy Wall Street raid reached tens of thousands of people and was embedded by the Washington Post.
"This is not actually my first Storify," he says, despite fun rumors to the contrary. "I was at Zuccotti Park about a month ago and happened to take a video that ended up getting on CNN, so this is kind of the second bizarre media day I've had in the last month."
Doernberg used Storify to track the reports of the media blackout. "I looked at Twitter around 1 o'clock, and everything was going insane," Doernberg says.
"By the time I decided to make a Storify, I had already read probably 100 tweets on this issue, so I tried to figure out what the overarching themes or the story seemed to be to me, and I went back through my memory of who tweeted what at what time." What resulted was a comprehensive document of tweets, links, photos and videos of instances of the NYPD suppressing the media presence in Zuccotti Park. The Washington Post ran it, and the post has been viewed more than 20,000 times.
The 99% Media
The founders of Storify couldn't be more delighted that students are making headlines using their platform. The day after the raid on Zuccotti Park, Storify shared two student stories from the raid on its blog. Doernberg's was one. The other was by Columbia journalism grad student XinHui Lim, whose Storify post captured the grisly details from the ground and included embedded live-streamed video. At one point in the night, that amateur video stream had 23,000 viewers.
Damman says this is the perfect demonstration of the Storify redesign. These social media documents are the real story, and the NYPD's obstruction of credentialed journalists only shows how out of touch the police are. "The police in New York don't realize that it doesn't matter to not have journalists on the scene," Damman says, "because everybody is a reporter. What happened last night shows that they don't get that."
"Most of the content comes from the people on the ground, from the 99%."
Herman agrees that Monday's events prove that the distinction between legacy media and new media is no longer important. During the raid, journalists became sources, regular people became journalists, and they traded places with each other throughout the night. It's all one medium now. "Let's not spite the Internet," Herman says. "Let's let the Internet be what it is."
The Gatekeepers
The NYPD's censorship efforts were thwarted by smartphones, Web technology and good, old-fashioned gumption. But authorities are working hard around the country to block journalists from covering the Occupation. Twenty six reporters have been arrested so far, ten of them in Zuccotti Park on Monday night.
Fortunately, those incidents are being captured on Storify, too, and the curator wants to make sure the free press is protected.
Next page: Josh Stearns of FreePress.net on new media, arrested journalists and the implications of the OWS blackout.
Josh Stearns, Associate Program Director at Free Press, has been storifying journalist arrests at Occupy protests since September. He's using Storify as a living page, updating each time another journalist is arrested. You can help him by sending tips and tweets to @jcstearns.
Free Press is also holding a petition for their Save The News campaign urging New York Mayor Michael Bloomberg and the U.S. Conference of Mayors to stop attacking freedom of the press.
Watching the Story Unfold
November 15 was a big night for journalist arrests, and Stearns was watching Twitter closely. "I think of Twitter as the place where I watch the story unfold," Stearns says, "but then I often look to a place like Storify or an article or liveblog where there's somebody intentionally trying to contextualize and weave things together."
One of the things Stearns struggled with during Monday's raids was "that reports were coming in at all different times. Trying to piece together when something happened" was a challenge, since both the events and tweets about the events were displaced in time.
"Twitter's so great for seeing the story unfold, but I think there's a lot of awesome work that can be done in contextualizing it." That's where Storify comes in. "I think Storify is a very flexible tool, being able to do that kind of rapid reporting or to bear witness over time."
Media Symbiosis
Stearns was impressed with Doernberg's work Monday night and how Storify enabled it. "His Storify wouldn't have been possible without people on the ground, and people on the ground weren't able to get their story out until his Storify collected those from all over the place and broadcasted it, and that story got into the Washington Post."
Storify provides the bridge between legacy and new media in situations like this. "I think there's really nice symbiosis between the two," Stearns says. "I think that's one thing Storify has done really well, positioning itself within a new media realm but making new media approachable for traditional organizations."
The Gatekeepers Are Changing
But legacy institutions aren't weathering the transition well. The Associated Press came down hard on its staff for tweeting too eagerly about their arrests in an email that feels awfully shy about new media participation. It warns AP reporters not to get "caught in the moment."
"If we're having people who are non-traditional journalists doing critical reporting, and they're getting thrown in jail because they don't have the right press credentials, we need to figure that out."And law enforcement agencies seem to have little conscience about arresting journalists, even ones who are waving press credentials at them. Doernberg's Storify captures two police o[…]
2011_Redux
from google
As they have since the Occupation began, people on the ground fired up their smartphones to report the events as they happened, and curators around the Web gathered and retweeted the salient messages. But early on in the raid, mainstream media outlets began reporting that the police were barring their reporters from entering the park. The NYPD even grounded a CBS News helicopter. The night had chilling implications for freedom of the press. But the news got out anyway. The raw power of citizen media - and the future of news envisioned by a site called Storify - thwarted the media blackout.
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
Saving The News
This is a new media age. The news of the Occupation has countless reporters, and some of the Web's best curators have taken on the task of weaving the Occupy stories together. In particular, Xeni Jardin has been a machine on Twitter, providing a one-woman breaking news channel of so many successive Occupy confrontations.
But for the Monday night raid at Zuccotti Park, and indeed for much of the Occupation, Storify has come into its own as the social news curation tool par excellence. In fact, thanks to the media blackout Monday night, some of the most important news outlets in the country would not have had a story if not for Storify.
Josh Harkinson, a reporter for Mother Jones, crashed the barricades and reported from the scene, becoming a source for all the curators, including his own publication:
Storify's New Role: The Backbone of News
"Most of the content comes from the people on the ground, from the 99%."Storify is one of those companies that arrives at its point in history just in the nick of time. Its co-founders pitched the idea during the Green Revolution in Iran, one of the first popular uprisings driven by social media. "Now it's actually happening here, on the soil of America, with the Occupy movement," says co-founder Xavier Damman.
The world needed a shareable, embeddable way to gather the tweetstorm of breaking news and turn it into a lasting document. Storify has made that possible. After a closed beta period with professional journalists, Storify opened to the public in April.
In October, it rolled out a brand new editing interface making the tool vastly easier to use. And one week ago, just before the police raided Zuccotti Park, Storify made its move, redesigning its homepage as a destination featuring the most important stories on the social Web. Storify's vision is no less than a leveling of the media playing field. On the Storify homepage, lifelong and first-time journalists stand side by side.
"All news is social now," says Storify CEO and co-founder Burt Herman. Whoever's on the ground is the reporter, and whoever's curating on the Web is the editor. It doesn't matter who is whom. "We always talk about quoting from the original sources, from politicians, companies and everybody else, but now the journalists who are normally reporting are the sources."
From a Dorm Room to the Front Page
While career journalists were being removed from Zuccotti Park, Ben Doernberg was watching the Web from his dorm room at Wesleyan University in Middletown, Connecticut. Ben is a college junior, and journalism is not his major. But his Storify of the Occupy Wall Street raid reached tens of thousands of people and was embedded by the Washington Post.
"This is not actually my first Storify," he says, despite fun rumors to the contrary. "I was at Zuccotti Park about a month ago and happened to take a video that ended up getting on CNN, so this is kind of the second bizarre media day I've had in the last month."
Doernberg used Storify to track the reports of the media blackout. "I looked at Twitter around 1 o'clock, and everything was going insane," Doernberg says.
"By the time I decided to make a Storify, I had already read probably 100 tweets on this issue, so I tried to figure out what the overarching themes or the story seemed to be to me, and I went back through my memory of who tweeted what at what time." What resulted was a comprehensive document of tweets, links, photos and videos of instances of the NYPD suppressing the media presence in Zuccotti Park. The Washington Post ran it, and the post has been viewed more than 20,000 times.
The 99% Media
The founders of Storify couldn't be more delighted that students are making headlines using their platform. The day after the raid on Zuccotti Park, Storify shared two student stories from the raid on its blog. Doernberg's was one. The other was by Columbia journalism grad student XinHui Lim, whose Storify post captured the grisly details from the ground and included embedded live-streamed video. At one point in the night, that amateur video stream had 23,000 viewers.
Damman says this is the perfect demonstration of the Storify redesign. These social media documents are the real story, and the NYPD's obstruction of credentialed journalists only shows how out of touch the police are. "The police in New York don't realize that it doesn't matter to not have journalists on the scene," Damman says, "because everybody is a reporter. What happened last night shows that they don't get that."
"Most of the content comes from the people on the ground, from the 99%."
Herman agrees that Monday's events prove that the distinction between legacy media and new media is no longer important. During the raid, journalists became sources, regular people became journalists, and they traded places with each other throughout the night. It's all one medium now. "Let's not spite the Internet," Herman says. "Let's let the Internet be what it is."
The Gatekeepers
The NYPD's censorship efforts were thwarted by smartphones, Web technology and good, old-fashioned gumption. But authorities are working hard around the country to block journalists from covering the Occupation. Twenty six reporters have been arrested so far, ten of them in Zuccotti Park on Monday night.
Fortunately, those incidents are being captured on Storify, too, and the curator wants to make sure the free press is protected.
Next page: Josh Stearns of FreePress.net on new media, arrested journalists and the implications of the OWS blackout.
Josh Stearns, Associate Program Director at Free Press, has been storifying journalist arrests at Occupy protests since September. He's using Storify as a living page, updating each time another journalist is arrested. You can help him by sending tips and tweets to @jcstearns.
Free Press is also holding a petition for their Save The News campaign urging New York Mayor Michael Bloomberg and the U.S. Conference of Mayors to stop attacking freedom of the press.
Watching the Story Unfold
November 15 was a big night for journalist arrests, and Stearns was watching Twitter closely. "I think of Twitter as the place where I watch the story unfold," Stearns says, "but then I often look to a place like Storify or an article or liveblog where there's somebody intentionally trying to contextualize and weave things together."
One of the things Stearns struggled with during Monday's raids was "that reports were coming in at all different times. Trying to piece together when something happened" was a challenge, since both the events and tweets about the events were displaced in time.
"Twitter's so great for seeing the story unfold, but I think there's a lot of awesome work that can be done in contextualizing it." That's where Storify comes in. "I think Storify is a very flexible tool, being able to do that kind of rapid reporting or to bear witness over time."
Media Symbiosis
Stearns was impressed with Doernberg's work Monday night and how Storify enabled it. "His Storify wouldn't have been possible without people on the ground, and people on the ground weren't able to get their story out until his Storify collected those from all over the place and broadcasted it, and that story got into the Washington Post."
Storify provides the bridge between legacy and new media in situations like this. "I think there's really nice symbiosis between the two," Stearns says. "I think that's one thing Storify has done really well, positioning itself within a new media realm but making new media approachable for traditional organizations."
The Gatekeepers Are Changing
But legacy institutions aren't weathering the transition well. The Associated Press came down hard on its staff for tweeting too eagerly about their arrests in an email that feels awfully shy about new media participation. It warns AP reporters not to get "caught in the moment."
"If we're having people who are non-traditional journalists doing critical reporting, and they're getting thrown in jail because they don't have the right press credentials, we need to figure that out."And law enforcement agencies seem to have little conscience about arresting journalists, even ones who are waving press credentials at them. Doernberg's Storify captures two police o[…]
december 2011 by rahuldave
How Facebook Mobile Was Designed to Write Once, Run Everywhere
december 2011 by rahuldave
Facebook has the most downloaded native application of all time. It also has perhaps the most visited mobile website of all time with nearly 350 million users and growing, using everything from basic feature phones to the smartest smartphones. It is available everywhere. The company started working on mobile solutions in 2006 and since then has grown with the times, using the tools available to them as they went along, from m.sites and WebKit touch interfaces to HTML5. Facebook's creed, really just a way to make their developers' lives easier, is to write once, run everywhere. This has been next to impossible.
Facebook mobile is predicated on browser technology. As Facebook's engineering manager Dave Fetterman says in the transcript below, the browser is what Facebook is good at, how it got where it is now and how it will iterate for the future of mobile. We will touch on the future tomorrow, but be sure to read Fetterman's presentation at Facebook's f8 developer conference below because it will inform what we are going to explore tomorrow morning. Really, how did Facebook design for all those platforms and devices?
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
What is below is a direct transcript with photos from Fetterman's f8 presentation. A few things to note:
Facebook mobile has its backbone in its mobile website. Everything that is built into the native applications actually comes from the mobile Web. Think of the way PhoneGap wraps a browser-based website and that is how Facebook approached the problem. And then some.
HTML5 is the future. The fourth page gets into how all of this history is leading Facebook to a precipice of change with HTML5 and the so-called Project Spartan.
Also note that Fetterman talks fast and occasionally swears. He is the classic Facebook engineer: kind of young, pretty brash and supremely confident. The transcript is as true to his actual words as possible.
Changing Mobile Standards Through The Past Five Years
We took an extreme HTML-based approach to this. So we will go into how we do this so you can learn how HTML5 is the way out of a lot of these problems.
Because, it wasn't really always this way for us. We have had the same mobile problems that you guys have. We are following the same mobile ecosystem that you guys are following to develop for your users.
So, we have the same problems of cross-platform development that you have and we are hoping that you can learn a little bit from us. So, we have been learning to deal with these issues with what we call "FaceWeb" and learning a new opportunity to get out of this that is emerging as we speak called HTML5.
So, in 2006, building a mobile presence meant that you had a WAP deck that was based on an HTML application with SMS and all of that. But, as you all know, mobile changed fundamentally in 2007. What happened then?
[Crowd] - The iPhone.
The iPhone! Great. What else happened in 2007, perhaps unveiling in the room that you are sitting in right now?
[Crowd] - The Platform.
Yes, the Facebook Platform API. So, what changed for us is that we had to develop a second user experience for the iPhone. A computer in your pocket that no longer sucked. So, it could have Javascript, a CSS and a really rich interaction model. In addition there was Facebook for BlackBerry, Facebook for Windows phone, for Nokia, for Samsung, for everyone now available through the Facebook API.
How about 2008? What was the big thing that happened in 2008?
[Crowd] - Ummm ... Android?
I will pretend that I heard the iPhone App Store. What most developers don't realize is that the first version of the iPhone, you could build websites but the App Store was not available to later. So, in 2008, the App Store enables us to build Facebook for iPhone. The flagship, the vanguard, the best substantiation of Facebook. Based off the API, the same way that you guys are building apps off the API now.
In 2009, what changed in 2009?
[Crowd] Ummm ... Android?
Android, yes. I will pretend that I heard Android. Android was the new player in 2009 and really started taking off. So, all of a sudden we have all of these users on all these devices using Facebook mobile in the wide rainbow of lovely different experiences across Android, iPhone, Windows, the Web. That was great from a user perspective. What sucks? The environment for my developers, essentially. You have the bad old days. You have four different platforms to build for something essentially. You want to build for all of those groups? You are going to have to build the sucker four times. Then there are all of the features - groups, deals, the new profile. All of this stuff and the matrix got really bad. So, we have to build things four times which means that the code gets slow. The code gets old. There are different versions of parity and things just don't work together which makes it extremely difficult for a fast moving company like Facebook.
Next page: Fetterman describes how Facebook reconciled M.Sites and Touch
How To Not Write The Same Functionality Four Times
So, how do we solve this problem? If we have any shot at solving this problem of building things four times ... if you want to build it once, the Web is probably your best shot. So, back in the day we said that we have two websites, right? We have touch.facebook.com and we have m.facebook.com. Different complete docket roots and who decided what is was going to be, where you are going to go based on your phone? Well, it wasn't that complicated. If you were a Webkit phone, you basically redirected towards touch, if you didn't, you got M. If you had CSS, hey, we could throw that in there, no charge, no problem. So, have had this guess and redirect sort of approach to the Web.
That doesn't really solve the problem of everyone having and optimized experience for their phone. Even things like inline images inside the screen, across CSS and versions, that is really problematic when you that those to my right are saved, those to my left are damned. That is the way it is going to work. So, if we had any chance of unifying these two groups and building something once for the mobile Web, we had to solve this problem.
So, what do we need to do? WebKit wasn't enough, we had to have a better level of granularity. What is the difference between a Javascript enabled mobile website from a non-Javascript enabled mobile website? Really, Javascript is there to enable certain types of display and certain type of interaction, primarily AJAX. But, when you think about the controller --- what is Groups? What is the news feed? What is Message? Those are kind of the same thing and they really don't have to be written twice. So back in the day you had to use inefficient solutions like NetBiscuits which were opaque. You could do some XSL post-processing but you can't post-process your way to good Javascript, it doesn't work. With Webkit you started to get poly-fills and modernizer and all this great stuff. But, you actually needed a way to write your code once.
Progressive Enhancement
Here is what we did.
The cornerstone of this is detecting what your phone is going to be able to do. Capabilities, then you can start the right experience. You guys heard of WURFL at all? Wireless Universal Resource File? This is one of the projects out there that attempts to map a user to a user-agent set of capabilities. You know, what is your screen size? What is your JS? Can it do cookies? These are all pernicious, nasty problems that need to be solved. And the use-agent, as you guys can tell, doesn't do the job. So, you need an open database for manufacturers and concerned citizens to be able to tell you what is up. We sponsored this project and this project is continuing to evolve as an open source data site.
So, once you have these capabilities you actually have to figure out what to do with these. A button on Facebook isn't just like it is HTML or this block of Javascript or something. What you want for the homepage is to have your composers render a button that does something. So, you guys say what we really want is a button. You guys figure internally what should be rendering. If it is a low-end phone maybe it is just straight up post form. It if it is a mid-range phone with CSS, maybe you could layer CSS on there. But if it is a high-end phone you really want an AJAX style experience. So, this technique was pioneered by somebody like Yahoo blueprint. So, instead of saying at the top level that this is going to be a good site and this is going to be a low-end site, each component inside that declarative markup that renders the display will decide what it is able to do. And they compose together to form the ideal experience for that phone. This technique is called progressive enhancement.
So, this actually got us to the point where we were able to write once and run anywhere across the Web. And, you know, the Web seems doable. You can do that on your desktop browsers already. Mobile is getting to the point where you actually can do this using a system like this. But, you guys are probably bored about hearing about the Web, despite the fact that an iPhone user and Android user, whoever, can go use a mobile website competently because they all have good browsers, everyone wants an iPhone feature.
So, we were able to eliminate on of our four stacks and get to the point where we had three and that is great. But, of cours[…]
2011_Redux
from google
Facebook mobile is predicated on browser technology. As Facebook's engineering manager Dave Fetterman says in the transcript below, the browser is what Facebook is good at, how it got where it is now and how it will iterate for the future of mobile. We will touch on the future tomorrow, but be sure to read Fetterman's presentation at Facebook's f8 developer conference below because it will inform what we are going to explore tomorrow morning. Really, how did Facebook design for all those platforms and devices?
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
What is below is a direct transcript with photos from Fetterman's f8 presentation. A few things to note:
Facebook mobile has its backbone in its mobile website. Everything that is built into the native applications actually comes from the mobile Web. Think of the way PhoneGap wraps a browser-based website and that is how Facebook approached the problem. And then some.
HTML5 is the future. The fourth page gets into how all of this history is leading Facebook to a precipice of change with HTML5 and the so-called Project Spartan.
Also note that Fetterman talks fast and occasionally swears. He is the classic Facebook engineer: kind of young, pretty brash and supremely confident. The transcript is as true to his actual words as possible.
Changing Mobile Standards Through The Past Five Years
We took an extreme HTML-based approach to this. So we will go into how we do this so you can learn how HTML5 is the way out of a lot of these problems.
Because, it wasn't really always this way for us. We have had the same mobile problems that you guys have. We are following the same mobile ecosystem that you guys are following to develop for your users.
So, we have the same problems of cross-platform development that you have and we are hoping that you can learn a little bit from us. So, we have been learning to deal with these issues with what we call "FaceWeb" and learning a new opportunity to get out of this that is emerging as we speak called HTML5.
So, in 2006, building a mobile presence meant that you had a WAP deck that was based on an HTML application with SMS and all of that. But, as you all know, mobile changed fundamentally in 2007. What happened then?
[Crowd] - The iPhone.
The iPhone! Great. What else happened in 2007, perhaps unveiling in the room that you are sitting in right now?
[Crowd] - The Platform.
Yes, the Facebook Platform API. So, what changed for us is that we had to develop a second user experience for the iPhone. A computer in your pocket that no longer sucked. So, it could have Javascript, a CSS and a really rich interaction model. In addition there was Facebook for BlackBerry, Facebook for Windows phone, for Nokia, for Samsung, for everyone now available through the Facebook API.
How about 2008? What was the big thing that happened in 2008?
[Crowd] - Ummm ... Android?
I will pretend that I heard the iPhone App Store. What most developers don't realize is that the first version of the iPhone, you could build websites but the App Store was not available to later. So, in 2008, the App Store enables us to build Facebook for iPhone. The flagship, the vanguard, the best substantiation of Facebook. Based off the API, the same way that you guys are building apps off the API now.
In 2009, what changed in 2009?
[Crowd] Ummm ... Android?
Android, yes. I will pretend that I heard Android. Android was the new player in 2009 and really started taking off. So, all of a sudden we have all of these users on all these devices using Facebook mobile in the wide rainbow of lovely different experiences across Android, iPhone, Windows, the Web. That was great from a user perspective. What sucks? The environment for my developers, essentially. You have the bad old days. You have four different platforms to build for something essentially. You want to build for all of those groups? You are going to have to build the sucker four times. Then there are all of the features - groups, deals, the new profile. All of this stuff and the matrix got really bad. So, we have to build things four times which means that the code gets slow. The code gets old. There are different versions of parity and things just don't work together which makes it extremely difficult for a fast moving company like Facebook.
Next page: Fetterman describes how Facebook reconciled M.Sites and Touch
How To Not Write The Same Functionality Four Times
So, how do we solve this problem? If we have any shot at solving this problem of building things four times ... if you want to build it once, the Web is probably your best shot. So, back in the day we said that we have two websites, right? We have touch.facebook.com and we have m.facebook.com. Different complete docket roots and who decided what is was going to be, where you are going to go based on your phone? Well, it wasn't that complicated. If you were a Webkit phone, you basically redirected towards touch, if you didn't, you got M. If you had CSS, hey, we could throw that in there, no charge, no problem. So, have had this guess and redirect sort of approach to the Web.
That doesn't really solve the problem of everyone having and optimized experience for their phone. Even things like inline images inside the screen, across CSS and versions, that is really problematic when you that those to my right are saved, those to my left are damned. That is the way it is going to work. So, if we had any chance of unifying these two groups and building something once for the mobile Web, we had to solve this problem.
So, what do we need to do? WebKit wasn't enough, we had to have a better level of granularity. What is the difference between a Javascript enabled mobile website from a non-Javascript enabled mobile website? Really, Javascript is there to enable certain types of display and certain type of interaction, primarily AJAX. But, when you think about the controller --- what is Groups? What is the news feed? What is Message? Those are kind of the same thing and they really don't have to be written twice. So back in the day you had to use inefficient solutions like NetBiscuits which were opaque. You could do some XSL post-processing but you can't post-process your way to good Javascript, it doesn't work. With Webkit you started to get poly-fills and modernizer and all this great stuff. But, you actually needed a way to write your code once.
Progressive Enhancement
Here is what we did.
The cornerstone of this is detecting what your phone is going to be able to do. Capabilities, then you can start the right experience. You guys heard of WURFL at all? Wireless Universal Resource File? This is one of the projects out there that attempts to map a user to a user-agent set of capabilities. You know, what is your screen size? What is your JS? Can it do cookies? These are all pernicious, nasty problems that need to be solved. And the use-agent, as you guys can tell, doesn't do the job. So, you need an open database for manufacturers and concerned citizens to be able to tell you what is up. We sponsored this project and this project is continuing to evolve as an open source data site.
So, once you have these capabilities you actually have to figure out what to do with these. A button on Facebook isn't just like it is HTML or this block of Javascript or something. What you want for the homepage is to have your composers render a button that does something. So, you guys say what we really want is a button. You guys figure internally what should be rendering. If it is a low-end phone maybe it is just straight up post form. It if it is a mid-range phone with CSS, maybe you could layer CSS on there. But if it is a high-end phone you really want an AJAX style experience. So, this technique was pioneered by somebody like Yahoo blueprint. So, instead of saying at the top level that this is going to be a good site and this is going to be a low-end site, each component inside that declarative markup that renders the display will decide what it is able to do. And they compose together to form the ideal experience for that phone. This technique is called progressive enhancement.
So, this actually got us to the point where we were able to write once and run anywhere across the Web. And, you know, the Web seems doable. You can do that on your desktop browsers already. Mobile is getting to the point where you actually can do this using a system like this. But, you guys are probably bored about hearing about the Web, despite the fact that an iPhone user and Android user, whoever, can go use a mobile website competently because they all have good browsers, everyone wants an iPhone feature.
So, we were able to eliminate on of our four stacks and get to the point where we had three and that is great. But, of cours[…]
december 2011 by rahuldave
How Facebook Mobile Was Designed to Write Once, Run Everywhere
december 2011 by rahuldave
Facebook has the most downloaded native application of all time. It also has perhaps the most visited mobile website of all time with nearly 350 million users and growing, using everything from basic feature phones to the smartest smartphones. It is available everywhere. The company started working on mobile solutions in 2006 and since then has grown with the times, using the tools available to them as they went along, from m.sites and WebKit touch interfaces to HTML5. Facebook's creed, really just a way to make their developers' lives easier, is to write once, run everywhere. This has been next to impossible.
Facebook mobile is predicated on browser technology. As Facebook's engineering manager Dave Fetterman says in the transcript below, the browser is what Facebook is good at, how it got where it is now and how it will iterate for the future of mobile. We will touch on the future tomorrow, but be sure to read Fetterman's presentation at Facebook's f8 developer conference below because it will inform what we are going to explore tomorrow morning. Really, how did Facebook design for all those platforms and devices?
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
What is below is a direct transcript with photos from Fetterman's f8 presentation. A few things to note:
Facebook mobile has its backbone in its mobile website. Everything that is built into the native applications actually comes from the mobile Web. Think of the way PhoneGap wraps a browser-based website and that is how Facebook approached the problem. And then some.
HTML5 is the future. The fourth page gets into how all of this history is leading Facebook to a precipice of change with HTML5 and the so-called Project Spartan.
Also note that Fetterman talks fast and occasionally swears. He is the classic Facebook engineer: kind of young, pretty brash and supremely confident. The transcript is as true to his actual words as possible.
Changing Mobile Standards Through The Past Five Years
We took an extreme HTML-based approach to this. So we will go into how we do this so you can learn how HTML5 is the way out of a lot of these problems.
Because, it wasn't really always this way for us. We have had the same mobile problems that you guys have. We are following the same mobile ecosystem that you guys are following to develop for your users.
So, we have the same problems of cross-platform development that you have and we are hoping that you can learn a little bit from us. So, we have been learning to deal with these issues with what we call "FaceWeb" and learning a new opportunity to get out of this that is emerging as we speak called HTML5.
So, in 2006, building a mobile presence meant that you had a WAP deck that was based on an HTML application with SMS and all of that. But, as you all know, mobile changed fundamentally in 2007. What happened then?
[Crowd] - The iPhone.
The iPhone! Great. What else happened in 2007, perhaps unveiling in the room that you are sitting in right now?
[Crowd] - The Platform.
Yes, the Facebook Platform API. So, what changed for us is that we had to develop a second user experience for the iPhone. A computer in your pocket that no longer sucked. So, it could have Javascript, a CSS and a really rich interaction model. In addition there was Facebook for BlackBerry, Facebook for Windows phone, for Nokia, for Samsung, for everyone now available through the Facebook API.
How about 2008? What was the big thing that happened in 2008?
[Crowd] - Ummm ... Android?
I will pretend that I heard the iPhone App Store. What most developers don't realize is that the first version of the iPhone, you could build websites but the App Store was not available to later. So, in 2008, the App Store enables us to build Facebook for iPhone. The flagship, the vanguard, the best substantiation of Facebook. Based off the API, the same way that you guys are building apps off the API now.
In 2009, what changed in 2009?
[Crowd] Ummm ... Android?
Android, yes. I will pretend that I heard Android. Android was the new player in 2009 and really started taking off. So, all of a sudden we have all of these users on all these devices using Facebook mobile in the wide rainbow of lovely different experiences across Android, iPhone, Windows, the Web. That was great from a user perspective. What sucks? The environment for my developers, essentially. You have the bad old days. You have four different platforms to build for something essentially. You want to build for all of those groups? You are going to have to build the sucker four times. Then there are all of the features - groups, deals, the new profile. All of this stuff and the matrix got really bad. So, we have to build things four times which means that the code gets slow. The code gets old. There are different versions of parity and things just don't work together which makes it extremely difficult for a fast moving company like Facebook.
Next page: Fetterman describes how Facebook reconciled M.Sites and Touch
How To Not Write The Same Functionality Four Times
So, how do we solve this problem? If we have any shot at solving this problem of building things four times ... if you want to build it once, the Web is probably your best shot. So, back in the day we said that we have two websites, right? We have touch.facebook.com and we have m.facebook.com. Different complete docket roots and who decided what is was going to be, where you are going to go based on your phone? Well, it wasn't that complicated. If you were a Webkit phone, you basically redirected towards touch, if you didn't, you got M. If you had CSS, hey, we could throw that in there, no charge, no problem. So, have had this guess and redirect sort of approach to the Web.
That doesn't really solve the problem of everyone having and optimized experience for their phone. Even things like inline images inside the screen, across CSS and versions, that is really problematic when you that those to my right are saved, those to my left are damned. That is the way it is going to work. So, if we had any chance of unifying these two groups and building something once for the mobile Web, we had to solve this problem.
So, what do we need to do? WebKit wasn't enough, we had to have a better level of granularity. What is the difference between a Javascript enabled mobile website from a non-Javascript enabled mobile website? Really, Javascript is there to enable certain types of display and certain type of interaction, primarily AJAX. But, when you think about the controller --- what is Groups? What is the news feed? What is Message? Those are kind of the same thing and they really don't have to be written twice. So back in the day you had to use inefficient solutions like NetBiscuits which were opaque. You could do some XSL post-processing but you can't post-process your way to good Javascript, it doesn't work. With Webkit you started to get poly-fills and modernizer and all this great stuff. But, you actually needed a way to write your code once.
Progressive Enhancement
Here is what we did.
The cornerstone of this is detecting what your phone is going to be able to do. Capabilities, then you can start the right experience. You guys heard of WURFL at all? Wireless Universal Resource File? This is one of the projects out there that attempts to map a user to a user-agent set of capabilities. You know, what is your screen size? What is your JS? Can it do cookies? These are all pernicious, nasty problems that need to be solved. And the use-agent, as you guys can tell, doesn't do the job. So, you need an open database for manufacturers and concerned citizens to be able to tell you what is up. We sponsored this project and this project is continuing to evolve as an open source data site.
So, once you have these capabilities you actually have to figure out what to do with these. A button on Facebook isn't just like it is HTML or this block of Javascript or something. What you want for the homepage is to have your composers render a button that does something. So, you guys say what we really want is a button. You guys figure internally what should be rendering. If it is a low-end phone maybe it is just straight up post form. It if it is a mid-range phone with CSS, maybe you could layer CSS on there. But if it is a high-end phone you really want an AJAX style experience. So, this technique was pioneered by somebody like Yahoo blueprint. So, instead of saying at the top level that this is going to be a good site and this is going to be a low-end site, each component inside that declarative markup that renders the display will decide what it is able to do. And they compose together to form the ideal experience for that phone. This technique is called progressive enhancement.
So, this actually got us to the point where we were able to write once and run anywhere across the Web. And, you know, the Web seems doable. You can do that on your desktop browsers already. Mobile is getting to the point where you actually can do this using a system like this. But, you guys are probably bored about hearing about the Web, despite the fact that an iPhone user and Android user, whoever, can go use a mobile website competently because they all have good browsers, everyone wants an iPhone feature.
So, we were able to eliminate on of our four stacks and get to the point where we had three and that is great. But, of cours[…]
2011_Redux
from google
Facebook mobile is predicated on browser technology. As Facebook's engineering manager Dave Fetterman says in the transcript below, the browser is what Facebook is good at, how it got where it is now and how it will iterate for the future of mobile. We will touch on the future tomorrow, but be sure to read Fetterman's presentation at Facebook's f8 developer conference below because it will inform what we are going to explore tomorrow morning. Really, how did Facebook design for all those platforms and devices?
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
What is below is a direct transcript with photos from Fetterman's f8 presentation. A few things to note:
Facebook mobile has its backbone in its mobile website. Everything that is built into the native applications actually comes from the mobile Web. Think of the way PhoneGap wraps a browser-based website and that is how Facebook approached the problem. And then some.
HTML5 is the future. The fourth page gets into how all of this history is leading Facebook to a precipice of change with HTML5 and the so-called Project Spartan.
Also note that Fetterman talks fast and occasionally swears. He is the classic Facebook engineer: kind of young, pretty brash and supremely confident. The transcript is as true to his actual words as possible.
Changing Mobile Standards Through The Past Five Years
We took an extreme HTML-based approach to this. So we will go into how we do this so you can learn how HTML5 is the way out of a lot of these problems.
Because, it wasn't really always this way for us. We have had the same mobile problems that you guys have. We are following the same mobile ecosystem that you guys are following to develop for your users.
So, we have the same problems of cross-platform development that you have and we are hoping that you can learn a little bit from us. So, we have been learning to deal with these issues with what we call "FaceWeb" and learning a new opportunity to get out of this that is emerging as we speak called HTML5.
So, in 2006, building a mobile presence meant that you had a WAP deck that was based on an HTML application with SMS and all of that. But, as you all know, mobile changed fundamentally in 2007. What happened then?
[Crowd] - The iPhone.
The iPhone! Great. What else happened in 2007, perhaps unveiling in the room that you are sitting in right now?
[Crowd] - The Platform.
Yes, the Facebook Platform API. So, what changed for us is that we had to develop a second user experience for the iPhone. A computer in your pocket that no longer sucked. So, it could have Javascript, a CSS and a really rich interaction model. In addition there was Facebook for BlackBerry, Facebook for Windows phone, for Nokia, for Samsung, for everyone now available through the Facebook API.
How about 2008? What was the big thing that happened in 2008?
[Crowd] - Ummm ... Android?
I will pretend that I heard the iPhone App Store. What most developers don't realize is that the first version of the iPhone, you could build websites but the App Store was not available to later. So, in 2008, the App Store enables us to build Facebook for iPhone. The flagship, the vanguard, the best substantiation of Facebook. Based off the API, the same way that you guys are building apps off the API now.
In 2009, what changed in 2009?
[Crowd] Ummm ... Android?
Android, yes. I will pretend that I heard Android. Android was the new player in 2009 and really started taking off. So, all of a sudden we have all of these users on all these devices using Facebook mobile in the wide rainbow of lovely different experiences across Android, iPhone, Windows, the Web. That was great from a user perspective. What sucks? The environment for my developers, essentially. You have the bad old days. You have four different platforms to build for something essentially. You want to build for all of those groups? You are going to have to build the sucker four times. Then there are all of the features - groups, deals, the new profile. All of this stuff and the matrix got really bad. So, we have to build things four times which means that the code gets slow. The code gets old. There are different versions of parity and things just don't work together which makes it extremely difficult for a fast moving company like Facebook.
Next page: Fetterman describes how Facebook reconciled M.Sites and Touch
How To Not Write The Same Functionality Four Times
So, how do we solve this problem? If we have any shot at solving this problem of building things four times ... if you want to build it once, the Web is probably your best shot. So, back in the day we said that we have two websites, right? We have touch.facebook.com and we have m.facebook.com. Different complete docket roots and who decided what is was going to be, where you are going to go based on your phone? Well, it wasn't that complicated. If you were a Webkit phone, you basically redirected towards touch, if you didn't, you got M. If you had CSS, hey, we could throw that in there, no charge, no problem. So, have had this guess and redirect sort of approach to the Web.
That doesn't really solve the problem of everyone having and optimized experience for their phone. Even things like inline images inside the screen, across CSS and versions, that is really problematic when you that those to my right are saved, those to my left are damned. That is the way it is going to work. So, if we had any chance of unifying these two groups and building something once for the mobile Web, we had to solve this problem.
So, what do we need to do? WebKit wasn't enough, we had to have a better level of granularity. What is the difference between a Javascript enabled mobile website from a non-Javascript enabled mobile website? Really, Javascript is there to enable certain types of display and certain type of interaction, primarily AJAX. But, when you think about the controller --- what is Groups? What is the news feed? What is Message? Those are kind of the same thing and they really don't have to be written twice. So back in the day you had to use inefficient solutions like NetBiscuits which were opaque. You could do some XSL post-processing but you can't post-process your way to good Javascript, it doesn't work. With Webkit you started to get poly-fills and modernizer and all this great stuff. But, you actually needed a way to write your code once.
Progressive Enhancement
Here is what we did.
The cornerstone of this is detecting what your phone is going to be able to do. Capabilities, then you can start the right experience. You guys heard of WURFL at all? Wireless Universal Resource File? This is one of the projects out there that attempts to map a user to a user-agent set of capabilities. You know, what is your screen size? What is your JS? Can it do cookies? These are all pernicious, nasty problems that need to be solved. And the use-agent, as you guys can tell, doesn't do the job. So, you need an open database for manufacturers and concerned citizens to be able to tell you what is up. We sponsored this project and this project is continuing to evolve as an open source data site.
So, once you have these capabilities you actually have to figure out what to do with these. A button on Facebook isn't just like it is HTML or this block of Javascript or something. What you want for the homepage is to have your composers render a button that does something. So, you guys say what we really want is a button. You guys figure internally what should be rendering. If it is a low-end phone maybe it is just straight up post form. It if it is a mid-range phone with CSS, maybe you could layer CSS on there. But if it is a high-end phone you really want an AJAX style experience. So, this technique was pioneered by somebody like Yahoo blueprint. So, instead of saying at the top level that this is going to be a good site and this is going to be a low-end site, each component inside that declarative markup that renders the display will decide what it is able to do. And they compose together to form the ideal experience for that phone. This technique is called progressive enhancement.
So, this actually got us to the point where we were able to write once and run anywhere across the Web. And, you know, the Web seems doable. You can do that on your desktop browsers already. Mobile is getting to the point where you actually can do this using a system like this. But, you guys are probably bored about hearing about the Web, despite the fact that an iPhone user and Android user, whoever, can go use a mobile website competently because they all have good browsers, everyone wants an iPhone feature.
So, we were able to eliminate on of our four stacks and get to the point where we had three and that is great. But, of cours[…]
december 2011 by rahuldave
5 Tools to Improve Your Idea Before You Write a Line of Code
december 2011 by rahuldave
In my last post on ReadWriteStart, I talked about how, in many cases, it wasn't an advantage to build your start-up in stealth mode. As a continuation of that theme, I thought it would be interesting to explore five tools you can use to iterate and improve your startup idea before writing one line of code. There is nothing worse than building a tool no one is interested in, so I'd encourage you to consider these options before starting down the path of building your next startup.
Specifically, these five tools can help you do three critical activities before starting to write a line of code: create a wireframe, get feedback from the target market and test value proposition through multiple landing pages.
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
iMockups for Wireframing Concepts
If a picture is worth 1,000 words, then a good mockup is worth 1,000 lines of code. If you own an iPad, iMockups is a killer solution to quickly and efficiently create wireframes. It's been interesting to watch a number of the startups I advise shift from trying to use PowerPoint or Keynote to flesh out concepts, to using iMockups. The feedback from those startups has consistently been that the iMockups tool makes it so much faster to put wireframes together that the time savings was well worth the $10. Check out the video below to see iMockups in action:
Feedback on Concept from Target Market
Once you've got a concept put together, it's often valuable to get some early feedback from your target market. Obviously, in many cases this can be done by setting up meetings with your target customers and walking them through the idea.
Another simple and relatively low cost way to get feedback from a critical mass of potential users is to use Ask Your Target Market. While there are a lot of online survey tools, the nice thing about this tool is it has developed a great network of respondents (or "panel" in market research parlance) who you can target for response. This allows you to get statistically meaningful feedback from a specific target audience.
Build & Test Landing Pages
A final obvious technique to testing and improving your idea is to build some landing pages to test out different value propositions.
LaunchRock: We've covered them a few times before, but with tools like LaunchRock that have automated the process of developing these landing pages this is a great way to test interest and get signups.
If you aren't familiar with LaunchRock, see the video the team did for a demo with Robert Scoble:
A/B Testing Different Value Propositions: To take this approach to the next level, you can even use a solution like Optimizely, Google Website Optimizer or Sumo Optimizer. For a thorough review of these options check out this analysis on our SMB channel ReadWriteBiz of the tools. The general technique of optimizing your landing page is a practice most startups should do. But before you build out your solution you can actually see which value propositions and features are more compelling by testing which call to action - for example "find new sources of information" vs "filter the information you already read" - gets a higher percentage of requests from users.
Conclusion
As an entrepreneur, you have to figure out the right plan to test and build your product. However, locking yourself in a room and designing and then building your product is rarely optimal. Before opening your IDE of choice, maybe the best step next time is to launch one of the tools mentioned above and started getting some feedback? Do you have other techniques to test out your ideas? Let me know in the comments below.
Test tube image from Horia Varlan
Discuss
2011_Redux
from google
Specifically, these five tools can help you do three critical activities before starting to write a line of code: create a wireframe, get feedback from the target market and test value proposition through multiple landing pages.
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
iMockups for Wireframing Concepts
If a picture is worth 1,000 words, then a good mockup is worth 1,000 lines of code. If you own an iPad, iMockups is a killer solution to quickly and efficiently create wireframes. It's been interesting to watch a number of the startups I advise shift from trying to use PowerPoint or Keynote to flesh out concepts, to using iMockups. The feedback from those startups has consistently been that the iMockups tool makes it so much faster to put wireframes together that the time savings was well worth the $10. Check out the video below to see iMockups in action:
Feedback on Concept from Target Market
Once you've got a concept put together, it's often valuable to get some early feedback from your target market. Obviously, in many cases this can be done by setting up meetings with your target customers and walking them through the idea.
Another simple and relatively low cost way to get feedback from a critical mass of potential users is to use Ask Your Target Market. While there are a lot of online survey tools, the nice thing about this tool is it has developed a great network of respondents (or "panel" in market research parlance) who you can target for response. This allows you to get statistically meaningful feedback from a specific target audience.
Build & Test Landing Pages
A final obvious technique to testing and improving your idea is to build some landing pages to test out different value propositions.
LaunchRock: We've covered them a few times before, but with tools like LaunchRock that have automated the process of developing these landing pages this is a great way to test interest and get signups.
If you aren't familiar with LaunchRock, see the video the team did for a demo with Robert Scoble:
A/B Testing Different Value Propositions: To take this approach to the next level, you can even use a solution like Optimizely, Google Website Optimizer or Sumo Optimizer. For a thorough review of these options check out this analysis on our SMB channel ReadWriteBiz of the tools. The general technique of optimizing your landing page is a practice most startups should do. But before you build out your solution you can actually see which value propositions and features are more compelling by testing which call to action - for example "find new sources of information" vs "filter the information you already read" - gets a higher percentage of requests from users.
Conclusion
As an entrepreneur, you have to figure out the right plan to test and build your product. However, locking yourself in a room and designing and then building your product is rarely optimal. Before opening your IDE of choice, maybe the best step next time is to launch one of the tools mentioned above and started getting some feedback? Do you have other techniques to test out your ideas? Let me know in the comments below.
Test tube image from Horia Varlan
Discuss
december 2011 by rahuldave
5 Tools to Improve Your Idea Before You Write a Line of Code
december 2011 by rahuldave
In my last post on ReadWriteStart, I talked about how, in many cases, it wasn't an advantage to build your start-up in stealth mode. As a continuation of that theme, I thought it would be interesting to explore five tools you can use to iterate and improve your startup idea before writing one line of code. There is nothing worse than building a tool no one is interested in, so I'd encourage you to consider these options before starting down the path of building your next startup.
Specifically, these five tools can help you do three critical activities before starting to write a line of code: create a wireframe, get feedback from the target market and test value proposition through multiple landing pages.
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
iMockups for Wireframing Concepts
If a picture is worth 1,000 words, then a good mockup is worth 1,000 lines of code. If you own an iPad, iMockups is a killer solution to quickly and efficiently create wireframes. It's been interesting to watch a number of the startups I advise shift from trying to use PowerPoint or Keynote to flesh out concepts, to using iMockups. The feedback from those startups has consistently been that the iMockups tool makes it so much faster to put wireframes together that the time savings was well worth the $10. Check out the video below to see iMockups in action:
Feedback on Concept from Target Market
Once you've got a concept put together, it's often valuable to get some early feedback from your target market. Obviously, in many cases this can be done by setting up meetings with your target customers and walking them through the idea.
Another simple and relatively low cost way to get feedback from a critical mass of potential users is to use Ask Your Target Market. While there are a lot of online survey tools, the nice thing about this tool is it has developed a great network of respondents (or "panel" in market research parlance) who you can target for response. This allows you to get statistically meaningful feedback from a specific target audience.
Build & Test Landing Pages
A final obvious technique to testing and improving your idea is to build some landing pages to test out different value propositions.
LaunchRock: We've covered them a few times before, but with tools like LaunchRock that have automated the process of developing these landing pages this is a great way to test interest and get signups.
If you aren't familiar with LaunchRock, see the video the team did for a demo with Robert Scoble:
A/B Testing Different Value Propositions: To take this approach to the next level, you can even use a solution like Optimizely, Google Website Optimizer or Sumo Optimizer. For a thorough review of these options check out this analysis on our SMB channel ReadWriteBiz of the tools. The general technique of optimizing your landing page is a practice most startups should do. But before you build out your solution you can actually see which value propositions and features are more compelling by testing which call to action - for example "find new sources of information" vs "filter the information you already read" - gets a higher percentage of requests from users.
Conclusion
As an entrepreneur, you have to figure out the right plan to test and build your product. However, locking yourself in a room and designing and then building your product is rarely optimal. Before opening your IDE of choice, maybe the best step next time is to launch one of the tools mentioned above and started getting some feedback? Do you have other techniques to test out your ideas? Let me know in the comments below.
Test tube image from Horia Varlan
Discuss
2011_Redux
from google
Specifically, these five tools can help you do three critical activities before starting to write a line of code: create a wireframe, get feedback from the target market and test value proposition through multiple landing pages.
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
iMockups for Wireframing Concepts
If a picture is worth 1,000 words, then a good mockup is worth 1,000 lines of code. If you own an iPad, iMockups is a killer solution to quickly and efficiently create wireframes. It's been interesting to watch a number of the startups I advise shift from trying to use PowerPoint or Keynote to flesh out concepts, to using iMockups. The feedback from those startups has consistently been that the iMockups tool makes it so much faster to put wireframes together that the time savings was well worth the $10. Check out the video below to see iMockups in action:
Feedback on Concept from Target Market
Once you've got a concept put together, it's often valuable to get some early feedback from your target market. Obviously, in many cases this can be done by setting up meetings with your target customers and walking them through the idea.
Another simple and relatively low cost way to get feedback from a critical mass of potential users is to use Ask Your Target Market. While there are a lot of online survey tools, the nice thing about this tool is it has developed a great network of respondents (or "panel" in market research parlance) who you can target for response. This allows you to get statistically meaningful feedback from a specific target audience.
Build & Test Landing Pages
A final obvious technique to testing and improving your idea is to build some landing pages to test out different value propositions.
LaunchRock: We've covered them a few times before, but with tools like LaunchRock that have automated the process of developing these landing pages this is a great way to test interest and get signups.
If you aren't familiar with LaunchRock, see the video the team did for a demo with Robert Scoble:
A/B Testing Different Value Propositions: To take this approach to the next level, you can even use a solution like Optimizely, Google Website Optimizer or Sumo Optimizer. For a thorough review of these options check out this analysis on our SMB channel ReadWriteBiz of the tools. The general technique of optimizing your landing page is a practice most startups should do. But before you build out your solution you can actually see which value propositions and features are more compelling by testing which call to action - for example "find new sources of information" vs "filter the information you already read" - gets a higher percentage of requests from users.
Conclusion
As an entrepreneur, you have to figure out the right plan to test and build your product. However, locking yourself in a room and designing and then building your product is rarely optimal. Before opening your IDE of choice, maybe the best step next time is to launch one of the tools mentioned above and started getting some feedback? Do you have other techniques to test out your ideas? Let me know in the comments below.
Test tube image from Horia Varlan
Discuss
december 2011 by rahuldave
Hilary Mason Wants To Get You Started With Big Data
december 2011 by rahuldave
I spent part of this week with Hilary Mason, one of the smartest people that I know in Big Data. She works as the Chief Scientist for Bit.ly and has a wealth of skills at her fingertips that bridge computer science and mathematics. Plus, she is used to facing largely male audiences and just being the smartest person in the room. She was speaking at The Strange Loop conference in St. Louis this week, which should definitely be on your radar for next year if you are interested in this topic or want to broaden your programming skills.
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
Mason outlined in a series of workshops the tools you need to get started with manipulating Big Data and understanding the basics of machine learning, something she does everyday as she sifts through each one of those shortened URLs that we all create furiously. (You can read about her latest revelation here which we wrote about earlier in the month.) You know when she says, "this is a hard problem" that she is really saying "this is a problem that I haven't yet figured out the best answer to." To each problem, her credo is Obtain, Scrub, Explore, Model, and Interpret. I'll review each of these steps.
The first step is setting up a proper environment, and for Mason it is a Linux machine with a variety of tools on it that you can find on her Github page linked above. She is a Python programmer, and so this reflects that interest. She uses Python with JSONview's Chrome extension, NLTK, numpy, Pycluster, hcluster, and mathplotlib. You can use most of these tools on other OSs too.
Second, you need to obtain a few test data sets that you can start to manipulate. Even if you aren't drinking out of the Bit.ly data fire hose, there are ways to get access to lots of great data around the Internet. Mason mentioned a few places, including:
The New York Times. Each and every article that is posted on the main NYT Web site going back dozens of years has oodles of metadata and tags galore. Just view the source on any news article to see how the human editors have classified it. You'll need to start off by registering for an API key here and then select "Article Search API"
Mason has put together several dozen different bundles of research-quality data sets at this link here
Pete Skomoroch's various sample datasets that he has collected, and there is always the epic reference
Data Source Handbook by Pete Warden
Some of these datasets have gotten almost urban legend status, such as the email collection that was part of all the Enron court cases: this is useful for testing anti-spam programs, even though it is several years old. Because of how people use Bit.ly, Mason said that they usually see malware and other bad stuff several hours before anyone else has picked it up around the Internet.
Third, you need to start thinking about how to make your data sets smaller. "Big Data usually refers to a data set that is too big to fit into your available memory, or too big to store on your own hard drive, or too big to fit into an Excel spreadsheet," says Mason. This is the "scrub" section. The smaller the dataset, the easier it is to manipulate and analyze.
Now comes the fun part, exploring your data. You want to ask questions and figure out patterns. If you are using the NYTimes data for example, you could look at words that are most frequently used to describe political candidates, or are particular words more often used in the technology section than in the sports section.
Next comes the mathematical modeling portion of the program. If you don't have a lot of depth in probability or statistics, you are going to need some help here. Mason rolls off the math almost as if she is speaking fluently in a foreign language. And given that I was an undergraduate math major, I can only understand your own frustrations here when you see something with the Greek Sigma sign (hint: that means a sum of things). She let slip the words "fourier transform" which brought me to the Wikipedia definition before I could try to remember what it was. But the essence here is to write code to get the answers of the questions that you are asking in your explorations.
Finally is interpretation. You want to put the answers that you obtained from your modeling into the context of why they are important. You may need to do some visualizations or reporting so that your results can be understood. Or you may choose to omit this part if your answers are sufficient for your particular purposes. Mason mentioned her spam-fighting tactics that she uses to cleanse the shortened URLs from evil doers. "As long as our routines seemed to be working, that was good enough for us and so we just stopped," she said. Part of this process is understanding when you have the best answer that you are going to have to your questions, "knowing when you have won" as she says.
If you are looking to learn more, a good place is to sign up for one of Stanford's free classes on AI, Machine Learning, and databases here. The classes start October 10 and continue until mid-December. They are free and you submit homework assignments and do everything that you would normally do in a typical CS class, including getting help from teaching assistants too.
Mason is lucky to have such a large playground to operate in, and we are lucky when we can sit at her feet and try to understand the totality of her experience. I hope I have given you a taste for the world of Big Data here and some of the best ways to get started at your own analysis. And if you need more motivation, she tells me that just about everyone is hiring their own "data person" these days, so if you get good enough at you probably have your pick of employers for years to come.
Discuss
2011_Redux
from google
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
Mason outlined in a series of workshops the tools you need to get started with manipulating Big Data and understanding the basics of machine learning, something she does everyday as she sifts through each one of those shortened URLs that we all create furiously. (You can read about her latest revelation here which we wrote about earlier in the month.) You know when she says, "this is a hard problem" that she is really saying "this is a problem that I haven't yet figured out the best answer to." To each problem, her credo is Obtain, Scrub, Explore, Model, and Interpret. I'll review each of these steps.
The first step is setting up a proper environment, and for Mason it is a Linux machine with a variety of tools on it that you can find on her Github page linked above. She is a Python programmer, and so this reflects that interest. She uses Python with JSONview's Chrome extension, NLTK, numpy, Pycluster, hcluster, and mathplotlib. You can use most of these tools on other OSs too.
Second, you need to obtain a few test data sets that you can start to manipulate. Even if you aren't drinking out of the Bit.ly data fire hose, there are ways to get access to lots of great data around the Internet. Mason mentioned a few places, including:
The New York Times. Each and every article that is posted on the main NYT Web site going back dozens of years has oodles of metadata and tags galore. Just view the source on any news article to see how the human editors have classified it. You'll need to start off by registering for an API key here and then select "Article Search API"
Mason has put together several dozen different bundles of research-quality data sets at this link here
Pete Skomoroch's various sample datasets that he has collected, and there is always the epic reference
Data Source Handbook by Pete Warden
Some of these datasets have gotten almost urban legend status, such as the email collection that was part of all the Enron court cases: this is useful for testing anti-spam programs, even though it is several years old. Because of how people use Bit.ly, Mason said that they usually see malware and other bad stuff several hours before anyone else has picked it up around the Internet.
Third, you need to start thinking about how to make your data sets smaller. "Big Data usually refers to a data set that is too big to fit into your available memory, or too big to store on your own hard drive, or too big to fit into an Excel spreadsheet," says Mason. This is the "scrub" section. The smaller the dataset, the easier it is to manipulate and analyze.
Now comes the fun part, exploring your data. You want to ask questions and figure out patterns. If you are using the NYTimes data for example, you could look at words that are most frequently used to describe political candidates, or are particular words more often used in the technology section than in the sports section.
Next comes the mathematical modeling portion of the program. If you don't have a lot of depth in probability or statistics, you are going to need some help here. Mason rolls off the math almost as if she is speaking fluently in a foreign language. And given that I was an undergraduate math major, I can only understand your own frustrations here when you see something with the Greek Sigma sign (hint: that means a sum of things). She let slip the words "fourier transform" which brought me to the Wikipedia definition before I could try to remember what it was. But the essence here is to write code to get the answers of the questions that you are asking in your explorations.
Finally is interpretation. You want to put the answers that you obtained from your modeling into the context of why they are important. You may need to do some visualizations or reporting so that your results can be understood. Or you may choose to omit this part if your answers are sufficient for your particular purposes. Mason mentioned her spam-fighting tactics that she uses to cleanse the shortened URLs from evil doers. "As long as our routines seemed to be working, that was good enough for us and so we just stopped," she said. Part of this process is understanding when you have the best answer that you are going to have to your questions, "knowing when you have won" as she says.
If you are looking to learn more, a good place is to sign up for one of Stanford's free classes on AI, Machine Learning, and databases here. The classes start October 10 and continue until mid-December. They are free and you submit homework assignments and do everything that you would normally do in a typical CS class, including getting help from teaching assistants too.
Mason is lucky to have such a large playground to operate in, and we are lucky when we can sit at her feet and try to understand the totality of her experience. I hope I have given you a taste for the world of Big Data here and some of the best ways to get started at your own analysis. And if you need more motivation, she tells me that just about everyone is hiring their own "data person" these days, so if you get good enough at you probably have your pick of employers for years to come.
Discuss
december 2011 by rahuldave
Hilary Mason Wants To Get You Started With Big Data
december 2011 by rahuldave
I spent part of this week with Hilary Mason, one of the smartest people that I know in Big Data. She works as the Chief Scientist for Bit.ly and has a wealth of skills at her fingertips that bridge computer science and mathematics. Plus, she is used to facing largely male audiences and just being the smartest person in the room. She was speaking at The Strange Loop conference in St. Louis this week, which should definitely be on your radar for next year if you are interested in this topic or want to broaden your programming skills.
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
Mason outlined in a series of workshops the tools you need to get started with manipulating Big Data and understanding the basics of machine learning, something she does everyday as she sifts through each one of those shortened URLs that we all create furiously. (You can read about her latest revelation here which we wrote about earlier in the month.) You know when she says, "this is a hard problem" that she is really saying "this is a problem that I haven't yet figured out the best answer to." To each problem, her credo is Obtain, Scrub, Explore, Model, and Interpret. I'll review each of these steps.
The first step is setting up a proper environment, and for Mason it is a Linux machine with a variety of tools on it that you can find on her Github page linked above. She is a Python programmer, and so this reflects that interest. She uses Python with JSONview's Chrome extension, NLTK, numpy, Pycluster, hcluster, and mathplotlib. You can use most of these tools on other OSs too.
Second, you need to obtain a few test data sets that you can start to manipulate. Even if you aren't drinking out of the Bit.ly data fire hose, there are ways to get access to lots of great data around the Internet. Mason mentioned a few places, including:
The New York Times. Each and every article that is posted on the main NYT Web site going back dozens of years has oodles of metadata and tags galore. Just view the source on any news article to see how the human editors have classified it. You'll need to start off by registering for an API key here and then select "Article Search API"
Mason has put together several dozen different bundles of research-quality data sets at this link here
Pete Skomoroch's various sample datasets that he has collected, and there is always the epic reference
Data Source Handbook by Pete Warden
Some of these datasets have gotten almost urban legend status, such as the email collection that was part of all the Enron court cases: this is useful for testing anti-spam programs, even though it is several years old. Because of how people use Bit.ly, Mason said that they usually see malware and other bad stuff several hours before anyone else has picked it up around the Internet.
Third, you need to start thinking about how to make your data sets smaller. "Big Data usually refers to a data set that is too big to fit into your available memory, or too big to store on your own hard drive, or too big to fit into an Excel spreadsheet," says Mason. This is the "scrub" section. The smaller the dataset, the easier it is to manipulate and analyze.
Now comes the fun part, exploring your data. You want to ask questions and figure out patterns. If you are using the NYTimes data for example, you could look at words that are most frequently used to describe political candidates, or are particular words more often used in the technology section than in the sports section.
Next comes the mathematical modeling portion of the program. If you don't have a lot of depth in probability or statistics, you are going to need some help here. Mason rolls off the math almost as if she is speaking fluently in a foreign language. And given that I was an undergraduate math major, I can only understand your own frustrations here when you see something with the Greek Sigma sign (hint: that means a sum of things). She let slip the words "fourier transform" which brought me to the Wikipedia definition before I could try to remember what it was. But the essence here is to write code to get the answers of the questions that you are asking in your explorations.
Finally is interpretation. You want to put the answers that you obtained from your modeling into the context of why they are important. You may need to do some visualizations or reporting so that your results can be understood. Or you may choose to omit this part if your answers are sufficient for your particular purposes. Mason mentioned her spam-fighting tactics that she uses to cleanse the shortened URLs from evil doers. "As long as our routines seemed to be working, that was good enough for us and so we just stopped," she said. Part of this process is understanding when you have the best answer that you are going to have to your questions, "knowing when you have won" as she says.
If you are looking to learn more, a good place is to sign up for one of Stanford's free classes on AI, Machine Learning, and databases here. The classes start October 10 and continue until mid-December. They are free and you submit homework assignments and do everything that you would normally do in a typical CS class, including getting help from teaching assistants too.
Mason is lucky to have such a large playground to operate in, and we are lucky when we can sit at her feet and try to understand the totality of her experience. I hope I have given you a taste for the world of Big Data here and some of the best ways to get started at your own analysis. And if you need more motivation, she tells me that just about everyone is hiring their own "data person" these days, so if you get good enough at you probably have your pick of employers for years to come.
Discuss
2011_Redux
from google
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
Mason outlined in a series of workshops the tools you need to get started with manipulating Big Data and understanding the basics of machine learning, something she does everyday as she sifts through each one of those shortened URLs that we all create furiously. (You can read about her latest revelation here which we wrote about earlier in the month.) You know when she says, "this is a hard problem" that she is really saying "this is a problem that I haven't yet figured out the best answer to." To each problem, her credo is Obtain, Scrub, Explore, Model, and Interpret. I'll review each of these steps.
The first step is setting up a proper environment, and for Mason it is a Linux machine with a variety of tools on it that you can find on her Github page linked above. She is a Python programmer, and so this reflects that interest. She uses Python with JSONview's Chrome extension, NLTK, numpy, Pycluster, hcluster, and mathplotlib. You can use most of these tools on other OSs too.
Second, you need to obtain a few test data sets that you can start to manipulate. Even if you aren't drinking out of the Bit.ly data fire hose, there are ways to get access to lots of great data around the Internet. Mason mentioned a few places, including:
The New York Times. Each and every article that is posted on the main NYT Web site going back dozens of years has oodles of metadata and tags galore. Just view the source on any news article to see how the human editors have classified it. You'll need to start off by registering for an API key here and then select "Article Search API"
Mason has put together several dozen different bundles of research-quality data sets at this link here
Pete Skomoroch's various sample datasets that he has collected, and there is always the epic reference
Data Source Handbook by Pete Warden
Some of these datasets have gotten almost urban legend status, such as the email collection that was part of all the Enron court cases: this is useful for testing anti-spam programs, even though it is several years old. Because of how people use Bit.ly, Mason said that they usually see malware and other bad stuff several hours before anyone else has picked it up around the Internet.
Third, you need to start thinking about how to make your data sets smaller. "Big Data usually refers to a data set that is too big to fit into your available memory, or too big to store on your own hard drive, or too big to fit into an Excel spreadsheet," says Mason. This is the "scrub" section. The smaller the dataset, the easier it is to manipulate and analyze.
Now comes the fun part, exploring your data. You want to ask questions and figure out patterns. If you are using the NYTimes data for example, you could look at words that are most frequently used to describe political candidates, or are particular words more often used in the technology section than in the sports section.
Next comes the mathematical modeling portion of the program. If you don't have a lot of depth in probability or statistics, you are going to need some help here. Mason rolls off the math almost as if she is speaking fluently in a foreign language. And given that I was an undergraduate math major, I can only understand your own frustrations here when you see something with the Greek Sigma sign (hint: that means a sum of things). She let slip the words "fourier transform" which brought me to the Wikipedia definition before I could try to remember what it was. But the essence here is to write code to get the answers of the questions that you are asking in your explorations.
Finally is interpretation. You want to put the answers that you obtained from your modeling into the context of why they are important. You may need to do some visualizations or reporting so that your results can be understood. Or you may choose to omit this part if your answers are sufficient for your particular purposes. Mason mentioned her spam-fighting tactics that she uses to cleanse the shortened URLs from evil doers. "As long as our routines seemed to be working, that was good enough for us and so we just stopped," she said. Part of this process is understanding when you have the best answer that you are going to have to your questions, "knowing when you have won" as she says.
If you are looking to learn more, a good place is to sign up for one of Stanford's free classes on AI, Machine Learning, and databases here. The classes start October 10 and continue until mid-December. They are free and you submit homework assignments and do everything that you would normally do in a typical CS class, including getting help from teaching assistants too.
Mason is lucky to have such a large playground to operate in, and we are lucky when we can sit at her feet and try to understand the totality of her experience. I hope I have given you a taste for the world of Big Data here and some of the best ways to get started at your own analysis. And if you need more motivation, she tells me that just about everyone is hiring their own "data person" these days, so if you get good enough at you probably have your pick of employers for years to come.
Discuss
december 2011 by rahuldave
How the Boston Globe Pulled Off HTML5 Responsive Design
december 2011 by rahuldave
On Monday, The Boston Globe released its new premium content mobile initiative dubbed BostonGlobe.com. That is not to be confused with Boston.com, its free flagship website. This unto itself is not all that interesting. Yet, the HTML5 development community is heaping praise on BostonGlobe.com primarily for how the sites renders across varying screen sizes, an innovation called responsive design.
Responsive design allows the Globe's content to be refitted to any screen size available automatically. It is a win in the fight against mobile device fragmentation and screen sizes and the future of how content is displayed on mobile devices. Below is an in-depth discussion with the creators of the Globe's responsive design and the challenges they faced along the way.
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
Filament Group Makes A Big Step In The Evolution of HTML5
The Boston Globe enlisted the services of Filament Group, a Boston-based design and development firm that focuses on accessibility. Below is a transcript of a conversation between ReadWriteMobile and three Filament Group designers and partners that were instrumental in bringing responsive design to reality. Todd Parker and Scott Jehl are both partners while Mat Marquis was one of the main developers that was "camped out" at the Globe during the design process. The man they call the "father" of responsive design, Ethan Marcotte, was not available to comment at this time.
Check out BostonGlobe.com's responsive design in action.
On how it got started
Todd Parker
I think we started the project in November. We started the front-end templates and were working with the designers up until late spring and then we have been doing a lot of integration support through the summer up until the launch.
Technical Challenges
I think up until now it has only been used in blogs and portfolios and things like that. The pieces have been there but it just hasn't been put together. I think it is also having a client that is that this is brave enough to say that this important for their business and makes the leap. Because it does take more time and more testing and things like that than your typical Web developer that can just throw something together.
So, in terms of technical challenges, I think a lot of it was media queries. A lot of things are reliant on media queries and Internet Explorer doesn't really support them in the versions that you can target. So, one of the things we had to target was a polyfill that can be used for media queries. There were some others out there that were too slow for our needs and so we created RespondJS that is a really fast, lightweight polyfill for media queries. That is one of the first things that we kind of had to solve on this project to really make it work. Otherwise it was just too slow.
The other big challenge that we were working on here was responsive images. So, everything we are doing is taking a mobile-first approach so that means that the page that is served up is as lean and lightweight as possible and that includes images. So, if you look at the Globe's site they have these big images that are a thousand pixels wide and they are really big and really rich, like the Big Picture, on all the article pages. So, what we doing in the HTML is actually referencing a smaller, low bandwidth image and we figured out a little trickery that if you are on a device like a tablet or a desktop that could use the high resolution image and if it does that is a loaded reaction flip. So, if you are on mobile you get the low resolution image and if you are on a browser or a tablet you get the high resolution image. So, delivering the appropriate image to the appropriate device was another technical challenge that took up quite a bit of work to actually work in a real CMS environment.
Next Page: More of the discussion with Filament Group and pictures and video of the new BostonGlobe.com.
On Challenges Posed By Advertising
Matt Marquis
I think one of the real challenges was not knowing what the challenges were going to be and kind of uncovering a lot of new problems here that no one has solved in the past. So, it requires a lot of new solutions that no one has never thought up. It is a lot of hard work.
Parker
I think we did a good job of kind of authoritatively solving those issues for the Globe. One of the trickier ones that is still a bit unresolved is advertising. Ads do all sorts of really ugly things with Javascript and reaching into the page. Getting those to be sandboxed and safe and not turning the page into some heavy broken mess was a pretty tricky solution.
Marquis
We have a pretty solid solution in place for those now. The general rule is that the more obtrusive they are from a user perspective, the tougher they are on us. We don't have any giant interstitials, we don't have any ads taking over the whole page which would be a lot more challenging to deal with. We have a couple of box ads and a couple of banner ads that are pretty easy to deal with now. We can sandbox those and keep them from destroying everything else that is on the website.
Parker
There is the technical side of advertising and making sure that plays nice with our approach. That was tricky. The other thing is that the way that ads are sold hasn't really caught up with this approach. So, they are selling ads for mobile placements in mobile slots and then there is desktop. We are covering such a broad range and we are not making distinctions between those. Where does a seven-inch Android tablet fit into that? Where does the Kindle fit into that? It is this really broad continuum of devices and capabilities. So, this allows us now so that we are basically serving up one ad and just positioning it differently on the page in the CSS. So, it is kind of a single-advertisement approach.
Challenges of Device Recognition and Varying Screen Sizes
Marquis
As far as that goes, we are targeting screen size in terms of display in terms of the features in terms of what we are serving up to the user. So, really, there is no situation where we are saying 'OK, so, if they are on a Android then they get XYZ, if they are on an iPad, they get this that and the other thing.' Really, it is about if they have a device that sports touch then the specific touch feature and will specifically add Javascript. So, we are not serving it up to everybody but just those that have the feature enabled. We would never say that the iPad gets this layout. It is just any screen between one size and another size gets this layout.
Parker
We do not do any user-agent detection. That is a big no-no. So, it is very open ended. So, that is all focused on features and capabilities and we test for those and then dynamically load things in as needed. So, that is why each device gets a bit of a tailored experience in terms of what they download. This tablet here may support touch events and this one doesn't. It might have different resolution and might be getting a different layout.
Marquis
It is clear that we did not plan under any circumstances for anybody to be opening it on a GameBoy, but, when somebody did recently, it worked great on a GameBoy.
Parker
I think the great upside of this is taking a much more agnostic approach rather than targeting any specific user agents. It is all about targeting capabilities. That way when we are working with jQuery mobile, when we get new test devices (and we get new test devices all the time), as they come in and we crack it open and look it on some devices that hadn't been on our radar before and the Globe will look great on it because we don't have to worry about that. So, as devices come out it is a very future compatible approach and works on all the older devices because we are working on progressive enhancement. It will work on your Newtons and old Palms and things like that.
How Is This Possible Now As Opposed To the Recent Past?
Parker
I think it is one of those situations where a year and a half ago maybe this could have been done, it is just a matter of putting all the technical pieces together.
Marquis
I think some facets of this could have been done in the past. I mean, HTML5 has a lot more APIs available for targeting features. Like, being able to check for touch support is technically part of HTML5 even though it is not HTML5 markup. So, that definitely allows us to do all of that conditional loading and such. In terms of the markup itself, we are doing a lot of HTML5 with additional semantic meaning, it could have been done in HTML4, just not meaningfully in terms of the markup.
Parker
For us, we have been focused on universal access. That has kind of been our thing. We have been around for 10 years. I is not just us. I think a lot of people have slowly been putting pieces together and now I think we have the core tools we need to make this really feasible. For example, we wrote a book on progressive enhancement a little over a year ago. That is the foundation that the Globe is built on. To serve up clean semantic HTML and layer on top of that CSS and Javascript in a clean and unobtrusive way. Now we are making more distinctions. Instead of saying you are going to get this enhanced experience because we have more capabilities. Basically what we are saying is that based on your screen size, we are going to target the layout even further.
Marquis
I think my favorite example of that wou[…]
2011_Redux
from google
Responsive design allows the Globe's content to be refitted to any screen size available automatically. It is a win in the fight against mobile device fragmentation and screen sizes and the future of how content is displayed on mobile devices. Below is an in-depth discussion with the creators of the Globe's responsive design and the challenges they faced along the way.
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
Filament Group Makes A Big Step In The Evolution of HTML5
The Boston Globe enlisted the services of Filament Group, a Boston-based design and development firm that focuses on accessibility. Below is a transcript of a conversation between ReadWriteMobile and three Filament Group designers and partners that were instrumental in bringing responsive design to reality. Todd Parker and Scott Jehl are both partners while Mat Marquis was one of the main developers that was "camped out" at the Globe during the design process. The man they call the "father" of responsive design, Ethan Marcotte, was not available to comment at this time.
Check out BostonGlobe.com's responsive design in action.
On how it got started
Todd Parker
I think we started the project in November. We started the front-end templates and were working with the designers up until late spring and then we have been doing a lot of integration support through the summer up until the launch.
Technical Challenges
I think up until now it has only been used in blogs and portfolios and things like that. The pieces have been there but it just hasn't been put together. I think it is also having a client that is that this is brave enough to say that this important for their business and makes the leap. Because it does take more time and more testing and things like that than your typical Web developer that can just throw something together.
So, in terms of technical challenges, I think a lot of it was media queries. A lot of things are reliant on media queries and Internet Explorer doesn't really support them in the versions that you can target. So, one of the things we had to target was a polyfill that can be used for media queries. There were some others out there that were too slow for our needs and so we created RespondJS that is a really fast, lightweight polyfill for media queries. That is one of the first things that we kind of had to solve on this project to really make it work. Otherwise it was just too slow.
The other big challenge that we were working on here was responsive images. So, everything we are doing is taking a mobile-first approach so that means that the page that is served up is as lean and lightweight as possible and that includes images. So, if you look at the Globe's site they have these big images that are a thousand pixels wide and they are really big and really rich, like the Big Picture, on all the article pages. So, what we doing in the HTML is actually referencing a smaller, low bandwidth image and we figured out a little trickery that if you are on a device like a tablet or a desktop that could use the high resolution image and if it does that is a loaded reaction flip. So, if you are on mobile you get the low resolution image and if you are on a browser or a tablet you get the high resolution image. So, delivering the appropriate image to the appropriate device was another technical challenge that took up quite a bit of work to actually work in a real CMS environment.
Next Page: More of the discussion with Filament Group and pictures and video of the new BostonGlobe.com.
On Challenges Posed By Advertising
Matt Marquis
I think one of the real challenges was not knowing what the challenges were going to be and kind of uncovering a lot of new problems here that no one has solved in the past. So, it requires a lot of new solutions that no one has never thought up. It is a lot of hard work.
Parker
I think we did a good job of kind of authoritatively solving those issues for the Globe. One of the trickier ones that is still a bit unresolved is advertising. Ads do all sorts of really ugly things with Javascript and reaching into the page. Getting those to be sandboxed and safe and not turning the page into some heavy broken mess was a pretty tricky solution.
Marquis
We have a pretty solid solution in place for those now. The general rule is that the more obtrusive they are from a user perspective, the tougher they are on us. We don't have any giant interstitials, we don't have any ads taking over the whole page which would be a lot more challenging to deal with. We have a couple of box ads and a couple of banner ads that are pretty easy to deal with now. We can sandbox those and keep them from destroying everything else that is on the website.
Parker
There is the technical side of advertising and making sure that plays nice with our approach. That was tricky. The other thing is that the way that ads are sold hasn't really caught up with this approach. So, they are selling ads for mobile placements in mobile slots and then there is desktop. We are covering such a broad range and we are not making distinctions between those. Where does a seven-inch Android tablet fit into that? Where does the Kindle fit into that? It is this really broad continuum of devices and capabilities. So, this allows us now so that we are basically serving up one ad and just positioning it differently on the page in the CSS. So, it is kind of a single-advertisement approach.
Challenges of Device Recognition and Varying Screen Sizes
Marquis
As far as that goes, we are targeting screen size in terms of display in terms of the features in terms of what we are serving up to the user. So, really, there is no situation where we are saying 'OK, so, if they are on a Android then they get XYZ, if they are on an iPad, they get this that and the other thing.' Really, it is about if they have a device that sports touch then the specific touch feature and will specifically add Javascript. So, we are not serving it up to everybody but just those that have the feature enabled. We would never say that the iPad gets this layout. It is just any screen between one size and another size gets this layout.
Parker
We do not do any user-agent detection. That is a big no-no. So, it is very open ended. So, that is all focused on features and capabilities and we test for those and then dynamically load things in as needed. So, that is why each device gets a bit of a tailored experience in terms of what they download. This tablet here may support touch events and this one doesn't. It might have different resolution and might be getting a different layout.
Marquis
It is clear that we did not plan under any circumstances for anybody to be opening it on a GameBoy, but, when somebody did recently, it worked great on a GameBoy.
Parker
I think the great upside of this is taking a much more agnostic approach rather than targeting any specific user agents. It is all about targeting capabilities. That way when we are working with jQuery mobile, when we get new test devices (and we get new test devices all the time), as they come in and we crack it open and look it on some devices that hadn't been on our radar before and the Globe will look great on it because we don't have to worry about that. So, as devices come out it is a very future compatible approach and works on all the older devices because we are working on progressive enhancement. It will work on your Newtons and old Palms and things like that.
How Is This Possible Now As Opposed To the Recent Past?
Parker
I think it is one of those situations where a year and a half ago maybe this could have been done, it is just a matter of putting all the technical pieces together.
Marquis
I think some facets of this could have been done in the past. I mean, HTML5 has a lot more APIs available for targeting features. Like, being able to check for touch support is technically part of HTML5 even though it is not HTML5 markup. So, that definitely allows us to do all of that conditional loading and such. In terms of the markup itself, we are doing a lot of HTML5 with additional semantic meaning, it could have been done in HTML4, just not meaningfully in terms of the markup.
Parker
For us, we have been focused on universal access. That has kind of been our thing. We have been around for 10 years. I is not just us. I think a lot of people have slowly been putting pieces together and now I think we have the core tools we need to make this really feasible. For example, we wrote a book on progressive enhancement a little over a year ago. That is the foundation that the Globe is built on. To serve up clean semantic HTML and layer on top of that CSS and Javascript in a clean and unobtrusive way. Now we are making more distinctions. Instead of saying you are going to get this enhanced experience because we have more capabilities. Basically what we are saying is that based on your screen size, we are going to target the layout even further.
Marquis
I think my favorite example of that wou[…]
december 2011 by rahuldave
4chan's Chris Poole: Facebook & Google Are Doing It Wrong
december 2011 by rahuldave
Chris Poole delivered the most powerful 10 minutes of Web philosophy of the afternoon at Web 2.0. The man formerly known as moot - founder of anonymous image sharing den 4chan and its new, better-lit cousin, Canvas, gave us a rousing and principled picture of what the big players get wrong about online identity.
"Google and Facebook would have you believe that you're a mirror," he said, "but in fact, we're more like diamonds." - multi-faceted. It was an appeal reminiscent of the one he gave at SXSW earlier this year, but it hit harder. Google Plus has since arrived, and Poole says it's even worse than Facebook for the future of online identity.
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
Identity Is Prismatic
"The portrait of identity online is often painted in black and white," Poole said. "Who you are online is who you are offline." That rosy view of identity is complemented with a similarly oversimplified view of anonymity. People think of anonymity as dark and chaotic, Poole said.
But human identity doesn't work like that online or offline. We present ourselves differently in different contexts, and that's key to our creativity and self-expression. "It's not 'who you share with,' it's 'who you share as,'" Poole told us. "Identity is prismatic."
Choosing Our Own Identities
"We were on the right track at one point," Poole said. In the early days of the Web, its creators used their real names because they were the only people online. As the namespace got more crowded, people started using handles.
AOL Instant Messenger brought screen names to the mainstream. Poole said he agonized over his AOL handle, because he knew it would be a representation of him. That insight persists today at hacker conventions, where the real Web experts hang out. People there introduce themselves with their handles, because that's how they have chosen to identify.
"Twitter does the best job of this" of today's major social networks, Poole said. The platform itself uses handles and allows made-up answers in the real name field. Furthermore, "most of the apps allow multiple accounts. Facebook would never allow this, right?" He says Google Plus is the worst; you don't even get a vanity URL to distinguish yourself, and we all know how Google Plus handles pseudonyms: they delete the accounts.
Google & Facebook Are Eroding Our Options
Google and Facebook are "consolidating identity and making people seem more simple than they really are," Poole said. "Our options are being eroded."
Poole's bottom line is that there's a big market opportunity in this authentic, fluid kind of identity, which the big players are willfully abandoning. "You can incorporate identity without forcing your users to sacrifice something." Poole believes a Web network can validate an account using legitimate services without forcing the presentation of that user to be an over-simplification.
Creativity and self-expression are at stake, Poole says, and he's particularly concerned about young people. Facebook's new Timeline will lock people into their Facebook identities from birth.
Speaking at Facebook recently, Poole told its developers that they set the bar for identity, but he has since realized he was wrong: we, the users, do. "We're about to sacrifice something that's valuable, and it's special."
"I would ask us all to strive for this ideal when we design products, and as users on the Web, what we demand of services," Poole said. "Facebook and Google do identity wrong, Twitter does it better, and I want people to think about what the world would be like if we did it right."
Check out the Web 2.0 schedule and watch the events live here.
Discuss
2011_Redux
from google
"Google and Facebook would have you believe that you're a mirror," he said, "but in fact, we're more like diamonds." - multi-faceted. It was an appeal reminiscent of the one he gave at SXSW earlier this year, but it hit harder. Google Plus has since arrived, and Poole says it's even worse than Facebook for the future of online identity.
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
Identity Is Prismatic
"The portrait of identity online is often painted in black and white," Poole said. "Who you are online is who you are offline." That rosy view of identity is complemented with a similarly oversimplified view of anonymity. People think of anonymity as dark and chaotic, Poole said.
But human identity doesn't work like that online or offline. We present ourselves differently in different contexts, and that's key to our creativity and self-expression. "It's not 'who you share with,' it's 'who you share as,'" Poole told us. "Identity is prismatic."
Choosing Our Own Identities
"We were on the right track at one point," Poole said. In the early days of the Web, its creators used their real names because they were the only people online. As the namespace got more crowded, people started using handles.
AOL Instant Messenger brought screen names to the mainstream. Poole said he agonized over his AOL handle, because he knew it would be a representation of him. That insight persists today at hacker conventions, where the real Web experts hang out. People there introduce themselves with their handles, because that's how they have chosen to identify.
"Twitter does the best job of this" of today's major social networks, Poole said. The platform itself uses handles and allows made-up answers in the real name field. Furthermore, "most of the apps allow multiple accounts. Facebook would never allow this, right?" He says Google Plus is the worst; you don't even get a vanity URL to distinguish yourself, and we all know how Google Plus handles pseudonyms: they delete the accounts.
Google & Facebook Are Eroding Our Options
Google and Facebook are "consolidating identity and making people seem more simple than they really are," Poole said. "Our options are being eroded."
Poole's bottom line is that there's a big market opportunity in this authentic, fluid kind of identity, which the big players are willfully abandoning. "You can incorporate identity without forcing your users to sacrifice something." Poole believes a Web network can validate an account using legitimate services without forcing the presentation of that user to be an over-simplification.
Creativity and self-expression are at stake, Poole says, and he's particularly concerned about young people. Facebook's new Timeline will lock people into their Facebook identities from birth.
Speaking at Facebook recently, Poole told its developers that they set the bar for identity, but he has since realized he was wrong: we, the users, do. "We're about to sacrifice something that's valuable, and it's special."
"I would ask us all to strive for this ideal when we design products, and as users on the Web, what we demand of services," Poole said. "Facebook and Google do identity wrong, Twitter does it better, and I want people to think about what the world would be like if we did it right."
Check out the Web 2.0 schedule and watch the events live here.
Discuss
december 2011 by rahuldave
4chan's Chris Poole: Facebook & Google Are Doing It Wrong
december 2011 by rahuldave
Chris Poole delivered the most powerful 10 minutes of Web philosophy of the afternoon at Web 2.0. The man formerly known as moot - founder of anonymous image sharing den 4chan and its new, better-lit cousin, Canvas, gave us a rousing and principled picture of what the big players get wrong about online identity.
"Google and Facebook would have you believe that you're a mirror," he said, "but in fact, we're more like diamonds." - multi-faceted. It was an appeal reminiscent of the one he gave at SXSW earlier this year, but it hit harder. Google Plus has since arrived, and Poole says it's even worse than Facebook for the future of online identity.
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
Identity Is Prismatic
"The portrait of identity online is often painted in black and white," Poole said. "Who you are online is who you are offline." That rosy view of identity is complemented with a similarly oversimplified view of anonymity. People think of anonymity as dark and chaotic, Poole said.
But human identity doesn't work like that online or offline. We present ourselves differently in different contexts, and that's key to our creativity and self-expression. "It's not 'who you share with,' it's 'who you share as,'" Poole told us. "Identity is prismatic."
Choosing Our Own Identities
"We were on the right track at one point," Poole said. In the early days of the Web, its creators used their real names because they were the only people online. As the namespace got more crowded, people started using handles.
AOL Instant Messenger brought screen names to the mainstream. Poole said he agonized over his AOL handle, because he knew it would be a representation of him. That insight persists today at hacker conventions, where the real Web experts hang out. People there introduce themselves with their handles, because that's how they have chosen to identify.
"Twitter does the best job of this" of today's major social networks, Poole said. The platform itself uses handles and allows made-up answers in the real name field. Furthermore, "most of the apps allow multiple accounts. Facebook would never allow this, right?" He says Google Plus is the worst; you don't even get a vanity URL to distinguish yourself, and we all know how Google Plus handles pseudonyms: they delete the accounts.
Google & Facebook Are Eroding Our Options
Google and Facebook are "consolidating identity and making people seem more simple than they really are," Poole said. "Our options are being eroded."
Poole's bottom line is that there's a big market opportunity in this authentic, fluid kind of identity, which the big players are willfully abandoning. "You can incorporate identity without forcing your users to sacrifice something." Poole believes a Web network can validate an account using legitimate services without forcing the presentation of that user to be an over-simplification.
Creativity and self-expression are at stake, Poole says, and he's particularly concerned about young people. Facebook's new Timeline will lock people into their Facebook identities from birth.
Speaking at Facebook recently, Poole told its developers that they set the bar for identity, but he has since realized he was wrong: we, the users, do. "We're about to sacrifice something that's valuable, and it's special."
"I would ask us all to strive for this ideal when we design products, and as users on the Web, what we demand of services," Poole said. "Facebook and Google do identity wrong, Twitter does it better, and I want people to think about what the world would be like if we did it right."
Check out the Web 2.0 schedule and watch the events live here.
Discuss
2011_Redux
from google
"Google and Facebook would have you believe that you're a mirror," he said, "but in fact, we're more like diamonds." - multi-faceted. It was an appeal reminiscent of the one he gave at SXSW earlier this year, but it hit harder. Google Plus has since arrived, and Poole says it's even worse than Facebook for the future of online identity.
Sponsor
Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!
Identity Is Prismatic
"The portrait of identity online is often painted in black and white," Poole said. "Who you are online is who you are offline." That rosy view of identity is complemented with a similarly oversimplified view of anonymity. People think of anonymity as dark and chaotic, Poole said.
But human identity doesn't work like that online or offline. We present ourselves differently in different contexts, and that's key to our creativity and self-expression. "It's not 'who you share with,' it's 'who you share as,'" Poole told us. "Identity is prismatic."
Choosing Our Own Identities
"We were on the right track at one point," Poole said. In the early days of the Web, its creators used their real names because they were the only people online. As the namespace got more crowded, people started using handles.
AOL Instant Messenger brought screen names to the mainstream. Poole said he agonized over his AOL handle, because he knew it would be a representation of him. That insight persists today at hacker conventions, where the real Web experts hang out. People there introduce themselves with their handles, because that's how they have chosen to identify.
"Twitter does the best job of this" of today's major social networks, Poole said. The platform itself uses handles and allows made-up answers in the real name field. Furthermore, "most of the apps allow multiple accounts. Facebook would never allow this, right?" He says Google Plus is the worst; you don't even get a vanity URL to distinguish yourself, and we all know how Google Plus handles pseudonyms: they delete the accounts.
Google & Facebook Are Eroding Our Options
Google and Facebook are "consolidating identity and making people seem more simple than they really are," Poole said. "Our options are being eroded."
Poole's bottom line is that there's a big market opportunity in this authentic, fluid kind of identity, which the big players are willfully abandoning. "You can incorporate identity without forcing your users to sacrifice something." Poole believes a Web network can validate an account using legitimate services without forcing the presentation of that user to be an over-simplification.
Creativity and self-expression are at stake, Poole says, and he's particularly concerned about young people. Facebook's new Timeline will lock people into their Facebook identities from birth.
Speaking at Facebook recently, Poole told its developers that they set the bar for identity, but he has since realized he was wrong: we, the users, do. "We're about to sacrifice something that's valuable, and it's special."
"I would ask us all to strive for this ideal when we design products, and as users on the Web, what we demand of services," Poole said. "Facebook and Google do identity wrong, Twitter does it better, and I want people to think about what the world would be like if we did it right."
Check out the Web 2.0 schedule and watch the events live here.
Discuss
december 2011 by rahuldave