Skip to main content

a question about basic libraries and "cosmestic" ones ... (OT ?)

35 replies [Last post]
dags
Offline
Joined: 2003-06-10
Points: 0

Hi,

That will be a long post, maybe a little OT. But I needed to ask the experts.

I was wondering why there is a lot of work and libraries related to laf, painters, visual effects, etc and too few about some basic and fundamental issues (from my point of view, of course) like making a quick, easy to code database connected form or report.

From my work experience, I think that most systems in most bussines follows some form of Paretto's law: the 80% of important issues or functionality are handled by 20% of programs (or less). The remaining 80% of programs deals with auxiliary (lookup) tables maintenance and things like that. All needed, but not the "core" of the bussines. Something that needs to be done very quickly to have more time to devote to bussines goals.

From my early programming days, I was told that I should acomplish functionality first and, once done, improve presentation later.

I used to code, still do it, in C language using some third party libraries which let me draw the form (an ascii file), positioning "screen" fields and setting the name of the database field each "screen" is linked to. I can start data entry inmediatelly using an ad-hoc program to "run" the form.

If a database field was referencing a lookup table (foreign key) that libraries showed something like a combobox filled with the values of lookup table. All I had to do is use a "IN " keyword in form code. This "combobox" let me find and select elements in the list, without any further coding. All in character mode. It was developed in Unix systems with dumb terminals. (remember Wyse 60 terminals ?).

