Fog Creek Software
Discussion Board




The Story Behind Yahoo Stores

Since Joel is dissing Yahoo stores on the front page of www.joelonsoftware.com, I thought I would link to the very interesting backstory behind Yahoo Stores:

It was started by Robert T. Morris (of the morris worm fame) and Paul Graham and the store generation tool was written in LISP. 

Paul has written about the experience in some depth:

http://www.paulgraham.com/avg.html

Its a fun story.

Carl Coryell-Martin
Monday, December 17, 2001

It doesn't surprise me that the same guy who is trying to design a language "for good programmers" is responsible for Yahoo Stores.

http://www.paulgraham.com/arcll1.html

His basic thesis, which goes against everything I believe in, is that it's a good idea to rely on the brains of your users instead of making things easy to use in the first place.

Paul writes:

"In some ways it makes the problem easier when you can assume the user is a good programmer. Language designers often find themselves worrying about the mess users might make if they were allowed to do such-and-such. Once you assume the user is a good programmer, you automatically have the answer to any such question: let the user do whatever he wants."

So, for the benefit of one language designer, make the entire programming community work harder. This concept is so thoroughly wrong-headed I don't even know where to begin. If Paul Graham were designing the security for an operating system, he would say, "assume a smart system administrator. Then you never have to worry about whether the default settings are secure."

Joel Spolsky
Monday, December 17, 2001

I hope the point of the story isn't that the programmers assigned to extend the Stores couldn't figure out how to deal with Lisp, and so resorted to sad hacks. :-)

Richard Jenkins
Monday, December 17, 2001

Are you sure that Graham is actually saying what you think he's saying?

Can you imagine a language feature that would make a language easier to use for people who've already mastered the language, but would make the language harder to learn?

How about a language feature that would make a language easier to use for people who know what they're doing, but would be dangerous for people who don't know what they're doing?

If you were designing a language for people who learn quickly and know what they're doing, would you add features like that?

Adam Spitz
Tuesday, December 18, 2001

The design of new languages aside, nothing beats the usability of Yahoo! Store, and Paul Graham can likely take a lot of the credit for that.

I'm usability obsessed (yes, I have Joel's book) and I am very familiar with Yahoo! Store and it's tour (I've set up several Yahoo! Stores).

Here's what Paul Graham, one of the creators of Yahoo! Store, says about the feature Joel is criticizing...
"The test drive was the way we got nearly all our new users. I think it will be the same for most Web-based applications. If users can get through a test drive successfully, they'll like the product. If they get confused or bored, they won't. So anything we could do to get more people through the test drive would increase our growth rate.

I studied click trails of people taking the test drive and found that at a certain step they would get confused and click on the browser's Back button. (If you try writing Web-based applications, you'll find that the Back button becomes one of your most interesting philosophical problems.) So I added a message at that point, telling users that they were nearly finished, and reminding them not to click on the Back button."

This quote is from http://paulgraham.com/road.html.

Yahoo! now also includes that message at the start of the tour, which is where you saw it and pointed out that people will likely ignore it.

The Yahoo! Store tour is the best intro I've ever seen to this type of product.  Fogbugz is easy to set up, but a Yahoo! Store is even easier - I've done both, several times for the latter.

The point Joel makes isn't quite as useful in this case, because of the nature of the task.  Deciding to set up an online store isn't the same as getting a Hotmail account, so most users who are serious about the product will actually read the screen.  In fact, as I recall from my first store, they are probably holding their breath and reading every word three times.

As you can see from the Graham's description of the problem, the "bad usability" is just an average crummy compromise that programmers have to make to get their product released, and like he says, the Back button is a prickly one.

Byron Fast
Tuesday, December 18, 2001

Despite what Paul Graham says, it's still stupid to mess with the normal functioning of the browser's back button.  I like my back button -- it's very useful, and I get upset when someone causes the button to behave in a non-standard way.  Bleh.

