#jon udell

[stephenfrancoeur]

Jon Udell, "Hands on: Slack gets a real-world teamwork test," InfoWorld

Newly arrived, Slack is already changing the way our workgroup collaborates, but the provisions for integration with other apps need help

Pull quote: “ It's great that Slack, IFTTT, and Zapier offer long lists of point-to-point integrations. But simply because I can make something out of a feed doesn't mean I should have to. Of course, most users can't or won't. But those lists can't grow infinitely long. There needs to be a general-purpose fallback. In theory that's still RSS/Atom feeds. In practice I find, too often, it isn't.”

[stephenfrancoeur]

Pull quote: "Libraries really are about bits. They are uniquely positioned to adopt and promote digital literacies. Why don’t they? Those literacies aren’t yet being marketed as effectively as 3D printing."

[parochialaesthetics]

Consider how my own inputs have evolved over the past five years. At one time, my RSS intake was mostly feeds from conventional published sources, along with a few from individuals. Now it’s the reverse. I subscribe to people more than to publications, and not because I don’t value the information in those publications -- I do, very much -- but rather because, outside of the realms in which I’m closely involved, I can delegate the job of tracking primary sources to people whose interests and inclinations qualify them to do so. The blog network is made of people. We are the nodes, actively filtering and retransmitting knowledge. Clearly this architecture can help manage the glut of information. More subtly, it can also help ensure that no vital inputs are suppressed because nobody has to rely on a single source. If one of the feeds I monitor doesn’t react to some event in a given domain, another probably will. When they all react, I know it was an especially important event.

The network is the blog | Developer World - InfoWorld

[stephenfrancoeur]

Pull quote: "I want things to work differently. I want to manage my affairs by syndicating, tagging, and republishing data feeds. Now I grant you that's a tall order. It presents all sorts of technical challenges. But trust me, those are solvable, I don't worry about that. I worry more about the human challenge. We won't get the right kinds of solutions unless customers demand them. I want to raise expectations about what's possible so that people will demand them, and I want to teach people how to be web thinkers so they'll demand the right kind of solutions."

[stephenfrancoeur]

Pull quote: "When you’re evaluating a cloud-based application or service, as you will often be doing from now on, ask whether its developer has prepared it to work with other applications and services in the cloud. That might mean a formal API. Or support for the relevant Internet data-exchange standard. Or a data import/export feature. Or sensibly-designed URL patterns. Or all of these things. Please ask. If you don’t, you may someday realize you bought the wrong kind of software. And in a world that’s increasingly connected, or anyway should be, we will all suffer the consequences."

[borismann]

I want to use the humble example of a church supper — recorded in Google Calendar or Hotmail Calendar, published on a website, and syndicated to other sites — to illustrate a general idea about personal (and organizational) clouds. They can, or anyway should, be active participants in an ecosystem of data exchange that puts everybody in control of their own information and requires nobody to copy and paste it elsewhere.

Jon Udell is doing excellent work, trying to break the conceptual (not technical) barrier that people have about sharing data.

This is what I'm trying to help support with the VanCal project, too. Except I need to look into the underlying Calagator code to see if it is actually properly subscribed to sources.

[stephenfrancoeur]

Pull quote: "The notion that the URL points to a data feed is another major conceptual hurdle. If you need something from me, a million years of evolution taught us how that must work. I hand it over to you. If I also need the thing that you need, then I make a copy, hand over the copy, and keep the original. When the thing in question is a chunk of information we reify it as an exchangeable object: a piece of paper, an e-mail attachment. That’s the physics of the real world. In the virtual realm, though, different laws of physics apply. I can simply refer to the thing you need. I hand you the reference instead of the thing, I still have the thing, you have it too, and we only need to do that transaction once. Thereafter when I change the thing, you have my changes too, no need for me to send another fax or e-mail attachment. The principles at work here — indirection, linking, automatic data exchange — are inherent to cloud-based systems. Computer programmers and information scientists realize that, but it’s still far from obvious to most other people."

[stephenfrancoeur]

Pull quote: "If you drill all the way down to an individual item of data, though, you’ll get the same result either way. Lindsay Shonteff’s name, for example, has 'its own homepage' in Netflix’s web of data. Here is its URL: http://odata.netflix.com/Catalog/People(85334)/Name/$value In this case the mechanism for 'automatically providing a hypertext view' of the Netflix catalog is the Open Data Protocol (OData). It’s one way, and I think a very good way, to make The Web is the API a true statement. Since OData is a Microsoft invention, and I work for Microsoft, you are entitled to be skeptical. But if you’ve followed my work and interests for the past 20 years you’ll know that OData is the sort of technology I’ve always championed: fundamental, non-proprietary, game-changing."