Sherfari revisited

Sherfari revisitedJAN 20 2003

In response to my post on building a better browser, several people argued for the Unix approach to software design: build apps that do one thing well.

Q: What is this one thing that a web browser should do well?

A not-so-good answer: Judging from the comments about my post, most experienced browser users & software developers would probably say that a web browser should download and display HTML documents quickly and accurately. In the same way that cameras are designed to transfer real-life scenes to film, that is technically correct and helpful to remember when it comes to implementation.

A better answer: Let's apply the Unix approach so that it makes sense from a user-centered design standpoint rather than at the application level**. Web browsers help people find and share information on the web. Sherfari was an attempt at envisioning a browser that does this better than the current crop of browsers by adding the capability to do a few things that people commonly use the web for. Some cried "bloat", but as long as application features and capabilities are useful and appropriate to an application's function (the "one thing"), there's no bloat.

The web offers so much information and so many opportunities that there is much room for the addition of features to improve the browsing experience without creating a bloated application. With their iLife apps, Apple has demonstrated the restraint and ingenuity necessary to build balanced applications that are powerful without being overwhelming. Let's see them apply that to their web browser.

** Here's what I mean by that. If you were building tools to help people to send and receive email, ham handedly applying the Unix approach solely from an application point of view might result in one app to receive mail (or perhaps two separate apps: one to get IMAP mail and one to POP it), another app to write mail, and yet another to send it. But from a user-centered perspective, one application to do all those things (and more) makes more sense.

There are 29 reader comments

jkottke28 20 2003 9:28PM

More on bloat, using a few of Apple's own applications as examples. I wanted to put this in my post above, but it didn't really fit in anywhere.

Why does iPhoto contain the capabilities to order hardcover books of prints and publish HTML pages of photos? They seem like unnecessary features in an application built for storing and organizing digital photos. But iPhoto's purpose includes sharing digital photos with other people, along with storage and organization. So it makes sense.

iTunes connects to an online service to retrieve song information when a CD is placed in the drive, an unnecessary feature for listening to music. But that feature adds useful context to the listening experience and makes ripping MP3s much easier as well.

If you think of a web browser like Safari as a program to download and display HTML documents quickly and accurately, the history, bookmarks, Rendezvous support, and even the Google search bar are unnecessary. But those things (although the utility of the Rendezvous support remains to be seen) are helpful enough in supporting the primary goal of the application to warrant inclusion in Safari's feature set.

Anil08 20 200311:08PM

If you're going to integrate these applications, then it probably makes more sense to add the intelligence to the searching function. Queries that find results that are appropriate for display as Sherlock channels or NetNewsWire feeds would show up with that UI when results are returned, and anything that didn't come up with intelligble results in those formats would be fed to the usual Google search results page.

Seems that placing the decision of "which context do you want to search in?" on the user is unnecessarily burdensome.

david45 20 200311:45PM

I'm not sure the world is ready. We don't even have a browsers that can render CSS properly without crashing!

The mozilla project is a perfect example of web programmers overloading a browser with features. How many people do you know who read newsgroups in Mozilla, or "ChatZilla?" Bugzilla and the Javascript debugger are useful, but those two features exist almost by accident. It's very difficult to anticipate the next big thing - web services are having their moment, but it's not clear that they're here for good - remember PointCast? Many Mac users I know prefer the (unstable) Chimera, and Linux and Windows people like Phoenix. People just like smaller browsers, that's why Safari is so popular.

It would be nice if there was a stable WebCore that developers could combine with RSS readers and XML parsers (like Watson & Sherlock) into Sherfari-like applications, but it's not ready yet. It's not even as polished as Apple's last browser was, and there's no guarantee it ever will be.

I love the idea of a unified search, but this is something that could be more immediately tackled on the server side. Why can't my.google.com keep track of updates to my favorite pages and RSS feeds, along with a my.yahoo memory like for my favorite movie theaters, a list of vegetarian restaraunts, etc. Since the time to market is much faster for a web site than a client-side app, it would be easier to deploy as well. Watson & Safari are basically fancy skins for LWP / Perl scripts. The idea does make incredible sense, so once you go through a few development cycles,you'll know much better exactly what people want, and by then webcore & NNW will be more easily married and you can produce a client Sherfari. This would be in line with the UNIX philosophy, and bring users the beautiful client service you're envisioning.

