web design

4 May 2004 - 12:02pm
10 years ago
46 replies
690 reads
Dave Collins
2004

Can anyone point me at a (recent) discourse on the merits of framed vs.
unframed web site design? (Can't believe I'm having to justify this...)

Thanks.

Dave Collins
User Interface Design
Phoenix Interactive
300 Wellington Street
London ON, N6B 3P2
V: 519.679.2913 x292
F: 519.679.6773
E: dcollins at phoenix-interactive.com
<mailto:dcollins at phoenix-interactive.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.dreamhost.com/pipermail/discuss-interactiondesigners.com/attachments/20040504/cb7839ba/attachment.html

Comments

4 May 2004 - 12:27pm
Frank Elley
2004

Can't help with the "design" issue -- I'm sure others will have excellent
resources.

However, I have run into particular, business-driven uses for frames in
syndicating content. It may or may not have anything to do with why you're
asking. But I thought you might be interested, because I was quite taken
aback to find out how common this is. Examples:

-- Small travel agency acts as a reseller for packages offered by a tour
company. The tour company has organized their site so that their tour
catalog appears in a separate frame. The small agency can integrate the tour
company's offerings easily on their site.

-- I've seen this sort of "lightweight syndication" technique used for
software VARs as well. The software VAR -- usually *not* a web-savvy company
-- has created their own web site consisting mostly, or even exclusively, of
the OEM company's site, but adding their own top navigation frame. I saw an
OEM even create a "web site generator" that allowed partners to plug in
their top banner, and it would generate source for their site as a reseller.

You can argue all you want that these designs have conceptual and technical
flaws. You can argue that better solutions exist. What you can't argue is
that these companies' businesses depend heavily on this kludged use of
frames. Even if you as the OEM (the syndicator of content) can propose a
better solution, how can you drag all your partners into compliance without
threatening to put them out of business if they don't comply? How can you
keep them from defecting to a competitor who makes it "easy" for them to
syndicate their content? Or as a partner, how can you justify not using
frames if the only option your OEM provides is the framed solution? There
will be a long period of transition as OEMs offer better syndication
solutions as *alternatives* while they encourage their partners to eat
higher up the technological food chain.

I have encountered this primarily in non-US markets, particularly Asia. I
can certainly understand how it happened, but it's an interesting and mildly
depressing example of how a bad idea gets adopted and perpetuated.

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com]On Behalf Of Dave Collins
Sent: May 04, 2004 10:03 AM
To: discuss at interactiondesigners.com
Subject: [ID Discuss] web design

Can anyone point me at a (recent) discourse on the merits of framed vs.
unframed web site design? (Can't believe I'm having to justify this...)

Thanks.

Dave Collins
User Interface Design
Phoenix Interactive
300 Wellington Street
London ON, N6B 3P2
V: 519.679.2913 x292
F: 519.679.6773
E: <mailto:dcollins at phoenix-interactive.com>
dcollins at phoenix-interactive.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.dreamhost.com/pipermail/discuss-interactiondesigners.com/attachments/20040504/bea8551c/attachment.html

4 May 2004 - 12:42pm
Dave Malouf
2005

Frames, are not usable b/c they are a poor hack into the HTML spec.
What was really attempted were "panes". That is a space on a screen that
scrolls internal to the window.
It also affords the ability to having objects on a page NOT scroll while
other spaces do scroll.

using XHTML frames are just plain obsolete and ugly. There are better ways
to achieve the same effects AND they degrade a lot more gracefully.

e.g. you can put content into a <div> layer and set it to "overflow" (adding
scrollbars when necessary). It's "box" will scroll while the rest of the
page doesn't. This sorta mimicks the <iframe> model but works in xHTML
compliant browsers. For browsers that don't accept this CSS style well you
end up w/ a normal page.

The reasons that frames don't work:
1. harder on searchengines
2. bookmarking becomes difficult
3. calculating frame sizes isn't x-browser equal
4. frames the way implemented in the HTML does not map to user expectations
in terms of scrollbar layout and what not.

The reason to use frames? hmmm? Can't think of any.

-- dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.dreamhost.com/pipermail/discuss-interactiondesigners.com/attachments/20040504/cd46b9f5/attachment.html

4 May 2004 - 2:22pm
Craig Oshima
2004

> Frames, are not usable b/c they are a poor hack into the HTML spec.

I agree with everything you level against frames. I don't like them
either. However, you go on to ask:

> The reason to use frames? hmmm? Can't think of any.

There are two reasons I can think of that warrant consideration *in
certain circumstances*. Both are more applicable to web applications,
rather than the typical web page. Notably, they're also raised for
practical implementation reasons rather than design reasons (as I said,
I agree there's no good "design" reason to use frames):

1. You need to keep substantial or complex data persistent across
multiple pages. You could embed this data in the URL (ugly) or store it
in a cookie (not guaranteed to be enabled), but a hidden frame is
another option. It has more flexibility, fewer limitations, and avoids
having to pass the data back and forth repeatedly across the wire. If
you have server-side functionality (ASP, PHP, JSP, etc.), then this is a
better way to

2. You need to communicate back to the server, but for whatever reason,
you don't want to reload the entire page. Amazon did this some time
back with their "Earn a nickel" thing where you answered questions about
their site and get nickels that get applied as discounts to your
purchases. By using a hidden frame, you can submit form posts (and
examine the response) without having the whole page reload.

--
Craig Oshima
coshima at acm.org

5 May 2004 - 4:42am
Michael Bartlett
2004

> The reasons that frames don't work:
> 1. harder on searchengines
> 2. bookmarking becomes difficult

The problem obviously with frames is that bookmarks will bookmark the entire
frameset (because that's what's in location.href) and search engines will
not restore the original layout as they've indexed the page and not it's
parent frameset. So you need to be able to:
a) keep some sort of reference to the page in the frameset so that the
frameset can load the page independently
b) allow the page to restore the frameset

Now the reason for this is badly implemented frames! It's a little more
complicated, but effectively you need to do something like this:

frameset.html
<frame src="left_menu.html" name="menuframe" dimensions blah blah>
<frame src="welcome.html" name="contentframe" blah blah>

then say you have a link in welcome.html to about.html:

about.html
<body onload=javascript:bookmarkcheater();>

<script>

function bookmarkcheater()
{
if (document.location == top.location) then
{

window.location.href="www.mysite.com/frameset.html?page='about.html'
}
else
{

window.location.href="www.mysite.com/frameset.html?page='about.html'
}
if

}
</script>

You will then need a piece of javascript in frameset.html that reads in the
value for passthru variable "page" and then populate frame[1].src with
"about.html". It's all a lot easier in PHP/ASP when you can have generic
functions and variables to pass across than explicitly manage them in a
hard-coded fashion like I've done in this example.

Disclaimer: if it doesn't work think about the concept and implement it
yourself - it's been years since I coded anything in any sort of production
capacity!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.dreamhost.com/pipermail/discuss-interactiondesigners.com/attachments/20040505/278c7298/attachment.html

5 May 2004 - 5:14am
Michael Bartlett
2004

Ooops, cut and paste went horribly wrong at the bottom and I've closed
HomeSite now, but I'm sure you get the general idea.

_____

From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of Michael Bartlett
Sent: 05 May 2004 10:43
To: discuss at interactiondesigners.com
Subject: RE: [ID Discuss] web design

> The reasons that frames don't work:
> 1. harder on searchengines
> 2. bookmarking becomes difficult

The problem obviously with frames is that bookmarks will bookmark the entire
frameset (because that's what's in location.href) and search engines will
not restore the original layout as they've indexed the page and not it's
parent frameset. So you need to be able to:
a) keep some sort of reference to the page in the frameset so that the
frameset can load the page independently
b) allow the page to restore the frameset

Now the reason for this is badly implemented frames! It's a little more
complicated, but effectively you need to do something like this:

frameset.html
<frame src="left_menu.html" name="menuframe" dimensions blah blah>
<frame src="welcome.html" name="contentframe" blah blah>

then say you have a link in welcome.html to about.html:

about.html
<body onload=javascript:bookmarkcheater();>

<script>

function bookmarkcheater()
{
if (document.location == top.location) then
{

window.location.href="www.mysite.com/frameset.html?page='about.html'
}
else
{

window.location.href="www.mysite.com/frameset.html?page='about.html'
}
if

}
</script>

You will then need a piece of javascript in frameset.html that reads in the
value for passthru variable "page" and then populate frame[1].src with
"about.html". It's all a lot easier in PHP/ASP when you can have generic
functions and variables to pass across than explicitly manage them in a
hard-coded fashion like I've done in this example.

Disclaimer: if it doesn't work think about the concept and implement it
yourself - it's been years since I coded anything in any sort of production
capacity!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.dreamhost.com/pipermail/discuss-interactiondesigners.com/attachments/20040505/74eb6024/attachment.html

5 May 2004 - 12:18pm
sandeepblues
2003

Consider the following specific scenario, and tell me
why frames would be bad to use here:

I have a Web Application. One of the pages is
dynamically generated report of inventory in a
manufacturing facility, and a bar chart. This page
also has an edit button at the top. When the user
presses the edit button, the page maximizes, and
displays another frame to the right of the previous
chart-view.

This frame has extensive configuration options to
allow the user to customize their chart-view. This
frame has a Preview button that allows the user to see
the customizations in-place in the left frame. WHen
the user presses the Finish button, the frame
vanishes, and the window resizes itself to fit the
contents of the chart etc.

While one could use div's I guess, what are the
problems with this approach? It simplifies the
development, and the edit button doesn't cause a
reload.

I will add the assumption that no user will want to
bookmark this page. It is a WebApp, so any search
engine will have to be home-grown. The scroll-bar
layout is so bad...there are just 2 frames: left and
right.

Sandeep

