Compare/contrast info on delivery mechanisms

15 Apr 2005 - 11:50am
9 years ago
9 replies
383 reads
Anastasia Fischer
2004

I am wondering if somewhere there exists information (a doc) comparing and
contrasting the customer experience issues around the various options for
delivering software (e.g. pure thin client, rich media interfaces, applet
fat clients, etc, etc). If this does not yet exist I would offer to start
something that we could all contribute to... I find that I am continually
being asked for opinions on these matters in terms of defining strategic
product directions, and the world seems to be changing very quickly as
discussions pop up around things like Ajax, etc. Since my background is not
deep in code I would love to have a better understanding of the
implications, benefits and limitations of the various options available.

Suggestions? Please send to me and I will compile... and post for further
editing by interested parties.

Thanks,
Anastasia

-----------------
Anastasia Fischer

EEMedia.com
Customer Experience

Tel: 207.596.5549

Comments

15 Apr 2005 - 12:02pm
Frank Ramirez
2004

Hi Anastasia,

What a timely question. Luke Wroblewski and I just published a paper
about this topic on Monday.

Web Application Solutions: A Designer's Guide
Overview:
Web Application Solutions is a guide that helps designers, product
managers, and business owners evaluate some of the most popular Web
application presentation layer solutions available today. We compare
each solution through consistent criteria (deployment & reach, user
interactions, processing, interface components & customization, back-end
integration, future proofing, staffing & cost, unique features) and
provide an overview, set of examples, and references for each. The full
paper is now available:

Download it here:
http://www.lukew.com/resources/WebApplicationSolutions.pdf
Extended overview on Luke's Blog: http://www.lukew.com/ff/entry.asp?170

Please let us know what you think.

Best,
Frank Ramirez

> -----Original Message-----
> From:
> discuss-interactiondesigners.com-bounces at lists.interactiondesi
> gners.com
> [mailto:discuss-interactiondesigners.com-bounces at lists.interac
> tiondesigners.com] On Behalf Of Anastasia Fischer
> Sent: Friday, April 15, 2005 10:51 AM
> To: 'Interaction Designers'
> Subject: [ID Discuss] Compare/contrast info on delivery mechanisms
>
>
> [Please voluntarily trim replies to include only relevant
> quoted material.]
>
> I am wondering if somewhere there exists information (a doc)
> comparing and contrasting the customer experience issues
> around the various options for delivering software (e.g. pure
> thin client, rich media interfaces, applet fat clients, etc,
> etc). If this does not yet exist I would offer to start
> something that we could all contribute to... I find that I am
> continually being asked for opinions on these matters in
> terms of defining strategic product directions, and the world
> seems to be changing very quickly as discussions pop up
> around things like Ajax, etc. Since my background is not deep
> in code I would love to have a better understanding of the
> implications, benefits and limitations of the various options
> available.
>
> Suggestions? Please send to me and I will compile... and post
> for further editing by interested parties.
>
> Thanks,
> Anastasia
>
>
> -----------------
> Anastasia Fischer
>
> EEMedia.com
> Customer Experience
>
> Tel: 207.596.5549
>
>
> _______________________________________________
> Welcome to the Interaction Design Group!
> To post to this list ....... discuss at ixdg.org
> (Un)Subscription Options ... http://discuss.ixdg.org/
> Announcements List ......... http://subscribe-announce.ixdg.org/
> Questions .................. lists at ixdg.org
> Home ....................... http://ixdg.org/
>

15 Apr 2005 - 1:49pm
Anastasia Fischer
2004

Thanks for sending the link to your paper, Frank! Very much appreciated.

I have just had a couple of minutes to look it over, and it looks great. I
have a question on the DHTML pages... I am wondering about any potential
browser and/or performance issues that might result from extensive usage of
JScript (assuming that browsers have been configured to accept it, etc)?

The reason I ask it that I have recently been reviewing an application that
uses the Ajax approach, sends most of the application UI up to the client at
login (which is a heavy load of JS among other things), and then does
incremental loads as needed. The overall approach seems ok, however client
users indicate some 'performance' problems, including some unpredictable
browser crashes and various other errors (even a cpu crash or two). The
origin of the problems has been difficult to determine as there is no
'application' directly logging exceptions. From past experience I know
JavaScript can sometimes be quite squirrelly and since there are so many
scripts being used one wonders if this could be contributing to the
problem... the browser is relatively mute about it all!?!?!

Ideas anyone?

thx
anastasia

-----------------
Anastasia Fischer

EEMEdia.com
Customer Experience

Tel: 207.596.5549

