Web-based or desktop app?

8 Feb 2005 - 9:30pm
9 years ago
21 replies
986 reads
Anjali Arora, NYU
2004

Hi. What are the arguments one would forward in favor of designing a web-based app as against a desktop one? What are the pros & cons of each?

Thanks.
-Anjali
---------------------------------------------------------------------
Anjali Arora,
Interactive Telecommunications Program,
Tisch School of the Arts, New York University
aa917 at nyu.edu
http://www.artbrush.net/

Comments

8 Feb 2005 - 9:54pm
Manu Sharma
2003

Anjali:
"What are the arguments one would forward in favor of designing a
web-based app as against a desktop one? What are the pros & cons of
each?"

:-)

We had a quite interesting discussion on this last month. Look up
threads titled "You Decide" and "The beginning of the end of the
desktop" in the archives.

Start from here:

http://listserver.dreamhost.com/pipermail/discuss-interactiondesigners.com/2005-January/thread.html#4227

http://listserver.dreamhost.com/pipermail/discuss-interactiondesigners.com/2005-January/thread.html#4347

Manu.

8 Feb 2005 - 10:16pm
Anjali Arora, NYU
2004

Thanks Manu, I had a vague feeling this had been discussed here on this list
recently.
-Anjali

----- Original Message -----
From: "Manu Sharma" <manu at orangehues.com>
To: "ixd-discussion" <discuss at ixdg.org>
Sent: Tuesday, February 08, 2005 9:54 PM
Subject: Re: [ID Discuss] Web-based or desktop app?

> [Please voluntarily trim replies to include only relevant quoted
material.]
>
> Anjali:
> "What are the arguments one would forward in favor of designing a
> web-based app as against a desktop one? What are the pros & cons of
> each?"
>
> :-)
>
> We had a quite interesting discussion on this last month. Look up
> threads titled "You Decide" and "The beginning of the end of the
> desktop" in the archives.
>
> Start from here:
>
>
http://listserver.dreamhost.com/pipermail/discuss-interactiondesigners.com/2
005-January/thread.html#4227
>
>
http://listserver.dreamhost.com/pipermail/discuss-interactiondesigners.com/2
005-January/thread.html#4347
>
> Manu.
>
>
>
>
>
>
> _______________________________________________
> 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/

9 Feb 2005 - 7:52am
Suresh JV
2004

-Anjali:
> What are the arguments one would forward in favor of
> designing a web-based app as against a desktop one?
> What are the pros & cons of each?

The following points may be considered:
*DeskTop App-DTA
*Web Based App-WBA

- Response time needs to be much faster in DTA
[Relative/percieved distance to server]
- Expection towards interaction are pretty standard in DTA
[Greater Error tolerence in WBA]
- The visual design is bound by the OS look and feel in DTA[until now!]
[Serious vs cool graphics, more options to emphasize branding in WBA]
- Expectation Drag & Drop functionality in DTA.
- Tolerence to Complex Interface in DTA as opposed to simple ones in WBA
- Longer Operation times in DTA [User tends to keep DTA open whole day]
- Longer Learning curves[DTA] vs short learning curves[WBA]
- Limted availability of Widgets in WBA.
- Option of Buy DTA vs Free use of WBA. [I think this is changing slowly]

- Cross Browser compatibility in WBA [ A major headache still]

PS: These would be user expectations. Not guidelines.

Regards,
Suresh JV.

9 Feb 2005 - 8:19am
DeleteMe
2005

On Tuesday 08 February 2005 10:30 pm, Anjali Arora, NYU wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> Hi. What are the arguments one would forward in favor of designing a
> web-based app as against a desktop one? What are the pros & cons of each?

WEB BASED

Pros :
Ease of deployment company-wide, since there is no software to install
Normally less resource usage on the client
More rapd development is usually possible
Ability to run the application on multiple platforms and architectures

