plaintext

…when the Sun sets in exact alignment with the Manhattan grid, fully illuminating every single cross-street for the last fifteen minutes of daylight

Nice post from Scott Berkun about misunderstanding the project manager role, both by outsiders and some PMs:

Our culture does not think of movie directors, executive chefs, astronauts, brain surgeons, or rock stars as project managers, despite the fact that much of what these cool, high profile occupations do is manage projects. The difference is these individuals would never describe themselves primarily as project managers. They’d describe themselves as directors, architects or rock stars first, and as a projects manager or team leaders second. They’re are committed first to the output, not the process. And the perspective many PMs have is the opposite: they are committed first to the process, and their status in the process, not the output.

I don’t know about rock stars (maybe rock stars’ managers?), but the more I learn about film, movie directors seem a very good comparison.

I like 37signal’s Design Decisions posts, which explain the thinking behind seemingly small details in their apps. It makes sense: building the core functionality of most web apps is relatively straightforward, the real quality (and, ultimately, most of the effort) is in the details. So, here’s my take on Feedvolley’s design.

I’m not aware of any site that does the quite same thing as Feedvolley, so the first challenge is to get users to understand what it’s about and how to use it. My favorite way to learn to use something is to play around with it (not recommended with firearms, bikes and similar BTW), so the goal was to make Feedvolley’s interface invite users to do just that. That means making it as easy as possible to accomplish something, and then make it rewarding to keep playing with what was created.

To make starting out easy, the homepage is a minimal form with fields for feed or HTML page URL (one of the features that make RSS/Atom a good Web API is the fact it’s often auto-discoverable) and email (more about that in a moment). A default theme is pre-selected.

Another way to create a page is by clicking the “Create a page like this” link located on top of every user-created Feedvolley page. This lets users start with an existing page and modify the content and HTML to their needs. That’s one of my favorite web app buttons - it invites a viewer to become participator, and lets users start with something similar to what they want, and just modify it as they learn the system.

You might have noticed there is no registration step here. Personally, I hate having to register to a website in order to do anything. Feedvolley (like Notifyr) uses email as its user authorization system. Each user gets an edit link with a unique token string. This token is also kept in a cookie, so users aren’t forced to go to their email in order to start editing. “Create a page like this” also serves as backup for this system. In case a user lost the edit link, she can simply go to her page, create a duplicate and continue editing that.

This may not be perfect, but seems optimal for most users. If some users ask for a more rigid authorization system, we can always add it later on as an option.

Once a user created a page, the next step is to make further work on it possible, and worth the time. This is where the “Customize” link comes into play: users can set a page’s URL path and have complete control over the HTML, JavaScript and CSS in the theme. To make themes as easy as possible, Feedvolley’s markup closely follows that of Tumblr (Tumblr’s templates inspired the Feedvolley concept, in fact. They do great work over there). In “work with the existing environment” spirit, this lets users easily adapt existing Tumblr themes for Feedvolley and also use Tubmlr’s docs, which also saved us some documentation pains :)

As far as design goes, I’m with the “it’s done when there’s nothing more to remove” (as opposed to “nothing more to add”) school. So, I’m pretty happy with the result in Feedvolley. Some challenges remain: how to make it more obvious that a page can be customized once it’s created, for example. It’s not perfect yet and we’ve already incorporated some user feedback into it - if you have any comments or requests, please leave them here or email me directly: niryariv@gmail.com.

Feedvolley is a new project I collaborated on with Kyle Bragger. It began when Kyle and I found we each had the same idea at the same time and so we set out to build it - Kyle, who is one of the brightest coders I’ve met and among the rare total developers that master the whole range from visual design to server side, is responsible for everything that looks good in Feedvolley, as well as for the name itself.

Feedvolley basically takes in an RSS feed and displays it in user defined HTML template. You can start with a default theme and can later use another pre-set theme or customize your own HTML/CSS/JavaScript. You can set the path portion of your URL (ie feedvolley.com/) and have people view it a regular web page. People who like it can then click “Create a page like this” and start off their own pages, modifying the look or content to their needs.

