A new Seekler niche: video games

January 17, 2008 by

We had some great successes last week promoting our list of the most anticipated movies of 2008, but as that traffic dies down – we’re looking to promote one of our fastest-growing niches: video games. Seekler has a great list of the best video games of all time as well as a list of the best free computer games.
But my favorite is definitely our list of the best online flash games. If you are looking to ease your boredom at work or school, definitely check this list out. But be warned – I unintentionally spent over three hours last night playing these games. Some of them are very, very addictive!

Seekler beta: exciting first week & more press

January 14, 2008 by

Just a few quick announcements:
Last week was a great one for Seekler. Just a few days after we launched our beta, we got an incoming link from FARK.com’s showbiz section, which brought us a ton of new visitors. Sorry if the site slowed down a bit – we’ll be addressing that this week.
Secondly, Seekler got another nice post at Mashable. Thanks, Kristen!

Seekler (beta) launches!

January 7, 2008 by

After many months of hard work, we’re proud to unveil the beta version of Seekler. We’ve added lots of features since we released our alpha version, but the most important one is that as of today, user registration is completely open to everyone!
We’ve only gotten this far because of our amazing alpha users and we will continue to be dependent on the support of users like you. If you can, doing any of the following would help us out immensely:
1. Use Seekler! Seekler will be able to attract more users as there is more and more useful data on the site. Making a new list or adding to an existing list would be a huge help. Also, you can add reviews to items on your existing lists to give them more depth.
2. Give us feedback! Seekler is far from finished, but we will continue to need your help to improve it. What features do you wish we had? What tasks are painful to complete? What lists do you wish we had?
3. Tell your friends! If you’ve been waiting to tell your friends about Seekler because it wasn’t easy to create an account, wait no more. Anyone can easily create an account and start making lists.
4. Link to us! Incoming links will help us get traffic and improve our position on search engines like Google. If you have a website, a blog, or even a MySpace of Facebook profile, and incoming link to Seekler would be very much appreciated. You can link directly to http://seekler.com or to a list that interests you. If you’re into movies, a link to our “Anticipated Movies of 2008” list would really help us out since we’re currently trying to promote that list.

One Good Niche: Most Anticipated Movies in 2008

December 20, 2007 by

Recently we wrote about our efforts to find some good niches for Seekler. Our theory is that if we can get a lot of great content in a few key areas, that will get a lot of visitors to our site – and hopefully, they’ll start using it for other niches as well.
We’ve recently found our first really successful niche – Most Anticipated Movies in 2008. We’re in the first few results on Google for search terms related to anticipate d movies, and as a result, a lot of traffic is coming for this list. We’ve added a lot of content to the list to make it really useful, including links to trailers, descriptions, and tags.
Another things we’ve done is add to the ability to attach your own review to an item. Instead of just ranking the items in order, you can also explain why you placed a certain item at the rank you did. Not all lists have reviews (it’s such a new feature), but the Anticipated Movies in 2008 list does – for instance, here are the reviews for my personally most-anticipated movie, The Dark Knight.
Hopefully our strategy of aggressively targeting niches pays off. What other niches would you like to see Seekler target?

Featuritis, Tyranny and Web Applications

December 13, 2007 by

