When a desktop programmer tries to write database applications
for the browser, he faces a great many challenges, both technical
and cultural. Both sets of challenges appear because the browser
and the web were invented for purposes different than our own.
On the technical side we must reinvent huge amounts of functionality
that we got "for free" with the old desktop systems of Foxpro, Delphi,
VB Classic and so on, and on the cultural side we must wade through
mountains of irrelevant or downright damaging advice that is aimed
at people working on the next version of Facebook or eBay.
In this essay we look at as many of these challenges as I can
muster.
Why A Desktop Developer Would Move to The Web
When the browser first appeared, it totally lacked the technical
powers required to replace desktop applications. Nevertheless,
some programmers immediately began to
ponder how to move into the world of the browser. The reasons were
simple then, are simple now, and have not changed:
- Far easier deployment -- nothing to install.
- Worldwide access -- businesses with multiple locations are
suddenly much easier to take care of.
- You could now create a public website and give customers and
vendors limited access to certain information.
- Operating System independence. This is far more of a reality
now than we dreamed it might be in the darkest days of
Microsoft's Total World Domination, but there were visionaries
early on who saw the possibilities.
So there are many programmers, and I am one of them, who continue to
work on the same kinds of applications we did before the web existed,
but who now deploy these applications in the browser, for the reasons
listed above. Here now is our tale of woe and sorrow!
The Cultural Divide
While desktop programmers were scratching their heads
and trying to figure out how to fit into
this new world, a new
generation of programmers was growing up who were
perfecting this new platform and developing applications
that were undreamed of before. Unfortunately, some of
the good advice they dreamed up is either irrelevant
or counter-productive to the database programmer who
is deploying to the web.
The driving reality for the database application programmer
is that her users are not surfing. They are using
a dedicated program written for the purposes of the business
they work for. Most of what the browser can do is either
not necessary or positively in their way, and the browser
lacks productivity tools that they took for granted
in "the old system." This fact is central to the
cultural divide between application programmers and
web programmers.
The Infamous Back Button Problem
If I surf over
to www.osnews.com and click on an article, when
I am finished I click "BACK" once or twice until I'm back
to osnews, and then pick another article. But to the
application user, who is not surfing but is using
a dedicated program, who has clicked "New Patient", typed in
the info, and clicked "Save", the back button is a positive
menace. It is misleading and dangerous. This has led
to who-knows-how-many rants from web programmers telling
application programmers, "You don't understand the web,
you shouldn't write it that way," in which the desparate
application programmer replies only, "but you don't
understand, I must have it work this way." The simple
fact is that when a user is modifying data in a browser
there is no concept of BACK. There may "UNDO" or "REVERT",
but once the data is saved it is saved. This is why
application programmers resort to trying to hide or disable
the button, or why they think they should be able to modify
the history (which of course they cannot do because that would
be a huge security hole for public sites).
Ajax only Makes The Back Button Worse
Picture a
user on the customers screen, who then goes to the menu
and picks the vendors screen. They work for five
minutes on the vendors screen, and their wonderful snappy
AJAX application is fetching search results and navigating
from row to row and saving changes. Then they decide they
made a mistake and hit [BACK] and wham! they're on the
customer screen! It seems that the better the applications
become, the worse the [BACK] button becomes. In my own
shop we have finally decided to have the login program
pop up a new window which does not have the [BACK]
button or the address bar. This is considered heresy
by web programmers (you don't understand the web! they
cry) but of course what is true for them is not true
for us, and vice-versa.
This also leads to much work. We must provide for
such features as UNDO with no native support in
the browser, and worse, with whatever native support
the browser does have been intended for something
totally different.
Your Application Must Work Without Javascript
This is dead wrong for the application programmer.
Application programmers have a power that is
totally outside the experience of a pure web
programmer: we can dictate system requirements to
the customer. This led to many unhappy problems
before the web, but with Firefox (and firebug!) we
now have a platform that is free and robust. We
simply install Firefox (or instruct the IT
department to do so) and we have a platform that
we know will support our application.
Keyboard Shortcuts
Nothing illustrates the divide between the web
and the desktop like keyboard shortcuts.
When Windows 95 swept the
office world (but before the web really came into
its own), programmers developed a new term for
applications that required constant use of the
mouse: we called them "mousetraps". The worst
kind of mousetrap program requires the user to
constantly lift their hand from the keyboard and
go to the mouse, then back again. This is fatiguing,
confusing, and terribly counter-productive for the
end user.
But the real problem is that the browser
was born a mousetrap. From the perspective
of the desktop programmer, keyboard shortcuts are
clearly an afterthought, a "red-headed stepchild"
as they say. Native HTML supports only the
ACCESSKEY attribute, and recently Firefox was changed
so that the default key combination is CTRL+ALT
instead of ALT. This small change led me to finally
realize that these folks, to put it mildly, have
never lived in my world and haven't the slightest
clue what my users need. I could expect no help
from them on this front.
The solution for the web programmer is to
remember my users are not surfing, they are using
a dedicated program. Therefore it is the
Right Thing for the application programmer to
hijack the CTRL-N key and have it mean "New Patient"
(or New Customer, New Vendor, etc)
instead of opening a new browser window. Moroever,
he must kill the CTRL-N so that it does nothing
on a page where there is no [New] button.
If he does not, then sometimes CTRL-N
will create a new patient, and sometimes it will pop
up a new window with my.yahoo.com! So the application
programmer confidently rewires the "standard" browser
keys and has happier customers for his effort.
Technical Problems In the Browser
No Default Focus
Have you ever gone to a website where the first thing you
must do is log in, but the user id input does not have
focus? That is a sure sign that the page was written
by a web programmer with no desktop experience.
When you put a database program into the browser, you
expect the user to be typing constantly, looking things
up, adding information, and so forth. So the application
programmer must ensure that his first control always
receives focus. Call it petty if you like, but without
it your program becomes a mousetrap. Perfection comes
by concentrating on these small things that either
annoy or please users.
Tabbing Off to Mars
Default browser behavior is to allow the user to TAB
through controls in the order they were created.
This can be modified by explicitly assigning TABINDEX
attributes to the control. However, when you get to
the last control, the browser then Tabs you up to the
menu, or the address bar, or anywhere else.
In a business application, where the user is not
surfing the web, this is wrong. Tabbing out of
the content area is equilivant to exiting the
application, it throws the user into a context that
they do not need and (sad to say) do not understand.
When I first began deploying business apps in the
browser I would get calls saying, "it's frozen" or
"i'm typing and nothings happening" and other such
mysterious claims. Once I observed the users I realized
they were "tabbing to Mars", the focus was up on the
menu or in the address bar or somewhere else equally
irrelevant. So we created the idea of the "Tab Loop",
so that when the user hits TAB on the last control it
loops back to the first. This completely ended
those calls.
The Tower Of Babel
Desktop programmers have a luxury undreamed of by
web programmers: they can do all or nearly all of
their programming in a single language, like
classic Visual Basic, Foxpro, or Delphi (or heck,
COBOL or 4GL!). Most of
these programmers also know SQL, but it is not seen
as a burden to learn it, it is just part of the
job.
But when the application programmer moves to the web,
he is confronted with at least four systems he must
grasp if he is to perform as a master crafstman:
(X)HTML, CSS, Javascript, and one or more
server languages like
Ruby, PHP, Java, etc. These different technologies
all have syntaxes
and philosophies that are different from each other
and from past experience. All I can say is I'm
glad I made the effort but I sure as heck hope I
never have to make a change that dramatic again.
Let's Not Talk About State
When an application programmer moves to the web,
he is confronted with the totally alien concept
that he cannot maintain state. This idea has been
discussed much in past years, and I suspect it may
not be the problem it once was, as most of us have
long since gotten past it. I did not want to leave
it out completely, but it is way too large an issue
to discuss in a paragraph and I doubt anyway that I
could add to the wisdom that is already out there.
Lousy Widgets
The HTML SELECT element stinks. Every serious
application programmer either downloads a
replacement or writes his own replacement. In
the old world of the desktop we did not have to
do such things.
The final piece of the puzzle in my shop was
jQuery.
The irony of jQuery is that it seems to me
its core function is DOM traversal and
manipulation, but its elegant simplicity has
drawn creative minds to do things like create
really nice widgets for entering time.
In my shop we finished off our desktop-in-browser
framework by using jQuery extensively, this
solved lots of our lousy widgets problem.
Salvation In the New Javascript Frameworks?
I should mention the new frameworks that are
emerging for desktop-in-browser, such as
extJS and
Dojo, not to
mention of course the
Yahoo!
User! Interface! Library!.
In my case I set out on the task of doing browser-based
applications four years ago, when none of these
technologies existed. So I developed my own simple
browser-side framework. jQuery let me round off the
rough edges, and now I have no need of a
third-party framework. So I am afraid I cannot offer
any experience in the use of these others.
But even so, if I could use somebody else's dedicated
work and put my efforts elsewhere, that would only
be wise, so I continue to watch them closely.
When Do Application Programmers Accept
Advice From Web Programmers?
Does all of this mean that we application programmers
can learn nothing from web programmers? Of course
not, that we be arrogant in the extreme.
The answer is that when we enter the world
of the public website, we must seek the advice and
guidance of the experts in that world. So when I
write the public portion of the application, the
part that is visible to customers, vendors and other
trading partners, I have to follow the standards of
common practice: the back button has to work, Javascript
should be optional, it should work on IE (arg),
and so on and so forth.
Conclusion: When Worlds Collide
The desktop application programmer who decides to
deploy business applications in the browser will
face two broad challenges: techical and culturual,
both of which stem from the origins of the web,
which are so different from the origins of the
desktop. The technical challenges tend to center
around features of the browser that are either
lacking or downright counter-productive, and this
is made worse because the advice a programmer will
receive comes from a culture whose goals are very
different from his own. The database programmer who
wants to deploy applications in the browser must
be prepared to reproduce a lot of features we took
for granted in the desktop, and he must also be
prepared to filter through the received wisdom
and throw out anything that does not meet the
needs of his end-users.
Addendum: After reading a few comments on ycombinator.com I should probably stress that the job of getting the application into the browser is completely doable (in fact I've done it myself). The browser can now easily handle the job of desktop applications. The OP lists the hazards I and many other have faced and overcome in getting there. A big part of the conclusion is that it is a lot easier to get done if you recognize why it seems so hard: which is that you may be getting advice from people whose goals are very different form yours.
"http://database-programmer.blogspot.com/2008/07/history-tables.html"
>Next Essay: History Tables
Update Contact :
No Wa/Telepon (puat) : 085267792168
No Wa/Telepon (fajar) : 085369237896
Email : Fajarudinsidik@gmail.com
No Wa/Telepon (puat) : 085267792168
No Wa/Telepon (fajar) : 085369237896
Email: Fajarudinsidik@gmail.com
atau Kirimkan Private messanger melalui email dengan klik tombol order dibawah ini :
