[thelist] Pet Market: SWF proven more efficient.

Thu Jun 20 10:59:01 CDT 2002

Hi,
<----- Original Message -----
<From: "John Dowdell" <jdowdell at macromedia.com>
<http://www.macromedia.com/desdev/mx/blueprint/articles/performance.html
<Howdy, I guess I'm throwing down a gauntlet here... can you pick holes in
<the performance metrics found for this set of web applications? 8)
Just a few comments:

Let's see, some quotes from MM:
"The key value of the Pet Market blueprint application was to show
  developers how to create Rich Internet Applications using Macromedia's
  MX toolset."
- So we can expect this application to be an example of "best practices" -
of how to do e-commerce site's in Flash - right?

"The ability of the Macromedia Flash designer to focus on usability was a
  major breakthrough for the team, because usability testing for the Pet
  Market application took on a much greater role than usual."
"The team took an unusually intensive approach to usability testing. "
Ahh, usability wasn't a priority in the past then... - isn't usability the
nr1 concern for an e-commerce site?

"One instance in particular brought out the wisdom of early usability
  testing.
  The team had originally envisioned a one-stop checkout process, in which
  all of the data entry and other business of checking out would be handled
  on a single screen. But the checkout tested poorly for usability. Said
  Steve Peterson, "The all-in-one checkout process confused people, so
  we threw it away and built something new. "
That's strange, I thought MM were all for one-screen solutions:
"As an example, Macromedia touts the reservations site for the Broadmoor
  Hotel in Colorado Springs, Colo., created with a pre-release version of
  Flash MX. Instead of the typical welter of online forms, the site allows
  prospective customers to check room availability and rates, make a
  reservation and submit credit card data all from the same screen. "
http://reservations.broadmoor.com/ (from the MX press-release)
So it seems MM like one-screen solutions, but the users don't. What's new?
I also wonder how they handle secure connections, when doing a one-screen
checkout process... Is the whole site run over a secure connection then? Or
are the credit card details passed back to the server quickly, before a
hacker can notice the un-encrypted packets...

"We chose to build an online store for a fictional pet retailer "
Not so fictional, they're right here: http://www.petmarket.com/

Let's try the application:
http://examples.macromedia.com/petmarket/flashstore.html

We'll have a look at the page's source:

<HTML>
<HEAD>
 <META http-equiv=Content-Type content="text/html;  charset=ISO-8859-1">
 <TITLE>Pet Market blueprint application</TITLE>
</HEAD>
 <FRAMESET rows="*,0" frameborder="NO" border="0" framespacing="0">
  <FRAME name="mainFrame" src="main.html">
  <FRAME name="_bottom" scrolling="NO" noresize src="subswf.html?
                    mode=home&pageTitle=Home&catOID=&productOID=">
 </FRAMESET>
<NOFRAMES>
 <BODY bgcolor="#FFFFFF" text="#000000">
 </BODY>
</NOFRAMES>
</HTML>

* What is surprising that even in a "blueprint application" they can't even
  be bothered to get such a simple page to validate to even html4.01
  frameset - let alone XHTML. I guess that demonstrates the total disregard
  for any standards other than their own.
  Doesn't do much for Dreamweaver MX's credibility either.
* Maybe someone can point out they should be using &amp; instead of & in
  URLs.
* Search engines. Ahem. Nothing here whatsoever for search engines, bar the
  title.
  Maybe next time "The team can take an unusually intensive approach to
  search-engine placement" as well, as we're talking about a "blueprint
  application"
.
* Framesets. No need to go into the pros and cons of using frames. It boils
down to "use them when you have to, avoid them if possible"
So why is this application embedded in a frame-set? (malformed at that).
Ohh... it's MM's 'solution' to the lack of back-button support... what a
hack!
Back in the early days of dhtml there was many a discussion about loading
content in hidden frames, to avoid re-loading the main document, but I
hadn't expected Flash developers would still be fiddling around with this
hack.
They say:
  "We did some iterations on the server side based on things we discovered
  during client-side development," said Brian Kruse. "The way data got
  pushed back and forth between the client and the server needed to be
  refined a few times."
Ok, so using the frame-set-hack is the "refined" version of Flash's
client-server interaction... what progress! Or maybe the frame-set thing
is just being used for the back-button...
It worked! They got Jakob Nielsen to think something was
dramatically new in the way Flash MX handles(doesn't) the backbutton.
He enthusiastically writes::
"Back button works. In my comments on designs implemented in earlier
  generations of Flash, I have been highly critical of the way they break
  the  Back button in the browser. Past annoyances make it that much
  sweeter to find that the Back button does work in Pet Market. In fact,
  if you want just a single argument for upgrading to Flash MX for your
  projects, Back-button support is it. "
So they got Jacob to think they actually did something about the back-
button, while all they did was embed the page in a frameset.
And he hates frame-sets - of the irony!
He obviously only tested IE5.5 or IE6 as other browsers don't link the
back-button to framesets anyway.

* What's being used for client-server communication? check the source:
  http://examples.macromedia.com/petmarket/subswf.html
  So this is what MM needs to use to get Flash-only webcontent? an
  html/javascript proxy?
Why not just use Flash's built-in XML object for  loading data from the
server? Or maybe they are... It looks to me like this is only being used
to allow the back-button to function in IE5+. If that is so, why don't they
do all this in an IFrame, as non IFrame browsers don't support the back-
button-hack anyway?

Another fun Nielsen quote:
"In defense of the designers of Pet Market, I recognize that they were
only creating a demo application and did not have the budget to handle
all the design details that are necessary to construct a real e-commerce
site. "Give us a few millions in venture capital, and we can definitely
build out the design," I hear them say. Fair enough, but it's still my
duty to point out that Pet Market violates many of the guidelines
for e-commerce usability. If it were a real site, it wouldn't sell very
many pets without fixing these problems."

Someone should inform those MM designers that the internet
bubble has burst.
People don't spend millions on an online petstore websites
anymore - at least I hope not, and if it takes that much to get this
thing working,there must be something seriously wrong with it!

While using the site I notice the long wait at
load time - where most websites are rendered and ready to go, this
one is still loading away...
The problem isn't even just the amount to be loaded (173k here) but
the way it's loaded - i.e. the elements are loaded one by one, so you
have to wait for the whole list to be completed before you can go.
Even when everything is in cache.

The design is nice though.

Cheers,
Richard.