I’ve been excited about the possibilities of web apps ever since Paul Graham sung their praises back in 2001 (I’m sure other people were talking about them in 2001 and before, but Paul’s essay was especially influential for me). What’s not to like? With web apps you get to release early and often, get real-time feedback on which features your users actually use, there is no clunky installation, and you get to write your app in something other than C++ (in my case, we got to write Seekler in Ruby, which is sweet).
One of the most promising properties of web apps is that they aren’t as susceptible to featuritis. If you’re not familiar with featuritis, just think back to the earliest version of Winamp you ever installed. It was a lean, simple, just-plain-great mp3 player. You know how you stopped using Winamp because they added all these insane features that made it slower, bigger, and less usable? That’s featuritis – the tendency of successive versions of software to add more and more features, most of which you never use.
Featuritis isn’t completely the product of over-eager developers (although that’s part of it). It’s mostly a result of the economics of desktop software – if you want someone to buy/download the newest version of your software, you better add some new stuff to justify it. No one is going to pay $200 for a new version of Windows that adds no new features, but is simpler, faster, more stable, and more secure.
Web apps don’t have this same pressure, because there is a different business model. With web apps, developers don’t have to justify the next version. Instead, we just have to make sure the current version is awesome enough that you’ll keep coming back (and either click on our advertisements or pay a monthly fee, depending on the app).
Web apps can shift their focus away from features and compete on things like performance, usability, simplicity, community and content. Of course, features are still important – although you don’t have to convince users to get that next upgrade, you still have to prevent them from moving to your competitor. But whereas before the focus was almost entirely on features, it’s now a little more balanced, so hopefully that means less featuritis and less bloat.
Jeff Atwood got me thinking about all this when he wrote about featuritis over at Coding Horror. I was reading his thoughts on upgrading to the newest version of Winamp, when this caught my eye:
“I don’t have to upgrade, of course, and there’s nothing forcing me to upgrade.”
And there lies one of the key advantages of desktop apps – even though there is considerable pressure for user to upgrade their desktop software, they do have the freedom not upgrade. And many users don’t upgrade. I know many users happily plugging away with old versions of word processors or graphics programs, some of them quite content running Windows 98. In fact, there are whole sites devoted to making sure people can find and use old versions of desktop apps.
The vast majority of web apps simply take this freedom away from their users. And yet, in all the talk I hear about the greatness of web apps, I rarely hear this problem discussed.
I think as we move out of the early days of web apps, this is going to be a bigger and bigger problem. The sizable number of users who don’t upgrade their desktop applications regularly are going to be pretty annoyed every time we force some new, shiny toy down their throats. Are we developers going to be (hopefully benevolent) dictators, forcing each individual to endure what we think is best for the masses? Or, on the other hand, will we be so terrified of angering our users that we stop delivering new features altogether? Neither option sounds that pleasant to me.
Clearly, I’m not the only one concerned about this: check out the latest version of Gmail. You’ll notice that they have a new link in the right-hand corner: ‘Older Version’. And I’m glad they do, because GTDInbox doesn’t work with the new version. But how long will they keep that up? Will they keep a link to all past versions?
It would seem the ideal situation would be to let users opt-out of updates but this presents some pretty big techincal headaches. Maybe you can just skin the old UI on new functionality to hide some of the new features. But when a new feature requires changes to your database, how are you going to make sure all current and old versions play nicely together? Are you really going to test creating and viewing data on every pairwise combination of app versions? Or are you going to sandbox old and new users into different DBs? Any way you slice it, it’s going to get real complicated, real fast.
Perhaps this is just a fundamental trade-off for web applications: you get some great benefits, but on the downside, you’re at the whim of the developer. But I suspect it’s solvable. I doubt there is a silver bullet, but if we start talking seriously about the trade-offs and possible solutions now, we might be able to get the best of both worlds.

Seekler List Widget

December 4, 2007 by

One way we think Seekler can be useful is for interacting with readers on a website. Publishing a list on a blog is a common post. The comments on published lists are commonly suggestions for other things to add to the list, or the commenter’s own ordering of the list. Trying to read through all the comments and combine them mentally is pretty hard. If you create lists on your blog with the Seekler widget, not only do you have a nice looking list, you also have a way to collect feedback from your readers in a useful way. For instance compare, Most Wanted Guitar Hero 3 songs with a blog post on that topic. Below I have included my list of Seekler feature requests, you can also check out what the community is requesting. Feel free to contribute to the list.

The widget shown above is our first test of a widget that will show one specific list. We also have a widget that will show all lists by a specific user.

Take some time to check these widgets out and give us some feedback so we can improve them and make them ready for release for all of our users.

Seeking Our Niche

