Oh god, what will I have stared with this post...

R

Ryan Stewart

Brian Kildea said:
I understand your point, but I think the answer here is very much dependent
on one's requirements. For example, I don't develop sofware for use by
100,000 "visitors". My applications are used by a very small community of
specialists, and there is on-line help, users manuals and training courses
that are developed to accompany the application. Many in this community
wrongly assume that every other project is just like theirs meaning that
*everyone* is writing applications for the whole Internet user base.

I will admit to having a preference for Swing. Some of it has to do with my
feeling that I can develop richer, more intuitive interfaces with Swing than
I can with what's available in a browser. That can serve my clients well --
maybe not everyone's, but mine. I also spent endless hours 3 years ago
trying to work around slight variations in browsers, and their Javascript
bugs that remained unfixed for many versions. I also hated the continuous
conversion between Javascript, HTML forms and server side "languages",
complicated by the lack of strong typing in any of these technologies. I
can do more than twice as much in half the time with Java and Swing and
create a much more bug free application. Surely one can argue that that
best serves the client -- in my case the paying client and the operators are
not the same. I think I serve them both well in this regard.
Yes. As has been stated by myself and others, including the post you replied
to, requirements should determine your tools. This thread started with Mr.
Eamer asking whether we would choose Swing or some web-based technology. My
answer is yes. I would choose one or the other based on what I'm expected to
develop. (Possibly something else, but these cover our needs pretty well at
the moment.)

As an aside, how is JSP any less strongly typed than Java? Oh, wait. You
said it's been 3+ years since you worked with web-based applications? Check
out some of the new stuff. At least give JSP a look.
 
A

Andrew Thompson

Brian Kildea said:
about ....
I understand your point,

I suspect not.
...but I think the answer here is very much dependent
on one's requirements.

And therein lies the hint. No - it does not depend
on "one's" requirements, it depends upon an ill
defined number of persons including the users
themselves, the entity funding the coding, UI
useability testing teams, '401' compliance
testing and advice teams (for an US gov.
entity)....

If I were the employer of a IT specialist
that was advising how "one's requirements
for an IT system were best served by..x, y
or z" ..I would want an independent opinion
that could couch the answer in terms of
"the _organisation's_ requirements are best served.."
...For example, I don't develop sofware for use by
100,000 "visitors". My applications are used by a very small community of
specialists, and there is on-line help, users manuals and training courses
that are developed to accompany the application.

On-line help and user manuals can both be done
in html. 'training courses'? What does that mean?

If you use web-cams to push video through an
very fat intranet from the learning user to the
teaching tutor, you could justify wrapping a
Java GUI around it, is that what you are doing?
Many in this community
wrongly assume that every other project is just like theirs meaning that
*everyone* is writing applications for the whole Internet user base.

Perhaps, but I had intranet applications in the
back of my mind when I made that post,
I decided not to mention for the reason
that "it's on an intranet" is no more reason
to justify a fat client than if it had been on
the net, you are still left with the question,
but what best suits the _user_.

Your wondeful swing application may leap
onto the screen in .9 seconds, but I'd warrant
if my thin client arrived in .7, the users would
prefer it, intranet or no intranet.
I will admit to having a preference for Swing. Some of it has to do with my
feeling that I can develop richer, more intuitive interfaces with Swing than
I can with what's available in a browser. That can serve my clients well --
maybe not everyone's, but mine. I also spent endless hours 3 years ago
trying to work around slight variations in browsers, and their Javascript
bugs that remained unfixed for many versions.

Now ..this is interesting. One of the advantages
of an installed client base is generally a consistency
of browser/JavasScript availability/JVM version..

Now you introduce how you hated the
inconsistencies of JavaScript across different
browsers?!? Try this..
http://www.google.com./groups?&q=jvm+compatibility
You'll find some of those links relate to
incompatibilities in JVM's..
...I also hated the continuous
conversion between Javascript, HTML forms and server side "languages",
complicated by the lack of strong typing in any of these technologies. I
can do more than twice as much in half the time with Java and Swing and
create a much more bug free application.