Cons:
Interactivity is very limited to what you can do with JavaScript / DHTML *
Having to support multiple browsers can be a real pain
Everyone using the application must be on the network at all times
Need for a central serve rinfrastructure, and possibly an admin for those
servers and a DBA. Note that this may be required for the client-side version
as well, it totally depends on the purpose of this application.

CLIENT BASED
Basically, invert the two above :)

* You can get around this limitation using ActiveX and Java applets, but IMO,
once you get into this, it is no longer a real web based application anymore,
since it now has client code as well. MIght as well just do everything with
client code and provide a link to the setup program.

--
If you wait by the river long enough, eventually
you will see the bodies of all your enemies float by.
- Sun Tzu

9 Feb 2005 - 9:15am
Wilder, Bill FIIS
2005

Anjali,

The major advantage of a Web app (aka "thin client") is the
zero-deployment -- you don't have to keep client-side software
installations up-to-date (a complex, expensive endeavor). The major
advantage of a desktop app (aka "rich client") is the user interface can
be very sophisticated. In the past there was a choice between the two.

There is now a third category - dubbed "smart client" - available. Think
about this as zero-deployment + rich UI = the best of both worlds. From
an operations point of view, it is like updating a web site -- when a
new version is available, all of the "smart clients" automagically
re-download/re-install. From an interaction point of view, a rich /
sophisticated user interface can be developed.

"Smart client" support is a feature of Microsoft .NET and would be
appropriate for a corporate environment that had standardized on .NET
and other Microsoft platforms (which, of course, is common and becoming
increasingly common).

Good smart client discussion:
http://weblogs.asp.net/dphill/articles/66300.aspx

Cheers,
-Bill

-----Original Message-----
From: Anjali Arora, NYU [mailto:aa917 at nyu.edu]
Sent: Tuesday, February 08, 2005 9:31 PM
To: 'IxD Discussion'
Subject: [ID Discuss] Web-based or desktop app?

[Please voluntarily trim replies to include only relevant quoted
material.]

Hi. What are the arguments one would forward in favor of designing a
web-based app as against a desktop one? What are the pros & cons of
each?

Thanks.
-Anjali
---------------------------------------------------------------------
Anjali Arora,
Interactive Telecommunications Program,
Tisch School of the Arts, New York University
aa917 at nyu.edu
http://www.artbrush.net/

_______________________________________________
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/

9 Feb 2005 - 2:54pm
Andrei Herasimchuk
2004

On Feb 9, 2005, at 4:52 AM, Suresh JV wrote:

> - Expection towards interaction are pretty standard in DTA
> [Greater Error tolerence in WBA]

What do you mean by greater tolerance? Errors are errors and should be
tolerated equally regardless of WBA or DTA. And that is tolerated
little.

> - The visual design is bound by the OS look and feel in DTA[until now!]

This has never been true. Just going back through the history of
desktop apps on either Mac or Windows proves this point.

> [Serious vs cool graphics, more options to emphasize branding in WBA]

Again, just not accurate. The fact many in the DTA space don't take
advantage of "cooler" graphics does not mean there are less options to
do it.

> - Tolerence to Complex Interface in DTA as opposed to simple ones in
> WBA

I would disagree with this as well.

> - Longer Operation times in DTA [User tends to keep DTA open whole day]

People seem to leave windows open regardless of DTA of WBA, and if they
do, the time is fairly equal.

> - Longer Learning curves[DTA] vs short learning curves[WBA]

Entirely not accurate.

> - Option of Buy DTA vs Free use of WBA. [I think this is changing
> slowly]

What constitutes "free." Is using Amazon.com free? Is using eBay free?

> - Cross Browser compatibility in WBA [ A major headache still]

I think you are referring to issue around cross-platform, which
regardless of DTA or WBA have major blocks to make it 100% possible
without hassle.

Andrei

9 Feb 2005 - 2:55pm
Andrei Herasimchuk
2004

