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.