--- David Heller <dave at interactiondesigners.com>
wrote:
> Frames, are not usable b/c they are a poor hack into
> the HTML spec.
> What was really attempted were "panes". That is a
> space on a screen that
> scrolls internal to the window.
> It also affords the ability to having objects on a
> page NOT scroll while
> other spaces do scroll.
>
> using XHTML frames are just plain obsolete and ugly.
> There are better ways
> to achieve the same effects AND they degrade a lot
> more gracefully.
>
> e.g. you can put content into a <div> layer and set
> it to "overflow" (adding
> scrollbars when necessary). It's "box" will scroll
> while the rest of the
> page doesn't. This sorta mimicks the <iframe> model
> but works in xHTML
> compliant browsers. For browsers that don't accept
> this CSS style well you
> end up w/ a normal page.
>
> The reasons that frames don't work:
> 1. harder on searchengines
> 2. bookmarking becomes difficult
> 3. calculating frame sizes isn't x-browser equal
> 4. frames the way implemented in the HTML does not
> map to user expectations
> in terms of scrollbar layout and what not.
>
> The reason to use frames? hmmm? Can't think of any.
>
> -- dave
> > _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members
> get announcements already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/

5 May 2004 - 12:23pm
Dave Collins
2004

>Consider the following specific scenario, and tell me
why frames would be bad to use here:

You describe a layout that is the reason frames were invented in the
first place. It is an excellent example of a place where frames are an
ideal solution.

Like Flash, frames have their place. It's the 95% instance of abuse that
causes the pretty much unilateral condemnation.

Dave

5 May 2004 - 1:38pm
Dave Malouf
2005

Sandeep ...
What are the long term viability & scalability issues here?
how will it grow over time?
What about backbutton use?

But those issues aside. Maybe it is a great implementation. In the end "it
depends".

I would put frames as a last resort thing in my designs, but I'm sure I can
come up w/ many examples like the one below where it can make sense. Frames
though do not fit w/ semantic xHTML coding, is harder to incorporate w/ XML
based widget building and the like.

The other pro- for frames is that it is easy to learn HTML. The JavaScript
is just as tough either way for the basic stuff and if that is all you need,
why learn anything else?

-- dave

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of Sandeep Jain
Sent: Wednesday, May 05, 2004 1:19 PM
To: id-discuss
Subject: RE: [ID Discuss] web design

Consider the following specific scenario, and tell me why frames would be
bad to use here:

I have a Web Application. One of the pages is dynamically generated report
of inventory in a manufacturing facility, and a bar chart. This page also
has an edit button at the top. When the user presses the edit button, the
page maximizes, and displays another frame to the right of the previous
chart-view.

This frame has extensive configuration options to allow the user to
customize their chart-view. This frame has a Preview button that allows the
user to see the customizations in-place in the left frame. WHen the user
presses the Finish button, the frame vanishes, and the window resizes itself
to fit the contents of the chart etc.

While one could use div's I guess, what are the problems with this approach?
It simplifies the development, and the edit button doesn't cause a reload.

I will add the assumption that no user will want to bookmark this page. It
is a WebApp, so any search engine will have to be home-grown. The
scroll-bar layout is so bad...there are just 2 frames: left and right.

Sandeep

--- David Heller <dave at interactiondesigners.com>
wrote:
> Frames, are not usable b/c they are a poor hack into the HTML spec.
> What was really attempted were "panes". That is a space on a screen
> that scrolls internal to the window.
> It also affords the ability to having objects on a page NOT scroll
> while other spaces do scroll.
>
> using XHTML frames are just plain obsolete and ugly.
> There are better ways
> to achieve the same effects AND they degrade a lot more gracefully.
>
> e.g. you can put content into a <div> layer and set it to "overflow"
> (adding scrollbars when necessary). It's "box" will scroll while the
> rest of the page doesn't. This sorta mimicks the <iframe> model but
> works in xHTML compliant browsers. For browsers that don't accept this
> CSS style well you end up w/ a normal page.
>
> The reasons that frames don't work:
> 1. harder on searchengines
> 2. bookmarking becomes difficult
> 3. calculating frame sizes isn't x-browser equal 4. frames the way
> implemented in the HTML does not map to user expectations in terms of
> scrollbar layout and what not.
>
> The reason to use frames? hmmm? Can't think of any.
>
> -- dave
> > _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
> already) http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

5 May 2004 - 2:00pm
Andrei Herasimchuk
2004

On May 5, 2004, at 11:38 AM, David Heller wrote:

> I would put frames as a last resort thing in my designs, but I'm sure
> I can
> come up w/ many examples like the one below where it can make sense.
> Frames
> though do not fit w/ semantic xHTML coding, is harder to incorporate
> w/ XML
> based widget building and the like.

I've stayed out of this thread for a while, but will say add this
little comment

David H. pretty much is correct with his assessment of frames and their
problems, at least from my point of view of having to create enterprise
applications that lived inside browsers.

However, I was forced to use frame in the last enterprise app I built
for a variety of interaction reasons. What did I learn?

I have this notion that if one finds they *really* need to use frames
in a web based design to solve certain interaction problems, data
display problems, whatever problems.... all legitimate design problems
I might add.... what they should really be asking themselves is why are
they doing all this work inside a web browser in the first place.

I mean really...

While I did all the design work to make a frame-based chat system work
in a web browser for the last company I worked for, all I kept asking
was: "This is silly. Why don't we just make a thin-client and do this
right?" The whole frames thing really is a serious band-aid, and
generally points out that one is trying to fit a square peg into a
round hole.

Bite the bullet. If your web app requires robust interaction, dump the
browser and do it right.

Andrei Herasimchuk
andrei at adobe.com

work: http://www.adobe.com
personal: http://www.designbyfire.com

5 May 2004 - 4:20pm
Priya Prakash
2004

> Bite the bullet. If your web app requires robust interaction, dump the
browser and do it right.

Now you're talking...I so agree with you Andrei :)

Priya Prakash
Interaction designer | Emerging platforms
BBCi Development & Services
Office: 0207 5570095| Fax: 0207 5573244

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com]On Behalf Of Andrei Herasimchuk
Sent: 05 May 2004 20:00
To: 'id-discuss'
Subject: Re: [ID Discuss] web design

On May 5, 2004, at 11:38 AM, David Heller wrote:

> I would put frames as a last resort thing in my designs, but I'm sure
> I can
> come up w/ many examples like the one below where it can make sense.
> Frames
> though do not fit w/ semantic xHTML coding, is harder to incorporate
> w/ XML
> based widget building and the like.

I've stayed out of this thread for a while, but will say add this
little comment

David H. pretty much is correct with his assessment of frames and their
problems, at least from my point of view of having to create enterprise
applications that lived inside browsers.

However, I was forced to use frame in the last enterprise app I built
for a variety of interaction reasons. What did I learn?

I have this notion that if one finds they *really* need to use frames
in a web based design to solve certain interaction problems, data
display problems, whatever problems.... all legitimate design problems
I might add.... what they should really be asking themselves is why are
they doing all this work inside a web browser in the first place.

I mean really...

While I did all the design work to make a frame-based chat system work
in a web browser for the last company I worked for, all I kept asking
was: "This is silly. Why don't we just make a thin-client and do this
right?" The whole frames thing really is a serious band-aid, and
generally points out that one is trying to fit a square peg into a
round hole.

Bite the bullet. If your web app requires robust interaction, dump the
browser and do it right.

Andrei Herasimchuk
andrei at adobe.com

work: http://www.adobe.com
personal: http://www.designbyfire.com

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest): http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

BBCi at http://www.bbc.co.uk/

This e-mail (and any attachments) is confidential and may contain
personal views which are not the views of the BBC unless specifically
stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately. Please note that the
BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

5 May 2004 - 4:25pm
Daniel Harvey
2004

To avoid downloading and installing stray apps?

-----Original Message-----
From: Priya Prakash [mailto:priya.prakash at bbc.co.uk]
Sent: Wednesday, May 05, 2004 5:21 PM
To: Andrei Herasimchuk; id-discuss
Subject: RE: [ID Discuss] web design

> Bite the bullet. If your web app requires robust interaction, dump the
browser and do it right.

Now you're talking...I so agree with you Andrei :)

Priya Prakash
Interaction designer | Emerging platforms
BBCi Development & Services
Office: 0207 5570095| Fax: 0207 5573244

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com]On Behalf Of Andrei Herasimchuk
Sent: 05 May 2004 20:00
To: 'id-discuss'
Subject: Re: [ID Discuss] web design

On May 5, 2004, at 11:38 AM, David Heller wrote:

> I would put frames as a last resort thing in my designs, but I'm sure
> I can
> come up w/ many examples like the one below where it can make sense.
> Frames
> though do not fit w/ semantic xHTML coding, is harder to incorporate
> w/ XML
> based widget building and the like.

I've stayed out of this thread for a while, but will say add this
little comment

David H. pretty much is correct with his assessment of frames and their
problems, at least from my point of view of having to create enterprise
applications that lived inside browsers.

However, I was forced to use frame in the last enterprise app I built
for a variety of interaction reasons. What did I learn?

I have this notion that if one finds they *really* need to use frames
in a web based design to solve certain interaction problems, data
display problems, whatever problems.... all legitimate design problems
I might add.... what they should really be asking themselves is why are
they doing all this work inside a web browser in the first place.

I mean really...

While I did all the design work to make a frame-based chat system work
in a web browser for the last company I worked for, all I kept asking
was: "This is silly. Why don't we just make a thin-client and do this
right?" The whole frames thing really is a serious band-aid, and
generally points out that one is trying to fit a square peg into a
round hole.

Bite the bullet. If your web app requires robust interaction, dump the
browser and do it right.

Andrei Herasimchuk
andrei at adobe.com

work: http://www.adobe.com
personal: http://www.designbyfire.com

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

BBCi at http://www.bbc.co.uk/

This e-mail (and any attachments) is confidential and may contain
personal views which are not the views of the BBC unless specifically
stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately. Please note that the
BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

5 May 2004 - 4:36pm
Andrei Herasimchuk
2004

On May 5, 2004, at 2:25 PM, Daniel Harvey wrote:

> To avoid downloading and installing stray apps?

I'm glad someone took the bait. 8^)

So, let's ask ourselves, what is worse?

1. Severely crippled, inelegant user experiences inside interaction
deficient web browsers, but a single app/icon to keep track of.
2. Robust user experiences aimed at solving the user task at and in as
robust an interaction as needed with many apps/icons to keep track.

Further, let's consider the Central/Flex model. You have a single app
that allows the user to manage multiple robust thin client/RIAs.

So, with the Central/Flex model, you solve one of the main gripe about
#2 by reducing the apps/icons to be just a browser and *one* other main
app/icon to install.