On Feb 9, 2005, at 5:19 AM, Jason Keirstead wrote:

> CLIENT BASED
> Basically, invert the two above :)

This is wildly inaccurate as a general statement.

Andrei

9 Feb 2005 - 3:00pm
Andrei Herasimchuk
2004

On Feb 9, 2005, at 6:15 AM, Wilder, Bill FIIS wrote:

> The major advantage of a Web app (aka "thin client") is the
> zero-deployment -- you don't have to keep client-side software
> installations up-to-date (a complex, expensive endeavor).

Then just how is it that both Apple and Microsoft are keeping people's
operating systems updated with the latest versions, bug fixes and
patches of applications?

> There is now a third category - dubbed "smart client" - available.
> Think
> about this as zero-deployment + rich UI = the best of both worlds. From
> an operations point of view, it is like updating a web site -- when a
> new version is available, all of the "smart clients" automagically
> re-download/re-install. From an interaction point of view, a rich /
> sophisticated user interface can be developed.

The term smart-client is Microsoft's way of trying to steal back an
application space they didn't make to market first. iTunes is a
web-enabled application. So is MusicMatch, World of Warcraft,
Everquest, poker apps, iLife apps, even some of Adobe's apps (although
the means with which it does it is very crude still) and the operating
system itself these days.

> "Smart client" support is a feature of Microsoft .NET and would be
> appropriate for a corporate environment that had standardized on .NET
> and other Microsoft platforms (which, of course, is common and becoming
> increasingly common).

It's appropriate for any application that takes advantage of being
connected to a network, .NET or not. If not, it just means the
application developer has to create all the backend technology
themselves.

Andrei

9 Feb 2005 - 3:04pm
DeleteMe
2005

On Wednesday 09 February 2005 3:55 pm, Andrei Herasimchuk wrote:
> This is wildly inaccurate as a general statement.

Er??

I don't see how. I discussed the pros and cons for Web apps above. The pros
and cons for client apps, with respect to the comparison, would logically be
the exact inverse of the above pros and cons.

You may think some of the pros and cons are invalid, but the statement
certainly is not.

--
If you wait by the river long enough, eventually
you will see the bodies of all your enemies float by.
- Sun Tzu

9 Feb 2005 - 3:08pm
Dave Malouf
2005

I tend to agree w/ Andrei that the reasons stated thus far are
predilections towards at best, but not true drivers in either
direction.

The only driver I can think of at this point, is deployability.
If there is nothing in your task process that requires the following:
Access to the local machine files system
Use of the registry (or whatever the Unix/Mac equivalent's are)

then HTML (this is what we mean by web-app right? is much more
deployable then a desktop (non-browser: HTML/HTTP) solution.

That being said, let me explain the limitations of deployability:
1. security on the user's computer is set high (sorry if I'm using
windows terminology)
2. the user is in a highly compliant environment where they aren't
even allowed to install applications, this includes Active X Controls
and Java WebStart apps

These are most common at the enterprise level of applications, and not
usually faced by the home user to any great consideration. Since I've
been living the enterprise world now for 4 years it is very strong in
my decision making process to have to make these considerations way
too often.

But from a pure GUI experience, there ain't nothing that an installed
application can/can't do that a Web-app w/ the propper coaxing can't
do at this point: DHTML is pretty amazing when you work it and there
are other non-HTML browser-based/HTTP-based (and non-HTTP-based)
solutions that are totally worth it over going to the C++/C# route.

I would NOT put .NET in the web-app category. Anything that requires a
23mb framework to be installed is not a thin app. ;) Arbitrary for
sure, but ya gotta draw a line somewhere. ;)

-- dave

9 Feb 2005 - 3:27pm
Dave Malouf
2005

On 2/9/05 3:00 PM, "Andrei Herasimchuk" <andrei at involutionstudios.com>
wrote:

