Hi,
Doug --
When
looking at the New Project wizard for Tilera's
Eclipse-based IDE, a key issue I had was how much prior
knowledge the wizard expects the user to have in order to
make the right choices: for example, how Eclipse organizes
projects (e.g. new vs. existing directory, workspace vs.
external directory, makefile vs. managed), what kinds of
projects can be built by managed projects (.exe, .so, .a),
and what the various toolchain options represent (GCC vs.
cross vs. "other toolchain" vs. proprietary compiler X
vs. proprietary compiler Y), etc.
As
a specific example of the toolchain issue, in another
Eclipse-based IDE I've looked at there are multiple
toolchain selections, which ultimately correspond to
different versions/implementations of the platform's
compiler, but from the wizard there's no obvious
indication of which toolchain name corresponds to what
compiler version. This matters because there are features
supported by one compiler but not by another, so you have
to go in knowing not only what compiler version you need
for your project, but also which of the otherwise
indistinguishable toolchain options selects that version.
If
you want a use-case, think of new customer X who's just
picked up our Eclipse-based IDE for the first time, and
isn't comfortable with IDEs to begin with, and wants to
just create a project around some existing code to try
stuff out. If said user has to read through the online
help just to figure out how to create the right project,
or has to create one or more incorrect projects first just
to discover which are the right options to use, it starts
them off on entirely the wrong foot with the tool, and
gives a terrible impression of the usability of the IDE
overall. And this gets repeated for every new customer.
Yes,
of course, once you know (or have read in the docs
somewhere) which two picks out of the lists you always
need, the wizard is simple to use, but to my mind this
kinda subverts the idea of having a wizard in the first
place. The current wizard is optimized for efficient
selection, not for discoverability, and that works against
us if we want to encourage use of CDT-based IDEs. In other
words, rather than trying to figure out how to bucket
project types, we should tackle the problem by first
finding out what the user wants to do, and then
have the wizard decide from that what project type and/or
toolchain is right for the job.
The
approach I took with Tilera's IDE was to add an extension
point that allowed inserting a custom "first page" in the
wizard, ahead of the existing one. This page asks a few
well-chosen introductory questions that:
(a) express things from the user's point-of-view and
(b) cover like 90% of the most common projects people
create.
This
page then populates subsequent page(s) and/or tweaks the
created project accordingly, the goal being that unless
you're doing something really unusual, you can immediately
click Finish and get a properly configured project,
perhaps without even looking at the other wizard pages.
Here
are examples of these kinds of introductory questions,
which we use in tile-eclipse's New Project wizard:
-
where do you want to create this project?
(o) in a subdirectory of the IDE workspace named:
[ text box ]
( ) in a new/existing directory outside the workspace:
[ pathname text box ] [ Browse... ]
-
how do you want to build it?
(o) Makefile: use your own existing makefile
( ) Managed: IDE generates makefile(s) for:
(o) an executable
( ) a shared library (.so)
( ) a static libary (.a)
-
which platform is this project intended for?
(o) Tilera hardware (cross-compiled with Tilera C/C++
compiler)
( ) Linux/x86 platform (compled with standard Linux GCC)
In
other words, turn the problem around and give users enough
ammunition in the wording of the questions to know whether
they're making the right choices, or if the provided
choices even cover the type of project they have in mind.
(Like, what if someone decides to create an Eclipse
project to build the Linux kernel? Don't laugh, someone
wanted to do that!)
We
could generalize these kinds of questions enough to
provide a default "intro page" (or pages) along these
lines for the default project & toolchain types that
come with CDT, but it would still make sense to define a
customization API such that an integrator could provide an
alternative, tailored intro page for the platform. This
custom "first page" (or its provider class) may also need
access to the constructed project to perform additional
configuration steps for platform-specific selections. For
example, another question we ask is what Tilera MDE
installation to use for the cross-compiler, and we
customize the project's environment variables accordingly.
Yeah,
it's a bit more UI than just having a couple of quick
pick-lists, but that's kinda the point. The current wizard
assumes a lot of prior knowledge, and leans towards
compactness at the expense of clarity. We may want to find
a way to rework that, while also making it customizable by
developers.
William
R. Swanson (traveler@xxxxxxxxxx)
Senior
Software Engineer
Tilera
Corporation
1900
West Park Drive, Suite 290
Westborough,
MA 01581
Hey
gang,
Even
though we're a community spread across the globe, it's
important that we have real design discussions and
help plan out our future directions. We can start here
on the mailing list, and as part of this discussion,
we can move it to a different venue if it becomes too
noisy or too awkward to make our points. As you can
tell from my blog, http://cdtdoug.ca, I
love to write, so this works best for me, but I moved
to QNX to work with a team that sits within spitting
distance of each other because I love that interaction
too, well, except for the spitting.
I'd
like to do something with the New Project wizard. I've
wanted to do that for a long time. And now that we've
gone through the exercise in Momentics, I think we can
bring some of that experience to the CDT and the
Eclipse C/C++ IDE in particular, and anyone else who
wants to contribute ideas and/or code to reuse it
themselves. But I'm not sure I have the full
perspective on everything all CDT projects would need.
First
up, the biggest problem is the first page, and the
Project Type and Toolchains panes in particular. What
is a project type. Is it the type of binary output,
executable or library? Is it the build system,
autotools or qmake or cmake? Is it the kind of
application, command-line or GUI or plug-in. The
target platform, BlackBerry or Desktop or Server?
Or
do you pick the toolchain you want first and then the
project type? The UI was mainly designed by a
contributing company that offered an alternative
compiler to gcc so the choice was left second which
made sense in those scenarios. But how does GCC cross
fit into that. For many of us, toolchain implies
target platform, but wouldn't you select the target
platform before picking the project type and then
selecting a toolchain? Are we missing something there?
Right
now we have quite a mix of concepts being presented in
these two panes, project type and toolchain and the
cohesion is terrible. I'd love to hear what you all
think of the dialog and how you think it should be
changed to make more sense to our users.