Caveat emptor
Tuesday, December 18, 2001

There is a difference between a dumbed-down language feature that helps beginners at the expense of experienced programmers, and a useful language feature that helps everyone.

Java did not include multiple inheritance because the designers deemed it too confusing for novices. I believe there are plenty of experienced programmers out there who resent this decision.

However, I doubt anyone would advocate removing type-checking. It's a valuable safety net that helps all programmers, and rarely gets in the way.

Actually, some are critical of Java because it doesn't provide a way for knowledgable programmers to "break" the type system, e.g. with casts! (see Jamie Zawinsky's essay "Java sucks")

Dan Maas
Tuesday, December 18, 2001

When you are browsing a static site it's
obvious what Back does, but in a Web-based
app, there is no general solution to what
the Back button should mean.  Suppose you
edit some object, then save it, then
delete it.  Then you click on Back a couple
times till you get to the page where you
were editing the object.  What should this
mean?  Should Back be Undo?  That could
be terribly confusing in some cases, and
even cause people to lose data.

I don't know of *any* Web-based app where
you can create and delete things and where
Back works consistently.  It doesn't work
in Yahoo Mail for example.

We probably spent weeks, in the aggregate, thinking about what to do about the Back button.  If there is a good general answer
to the problem, Joel should tell us what
it is, and then he can diss us for not
thinking of it.

As for Arc, I think you actually get a
better language if you design for smart
programmers.  Designed for smart
programmers: C, Smalltalk, Lisp.  Designed
for "average" programmers: Cobol, Pascal,
Java.  See a pattern here?

Paul Graham
Tuesday, December 18, 2001

Wow. I wonder how many superstar is visiting JoelOnSoftware everyday!

I think Joel's point is sound and clear. User just won't read the text!
It's funny for the past couple of days where our group is discussing the latest functional spec. that we prepared - everyone is pointing finger at the screen layout criticizing the design. A lot of their arguments are not valid because they have been covered in the text below. No one is paying attention to the detailed description below each screen.

See, even programmers don't read the text written by their peers.

As to Paul's argument - Yes, we just can't deal with the back button in some cases. My previous employer insisted to add web GUI for all of our products (video editing, presentation editing, etc.) even though a lot of these don’t make much sense using plain'o html (we were forced to design half-assed web interface that needs to be compatible with NS4)

Well, it's an indication that the task at hand is not a good candidate for a HTML app. I guess it's okay to use other alternative (e.g. flash) for the tour. A little more work you can detect whether the client has flash installed and fall back to the not-so-perfect HTML solution if needed.

BTW, I totally agree with Paul regarding language design. A lot of people argue that C# is just Java with extra syntactic sugar (get set properties, for example). Well, it has its value, it enables programmer to express the idea more precisely and the result is easier to follow, maintain and use.

Mac
Tuesday, December 18, 2001

Looking beyond the Failure of the Back Button, Michael (who is building our store right now) reports that overall, Yahoo Stores has proven to be quite easy to use.

Programming languages. Even "good programmers" are humans, and even skillful humans are more successful when tools are easier to use. It's the same reason that everybody loves OXO tools even though they are designed for people with arthritis. And even sophisticated programmers like Fog Creek's find Yahoo Stores easy to use, even though it was designed for people who carve tiki-dolls in their garage and don't know the first thing about programming. If Paul had decided that he was creating Yahoo Stores for "smart people," it just wouldn't have been successful. And yes, this means that programmers and designers have to work harder, MUCH harder, even to make things a tiny bit easier for users. You may not have a general solution to the back button, you may need to use a specific solution to the back button (although frankly there are hundreds of signup and tour systems on the web with multiple pages that survive Back just fine, mainly because some programmers worked hard).

BUT, I'm very glad that people are still challenging the assumptions language designers make. It's important to get these language mutations out there and let them compete on their merits.

Joel Spolsky
Tuesday, December 18, 2001

On the state of the back button:

