Difference b/w online & installed apps

29 Apr 2008 - 7:51am
6 years ago
6 replies
504 reads
Vishal Subraman...
2005

I'm designing Interaction models, process flows and interfaces for an
application that can potentially be an online app or an installed one
(depending on capability, performance needs). From a design perspective,
should there be a difference between the two? There are of course inherent
interface elements in each type and technical limitations with a browser
based app (that are fast disappearing?). A quick look at tools that exist in
both formats (word processors, presentations, spreadsheets, image editing)
shows little difference between the two.
--
-Vishal
http://www.vishaliyer.com

Comments

29 Apr 2008 - 9:16am
Michael Micheletti
2006

Hi Vishal,

I work in a real-time two-way communications domain, so I'm off at the edge
here. But I find there are a small constellation of functions that just
don't work now with browser-based applications without either employing
crazy architectures or shoveling massive traffic across the network.
Accessing network sockets, hooking multiple audio cards, audio mixing, disk
access, complex network routing and peer networking are (rightly) frowned
upon by browsers as security risks. The new Flash/Flex/Air and Silverlight
client capabilities take me somewhat in the right direction (you can get to
the local drives) but I still couldn't build our communications clients in
them, not even in the Flash/Flex/Air/Silverlight of the dreamy-look future
roadmap. Which is sad, because I want to.

If you are not working in a real-time domain though, these limitations may
not apply to you. You may be able to deliver a higher level of fit and
finish in an installed client, and it may allow your developers to maintain
internal state and so on more easily. But then it does need to be installed.
I heard long ago that the web didn't kill off client-server architectures
because the web was better, it killed them off because you didn't need to
install anything. So weigh application support costs into your equation.
Also consider the capabilities of your development team (including their
development aspirations - where they'd like to go) and the strategic focus
of your company. Hope this helps,

Michael Micheletti

29 Apr 2008 - 9:43am
Vishal Subraman...
2005

Michael,

I totally agree, these are the technical decisions that our dev team is
making. Photoshop won't be an online app in the near future, but there are
basic image editing programs that are.

I was asking from a IxD perspective (conceptually too). Say you're designing
an image editing tool that will be distributed both online and as an
installable s/w. Assuming there are no technical limitations, would they
behave any differently from each other?

--
-Vishal
http://www.vishaliyer.com

On Tue, Apr 29, 2008 at 11:16 AM, Michael Micheletti <
michael.micheletti at gmail.com> wrote:

> Hi Vishal,
>
> I work in a real-time two-way communications domain, so I'm off at the
> edge here. But I find there are a small constellation of functions that just
> don't work now with browser-based applications without either employing
> crazy architectures or shoveling massive traffic across the network.
> Accessing network sockets, hooking multiple audio cards, audio mixing, disk
> access, complex network routing and peer networking are (rightly) frowned
> upon by browsers as security risks. The new Flash/Flex/Air and Silverlight
> client capabilities take me somewhat in the right direction (you can get to
> the local drives) but I still couldn't build our communications clients in
> them, not even in the Flash/Flex/Air/Silverlight of the dreamy-look future
> roadmap. Which is sad, because I want to.
>
> If you are not working in a real-time domain though, these limitations may
> not apply to you. You may be able to deliver a higher level of fit and
> finish in an installed client, and it may allow your developers to maintain
> internal state and so on more easily. But then it does need to be installed.
> I heard long ago that the web didn't kill off client-server architectures
> because the web was better, it killed them off because you didn't need to
> install anything. So weigh application support costs into your equation.
> Also consider the capabilities of your development team (including their
> development aspirations - where they'd like to go) and the strategic focus
> of your company. Hope this helps,
>
> Michael Micheletti
>

29 Apr 2008 - 10:02am
Michael Micheletti
2006

On Tue, Apr 29, 2008 at 8:43 AM, Vishal Iyer <vishaliyer1 at gmail.com> wrote:

> I was asking from a IxD perspective (conceptually too). Say you're
> designing
> an image editing tool that will be distributed both online and as an
> installable s/w. Assuming there are no technical limitations, would they
> behave any differently from each other?
>

Hi Vishal, I'm not an authority but I'll do my best to answer your question.
Interested in hearing other viewpoints too.

Users of the browser-based version will push the back button every so often
- what will this do in an image-editing application? Will they be able to
bookmark specific images, or just the application entry point? Will there be
a browser history different from an application history of recently edited
images? Will you have related links or advertising in a downloadable client?
Will other websites link to your downloadable client, or only to your web
application?

I suppose the single thing most different experientially about browser-based
applications and stand-alone applications is that the browser is itself an
application; my guess is that the browser is considered to be _the_
application and your image editing app is considered a website. Even though
I should know better, I think about gmail (which I'm using now to edit this
message) in much the same way. If your web application doesn't work like
other web applications and sites, it looks "broken" even if it isn't. A
stand-alone application needs to behave with logical internal consistency,
but it doesn't need to act like a website. Does this help? All the best,

Michael

29 Apr 2008 - 11:25am
Vishal Subraman...
2005

The browser until now has been primarily an information
exchange application, hence the bookmarks, back button, refresh, history
etc. With the rapid increase in task based applications over the web, the
next generation browser (and front-end scripting) will potentially further
reduce reduce the gap between online and installed apps.

-Vishal
www.vishaliyer.com

> Users of the browser-based version will push the back button every so
> often - what will this do in an image-editing application? Will they be able
> to bookmark specific images, or just the application entry point? Will there
> be a browser history different from an application history of recently
> edited images? Will you have related links or advertising in a downloadable
> client? Will other websites link to your downloadable client, or only to
> your web application?
>
> I suppose the single thing most different experientially about
> browser-based applications and stand-alone applications is that the browser
> is itself an application; my guess is that the browser is considered to be
> _the_ application and your image editing app is considered a website. Even
> though I should know better, I think about gmail (which I'm using now to
> edit this message) in much the same way. If your web application doesn't
> work like other web applications and sites, it looks "broken" even if it
> isn't. A stand-alone application needs to behave with logical internal
> consistency, but it doesn't need to act like a website. Does this help? All
> the best,
>
> Michael
>

--
-Vishal
http://www.vishaliyer.com

29 Apr 2008 - 12:25pm
Jeff Garbers
2008

On Apr 29, 2008, at 1:25 PM, Vishal Iyer wrote:

> The browser until now has been primarily an information exchange
> application, hence the bookmarks, back button, refresh, history etc.
> With the rapid increase in task based applications over the web, the
> next generation browser (and front-end scripting) will potentially
> further reduce the gap between online and installed apps.

We're certainly seeing a blurring of the old distinctions between
browser-based and installed applications. Installed ("native") apps
often have embedded HTML controls, use underlined blue text to
indicate command or navigation options, and so on. Rich browser-based
applications provide local interactivity without reloading pages, or
even a strong notion of a "page". And "site-specific browsers" like
Fluid (http://www.fluidapp.com) add a new twist.

I wonder, though, how users' understanding of how things usually work
on Web sites affect their expectations in browser-based applications,
and how that impacts usability of those applications. For example,
drag-and-drop is ubiquitous in native apps, especially on the Mac, but
uncommon (although increasing) among Web-based apps. A similar
situation exists with shortcut keys, modal dialogs, and toolbars with
labeled (or unlabeled) icons. However, toolkits like Ext (http://extjs.com/
) appear to be leading us to reproduce the UI conventions of native
apps in browser-based applications.

In browser-based applications, we also have the possibility of users
being confused about whether they're controlling the app or the
browser. For example, does pressing Command-S (or Ctrl-S) tell my Web-
based word processor to save my document, or does it tell my browser
to save the page? If the app has its own menu and toolbar, won't that
make it a lot harder to support, since we'd constantly have to be
making a distinction between the app's controls and the browser's
controls ("which 'save' button do I click?")?

Apps like Backpack and Basecamp from 37 Signals are, in my opinion,
pretty usable, although they don't look at all like their desktop
counterparts. Instead, they follow Web conventions for the most part,
with client-side interactions where they really usability.

So my questions for the list are:

1) Does making browser-based applications behave like native apps
enhance their usability?

2) Does the answer to question #1 vary based on what kind of
application it is, or who's using it?

3) Is it reasonable to expect users to abandon or at least suppress
their Web-based expectations when using browser-based applications?
For example, is it OK to expect them not to use the back button, not
to open links in new tabs or windows, not to bookmark pages, etc.?