> -----Original Message-----
> From: Frank Ramirez [mailto:frank at ramirezdesign.com]
> Sent: Friday, April 15, 2005 2:03 PM
> To: afischer at eemedia.com; 'Interaction Designers'
> Subject: RE: [ID Discuss] Compare/contrast info on delivery mechanisms
>
>
> Hi Anastasia,
>
> What a timely question. Luke Wroblewski and I just published a paper
> about this topic on Monday.
>
> Web Application Solutions: A Designer's Guide
> Overview:
> Web Application Solutions is a guide that helps designers, product
> managers, and business owners evaluate some of the most popular Web
> application presentation layer solutions available today. We compare
> each solution through consistent criteria (deployment & reach, user
> interactions, processing, interface components & customization, back-end
> integration, future proofing, staffing & cost, unique features) and
> provide an overview, set of examples, and references for each. The full
> paper is now available:
>
> Download it here:
> http://www.lukew.com/resources/WebApplicationSolutions.pdf
> Extended overview on Luke's Blog: http://www.lukew.com/ff/entry.asp?170
>
> Please let us know what you think.
>
> Best,
> Frank Ramirez
>
> > -----Original Message-----
> > From:
> > discuss-interactiondesigners.com-bounces at lists.interactiondesi
> > gners.com
> > [mailto:discuss-interactiondesigners.com-bounces at lists.interac
> > tiondesigners.com] On Behalf Of Anastasia Fischer
> > Sent: Friday, April 15, 2005 10:51 AM
> > To: 'Interaction Designers'
> > Subject: [ID Discuss] Compare/contrast info on delivery mechanisms
> >
> >
> > [Please voluntarily trim replies to include only relevant
> > quoted material.]
> >
> > I am wondering if somewhere there exists information (a doc)
> > comparing and contrasting the customer experience issues
> > around the various options for delivering software (e.g. pure
> > thin client, rich media interfaces, applet fat clients, etc,
> > etc). If this does not yet exist I would offer to start
> > something that we could all contribute to... I find that I am
> > continually being asked for opinions on these matters in
> > terms of defining strategic product directions, and the world
> > seems to be changing very quickly as discussions pop up
> > around things like Ajax, etc. Since my background is not deep
> > in code I would love to have a better understanding of the
> > implications, benefits and limitations of the various options
> > available.
> >
> > Suggestions? Please send to me and I will compile... and post
> > for further editing by interested parties.
> >
> > Thanks,
> > Anastasia
> >
> >
> > -----------------
> > Anastasia Fischer
> >
> > EEMedia.com
> > Customer Experience
> >
> > Tel: 207.596.5549
> >
> >
> > _______________________________________________
> > Welcome to the Interaction Design Group!
> > To post to this list ....... discuss at ixdg.org
> > (Un)Subscription Options ... http://discuss.ixdg.org/
> > Announcements List ......... http://subscribe-announce.ixdg.org/
> > Questions .................. lists at ixdg.org
> > Home ....................... http://ixdg.org/
> >
>
>
>

15 Apr 2005 - 3:07pm
Dave Malouf
2005

On 4/15/05 3:49 PM, "Anastasia Fischer" <afischer at eemedia.com> wrote:

> The reason I ask it that I have recently been reviewing an application that
> uses the Ajax approach, sends most of the application UI up to the client at
> login (which is a heavy load of JS among other things), and then does
> incremental loads as needed. The overall approach seems ok, however client
> users indicate some 'performance' problems, including some unpredictable
> browser crashes and various other errors (even a cpu crash or two). The
> origin of the problems has been difficult to determine as there is no
> 'application' directly logging exceptions. From past experience I know
> JavaScript can sometimes be quite squirrelly and since there are so many
> scripts being used one wonders if this could be contributing to the
> problem... the browser is relatively mute about it all!?!?!

The only thing I would say is that I have never had any crashes while using
some of the more robust examples of AJ+X such as Gmail and Flicker.

I do think that there are known memory management issues w/ JS that have
been documented on the Net and that if your developers are experienced
enough that they should be able to avoid them through good code management.
As in most things "languages" don't cause problems, just how well someone
knows how to speak it and knowing the fine arts of irony, sarcasm and idiom
are the realm of the truly fluent. In the case of computer languages,
sometimes you have to risk getting slapped in the face (so to speak) in
order to find just the right line (of code).

-- dave

-- dave

David Heller
http://synapticburn.com/
http://ixdg.org
dave at ixdg.org
dave at synapticburn.com
AIM: bolinhanyc || Y!: dave_ux || MSN: hippiefunk at hotmail.com

17 Apr 2005 - 7:25am
Tom George
2004

I think the essence of your reply is that if you are clever enough and
you have enough money you can make it work. Ajax seems like a very
clever use of JavaScript, but if the goal is RIA, I would say use Flash
or Flex which are intended to build RIA. There is a lot of JavaScript
out there that works only in IE or on Windows.

- Tom