At this stage of the game, I'll take a Centralk/Flex model. Hell, I'll
even take a ten icons I have to instlal, manage in my Start menu and
launch myself over Adobe's horrid intranet, browser based system for
managing my 401k, insurance, PTO time, booking travel, expense
reimbursement, etc... all done with extraordinarily crappy user
interfaces inside a totally crippled browser interaction model.

Do I sound bitter? Probably not bitter enough to be honest.

Andrei Herasimchuk
andrei at adobe.com

work: http://www.adobe.com
personal: http://www.designbyfire.com

5 May 2004 - 5:41pm
Dave Collins
2004

>>> Bite the bullet. If your web app requires robust interaction, dump
the
browser and do it right.
>> To avoid downloading and installing stray apps?
>
>So, let's ask ourselves, what is worse?
>
>1. Severely crippled, inelegant user experiences inside interaction
>deficient web browsers, but a single app/icon to keep track of.
>2. Robust user experiences aimed at solving the user task at and in as
>robust an interaction as needed with many apps/icons to keep track.

Stray apps need to be installed, licensed, tracked, upgraded, serviced,
backed up, and etc. Even for an in-house solution, this is not trivial.
Web protocol is becoming so popular these days because it eliminates
much of that, and leaves the rest to be handled back at the host.

<anecdote type="personal">
I blog using LiveJournal (www.livejournal.com/users/davesbrain/). It
bugs me that they want me to download a whole app just so I can easily
update my blog. Why would an app that's designed to generate web content
need to run anywhere but in a web browser? They want me to download it
everywhere I have a PC, and they discourage accessing it online from
anywhere I want.
</anecdote>

Dave

5 May 2004 - 5:53pm
Andrei Herasimchuk
2004

On May 5, 2004, at 3:41 PM, Dave Collins wrote:

> Stray apps need to be installed, licensed, tracked, upgraded, serviced,
> backed up, and etc. Even for an in-house solution, this is not trivial.
> Web protocol is becoming so popular these days because it eliminates
> much of that, and leaves the rest to be handled back at the host.

Strays apps can be auto-updated, serviced, backed-up and tracked as
easily as their browser based counterparts. There's nothing inherent in
the application design model of a client application (thin, RIA or
desktop) that prevents it from maximizing the fact the user has a live
internet connection.

As for licensing, an app is an app is an app. Nothing about how it is
delivered affects the licensing model a business chooses. It's merely a
business decision.

> <anecdote type="personal">
> I blog using LiveJournal (www.livejournal.com/users/davesbrain/). It
> bugs me that they want me to download a whole app just so I can easily
> update my blog. Why would an app that's designed to generate web
> content
> need to run anywhere but in a web browser? They want me to download it
> everywhere I have a PC, and they discourage accessing it online from
> anywhere I want.
> </anecdote>

Funny. I'm dying the day that MoveableType has a real client so I can
manage my blog far more effectively than the crippled interface the
browser-based version gives me. The same reason I use an email client
over a browser-based version is the same reason I want to do a lot of
this stuff with a real client or a browser based version.

Let's see a show of hands: Who would prefer to use the browser based
version of Microsoft Outlook over the desktop client ***as their
primary*** interface to using email on a daily basis?

Andrei Herasimchuk
andrei at adobe.com

work: http://www.adobe.com
personal: http://www.designbyfire.com

6 May 2004 - 2:27am
id at ourbrisba...
2004

Quoting Andrei Herasimchuk <andrei at adobe.com>:
> Let's see a show of hands: Who would prefer to use the browser based
> version of Microsoft Outlook over the desktop client ***as their
> primary*** interface to using email on a daily basis?

I really detest having to design browser-based apps (although in my experience,
the main motivation has been for executives to keep up with the fashion over and
above practicality, usability, cost, etc). However, I'll chime in with my "It
depends." as usual.

I'm actually writing this in a browser-based e-mail client that I designed a few
years back. It took a helluva lot of work for my developers to code it, but
it's a great solution for users that are constantly stuck in transit or on
different machines (such as myself)...

Why did it take so much coding? Because it looks like, responds like, and has
the same functions as a desktop e-mail client. It features drag and drop,
keyboard shortcuts, contextual menus, scrollable panes (yes, using frames!),
one-click address book, etc. It reacts in real-time (saving server trips for
when it's necessary using some smart caching) to user input, populates the
preview pane when a message is selected, and follows all the conventions of a
GUI app. At no point do users even think of it as a browser-based app.

So, no Andrei, I would never use the browser-based version of Outlook over and
above the desktop client, but I would (and do) use this browser-based app. ;)

Best regards,

Ash Donaldson
User Experience Designer
"It depends."

6 May 2004 - 4:01am
Andrei Herasimchuk
2004

On May 6, 2004, at 12:27 AM, id at ourbrisbane.com wrote:

> I'm actually writing this in a browser-based e-mail client that I
> designed a few
> years back. It took a helluva lot of work for my developers to code
> it, but
> it's a great solution for users that are constantly stuck in transit
> or on
> different machines (such as myself)...

The question was who would *prefer* to use a browser based email client
as *the primary* interface. As in, the one you would want to use first
because as your choice and preference for every day use. I understand
why people need to use browser based email programs, but that is
usually out of necessity. No one I know prefers to Outlook inside a
browser if they can use the real deal. (Sidenote: what does being stuck
in transit have to do with it? The only time I see people using browser
email clients is from other people's machine only, never on their own
stuck in transit.)

> Why did it take so much coding? Because it looks like, responds like,
> and has
> the same functions as a desktop e-mail client. It features drag and
> drop,
> keyboard shortcuts, contextual menus, scrollable panes (yes, using
> frames!),
> one-click address book, etc. It reacts in real-time (saving server
> trips for
> when it's necessary using some smart caching) to user input, populates
> the
> preview pane when a message is selected, and follows all the
> conventions of a
> GUI app.

Is it really a single URI that creates a web page that mimics a
browser? Does it have Undo? Does it work only in IE on Windows to get
those features like real context menus and keyboard shortcuts? Does it
have real alerts, error dialogs and modal dialog boxes (like save as
and such) when needed? Can it do multiple selection?

I have to ask... if you went to all that work to mimic what a desktop
client can do (*especially* if you got a web page to have real undo,
real context menus and things like real delete functions that do the
right thing when I hit the DELETE key), why didn't you just make a real
client and save a bunch of work tricking a browser to act like one?

I'll admit: I'm dubious. I worked on a real-time chat system myself,
one that worked inside an enterprise app. (So all conversations could
be tracked, added to issue tracking, ticketed, metadata, dispplay info
based on user permission sets * roles, etc.). It did all the thing you
could do with IM but was hooked into the enterprise app itself. We took
over the browser window, nuked chrome, added our own buttons, created
framesets (seven total needed to make it work) to refresh and mimic
real-time instant messaging, allowed text entry, allowed data entry,
etc etc etc. And while it was a wonderful feat of web coding to make it
happen, I still thought it lacked as compared to a real IM client. It
never had the right feel, always showing it's web page roots
constantly.

I'm skeptical that it actually feels as responsive and robust as a real
client until I use it myself. I have yet to see anything hold up to the
test of feeling as robust as a thin client or real client. But I'm more
than happy to be shown the light.

Any chance we can use this app or see it in action? (I'm on a Mac by
the way, using Safari.)

Andrei Herasimchuk
andrei at adobe.com

work: http://www.adobe.com
personal: http://www.designbyfire.com

6 May 2004 - 4:53am
Michael Bartlett
2004

The "IT Guy" falls into our cast of characters because we understand his
pains with regards to the management of application deployment. In fact the
last release of our software there was hardly any changes to the interaction
of the product, but a huge paradigm shift in how we allow for easy
deployment and configuration and it has been very well received by our
existing clients.

Take, for example, Siebel. Its primary interface is now a web browser filled
with frames and ActiveX/JAVA components. I can get access to important
customer data from anywhere in the world (believe me, I've done it from a
terminal in SFO airport!), our IT guys don't have to worry about automatic
update scripts that they had to run very frequently and the usability impact
has been quite minimal.

At the end of the day, there is a time and place for everything, its about
choosing correctly under such circumstances which make us either succeed or
fail.

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of Daniel Harvey
Sent: 05 May 2004 22:26
To: 'Priya Prakash'; Andrei Herasimchuk; id-discuss
Subject: RE: [ID Discuss] web design

To avoid downloading and installing stray apps?

-----Original Message-----
From: Priya Prakash [mailto:priya.prakash at bbc.co.uk]
Sent: Wednesday, May 05, 2004 5:21 PM
To: Andrei Herasimchuk; id-discuss
Subject: RE: [ID Discuss] web design

> Bite the bullet. If your web app requires robust interaction, dump the
browser and do it right.

Now you're talking...I so agree with you Andrei :)

Priya Prakash
Interaction designer | Emerging platforms
BBCi Development & Services
Office: 0207 5570095| Fax: 0207 5573244

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com]On Behalf Of Andrei Herasimchuk
Sent: 05 May 2004 20:00
To: 'id-discuss'
Subject: Re: [ID Discuss] web design

On May 5, 2004, at 11:38 AM, David Heller wrote:

> I would put frames as a last resort thing in my designs, but I'm sure
> I can
> come up w/ many examples like the one below where it can make sense.
> Frames
> though do not fit w/ semantic xHTML coding, is harder to incorporate
> w/ XML
> based widget building and the like.

I've stayed out of this thread for a while, but will say add this
little comment

David H. pretty much is correct with his assessment of frames and their
problems, at least from my point of view of having to create enterprise
applications that lived inside browsers.

However, I was forced to use frame in the last enterprise app I built
for a variety of interaction reasons. What did I learn?

I have this notion that if one finds they *really* need to use frames
in a web based design to solve certain interaction problems, data
display problems, whatever problems.... all legitimate design problems
I might add.... what they should really be asking themselves is why are
they doing all this work inside a web browser in the first place.

I mean really...

While I did all the design work to make a frame-based chat system work
in a web browser for the last company I worked for, all I kept asking
was: "This is silly. Why don't we just make a thin-client and do this
right?" The whole frames thing really is a serious band-aid, and
generally points out that one is trying to fit a square peg into a
round hole.

Bite the bullet. If your web app requires robust interaction, dump the
browser and do it right.

Andrei Herasimchuk
andrei at adobe.com

work: http://www.adobe.com
personal: http://www.designbyfire.com

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

