Hi Michael, *,
On Wed, Nov 01, 2006 at 02:20:28PM +0000, Michael Meeks wrote:
> On Tue, 2006-10-31 at 17:42 +0100, Christian Lohmaier wrote:
> > I disagree. Esp. when the UI is changed significantly the UI-mockups are
> > necessary. Both for finding flaws in the proposed design as well as for
> > documentation.
>
> I'm well up for the UI team doing mock-ups and communicating those to
> the developer, makes perfect sense. Of course, what comes out in the
> product may not be like the mockups, hopefully it's even better - so why
> enshrine the mockup process in a formal document ?
I don't expect the spec to be final from the very beginning. I don't
want you or anybody else to do a mockup that fits every need in the very
first attempt. But when you have agreed on an UI (and you need to have
that agreement, since you need to code that stuff), that should be put
into the spec. In the formal document. Again to give documentation a
chance to prepare help-texts that actually match the product as well for
"outsiders" (people not part of the implementation team) to have a look.
> > I'm sure nobody expects you to do a pixel-accurate mockup, but again the
> > user-interaction part should be clearly visualized.
>
> Sure - and of course UI is important.
>
> Snip some good quick-starter related questions - sure - all of these
> things can be easily added to an unstructured wiki page / FAQ, that can
> be built up as people ask the questions.
^^^^^^^^^^^^^^^^^^^^^^
Oh, good that you write this. It seems you have a completely different
view of "wiki based specs" than I have.
Writing the spec after the bugs are found and reported is /not/ an
option.
Using the wiki to collaboratively write and edit the spec is OK, no
matter whether it is before implementation (preferable), during
implementation (well,...) or after integration into a CWS (not the best
choice "obviously").
But surely the specification needs to be "final" or "stable" or whatever
you want to call it before the code gets into the master.
So adjusting the spec as your likings after throwing random junks of
code into the tree is not what I have in mind when talking about
wiki-based specifications.
(Don't confuse this with updating the spec when the feature gets
redesigned or changed afterwards, this is of course fine - but this
should not be an "excuse" for not creating a spec in the beginning)
> > > In this scenario, a spec cannot be used to verify the
> > > implementation, because the implementation is done first.
> >
> > Well, you can still see whether what you coded actually is what you
> > thought it would do (i.e. what you coded is what you wrote down in the
> > spec).
>
> But we didn't write down a spec. We conceived of the idea, then
> implemented it, now we have it. The original conception of course was
> prolly inaccurate, no-one gets things right 1st time, we most likely
> have a solution that is now far better than that, similarly we are now
> probably aware of the various limitations of the current approach, and
> various next steps / future development to do.
I don't understand how this is contradicting my point. Again what you
need to write down is not how many lines of codes you used or how you
named your variables and stuff.
And if you need to change your whole feature multiple times, then you
ought to thing before. (and again this doesn't relate on how to actually
code it, but on what the feature is supposed to do)
> > It is true that you miss the "find errors in the planning phase"
> > (but again I don't think you start coding without having planned the
> > changed first, so no gain/no loss)
>
> The problem is that there is a very large difference between conceiving
> an idea and writing it down as prose (with pictures); you can conceive
> of things almost instantly, writing a general document for an uncertain
> audience is very time consuming.
Hunting for the missing information is as well. And for more people.
ciao
Christian
--
NP: Metallica - Better Than You
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
