tech support 8

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg
Showing posts with label RSS. Show all posts
Showing posts with label RSS. Show all posts

Monday, 8 July 2013

Backing Up Your Social Media

Posted on 13:08 by Unknown


Social media icons
Social media outlets are practically a dime a dozen. Excluding ones that are pretty stable right now (Twitter, Facebook, etc.), most of them will either fail or get bought. The problem is that your data, your content, typically dies when they do.




As an individual you might not care too much if one of the niche services fails. As a business who relies on social media, however, you should care.




Every post to Twitter or Facebook or Blogger or (insert whatever services you use here) represents effort spent to promote your brand. That effort is probably from paid staff (because nobody lets interns have the keys to their global brand, right?) and represents some cost as a result. Cultivated Facebook campaigns, Twitter conversations, Pinterest boards, all represent a combination of your effort and community participation.




When a service goes away, so does the money and effort you spent to cultivate it. So does the community feedback that demonstrates to others that yours is a good brand. So does any SEO benefit it may be giving you. So does the content you created.




I regularly ask social media practitioners how they back up all the data they post to these services and it almost always results in blank stares.




Most organizations make some effort to back up their marketing or sales materials, in addition to their intellectual property, but for some reason social media is left out in the cold.




I'll cover some examples of what I have done and do, along with some tips on how you can plan for your own back-up.



Twitter




Twitter allows you to produce an archive of all your tweets whenever you request it. What you will get is a link to download a ZIP archive which contains a completely stand-alone web site that allows you to see all your tweets. You can use this site right from your computer with no internet connection.




I suggest taking it one step further and creating a folder on your public web site so you and all your team (and even the general public if you want to share the address) can access all of your tweets at any time from any where. This method will also allow you to search all your tweets instead of being limited by Twitter's own date restrictions on searches. For example, I have my Twitter archive at AdrianRoselli.com/Tweets.




Tweets in the archive contain the full content of the original tweet, but do not contain any of the replies to, favorites of, or re-tweets of your tweets. They do, however, link you directly to the tweet at Twitter.com so you can get all that information.




As part of your job as a social media manager I recommend you set up a calendar reminder for the first of each month (or whenever works for you) to download and store your Twitter archive.



Facebook




Facebook also allows you to create an archive of everything you have posted, including photos, videos, wall posts, messages and chat conversations along with the names of your Facebook friends. It does not include comments you've left on the posts of others. An expanded archive option also provides historic information such as your IP addresses for when you have logged into Facebook.