BBCi at http://www.bbc.co.uk/

This e-mail (and any attachments) is confidential and may contain
personal views which are not the views of the BBC unless specifically
stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately. Please note that the
BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/
_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

6 May 2004 - 8:39am
Elizabeth Buie
2004

Andrei asks:

"Who would prefer to use the browser based version of Microsoft Outlook
over the desktop client ***as their primary*** interface to using email on
a daily basis?"

Can I vote "neither"?

I agree about the preferability of desktop clients over browser-based
interfaces.

I would not, however, choose Outlook as my desktop client. :-)

Elizabeth

--
Elizabeth Buie
Computer Sciences Corporation
Rockville, Maryland
301.921.3326

----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
----------------------------------------------------------------------------------------

6 May 2004 - 11:48am
Craig Oshima
2004

I hope Siebel doesn't leave that important customer data in the cache of
that terminal at SFO! :-)

--
Craig Oshima
coshima at acm.org

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com] On Behalf Of Michael Bartlett
Sent: Thursday, May 06, 2004 2:54 AM
To: Daniel Harvey; 'Priya Prakash'; Andrei Herasimchuk; id-discuss
Subject: RE: [ID Discuss] web design

The "IT Guy" falls into our cast of characters because we understand his
pains with regards to the management of application deployment. In fact
the
last release of our software there was hardly any changes to the
interaction
of the product, but a huge paradigm shift in how we allow for easy
deployment and configuration and it has been very well received by our
existing clients.

Take, for example, Siebel. Its primary interface is now a web browser
filled
with frames and ActiveX/JAVA components. I can get access to important
customer data from anywhere in the world (believe me, I've done it from
a
terminal in SFO airport!), our IT guys don't have to worry about
automatic
update scripts that they had to run very frequently and the usability
impact
has been quite minimal.

At the end of the day, there is a time and place for everything, its
about
choosing correctly under such circumstances which make us either succeed
or
fail.

6 May 2004 - 12:17pm
Andrei Herasimchuk
2004

On May 6, 2004, at 2:53 AM, Michael Bartlett wrote:

> The "IT Guy" falls into our cast of characters because we understand
> his
> pains with regards to the management of application deployment. In
> fact the
> last release of our software there was hardly any changes to the
> interaction
> of the product, but a huge paradigm shift in how we allow for easy
> deployment and configuration and it has been very well received by our
> existing clients.

The whole deliver in a web browser to make IT happy is mostly a red
herring in my opinion. It is fairly straight-forward to give the user a
self-installing app based on a URL, and once a very thin client app is
installed, then proceed to update, managing licenses, deploy, etc etc
etc, can be done by the client app without any user interaction needed
as long as an internet connection is available. (Imagine that single
app being something like the Central model, and then you really
simplify things. How about Windows Update on Windows and Software
Update on Mac OS anyone?)

The fact a lot of apps have done this poorly due to lack of skill or
lack of operating system technology to handle the network connection
stuff persists the myth that browser apps are easier for IT to manage.

> Take, for example, Siebel. Its primary interface is now a web browser
> filled
> with frames and ActiveX/JAVA components. I can get access to important
> customer data from anywhere in the world (believe me, I've done it
> from a
> terminal in SFO airport!), our IT guys don't have to worry about
> automatic
> update scripts that they had to run very frequently and the usability
> impact
> has been quite minimal.

We use Siebel (and other enterprise appss) at work. It sucks beyond
belief and if you ask any Adobe employee about their experiences with
most of the enterprise, browser based software we have to use, you
would get an earful from 90% of the employee population. I would prefer
forcing our IT guys to handle the minor annoyances with firewalls,
dealing with a few installed apps and security issues (which is part of
their job anyway IMHO) than to be forced to waste hours upon hours
using horrendously inadequate browser software for general purpose
corporate work that is kludged together with every known technology
known to man just to make it appear as if its as usable as a real
client app.

> At the end of the day, there is a time and place for everything, its
> about
> choosing correctly under such circumstances which make us either
> succeed or
> fail.

I won't argue with the point. But I'm a bit tired of the IT excuse.
It's just that, an excuse. (I can hear the IT guys coming to disconnect
my port right now.)

Andrei Herasimchuk
andrei at adobe.com

work: http://www.adobe.com
personal: http://www.designbyfire.com

6 May 2004 - 1:26pm
sandeepblues
2003

The claim is: "when robust interaction is required,
switch to fat client GUI."

The advantage of the "crippled web interaction model"
is that it limits the ways of interaction, and
thereby, simplifies the interaction. I read somewhere
the quote from a user...something like... "I wanted to
access the functionality quickly, so I took the long
route to it." The other principle here is the 80-20
rule.

If there is an application that frequently requires
simple interaction, and seldom requires robust
interaction, then there are very clear advantages to
the Web approach. The simple user is far more
familiar with the limited Web interactions, and will
often prefer to have the "robust" interaction
converted to a long route of simple interactions, than
to switch and re-learn a fat client.

Of course, the counter to that is: simple users
become intermediate users. However, if you are trying
to gain acceptance amongst a vast group of consumers
who might have differing interaction habits, then as a
product strategy, banking on the lowest common
denominator might have advantages. Yes...that
encourages mediocrity...but its about the money and
product acceptance.

Thoughts?

Sandeep

6 May 2004 - 1:42pm
Dave Malouf
2005

<sandeep>
The claim is: "when robust interaction is required, switch to fat client
GUI."
</sandeep>

That isn't the claim.
FAT is not the claim. Rich is the claim.
Technologies like Flash, Curl, xAML (coming in 2006), .NET are distributed
over HTTP or similar protocols, so the user is ALWAYS using the freshest
version. The plug-in or rendering agent needs a one time install, but stays
consistent overtime, or auto-updates like the OS itself does today. The GUI
widgets are either part of the rendering agent app (like HTML, .NET, don't
know about CURL, Jenny?) or you can send custom widgets. In many cases these
can even be stored locally for later use. In Flashes case this may or may
not require Central.

On the other side of things, I have seen IE6 environments that are
incredibly compelling. Some use activeX controls to enhance HTML activity,
but these are not installs per se (no registry record, temp use), but for
the most part it is pure IE HTML (xHTML variant).

I think though from an IxD perspective, Andrei and I would challenge the
need for HTML. The IT piece I wouldn't call a red herring like Andrei did,
but a bubble remnant. People wanted Web stuff in the 90's so a lot of
expense went to doing just that. After the bust, it was still a "remnant"
requirement that to me falls in the category of many requirements which
don't define the end goal as much as the means. The question of why is not
asked, just how. Yes we can rationalize that "how" as has been done here,
but no one writes the requirement as, "I need to have a distributed install
in one location, easily customize and redistribute GUI for my application
that is secure and runs x-platform and x-browser." They say, "I need a web
interface."

-- dave

6 May 2004 - 2:28pm
sandeepblues
2003

Ok, switch "fat" to "rich" in my claim.

The rest of my previous email tries to justify when
HTML is still a good choice in certain apps that
require robust interactions.

Thoughts on that will be appreciated.

Thanks.

Sandeep

--- David Heller <dave at interactiondesigners.com>
wrote:
> <sandeep>
> The claim is: "when robust interaction is required,
> switch to fat client
> GUI."
> </sandeep>
>
> That isn't the claim.
> FAT is not the claim. Rich is the claim.
> Technologies like Flash, Curl, xAML (coming in
> 2006), .NET are distributed
> over HTTP or similar protocols, so the user is
> ALWAYS using the freshest
> version. The plug-in or rendering agent needs a one
> time install, but stays
> consistent overtime, or auto-updates like the OS
> itself does today. The GUI
> widgets are either part of the rendering agent app
> (like HTML, .NET, don't
> know about CURL, Jenny?) or you can send custom
> widgets. In many cases these
> can even be stored locally for later use. In Flashes
> case this may or may
> not require Central.
>
> On the other side of things, I have seen IE6
> environments that are
> incredibly compelling. Some use activeX controls to
> enhance HTML activity,
> but these are not installs per se (no registry
> record, temp use), but for
> the most part it is pure IE HTML (xHTML variant).
>
> I think though from an IxD perspective, Andrei and I
> would challenge the
> need for HTML. The IT piece I wouldn't call a red
> herring like Andrei did,
> but a bubble remnant. People wanted Web stuff in the
> 90's so a lot of
> expense went to doing just that. After the bust, it
> was still a "remnant"
> requirement that to me falls in the category of many
> requirements which
> don't define the end goal as much as the means. The
> question of why is not
> asked, just how. Yes we can rationalize that "how"
> as has been done here,
> but no one writes the requirement as, "I need to
> have a distributed install
> in one location, easily customize and redistribute
> GUI for my application
> that is secure and runs x-platform and x-browser."
> They say, "I need a web
> interface."
>
> -- dave
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members
> get announcements already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/

6 May 2004 - 2:55pm
Dave Malouf
2005

<sandeep>
The advantage of the "crippled web interaction model"
is that it limits the ways of interaction, and thereby, simplifies the
interaction. I read somewhere the quote from a user...something like... "I
wanted to access the functionality quickly, so I took the long route to it."
The other principle here is the 80-20 rule.
</sandeep>

I've never been a fan of the KISS me principle. Simple is not what I'm going
for.
Clarity is good, simplicity is not. I'm not sure what type of interactions
you are referring to here that you would want to be "simple" that couldn't
benefit from richness. Even a slight animated effect on the opening of a
screen/application adds to the engagement, enjoyability, etc. w/o making it
more difficult to use, and quite honestly has been shown to help users with
muscle memory in regards to navigating a screen AND for feeling more
involved in their work. Basically, how can interaction design be used to
enhance the overall experience?

Richness does not mean slower, more difficult, nor does it mean less usable.
Richer, just means richer. ;) ... Can richness lead to those things if
designed poorly? ... SURE! So can simple HTML.

-dave

6 May 2004 - 3:46pm
Andrei Herasimchuk
2004

On May 6, 2004, at 11:26 AM, Sandeep Jain wrote:

> The advantage of the "crippled web interaction model"
> is that it limits the ways of interaction, and
> thereby, simplifies the interaction.

This is a false theory.

Anyone who uses a Siebel enterprise app in their corporate environment
knows that the interaction is anything but simplified. In fact, due to
the app having to play tricks and get around broken HTML-based
interaction models (like making a selection or more than one selection
for example) tends to complicate the workflow far more often than
necessary.

