RE: [wtp-dev] Why Do We Need the Preference to EnableMultiple Modules pe

[Arthur Ryman <ryman@xxxxxxxxxx>]

Kosta,

I know you are just trying to make a
point, but as a matter of fact, some people think we have too many plug-ins
and want us to combine them. Of course, you can never satisfy everyone.

The issue here is one of cohesion. If
modules belong together, e.g. a Web module calling some EJBs, we should
enable developers to develop them in one project. This requirement was
clearly articulated by our partners at the start of WTP and we accepted
it, at significant development expense. Now we have to make it work well.
Yes, there are limitations imposed by JDT and Eclipse, but the fallback
is to split up the modules into several projects if they really need separate
classpaths.

I certainly think it would be a definitive
plus if WTP could be used by organizations that have other ways of working,
i.e. we can't expect everyone to migrate their projects or all cutover
to WTP. If we can coexist then we at least get our foot in the door and
remove potential obstacles to more widespread adoption.

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/

"Konstantin Komissarchik" <kosta@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

07/07/2005 11:56 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	<wtp-dev-bounces@xxxxxxxxxxx>
Subject	RE: [wtp-dev] Why Do We Need the Preference to        EnableMultiple        Modules        per Project?

I’ll throw in my $0.02 and
duck for cover. :)
 
1. A project is more than a
mechanism for grouping related work. It’s also the level of granularity
for classpath, build, natures, properties, etc. To me, the fact that in
the multiple components per project model these would be shared is a HUGE
problem. It far outweighs any benefits that would be gained by being able
to treat a whole app as a single project. I believe that any application
should be designed in such a way as to make it difficult for a novice user
following the ‘obvious’ path to shoot themselves in the foot. If a novice
user, who doesn’t understand all the limitations, goes down the path of
multiple components per project, I believe chances are very good that they
will not only blow their foot off, but take the entire leg with it.
 
2. If putting an entire app
into a single project is so compelling, why are we not developing wtp by
putting all of the plugins into a single project? Yes, eclipse is lacking
a higher-level abstraction that allows multiple projects to be grouped
together into an app and handled as a unit, but is it really the job of
WTP to solve this and to solve it in a way that’s inconsistent with the
rest of eclipse?
 
Ducking for cover,
 
Konstantin Komissarchik
BEA Systems

---

From: wtp-dev-bounces@xxxxxxxxxxx
[mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Arthur Ryman
Sent: Thursday, July 07, 2005 7:05 AM
To: General discussion of project-wide or architectural issues.
Cc: General discussion of project-wide or architectural issues.; wtp-dev-bounces@xxxxxxxxxxx
Subject: Re: [wtp-dev] Why Do We Need the Preference to EnableMultiple
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