Each "screen" field could have some properties : screen field name, database field name, foreign key table, some basic validation rules (not null, <, >, not in (value1, value2, ..., value N), in (value1, value2, ..., valueN), between X and Y. Easy, indeed.

I know, there were no object - relational issues because database was some sort of ISAM db. Now, Java and databases have great features and some complications too, but for many bussines system, it should be a great time saving feature something like this "form editor" and "form interpreter". Something like iReport form data entry forms.

I most java lists there is a recurring question: how to make a simple desktop data entry form, with basic capabilities. I can do one with swing and JDBC, but what if a have to do 20, 30 or 50 of them ?. What about some basic validation ?. I think there is need for a really simple solution, XML free.

"Form Editor" already exists, and is really, really good : Matisse.

I was trying to find the "Form Interpreter" part (or code generator) that make me works faster, without luck. Besides, I don't have the time (neither brain, I guess :-) ) to code it myself. Maybe someone knows something like that. Please give me a link, an idea or a opinion.

Regards,
Diego.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
rah003
Offline
Joined: 2004-05-26
Points: 0

> apps, where people use them for, say 80% of there
> day, effects and animations could get bothersome.

Your FF example there was right to the point, yet I have to say that I have users who work with the applications 80 and more % of they daytime and they demand those effects. And this is not a rare case. It just depend where and how any kind of effect it used. As Romain and others pointed out when changing views, you can use transitions to help people keep track of what is moving where. When there is lot of tabular or text data, it is less obtrusive for user to highlight place of interest for them by letting it flash few times rather then popping out annoying message box and so on. It all depends on a use of any kind of feature and generalization to all effects in all business apps is very dangerous. Just because one can kill with a knife, doesn't mean all knifes are bad.

> However, the real issue is usability (and then to
> some extent, user taste - some folks like snazzy apps, some just want to see gray all day.) A usable
> app is not always a plain app, and vice versa.

Amen to that. I think this is the key point.

> I'll also note in the business world, it is harder to
> justify spending time to add effects to the apps when other things need to be done. But thats
> where its good to know how effects enhance the user experience, and how you can fit them in without overdoing it.

Actually, in my experience it is quite contrary. Specially (but not exclusively) when you deal with the managers or not-so-computer-literate customers, it is much easier to justify development time for a feature/app which delivers nice UI then for one that had cool and efficient data processing or algorithm behind but visually sucks. Same is true for the user experience. If the processing on the backend takes while, they are happy to wait as long as UI stays responsive and informs them that something is going on and there is a progress on the task.

... sorry for the rant.

dags
Offline
Joined: 2003-06-10
Points: 0

I am a BIG fan of swinglabs team too !.

Sometimes it seems that there is a sort of divorce between what applications developers need and tools/libraries developers wants to do or think it is needed. Of course open source tools developers can do whatever they want, it is always welcomed. But maybe, just maybe, an improvement in communications between apps developers and tools developers could lead to a better development environment. Netbeans team seems to understand this very well.

There must be always some developers experiencing new things, no matter how strange or pointless seems to be. It is a fundamental part of progress and evolution, I guess.

A tools developer should have strong experience developing applications (bussines applications f.i.) or should have a n experienced application developer as partner, I guess.

Anyway, swinglabs project is really interesting and I am learning a lot each day. Just wanted to point my surprise for the slow advance in some topics I consider a "must" and to get some feedback to keep learning.

At least in my country and working environment, most of the work is related to traditional bussines applications: accounting, order entry, invoicing, inventory, claims processing, etc. Most of that apps could get initially more benefits from databinding, easier form and report processing than painters and other presentation improvements. After getting the apps working, presentation improvements are the next logical step, of course.

There is another item that doesn't get the attention I think it deserve : integration of swing applications with workflow and rules engines.

All is needed. Maybe the priorities are the issue.

Regards,
Diego.

rasto1968
Offline
Joined: 2004-08-25
Points: 0

> At least in my country and working environment, most
> of the work is related to traditional bussines
> applications: accounting, order entry, invoicing,
> inventory, claims processing, etc. Most of that apps
> could get initially more benefits from databinding,
> easier form and report processing than painters and
> other presentation improvements. After getting the
> apps working, presentation improvements are the next
> logical step, of course.

Yes, I agree 100% with you here. I would guess a large proportion of swing apps are business focussed, and hence their needs for 'shiny' interfaces are minimal - they want something that is easy for (possibly) low skilled workers to use and 'shiny' stuff can be a bit of a distraction in these cases. I would love to add some of the flashy GUI effects to my apps, but I know exactly what reaction I would get from my users.

Consumer oriented apps are a different story and this is where I see the more advanced swingx stuff really fitting in. The sort of applications that have been showcased on http://community.java.net/javadesktop/ show just how good swing based apps can now look.

Cheers
Rob

osbald
Offline
Joined: 2003-06-13
Points: 0

Rob, What we're talking about is wether you extend your ui components from JDialog, JFrame or JPanel in which case the we refer to the as having a is-a relationship. i.e. is-a Component (re JComponent). This is generaly frowned upon thse days (find Jeanettes ImperialRules page in the wiki). Mostly because it dosn't make any sense to extend a JDialog unless you're modifying the behaviour of a Dialog box or Panel in some way.. OOD basics really.

The alternative is to get the view part of the UI from a normal Object, Builder, BeanInfo, Factory or whatever. Which we refer to as a the has-a relationship (has-a Component). The current project I've been working on uses the latter. Have to say it does tend to throw some stubbling blocks your way if you're overly used to creating lots of anonymous listeners which rely on access to protected inner state.. On the otherhand overcoming those obsticles tends to encourage loser coupled code and offers greater scope for reuse. Although we lack much documentation and samples for the latter and mostly gui builders, tutorials and books tend to plum for the former. ugh!

The BeanForm is what you need to find hidden in Netbeans (ref: http://forums.java.net/jive/thread.jspa?forumID=74&threadID=20837&messag...)
like I say you have to get to know Netbeans quite well to make it work and avoid acciently attaching listeners, useless list & tablemodels and the like.

- Richard

Message was edited by: osbald

Scott just beat me to it.. damn.

rasto1968
Offline
Joined: 2004-08-25
Points: 0

Scott/Richard thanks for the explanations - I hadn't seen these problems described in this manner before, I know it as encapsulation vs. inheritance.

Cheers
Rob

kleopatra
Offline
Joined: 2003-06-11
Points: 0

Rob,

> seen these problems described in this manner before,
> I know it as encapsulation vs. inheritance.
>

exactly - the "vs." can't be emphasized enough :-)

An example of how (arguably) inappropriate inheritance can introduce subtle and hard-to-understand misbehaviour is core's DefaultTableCellRenderer:

- a CellRenderer is-a provider of a configured component for drawing a part of a larger component.

- to configure the provider makes use of the component's public setter methods for visual properties like color, font,... This must be done in each call to getXXRendererComponent - the only entry point into the provider. So all the properties the provider cares about are kind of volatile, living during the configuration and "shortly" afterwards (the assumption is that the usage of the component like drawing happens in or very near the next code line after requesting the component)

- core Swing opted for subclassing a JLabel to implement the renderer interface: the resulting class is-a JLabel and is-a CellRenderer.

(following is guess-work, wasn't there :-)

- enter a new requirement: colors should be configurable on the default renderer level. Unfortunately, this need happened in a period of api-freeze - so no way, sorry, can't do ...

- ... except maybe ... there is already a method setBackground(..) so it was overly tempting to override and add the side-effect to set the new configuration color.

- at this point trouble started: the new color property was required for the renderer role, but implemented in the label role, thus mixing concerns. Consequently, the configuration during the getXXComponent didn't work any longer (reminder: the renderer uses the component methods to configure) which required the really nasty workaround to call super's setters.

- and the trouble surfaced with SwingX Highlighters: they play with component's only, can't know about the role mixing and happily (and rightfully) call the component's setters - thus leading to the infamous "color memory" issue #258-swingx ;-)

Yeah, this could have happened with an implementation using delegation to a label as well - but maybe not: the different roles would have been more clear and maybe the task tagged as "impossible-without-api-changes".

end-of-sermon

Cheers
Jeanette

osbald
Offline
Joined: 2003-06-13
Points: 0

So spake the keeper of the Imperial Rules (g)

http://wiki.java.net/bin/view/Javadesktop/SwingLabsImperialRules

- Richard

Scott Violet

jdnc-interest@javadesktop.org wrote:
> Yeah I know that Scott, but its not as well supported and its a bit of a
> pain adding accessors to the BeanForm private fields. Also find the GUI
> builder loves to reset models, borders, text strings (after using the
> I18N tool) etc.. at at whim.

Be sure and file bugs on these problems. I'm not sure if the NetBeans
guys are aware of them.

> You can't deny it's really geared towards
> is-a.

That I can't deny, and it's a battle I've been fighting. Sadly I'm losing:(

> What bothers me more though is double-clicking on anything creates
> various inner listeners on the fly where I'm after sharing common code /
> Actions & ActionManagers and having a separate presentation model with
> beans binding (one day I hope!) Find Netbeans a real pain to work with
> when you want to do something ever-so-slightly different from slapping
> down a few ad-hoc components and listeners.

NetBeans will get first class support for 295 and 296. The 296 support
will make it more natural to use Actions, and 295 will make it easy to
bind various properties. Or so we hope;)

-Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

osbald
Offline
Joined: 2003-06-13
Points: 0

Sounds good, wasn't expecting any JSR 296 support I'd just supposed that was more of a JDK 7 timescale. Realised after my first posting that injecting actions would allow for some sharing.. but it isn't clear how useful injection sharing might be. Suspect it'll push part of the problem onto unique naming schemes.. But hey if it can make my life easier.

rasto1968
Offline
Joined: 2004-08-25
Points: 0

> While not obvious, NetBeans also supports the has-a
> component, vs is-a
> component model when using Matisse. And yes, I agree
> that has-a is the
> 'right way'.

Scott,

Could you possibly explain the difference between these two terms as I would like to make sure I'm not using the wrong one ;)

For anything other than simple OK/Cancel type buttons I tend to not let Netbeans generate the listener code - I have been using plain actions but recently discovered the usefulness of action maps so I am trying to use these more now.

Cheers
Rob

Scott Violet

jdnc-interest@javadesktop.org wrote:
>> While not obvious, NetBeans also supports the has-a
>> component, vs is-a
>> component model when using Matisse. And yes, I agree
>> that has-a is the
>> 'right way'.
>
> Scott,
>
> Could you possibly explain the difference between these two terms as I
> would like to make sure I'm not using the wrong one ;)

This has gotta to be explained on the web some where, but I'll go for a
quick description. If not enough, try googling. Both of these
descriptions refer to class hierarchy. If you form is-a-JComponent, then
it extends JComponent, if it has-a-JComponent, then your form has a
field of type JComponent that Matisse will layout. Here's simple code:

public class IsAJComponent extends JComponent {
}

public class HasAJComponent {
private JPanel panel;
}

Why does this matter? When other parts of your app get a handle to your
form, do you want them to see all the JComponent API on your class? Or
do you want to force them through a narrow API that exposes just what
you want them to see.

> For anything other than simple OK/Cancel type buttons I tend to not let
> Netbeans generate the listener code - I have been using plain actions
> but recently discovered the usefulness of action maps so I am trying to
> use these more now.

How you wire components is orthogonal to has-a vs is-a relations. You
should be able to choose between the two without changing your code to
wire listeners and actions.

-Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

evickroy
Offline
Joined: 2004-07-23
Points: 0

> A popular solution must involve a simple, high level
> framework that hides all individual libraries
> configurations and issues and free the developer from
> that boring tasks.

I believe that is where Netbeans 6 comes in to hide that complexity without restricting the developer too much.

Erik

osbald
Offline
Joined: 2003-06-13
Points: 0

> I believe that is where Netbeans 6 comes in to hide that complexity without restricting the developer too much.

Have to say I don't care for the kind of UI code Netbeans produces and the kind of coding it encourages.. It's very keen on the extends JComponent and tightly coupled listener spaghetti.

After finding BeanForm I've been slightly happier although I have to compromise a bit to get at the form and Netbeans is a bit clunkier with them.

I'd very much like to see Binding.. like last week ;) JSR 296 looks pretty interesting as a bunch of common utility methods although it dosnt tackle the wider architecture & pattern issues. The injection should save some typing, but I'm not sure how the action annotations will pan out.. suspect they might emcourage that old school code style all over again. Action Management and knowing where to put the EDT/Swingworker code are two of my constant irritations. Currently I'm putting EDT (remote method calls/jdbc mostly) stuff in my view components, because my models shouldn't need to know about Swing - maybe I need another wrapping model layer that does?.

- Richard

Scott Violet

jdnc-interest@javadesktop.org wrote:
>> I believe that is where Netbeans 6 comes in to hide that complexity without restricting the developer too much.
>
> Have to say I don't care for the kind of UI code Netbeans produces and
> the kind of coding it encourages.. It's very keen on the extends
> JComponent and tightly coupled listener spaghetti.

While not obvious, NetBeans also supports the has-a component, vs is-a
component model when using Matisse. And yes, I agree that has-a is the
'right way'.

-Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

osbald
Offline
Joined: 2003-06-13
Points: 0

Yeah I know that Scott, but its not as well supported and its a bit of a pain adding accessors to gat at the BeanForm private fields / view components. Also find the GUI builder loves to reset models, borders, text strings (after using the I18N tool) etc.. at at whim. You can't deny it's really geared towards is-a.

What bothers me more though is double-clicking on anything creates various inner listeners on the fly where I'm after sharing common code / Actions & ActionManagers and having a separate presentation model with beans binding (one day I hope!) Find Netbeans a real pain to work with when you want to do something ever-so-slightly different from slapping down a few ad-hoc components and listeners.

I supposed you could try and use the free custom code pre & post prompts Netbeans leaves you but it's deeply frustrating not to mention I'm sure it fails to keep the form files in-sync with things like refactoring. Had a similar issue when I tried out the Platform RCP the wizards were all very well & good but when I moved a few packages about everything broke down because the crucial (and numerous) RCP xml files weren't included in the refactoring - quickly decided I couldn't work like that.

- Richard

Joshua Marinacci

> What bothers me more though is double-clicking on anything creates
> various inner listeners on the fly where I'm after sharing common
> code / Actions & ActionManagers and having a separate presentation
> model with beans binding (one day I hope!) Find Netbeans a real
> pain to work with when you want to do something ever-so-slightly
> different from slapping down a few ad-hoc components and listeners.

The new Action support for JSR296 will aleviate this somewhat. For
menu items, command buttons, and toolbar buttons you will now be able
to use annotated action methods. You put the methods wherever makes
sense for your code and the NetBeans will find the actions and let
you choose which one should be attached to your components. Nothing
is hard coded because it will go through the action maps. This makes
it very easy to rewire components. It also means you'll be able to
have a global list of actions that you can sort through and edit the
text, tooltips, icons, etc. all in one standard place. I think you'll
find it makes your life a lot easier.

- Josh

- Blasting forth in three part harmony!

[att1.html]

osbald
Offline
Joined: 2003-06-13
Points: 0

Certainly sounds interesting, I'm not sure I follow "define @Action annotations anywhere that makes sense to your code" which makes them sound kinda static/singleton beasts. Have me wondering about scope and context.

Given the has-a style I'll often need to pass an context (presentation model) of some sort into my actions and often end up with a hierarchy of action types. Because to the context thing actions may be created dynamically for the lifetime of a single dialog.. they're not always simple static things that could be looked up by name.. e.g. the "DoubleClickAction" I habitually attach to JLists ActionManager which'll be customised for each lists model/data.

But I'm only second guessing until I see some code.. Screenshots? not screenshots what a tease (g)..

- Richard

(Josh's missing post)

> Yup. JSR 296 will be available as a standalone jar
> as well as in JDK 7. 296 support in NetBeans is
> my fulltime job right now so I can assure you
> we'll have it.
>
> The advantage of injection and the annotations is
> two fold. First, separation of concerns. Your
> code can include only an @Action annotation. You
> don't need to set the properties there. This lets
> you pull all of that declarative junk (stuff which
> might need to be translated anyway) into resource
> bundles. This makes your code very clean,
> containing only useful code statements that focus
> on what you really want to do, rather than gui
> stuff. It's much like CSS which lets you separate
> content from layout.
>
> Second, with injection the IDE (NetBeans in this
> case) can handle a lot of the boiler plate code
> for you. You write your action method by hand an
> annotate it. Then the IDE can find it and bind it
> to components graphically, as well as manage the
> resource bundles (putting them in the right
> place, handling locales, etc.) It will greatly
> speed up development time and let you focus on
> what really matters, your code that actually does
> something.
>
> I think you'll be pretty happy with it. I'll be
> posting screenshots of our progress soon.
>

evickroy
Offline
Joined: 2004-07-23
Points: 0

> > The lack of those basic ease of use features is
> why Java is almost
> > non existent on the corporate desktop and why .NET
> rules that domain.
>
> While there might be a hint of truth there I would
> not be as
> definitive. I've seen many corporate Swing apps and
> very few .NET ones.

I guess it depends on your area. The reverse is true for me. The region I am in, most desktop apps are .NET. From discussions with other developers, this seems mostly due to lack of RAD development with databound components in Java. I know that is what has hampered adoption of Java on the desktop at our company.

It's beyond frustrating that Netbeans now has training material like this for the web, but still nothing exists for Swing along these lines:

"Training
Using Databound Components to Access a Database
In this tutorial, you use the NetBeans Visual Web Pack 5.5 integrated development environment (IDE) to create and deploy a web application that displays master-detail data from a database that is bundled with the IDE. In the application, you select a person from a drop-down list, and the application displays a table that shows all the trip records for that person. Read more ..."

Erik

Romain GUY

> I guess it depends on your area. The reverse is true for me. The
> region I am in, most desktop apps are .NET. From discussions with
> other developers, this seems mostly due to lack of RAD development
> with databound components in Java.

I could not agree more! Hopefully this will soon change.

> "Training
> Using Databound Components to Access a Database
> In this tutorial, you use the NetBeans Visual Web Pack 5.5
> integrated development environment (IDE) to create and deploy a web
> application that displays master-detail data from a database that
> is bundled with the IDE. In the application, you select a person
> from a drop-down list, and the application displays a table that
> shows all the trip records for that person. Read more ..."

Time to launch a start-up? :)

>
>
> Erik
> [Message sent by forum member 'evickroy' (evickroy)]
>
> http://forums.java.net/jive/thread.jspa?messageID=196943
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>

--
Romain GUY
http://www.curious-creature.org
http://www.progx.org

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

dags
Offline
Joined: 2003-06-10
Points: 0

I agree with most of comments. I know about jsr295 and 296, about jgoodies excellent libraries, about future Netbeans databinding support and most of mentioned projects. I have even initiated some threads about that issues in the past and participated in some coding projects (http://swingset.sourceforge.net/, f.i).

The fact is, and that was what I wanted to state, that is a "too quiet" arena, compared with "fancy" features projects.

If this lack is recognized as an important factor of poor java presence (desktop apps, better later that never ?) in corporations and bussines world, shouldn't it deserve a more commitment to solve it ?. What happened with "release sooner, release often" ?. I volunteer to do some testing and maybe even some code contributions, if that kind of resources is an issue.

Finally, I am very happy to have comments and answers from some of swing "popes". Thanks.

Regards,
Diego.

Message was edited by: dags

dags
Offline
Joined: 2003-06-10
Points: 0

One aditional comment:

I think that having several libraries to perform databinding, validation, etc., is an approach that will be used only by a limited number of developers. Every added library contribute to increase application's complexity and require to learn a lot of things rarely used. Maybe JSR 296 will handle this.

A popular solution must involve a simple, high level framework that hides all individual libraries configurations and issues and free the developer from that boring tasks.

Regards,
Diego.

jancarel
Offline
Joined: 2004-03-11
Points: 0

Im am a longtime forum watcher and with some frustration I can tell you we have been here before a few times.
For me, I would have liked to have the databinding sooner and the JXLoginPanel later.
Guess we will have to hold our breath a lot longer and wait for something workable to come out of the Java camp.
In the meantime we can always use another programming environment.

kleopatra
Offline
Joined: 2003-06-11
Points: 0

> Im am a longtime forum watcher and with some
> frustration I can tell you we have been here before a
> few times.
> For me, I would have liked to have the databinding
> sooner and the JXLoginPanel later.

agreed - but if it were as easy as a loginPanel, we would have binding for ages ;-)

> Guess we will have to hold our breath a lot longer
> and wait for something workable to come out of the
> Java camp.
> In the meantime we can always use another programming
> environment.

Just curious - do you?

Cheers
Jeanette

jancarel
Offline
Joined: 2004-03-11
Points: 0

> > In the meantime we can always use another
> programming
> > environment.
>
> Just curious - do you?
>
> Cheers
> Jeanette

Hi Jeanette,
Of course not, Java is my chosen environment! I admire the work the SwingLabs team are doing, but sometimes can't help expressing my opinion that a data entry framework / binding / validation / forms should have been available sooner.

Kleopatra

> Of course not, Java is my chosen environment! I admire the work the SwingLabs team are doing, but sometimes can't help expressing my opinion that a data entry framework / binding / validation / forms should have been available sooner.

good answer, exactly what I wanted to hear

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

srnm
Offline
Joined: 2003-06-10
Points: 0

Coming late to this thread...

The work that has been done on Aerith, mac-like 3D effects, painters etc. is important. Kudos to Romain and everyone working on these things for bringing the "sexy back" to java on the desktop.

However, I have to say that for my applications it is mostly irrelevant -- except for the side-effect of increasing the attention on java on the desktop.

Desktop apps for "knowledge workers" don't, in general, need these things. I don't know if my apps are typical. The last 3 apps I have written are trading related and have active and concurrent domain models. I have developed a code-base and set of design and usage patterns for the way that I use swing that produces stable and maintainable apps but I can't say that it was "easy".

A well-supported application framework with databinding would really be helpful.

After that a rich set of "easy to program" data-aware information presentation tools like richer tables, tree tables, pivot tables, date pickers, calendars, graphs, and charting would all be useful.

I've been using swingx builds for well over 18months now, when it was still jdnc, and am a heavy user of JXTable and all it's extra features: sorting, highlighters, rollovers, filtering...

I almost switched away from swingx some months ago when I realised that pretty much nothing that I had read about published schedules had come to pass, and the demos/downloads weren't working and that the "scattered" state of the documentation and websites had not really improved despite some effort to fix the problems.

But I'm back to using the weekly builds on a new application. So far so good and have to say that the components I use work well, have been stable, and only require a small amount of manual "tracing" through the source for me to figure out how to use them. Thanks to the swingx team!

However, as a point of comparison, the eclipse team deliver stable milestones every 6 weeks with excellent documentation. I have given serious consideration to SWT/JFace/RCP for my last two apps for this reason alone. A stable platform with a well-planned future and a feature-set focused on delivering "business application functionality" is a powerful magnet. In the end I decided to stay with Swing because I have been using it since before 1.0 and I know swing too well and don't have time to learn a new toolkit.

So now I'm building another Swing application, but this time with an OSGi/Spring foundation. And it's coming along very well.

I can't live without:
JXTable
JFreeChart
JGoodies Looks (although JTattoo looks good too)
JGoodies Forms
l2fprod's property sheet

and Spring, joda-time, and JMS, although they're not UI-related.

I use a couple more features from swingx: JXRadioGroup, swingworker, JXTreeTable, but was very cautious before adopting them. Also, recently ditched a 3rd party "docking" library in favour of JXMultiSplitPane and so far very happy with it. If I had a swing app framework and databinding toolkit I'd use them.

Hope this is useful, and apologies in advance if anything I said doesn't do justice to the efforts made by someone. Just calling it as I see it...

Thanks again,
srnm

Message was edited by: srnm

Message was edited by: srnm

gfx
Offline
Joined: 2003-06-14
Points: 0

>they want something that is easy for (possibly) low skilled workers to use >and 'shiny' stuff can be a bit of a distraction in these cases

If the "shiny" stuff is distracting then it's been used in a wrong way. I totally understand what you're saying, but nothing prevents a business app to look good. Which doesn't mean you should have annoying effects everywhere.

rasto1968
Offline
Joined: 2004-08-25
Points: 0

> >they want something that is easy for (possibly) low
> skilled workers to use >and 'shiny' stuff can be a
> bit of a distraction in these cases
>
> If the "shiny" stuff is distracting then it's been
> used in a wrong way. I totally understand what you're
> saying, but nothing prevents a business app to look
> good. Which doesn't mean you should have annoying
> effects everywhere.

I didn't mean that the app shouldn't look good, its more that quite a lot of the 'shiny' stuff that I see demo'ed at the moment doesn't, in my opinion, really have a place in a business focussed application. In most cases, users of business apps want to get something done as quickly and hassle free as possible and things like fading menus, animated layout transitions, reflections etc. just get in the way.

Sure, you could add an option to turn all of these off so that when you demo your app it looks nice and 'shiny' but when users actually use it they get a nice quick interface - but all this adds extra effort in coding/testing and in my resource constrained environment (a team of one ;)) I just don't have time for this.

I love looking at all the new stuff that is being done and I do try and find sensible ways in which I can apply it to my solutions, I like the highlighter effect on JXTables/Lists and I have also used you infinite progress glass panel to disable my app when appropriate. I guess I'm just a frustrated consumer app developer at heart, I want to write something that looks like iTunes, Aerith etc. but unfortunately I have the wrong target audience :(

A good example of distracting 'shiny' stuff in the wrong place is the new MS Office Vista interface - I find it much less intuitive than the old Office XP interface. Sure it looks nice, but I certainly don't find it easier to use/learn.

Cheers
Rob

Bill Snyder

Rob, I agree with some of your points about business apps. In those types of
apps, where people use them for, say 80% of there day, effects and
animations could get bothersome. For instance, I probably wouldn't use
tabbed-pane fades or list-selection fades excessively in those types of
apps. ( If firefox faded tabs everytime I switched, I would get a headache.)

However, the real issue is usability (and then to some extent, user taste -
some folks like snazzy apps, some just want to see gray all day.) A usable
app is not always a plain app, and vice versa.

I'll also note in the business world, it is harder to justify spending time
to add effects to the apps when other things need to be done. But thats
where its good to know how effects enhance the user experience, and how you
can fit them in without overdoing it.

--Bill

On 1/25/07, jdnc-interest@javadesktop.org
wrote:
>
> > >they want something that is easy for (possibly) low
> > skilled workers to use >and 'shiny' stuff can be a
> > bit of a distraction in these cases
> >
> > If the "shiny" stuff is distracting then it's been
> > used in a wrong way. I totally understand what you're
> > saying, but nothing prevents a business app to look
> > good. Which doesn't mean you should have annoying
> > effects everywhere.
>
> I didn't mean that the app shouldn't look good, its more that quite a lot
> of the 'shiny' stuff that I see demo'ed at the moment doesn't, in my
> opinion, really have a place in a business focussed application. In most
> cases, users of business apps want to get something done as quickly and
> hassle free as possible and things like fading menus, animated layout
> transitions, reflections etc. just get in the way.
>
> Sure, you could add an option to turn all of these off so that when you
> demo your app it looks nice and 'shiny' but when users actually use it they
> get a nice quick interface - but all this adds extra effort in
> coding/testing and in my resource constrained environment (a team of one ;))
> I just don't have time for this.
>
> I love looking at all the new stuff that is being done and I do try and
> find sensible ways in which I can apply it to my solutions, I like the
> highlighter effect on JXTables/Lists and I have also used you infinite
> progress glass panel to disable my app when appropriate. I guess I'm just a
> frustrated consumer app developer at heart, I want to write something that
> looks like iTunes, Aerith etc. but unfortunately I have the wrong target
> audience :(
>
> A good example of distracting 'shiny' stuff in the wrong place is the new
> MS Office Vista interface - I find it much less intuitive than the old
> Office XP interface. Sure it looks nice, but I certainly don't find it
> easier to use/learn.
>
> Cheers
> Rob
> [Message sent by forum member 'rasto1968' (rasto1968)]
>
> http://forums.java.net/jive/thread.jspa?messageID=198238
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>
[att1.html]

dags
Offline
Joined: 2003-06-10
Points: 0

I agree with Rob's comments.

And more. In of my customers there has been, for many years, a character based application to invoice walk-in customers. It is unix based. Operators are really, really fast making an invoice, and that is what is needed to improve customer's "shopping experience". Operators did a lot of improvement requests in the past to achieve that. They don't need to use the mouse neither TAB key. Just number pad, ENTER and some cursor keys in most cases. F1 sometimes to get a searchable list of product codes or other lookup table.

Now, management wants a "modern" interface so they will be migrating to a .NET or VB application. Well, someday maybe. They are 8 months behind schedule. Yes, I am out of that project.

That makes me face a challenge: to code a similar invoicing application, with similar data entry speed but with improved user interface and usability. Best of both worlds. Mouse must be really an option and work sould be done with just a few keystrokes.

My surprise is that seems to be very few people with same goals or requirements. I see everyday people using that windows based (VB, .NET, even Java) bussines systems in wich a simple task, like making an invoice to a recurring customer, requieres a lot of mouse clicks and screen changes. Maybe operators didn't get proper training. Maybe is a poor system design. Maybe is just my "old-fashioned" mind seeing troubles where didn't exists. But numbers don't lie. It is faster the character based application.

Could some "user interface" expert make some comments on this issue ?.

Thanks,
Diego.

rbair
Offline
Joined: 2003-07-08
Points: 0

Hi,

I've been reading this thread, just observing everybodies feedback. I'm afraid I don't have much to comment on. What is there to say? Here are some basic criteria I'm looking at:

- Lots and lots and lots of data entry apps have been written in Swing
- Databinding, Appframework, etc will be great improvements. They are *high* priority items and, even though you may not see the work, they are being worked on by many individuals.
- Flash, Flex, XAML, Cocoa and such are very successful in the "whizzy" department. Swing shoulda/coulda/woulda been the ideal GUI toolkit for whizzy effects. Only a few critical pieces are missing (animations, effects, etc).
- Whizzy demos spark interest. Google maps, for instance, drives the AJAX fire. There are other ways to view/use a map, but they provided a killer user experience.

There are other ideas that could be built in this space. I'd like to see a real Validation framework along the lines of what Karsten has done. However, some pieces will make more sense as extensions of JSR 295/296 rather than competing or alternate frameworks.

As always, we're open to code submissions :)

Richard

rasto1968
Offline
Joined: 2004-08-25
Points: 0

This is what the DataBinding JSR(s) are all about, they will (hopefully) make it very easy to bind database values to form components (beans).

Have a search for 'data binding', you should be able to see lots of discussions about it.

Rob

evickroy
Offline
Joined: 2004-07-23
Points: 0

This argument has been brought up before. The lack of those basic ease of use features is why Java is almost non existent on the corporate desktop and why .NET rules that domain. JSRs 295 and 296 combined with IDE support in Netbeans 6.0 should solve some of these problems. A decade late, but hopefully, not too late. Currently, you can accomplish "some" of this with the JGoodies Binding/Validation frameworks. The missing piece there is the persistence. Hopefully, JDBC 4.0 or the Persistence API will ease that burden, but time will tell. Netbeans 6.0 "should" (hopefully?), include some support tying all of these pieces together. There are other alternatives, of course.

Erik

Romain GUY

> The lack of those basic ease of use features is why Java is almost
> non existent on the corporate desktop and why .NET rules that domain.

While there might be a hint of truth there I would not be as
definitive. I've seen many corporate Swing apps and very few .NET ones.

--
Romain GUY
http://www.curious-creature.org
http://www.progx.org

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Bill Snyder

There will be graphical support for beans-binding and the app framework in
NetBeans, too. Cant wait for that....

On 1/22/07, Romain GUY wrote:
>
> > The lack of those basic ease of use features is why Java is almost
> > non existent on the corporate desktop and why .NET rules that domain.
>
> While there might be a hint of truth there I would not be as
> definitive. I've seen many corporate Swing apps and very few .NET ones.
>
> --
> Romain GUY
> http://www.curious-creature.org
> http://www.progx.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>
[att1.html]