On Thu, 18 Sep 2003, Max Cooper wrote:
I'll admit it -- my opinions on this topic are undoubtedly not mainstream.
But, when dealing with the realities of the technologies we have been
handed (HTTP and HTML), I don't buy the "deal with whatever the user
throws at you" dictum. It's not technically feasible in a general sense,
and it ignores the fact that many (I won't necessarily claim "most" unless
you are talking about intranet apps with controlled populations that you
can train directly) are willing to learn to abide by the rules -- IF the
app makes it easier to obey than to disobey.
> Date: Thu, 18 Sep 2003 18:28:39 -0700
> From: Max Cooper <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: Is it possible to remove *.do or /do/* from the URL
>
> I agree with Matt here wholeheartedly.
>
> If you build an app that runs in a web browser, your app should work
> properly in that environment. Asking users not to use the Back button is not
> a reasonable expectation, and trying to hide it with JavaScript or other
> hacks is folly.
>
By that argument, GUI apps should not ever disable menu options that are
not relevant to the current state of the computation either -- instead,
they should just leave the option enabled and "deal with it" when the user
selects it. :-)
> However, there are MANY, MANY questions about how to escape the
> responsibility of making our apps work properly in a browser on this list.
> And I know that the apps I have built aren't all perfect (even though I
> think it is a good goal to shoot for). The fact is that it is HARD to design
> an app for the web and implement it so that it works well in a browser.
Not only is it hard, its nearly impossible.
The closest analog to the back button in a traditional GUI app is the
"undo" menu option typically found on the "Edit" menu. Although it can be
challenging to program the mechanics of this facility, most robust apps
GUI based succeed -- for one or more of a number of reasons:
* They have fine-grained control over the amount of state that
gets restored (typically one edit) -- dealing with an entire
page is far too coarse grained for what users really want to do.
* They don't have any analog to bookmarks that let you both
abandon one complete line of computation and simultaneously
attempt to jump into the middle of a completely different
line of computation in one fell swoop. This is a MUCH more
serious issue than back buttons.
* They are fundamentally modal by nature, while browseable
web sites tend to be non-modal. In other words, the set
of state transitions that the user can initiate is very
tightly controlled by the application. The user has an
illusion of control because the number of possible actions
is often quite large, but random jumps throught the screens
isn't one of them.
> Part of me thinks the solution will NOT be that web developers all become
> willing and capable of making their apps work (more) correctly in a browser.
Perversely, I think we agree here :-). But the root problem isn't even
the willingness of developers to do the work -- it's the fact that the
goal is not achieveable without disabling some of the behaviors that
people are used to when they browse web sites.
> But rather that some other technology will come along that avoids client
> installation like a web app does, but also avoids some of the "web site"
> problems, and perhaps most importantly enables developers to write richer,
> more responsive GUIs. There are many technologies in this space, and I have
> no recommendations or even any clue as to which ones have a good chance of
> spreading. But I think something like this might "catch on" in a big way at
> some point.
>
Technical goodness won't make the slightest bit of difference. Widespread
adoption of something other than browsers would be a marketing issue, and
would have to be imposed on enough people (in the short run) to reach the
critical mass necessary to attract developers to that platform.
I don't see much changing in the near term -- current trends are much more
evolutionary than revolutionary.
> On the other hand, perhaps a "web site" is a good model for writing our
> applications. And that we should figure out strategies and design patterns
> to make our apps work correctly in this environment.
I strongly disagree. Web sites that are friendly to browsing impose no
multi-step ordering requirements on the user. Non-trivial interactive
applications (I'm not taking about adding a comment to a guest book; I'm
talking about adding an order to a database) have the same kinds of
ordering and transactional restrictions, whether you implement them in a
client-server GUI in your favorite language, or as a webapp. It's a
different beast.
> Web apps do have some
> pretty cool advantages -- for instance, you can send someone a link to a
> particular page/screen in the app. Our managers send out a link to the
> timesheet we have on our intranet. You can bookmark a particular screen or
> pages in an app that are most relevant to your activities for quick access.
> Having a web interface also means that your app can be scripted by simply
> making a HTTP requests, and perhaps looking at the responses. For these
> reasons, perhaps we should come around to the idea that all web apps are web
> sites, and take care to build them as such.
Good luck.
> Whatever the case, I think the bottom line is that if you are deploying your
> app to run on a browser, it should work correctly when the user presses the
> Back button, bookmarks a page, or decides to mess with the URL a bit. It
> isn't always easy to make the app work properly, but there should be some
> conscious thought about how to design the app so that it can work properly,
> and some care in implementation to make sure that it does work as well as
> the design allows. I have long wanted to write some "design patterns" to
> record good solutions to common problems (or anti-patterns for bad ones)
> that could be re-used by myself (when I forget, or when I need delegate) and
> others. It would also be useful to describe why a certain pattern works or
> why it is "good" about it to help raise awareness of the issues. But it sure
> is hard to find the time... perhaps if I stopped writing long, rambling
> email messages to the struts-user list I could get this done. :-)
>
I'd love it if such patterns were possible. I'm currently a skeptic.
In the mean time, a very large number of currently popular webapps are
dealing with back buttons by hiding/disabling them, or whining at the user
if they are used ("that page has expired"). I'd be interested in any
large scale webapps that you think operate in the preferred style with
regards to these issues, so we can learn something from them.
> -Max
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