This is just my personal (biased) opinion, but I think that as web apps get smarter, back may come full circle from meaning "previous" through "undefined" to finally meaning "kill -9". Oboviously, we've got a way to go before web apps get powerful enough to justify that kind of cataclysmic behaviour from a previously innocuious action.

Once application state can start to be maintained on a page (without constant refereshing), then perhaps the intractable back-button problem might become a bit more transparent. The real problem then becomes transmitting app state back to the server for "pickleing" either often enough so as not to completely loose the user expereience, or when the app "unloads".

I guess it's really a question of how much interface work you are proposing to do in a single page.

--
Alex Russell
http://netWindows.org

Alex Russell
Tuesday, December 18, 2001

I think the whole back button problem just proves the ultimate argument that a web browser is not suited to building applications.

Heres something I find very curious:

http://www.paulgraham.com/avg.html

The full article is provided in a number of formats, such as PDF and Postscript but not html.

It all seems rather strange that a browser can be considered the best medium for building online stores, but not for displaying text.  For that we need a separate application installed.

Ged Byrne
Wednesday, December 19, 2001

re: Ged Byrne

Hit the ASCII version.  Just plain text.  Maybe a fun, 'leet way to say, "Plain text."

Anon
Wednesday, December 19, 2001

Does anyone know what web server Viaweb used? CLISP over CGI? What database? Where they store session state?

anon
Wednesday, December 19, 2001

<Yes, we just can't deal with the back button in some cases.  ... Well, it's an indication that the task at hand is not a good candidate for a HTML app. >

I can't really agree with that.  While it's certainly true the too many apps that would have been better as standalone have been shoehorned into the browser interface, there are applications that are well suited for browser interfaces yet still have problems with Back.

Example: the company I work for sells an application for corporate financial analysis. The system administrators prepare the data using a desktop app, but the managers access the data using their browsers.  They can analyze it six ways from Sunday, prepare graphs, the whole schmeer; the sysadmins love it because they have no software to deploy, and the managers love it because they can get to their data from anywhere.  It all works great.

Except for the Back button. The guys who implemented the web interface spent a bunch of time trying to figure a way to make Back work that way it's SUPPOSED to, i.e., to recreate the previous screen. It just didn't work because Back was designed for simple HTML, which this ain't.  They ended up putting Previous/Next buttons in the page because they could control what these do, unlike Back. But of course, users continue to hit Back and complain.

Another poster said that it's stupid to "mess with the normal functioning of the browser's back button." But that's not what's happening--the programmers are just trying to work around the fact that in some cases Back doesn't do what it's supposed to do, i.e., restore the previous screen. So they're not "messing" with it, they're trying to work around the fact that Back does NOT always do what users expect.

Chris Dunford
Wednesday, December 19, 2001

So, the back button can do one of three things: 
1) Resubit the form the user is backing into
2) Display again from cache w/ form fields intact
3) Same as #2, except w/out form fields intact

Is this true?  Then it's just a matter of making sure the app works under these three scenarios.

Are there more scenarios?

anonymous
Wednesday, December 19, 2001

<Are there more scenarios?>

Sure.  Why are you assuming it's a form?  It could be a display locally generated by a Java applet or whatever.

Suppose you're playing a Java game of Hangman in the browser.  How would you get each Back click to return to the previous step of the game?

Chris Dunford
Wednesday, December 19, 2001

Chris Dunford:

Well, I do know Java applets (unlike web design), and there is no scenario to make them work if you you press Back.  However, I know Yahoo Stores doesn't use them, because that would be atrocious design.

If you really need to use such things, you can use Javascript to popup a window without back buttons.

However, given various assumptions, there could be a reasonable, consistent action taken under all but the most impossible scenarios.

I don't even assume we're using forms, really.  Any request/response model should work, even with some variations by different browsers.  How complex can it get?

anonymous
Wednesday, December 19, 2001