Consuming an RSS feed and putting out HTML may seem a bit counter-intuitive, but I think it can have some interesting uses. One is to complement feed tools like Yahoo!’s Pipes that let you mix together and modify different feeds. For example, you could use Yahoo! Pipes to combine several job site feeds, filter only those which contain a certain keyword and present the resulting feed as an HTML page. Or you could take the output of a any feed aggregator and display it River of News style, perhaps with some JavaScript effects etc., or you might use a scraping tool like Dapper to extract certain parts of a page’s contents into an RSS feed, and display it with your own look.

Another use is to skin existing websites. You can take content from any website with an RSS feed and use Feedvolley to present it with a different HTML skin. For example, here’s the NY Times’ homepage in a different layout. There’s a nice subversive potential here, and having complete control over your HTML/JS/CSS allows for a lot of creativity. My own front-end coding skills somewhat lacking, I still managed to do a mildly interesting project like NYMinute using META Refresh tag and Flickr’s ‘photos tagged nyc’ feed.

Hopefully, users will put Feedvolley to other, unforeseen uses. I already found an unexpected one in the site itself, to display the Recent Pages feed. When I demoed it to a friend, he instantly set up a digest page of updates to his company’s Wiki site. You can get something up very quickly with just a URL and your email address, and later on you can customize it to do anything that can be done with HTML and JavaScript.

Feedvolley continues on themes from projects like Notifyr and Prixfeed. First, RSS as the web API - I think RSS goes a long way towards a common API for websites. It is read only and lacks some features, but most sites only need a read-only API, detailed information can added via domain-specific tags or microformats and, most importantly, it’s already in wide use. I think there’s a lot more to do with the RSS content already being out there in addition to the current Feed Reader uses.

Second, the idea of content modifiers (or participators, user/developers etc). Everything Feedvolley does can be accomplished with some code, but removing the setup and maintainence overhead and the need to write code opens this kind of application to a much bigger potential crowd (this is like Notifyr’s URLs that allow web literate - but not necessarily technical - users to construct a link lets people subscribe to their Flickr page). UI elements like minimal setup dialog, no registration requirement and support for copying existing pages are there to make Feedvolley something that you can play around with, tweaking it and getting instant feedback.

Really, you can :) Just follow this: Feedvolley

I don’t usually read Fast Company & co, but I found an article in the recent issue pretty inspiring. It’s about a landscaping company called Whole Systems Design which tries to build stuff in a way that takes into account the environment where it’s located. Environment not just in the “compost your pizza leftovers to offset CO2 of your vacation” meaning, but in the “stuff that already exists when you start building” sense. It’s a simple and intelligent approach to design - create something that works with what’s already there. From the article:

[company's founder, Ben Falk] calls mainstream environmentalism, with its “nihilistic,” minimize-human-impact approach, one of the “largest hurdles we face toward being a good community member of the earth again.” He cites one of his influences, Berkeley architect Christopher Alexander, who asked, “Can a building be just as natural as a tree?” Adds Falk: “Or a beaver dam? … It goes beyond ‘Let’s pretend we’re not there.’ We’re here. Let’s make a good impact.”

This links for me with the release of Phusion Passenger, aka “mod_rails for Apache”. I don’t know how well it works (Dreamhost now offers it, which seems a good sign), but if it works well this may be the most important thing that happened for Ruby on Rails since it was launched.

Rails’ main weakness, in my opinion, was that it did not take into account what was already before it, namely the Apache web server (and also stuff like existing code/DB schemes, but that’s less critical perhaps). It was very slow under Apache, and instead of fixing this the Rails community set out to replace Apache with something else - first lighttpd, then Mongrel, now nginx. But it turns out Apache leads its category, by a large margin, for a reason and that creating a good web server, though it might seem pretty straightforward to begin with, is actually pretty hard.

With mod_rails, Rails deployment may now be as easy as PHP deployment, which will give RoR a chance to compete in the shared server space, which is often looked down upon and yet is far bigger than the dedicated server domain, as seen here (this is based on PHP IP vs Domain stats - very rough but generally the right idea):

It is said that The Velvet Underground were hugely influential even though few actually bought their records, because most of those who did listen to them ended up starting bands. For some time, I was thinking Ruby on Rails is going to end up similarly - myself and many other developers got our initial exposure to MVC and ORM and Convention Over Configuration from Rails, but we often ended up building applications in Rails-influenced frameworks like CakePHP or Code Igniter that implemented these ideas in languages that could be easily deployed with reasonable performance (the key word here is easily. You can get performance with Rails, but it requires leaving your core problem for some time, to specialize on deploying RoR). Now, it may not be this way - provided people are still working on improving the docs :)