November 21, 2007 by

We originally built Seekler with a few key niches in mind, including comic books, programming resources, and movies. We have kept Seekler fairly general hoping that it could serve a large range of areas. As we have approached launch we have discussed many niches we thought we could target with Seekler, but we didn’t write down or fully develop our thoughts. We knew that we couldn’t try to attack all of our niches at once and that some would be a better fit initially. We also knew that some niches were already well-served by existing sites like Amazon.
After a few of our Seekler pitches didn’t go as well as we would have hoped, we realized the example niches we used heavily affected how people thought about that site. Sometimes coming up with the examples on the spot didn’t lead our conversation in the right direction. We realized we needed to spend some time and reflect on which niches Seekler could be perfect for and which were not as good. After working on our niche list, we started seeing patterns and discovering new niches we think Seekler could serve. Figuring this out has been incredibly valuable, helping us focus our development.
To help us focus in on the best niches we created a graph like so:
We then started placing our ideas along the graph until patterns began to emerge. It forced us to realize some of the topics we thought we could serve were actually bad matches, while other topics we never considered were well-suited for Seekler. The resulting graph can be seen below.
One pattern we noticed is that Seekler is not good at niches that require professional reviewers. We previously used digital cameras as an example for a good product people could use Seekler to narrow their choices down and then find in-depth reviews. It turns out the using the community review process for digital cameras really makes no sense. We allow a large community to build up opinions by offering lists in order of best to worst. The average consumer only buys one camera every few years, how could they rate their 10 best digital cameras every year? Only professional review groups can get full collections of cars, cameras, and other more expensive or rare items. These are a bad fit for our community review process, and well served by professional reviews which often fully review the entire market of items.
Seekler is excellent at products that people buy or use regularly and cost little to no money. The average person goes through a lot of music, books, comics, and games, for example. So it is easy for a comic fan to list his favorite Marvel comics. These niches are a better fit for the Seekler community and actually harder for expert reviewers to cover, as they can’t expect to have in-depth reviews across the entire space. Another reason community reviews can be useful is that in some cases, the opinion of experts isn’t as important as much as say the opinion of your friends, people your age, or of a diverse community in general. There are many areas where the long tail of reviews is often poorly served, while there are clearly many fans that exist with valuable opinions on often overlooked niches. For instance I think Seekler will reach a collection of the top 100 punk songs far before Rolling Stone will ever create that list.
In some ways we see the community review process as complimentary to in-depth reviews. While topics like punk music the opinion of the community may be enough to warrant a purchase. There are other cases where the user still may want in-depth reviews, after narrowing down your choices. We think the community review process can help you quickly narrow down the list of comics or anything you’re interested in faster than trying to read a huge collection of expert reviews. In this case while the user still may really be interested in in-depth reviews that get into the details of a comic, Seekler can still help them find interesting new comics which they can then follow up on.
Just learning these concepts about Seekler was important, as it helped us to improve our pitch. It also helped us realize some of the features we had planned were more important than others. Taking a step back from our code, after months of programming, and thinking more about the problem we are trying to solve gave us a better focus on our problem and a better understanding of our users. We don’t think we have found all of the best niches to initially focus on, but we have a better understanding where we should begin. If you have any suggestions, we are all ears as we are hoping our initial users will also help lead the direction of the site, by suggesting niches for Seekler to target.

Review: Website Monitoring with Mon.itor.Us

November 16, 2007 by