> [Please voluntarily trim replies to include only relevant quoted material.]
>
>
> On Feb 9, 2005, at 6:15 AM, Wilder, Bill FIIS wrote:
>
>> The major advantage of a Web app (aka "thin client") is the
>> zero-deployment -- you don't have to keep client-side software
>> installations up-to-date (a complex, expensive endeavor).
>
> Then just how is it that both Apple and Microsoft are keeping people's
> operating systems updated with the latest versions, bug fixes and
> patches of applications?

I think Andrei is generally correct, but he isn't making a clear distinction
here. He is reacting to the literalness of Bill's message instead of the
intent.

There is a clear distinction worth making between initial deployment and
continuing maintenance.

Operating systems have their initial deployment was the purchase of the PC
in 99% of the cases. Even with that, many corporate environments turn off
auto-updates as they are a "risk" b/c often updates corrupt the "image".

Web applications do not have this advantage.

Even desktop apps don't have this advantage, but their deployment unlike an
OSes has a big upfront cost and as I mentioned in the earlier message this
has pretty big ramifications and considerations.

There are differences between thick and thin and to say that there are no
differences doesn't do anyone any good. The question is which one fits your
needs:
Users
Development
Marketing message

I do think though that Interaction Design and Web vs. Thick is becoming more
and more irrelevant once you say that your browser universe is ...
5.0 +
Can include plugins like Flash (but it doesn't even have to)

-- dave

9 Feb 2005 - 3:35pm
DeleteMe
2005

On Wednesday 09 February 2005 4:00 pm, Andrei Herasimchuk wrote:
> Then just how is it that both Apple and Microsoft are keeping people's
> operating systems updated with the latest versions, bug fixes and
> patches of applications?

It could be argued that Windows itself is a smart-client, in that it
automatically downloads and adds capabilities to itself.

> The term smart-client is Microsoft's way of trying to steal back an
> application space they didn't make to market first. iTunes is a
> web-enabled application. So is MusicMatch, World of Warcraft,
> Everquest, poker apps, iLife apps, even some of Adobe's apps

Just because an application is networked does not make it a smart client. A
smart client can swap itself out, in its entirety, with a new version, with 0
user interaction. ( It could be argued that WOW and Everquest do that, but
they don't really, since the underlying game engine and updater code is never
auto-updated ).

--
If you wait by the river long enough, eventually
you will see the bodies of all your enemies float by.
- Sun Tzu

9 Feb 2005 - 4:30pm
Andrei Herasimchuk
2004

On Feb 9, 2005, at 12:04 PM, Jason Keirstead wrote:

> I don't see how. I discussed the pros and cons for Web apps above.

Your pros and cons are inaccurate, imho.

> The pros and cons for client apps, with respect to the comparison,
> would logically be
> the exact inverse of the above pros and cons.

I know you claim this is true, and I claim its not. Your pros and cons
are not accurate, again, imho.

Andrei

9 Feb 2005 - 4:35pm
Andrei Herasimchuk
2004

On Feb 9, 2005, at 12:35 PM, Jason Keirstead wrote:

> It could be argued that Windows itself is a smart-client, in that it
> automatically downloads and adds capabilities to itself.

I know I was being presumptuous, but that was my point. The term
"smart-client" is just marketing-speak for Microsoft while they work to
get Longhorn out but want recognition for the fact they are working on
these kind of apps back in the labs. The fact, many apps do this stuff
today. The lines have been blurred and distinctions broken down.

> Just because an application is networked does not make it a smart
> client. A
> smart client can swap itself out, in its entirety, with a new version,
> with 0
> user interaction. ( It could be argued that WOW and Everquest do that,
> but
> they don't really, since the underlying game engine and updater code
> is never
> auto-updated ).

The iLife apps and iTunes apps also do that. when they update, the old
ones are tossed and replaced with new ones. As does MusicMatch and a
host of other apps. Again, that was my point.

Andrei

9 Feb 2005 - 4:46pm
Andrei Herasimchuk
2004

On Feb 9, 2005, at 12:27 PM, David Heller wrote:

> I think Andrei is generally correct, but he isn't making a clear
> distinction
> here. He is reacting to the literalness of Bill's message instead of
> the
> intent.

I'm not sure the benefit of dealing with intent when someone states in
a message:

"The major advantage of a Web app (aka "thin client") is the
zero-deployment -- you don't have to keep client-side software
installations up-to-date (a complex, expensive endeavor). "

That's simply an inaccurate statement. It's not necessarily a complex
and expensive endeavor and client apps also have "zero-deployment"
these days. I didn't say the statement was wrong, I was trying to point
out how I thought it was inaccurate. (Maybe I should have been more
direct?) And due to its inaccuracy, the "major advantage" purported in
the statement is also not really a major advantage.

> Operating systems have their initial deployment was the purchase of
> the PC
> in 99% of the cases. Even with that, many corporate environments turn
> off
> auto-updates as they are a "risk" b/c often updates corrupt the
> "image".

If you ever sell a large enterprise web-based app into a corporate
America, you'll find they don't take too kindly to large sweeping
upgrades without their consent either. The issue then to me becomes
that both DTA and WBA have issues around deployment that technically
are close enough to not be a technical or interaction issue if executed
properly. What matters is corporate culture and how IT wants to control
the applications, and that's a problem outside of the technical issues.

Andrei

9 Feb 2005 - 5:02pm
Andrei Herasimchuk
2004

For clarity's sake.

> WEB BASED
>
> Pros :
> Ease of deployment company-wide, since there is no software to
> install

There is software to install, it's just done on a server in one
location than deployed on multiple machines. There are plenty of means
and method to send out emails to company employees and instead of
providing a URL for a log-in, provide a link that starts the install
process on their machine. Once they have the client, then maintenance
is pretty-forward is the developer knows how to code it properly.

An icon in a Favorites folder is the same as an icon for the client
app. The issue is where does that icon live to the user, and how do you
get past that first "go here" problem to start the process of using the
application. If done well, this process is negligible on the difference
between getting started with browser based apps versus desktop apps,
with a large upside for desktop apps. But it requires being done
correctly, and installers are the most neglected of all applications in
the tech sector and most damaged by poor development, tinkering by
marketing people, and over-designed by so many of us.

> Normally less resource usage on the client

This is generally accurate, but it can depend on the kind of task and
the kind of application.

> More rapd development is usually possible

Just inaccurate. I've worked on enough desktop clients and web based
products to know that code gets developed quickly based on the bias of
the team. I've seen projects in web-based applications that thought
they were happening on quick schedules, felt like they were, but was
taking just as long as normal client development to the myriad of
browser issues, custom coding to make up for lack of functionality,
etc. Further, features sets tended to be smaller in web based products
to create the feel of faster development, but when compared to a
desktop client and comparable feature sets, took equal amounts of time.

> Ability to run the application on multiple platforms and
> architectures

Not a pro at all. The amount of time and effort it takes to make
something work across Mac and Windows is nearly the same as it takes to
make something work in IE, Moz, Firefox, and Safari on Mac and Windows
in my experience. The issues are different, but they are plentiful all
the way around. there's plenty of pain to share in this issue. Again,
what tends to be a problem here is lack of expertise on how to handle
cross-platform/cross-browser issues.

> Cons:
> Interactivity is very limited to what you can do with JavaScript /
> DHTML *

Agreed.

> Having to support multiple browsers can be a real pain

Given the range of issues on supporting cross-platforms as well, I
don't see this as a relevant point for either web or desktop
development. It's just part of the game.

> Everyone using the application must be on the network at all times

This would be true for desktop clients that rely on server information.
Like say a game like Everquest. Or a ticketing application for a travel
agency. So again, this issue is *outside* the confines of web or
desktop client development. (A crude example for using a web based apps
disconnected from the network.... I use MovableType on my laptop all
the time to test out an entire blog construction without being
connecting to any network.)

> Need for a central server infrastructure, and possibly an admin
> for those
> servers and a DBA. Note that this may be required for the client-side
> version
> as well, it totally depends on the purpose of this application.

Not a pro or con for either web or desktop. It's applicable to both.

> CLIENT BASED
> Basically, invert the two above :)

