well I don't see why it can't be made to be called simply as a tag. Means
the page is a .cfm page rather than an .htm page but you still don't need
coders involved. This would make a little more sense to me - after all if
you spend even an hour or two messing about with trying to get it working,
it's already missing the point. It's a handy utility which can save time
and resources - and in the words Hal and others have already used, it should
be able to be literally "dropped" into the page.
Toby Tremayne
Code Poet and Zen Master of the Heavy Sleep
Show Ads Interactive
359 Plummer St
Port Melbourne
VIC 3207
P +61 3 9245 1247
F _61 3 9646 9814
ICQ UIN 13107913
-----Original Message-----
From: Johnson, Russ [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 25 January 2001 1:38 AM
To: Fusebox
Subject: RE: DevNotes WAY cool! Call for suggestions...
I agree Hal, however, will this still work for those of us that have to use
FuseBox during the "fleshing out" phase?
When you work for a big corp, you dont always have the luxury of saying "We
need and extra 2 weeks to do this because it makes sense.". We have way to
many overzealous project managers who like to cut your dev time in half so
we do the "look and feel" as we are developing the app in FuseBox. When the
look and feel is completed (usually way before the coding) we can drop in
the header and footer files and let the client take a look see.
This is where Devnotes would be great for us. However, I am understanding
from list traffic that if you use them in a FuseBox app the notes are not
unique for each page. Am I misunderstanding this?
Russ
-----Original Message-----
From: Hal Helms [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 23, 2001 11:29 PM
To: Fusebox
Subject: RE: DevNotes WAY cool! Call for suggestions...
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
