When I started at Oracle in 1990, I worked in International Technical Support in the Unix group, helping the tech support departments in our international subsidiaries find solutions to problems that they couldn't figure out locally. There was a guy in my team named Per Brondum who had recently come over to Oracle headquarters from Oracle Denmark where he worked as a sales consultant, and before that in the IT department at Lego. We worked together for many years, first there in support, then in Oracle Tools development where he lead the product management team for Oracle Reports, and I for our Oracle Forms product. As product managers, we did lots of traveling to user groups and user conferences to present about our products.
Though Per left Oracle some years ago to lead a number of other efforts at smaller companies, we've kept in touch over the years. All of his other jobs have involved Oracle technology in some way, shape, or form. Recently he's taken some time off to take a trip around the world, and I've been following his wanderings through Asia on his Travel Blog. As luck would have it, this week he's in my neck of the woods so we're going to hook up tonight for dinner.
While on his world traveling, he's been tinkering around with some cool software ideas and he delighted me last night while we were chatting to tell me that he'd downloaded JDeveloper 10g and the Oracle 10g database (while at an Internet Cafe along the road that happened to have decent bandwidth) and he'd been hacking away at a prototype of his idea using JDeveloper and the ADF framework. Being an old salt with Oracle Forms and Oracle Reports, I'm going to be very interested to get his feedback about what he finds complicated or confusing about this first-time use of our J2EE application framework. I'll use that feedback to hopefully make the product simpler for developers like him coming from the Oracle Forms (or Visual Basic, for that matter) type of client/server development background.
As he described to me one of the first problems he hit, it became clear that like many developers, he was thinking of developing his UI first. Since he wanted to create a form, he started by creating a Swing Form for ADF JClient. But this form wizard expects the user to select some view objects to work against, so it launched him into a nested wizard to help create some business components. His first impression was that it was a little odd, and I agreed with him. We definitely need to do a better job in future releases of supporting this kind of "UI First" development where you layout your user interface, and then bind it to data later (or perhaps use the user interface to suggest a potential data structure to drive it.
Things would have gone more smoothly if he had first thought to design the data model for his application, and then defaulted a Form or some UI panels based on the view objects in that data model. However, that's not the way a lot of developers approach problems they want to solve. We've seen in usability tests that given a task, many developers approach the problem from this "UI First" path. We are working for our next major release to cater more elegantly to this style of development.
In the meantime, I suggested that he imagine for a moment that he were working again with Oracle Reports, where before creating any kind of report layout, you would first design the data model of your report, then proceed to default the layout for that data model. I pointed him to the "Test..." menu item on the right-mouse context menu of an ADF Application Module component, which brings up a user interface that allows you to test out your data model to make sure it's showing the data and coordinating the master/detail levels that you want. Hopefully, this will make his second form that he builds an even more productive experience.
My wife will probably kill me if we "talk shop" at the dinner table tonight, so Per and I will need to carry on with his ADF adventure, and any other problems he hits on his journey, over email...
2:06:33 PM 
|
|
