Good point, Emilio, about "gilding the lily". Here's how I use DevNotes.
While I am doing a wireframe to establish functionality, the art
director/graphics dude/dudette is working with the client to establish look
and feel. They typically draw up three comps of three separate pages: the
home screen and two representative "inner" pages. Once this is decided on, I
hand this over to user interface people to mesh the needed functionality
with the look and feel. The result is an initial cut at a prototype, done
entirely in HTML. No coders needed at this point. THIS is where I use the
DevNotes, and this iterative process of defining the prototype continues for
some time. Once this is done and we've reached "prototype freeze", the
DevNotes come off the application, letting the client know that the time for
changes is now officially over.
Because of this, I don't have them as a Fusebox app, as this would mean that
it would need to involve coders. So if we do start adding in functionality,
it's very important to me that we not make this difficult at all to use and
that it can be a simple custom tag added to pages created by non-coders.
Hal Helms
== See ColdFusionTraining.com for info on "Best Practices with ColdFusion &
Fusebox" training ==
-----Original Message-----
From: Emilio [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 23, 2001 9:45 AM
To: Fusebox
Subject: Re: DevNotes WAY cool! Call for suggestions...
I've found it immensely helpful in solving common problems in
> getting info from clients--and having that information in one, central,
> web-accessible place.
>
> My initial solution was quick and dirty and it could definitely use some
> improvements. I think it would be excellent if those interested could map
> out a plan for these improvements. My concerns are that it stay easy to
> implement and flexible. I primarily use it for doing prototypes. I do
> prototypes in a non-Fusebox environment very deliberately, as I want the
> prototype to be able to be handled by non-programmers. This is part of my
> overall development methodology. It's important for me to be able to tack
it
> on to what the user interface people are doing.
I also think addressing where this tool fits into the development process is
going to help define what/how it works.
If we start jumping ahead on all the features we can add, we might forget
where the tool came from and what problems it solved. Mainly KISS. If you
start bogging this down in functionality and design, you'll leave the client
and project deadlines behind. I told my client that if they wanted to make
suggestions about content, write up a word doc, make your own "materials
needed" entry and upload the files. They understood that, liked that
flexibility and could quickly and easily start doing what they needed to do.
Another thing to keep in mind is if you've never used Devnotes before, then
you have never accounted for the time it will add to the project. I'm still
unsure of how much its added and I' having a hard time keeping everything on
track in terms of what to allocate time to. So again if we start making
this a full blown application moving to version XX then potentially it will
add more time than its saving.
So back to my original point we should address the niche it is filling and
how much time a project should devote to that niche before we figure out all
the bells and whistles.
We should learn to maixmize a tool for what it is before improving it. This
happens too much in our society, we think we can always improve upon
something, but should it be?
my 0.02
Emilio
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