Actually, what am I saying?  If the applet is in constant communication with home base, the applet can startup from a reasonable position once the user realizes that hitting back is a no-no.  It degrades gracefully, even with security issues.

anonymous
Wednesday, December 19, 2001

<If the applet is in constant communication with home base, the applet can startup from a reasonable position once the user realizes that hitting back is a no-no. >

I'm not sure I follow.  In the Hangman example, Back probably takes him back to the start screen, even if he's performed dozens of moves.  There's no way to stop it (that we know of), and no way to step back one step at a time without adding a separate Back button (which we call Previous) to the main window.  The Back button does what it does, and we don't control it.  Basically, the user loses whatever work he's done.

Yes, we could get rid of the toolbar, but that's not very friendly either.

My basic point is that there -are- some cases where the Back button is very bad for the user, and there's no reasonable way around it (again, that we know of). I admire Joel and his writings very much, but I do think that his statement that most decent programmers "can always figure out how to design an interaction that won't fail if you hit back or reload" casts too wide a net.  That may be true for forms and such, but there are cases where it's difficult to impossible.

I have to agree with Paul Graham on this one.  Like him, we spent weeks thinking about what to do with the Back button and, like him, we did not come up with a good answer.

Chris Dunford
Wednesday, December 19, 2001

Keep in mind that in 1995, when Viaweb was started, most Web users probably didn't have browsers with JavaScript, Java, or anything else that makes Web applications a bit more flexible.  Judging from the graph on http://www.useit.com/alertbox/980322.html , the number of Netscape 2 browsers in use didn't overtake Netscape 1 until February 1996, and Netscape 3 didn't overtake Netscape 2 until August 1996, and Netscape 4 didn't overtake Netscape 3 until sometime in 1998.  Even in January 1997, there were more Netscape 2 users than Netscape 4 users.

Seth Gordon
Wednesday, December 19, 2001

While Netscape users have been slow to upgrade, Microsoft has been very successful in getting users to upgrade. Defying Neilsen's predictions, it took only 9 months for IE5.x to become the leading browser. I suspect IE6 will ramp up as quickly; many resources suggest it already has ~20% market share.

Dave Rothgery
Thursday, December 20, 2001

To be cynical, I think Netscape users were afraid to upgrade to the increasingly bloated and buggy versions of the Netscape browsers. IE was getting faster and more standards compliant.

Of course, Microsoft has the advantage that it can bundle IE with Windows. IE was much more componetized than Netscape, so Microsoft was able to do huge deals like become AOL's browser. Even after purchasing Netscape, AOL still uses the IE browser.

cop
Thursday, December 20, 2001

Microsoft didn't just bundle IE with Windows. They bundled IE with darn near everything they shipped. New versions of Office. New versions of Visual Studio. Service packs for existing software.

The only way I can figure that anyone is still using IE4 (and somehow 4-5% my users are!) is that they haven't installed any Microsoft software since then.

Not that I'm compaining, mind you.

Dave Rothgery
Thursday, December 20, 2001

<b>Do not use HTML tags. Surround URLs with spaces.</b>

Sorry, could resist

:-)

= tmk =

tmk
Sunday, December 23, 2001

With respect to designing a development tool for experienced and/or talented programmers, Joel and Paul are clearly of the same mind, even if they want to debate whether Lisp is such a tool.

Anyone who reads Joels writings on setting up a software company can see he wastes no time pandering to the "average" programmer. In fact, he boasts that he doesn't hire them in the first place.

Love and Kisses ;-)

http://www.braithwaite-lee.com/

Reginald Braithwaite-Lee
Wednesday, December 26, 2001

I was doing a search on Yahoo! Stores, and found a link to this article and all the comments made about the whole "ease of use" and programming issue. 

After reading a lot of the posts here about the "Back Button" and all of it's problems, I'll tell you what I do to get around it.

My designs are developed so that the user ISN'T using the
actual browser buttons. 

