FaceBook Beacon is an interesting idea but the choice of opt-out instead of opt-in is a poor one by FaceBook. MoveOn is dead right to be causing a stir over this. At the end of the day all MoveOn wants is that Beacon becomes an opt-in system.
The goal is to produce a full gigawatt of power from renewable sources, cheaper than coal
Google launches a renewable energy initiative.
It is sad that Google has to defend this move as “not straying from core values” because “it needs power.” Here is a company with the money and the creative leadership willing to tackle one of the world’s greatest problems but has to, in the same breath, defend itself with a “level headed business case” to, inevitably, its stock holders.
Folks. They want to solve the energy problem. They have a good shot at doing it. Get behind them and make it happen.
I liked TechCrunch when you got an unbiased yet still opinionated view of new start-ups on the web. Back when it was just fiery Arrington and a passion for new, interesting ideas. Sadly it has become a victim of its own success with increasing irrelevance, bias and low quality, even by blog standards, writing. This latest post on Why Digg Is Still The Best pushed TechCrunch out of my Purgatory category and into the dead pool.
Unsubscribed.
TechCrunch is having another fit over PayPerPost/IZEA.
Advertising influences your content. You tend to write more on what brings in traffic that will hopefully click on your contextual ads. You end up writing in a way that promotes certain keywords, title styles, lead paragraph structure, when and who you link to etc.
I would think it is painfully clear that there is not a big difference between what TechCrunch and many other blogs do with AdSense and other contextual advertising and what other bloggers do with PayPerPost. PayPerPost pay you directly for writing for their advertisers while AdSense and co. pay you indirectly for writing about their advertisers.
This is why some key bloggers do not put advertising on their blogs even though it would make them some serious money. They realise that their content will be influenced by the inevitable tug of monetisation through advertising.
I’m not against advertising. I just hope that every blogger, including TechCrunch, realises the deal they are making when they first put advertising on their blog.
We shouldn’t be shocked that “viral” videos are often the creation of professional and determined marketers. The media we webbies so often criticise must be having the last laugh as their crafted videos go “viral” on our seemingly “user generated” sites. Reading Dan Ackerman Greenberg’s post on TechCrunch is sickening yet fascinating. The ways we are manipulated by our own systems. Dan calls it entertainment, most of us would call it abuse of trust.
If you are looking to get your brand out there at any ethical cost and make a fast buck at the expense of many then Dan is your man. If you care for the long term value of the web though you will work with the system.
I love being a geek. One can spend a pleasurable hour or ten looking into the difference between URI and URL. Even though I consider myself a web-developer I ashamedly admit to not knowing the difference between URI and URL. I see them used interchangeably and have left it at that for many years.
Then Ajaxian went and linked to the difference between URI and URL by Ryan McDonough. I read it and thought it made some sense and was even quite useful. The whole representation vs. identifier finally made sense.
However someone posted a comment discrediting the post and a it sparked my geek instinct. It turns out URI and URL is a well discussed topic in many internet circles with a lot of confusing RFCs, W3C specs. and conflicting forum and blog posts.
This forum discussion however seems to clear it up for me. It comes down to identifiers and locators.
isbn:1857988132 is an URI. It identifies a resource. It however does not locate it. http://www.alibris.com/books/isbn/1857988132 is an URL as it both identifies and locates a resource. An URL is a subset of URI though so, as hierarchies work, it is a URI too.
mailto:joe@soap.com is an URL and an URI.
tag:yaml.org,2002:int is an URI but not an URL as it only identifies and does not locate.
You can get a list of URI schemes (the bit in the beginning e.g. http, mailto, ftp, isbn, pop, imap etc.) that is quite fascinating.
Sadly I am still confused as to whether URL has been formally deprecated to make things simpler to understand. Some sources say it has been while others say it hasn’t. Colloquially URL will remain for a long time but technically many are saying it is deprecated.
You might still be wondering why I love being a geek. I love it because with the information I just unearthed I can better understand a complex yet robust system through its rational rules and go on to build an application that does amazing things. Things like the world wide web.
Whenever I read about someone proposing to add a dozen or more new elements to RSS I ask myself; why not use or propose a MicroFormat instead? It requires less tooling, fragile aggregators won’t choke on it, developers can innovate quicker without waiting for extensive RSS spec. changes, and humans get the benefit straight away without having to wait for systems that may or may not take advantage of the new data.
I’ve always seen RSS as a list mechanism with each item having a payload. RSS shouldn’t be entangled in what it is carrying. That payload is not defined by RSS and you don’t need approval from the RSS board to put a MicroFormat into your RSS item.
Finally, using a MicroFormat makes it very simple to inject the same data and structure into other formats e.g. HTML documents.
I’ve spent the past few hours going over OpenSocial again. It is very rough at the moment and calling it even a beta is a stretch. Getting anything to work by reading the OpenSocial docs is fruitless. I asked for an Orkut sandbox login hours ago and haven’t heard anything back yet.
So I then tried Plaxo’s OpenSocial container but any Gadget URL I entered was rejected as unapproved. Guys, please include some sample URLs that work.
I dithered about for another hour until I stumbled across the easiest way to see your first OpenSocial Gadget working. Go to Ning, create a Social Network, drag the Gadgets module into your Main Page, save and then go to your Main Page. You can then click the Gadget Directory link and select from a few Gadgets. They are very basic Gadgets, anything on Netvibes/PageFlakes/etc. is far more developed at this stage. The Last.FM gadget couldn’t even pick up my username from Ning and link in my Last.FM profile, I had to type it in manually. Doesn’t that defeat the point?
Anyway, that is the easiest way to see OpenSocial running. If you want to see a list of OpenSocial Gadgets available on Ning check out opensocial.ning.com. You can’t do anything with them though if you don’t have a Ning Social Network with a Gadget container.
The potential is there but right now don’t expect to be impressed or even mildly entertained.
The People Data API of OpenSocial though is the most interesting aspect. Unfortunately it is not released yet, just some half-completed docs on Google. But never say web developers require released software to do something. Voidstar over at Ecademy has implemented some of People Data API. Check out a feed of a person and his friends list. Some serious data in there. No security or authentication yet though. Voidstar is going on the principal of some FOAF using sites which is “if it can be seen in public HTML it can be seen in an API” which is fair enough. My question for People Data API is how many sites are going to implement it in an open enough way to be actually useful? Allowing Gadgets to run on your site is easily allowable but allowing all your social data to be opened up to anyone on the web? Many a business person won’t like that idea (even though they are wrong and should stop fighting the internet.)
I didn’t bother with the Activities Data API which also is not released.
So there you go, OpenSocial in action. Sort of. Lots of potential, lots of bits I really don’t like, no real authentication model (”implementation details” according to Google) or security model (an inline OpenSocial Gadget can take any data off the surrounding page and send it to any site it likes), no real use yet, no useful Gadgets yet, just one open OpenSocial container.
This is one of those things that is likely going to be big whether you like it or not. So you probably need to be aware of it and how you can take advantage of it in the short term (the web will outlast OpenSocial by a long, long way) and also how you can use it now but not be tied into it in the long term.
Second last comment:
Finally, although Open Social provides standard API calls to do many of the things you’ll want to do as an Open Social app, nothing will prevent containers from implementing additional Javascript or web services APIs to provide additional functionality to developers. Open Social app developers can therefore choose to stay “onroad” and have their apps run in any Open Social container, or go “offroad” for one or more specific containers to do special things. Open Social standardizes common functionality but doesn’t prohibit innovation.
That is from Marc Andreessen, a fairly smart chap. What he describes there about going “off-road” is the worst possible thing that can happen to OpenSocial. It ruins the user experience. It ruins the developer experience. When OpenSocial says a Gadget will run in any OpenSocial container and then it doesn’t users and developers are going to get frustrated. We see it in mobile development where you develop for Symbian and get a different experience on different Symbian phones. It doesn’t prohibit innovation but it limits use. It dumbs down applications to the point that they become trinkets, collected by many, used by few.
We may just end up with a proliferation of OpenSocial ME, OpenSocial LITE, OpenSocial Standard, OpenSocial Enhanced and OpenSocial Telco.
Actually, what we will end up with is the world wide web as we already have it. We will have just wasted years trying to get it working in OpenSocial.
My last comment is that “social” is not the be all and end all of life. I dare say it is distracting us from true knowledge creation. You spend your time tweaking your social network when you might rather be inventing a cure for cancer. A lot of our greatest advances have not been social. Yes they involved people but the leap forward was we rotate around the sun, time is relative, generation and movement of electrons, mass production, customisation, genes, clean water, radiation etc.
By calling it OpenSocial and focusing on social we run the risk of building a massive layer of social tale chasing. Hi friend, hi friend, hi friend… Oh, hello friend. I just ate lunch. Hi friend.
Hey, friend, what happened to the water supply?
The web is a lot more than a social network.
Oh dear. This iLike OpenSocial Gadget running on Ning thinks I like 50 Cent, Avril Lavigne, Justin Timberlake, Sean Kingston and Fergie.
I think you’ll find that if you visit my Last.FM account you won’t find any of those artists and a rather different mix.
Lets hope OpenSocial gets more successful and useful Gadgets over time. So far I haven’t seen a single working one that is any better because it has a connection to my social data.
In the long term vision, thinking in terms of the graph rather than the web is critical to us making best use of the mobile web, the zoo of wildy differing devices which will give us access to the system. Then, when I book a flight it is the flight that interests me. Not the flight page on the travel site, or the flight page on the airline site, but the URI (issued by the airlines) of the flight itself. That’s what I will bookmark. And whichever device I use to look up the bookmark, phone or office wall, it will access a situation-appropriate view of an integration of everything I know about that flight from different sources. The task of booking and taking the flight will involve many interactions. And all throughout them, that task and the flight will be primary things in my awareness, the websites involved will be secondary things, and the network and the devices tertiary.
Tim Berners-Lee on, believe it or not, social networking (more specifically the graph that represents your social network.)
Stuff like that blows my mind. How we can create a link to a flight or friend or product or meme and then run web-scale processes against it. It also makes me think that web-apps as we are currently building them are poorly thought through.
We wrap the items in the catalogue which is wrapped in the store. The items shouldn’t be wrapped, they are outside of the store. They can be used by the store application but they aren’t owned or walled by it. Same with social networks and people. You aren’t my Facebook friend. You are my friend and Facebook is just one application that knows about our relationship. It doesn’t own the relationship.