Given what I stated above, I claim this is statement is just inaccurate.

Andrei

9 Feb 2005 - 5:11pm
Dave Malouf
2005

On 2/9/05 4:46 PM, "Andrei Herasimchuk" <andrei at involutionstudios.com>
wrote:

> If you ever sell a large enterprise web-based app into a corporate
> America, you'll find they don't take too kindly to large sweeping
> upgrades without their consent either. The issue then to me becomes
> that both DTA and WBA have issues around deployment that technically
> are close enough to not be a technical or interaction issue if executed
> properly. What matters is corporate culture and how IT wants to control
> the applications, and that's a problem outside of the technical issues.

I'll ignore the possible inference of not having installed enterprise
software ... (I think Documentum Qualifies) ...

That put aside ... Not all enterprise is installed. Some is hosted AND even
when it is "installed" the installer doesn't necessarily control the entire
enterprise environment.

I agree that this is a technical/cultural issue based mainly in paranoia
akin to that of the US's President's insistence that we need more money to
fight terrorism than we ever needed to fight the Soviet Union during a cold
war ... Hmm?

But the cultural requirement is not going away (just like the US President),
so the reality is still there. You often say Andrei that you don't like
academic discussions, but it sounds like this is one.

REALITY: I maintain the design for a hosted document management system. Till
recently there was little to no need to access the OS/desktop from the
browser in any way that the browser does not already allow within its most
strict security models. It made total sense for us to remain an HTML-based
application.