> If there is an application that frequently requires
> simple interaction, and seldom requires robust
> interaction, then there are very clear advantages to
> the Web approach.

Again, a false theory.

Let me put it this way: Let's say a gourmet chef has 10 ingredients at
his disposal to make a dinner. A good gourmet could use only the 2 or 3
that really make the meal delicious based on what kind of meal he wants
to make. That same chef will be at the mercy of the specific 2 or 3
ingredients he is forced to use to use if the number of ingredients are
restricted from his use. The resulting meal might not work given the
context of the party.

> The simple user is far more
> familiar with the limited Web interactions, and will
> often prefer to have the "robust" interaction
> converted to a long route of simple interactions, than
> to switch and re-learn a fat client.

You have proof of this? It would be a great research paper. Create two
applications that are both exemplary products for a chosen task, and
are very well designed as both a browser app and a client app. Then put
them to the test with users. A good example would be an application for
buying tickets for a trip to Europe.

Andrei Herasimchuk
andrei at adobe.com

work: http://www.adobe.com
personal: http://www.designbyfire.com

6 May 2004 - 8:38pm
Josh Seiden
2003

The problem with this argument, Sandeep, is that you
are conflating an interaction style with an
implementation technology.

You are certainly correct to suggest that simple
interactions are appropriate for certain classes of
users. The implication that you get this for free from
HTML seems oversimplified.

In fact, the implication that you get simple
interactions for free from *any* technology is a
fallacy. "Simple" is relative--it depends on the user.
You get simple interactions when you match the
interaction style to the user's mental model.

JS

> -----Original Message-----
> From:
>
discuss-interactiondesigners.com-bounces at lists.interact
iondesi
> gners.com
>
[mailto:discuss-interactiondesigners.com-bounces at lists.
interac
> tiondesigners.com] On Behalf Of Sandeep Jain
> Sent: Thursday, May 06, 2004 2:27 PM
> To: id-discuss Designers
> Subject: Re: [ID Discuss] web design
>
>
> The claim is: "when robust interaction is required,
> switch to fat client GUI."
>
> The advantage of the "crippled web interaction model"
> is that it limits the ways of interaction, and
> thereby, simplifies the interaction. I read
somewhere
> the quote from a user...something like... "I wanted
to
> access the functionality quickly, so I took the long
> route to it." The other principle here is the 80-20
> rule.
>
> If there is an application that frequently requires
> simple interaction, and seldom requires robust
> interaction, then there are very clear advantages to
> the Web approach. The simple user is far more
> familiar with the limited Web interactions, and will
> often prefer to have the "robust" interaction
> converted to a long route of simple interactions,
than
> to switch and re-learn a fat client.
>
>
> Of course, the counter to that is: simple users
> become intermediate users. However, if you are
trying
> to gain acceptance amongst a vast group of consumers
> who might have differing interaction habits, then as
a
> product strategy, banking on the lowest common
> denominator might have advantages. Yes...that
> encourages mediocrity...but its about the money and
> product acceptance.
>
> Thoughts?
>
> Sandeep
>
>
>
> _______________________________________________
> Interaction Design Discussion List
discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get
announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

7 May 2004 - 3:07pm
sandeepblues
2003

One doesn't get simplicity for free. However, there
is a reason why millions of people are able to use the
Internet, with relative ease. It is because the
palette of interactions is restricted. The interaction
can be designed to be painful, but the restrictive
tools for interaction (click a link, press a button,
fill up a field) are simple and "for free" if you
will. If each website had access to the WIMP palette,
then the WWW would not be where it is, because the
richness of each WIMP website would scare the common
user away.

This sucks for the power user, and there in lie your
"classes of users". A power user might find the HTML
interactions excruciating to use, but he/she can't
deny that those interactions are simple to understand
and use.

Besides being simple, HTML interactions are
universal. More people relate to JK Rowling's work,
than Thomas Hardy's. Why? It has simpler language,
it has more universal appeal, and is more
democratically useful.

There are cases where it takes many clicks to do
something that could be done in a few interactions in
WIMP, but the long route can be simpler and universal.

Sandeep