I thought it might be a good time to share another tool that we work with. After running multiple sites over the years, I eventually started looking for tools to verify my site was up and running. I started by writing my own scripts to just verify my sites were accessible and email me if there were any problems. Then I found some online services that would check this for me, but they always seemed to run into their own issues. At one job, we used Nagios which is a great piece of Open Source Software, but may be a bit of overkill to set up for simple website monitoring. If you need customized and complex monitoring, I think Nagios would clearly be the way to go, but if you have simple needs, I think easier solutions would make sense.
So while continuing my search for an optimal solution, I eventually stumbled upon Mon.itor.Us, which has been a great solution for us. It is very easy to set up, most of the services are free. It can send weekly reports or only notify you when there is a problem on your network. It has some nice features such as accessing your site from a few locations across the globe, which gives you a better picture of your site’s response time.
Mon.itor.Us offers monitoring for HTTP, HTTPS, FTP, SIP, TCP, UDP, IMAP, SMTP, POP3, PING, and DNS. The site also offers other monitoring services like user agent tracking, site visitor statistics, and other options. This more than covers our simple needs: in fact, we use other services for our visitor statistics.
Mon.itor.Us isn’t perfect, but has served us well. We wanted to get SMS notifications if any of our sites went down, which isn’t a free service of Mon.itor.Us. Seeing as we didn’t want to set up our own monitoring and dealing with enabling SMS, it was easily worth the $5 dollars that we spent to enable SMS notifications for our account. The time saved by outsourcing this function of our IT easily covers the minor cost. The only other complaint is that the site’s UI can sometimes be confusing. For instance, when I was trying to edit my account information, I could only figure out how to add new accounts, but not edit existing ones. It turned out that after viewing the ‘new account’ form you could then click on existing account names to edit them. The dual use of the form which initially is only for adding accounts wasn’t clear to me. Other than these minor complaints the service has worked extremely well for us.
Mon.itor.Us has made it simple for us to not worry about monitoring Seekler, so we can focus on other things like coding.

Pattern Matching in Ruby

November 11, 2007 by

for the impatient:[tests]
To paraphrase Alan Perlis, learning a good programming language should affect the way you think about programming. The only problem: since it’s such a good language, it’ll probably give you a bad case of feature envy when you use other languages.
Case in point: Pattern matching in Haskell (Yeah, I know, other languages have pattern matching, but Haskell introduced me to the concept). Pattern matching let’s you write very clear code by choosing an execution path based on the structure of a function’s arguments. So, for instance, you can write:

fib :: Integer -> Integer
fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2)

Instead of checking the argument within the function, you essentially write three versions of the function ‘fib’ – one for when the argument is 0, one for when the argument is 1, and one for all other cases.
Now this may just seem like a fancy switch statement, but it’s much more powerful than that. For instance, pattern matmching can break down lists. Check out the Haskell implementation of map.

map _ []     = []
map f (x:xs) = f x : map f xs

What’s going on here? Remember, map is a function that takes a function and a list and applies the function to each member of the list. The _ is like a wild card – it matches anything. The [] stands for the empty list. So, if the arguments to ‘map’ are an empty list and ANY function, it just returns an empty list.
Otherwise, Haskell binds the first element of the list to the name ‘x’ and the remainder of the list to the name ‘xs’. It then applies the function to x and recursively calls ‘map’ on the remainder of the list. Very cool!
As you can see, pattern matching can really simplify methods, especially when the arguments to the method have complex structures (if you’re still not convinced, Steve Yegge motivates pattern matching much better than I have). The trouble is, I don’t use Haskell on a regular basis – I use Ruby. And Ruby doesn’t have pattern matching.
Luckily, Ruby is a remarkably flexible language. So much so that a number of people have implemented various versions of pattern matching in Ruby. But while those implemenations are very cool and taught me a lot, none of them quite felt right. Plus, I’d been looking for an excuse to play around with Ruby’s metaprogramming features and this seemed like a good opportunity.
So, I wrote my own version of pattern matching in Ruby. The Fibonacci sequence looks like this:

def fib(n)
match n do
with(0) {0}
with(1) {1}
otherwise {fib(n-1) + fib(n-2)}

(Although this isn’t really a great example because a case statement would suffice). And map looks like this:

def map(proc,arr)
match([proc,arr]) do
with([:_,[]]) {[]}
with([:f,:x % :xs]) { [f.call(x)] + map(f,xs) }

