The Rhapsody Web Services blog has a interesting writeup of using Grazr with the Rhapsody OPML files for their music listings. They also point to a great Grazr mashup app by Jason Bentley called Grazrhapsody. Here’s a screenshot of the app:
Edward Grech (Alto Maltés) has produced a GrazrScript application that lets you browse Flickr photos based on tags. The platform is finally coming together. He wrote the Flickr API logic and OPML generation in GrazrScript, and calls an XSLT script on his server to transform the result into feeds. By delivering the feeds through our widget he automatically has an application that works on the iPhone, Ajax desktops, and Facebook. You can learn more about GrazrScript programming in our tutorial.
We wanted to continue on the path of exercising our technology as a complete platform for OPML and feeds, so we have built a custom application that lets you browse the social graph of friends on Twitter. First we created an open API that gathers the information we needed from the Twitter API, and makes it available to anyone who wants to build their own Twitter application. This is a higher level API than Twitter’s, because it delivers complete OPML files and feeds with much more information. We plan on following this path with future applications. Grazr Corp. is about much more than a simple (well, not that simple) widget.
Then we built the Grazr Twitter Reader on top of this API that incorporates many of Grazr’s features, including a custom theme, and a built-in search form created with GrazrScript. I’ve been having so much fun with Dave Winer’s Twittergram.com, that I also got the coders to build Twittergram support into this app. The Twitter Reader works in the same destinations as one of our normal widgets, so you can add it to any web page or run it on the iPhone. We even built on what we learned from our first Facebook app, and created an easy install for your Facebook profile. You will find complete installation instructions for this application in our Tools section.
This is just our first version of a Twitter tool. We have plans to incorporate posting, following, and many other Twitter functions into later versions. We also expect to build more Grazr applications for other online services, so please let us know what sites you would like to see us work with, like Digg, eBay, or Flickr?
So, what would you use this application for? Well, you could use it to keep track of Robert Scoble’s ever growing media empire:
It appears that being a platform is the new goal of Web 2.0. So now everyone will rush to proclaim themselves a platform, until the word has no meaning. Actually we’ve always thought Grazr was a platform, but we didn’t know that was a desirable buzzword, so we’ve been calling it an application development system for feeds. I’ll have to rewrite my Powerpoint slides. Being a dinosaur, I thought platform already had a specific meaning. It’s supposed to be a collection of software tools that allows others to build applications. That makes Windows and LAMP platforms, but is MySpace a platform as Scott claims? I guess it is if you broaden the definition to mean any site that allows others to add functionality. The problem with this step is that with the use of widgets any site can then be a platform. So we’re all platforms. In that case, does the word have any meaning?
I spoke to an investor today about GrazrScript, and his first question was “What is the killer app?” I guess this is a good question to ask about any end-user product, but I’m not sure what the answer would be for a programming language. I taught dBASE for many years and I have no idea what the killer app was. People used dBASE for everything from billing to inventory to running the logistics for the US Navy. Just today as I was sitting in the lobby of the Palace Hotel waiting for Web 2.0 to start, someone came up to say hello and describe the apps he built with dBASE for the Pentagon. So was this a defense related application? No, he built a system to manage all the parties they held. I programmed in Perl for a few years at the start of the Dotcom, and it is still one of the leading Web languages. But what is Perl’s killer app? It has been used for every type of application on the Web.
I had a similar problem when I was teaching programming seminars. I’d explain some totally generic technique, like calculating the date one week from today. If you think about it, this is more than adding 7 days. Inevitably, someone would ask, “When would I use that?” I never knew what to say. My only answer was “whenever you need to calculate the date 7 days from the current date.” I do know that this is a common need, but where it would be applied is up to the developer.
I think about GrazrScript the same way. I clearly see a time when there are thousands of feeds a user might have to search and manipulate to find an answer to a specific question. I know they will need an application to help them perform this operation. I also know that aggregators and search engines are generic tools that can’t be harnessed for highly specific applications. What will those applications be? Whatever the user wants them to be. If they are sales people, it will be a sales app. If they are investors, it will be an investment app. If they are sports fans, it will be a sports app.
To me the killer app for a language is being able to perform some programming task with much less work than any other tools. When dBASE appeared, it was many times easier than CBASIC for database programming. PHP was many times easier than Perl for CGI programming. GrazrScript is many times easier than any existing language for building applications built on feeds.
The other problem with killer apps is that by definition they don’t appear until several years after the product is in use. The killer app for Apple was being able to run VisiCalc. That was realised at least 4 years after the first Apple. The killer app for the IBM PC was Lotus 1-2-3, which came out 2 years after the first PC. So maybe in 2 or 3 years we can look back and say the killer app for GrazrScript was video feed programming. But it is just as likely it will be something people want to do with feeds that doesn’t even exist today. That is the purpose of a programming language. It allows new applications to emerge that weren’t possible before, or were too time consuming to build in large numbers.
Maybe the killer app for feeds will be the ability to use them with GrazrScript.
We just posted the announcement on our home page that the beta version of our new feed programming language, called GrazrScript, is now available in all copies of Grazr. GrazrScript is based on a simple principle. There are now thousands, perhaps hundreds of thousands of feeds available on the Internet that are based on user queries. These appear within search engines, media sharing sites, job sites, government agencies, etc. The one thing they all have in common is that a user query is placed within a URL, and the results are sent back as a standard feed or OPML file.
For example, the following URL will get a feed of Google News items based on a search for “video”: http://news.google.com/news?q=video&output=rss. If you look closely at this URL, you will see that the word “video” is placed after the characters “q=”. This is Google’s way of saying to search for video. If you change the URL to place another word after “q=”, you can search for anything you want. Of course, changing URLs by hand and then reading raw feeds is not the best user interface.
GrazrScript allows you to harness the power of all of these feeds, and publish them on any Web page with a simple to use form and a rich user interface for reading the results. Try typing video into this GrazrScript application and pressing the Enter button. What you are seeing in action is a GrazrScript application based on a Google query for news. You can look at the program here. The key to GrazrScript’s power is that the entire program for this application is just 15 lines in length, almost all of that is the same for every application. In fact, by modifying just one instruction to search in a different URL you can change this application to work with any site that takes a query as a URL and returns a feed.
This post is an excerpt from the GrazrScript tutorial. You can also find a detailed description of the GrazrScript syntax in our 1.0 draft specification. GrazrScript is an extension of OPML 2.0, and carries the same license. Anyone may use the GrazrScript language in their own personal and commercial products for free.
We will be releasing our new feed programming language shortly. Since teasing is an established tradition in the blogosphere, I’ll follow along and not use its name yet. What I wanted to do before we make the first announcement is explain the strategy we will be following. Our long-term goal is to produce an ‘end-user application development system’ for feeds. If you think about it, there is something inherently contradictory in that phrase. How can a user be a developer? The distinction between programmers and users is a long established one, which reflects the dichotomy between producers of applications and consumers. Many of the Web 2.0 revolutionaries are trying to break down that wall, and think of everyone as participants. I agree with that goal, and have long supported it. It isn’t a new idea. it was just forgotten during the Dotcom and Dotbomb.
I spent 14 years teaching dBASE programming before the Dotcom started, so I know that it is possible to have non-programmers build useful apps. In the end, there is a distribution along a power curve, where some people stay as non-programmers, some become dabblers, and others work their way up to serious coders. The benefit of taking people up a power curve is that they bring their application expertise with them. The idea that just because someone knows how to program in Ruby or Perl means that they know what people need in their specific industry is ridiculous. The current glut of horizontal Web apps is one symptom of this fallacy. If you don’t know how accounting or insurance works, you just build yet another online version of Microsoft Office. You get better applications by showing the people who need them how to build them. That leads to a generation of vertical apps that serve the needs of many industries.
One of the most important characteristics of a development system for non-programmers is the learning curve. You want to have the smoothest, most gradual slope possible, so people get reinforcement and continue to learn new techniques. What you don’t want is a big jump in the required knowledge, often called a wall. The worst kind of learning curve has a wall right at the start. Right now Web program is like that. You have to work through lots of technologies to get your first program running on the Web. We hope to provide an extremely easy entry point, and then take everyone up the learning curve in a steady fashion.
The Web 2.0 model of incremental release of features fits into the dual goals of a smooth learning curve and distribution of people along a power curve. I remember having someone come up to me during a class I was teaching about 10 years into the dBASE era and asking if it was possible to learn the language if they hadn’t been around for the past 10 years. Java has a similar problem. There are so many libraries and conventions, I couldn’t even begin to learn it now. We could go off for a year or two and build the perfect language, but when we were done, nobody would have gone through the development process with us. Instead we plan on working closely with the people who start early with our language, and build features and commands with them. This allows gurus to develop in a community, so they will be there to help new members get started.
This long-term strategy also fits with our needs as a startup. We can tactically adjust the language as needs appear and deliver incremental features with a smaller staff. Having your strategy and tactics aligned is a good thing.
Reification is one of my favorite words from my recent studies of History of Science. It means to turn an abstract concept into a material thing. I first learned it from Stephen Jay Gould’s “The Mismeasure of Man” in which he explains how the intelligence test was deliberately used to reify IQ as something that could be measured, and more importantly, a thing that could be inherited. This in turn was used to reify race as a thing that could also be objectively determined. Although Gould rightly attacks these forms of reification, the idea is a powerful one. It is also used by advertisers to turn brands into “lifestyles,” and politicians to turn a loose collection of beliefs into a concrete enemy against whom war can be waged. Whoo, boy, I’m getting more pedantic than usual here. Sorry, I haven’t been blogging for a while.
Anyway, we are facing a similar need for reification in relation to Grazr. If Grazr is to become an application development system, where and what are the applications? It isn’t Grazr itself, since that is a standalone client that works with individual feeds. It isn’t really the Grazr programs (I’ll be writing about how Grazr programs work inside soon), since they don’t run without Grazr. In the case of a traditional scripting language, like Perl or Ruby, people have reified the running program or even its user interface as an application, even though it is actually a combination of the script, data, and the language interpreter. We have decided to adopt this model, and describe the combination of Grazr and an OPML file when they appear on a Web page as an application.
One method of reification is giving the thing in question a discrete physical existence that can be copied and manipulated as an object. For example, a TV show is a thing that can be copied and shared, even though in reality it is just an arbitrary span of time taken from a much larger stream of audio and video being broadcast. In the case of Grazr, we have just added the ability to clone a Grazr application, with all of its attributes, and then paste it onto another page. We have provided the ability to click on the bottom panel of a Grazr to load the current file into the config page for a while, but that didn’t go far enough. Earlier this week we improved this feature to provide complete cloning. Now when you click the bottom panel of a Grazr on any page everything about that Grazr, including the view, fonts, title, etc. are copied to the config page. So you can literally pick up a Grazr from one page and then put it on another. The goal is to instill the idea of the Grazr and its contents as a thing that we call an application.
You can try this out with this Grazr of YouTube videos in 3 pane view. If you click the bottom panel, the current properties are loaded into the config page. Grazr will even clone any changes you make before you click the bottom panel, such as selecting a new view. The only attribute of a Grazr application that isn’t cloned is its size. There are several reasons for this, such as the case of a Grazr that has been launched into its own window and resized. It isn’t clear if the user would want to clone the new size of the window or the size when it first appeared on a page.