--- Joshua Seiden <josh at 36partners.com> wrote:
> The problem with this argument, Sandeep, is that you
> are conflating an interaction style with an
> implementation technology.
>
> You are certainly correct to suggest that simple
> interactions are appropriate for certain classes of
> users. The implication that you get this for free
> from
> HTML seems oversimplified.
>
> In fact, the implication that you get simple
> interactions for free from *any* technology is a
> fallacy. "Simple" is relative--it depends on the
> user.
> You get simple interactions when you match the
> interaction style to the user's mental model.
>
> JS
>
> > -----Original Message-----
> > From:
> >
>
discuss-interactiondesigners.com-bounces at lists.interact
> iondesi
> > gners.com
> >
>
[mailto:discuss-interactiondesigners.com-bounces at lists.
> interac
> > tiondesigners.com] On Behalf Of Sandeep Jain
> > Sent: Thursday, May 06, 2004 2:27 PM
> > To: id-discuss Designers
> > Subject: Re: [ID Discuss] web design
> >
> >
> > The claim is: "when robust interaction is
> required,
> > switch to fat client GUI."
> >
> > The advantage of the "crippled web interaction
> model"
> > is that it limits the ways of interaction, and
> > thereby, simplifies the interaction. I read
> somewhere
> > the quote from a user...something like... "I
> wanted
> to
> > access the functionality quickly, so I took the
> long
> > route to it." The other principle here is the
> 80-20
> > rule.
> >
> > If there is an application that frequently
> requires
> > simple interaction, and seldom requires robust
> > interaction, then there are very clear advantages
> to
> > the Web approach. The simple user is far more
> > familiar with the limited Web interactions, and
> will
> > often prefer to have the "robust" interaction
> > converted to a long route of simple interactions,
> than
> > to switch and re-learn a fat client.
> >
> >
> > Of course, the counter to that is: simple users
> > become intermediate users. However, if you are
> trying
> > to gain acceptance amongst a vast group of
> consumers
> > who might have differing interaction habits, then
> as
> a
> > product strategy, banking on the lowest common
> > denominator might have advantages. Yes...that
> > encourages mediocrity...but its about the money
> and
> > product acceptance.
> >
> > Thoughts?
> >
> > Sandeep
> >
> >
> >
> > _______________________________________________
> > Interaction Design Discussion List
> discuss at interactiondesigners.com
> > --
> > to change your options (unsubscribe or set
> digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members
> get
> announcements already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/
>
>

7 May 2004 - 3:15pm
Dave Malouf
2005

Sandeep, again, the argument doesn't stand up. B/c every place that you said
"internet" or "web" you could say "Mac" except it has a full rich framework
and that framework is manipulated to be very simple, which is the #1 reason
stated for its success.

This is almost like the early Flash is 99% bad arguments.
Flash is not used appropriately so all Flash is unusable.
You are equating the engine w/ the engineer and this doesn't make sense.

Also, have you ever read Hemingway? Talk about simple words? The ideas are
complex though.

Rowling's subject is what makes her appealing, not the language that she
uses, and while you are at it. The language both writers use is the same,
English ... It is what they do with it. The language allows for a range of
infinite complexity, but it is the choice of words and subject that changes
the appeal, not the language. HTML and RIAs are different languages, but
HTML is grunts and RIAs is English.

-- dave

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of Sandeep Jain
Sent: Friday, May 07, 2004 4:07 PM
To: josh at 36partners.com; 'id-discuss Designers'
Subject: RE: [ID Discuss] web design

One doesn't get simplicity for free. However, there is a reason why
millions of people are able to use the Internet, with relative ease. It is
because the palette of interactions is restricted. The interaction can be
designed to be painful, but the restrictive tools for interaction (click a
link, press a button, fill up a field) are simple and "for free" if you
will. If each website had access to the WIMP palette, then the WWW would not
be where it is, because the richness of each WIMP website would scare the
common user away.

This sucks for the power user, and there in lie your "classes of users". A
power user might find the HTML interactions excruciating to use, but he/she
can't deny that those interactions are simple to understand and use.

Besides being simple, HTML interactions are universal. More people relate
to JK Rowling's work, than Thomas Hardy's. Why? It has simpler language,
it has more universal appeal, and is more democratically useful.

There are cases where it takes many clicks to do something that could be
done in a few interactions in WIMP, but the long route can be simpler and
universal.

Sandeep

--- Joshua Seiden <josh at 36partners.com> wrote:
> The problem with this argument, Sandeep, is that you are conflating an
> interaction style with an implementation technology.
>
> You are certainly correct to suggest that simple interactions are
> appropriate for certain classes of users. The implication that you get
> this for free from HTML seems oversimplified.
>
> In fact, the implication that you get simple interactions for free
> from *any* technology is a fallacy. "Simple" is relative--it depends
> on the user.
> You get simple interactions when you match the interaction style to
> the user's mental model.
>
> JS
>
> > -----Original Message-----
> > From:
> >
>
discuss-interactiondesigners.com-bounces at lists.interact
> iondesi
> > gners.com
> >
>
[mailto:discuss-interactiondesigners.com-bounces at lists.
> interac
> > tiondesigners.com] On Behalf Of Sandeep Jain
> > Sent: Thursday, May 06, 2004 2:27 PM
> > To: id-discuss Designers
> > Subject: Re: [ID Discuss] web design
> >
> >
> > The claim is: "when robust interaction is
> required,
> > switch to fat client GUI."
> >
> > The advantage of the "crippled web interaction
> model"
> > is that it limits the ways of interaction, and thereby, simplifies
> > the interaction. I read
> somewhere
> > the quote from a user...something like... "I
> wanted
> to
> > access the functionality quickly, so I took the
> long
> > route to it." The other principle here is the
> 80-20
> > rule.
> >
> > If there is an application that frequently
> requires
> > simple interaction, and seldom requires robust interaction, then
> > there are very clear advantages
> to
> > the Web approach. The simple user is far more familiar with the
> > limited Web interactions, and
> will
> > often prefer to have the "robust" interaction converted to a long
> > route of simple interactions,
> than
> > to switch and re-learn a fat client.
> >
> >
> > Of course, the counter to that is: simple users become intermediate
> > users. However, if you are
> trying
> > to gain acceptance amongst a vast group of
> consumers
> > who might have differing interaction habits, then
> as
> a
> > product strategy, banking on the lowest common denominator might
> > have advantages. Yes...that encourages mediocrity...but its about
> > the money
> and
> > product acceptance.
> >
> > Thoughts?
> >
> > Sandeep
> >
> >
> >
> > _______________________________________________
> > Interaction Design Discussion List
> discuss at interactiondesigners.com
> > --
> > to change your options (unsubscribe or set
> digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
> already) http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/
>
>

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

7 May 2004 - 5:25pm
sandeepblues
2003

I beg to differ.

Mac does *not* have a wide following. It is *not*
successful. It influences the world in a very tiny
way, and "web" and "internet" is used in a huge way.
Orders of magnitude. Comparing the two is only
appropriate in the idealist world of IxD designers.
The speed of acceptance and familiarity with any WIMP
interface is far less than interfaces in HTML.

When I was referring to language, I was referring to
the use of English in expressing onself.

If Rowling expressed the same subject with a complex
use of English, the books will not be as popular.
Engineers might focus on and be impressed with the
"core" content/subject of a book, but the world at
large wants to read a book that reads easily and flows
smoothly....and of course, has an engaging subject as
well. The world at large doesn't know big words and
does not care for rich use of language.

Your reference to Hemingway supports my point. Simple
language can be used to provide rich meaning. HTML
can be used to provide usefulness to users in rich
ways.

I strongly agree that a rich WIMP interface is more
appropriate for a consistently complex interactions.
I was referring to the 80-20% situations and to the
universal acceptance of Hypercard-like UIs as reasons
in support of using HTML in many cases, over WIMP.

HTML democratizes user interfaces. It has immediate
appeal. It has universal appeal. The learning curve is
small. Why? Because it uses simple words to express
interesting subjects.

Sandeep

--- David Heller <dave at interactiondesigners.com>
wrote:
> Sandeep, again, the argument doesn't stand up. B/c
> every place that you said
> "internet" or "web" you could say "Mac" except it
> has a full rich framework
> and that framework is manipulated to be very simple,
> which is the #1 reason
> stated for its success.
>
> This is almost like the early Flash is 99% bad
> arguments.
> Flash is not used appropriately so all Flash is
> unusable.
> You are equating the engine w/ the engineer and this
> doesn't make sense.
>
> Also, have you ever read Hemingway? Talk about
> simple words? The ideas are
> complex though.
>
> Rowling's subject is what makes her appealing, not
> the language that she
> uses, and while you are at it. The language both
> writers use is the same,
> English ... It is what they do with it. The language
> allows for a range of
> infinite complexity, but it is the choice of words
> and subject that changes
> the appeal, not the language. HTML and RIAs are
> different languages, but
> HTML is grunts and RIAs is English.
>
> -- dave
>
> -----Original Message-----
> From:
>
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
>
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
> com] On Behalf Of Sandeep Jain
> Sent: Friday, May 07, 2004 4:07 PM
> To: josh at 36partners.com; 'id-discuss Designers'
> Subject: RE: [ID Discuss] web design
>
> One doesn't get simplicity for free. However,
> there is a reason why
> millions of people are able to use the Internet,
> with relative ease. It is
> because the palette of interactions is restricted.
> The interaction can be
> designed to be painful, but the restrictive tools
> for interaction (click a
> link, press a button, fill up a field) are simple
> and "for free" if you
> will. If each website had access to the WIMP
> palette, then the WWW would not
> be where it is, because the richness of each WIMP
> website would scare the
> common user away.
>
> This sucks for the power user, and there in lie
> your "classes of users". A
> power user might find the HTML interactions
> excruciating to use, but he/she
> can't deny that those interactions are simple to
> understand and use.
>
> Besides being simple, HTML interactions are
> universal. More people relate
> to JK Rowling's work, than Thomas Hardy's. Why? It
> has simpler language,
> it has more universal appeal, and is more
> democratically useful.
>
> There are cases where it takes many clicks to do
> something that could be
> done in a few interactions in WIMP, but the long
> route can be simpler and
> universal.
>
>
>
> Sandeep
>
> --- Joshua Seiden <josh at 36partners.com> wrote:
> > The problem with this argument, Sandeep, is that
> you are conflating an
> > interaction style with an implementation
> technology.
> >
> > You are certainly correct to suggest that simple
> interactions are
> > appropriate for certain classes of users. The
> implication that you get
> > this for free from HTML seems oversimplified.
> >
> > In fact, the implication that you get simple
> interactions for free
> > from *any* technology is a fallacy. "Simple" is
> relative--it depends
> > on the user.
> > You get simple interactions when you match the
> interaction style to
> > the user's mental model.
> >
> > JS
> >
> > > -----Original Message-----
> > > From:
> > >
> >
>
discuss-interactiondesigners.com-bounces at lists.interact
> > iondesi
> > > gners.com
> > >
> >
>
[mailto:discuss-interactiondesigners.com-bounces at lists.
> > interac
> > > tiondesigners.com] On Behalf Of Sandeep Jain
> > > Sent: Thursday, May 06, 2004 2:27 PM
> > > To: id-discuss Designers
> > > Subject: Re: [ID Discuss] web design
> > >
> > >
> > > The claim is: "when robust interaction is
> > required,
> > > switch to fat client GUI."
> > >
> > > The advantage of the "crippled web interaction
> > model"
> > > is that it limits the ways of interaction, and
> thereby, simplifies
> > > the interaction. I read
> > somewhere
> > > the quote from a user...something like... "I
> > wanted
> > to
> > > access the functionality quickly, so I took the
> > long
> > > route to it." The other principle here is the
> > 80-20
> > > rule.
> > >
> > > If there is an application that frequently
> > requires
> > > simple interaction, and seldom requires robust
> interaction, then
> > > there are very clear advantages
> > to
> > > the Web approach. The simple user is far more
> familiar with the
> > > limited Web interactions, and
> > will
> > > often prefer to have the "robust" interaction
> converted to a long
> > > route of simple interactions,
> > than
> > > to switch and re-learn a fat client.
> > >
> > >
> > > Of course, the counter to that is: simple users
> become intermediate
> > > users. However, if you are
> > trying
> > > to gain acceptance amongst a vast group of
> > consumers
> > > who might have differing interaction habits,
> then
> > as
> > a
> > > product strategy, banking on the lowest common
> denominator might
> > > have advantages. Yes...that encourages
> mediocrity...but its about
> > > the money
> > and
> > > product acceptance.
> > >
> > > Thoughts?
> > >
> > > Sandeep
> > >
> > >
> > >
> > > _______________________________________________
> > > Interaction Design Discussion List
> > discuss at interactiondesigners.com
> > > --
> > > to change your options (unsubscribe or set
> > digest):
> > http://discuss.interactiondesigners.com
> > --
> > Questions: lists at interactiondesigners.com
> > --
> > Announcement Online List (discussion list members
> get announcements
> > already)
> http://interactiondesigners.com/announceList/
> > --
> > http://interactiondesigners.com/
> >
> >
>
>
=== message truncated ===

7 May 2004 - 5:46pm
Dave Malouf
2005

<<HTML democratizes user interfaces. It has immediate
appeal. It has universal appeal. The learning curve is
small. Why? Because it uses simple words to express
interesting subjects.>>

Is it HTML, or the web browser?
I feel you are confusing the language w/ the medium of delivery.

I can make something look and behave exactly like HTML using Flash or Curl.
It will use the same materials and be transported using the same web
browser.

I don't understand.

What I would say about HTML is that it is easy to compose with. Possibly
easier than other forms of composition and thus the democratizing factor of
HTML is that anyone can do it and tools have been made to make it even
easier.

BUT that being said, I can create a pure blog in FLASH.

HTML also is not an application language. It is an information display
language. Even the examples that you gave are informational -
non-transactional.

Take for example a simple application: a calculator.
Which is better? An HTML version? WIMP version?
HTML can't use the number keypad
HTML cannot give sound feedback
And that is just the beginning

And if that isn't simple enough, then I feel this discussion is moot. If you
think that HTML is better for information transfer, then I could agree w/
that ... but for anything interactive and intelligent I don't think your
point has been made except by espousing an off truism and hoping we'll
accept it.

-- dave

7 May 2004 - 6:44pm
Andrei Herasimchuk
2004

On May 7, 2004, at 3:25 PM, Sandeep Jain wrote:

> Mac does *not* have a wide following. It is *not*
> successful. It influences the world in a very tiny
> way, and "web" and "internet" is used in a huge way.
> Orders of magnitude. Comparing the two is only
> appropriate in the idealist world of IxD designers.

While Apple had a hard time getting market share due to poor business
decisions they made, to say the Mac was not successful and has little
influence is simply re-writing history.

> The speed of acceptance and familiarity with any WIMP
> interface is far less than interfaces in HTML.

Really? So... word processing, spreadsheets, email, instant
messaging... you know... all those things that are done with client
applications by a large majority of the computing population (I would
venture to guess in the 80% range)... I guess those are nothing
compared to what HTML has done in the sphere of influence or
acceptance? User familiarity with them is sorely lacking when compared
to shopping for books on Amazon according to your logic.

> HTML democratizes user interfaces. It has immediate
> appeal. It has universal appeal. The learning curve is
> small. Why? Because it uses simple words to express
> interesting subjects.

I ask again.... do you use a client for email or a web browser? And
why? By the way... I think that since most people use a computer for
email... in fact a large majority of computer use is for nothing but
email, this gets at the heart of the discussion.

Andrei Herasimchuk
andrei at adobe.com

work: http://www.adobe.com
personal: http://www.designbyfire.com

7 May 2004 - 8:25pm
sandeepblues
2003

Dave Heller's comment was:
"you could say "Mac" except it has a full rich
framework and that framework is manipulated to be very
simple"

My response was more about Mac's framework's direct
usage by the world. I am definitely not discounting
the indirect influence of Apple and Xerox on user
interfaces. I was just stating that Mac's own rich
UIs are not being used as widely as the Web Browser's
poor UIs. So, don't compare them.

Of course, spreadsheets etc. are very important to the
computing population. Ask a user to switch from Xcel
to Lotus or vice-versa. Ask the same user to switch
from using different websites (Google, Yahoo, MSN, or
buying a book from AMazon or DVD from BMG). The
changes in interactions involved with the latter will
have more acceptance and familiarity. Do you
disagree?