Michael Buffington05 21 200312:05AM

Your idea of "the one" is pretty subjective, and would cause me to cry bloat. I love Safari's simplicity - it does exactly what I want a web browser to do: render HTML quickly and accurately (ok, so maybe not so accurate all the time). I don't want a browser that does everything including render HTML.

pb11 21 200312:11AM

I still think most of Sherlock could be duplicated in JavaScript/DHTML/etc.

Seperating email into IMAP reading, POP reading, sending, etc. is not a good analogy. The idea is to put the right functions together while keeping the application as small and focused as possible.

I'd agree that the book-making feature of iPhoto doesn't make sense (and could be a web service instead).

Knowing what song/artist/album you are listening to I would say is an important aspect of a music player.

I've seen requests for history to be removed (I never use it myself) but I'm not sure how it would work as a standalone app. Bookmark management in browsers has always been somewhat silly and never much better than if bookmarks were simply handled in the file manager. I hid the bookmark menu immediately.

I'm slightly disappointed that the Google thing is currently hard-coded. I think a better thing to do would be a customizable set of search forms (and not just "search"). That would be a better use of the drop-down than "history".

The biggest problem with Sherfari is that there's little agreement on even if Sherlock itself is useful. Even something like mail, that is obviously useful, is seen as a bad add-on to a browser.

And as everyone is all too familiar, the synonym for bloated-browser is Mozilla.

david26 21 200312:26AM

If you think of a web browser like Safari as a program to download and display HTML documents quickly and accurately, the history, bookmarks, Rendezvous support, and even the Google search bar are unnecessary. But those things (although the utility of the Rendezvous support remains to be seen) are helpful enough in supporting the primary goal of the application to warrant inclusion in Safari's feature set.

I agree with this - and I think Rendezvous is the most useful of the bunch. Imagine you're developing a web site with a group of other people. Instead of trying to figure out 10.1.5.which is the IP of your friend's computer, you can just look at their mockups/dev environment using rendezvous.

And their inclusion isn't necessarily counter to "the Unix Philosophy," since those are all smaller pieces of code (esp. Rendezvous) which have been pulled together by the Safari application to complete a larger set of tasks.

tomas56 21 2003 1:56AM

pb said: The biggest problem with Sherfari is that there's little agreement on even if Sherlock itself is useful.

This is exactly why I had a negative initial reaction to Jason's concept of merging Safari and Sherlock/Net News Wire. My pattern with both of those apps was to use them for a couple of weeks then realize that I could get things done a lot more efficiently just by staying in my browser.

But my primary reasons for abandoning those apps would be mooted by the "Sherfari" model:

1) I don't like opening another application (Sherlock) to do something which a currently open application (Safari) is capable of doing faster (especially if you factor in launch time and "channel" load time).

2) I don't like the way a task in Sherlock is inevitably broken up across applications (for example, I find a movie in Sherlock but have to jump to my browser to buy the ticket).

So yeah, I think the concept of having Sherlock- and Net News Wire-type functionality built into Safari is solid from a user-centered design standpoint. But plopping those applications' interfaces into a Safari window is obviously the wrong approach. A more subtle merging of, for example, some of Net News Wire's functionality into Safari's bookmarks organizer might be fruitful.

Thomas Mertz30 21 2003 2:30AM

First, I'm not a Mac-user ... I wish a was, but I'm not!

Now, Jason, I completely agree with your viewpoint. It would be excellent with a browser/omni-web-tool ... it would things so much easier.
But what I'd really like to see before any of this, is a 100% standards compliant browser. A browser I can code for without using browser specific hacks, and completely standardized web where I won't need 30+ (exaggeration) stylesheets to ensure that my page is displayed properly in every browser!

AS28 21 2003 5:28AM

David: "How many people do you know who read newsgroups in Mozilla, or "'ChatZilla?'"

Well, I do read news in Mozilla (works quite nicely, thank you), and my girlfriend uses ChatZilla for IRC (although even I fail to understand why she does that :)).