On Apr 15, 2005, at 05:07 PM, David Heller wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> On 4/15/05 3:49 PM, "Anastasia Fischer" <afischer at eemedia.com> wrote:
>
>> ...
>
> ... examples of AJ+X such as Gmail and Flicker.
>
> ... and that if your developers are experienced enough that they
> should be able to avoid them through good code management.

17 Apr 2005 - 8:32am
Dave Malouf
2005

> I think the essence of your reply is that if you are clever
> enough and
> you have enough money you can make it work. Ajax seems like a very
> clever use of JavaScript, but if the goal is RIA, I would say
> use Flash
> or Flex which are intended to build RIA. There is a lot of JavaScript
> out there that works only in IE or on Windows.

Yup, you got the gist, though I do find the use of the word "clever" in this
case to be derogatory as opposed to good, or talented, or knowledgeable. The
only reason I mention this is that few HTML/JS folks are trained in OO
programming and the those that are trained in it usually find that HTML/JS
is beneath them. What I have learned is that the programmers that succeed
are of two types: traditional HTMLers train themselves up, or CS trained
folks take on the specific challenges of HTML/JS. This is NOT about
"cleverness" but about darn-tootin', straight as an arrow, good programming
skills.

Did I post here that link to Luke W. and Frank R.'s recent paper comparing
various RIA types? Ok, I'll do it again here, b/c of it's relevance:
http://lukew.com/ff/entry.asp?170

You will get no argument from me about Flash/Flex for some types of
solutions. But it has its limitations either technologically or culturally.
It works best w/ player 7 which while growing has a limited install rate as
it is NOT the player that comes w/ OSes. Installing software due to the
threat of viruses is getting harder and harder for people to accept to do
and for corporations to allow. In a corp environment for example it would be
near impossible to get them to allow their end-users to install new
software. And if I was them I would do the same thing.

That being said Flash (Flex to me doesn't really add anything in the
equations we are talking about as Interactin Designers when comparing it to
AJ+X) has a ton of advantages over any HTML solution, not the least of which
is x-browser/platform consistency and font control. It also is better for
more "animated" like interaction models, and for more graphically intensive
interfaces. It also has a better widget library that is more customizable
(programatically) than that of HTML.

My main point is that "it depends". And to throw technologies out there
without knowing the full context of the solution is something that I thought
we designers have been fighting against for quite a long time.

I also think that Flash is still loosing it's battle among "serious"
development communities who are now looking to Eclipse and .NET as more
viable solutions with larger development communities to draw upon. Both
again have their issues, but if I am going to make an investment in a new
platform (as a CTO) Flash is the least attractive. As a designer, I love it,
but as a chief technologist, it is only slightly attractive. Flex helps, but
not enough for some reason.

-- dave

17 Apr 2005 - 1:45pm
Donna Fritzsche
2005

An earlier poster said,
>>. Ajax seems like a very clever use of JavaScript, but if the goal is RIA, I would say
> > use Flash or Flex which are intended to build RIA. There is a lot of JavaScript
> > out there that works only in IE or on Windows.

Dave said
> Yup, you got the gist, though I do find the use of the word "clever"
> in this case to be derogatory as opposed to good, or talented, or
> knowledgeable. .... This is NOT about "cleverness" but
> about darn-tootin', straight as an arrow, good programming skills.
> This is NOT about "cleverness" but
> about darn-tootin', straight as an arrow, good programming skills.
>

Dave,
Earlier you compared this skill to knowing the fine art of irony..

>"As in most things  "languages" don't cause problems, just how well someone
>knows how to speak it and knowing the fine arts of irony, sarcasm and idiom
>are the realm of the truly fluent. In the case of computer languages,
>sometimes you have to risk getting slapped in the face (so to speak) in
>order to find just the right line (of code)".

I had the same interpretation as the previous poster who called it cleverness.
The use of Irony, sarcasm and idiom are art forms in any language. For large-scale
deployment you need solid engineering (which may indeed be executed in an elegant
manner)

So, I am left sincerely wondering, does the language lend itself to the functionality
(w/o clever, nuanced lines of code) or is there really a better language that addresses
the problem space straight out.

I do think that an ill-advised choice of "language" can cause problems and choosing
the right one for the given context is very important. Yes, a screwdriver can be used as
a hammer, but different tools lend themselves to different tasks. (I dont think turing-
machine equivalence applies when choosing a computer language for large-scale
deployment.)

Curious if you or anyone else could help clear this up.

Donna

Ps Haven't yet read the paper by Luke and Frank, it looks very useful!

17 Apr 2005 - 4:45pm
Dave Malouf
2005