(and it's fatter!)
Surely one can argue that that
best serves the client -- in my case the paying client and the operators are
not the same. I think I serve them both well in this regard.

I, I, I, I, I, I, one, client, paying client, operator, I, I....

Not a good sign that _you_ are customer focused.

The more you say, the more you make the case
that UI requirements should be determined by
somone who is _not_ the developer.
 
B

Brian Kildea

Andrew Thompson said:
I suspect not.


And therein lies the hint. No - it does not depend
on "one's" requirements, it depends upon an ill
defined number of persons including the users
themselves, the entity funding the coding, UI
useability testing teams, '401' compliance
testing and advice teams (for an US gov.
entity)....

If I were the employer of a IT specialist
that was advising how "one's requirements
for an IT system were best served by..x, y
or z" ..I would want an independent opinion
that could couch the answer in terms of
"the _organisation's_ requirements are best served.."


On-line help and user manuals can both be done
in html. 'training courses'? What does that mean?

If you use web-cams to push video through an
very fat intranet from the learning user to the
teaching tutor, you could justify wrapping a
Java GUI around it, is that what you are doing?


Perhaps, but I had intranet applications in the
back of my mind when I made that post,
I decided not to mention for the reason
that "it's on an intranet" is no more reason
to justify a fat client than if it had been on
the net, you are still left with the question,
but what best suits the _user_.

Your wondeful swing application may leap
onto the screen in .9 seconds, but I'd warrant
if my thin client arrived in .7, the users would
prefer it, intranet or no intranet.
with

Now ..this is interesting. One of the advantages
of an installed client base is generally a consistency
of browser/JavasScript availability/JVM version..

Now you introduce how you hated the
inconsistencies of JavaScript across different
browsers?!? Try this..
http://www.google.com./groups?&q=jvm+compatibility
You'll find some of those links relate to
incompatibilities in JVM's..


(and it's fatter!)


I, I, I, I, I, I, one, client, paying client, operator, I, I....

Not a good sign that _you_ are customer focused.

The more you say, the more you make the case
that UI requirements should be determined by
somone who is _not_ the developer.

--
Andrew Thompson
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site

My aren't we holier than thou! I admit my preference to Swing. It's too
bad you cannot do the same for your infatuation with thin clients. However,
your fondness for thin clients does prove your point well: UI requirements
should be determined by somone who is _not_ the developer.

My client controls the server, every client that runs the application and
the network between them. He has the whole freakin' Gigabit Ethernet to
himself at every installation; it is a closed system. This also means that
I have no JVM compatibility problems either. The requirements are not
originated by me. They are the ones given to me by the client. Thus, they
constitute my requirements in the same sense someone might be given one's
marching orders. It is perfectly correct English; you should try it.

Swing, Java and CORBA have served us very well. We would be happy to adopt
other technologies as our client requires. However, these technologies have
served *him* and *his* customers well.
 
B

Brian Kildea

Ryan Stewart said:
with
Yes. As has been stated by myself and others, including the post you replied
to, requirements should determine your tools. This thread started with Mr.
Eamer asking whether we would choose Swing or some web-based technology. My
answer is yes. I would choose one or the other based on what I'm expected to
develop. (Possibly something else, but these cover our needs pretty well at
the moment.)

As an aside, how is JSP any less strongly typed than Java? Oh, wait. You
said it's been 3+ years since you worked with web-based applications? Check
out some of the new stuff. At least give JSP a look.

Thanks Ryan. Yes, unfortunately JSP wasn't really an option to me at the
time. It was not my intent to suggest that it's not. I would be interested
in taking a closer look at it. Ditto for J2EE. The project I work on now
began 6 years ago. Web technologies have come a long way in that time.
What my billable time does not expose me to I try to become familiar with
through tinkering and classes. My tinkering's been focused on the embedded
world for the last three years.
 
A

Andrew Thompson

...UI requirements
should be determined by somone who is _not_ the developer. ....
Swing, Java and CORBA have served us very well. We would be happy to adopt
other technologies as our client requires. However, these technologies have
served *him* and *his* customers well.

If the customer is happy, everybody is happy. :)
 
S

Scott Ellsworth

Andrew Thompson said:
Where in this thread did we 'swing'
(yeh ok, bad pun) from what's best
for the client, to what the developer
wants?

Ofttimes, a developer's wants are based on experience. Not always -
sometimes we just make stuff up, but if the developer has a bias, I
usually listen before rejecting it.

I, like most consultants, usually understand the technologies and
options better than my clients, or they would not be paying me
consulting fees. They virtually always understand their own needs and
problem space better than I do, or they would find a different business.
(I may be clever, but they do what they do all day, every day. Hard to
beat that much focus.) Thus, turning their requests into technology
proposals is a major part of my job, and making sure that they know the
implications is a close second. Not rocket science - I suspect every
good developer does that.

As a developer, I find that Swing is a good solution to most UI
problems, but I have used other tools as well. I use Cocoa when I can,
but that is not an option for a cross platform app. I like WebObjects
on the web, but servlets are usually lighter weight. I delivered one
web app in Perl with Mason, because they also wanted a Perl API for the
functionality. When I wanted a thick client, I have had many problems
with applets even when I controlled the environment, and relatively few
with WebStart.

Pure server side web technologies tend to be outgrown surprisingly
early, at least in my experience. When we can keep it simple enough for
a web app to be a good tool, it has a lot to reccomend it. That said,
the apps do not stay that simple in distressingly many cases. All too
often, the proof of concept works great as a web app, but they then want
a whole new feature set for the released product that pushes us into the
thick client space.

So, when I tell a client that I lean towards WebStart based Swing apps
for most tasks, it is not arbitrary. I love it when a web app can be
used as the solution, but I do not stick with it beyond its lifetime. I
consider it key to make the client aware of how much further they can go
with a thin client model, so they get to make the call. If nothing
else, Swing apps are more complicated.
I'd prefer to have a thin web client
used by 100,000 visitors, to a Swing
UI with advanced widgets that can
be accessed by only 10, 10,000 or
99,000 web surfers.

Agreed, as long as you expect 100k visitors. An app with complicated UI
requirements might not be feasible to expose to the web at large, but
might do just fine for an intranet app.
If you don't need anything more, stick
with the thin client, in order to best serve
the _client_.

Agreed completely - a thin client is much easier to maintain. I have
just had too many cases of scope creep that made the thin client
unreasonable. Thus, serving the client means knowing when to move to a
thicker technology.

Scott
(e-mail address removed)
Java, Cocoa, WebObjects and database consulting
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top