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