At work, I use the browser for my personal email,
versus professional email (Outlook). Would I prefer
to use a thin client? That depends on whether that
same thin client is available in every kiosk in the
world or not. If not, then I will suffer the poor
interactions of HTML, and enjoy its universality, than
learn some new "rich" interface, for every damn
kiosk...because clearly every designer has some trick
up his sleeve to make things "richer" for the kiosk
they tout. Email in MSN versus Yahoo verus Google can
only be so different, because of the limited palette
of HTML. Email differences in Outlook versus Eudora
versus Netscape are huge. At the end of the day, the
limited interactions from HTML mean that I can expect
similar interactions from each.

They are poor interactions for complex data entry, but
as David said, as an informational tool, interacting
with HTML is pretty good. If I spend 10% of my time
manipulating email, and 90% of my time reading it,
then the universality of HTML is awesome.

Sandeep

7 May 2004 - 9:13pm
Josh Seiden
2003

So I'm re-reading your posts, Sandeep, and I think I
agree with the main thrust, but I think that the
terminology that you're using is perhaps less precise
than it could be, and is why I'm having trouble.

In an earlier post, Sandeep wrote:

> The advantage of the "crippled web interaction model"
> is that it limits the ways of interaction, and
> thereby, simplifies the interaction.

What you are talking about here is a specific
"application posture."