New markets have arisen (or should I say new competitors) forcing us to add
functionality that changes the above so that it is now a requirement to give
the user the ability to treat the browser and desktop as one integrate
whole. We do not have time, budget, or RIO models that warrant a
re-architecting of the system so that the whole application would change to
a thicker client and traditional thin-client support Flash & Java by
themselves don't offer the appropriate level of support at least not within
some sort of installation being done of new software.

Installation of software is frowned upon by our market. They manage entire
images to the .dll level.

So!!! The design problem is really a balancing act as I expressed already
between:
1. Customer reality
2. Our abilities
3. market pressure
4. available technologies

So the design problem comes when you make a choice based on those 4 criteria
and then have to mitigate the problems associated with that decision since
it will not be perfect. I wouldn't call that an IxD design problem, but
definitely a solution crying from a designer of some type. ;)

Now does this problem face many many people?

At Documentum (which probably faces the same problems as SAP, FKA People
Soft, Seibel, etc.) we faced the problem of the platform, where we relied on
components that relied on 3rd parties such as Sun Java VM and if they were
updated before we were ready for their update, they might have caused
problems. We then need to have a way to re-deploy without requiring Admin
rights to the desktop. Otherwise Administrators go insane. So they like the
web-based solution so they can install once and run everywhere. Even the
"updates" require admin rights by the user in many cases.

I'm sure all this is in some way helpful to the original poster who was
looking for a set of criteria to make a decision. In the end you have to
make the call based on the 4 points I mentioned earlier.

Good luck!

-- dave

-- dave

9 Feb 2005 - 6:14pm
Andrei Herasimchuk
2004

On Feb 9, 2005, at 2:11 PM, David Heller wrote:

> I'll ignore the possible inference of not having installed enterprise
> software ... (I think Documentum Qualifies) ...

Sorry... I meant "you" as in general/plural. If we were writing in
Latin, that would have been explicit. 8^)

Andrei

10 Feb 2005 - 4:02am
Tadej Maligoj
2004

