Hi Quinton,
On 23/02/2009, at 6:00 PM, Q wrote:
> On 23/02/2009, at 1:10 PM, Lachlan Deck wrote:
>
>> So here's a preview of what I'm looking to submit patches of as a
>> 'new and improved' component creation wizard.
>>
>> So, this is a call for feedback (note feedback vs commitment to do :)
>> - first impressions
>
> First impression, it's too complicated.
As a one-liner... for the most part I'm going to beg to differ though
certainly I'll have a think about how to make the most common options
the most prominent.
> I am a subscriber to the KISS principle, less is more and all that,
> and this kinda goes the other way.
> If someone were to ask me how they can improve the existing
> component creation wizard my answer would probably be to make it
> smarter, have fewer input options but more output possibilities,
> have better defaults but still do what the user expects.
I'm all for KISS where appropriate. But I'm also a believer in
consistency (e.g., with the platform) and transparency where
appropriate.
We need to be clear up front about what a wizard is not. A wizard is
not a "follow the wizard's adventure" it's much more akin to a "choose
your own adventure - but here's some sensible defaults".
A wizard is certainly something which aims to quickly allow you to
create something, it has default options pre-populated of course, but
it does not stop the user from saying "no, that's not what I wanted."
To take a sample of the available wizards in Eclipse:
- new project .. has default but allows the user to adjust things
- new java class ... ditto
- new groovy class ... ditto
- new package .. ditto
- new interface .. ditto
- new enum .. ditto
- etc etc
So, to come back to consistency and, as you mentioned, users
expectations I believe the above sampling of wizards shows what is
found to be consistent and as such what users come to expect from any
third party wizards that come along.
To further the point: this is a file-creation dialog. The wizard in
the end creates the file where I want it, not the other way around.
It's a tool for me, not the other way around. Certainly, the wizard
presents the most common options (it may present these options in such
a way such that they don't distract, sure) but in the end it does my
bidding.
> A few questions come to mind when looking at this UI:
> What do we really need to know to do what the user wants in the vast
> majority of cases?
The very fact that you ask this question shows that the wizard can
certainly make numerous - even most - decisions by default but it
cannot read the users mind. It cannot think outside its own
parameters, not should it. That's why we have a wizard; we actually
ask the user, 'is this what you wanted?'
There's a good ad on tv (at least down under) for an insurance company
where it shows them actually asking the customer what they want. I
can't remember right now who it's for - but it's a novel approach ;-)
The alternative in my view always leads to dissatisfaction. Again I'm
not suggesting that things couldn't be made more intuitive, if indeed
it's not, and for the newbie less confronting, if indeed it is.
In the common cases the defaults that are presented won't need much if
any adjusting. I'm all for intelligence for the defaults. (You
obviously can't play with a screenshot, but I believe I've covered
most of the defaults pretty well .. with some minor tweaking perhaps.)
> Can we make an intelligent decision based on convention or the
> existing project contents without asking the user?
Yes, we can and we should /select/ intelligent defaults and/or even
remember previous options. Should we, however, hide these decisions
completely from the user (i.e., lack of transparency) without giving
the user the option to alter it? Absolutely not.
> How much productivity do you gain by having this in the wizard?
I'm all for productivity and I believe that's what default options
provide. The initial focus (and presentation of the options requiring
input) allow for productive use of the wizard without unnecessary
restrictions.
> How often are users likely to change the default value?
This question, in my view, is only relevant for the organisation of
the elements not whether or not they are available at all.
If we want the most basic wizard - then just the 'name' will suffice.
The wizard could then be unhelpful and put everything in the default
package, decide whether or not to add html content, etc. Asking the
user is the right thing to do. I certainly don't want to make it
unintuitive or unproductive. But it certainly requires user input and
confirmation.
> The API file for example, the API editor is always accessible
> through the component editor, and will create an API file when
> needed, so do we need to care about it in the component wizard?
To answer this, I believe we need to come back to the fundamentals of
what a wizard is for or what it allows the user to do. It should, I
believe, allow the user to reach their goal in the least amount of time.
Now - what is that goal? This may differ, of course, but here's my
thoughts about what could be in future: the wizard could allow the
user to define the api up front, it could allow the user to similarly
define the display group up front ... thus allowing the wizard to auto-
create the relevant javadocs, stub methods and so forth .. thus making
productivity better because there's much less file hopping required
later in order to achieve the same things. Of course, doing this would
require an optional multi-page wizard.
Now, of course, editors are required for subsequent changes where
necessary.
> In the "controller" section, how important is it to have all these
> new options at creation time,
Firstly, these are the options presented in the class creation dialog
(for the most part). So it's consistent with it.
Secondly, it's much more convenient to do adjust these things quickly
via the wizard than to do so afterwards. Of course, you can leave them
'as is'.
> and how often will users need (or bother) to change them from the
> defaults.
Same answer for similar question above.
> Why is abstract/private/protected/static even listed? How often do
> users create a WOComponent that isn't public?
I've answered the question about 'how often'.
So as for abstract etc I'll ask a question: do you never create
component controller hierarchies?
But, I agree that default/private/protected/static are options that
could be dropped. I believe abstract and final should stay.
> How inconvenient is it to the user if they were always created public?
Again - the defaults are presented for transparency .. so we don't
need to guess on that one.
> I think your suggestion of adding support for custom user templates
> would be of significant value. This might allow a user to simply
> name the component and select a template that corresponds to the
> type of component they wish to create.
Cool. Certainly it will allow for flexibility - however it can't
decide what interfaces and so forth are relevant for the current need.
> A variety of custom component types (List/Detail/Confirmation/etc),
> and an extensive amount of customisation could be achieved while
> using the simplest of user interfaces.
>
> As for the java source folder, does this serve any purpose other
> than to solve an issue with maven projects? Is it really necessary
> or can we fix it in the wizard without having to ask the user?
You seem to want to deprive the user of both knowledge and the ability
to make a decision. I just don't agree and as mentioned above - none
of the other wizards in Eclipse follow this rule.
Now if you want to limit what the incremental builder supports this
might be a different story but for a file creation dialog... no.
> I like what you have done with the cleaned up visuals and view/
> controller separation
Okay, cool.
>> - features you think might be useful additions / behaviours
>
> The encoding type isn't really optional, it needs to be set to
> something,
Correct me if I'm wrong - but isn't this only needed for what gets
populated in the WOO file? Otherwise, the default encoding can be
inherited from the parent container.
> and it should use java encoding type names and drop the old Obj-C
> naming.
good point. Will do.
> Optional WOO file creation was previously a feature of the wizard,
> but was removed for good reasons (that I don't recall right now).
I can't think of a good reason as to why it's necessary ... unless the
component editor borks when it's not there?
with regards,
--Lachlan Deck
This archive was generated by hypermail 2.0.0 : Mon Feb 23 2009 - 07:25:05 EST