Posture describes the set of interaction idioms that
the program deploys to get its job done. Roughly, you
can think of posture as the interaction tenor of the
program. (Read more in Cooper and Reimann's "About Face
2.0.")

> I read somewhere
> the quote from a user...something like... "I wanted
to
> access the functionality quickly, so I took the long
> route to it."

In the quote you refer to, the user is expressing a
preference for a design that uses "transient" posture
as opposed to one that uses "sovereign" posture. This
is to be expected. Transient applications are well
suited to inexperienced users. (I believe that this is
the point of your post...) Note that the user is not
expressing a preference for "HTML" or "the web," but
rather, a way of moving through a task.

> HTML democratizes user interfaces. It has immediate
> appeal. It has universal appeal. The learning curve
is
> small. Why? Because it uses simple words to express
interesting
> subjects.

For clarity's sake, important to separate the notion of
implementation technology from the application posture.
Why? Because technologies and postures do not map to
each other in a 1-1 way, even though they sometimes
appear to do so. This appearance of mapping can lead to
many many problems--when designers mistake an
implementation technology choice for a posture choice.

**Why designers shouldn't mistake a technology choice
for a posture choice**

All software technologies make it easy to deploy
certain kinds of interactions, and make it more
difficult to deploy others. As a result of this
property, and barring any effort to counteract this
property, applications tend to reflect the
implementation technology. Windows applications have
lots of windows. HTML uses page-to-page navigation.
This tendency towards a certain style is the reason for
the false mapping.

Applications that reflect the way they are built are
said to reflect the "system model," or "implementation
model." But users rarely have an accurate map of the
system model in their heads. Instead, they build a
mental model, which typically differs significantly
from the implementation model. Where these models
conflict, users have trouble using the system.

Thus, designers should strive to create applications
that conform to users' mental models, and to avoid
creating applications that conform to the
implementation model. In this way, the likelihood of a
model conflict, (and thus of user problems) is reduced.

When designers equate technology with posture, they are
choosing to build an application that conforms to the
implementation model, and thus courting a model
conflict.

So what's the take away? Two thoughts:

- Specifically, designers should not confuse
implementation technologies with interaction postures.

- More generally, as a community, we need to be able to
speak precisely about our tools, and the elements that
we have under our control. If we can't, we'll spend all
our time re-learning old lessons, and will never grow
as a field.

JS

7 May 2004 - 10:38pm
sandeepblues
2003

I appreciate all the exchange on this subject, and I
am learning from it. Thank you all.

Thanks for setting right my imprecise terminology. I
have had a hard time keeping up with Ixd jargon, since
a lot of old problems resurface, and are given new
jargonish words to describe them. To my loss, I
decided to stick with describing things in lay,
imprecise terms, versus using newfangled terms.

You are also right that technology should be separated
from the posture. I made the mistake of not
separating the 2 out. My intention was to describe
how HTML technology enables designers to posture
applications to inexperienced users in ways that can
be more appealing than the 'richer' WIMP interfaces.

Limitations of HTML technology do shine through many
webapp postures, in ways that lead to laborious action
on the part of the user.

I am arguing that those limitations are the benefits
of that technology (or equivalent Hypercard-like
technology). By forcing designers to use simple
interaction tools to handle many web design problems,
people are comfortable interacting with webapps that
range from EBay, Amazon, Netflix, Etrade etc. If you
had WIMP interfaces for each webapp, you can be sure
that the "creative" designers would make these apps so
"rich" that they would be really annoying to use. The
poorness of that technology and the postures it forces
designers to produce are frequently its benefits.

Sandeep

8 May 2004 - 7:22am
Dave Malouf
2005

<sandeep>
By forcing designers to use simple
interaction tools to handle many web design problems,
people are comfortable interacting with webapps that
range from EBay, Amazon, Netflix, Etrade etc. If you
had WIMP interfaces for each webapp, you can be sure
that the "creative" designers would make these apps so
"rich" that they would be really annoying to use. The
poorness of that technology and the postures it forces
designers to produce are frequently its benefits.
</sandeep>

This again was Jakob Nielsen's argument for the 99% Flash Bad case.
Flash has no standards, thus designers will make bad decisions.

Hmm? That is to say that designers don't make a messaout of HTML?
Then why are so many usability employed by web shops ... Most of which can't
even do the real job they need?

The examples you gave btw, are great!
Amazon, I'll give you. 99% of Amazon is information display and they more
than anyone else out there have done an amazing job of putting a ton of
information in their site. Their search engine is probably one of the best.

eBay, NetFlix are the exact opposite. I walk into both of these and I just
want to run for the hills. I struggle w/ NetFlix b/c of what it offers, but
it is a usability nightmare. eBay ... Yikes!

Now that being said, you could say the same thing about every rich
application out there. My point is that technology has no guarantee on
usability. That your equation of simplicity to me doesn't work. The language
is too simple to express the complex requirements of most web sites (BTW,
maybe eTrade has an application for research, but I would not call any of
these applications ... Applications need more than a store to be an
application. These are informational sites. An Application would be
something like e-mail client, photo editing, content management, CRM, etc.)

But even these informational sites ... Compare accuweather.com to the
accuweather app on Central. Take a look. Tell me which one offers a better
experience in finding information easily and displaying it in a more
readable fashion. Even their RSS reader is quite better than a standard HTML
version.

If the idea is that you just need to create standard components in order to
create usability, then Flash & .Net both have those. If the idea is that
HTML has reached a certain level of ubiquity in people's understandings then
why did MS push away from the web interfaces they tried to push in their
early application of the 95/98 era? Why hasn't Aqua even considered them?

If you engage people with a useful product (good feelings + support of
motivation) you will go a much longer way than simple usability ever will.

==dave

9 May 2004 - 8:57pm
id at ourbrisba...
2004

Quoting Andrei Herasimchuk <andrei at adobe.com>:
> The question was who would *prefer* to use a browser based email client
> as *the primary* interface. As in, the one you would want to use first
> because as your choice and preference for every day use. I understand
> why people need to use browser based email programs, but that is
> usually out of necessity. No one I know prefers to Outlook inside a
> browser if they can use the real deal. (Sidenote: what does being stuck
> in transit have to do with it? The only time I see people using browser
> email clients is from other people's machine only, never on their own
> stuck in transit.)

Yes. Some people need to use a browser based e-mail app out of necessity.
Although many of us in IT-related industries have laptops, there are still
millions of people that access e-mail that don't have a laptop.

Giving this target market the ability to use a more familiar and satisfying
interaction paradigm is a good thing as far as I can see.

> Is it really a single URI that creates a web page that mimics a
> browser? Does it have Undo? Does it work only in IE on Windows to get
> those features like real context menus and keyboard shortcuts? Does it
> have real alerts, error dialogs and modal dialog boxes (like save as
> and such) when needed? Can it do multiple selection?

Why worry about the technicalities behind it? User experience is about
perception. If users perceive that this looks like and works like a GUI app,
that's all that matters. Yes, I used smoke and mirrors, but it works.

It has no specific undo function (although it would be not be a large packet of
work to integrate such functionality) because the development scope was not as
large as we hoped, and all critical functions (such as deleting messages or
folders, or moving files), are able to be manually undone (dragging e-mails from
the trash, etc).

It works in standards compliant browsers, and of course also IE for PC (since
our target market was dominated by it). Safari is not fully supported, but as a
Mac user myself (on my PowerBook at the moment), I find Safari too incompatible
with too many websites and apps (I use Mozilla on the Mac as my Internet banking
and some bill paying sites don't work with Safari), and the penetration for our
target market was so small (and the budget severely restricted), that we made a
business decision not to cater for it.

This is not bloatware. It does not contain thousands of extraneous functions
such as calendar integration, task lists, etc. To do that, we would have needed
a little more than a month of development time and 2 coders. It's an e-mail
client with an address book and folders that has drag and drop features,
real-time interactions, multiple select functionality, etc, to behave like a GUI
app.

> I have to ask... if you went to all that work to mimic what a desktop
> client can do (*especially* if you got a web page to have real undo,
> real context menus and things like real delete functions that do the
> right thing when I hit the DELETE key), why didn't you just make a real
> client and save a bunch of work tricking a browser to act like one?

Because of the target market. What would be the business driver behind
replicating a GUI e-mail client on a limited scope and budget?

> I'll admit: I'm dubious. I worked on a real-time chat system myself,
> one that worked inside an enterprise app. (So all conversations could
> be tracked, added to issue tracking, ticketed, metadata, dispplay info
> based on user permission sets * roles, etc.). It did all the thing you
> could do with IM but was hooked into the enterprise app itself. We took
> over the browser window, nuked chrome, added our own buttons, created
> framesets (seven total needed to make it work) to refresh and mimic
> real-time instant messaging, allowed text entry, allowed data entry,
> etc etc etc. And while it was a wonderful feat of web coding to make it
> happen, I still thought it lacked as compared to a real IM client. It
> never had the right feel, always showing it's web page roots
> constantly.

Some of the tricks we performed to enable users to perceive this as real-time
interaction would not work quite as well with a synchronous chat system. For
example, drag-and-drop, multiple selection and delete functions are seen to
happen in real-time on the front end (to the user), but the actual functions
wait for timing (moving files happens in the background during latent time), or
explicit commands (such as "Empty Trash").

> I'm skeptical that it actually feels as responsive and robust as a real
> client until I use it myself. I have yet to see anything hold up to the
> test of feeling as robust as a thin client or real client. But I'm more
> than happy to be shown the light.
>
> Any chance we can use this app or see it in action? (I'm on a Mac by
> the way, using Safari.)

Please feel free to try it out (it's free), but I'd use Mozilla (for Mac) or IE
(for PC) to access it properly. Just register at www.ourbrisbane.com

Best regards,

Ash Donaldson
User Experience Designer
"It depends."

10 May 2004 - 6:06pm
Cwodtke
2004

> Mac does *not* have a wide following. It is *not*
> successful. It influences the world in a very tiny
> way,

fun fact--

looking at yahoo stats, more people have JavaScript turned off than have
Macs.

10 May 2004 - 6:24pm
Chris Ryan
2004

On May 7, 2004, at 3:25 PM, Sandeep Jain wrote:

> Mac does *not* have a wide following. It is *not*
> successful. It influences the world in a very tiny
> way, [...]

Microsoft customers are basically using the user interface designed by
Apple. Take a look at the history of the graphic user interface (e.g.
the Xerox Star) and you will probably realize that the fact that the
same applications (e.g. Photoshop, Word) can be used on Mac OS and
Windows interchangeably in terms of near-identical user experience,
didn't happen by accident or because the Mac UI represents some
"perfect" or "obvious" design.

Some would argue that Microsoft is still following Apple's lead in many
areas--especially with OS X (I read something on Slashdot just last
week that pointed out how the recently introduced Longhorn UI borrows
heavily from Apple). So the Mac might not have a huge market share, but
(still) has a disproportionate influence. And Mac users get to reap the
benefit of Apple's position of having to be innovative just to maintain
their small market share.

Chris

10 May 2004 - 9:42pm
Dave Malouf
2005

<< Some would argue that Microsoft is still following Apple's lead in many
areas--especially with OS X >>

I think this statement is true.
I was just saying today in a strategy meeting after somone said something
like, "we should be incrimentally ahead of our competition." that "we could
always take the MS approach of staying incrementally behind the competition,
but holding onto the marketshare through fresh integration strategies that
make switching near impossible."

But that being said, Longhorn (the 2006 version of Windows) is really going
to shake the rug under OS X. It is the first Windows OS to really make a
substantional contribution to the computing world that is going to change
the course of computing. The xAML stuff is quite impressive. But only MS
would ever think that the app server and the web browser should be one. I
mean it totally makes sense, but only MS could do it, think of doing it.
Gotta love to hate them.

-- dave

11 May 2004 - 8:49am
david gee
2004

>But that being said, Longhorn (the 2006 version of Windows)
>is really going to shake the rug under OS X.
>It is the first Windows OS to really make a substantional
>contribution to the computing world that is going to change
>the course of computing. The xAML stuff is quite impressive.
>But only MS would ever think that the app server and the
>web browser should be one. I mean it totally makes sense,
>but only MS could do it, think of doing it.
>Gotta love to hate them.
>
>-- dave

Sorry to disappoint you, but no, not only Microsoft could do it, and no,
Microsoft didn't think of doing it. As always, they ripped it off:

http://xulplanet.mozdev.org/

As for "a substantial contribution to the computing world", I really
hope you're not referring to XAML - a closed source technology which
seems to be specifically designed to annihilate the Mac and Linux
platforms is hardly a great leap forward.

David Gee

11 May 2004 - 10:18am
Chris Ryan
2004

On May 10, 2004, at 7:42 PM, David Heller wrote:

> But that being said, Longhorn (the 2006 version of Windows) is really
> going
> to shake the rug under OS X.

The latest word is 2007, and some people have even started calling
Longhorn "Microsoft's Copland" (a reference to the code name of Apple's
failed new-OS strategy in the mid-1990s). At any rate, by 2007 Apple
will have had at least two major updates to OS X, if they continue to
follow their schedule of yearly releases, which have been outstanding.
Not that this will likely have a major impact on their market share,
but interesting things are happening in new markets for Apple, from
scientific applications to video to Unix geeks.

Chris

11 May 2004 - 12:08pm
tomchi at ok-ca...
2004

David Gee wrote: "Sorry to disappoint you, but no, not only Microsoft could
do it, and no, Microsoft didn't think of doing it. As always, they ripped it
off:"

Yes, and Apple "ripped off" the desktop and the mouse from PARC... and
everyone ripped off Ivan Sutherland. Anyhow. The tech world is not like
everything else. It was very fortunate that Apple ripped off PARC, and very
fortunate that a slew of hardware makers ripped off the original IBM-PC...
since their work brought PC prices down significantly from 3-5k a pop.

This sense of outrage is a little silly really. The OSS dudes all want the
world to know that *they* are the innovators... *they* make the best
software and that everyone rips them off. Meanwhile, GIMP is a shoddy
ripoff of Photoshop, Ximian Evolution is a O.K. ripoff of Outlook 2000, etc,
etc.

This is not to say there is no innovation in OSS, only to say that this
sense of outrage and the air of superiority in that community has got to be
one of the biggest roadblocks to widespread adoption. Drop the attitude.
Write good software. Ship it. Share it. World changes... everyone goes
home happy.

11 May 2004 - 12:11pm
tomchi at ok-ca...
2004

David Gee wrote: "Sorry to disappoint you, but no, not only Microsoft could
do it, and no, Microsoft didn't think of doing it. As always, they ripped it
off:"

Yes, and Apple "ripped off" the desktop and the mouse from PARC... and
everyone ripped off Ivan Sutherland. Anyhow. The tech world is not like
everything else. It was very fortunate that Apple ripped off PARC, and very
fortunate that a slew of hardware makers ripped off the original IBM-PC...
since their work brought PC prices down significantly from 3-5k a pop.

This sense of outrage is a little silly really. The OSS dudes all want the
world to know that *they* are the innovators... *they* make the best
software and that everyone rips them off. Meanwhile, GIMP is a shoddy
ripoff of Photoshop, Ximian Evolution is a O.K. ripoff of Outlook 2000, etc,
etc.

This is not to say there is no innovation in OSS, only to say that this
sense of outrage and the air of superiority in that community has got to be
one of the biggest roadblocks to widespread adoption. Drop the attitude.
Write good software. Ship it. Share it. World changes... everyone goes
home happy.

11 May 2004 - 12:14pm
david gee
2004

You seem to be misinterpreting me - here's a clue: I'm developing a .Net
web application right now. I don't have a beard, I'm kind of skinny, and
you want find a penguin sticker on the volvo I don't drive. Hell, I
don't even run Linux on any of my computers, I'm just too lazy ;p So
please, no need to be so defensive - my comment was perfectly justified.

I was merely responding to the original post, which not only stated that
Microsoft came up with the XAML concept out of nowhere, but also that
nobody else could possibly conceive of such a thing. Which, you can't
deny, was pure disinformation. I really don't have a problem with them
ripping it off - I'm learning both XAML and XUL in my spare time.

I hope XUL wins out, for two main reasons:
It should be "ready for primetime" way before Longhorn.
It's cross platform (from what I'm hearing about XAML, it seems like it
may even lock out non-Longhorn Windows users).

The fact that it's open source is a nice bonus, but not the real reason
I prefer it.

And I agree, GIMP is bloody awful.

Nice comic, by the way.

David

-----Original Message-----
From: tom chi [mailto:thegoodtomchi at ok-cancel.com]
Sent: Tuesday, May 11, 2004 12:44 PM
To: Gee, David; 'David Heller';
discuss-interactiondesigners.com at lists.interactiondesigners.com
Subject: RE: [ID Discuss] web design

David Gee wrote: "Sorry to disappoint you, but no, not only Microsoft
could do it, and no, Microsoft didn't think of doing it. As always, they
ripped it off:"

Yes, and Apple "ripped off" the desktop and the mouse from PARC... and
everyone ripped off Ivan Sutherland. Anyhow. The tech world is not
like everything else. It was very fortunate that Apple ripped off PARC,
and very fortunate that a slew of hardware makers ripped off the
original IBM-PC... since their work brought PC prices down significantly
from 3-5k a pop.

This sense of outrage is a little silly really. The OSS dudes all want
the world to know that *they* are the innovators... *they* make the best
software and that everyone rips them off. Meanwhile, GIMP is a shoddy
ripoff of Photoshop, Ximian Evolution is a O.K. ripoff of Outlook 2000,
etc, etc.

This is not to say there is no innovation in OSS, only to say that this
sense of outrage and the air of superiority in that community has got to
be one of the biggest roadblocks to widespread adoption. Drop the
attitude. Write good software. Ship it. Share it. World changes...
everyone goes home happy.

11 May 2004 - 12:17pm
Todd Warfel
2003

Actually, PARC gave the desktop and mouse to Apple.

Now the Ivan Sutherland part...

On May 11, 2004, at 1:11 PM, tom chi wrote:

> Yes, and Apple "ripped off" the desktop and the mouse from PARC... and
> everyone ripped off Ivan Sutherland.

Cheers!

Todd R. Warfel
User Experience Architect
MessageFirst | making products easier to use
--------------------------------------
Contact Info
voice: (607) 339-9640
email: twarfel at messagefirst.com
web: www.messagefirst.com
aim: twarfel at mac.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 926 bytes
Desc: not available
Url : http://listserver.dreamhost.com/pipermail/discuss-interactiondesigners.com/attachments/20040511/543f2ed8/attachment.bin

11 May 2004 - 12:40pm
Andrei Herasimchuk
2004

On May 11, 2004, at 10:11 AM, tom chi wrote:

> Drop the attitude.
> Write good software. Ship it. Share it. World changes... everyone
> goes
> home happy.

I think there's a comic in that sentiment somewhere. 8^)

Andrei Herasimchuk
andrei at adobe.com

work: http://www.adobe.com
personal: http://www.designbyfire.com

Syndicate content Get the feed