As such, I recommend against posting your entire Facebook archive to your web site as it will probably contain information that you have opted to not share with the general public (especially since it can also contain other people's private information).




I should note that I am talking about a personal profile here, not a business profile. So far I have been unable to find information on how to archive a business/organization profile. Suggestions are welcome.




[Your Blog Here]





Quite a lot of social media involves maintaining a blog. This blog may exist on any one of many platforms, including one you've built yourself. For this example, I am talking about a blog that you host elsewhere, probably for free, such as an option from Wordpress or Blogger, among others.




In an ideal scenario you will have secured a blog sub-domain, such as blog.adrianroselli.com. This is the first step to having some portability and control should your blogging platform go away. It won't be so easy to get adrianroselli.blogger.com if Blogger goes away, mostly because I don't own (and likely would be unable to purchase) the domain blogger.com.




If your blog platform does go away and you have some advance notice, you have some options to get your content before it is lost. Some platforms will offer you a way to get all your content out and other platforms may offer you a way to import that content. If your failing platform doesn't offer an archive, you can always spider the content using a tool like HTTrack.




Ideally you'll want to recreate your content on your new blogging platform, so make sure you also recreate the same page addresses (most of the blogging tools allow you to create a custom page address, though it will be a manual process). In this scenario, any inbound links won't be broken. For those cases where you cannot replicate the page addresses, explore options to create custom redirections with your new blog provider or, if it's on your own server, through server-level mappings.



Pinterest, Tumblr, Instagram, and Other Services




I have used many services over the years, in particular services targeted at image sharing. I have used Brightkite, Plyce, Picplz, Posterous and am now on to Tumblr. With the exception of Tumblr (so far), they have all gone away. I haven't lost my images, however. In the case of Brightkite they made everything available for download for quite some time and in a structured format. Picplz offered the same, but not until many users raised a stink and followed its founder to his next gig to push their point. Posterous made its site available as a static HTML archive.




Had these sites not made the content available, however, I still had a plan to get everything out. I simply spidered my profile page for each site using a tool (HTTrack again) that converts it all to static HTML. In short, I captured every page and every image to a format that I could simply post on my own site or view on my local computer (as I did with Picplz and Posterous). While I cannot replicate the old addresses (similar to the case with a blog domain), I can at least make my content available should I want to reference it again.




When Pinterest or Instagram or Tumblr or insert-service-here announces it is going away, I will simply fire up the same tool and begin my archive process. Each service may very well offer a tool to do this, but I'd rather make sure I have it just in case they don't. In addition, sometimes it's more work to process a stack of JSON files than it is to simply spider the site and post it somewhere on your own site.



Related Bits




  • Startups should bend over backwards to let users take their data after they shut down [Updated], June 3, 2012 at The Next Web.

  • Proposed Standards for the Care and Feeding of User Generated Content, June 25, 2012 at Zeldman.com

  • You Get What You Pay For, December 17, 2010 by me.



Too lazy to read Terms of Service. Just going to upload videos to Vine & Instagram at the same time and let them fight about who owns them.

— Adrian Roselli (@aardrian) June 20, 2013


Read More
Posted in Brightkite, Facebook, picplz, rant, RSS, social media, Twitter | No comments

Thursday, 28 July 2011

Don't Let HTML5 Become the New DHTML

Posted on 11:29 by Unknown

Beers with non-HTML5 technologies imprinted on them.
This photo represents some of the technologies (pint glasses) that HTML5 (t-shirt) is thought to encompass (drink). The horror of that concept is represented by the hands (defensive wounds coming).

I had the pleasure of sharing some pints with Bruce Lawson and Chris Mills last week in London. While discussing what bands are emo versus punk rock and during an exchange of favorite phrases to refer to the chronically daft, we touched on HTML5 and its perceptions a bit.

This thought process was rekindled just this week when I got in a discussion with a not-very-technical manager of web projects who insisted on mobile support and decidedly CSS3-based styling by implementing HTML5. The key here is the insistence on using HTML5. For a little context, we use HTML 4.01 Transitional for our projects. It's a valid and complete specification. It allows us to use things like WOFF, CSS3, AJAX, support mobile devices and so on.

I understand that many have co-opted "HTML5" as a brand for a suite of new technologies (most of them even from the W3C or WHATWG). I do not accept that, however, because it confuses the point when it comes time to make choices about technologies. This is a battle I have already fought repeatedly back when DHTML (and IE4!) became the rage and I had clients asking what technologies I would use to build their pages — insisting in advance that it be DHTML. I could explain that DHTML was just a terrible term coined to mean HTML4, CSS and JavaScript, but clients didn't care. It didn't matter to them. Good for them.

For developers and the people that manage them, including those who write on these topics, I have a different expectation than I have from clients. Allowing HTML5 to mean CSS3, geolocation, H.264, or any other technology just makes it harder on us who work in this space. A technology for a project should be chosen based on the goals at hand, not because a client insists on it because of a misunderstanding of a brand or because the press release will sound great when citing how cutting edge everyone is. Most importantly, a technology should not be chosen because of confusion over terminology — least of all when that term actually refers to one particular specification.

Please, fellow developer/writer/manager, make an effort to understand the technologies you reference so you do not confuse other developers/writers/managers, set incorrect expectations with clients, or generally demonstrate that you do not get it (especially if you want to work for me).

I have written on this extensively (with many links in each article that are to further details not written by me):

  • W3C Clarifies HTML5 Logo Is for HTML Only

  • HTML5 Finally Gets... a Logo?

  • Google, Arcade Fire Confused on HTML5

  • Google Doodle: Bouncy Balls Aren't HTML5

  • HTML5 and CSS3 Confusion

If you are a writer (whether a journalist, blogger or analyst) then please take a few moments to read this useful and informational post: HTML5: notes for analysts and journalists (also not written by me). There will be a quiz. I don't know when, but there will be a quiz.

Now, to reveal how Bruce and Chris really felt about the HTML5 confusion:

Beers with non-HTML5 technologies imprinted on them. And Bruce Lawson and Chris Mills looking horrified and sheepish, respectively

Here are posts from both Bruce and Chris discussing this confusion, within the context of the new HTML5 logo muddying the point earlier this year:

  • On the HTML5 logo, by Bruce Lawson on January 18, 2011.

  • HTML5 logo: be proud, but don’t muddy the waters!, by Chris Mills on January 18, 2011.

Read More
Posted in css, Flash, fonts, html, JavaScript, mobile, rant, RSS, standards, SVG, video, W3C, whatwg, WOFF | No comments

Monday, 30 May 2011

Is RSS at Risk?

Posted on 08:59 by Unknown


RSS logo with bullet holes.
I spent about a thousand words explaining RSS before I realized that, for the most part, if you are reading this blog I have to guess you have some familiarity with it (at least by just having heard of it). If you need some background, Wikipedia has a pretty good overview on RSS.




If you are a web site developer or author, there are three methods to get your Twitter feed or your Facebook business page information integrated into your site: via some sort of JavaScript-driven widget, via an API that is unique to each, or via RSS. This isn't limited to just Twitter and Facebook. PicPlz, Foursquare, and others provide these methods as well.




A JavaScript widget (whether via an embedded iframe or not) typically does not integrate well with a site, forcing the branding of the service, its color scheme, and its styles. For many sites, a Facebook widget or Twitter widget can look very out of place, almost like an afterthought. On top of this, because these widgets rely on JavaScript so heavily there is no alternative for those without JavaScript support (whether by choice, by restrictions, or by errors elsewhere on the page — see my post Beyond Hash-Bangs: Reliance on JavaScript Is a Bad Idea)




The API approach gets around styling issues, but often each API has its own proprietary offerings and syntax, requiring you as the developer to learn it, integrate it with your own platform, and spend time maintaining it as the API changes (possibly on a whim). While using this method you have control over how the data is styled on your site, relying on a free service means that you will have less input and recourse should a feature suddenly change (as I say, free doesn't mean good: You Get What You Pay For). Many APIs are reliant on JSON solutions as well, requiring JavaScript to perform the calls, and therefore the rendering, unless you are processing all of the features server-side.




The third method I mention, and the point of this post, is RSS. Because RSS has a standardized XML structure behind it (spread across parallel but unique versions, not counting variants like ATOM), as a developer you always know what to expect from an RSS feed. A JavaScript developer can just as easily parse the XML structure as a server-side coder. Once you have built a function to parse and display an RSS feed from one source, you can re-use it for any other RSS feed, forking it if you want to present the data in a different way on your site. This means you have complete control over the presentation (HTML, CSS and code structure).




In addition, most blog platforms (I'd say all, but someone might surprise me with one I don't know) not only provide RSS feeds of their data (and can even rely on a service like FeedBurner to provide additional RSS versions), they also support RSS import. This little feature means that if you provide content from your site as an RSS feed, any blogger can integrate it into his or her blog with only a few clicks.




An example of just how robust RSS can be is demonstrated with podcasts (and even vodcasts). The structure of a podcast file is really just an RSS feed with attachments, much like you might attach a file to an email. A regular RSS reader should be able to process the file, even if it cannot play the music. A podcast reader should, conversely, be able to read a standard RSS feed, even if there is no music to play.




Another powerful adaption is GeoRSS, which allows geographic data to be embedded in a feed. Syndicated content can be associated with locations on a map, something which has proven to be useful to the rise of location-based social media. For example, you can get your Foursquare history as an RSS feed, with each location tagged with geolocation data. In fact, a precursor to Foursquare, Brightkite, allowed users to generate custom RSS feeds to track specific spans of time, locations, groups of users, and even control how many items to display. When it came time for Brightkite to shutter its location-based services, it made all user data available to its users via RSS feeds.




Because of these reasons I have typically ignored hype expressing that RSS is on its way out. And then I stumbled across the post Twitter and Facebook Both Quietly Kill RSS, Completely, which was followed up a couple weeks later with Facebook Listens. RSS Added Back to Pages. Will Twitter be next?




This reminded me of an exchange I had on the Picplz API mailing list, where I asked if they would update the RSS they provided with geolocation data (since most photos are associated with a venue pulled from Foursquare). I was told that the RSS pre-dates the API and essentially that there aren't any changes in the pipe.




In just the last few days I have been struggling with the new MapQuest, trying to figure out how to embed GeoRSS in the new platform. In addition, I noticed that my "classic" MapQuest maps were no longer showing the embedded GeoRSS. After going through the support forum I found that GeoRSS is not (yet) supported in the new MapQuest, and nobody had noticed that it appears to be broken on the classic MapQuest (the solution they told me I should use for now).




So now I find myself wondering about the future of RSS. When Google Chrome doesn't even show an RSS icon or format it for display, when a new location-based service isn't adding the GeoRSS features, when a major mapping service doesn't support GeoRSS in its latest release, when Twitter buries the link for RSS, and when Facebook toys with its removal, I am concerned that they are contributing to the eventual demise of RSS.




I understand that content drivers (Twitter and Facebook) who survive on advertising revenues want to drive their brand and, ideally, their advertising to end users. Widgets that include a brand and drive people back to the advertising on the parent site make sense. For services and platforms (Picplz and MapQuest), pushing developers to a proprietary API increases the developers' investment in your platform, making it less likely for them to peel off when they can't simply apply their code to the next shiny new thing.




Unfortunately, these all combine to make the barrier to content syndication higher for everyone. While we can still wield an RSS parser to syndicate much of this content (often the one built into a blog, but typically a module within a CMS or other platform), it may be a matter of time before we lose the freedom to rapidly and repeatedly re-use a tool already in our belt. It may also be a matter of time before we as developers forget we should always build an RSS feed when we are instead enamored with the ability to claim our product or service has an API — even if it's not offering any more than an RSS feed can offer.




As developers we need to make sure we are helping our users, future developers, and ultimately our clients, by leveraging standardized tools. When it comes to content syndication and generally sharing data, RSS is the common denominator and typically worthy of implementation as the first step in a solution. If we aren't continuing to use it and expect it, the walled gardens and self-congratulatory APIs will catch up to us.





Related




  • Rest in Peace, RSS, May 5, 2009.

  • No, RSS Is Not Dead, and Neither Are RSS Readers, September 13, 2010.

  • How to reboot RSS, September 13, 2010

  • XML vs the Web, November 24, 2010.

  • RSS Is Dying, and You Should Be Very Worried, January 3, 2011.

  • Sure, RSS Is Dead — Just Like the Web Is Dead, January 4, 2011.

  • What I mean by "the open web", January 04, 2011

  • Why Big Media Wants to Kill RSS, and Why We Shouldn’t Let It, January 4, 2011.

  • Blogging Forefather Seeks to Re-Invent Blogging, Again, January 5, 2011

  • RSS: A Reply, January 14, 2011.

  • Twitter and Facebook Both Quietly Kill RSS, Completely, May 8, 2011.

  • Facebook Listens. RSS Added Back to Pages. Will Twitter be next? May 21, 2011.

Read More
Posted in geolocation, Mapquest, rant, RSS, social media, standards | No comments
Older Posts Home
Subscribe to: Posts (Atom)

Popular Posts

  • New Google Analytics Features
    In the article " Google Analytics Now More Powerful, Flexible and Intelligent " from last Tuesday (yes, I know I'm behind on t...
  • Speaking: Accessible Web Apps & Standards
    I will be speaking twice in September, both of them sponsored by Infotech Niagara. If you're in the Buffalo area, these are great opport...
  • HTML5 Finally Gets... a Logo?
    Start Rant With all the debate about elements , attributes , semantic meaning and who really owns HTML5 , it's thrilling to see that t...
  • Speaking at WordCamp Buffalo 2013
    This Saturday I will be speaking at Buffalo's second WordCamp . Last year was a great day-long event filled with many good speakers (not...
  • Current CSS3, HTML5 Support
    The Tool Last week saw the launch of FindMeByIp.com , a very handy web site that displays a user's current IP address (along with a geog...
  • Copying Content Styled with Text-Transform
    Using the CSS property text-transform to automatically shift copy to uppercase has been popular for a while now, but a combination of a rec...
  • Come See Me: October 6
    I will be one of the panelists at the Business First Power Breakfast: Online Networks , this coming Tuesday, October 6, 2009 at 7:30am at S...
  • Accessibility Bookmarklets and Tools
    Testing accessibility on your web projects can be a tricky task if you have no firsthand experience with visual, audible, physical or even c...
  • Brightkite Yields to Foursquare, Gowalla, Etc.
    Brighkite has made an announcement today that affects me and a handful of other people (not counting all the people on Facebook whose timel...
  • Social Media Day 2011 in Buffalo #smdayBUF
    Last night marked the second Mashable-sponsored Social Media Day here in Buffalo. With 154 RSVPs for the event, the venue, The Eights Bist...

Categories

  • accessibility
  • Adobe
  • analytics
  • Apple
  • apps
  • ARIA
  • Bing
  • Blink
  • Brightkite
  • browser
  • Buzz
  • Chrome
  • clients
  • css
  • design
  • Facebook
  • Firefox
  • Flash
  • fonts
  • food
  • Foursquare
  • g11n
  • geolocation
  • globalization
  • Google
  • Gowalla
  • html
  • i18n
  • ICANN
  • infographic
  • Instagram
  • internationalization
  • internet
  • Internet Explorer
  • JavaScript
  • JAWS
  • Klout
  • L10n
  • law
  • localization
  • Lynx
  • Mapquest
  • Microsoft
  • mobile
  • Netscape
  • ning
  • Opera
  • patents
  • picplz
  • Plus
  • print
  • privacy
  • project management
  • QR
  • rant
  • RSS
  • Safari
  • SCVNGR
  • search
  • SEM
  • SEO
  • social media
  • Sony
  • speaking
  • standards
  • SVG
  • touch
  • translation
  • Twitter
  • typefaces
  • usability
  • UX
  • Verizon
  • video
  • W3C
  • WAI
  • WCAG
  • WebKit
  • whatwg
  • Wired
  • WOFF
  • xhtml
  • Yahoo
  • YouTube

Blog Archive

  • ▼  2013 (39)
    • ▼  December (1)
      • Web Development Advent Calendars for 2013
    • ►  November (7)
    • ►  September (4)
    • ►  July (3)
    • ►  June (2)
    • ►  May (5)
    • ►  April (3)
    • ►  March (6)
    • ►  February (2)
    • ►  January (6)
  • ►  2012 (63)
    • ►  December (2)
    • ►  November (4)
    • ►  October (5)
    • ►  September (5)
    • ►  August (4)
    • ►  July (6)
    • ►  June (7)
    • ►  May (7)
    • ►  April (8)
    • ►  March (5)
    • ►  February (3)
    • ►  January (7)
  • ►  2011 (67)
    • ►  December (5)
    • ►  November (7)
    • ►  October (5)
    • ►  September (4)
    • ►  August (8)
    • ►  July (3)
    • ►  June (8)
    • ►  May (3)
    • ►  April (1)
    • ►  March (6)
    • ►  February (6)
    • ►  January (11)
  • ►  2010 (100)
    • ►  December (8)
    • ►  November (7)
    • ►  October (5)
    • ►  September (10)
    • ►  August (7)
    • ►  July (11)
    • ►  June (12)
    • ►  May (6)
    • ►  April (8)
    • ►  March (10)
    • ►  February (5)
    • ►  January (11)
  • ►  2009 (51)
    • ►  December (9)
    • ►  November (6)
    • ►  October (21)
    • ►  September (13)
    • ►  August (2)
  • ►  2003 (3)
    • ►  October (1)
    • ►  January (2)
  • ►  2002 (9)
    • ►  December (1)
    • ►  June (3)
    • ►  April (1)
    • ►  March (3)
    • ►  January (1)
  • ►  2001 (1)
    • ►  February (1)
  • ►  2000 (4)
    • ►  October (1)
    • ►  July (1)
    • ►  June (1)
    • ►  January (1)
  • ►  1999 (7)
    • ►  November (1)
    • ►  September (2)
    • ►  August (2)
    • ►  July (1)
    • ►  June (1)
Powered by Blogger.

About Me

Unknown
View my complete profile