It’s not quite as succinct as the Haskell code, but it’s reasonably close (note that I can’t use Haskell’s : operator to destructure the list, so I use the % operator instead).
Here’s a more interesting, if contrived, example – let’s say you have a tree structure (represented by nested arrays). Each node has a left and right branch as well as an operator. So a tree might look like this:
[[5,'*',10],'+',[6, '/', 3]]
Now let’s write a method that will give us a string representation of any tree. So, for the example above, we’d want “((5 * 10) + (6 / 3))”. Without pattern matching, we’d write something like this:

def disp(tree)
elsif(tree.is_a?(Array) && tree.length==3 && tree[1].is_a?(String))
"(#{disp(tree[0])} #{tree[1]} #{disp(tree[2])})"
"Invalid tree structure"

but with pattern matching, we can write:

def disp(tree)
match tree do
with(:num & Fixnum) {num}
with([:left, :op & String, :right]){"(#{disp(left)} #{op} #{disp(right)})"}
otherwise {"Invalid tree structure"}

Let’s go through this step by step. If ‘tree’ is a Fixnum, we assign bind it to the name ‘num’ and return it (the & operator binds the matching argument to the symbol on its left – in this case, :num). If ‘tree’ is actually a tree node, we give a name (‘left’, ‘op’, and ‘right’) to the various parts of the node and recurse. Once you get past the strange looking syntax, the code is much cleaner and easier to understand than the version without pattern matching.
We can also destructure arrays. Here’s an example that drops the first three elements of an array:

def drop_three(array)
match array do
with(:_ % :_ % :_ % :xs) { xs }

If you’d like more examples, the tests are a good place to start. Or you can just check out the source code. Feel free to use it however you want – I’d love it if a better Ruby hacker than I improved this stuff…
A few caveats:

  • I really can’t take much credit for this, my code is heavily depedent on some very nice DSL and let code written by Reginald Braithwaite. It’s cool stuff, check it out.
  • This was my first attempt at some serious Ruby metaprogramming. I probably did some dumb stuff – so if you have any tips, please let me know.
  • It’s pretty darn slow right now. If anyone wants to take a crack at speeding it up, be my guest. I’ll probably look into it as time permits.

Thanks and enjoy!

Lessons Learned from our YC Interview (with Tips!)

November 7, 2007 by