>> I'll ignore the possible inference of not having installed enterprise
>> software ... (I think Documentum Qualifies) ...

> Sorry... I meant "you" as in general/plural. If we were writing in
>Latin, that would have been explicit. 8^)

Or any other language but English ... ;+]

By the way, very interesting discussion. There is still a strong
belief about simplicity of Web based application even among the
engineers. Makes problems when deciding on strategic level as Dave
stated.

Tadej

On Wed, 9 Feb 2005 15:14:16 -0800, Andrei Herasimchuk
<andrei at involutionstudios.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> On Feb 9, 2005, at 2:11 PM, David Heller wrote:
>
> > I'll ignore the possible inference of not having installed enterprise
> > software ... (I think Documentum Qualifies) ...
>
> Sorry... I meant "you" as in general/plural. If we were writing in
> Latin, that would have been explicit. 8^)
>
> Andrei
>
> _______________________________________________
> 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/
>

--
_______________________________
Tadej Maligoj, Information Architect
e1: tadej.maligoj at gmail.com
e2: studio at maligoj.com
m: 031 306 986
w: www.maligoj.com

11 Feb 2005 - 1:58am
Suresh JV
2004

I did mention in the PS, that these would be from Users Point of View.
I pretty well agree with all the points you've mentioned from a developers
perspective.

Andrei:

> - The visual design is bound by the OS look and feel in DTA[until now!]

> This has never been true. Just going back through the history of
> desktop apps on either Mac or Windows proves this point.

[Suresh]
This is not about capability of designing. But more about the user
expectation of standard menus or controls in standard places.
In a WBA, the user still looks for consistancy rather than a
standard place.

.....................................................................
> - Tolerence to Complex Interface in DTA as opposed to simple ones in
> WBA

> I would disagree with this as well.

[Suresh]
In WBA, since the uptime of browser itself is linked to the money,
there will be an urgency to learn things faster. There would be no
such hurry in DTA. The user would typically spend more time with a
cooler head on a DTA. [no pressure of phone bill going up. ;)]

.....................................................................
> - Longer Learning curves[DTA] vs short learning curves[WBA]

> Entirely not accurate.

[Suresh]
Attributed to the uptime and phone bill.

.....................................................................
> - Option of Buy DTA vs Free use of WBA. [I think this is changing
> slowly]

> What constitutes "free." Is using Amazon.com free? Is using eBay free?

[Suresh]
Sorry. I had Salesforce/Timesheet kind of applications in mind. Atleast
here in my local context, people still expect free stuff on the web,
even if they buy a shrink wrapped software. [Even that is not a norm!] ;(

Suresh.

11 Feb 2005 - 7:33am
Dave Malouf
2005

I think your question Suresh then is about metaphor and not about
technology. Can you bring all the advantages (or disadvantages) of
traditional windows desktop apps to the web? Or is there an intrinsic
relationship that users have with the web browser that prevents the breaking
of expectations?

While at Documentum I managed the GUI of our web-based platform and
performed some 100 tests over 2 years on it. The one consistent result has
to be that ther was no consistent result regarding the use of desktop
metaphor in a web environment. Both "power-users" and "novices" alike
struggled with some aspects and enjoyed others. These aspects were never
consistent across any discenable patterned user-type.

The exception to the above, was that once in a web browser, the back-button
rules all. Breaking the back-button is the most frustrating thing you can do
to a user, and using "frames" (in quotes b/c you can use panels in DHTML and
it has the same effect on the back-button; try consistently using the
back-button in Gmail and you'll understand) automatically breaks the user
expectation of the back-button.

The other less correlated exception was that a menubar in the HTML part was
confusing to users (30-40%--I'd say significant). They often went up to use
the menubar of the browser itself.

I realize this isn't an answer to the question, but it does help ya think
about what to look for in your web-app designs; things that don't come up in
your desktop designs usually.

-- dave

Syndicate content Get the feed