29 Apr 2008 - 4:09pm
peter roman
2008

Hi Vishal,

A lot of the work we've done here at Picnik.com has been to ensure that
our app is a good web citizen. Meaning, back and forward buttons do in
fact navigate as expected, users can in fact create bookmarks to
specific tools, and perhaps most importantly, the app does everything it
possibly can to fit inside of a single, resizable web browser window.
That last bit has proven crucial, especially in a lot of our third-party
integrations. Facebook, for instance, only gives us 640px across to work in.

In terms of basic UI controls (sliders, input fields), we haven't seen
any point to reinventing things. The main thing to keep in mind, though,
is that these controls will need to work cross browsers and more
importantly cross OS (unlike a pure desktop app that would likely adopt
the system's controls) so they need to be very recognizable as what they
are. The default Flex skin is pretty awful in this respect.

Outside of the web browser vs desktop shell, an offline version of
Picnik probably wouldn't change much. Granted, in our case we've already
got a well-established online app, but why force people to re-learn
things? With Flex and AIR, we've got some wonderful opportunities to
achieve a level of consistency between desktop and web that hasn't been
possible before.

Best of luck,
-peter

--
www.picnik.com
blog.picnik.com

Vishal Iyer wrote:
> Michael,
>
> I totally agree, these are the technical decisions that our dev team is
> making. Photoshop won't be an online app in the near future, but there are
> basic image editing programs that are.
>
> I was asking from a IxD perspective (conceptually too). Say you're designing
> an image editing tool that will be distributed both online and as an
> installable s/w. Assuming there are no technical limitations, would they
> behave any differently from each other?
>

Syndicate content Get the feed