Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Why Do We Need the Preference to Enable Multiple Modules per Project?

Arthur,
 
You thoughts about support for uniformity and consistency in our tools sounds good and the right thing to do. We can have a detailed design discussion over a conference call post 0.7 (M8) and come to a consensus on what is the best thing to do that our users will like and what is possible with the limitations we have from core platform. The only point we want to stress from the J2EE team point of view is that this change is quite major and will destabilize 0.7 release. We have a big number of defects that we need to address to give a good quality 0.7. Making this change will leading to more defects. With RC1 for 0.7 being 13th of this month it  is not the right thing to do at this point. Do you agree ?

Regards, Vijay
-------------------------------------------------
Vijay Bhadriraju                                        
Rational Tools, J2EE Tooling              
Ph: (919) 486-1898, T/L: 526-1898    
Internet: vbhadrir@xxxxxxxxxx          
-------------------------------------------------


Arthur Ryman <ryman@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

07/07/2005 12:36 PM

Please respond to "General discussion of project-wide or architectural issues."
To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
bcc
Subject
Re: [wtp-dev] Why Do We Need the Preference        to        Enable        Multiple        Modules        per Project?





John,

The goal of the flexible project layout requirement was to give users more freedom about how they organized their projects. We can't be infinitely flexible, but whatever layouts we do support should be supported in a uniform and consistent manner by all our tools. At present we support the one-module-in-root style, which is both a simple and reasonable organization (not to mention currently supported by some products), and the one-or-more-in-subdirectories style.  Can these be unified so that we allow both a root module and one or more in subdirectories? That would eliminate migration issues.

Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
intranet: http://labweb.torolab.ibm.com/DRY6/

John Lanuti <jlanuti@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

07/07/2005 11:43 AM

Please respond to
"General discussion of project-wide or architectural issues."
To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject
Re: [wtp-dev] Why Do We Need the Preference to        Enable        Multiple        Modules        per Project?








Arthur,

I definately see your point about modes.  The preference to disable multiple modules per project is a way to set the development mode.  I agree this is bad.
I think we should definately remove the preference, however, I do not think this should happen in 0.7.  There are reasons why it is not our reccommend approach
yet.  For example, there are migration issues which we do not handle if you created a project with one module and then wanted to add a second module.  When you
add just one, the module goes into the project root, with multiple modules, there are module folders.  There are also classpath issues.  The classpath is for a project
only and one module may be relying a class it may not actually have at runtime.  There are other issues as well with multiple modules per project.  The wizard is less
refined and not as usable.  These are all known issues.  These are all issues we can tackle with a well thought out solution for M8.  It is not worth the risk in stability
to make a hasty decision here.  We have made this mistake before, and we would like to implement the real solution.  The advanced tab on the wizard is a great idea.
However, we have a ton of defects for M6 and adding this new function to the wizard would open up a whole new can of worms.

In addition, people do like the simple wizards.  It is a good experience.  The web services problem will be addressed.  Most users will only want one module per project.
And for those that want to delve into multiple modules per project, let's make sure it is with caveats.  We are not yet comfortable with this function and we cannot reccommend
it at this time.  Henceforth, we hide it via the preference.  I think this is our best chance at keeping 0.7 simple and easy to use, and to also ensure it stays stable through the
release.  As soon as 0.7 ships, we can yank the preference, break the wizard and start putting it back together.  I think that is a viable solution for now.

Thanks,

John Lanuti
Software Engineer, IBM Rational
jlanuti@xxxxxxxxxx
t/l 441-7861

"You see this wandering soul, he's never gonna stop, because he loves and he feels this world can grow.
He's not afraid of feeling, he loves what he believes, he feels, and he grows."  - Of A Revolution
Arthur Ryman <ryman@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

07/07/2005 10:04 AM

Please respond to
"General discussion of project-wide or architectural issues."
To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>, wtp-dev-bounces@xxxxxxxxxxx
Subject
Re: [wtp-dev] Why Do We Need the Preference to Enable        Multiple        Modules        per Project?







John,

Thx for the feedback. I agree that our UI should be as simple as possible and that we should implement the notion of progressive disclosure though UI controls like "Advanced" buttons.