Just discovered Cloc - a pretty useful tool for counting lines of code in a project. It even auto-determines the languages used and sorts the results in lines of code per language.

Yesterday this image made it to Digg & co:

It was presented as the next Ubuntu theme, but it’s not - the linked page was quick to post an explanation: “I’m sorry to say that this is not planned to be the next Ubuntu theme. It has been passed it up to the art team, and there’s a lot of work ahead”

However, he adds - this is the cool part - “If you are visiting and you do have ideas or suggestions, please post them here! There’s an entire sub-wiki just for your input!”

Compare this to Apple sending a legal “please don’t send unsolicited ideas” letter to an 8 year old girl who wrote them. Not because Apple is mean, simply because that’s how it works in that type of business. Who do you think will eventually build the better product?

Ubuntu’s Brainstorm app is very cool. Basically it lets users post suggestions, bugs and requests for Ubuntu, and rate/comment other users’ posts. It enables users to get involved in the process and lets developers know what users are missing most and get ideas for future additions. It’s a new interface for discussion, something new on top of forums, bug tracking apps etc.

(Dell’s Ideastorm, predates Brainstorm, but the concept will probably work better with Open Source projects where users are more accustomed to this kind of feedback process. Ideastorm’s own top items are almost all Open-Source related. Having less of a life also makes some difference I suppose ;))

You can get the source at Ubuntu’s repository but unfortunately there isn’t a downloadable standalone package for this yet. It would be great to have an simple install of this, I think almost any product and company could benefit from something like this.

This is why open source software is growing so fast: it’s a positive feedback loop, its products feed its own growth. Good to see Ubuntu growing so nicely, with Vista & Leopard we definitely need an alternative.

This gives you (almost) complete access to Metafilter’s database: you can simply run any SELECT query on their DB that you like - export as CSV/Tab delimited file too. Very very cool. Wouldn’t it be nice to see something like this on, say, NYTimes or Amazon.com?

I spent some time recently polishing the old “Amazon price feed” project, and gave it its own domain: Prixfeed.com (pricefeed.com was, naturally, taken). Basically what it does is take an Amazon product (by its page URL or ASIN code) and returns an RSS feed of its price. This lets users keep a watch on the price, getting updated whenever it changes.

Always liked 37signals‘ Design Decisions posts, so here are a few I made with Prixfeed, mostly to keep it simple and minimum-effort as possible (BTW, where it says “RSS Reader” I refer to the software reading the RSS feed, not the person using that software):

• One URL:

  http://prixfeed.com/?ASIN=<Amazon ASIN or product URL> returns the RSS feed.
  (Or, with URI Templates: http://prixfeed.com/?ASIN={ASIN} )

  http://prixfeed.com/ without params will display a form where the user can enter an Amazon ASIN code or product URL, which then directs to the its RSS feed.

• No cron jobs: Prixfeed simply checks a product’s price whenever the above URL is called (naturally, some caching is needed here to guard from buggy/malicious clients overloading it). This means data refresh is timed and triggered by the RSS readers, removing the need to build a backend update system or keep track of what data needs to be - ie, which products are currently monitored. Which leads to:
• No database: so no need to keep track of who’s tracking which product, but with a non-RSS system (eg. email alerts) you’d still have to store prices in order to guarantee you’re only sending out a message when the price has changed. RSS, though, has a guid element which lets an RSS reader determine whether an item was read before. By making that GUID a function of the price, Prixfeed makes sure the RSS readers will display only new prices as new items.
• Machine readable: it’s easy to programatically create a Prixfeed URL request for an item price, but I wanted to make the response machine-parseable as well, while keeping it human-readable. One way would be to have a URL param that will return an XML response, but I like the minimalism of a single URL so I decided to use a Microformat-like approach. The response’s description element contains HTML which includes attributes like id="price" etc that allow automatic parsing of the content (more details here).
• Small output: each message contains the text “The Amazon price for <item> is now $x” and a purchase link. I like minimum friction products - there should be some proportion between the value you’re getting from something and the investment it requires you to put in, both when entering information and reading it. Since the value here is less than life-changing, I figured I better keep the time investment minimal as well.

That’s it then - once again I manage to write a blog post with more lines than the code its about! Go on and RSS thy Amazon purchases!