I actually don't see adding e.g. ChatZilla to the Mozilla package as being bloat because you can choose not to install it. Of course it sort of means wasted production resources but hey, you know you can't stop coders from coming up with silly and useless things anyway...

Personally, I actually like the idea of having one program for as many (related) tasks as possible. I understand the point of efficiency but so far Mozilla seems to be fast enough for me.

jkottke41 21 2003 9:41AM

web services are having their moment, but it's not clear that they're here for good

"Web services" as a marketing term is having its moment, but it's fairly clear that web service-like things are here to stay (CDDB has been around forever, for instance).

I don't want a browser that does everything including render HTML.

I feel like I'm talking to myself here. Or not doing a good job in explaining what I'm after. Anyway, at the risk of repeating myself:

"Finding the right balance between useful and bloat is the key here. As Milton Glaser said: 'just enough is more'. I'm not suggesting throwing everything into the browser (iTunes within the browser doesn't make a lot of sense)..."

And I've repeatedly used words and phrases like "careful", "balanced", "a few", "appropriate", and "restraint". How can you say I'm advocating the creation of some ridiculous megabrowser that "does everything"?

Seperating email into IMAP reading, POP reading, sending, etc. is not a good analogy. The idea is to put the right functions together while keeping the application as small and focused as possible.

That's exactly my point. And as Michael noted above, one person's (or company's) idea of "small and focused" is different than someone else's. My opinion is that the browser is currently too small and too focused.

As for the email analogy, your assessment that including all those functions in an email program is subjective as well. Shouldn't writing email be done in a writing application like Word? (Note: just so I'm completely understood here, I don't think writing email should be done in Word. I'm playing the devil's advocate here. Everyone clear on that?)

But plopping [Sherlock's] interfaces into a Safari window is obviously the wrong approach.

Agreed. The mockups were a quick representation of what I was talking about. I wasn't literally suggesting merging Safari and Sherlock.

Maciej Ceglowski27 21 200311:27AM

First, to those posters who say "before talking about feature X, let's get a browser that is actually standards compliant", please think that through. You do not want what you think you want, because so many existing pages would break in it. All the new browsers, Mozilla and Safari included, have had to hack in elaborate compatibility modes to prevent their becoming unusable. You can find a lot of good discussion on this (and other) points at David Hyatt's weblog (and I would love to hear his opinion in this thread.

Unless I'm misunderstanding Jason's argument, he's pointing out that search is a big part of what we use the browser for, so if you are going to build a custom search client (like Sherlock), build it into the browser. Focus on the user experience, make it seamless, and make it fast.

The posters who respond to that with "why not just have Google add custom pages for personal use?", or "let's do this in JavaScript and HTML" should have their email clients taken away from them and be forced to use web-based mail, preferably Outlook. (I'm on dialup, page loads make me bitter).

An analogy, beating the Unix thing to death: Mozilla is a Swiss Army knife with too many pieces. Who really uses the fish scaler all that much? Do we actually need that magnifying glass?

Having search + browser is more like having one of those corkscrews that doubles as a bottle opener. Sure, the two functions are seperable, but it turns out to be really handy to have a bottle opener when you're using a corkscrew. It's a design decision based on watching how people actually use the two tools. In real life, the need to uncork wine bottles tends to correlate with the need to open beer bottles.

From an engineering point of view, you can design the thing so that the bottle-opening component doesn't degrade the corkscrew behavior, and vice versa.

But the impetus comes from observing how people use both, and having the insight to notice that combining them might be a good idea.

Todd Warfel40 21 200312:40PM

Why does iPhoto contain the capabilities to order hardcover books of prints and publish HTML pages of photos? They seem like unnecessary features in an application built for storing and organizing digital photos.

I disagree. iPhoto's core concept is managing images - therefore, organizing, importing, exporting (.jpg, html), creating photo albums, printing, and integration with some type of Web service for printing is within the core concept.

iTunes connects to an online service to retrieve song information when a CD is placed in the drive, an unnecessary feature for listening to music. But that feature adds useful context to the listening experience and makes ripping MP3s much easier as well.

Likewise, iTunes core concept is organizing music -- this includes playing, importing, exporting, shuffling, making playlist, etc.

A Web browser's core concept is finding information on the Web (a vast network) and enabling the user to interact with that information. Therefore, finding information (search), display of the information (HTML, CSS, SWF, etc), interaction (forms, navigation) are appropriate.

By this argument, some of Sherlock's features would be appropriate to integrate into Safari. I wouldn't want bloatware. So, it would be up to Apple to integrate the two w/o creating bloatware.

dclay46 21 200312:46PM

I must agree with the less-is-more faction here. A pc user, I spend the first 20, post-installation minutes stripping everything out of Netscape/IE that I can: "edit" buttons, links to "AOL Instant Messenger" etc. If I was stuck with Sherlock with Safari I wouldn't download the latter--I simply want my browswer to render HTML.

Now the ability to treat Sherlock as a plug-in (preferably downloaded separately) would be great. Extend the functionality of the software for those who desire it. [ In fact, I think any application that uses HTTP should operate through the browswer in a model like the one jason proposed. I get nervous when VB/C applications go online (who knows what they are telling Bill Gates about me). ]

I guess the key is to offer users an uncluttered UI for the software's primary purpose and give more ambitious users the ability to extend it. If we could somehow convert AOL back into an ISP...

Geoffrey Smith32 21 2003 2:32PM

First, to those posters who say "before talking about feature X, let's get a browser that is actually standards compliant", please think that through.

I think they mean a browser that impliments standard markup properly. Safari renders CSS improperly in many ways, and it would seem wiser to focus on those issues first, then worry about extra features like Sherlock.

Michel21 21 2003 3:21PM

I think that a better aproach would be not to extend the browser, but to add some kind of webserver to the OS. That way, you will have as many applications running in your webserver (apps written in C++, PHP, Perl, etc.) as you want, and those applications would serve to as many different purposes as there are developers willing to write them. The browser would still be a tool for accessing web documents, and the other applications (Sherlock, of instance) would become something similar to a local Google.

John Dowdell48 21 2003 3:48PM

Jason, would you want functionality similar to Sherlock within a browser, such as by downloading a regular HTML web page which contains interactivity for stateless retrieval from multiple sources? Or would you prefer that the code be stored client-side, within the source of the viewing application itself? Or does this not matter in your scenario...?

Rephrased, would a Flash application in an HTML page do it for you? Or would you not want to take the hit of re-downloading the code each time?

(I've got further comment in my blog, but realized later that the above question about preferences for where the code lives may get to the root of the issue.)

Regards,
John Dowdell
Macromedia Support

Michael05 21 2003 4:05PM

Tim Bray chimes in with a plea to integrate RSS and browsers.

jason mcgonnell16 21 2003 4:16PM

you know, the "sherfari" idea to me is very similar to the evolution of the wyse winterminal - the thin client started simple enough and now you can get them with hard/disk drives that makes them..well, fat clients. at some point integrating too many things starts the cycle back over again of seperating everything. maybe not the best analogy but, whatever. i'm in agreement with those that don't see the point in the "sherfari" idea.

ry rivard28 21 2003 4:28PM

All the comments, especially the necessary/unnecessary talk, boil down to: Do we want an internet, or do we want an application-specific network.

It seems that just as browsers could do everything, technology (and the people behind it) started moving away from the browser as the user's liaison to the whole internet. This was/is a mistake.

While the upper echelon of programmers can sit around debating how to make RDF work better, I have friends who still have no idea what all 'those little orange X-M-L icons' mean. 'I click on them and it brings up all this...stuff,' they say.

Everyone can benefit from the aggregation of RDF/XML news, but not everyone can (or would be compelled to) give time to learning new interfaces in new applications and, on top of that, using them in tandem with their (X)HTML browser.

The point is not to become lost in esotericism of newness, but to give users the fullest access to the whole internet. Jason's idea does this.

jkottke17 21 2003 5:17PM

Or would you prefer that the code be stored client-side, within the source of the viewing application itself?

Right. The interface and programming logic are stored locally and the only thing that you download each time is the data.

pb20 21 2003 6:20PM

Jason, would you want functionality similar to Sherlock within a browser, such as by downloading a regular HTML web page which contains interactivity for stateless retrieval from multiple sources? Or would you prefer that the code be stored client-side, within the source of the viewing application itself? Or does this not matter in your scenario...?

Rephrased, would a Flash application in an HTML page do it for you? Or would you not want to take the hit of re-downloading the code each time?

This is all or mostly doable with JavaScript and DHTML. Check out http://www.versalent.com/

John Dowdell34 21 2003 6:34PM

Jason, gotcha, thanks -- we're seeking to transfer UI and logic only once, and then to deal with live data feeds after that, understood.

What would you think if Sherlock had a module which browsed among HTML documents? Would that do it for you too, or is it more than you want the browser to be a first-class peer to the application side, rather than just another tool within that set of applications?

(Pat, thanks for the link to Versalent, which advertises JavaScript-based "Rich Internet Applications" (hey, that's Macromedia's term! ;-) I tried to use their demo but they didn't like my Mozilla... they specify "IE/Win only".)

Jim Ray13 21 2003 9:13PM

While I found the Sherfari concept intriguing initially, I still have to agree that it's the wrong way for a web browser to go. I see your point about the Unix-ness (from a user, rather than developer perspective) but what about Mac-ness? After all, Apple shouldn't give up the pioneering user interface and application design they developed just because they're now running Unix under the hood. Beyond the much maligned bloat aspect of a Sherfari browser, it breaks the paradigm of a browser and becomes something much more difficult to use. Rather than a single interface, Sherfari could potentially introduce myriad interfaces that don't necessarily have anything to do with one another. Very un-Mac.

I would like to see Safari push the boundaries of what it means to be a browser, I just don't think that Sherfari is it.

guanyao18 21 2003 9:18PM

Is UNIX the best example of doing one thing and doing it well? Has no one heard of emacs, which is the epitomy of bloat. Sure it does text editing pretty well, but it's also an rpg game, a news reader, and a multitude of other things.

struan22 21 200310:22PM

Is UNIX the best example of doing one thing and doing it well? Has no one heard of emacs, which is the epitomy of bloat.

I think if you look at cat, grep, less, ls and so forth then you see what people mean by the unix philosophy. They all do one thing well but you can tie them together to achieve your goal.

And hey, emacs isn't so much a text editor as a LISP interpreter which by default runs a text editing program.

jkottke32 21 200310:32PM

What would you think if Sherlock had a module which browsed among HTML documents?

John, I get the feeling you're asking all these questions for a reason.... ;)

It's hard to say how all this should be done without doing some user research. I feel that the general get-any-HTML-page browser is the most important element in this hypothetical situation because people will still use it for most of their web browsing. Stuffing into a Sherlock-type interface doesn't seem appropriate.

John Dowdell05 22 2003 7:05PM

Jason! and here I thought it was you who was raising this discussion for a reason...! ;-)

I agree with you on that "user research" angle... I'm still hearing stories about people who navigate in browsers by returning to search engines instead of keeping bookmarks! To make a tool which is broadly useful its intent needs to be checked against how people will naturally tend to use it.

For me, the background info that we're making calls across the network is less important than how people will organize in their own head the work they're doing... I really like how Sherlock is organized around specific tasks people will be accomplishing, rather than by who happens to own a data source. Web pages are a valuable step, but I'd wager they're not the final product of networked intelligence... but then again, I guess we all agree on that anyway, I'm not saying anything new here.... ;-)

Nigel L51 23 2003 2:51AM

Information transfer from the network to me (and, less often, vice versa) is the aim. Intertwingularity wasn't mentioned as such, but certainly is inherent in what many said. A satisfactory way to use RSS and unstructured blog (nodes?) info is increasingly needed. Something akin to automatic buzz indexing on my interests, though how to do it without spying on me is a dilemma. I continue to feel that the style of Mozilla facilitates information presentation -- perhaps why college students are fans.
This topic is an outstanding idea. It reminds me of the B-School case study of the wreck of the Penn Central: they thought they were in the railway biz when in fact their biz was transportation.

pb58 23 200311:58AM

I still contend that most or all of Sherlock could be duplicated in a web interface. Versalent gets all its data in the background. The main page never refreshes. I'm not sure what they use that requires IE. I think IE includes some specialized XML parsing and other tools.

This thread is closed to new comments. Thanks to everyone who responded.