However, we need to make a distinction between Preferences and Modes. Preferences are generally a good thing if they allow users to tailor the IDE to their tastes. Modes are generally a bad thing since they lead to usability problems (e.g. I could do that before, now I can't. Why?) Modes are also dangerous since they complicate code. You can get a combinatorial explosion when you have several modes, i.e. modes can interact with eachother. (Known as the "Feature Interaction Problem").[1]

One of the great advances in UI design was the elimination of UI modes that were the norm in applications. Command line systems used to prompt you for input and the input was very modal. (e.g. the vi editor) Windowing systems creating modeless UIs. In fact, early Macintosh programmers wore T-shirts that said "Don't Mode Me In".

I also think that labelling multiple modules per projects as Advanced is really a matter of where you are coming from. A Project is an Eclipse mechanism for grouping related work. If an application contains several modules, isn't it simpler to put them in one Project and let the tools do they right thing at deployment time? Doesn't it take more skill to set up several inter-related Projects, and to know that you have to check them out as a group to do development work?

I got confused by a change in the default behavoir between builds, but it exposed a bug in the code which indicates to me that some developers were also "confused" or at least had a different interpretation of the meaing of the preference.

[1] http://www.research.att.com/~pamela/faq.html

Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
intranet: http://labweb.torolab.ibm.com/DRY6/
John Lanuti <jlanuti@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

07/07/2005 09:15 AM

Please respond to
"General discussion of project-wide or architectural issues."
To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject
Re: [wtp-dev] Why Do We Need the Preference to Enable Multiple        Modules        per Project?








Arthur,

The flexible project preference was added to give a better "out of the box" experience.  If a new user picks up WTP, it is much easier
for them to deal with the concepts surrounding one module per project.  The wizards are easier to follow and it hides a lot of the complexity
from them.  It was our guess that most users would still be using this one module per project paradigm, however, we absolutely want to allow flexibility
and show off all the work we did to provide this flexibility.  In this respect, multiple modules per project is an advanced feature for advanced users.  And
what do we typically do with advanced options and settings?  We hide them by default.  This was the reasoning behind the preference -- to hide the
complexity and confusion to someone who did not care about these advanced flexible options.

That being said, I guess I'd like to hear feedback from others on what they think.  I mean, if it confused Arthur, it seems like it will surely confuse a novice user!  :-)
Maybe we could keep the preference, but leave it on by default instead of off?

Thanks,

John Lanuti
Software Engineer, IBM Rational
jlanuti@xxxxxxxxxx
t/l 441-7861

"You see this wandering soul, he's never gonna stop, because he loves and he feels this world can grow.
He's not afraid of feeling, he loves what he believes, he feels, and he grows."  - Of A Revolution
Arthur Ryman <ryman@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

07/07/2005 08:00 AM

Please respond to
"General discussion of project-wide or architectural issues."
To
wtp-dev@xxxxxxxxxxx
cc
Subject
[wtp-dev] Why Do We Need the Preference to Enable Multiple Modules        per Project?









While using WTP to develop some Web apps, I ran into a feature of our UI that I find problematic, and I'd like to hear from other people about why we need this feature.

The feature is the Flexible Project Preference. The user now has to explicity check a box to enable multiple modules per project.

I find this problematic for several reasons:

1. It caused a usability problem. I created a project with a Web module in an earlier build of WTP and then worked on it with a later build which has this preference disabled. It caused the Web service wizard to fail [1]. This will be corrected, but it pointed out to me that this preference is causing bimodal behavior. Our code in now more complex than it needs to be and there is more potential for bugs and usability problems.

2. We went to a lot a development effort to upgrade the code base to allow multiple modules per project. This should be the WTP norm. We should promote this feature and improve our UI to make it very easy for users. Disabling it seems like a step backwards and an admission of failure.

3. The initial wizards to create multiple modules were somewhat awkward, and this may have motivated this preference. However, the wizards are very usable now so I believe this preference has outlived its usefulness and is now just extra baggage that should be jetisonned asap.

I have created a bug [2] to remove this preference. Please review it and voted for it if you agree.

Is anyone a strong advocate of this preference? If so, please explain why you think we should keep it. I'd like to discuss this in our telecon today.

Let's move on this quickly since time is running out. Thx.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=102244
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=102487

Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
intranet: http://labweb.torolab.ibm.com/DRY6/_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev

Back to the top