I’m back from Cambridge with some unfortunate news: Y Combinator decided not to fund us. Dan and I are disappointed but we’re glad that we got the opportunity to pitch our idea. Thank you Paul, Jessica, Trevor, and Robert (whom I’ll collectively refer to as ‘YC’ for brevity’s sake) for meeting with us and for giving us feedback on Seekler. We really appreciate it.
Obviously, we’re disappointed with their decision but we’re optimistic – clearly they thought Seekler was interesting enough to warrant flying us out and they said that we should continue working in this space. They also gave us some great feedback that will help us improve.
The whole process was great, but I want to mention one thing I found particularly awesome – the way in which YC gives you their decision. Given that they are very busy calling all the teams in one night, I expected the decision to be a quick ‘yes’ or ‘no’. Instead, Paul called me up and we talked for over five minutes about Seekler. He gave me specific reasons why they chose not to invest, listened to my ideas for the future, and gave me great feedback. I know that his time is valuable (especially on decision night) and I really appreciate the way he gave everyone (even those who didn’t get investments) great advice and ideas to improve.
So we left the weekend with a good idea of why YC chose not to invest in us. Their main reason was that Seekler doesn’t have a huge innovation that would let us really compete with existing review sites like Yelp. The frustrating thing is that I feel like this criticism is based on a misconception of what Seekler is all about. I feel like they rejected a concept that was close to Seekler, but not quite Seekler.
A few keys points I want to make absolutely clear before continuing:
1. I’m not a mind reader – I can’t say for certain if the YC folks truly understand Seekler or not. Maybe they understand perfectly and were just not interested.
2. Even if they don’t understand, it’s impossible to say whether they would have been any more interested in Seekler if they had understood better.
3. Any misconceptions YC might have about Seekler are entirely our fault and not in any ways YC’s. What we said ultimately doesn’t matter – what’s important is what they heard. And we were responsible for making sure they heard what we wanted.
I don’t want to go into the reasons I disagree with their reasons – that’s not really the point of this post. The only reason I mention it is that it illustrates the lessons we learned while interviewing with YC. Hopefully these lessons will be useful to future YC interviewees – but they should apply to anyone pitching to an investor.
Let me really quickly give you a picture of what the interview itself is like. First, it’s really short – only ten minutes. If you have a demo (which we did), you’ll be asked to show it, but YC will almost immediately start making requests and asking questions, effectively taking control of the demo. From there it’s just non-stop, rapid-fire set of questions for ten minutes. It’s intense, but actually pretty fun.
In retrospect, the interview format makes a lot of sense – they have a short amount of time to assess you and your idea, so they need to get the answers they need as fast as they can. But I wasn’t really expecting it and it can throw you off-guard if you don’t see it coming.
That said, here are some specific tips for getting the most out of your ten minutes. The key is to take responsibility for communicating your vision.
Tip 1. If you have demo, walk in with it loaded and your laptop open.
This should be pretty obvious, but don’t trust your laptop to wake up quickly. My MacBook Pro is usually pretty good about coming out of sleep, but of course during the the interview it took about 20 seconds to become responsive. When you only have 10 minutes, every second counts.
Tip 2. Show them the coolest thing right off the bat.
We had a scripted five-minute demo all planned out. We only showed about 10% of it. Don’t assume that you’ll get past step two of your demo – jump right into the part you want them to focus on, because that’s all you’ll get to show once they start asking questions.
Tip 3. If you have user-generated content, carefully prune it for the demo
For our demo, we had prepared data on comic books, because it’s a great example of a niche that is not currently well-served and that Seekler would be prefect for. However, we’ve had alpha users for some time on Seekler and we’ve let them create any types of content that they want. So, when we fired up the Seekler home page, the first thing YC saw was lists on restaurants. They asked to see that, and we obliged. Unfortunately, our data on restaurants sucks. And frankly, restaurants is a pretty bad niche for Seekler – simply because there are other sites that do it so much better than we will.
But first impressions are hard to change – we got several minutes of questions about how we are going to beat Yelp and Zagat. Ultimately, it seems their concept was largely defined by this first impression. We definitely should have only displayed niches that fit really well with our vision for Seekler.
Pruning your data can seem counter-intuitive. Many sites are quite general and it may seem like you don’t want to limit your vision to just one area. We thought it would be good to show the breadth of content on Seekler. But some content is just plain better for your app than other content. Think about it – if you were pitching YouTube, you wouldn’t your investors to come to the front page and just see music videos. This will give them the impression that you’re trying to compete with MTV (plus it raises questions about copyright infringement). You’d be better off showing off the highest-quality user created videos you can find. Always show the data that best fits with your app first.
4. Watch the clock and deliver your vision
YC will hammer you non-stop with technical and business questions. You need to answer these, but you also need to watch the clock and make time to really explain your vision. We spent several minutes answering questions about the mathematical feasibility of our project. We know the math works but we found ourselves eating up a lot of our ten minutes trying to convince them. While we addressed their specific concerns on the math, I think the main focus of the site got lost in the chaos. You’re ultimately responsible for making sure they really get it – and that may mean that you have to gloss over specific questions a bit to make time for explaining your overall strategy and business plan.
Overall, the weekend was a hugely positive experience. We made some mistakes in our interview, but now we know more about pitching to investors. Regardless of the potential misunderstandings about Seekler, YC gave us some great advice which will undoubtedly make Seekler better going forward. We got to meet some incredibly smart people who have inspired us to quit our jobs and start Seekler. And they said we could continue to send them updates, so hopefully we can benefit from their experience even though we won’t be going to the Valley.
Congratulations and the best of luck to all the teams that got funding!