> Dave,
> Earlier you compared this skill to knowing the fine art of irony..
>
> >"As in most things  "languages" don't cause problems, just
> how well someone
> >knows how to speak it and knowing the fine arts of irony,
> sarcasm and idiom
> >are the realm of the truly fluent. In the case of computer languages,
> >sometimes you have to risk getting slapped in the face (so
> to speak) in
> >order to find just the right line (of code)".
>
> I had the same interpretation as the previous poster who
> called it cleverness.
> The use of Irony, sarcasm and idiom are art forms in any
> language. For large-scale
> deployment you need solid engineering (which may indeed be
> executed in an elegant
> manner)

Donna, the part that is most important in my quote you took is "truly
fluent". Command of language is what I was trying to say was the main
requirement, and that requirement is the same regardless of choice of
language (AKA Technology). I can screw up an application as easily in C++ as
I could in JavaScript.

Here is what I really think the difference is, and I'm re-iterating my last
post, it is about education. People are educated in fine "engineering" with
more complex languages like Java, C++, C# etc. And languages like PHP,
Python, JavaScript and ASP are left to informal training as the primary
means of acquisition. This means that those who are the most formally
educated coders aren't the ones doing this level of code. In most
institutions it is left to the "web designer" to do.

Now, I'm about to get hit w/ a flury of ... But but but Me!!!!

And I would say, I'm sure you are a fine coder, but in my experience, there
are those people who understand the engineering principals of Object
Oriented programming and those that don't. Even if JS is just Object Based
and not object oriented, there is much to be gained from the perspective of
a formal OO education that in most cases is not looked to when hiring a
mere-HTML/JavaScript person.

Basicaly, JS is not given the due attention by most people practicing it, so
few achieve the level of fluency I'm talking about.

So the misunderstanding that was had, that equated "irony" w/ "hacking", was
really misplaced, b/c I believe the exact opposite. That irony is more of an
egineering level skill than mere pun for example. ;) But the metaphor can be
taken too far. My point is about fluency. And I think that goes way beyond
"engineering".

-- dave

17 Apr 2005 - 5:13pm
Donna Fritzsche
2005

> My point is about fluency. And I think that goes way beyond
>"engineering".
>
>-- dave
>

I honestly dont know if we agree or disagree. But a couple of
related points - from my perspective:
1)In order to solidly engineer something (esp. in an elegant manner),
you need to be well-versed in, if not fluent with your materials,
language, etc.
2)One of the best ways to learn good OO practices is on the job with
a good team.

Thanks for following up - I dont know enough about javascript, etc.
to be able to address them specifically. I wouldn't be surprised
though if someone said that they dont provide a rich enough base to
cleanly meet all of the needs that are placed upon them - no matter
how fluent the programmer. (and I agree, you want the programmer to
be fluent).

Donna

18 Apr 2005 - 8:10am
Anastasia Fischer
2004

Donna said:
> Thanks for following up - I don't know enough about JavaScript, etc.
> to be able to address them specifically. I wouldn't be surprised
> though if someone said that they don't provide a rich enough base to
> cleanly meet all of the needs that are placed upon them - no matter
> how fluent the programmer. (and I agree, you want the programmer to
> be fluent).

In the environments I work with (large corps with strong security reqs) the
debate about fat/thin has been raging for years, with thin winning the
battle, but product managers not pleased with the lack of functionality. RMI
are only still being discussed by consultants as the corps are very slow to
address non "proven" techs, the main issue being strong security concerns
for transactions. Flash is not considered sufficient by the IT departments,
however there are whispers of considering .NET.

In the meanwhile however I see lots of 'thin' apps that have become
incredibly heavy due to JScript trying to replicate the RMI or fat clients.
These applications are all form based with significant content dependencies.
Product managers seem to hate wizards so they end up with these hugely
complex pages of JavaScript... which they have a very difficult time
debugging and managing. In addition I have found it difficult to get
developers to agree to modifications/changes to form-based apps that are
constructed with alot of JS.... especially if they use the layers (on of my
current pet peeves).

Most of the developers, as to David's point, see coding JS and HTML as
beneath them (and have very little fluency in CSS) so they don't do it with
perhaps the elegance (or attention?) that they might code something more
meaningful to them. As a result I am noticing a dearth of developers who
really are good at 'thin' client programming... and even more startling
there don't seem to be many people who are designing really good system
architectures to support these types of apps.

I am not a very sophisticated coder myself, but I am wondering if there
might be some fundamental difference in code that is compiled vs JavaScript
and HTML? I know that compilers really help developers iron out bugs.

Anyhow I am still back to fundamental questions about JavaScript... I have
never seen HTML crash a browser, but JS seems to have that ability. For some
strange reason the developers I have talked all seem to be mute on this
subject?!?!

Anastasia

-----------------
Anastasia Fischer

EEMedia.com
Customer Experience

Tel: 207.596.5549

Syndicate content Get the feed