January 26, 2007

Webshots Integrates User Videos

Posted in Usability, webshots at 5:17 am by mj

Just before the holidays, Webshots launched videos. What I love about this is that videos are just another way to tell your story, and fit seamlessly into your albums. The coolest part of this, IMO, is the new slideshow.

(See an example slideshow at Webshots. *ahem* wordpress.com doesn’t yet support inlining Webshots videos or slideshows.)

While we do have a Video channel, our intent is for videos and photos to complement one-another, and to coexist on the page. Mark, our lead designer, has done a great job since mid-2006, and the natural fit of videos is one area where our August redesign is starting to pay off. (More payoffs will be apparent in the coming months.)

The one thing I think we did wrong is having a separate video search. This was a product decision made early on, with some technical ramifications. While it’s great to be able to effortlessly see the latest videos–overall, or by keyword–it’s the one area where we’re intentionally segregating photos and videos, and I’m not sure if that fits in with what our users will want. I think we should improve on that by making photos and videos searched together by default, and supporting a photo-only or video-only filter as an advanced option.

It’s interesting to note that, at launch, we supported higher resolution and better quality videos than the obvious rival YouTube. I was blown away by our team’s tests that showed the same video uploaded to each, and ours was obviously far superior.

Alas, that did not last, as many DSL connections could not support the increased bandwidth, so we had to scale back. Now, our videos have only a slightly greater encoded quality than YouTube, and our resolution is comparable. Longer term, I’d expect us to support multiple encodings/resolutions, and serve the best version that your connection will support.

January 25, 2007

Is Code Quality Subjective?

Posted in Coding, Development, Software, Style at 4:42 am by mj

Most developers I know fall into one of two camps: either they believe that their code is the best code and that everybody else who does it differently needs to learn a thing or two, or they believe that some “standard” codebase is the best code and, de facto, represents the best way to do something.

Certainly, I have a hard time understanding why anybody would write

    if (someCondition) doSomething();

rather than

    if (someCondition) {
        doSomething();
    }

Nowhere has my annoyance been higher than when I started dealing with code from a team of offshore contractors, who not only do the former (against all Java coding conventions), but they like to confuse others with beauties like:

/* is the following code active or inactive? * /
doSomething();
if (complexLogic1() && complexLogic2()) doSomethingAgain();
maybeThisCodeWorks();
/**/

and

 <!-- MyTag
   <SubTag>value</SubTag>
 </MyTag -->
 <MyTag>
   <SubTag>another value</SubTag>
 </MyTag>

Another recent example: I’ve been evaluating Solr for use at Webshots. The Solr guys have done a tremendous job producing an enterprise-y application layer on top of Lucene, and it came out of an internal CNET project by another team (developed in response, IIRC, to the acquisition of Webshots, which introduced Lucene to CNET). There are still some suspicious gaps in Solr that make it not yet suitable for Webshots’ scale, but nothing a few good contributions from us can’t tackle.

But the code style!

One good, and recent, example is negative filters. It just so happens that I solved the same issue recently at Webshots without knowledge that Solr already had an issue open on it. My solution was a NegatedFilter class that can be utilized by any consumer of Lucene, usually in conjunction with a CachingWrapperFilter. I just didn’t contribute it to Lucene (bad developer, no cookie!).

Their solution (patch available from the link) is quite Solr-specific, messy, and long. I haven’t yet compared to see if theirs is a significantly better performer, but since mine is just flipping bits and took, e.g., a 4 minute filter down to 10 seconds, I don’t see that there’s much need for improved performance.

And yet, Yonik and team will tell you that the Webshots search application is also messy and fragile, despite its scalability. (I know because I’ve had this discussion with them before. :)) In fact, they’ll also tell you that our application isn’t scalable. Which is somewhat true–but, so far, I haven’t seen where Solr is more scalable. I’ll have better performance metrics in a few weeks, though.

Finally, another example is using Spring for app configuration. The problem that I see with spring is precisely the same discussion that takes place in the Ruby community: the ability to use domain-specific languages. If you specify your own XML format for configuration, the XML file becomes a domain-specific language that feels natural for the application that you’re trying to configure. If you use Spring for your configuration, you get a lot of nicetities on the code side, but your vocabulary becomes limited to beans and properties and props, which feels natural and intuitive in only a few contexts, and certainly is nothing you’d want to give non-engineers to manage.

Thoughts, further examples or rebuttals?

January 19, 2007

Good-bye, Findory, & Are We Ready for Personalized News?

Posted in Personalization, Search, Usability at 10:04 pm by mj

Greg Linden–founder, architect, designer, programmer, visionary, banker behind Findoryput Findory on autopilot until its resources are depleted.

Findory has been my primary start page for quite a while. Sure, it had its shortcomings. Too many of its sources were aggregators: Slashdot, Metafilter, Planet fill-in-the-blank, and so on. Clicking on a news story through one of those aggregators meant weeks or months of getting stories from them in your top results.

While its traffic peaked in 2006, Greg recently lamented on his blog that Q3-Q4 saw a serious decline in uniques. I suspect that’s what sparked his introspection.

I stand with those asking Greg to open source his code, or at least produce a well-footnoted, well-referenced book from it.

Here’s the lesson that I draw from Findory compared with, say, digg, memeorandum and memetracker: Context is king.

People say they want personalization, but not in a void. What’s more important than personalization is social context. For news, that means: who’s talking about this story? what are the reactions and additions to this story? do other people like this story? is it a story that crosses social cliques?

And, yes, it also means that what the A-listers write about carries more weight than what, say, I write about (a Z-lister?), regardless of overlapping interests.

As Greg has pointed out previously, personalized search means a smaller shared context among searchers, which is good for fighting spam (in the short-term). But is it bad for searchers? How do you share your search results with somebody else by simply copying the URL?

That problem is magnified with personalized news. Although you may get stories that are really interesting to you, you may just as well get no interesting stories since your interests aren’t generating much worth writing about at the moment. And you’re less likely to engage in a shared cultural experience.

I take note that the good bloggers didn’t use Findory to find interesting things to write about. I don’t think Findory’s bugs and little quirks are the reason for that. I think it’s the lack of social awareness, which suppresses to the social cues we use to find interesting stuff.

Opinions?