I find that developing an interface that is clear, clean, and self explanitory should allow the user to do what it is they want within the specs of the design.  When I go to meet with my clients, and ask them about how they want their site to look, I usually get  one of these answers:

1. "Well, we really don't have an idea, we were hoping you would help us with that too..."

2. "This is our competitor's site, and we like this, this, and this too, but we need it to look BETTER than they have it... Can you do that, or how can we cost-effectively "beat them"? "

3. "This is our current site, put together by some of our UNIX guys... they know that HTML-stuff.... We need it to look better than this..."

Follow any of these up with "and it's got to look PROFESSIONAL", and you have a typical scenerio of what I (as well as others) go through to make a web site, look and function the way a user would think it should.

Now, how does this relate to the "Back Button" issue? Easy, Spend the time to develop the interface in such a way to not have to need to even use it.  Here's an example I see in lot of other designs:

WEB PAGE BUTTONS LABELED "BACK"

These are great, but missing a key element.  WHERE ARE THEY "BACK"-ING TO??  This kind of button needs a description on WHERE the user is backing to, maybe even a JavaScript alert with a further description as to the outcomes of clicking "OK" to continue "BACK"-ING?  This just seems like a more complete thought than just writing "BACK" on a button.

There are some cases, where it's understood that the "BACK" button on a web page will do what the user thinks it will do, and that's the grey area (I think it is anyway), and that's based on the CONTEXT on where that BACK button goes.  Please let me know if I've lost any of you? Thanks.

But the BROWSER BACK BUTTON, is yes, unpredictable in a lot of ways.  But, like I've mentioned above, if the design is THOUGHT OUT, as well as beta tested, and given to people to test outside the realm of the creators of it, then I think we'd all be looking at something else to worry about.

Then, throw the fact that the pages are generated DYNAMICALLY, and now you have the uncertainty of where that back button goes. Someone posted earlier, that there's a usual list of things that could be associated with this like re-sending form data, or clearing all the fields and having the user re-type all that info in again or whatever , amongst other things.  That is a realm I can say first hand, I have not had the pleasure of dealing with, but as I learn PHP, I see that I'm going to have to deal with this as well.

But, I still think that the interfaces, their meaning, and their functions should be extensively thought out. And when a button that has a larger reprocussion than just re-displaying a static page, that there should be an alert, a warning, SOMETHING to let the user at the key know what's going to happen. I still think that some of this problem is due to ASSUMPTION.  Assumption that everyone is going to understand what everything in an interface does. 

I think that if we take more time to REALLY look at how we as humans think when it comes to making decisions and relate it to things we see and do on a daily basis, then relay that to the users who use our sites, software, apps, games, and whathaveyou, we'd be heading in the right direction.

Did you know, that McDonald's had at one time used (or considered using) a cash register, that had pictures of the food  we buy from them, because a growing number of employees that were working there were having trouble figuring out how to calculate what the customer ordered?  Ever see all those little color-coded buttons on a register at McDonalds?  Take a look, or ask someone you know who works or worked there...
most people have complained that trying to remember all the functions and operations while the customers are giving their order was difficult.  But that picture based would (or could) have sped up the order taking process.

What thwarted that cash register from being used? The fact that someone felt it was targeting those who had no education or couldn't read or write, but understood visuals easier.

I have taken a look at a lot of different e-commerce stores, and I think that the Yahoo! Stores should be a but more friendly in letting people who design their own websites use their services.  A few people I know who've had clients who specifically wanted Yahoo!'s Storefront backend, AND a custom designed  site (which my friend was designing) found that they could NOT have both.  The e-commerce pages were un-modifyable at that time.  Has this changed?  I hope so, because I've got a client who's asking a similar question.  I've e-mailed Yahoo! on this, and gotten no reply yet.

Any other web designers come across these snafus? E-mail me, please?  Thanks.  Ciao.

Brian K. James
Tuesday, October 07, 2003

*  Recent Topics

*  Fog Creek Home