Forum: Ruby web site development methodology

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
94a4542a068200647f3b99ab78e53e0a?d=identicon&s=25 colonel.ender@gmail.com (Guest)
on 2006-03-26 09:18
(Received via mailing list)
I'm starting a new web site project to support a few thousand
concurrent users and am searching for a development methodology that
will help me work with another firm which will be doing the graphic
design on the site.

Can anyone point me to some suggested web development methodologies
(specifically geared towards web site development)?

I'm having trouble with things like ... when to hand the web views over
for graphic work, should the graphic designer figure out the layout of
the views even though the developers will be doing the initial work on
implementing the views, how to continue back-end work while the visuals
are being done (if they can be done in parallel), etc...

I'd also like to get ideas on how to draw up and present the site to
the client, what to present in the beginning, etc...

I'm not looking for anything w/ heavy upfront design work and as big as
RUP. I think it needs to be lightweight.

Any help much appreciated.
C4edcb52652d2b17fe2b38ef13bae729?d=identicon&s=25 David Andrew Thompson (Guest)
on 2006-03-26 09:24
(Received via mailing list)
This is a highly debated subject. As an agile developer I would
recommend reading through the wikipedia entry on Agile Software
Development...http://en.wikipedia.org/wiki/Waterfall_model

Dave
1b5341b64f7ce0244366eae17f06c801?d=identicon&s=25 Kirk Haines (Guest)
on 2006-03-26 22:17
(Received via mailing list)
On Sunday 26 March 2006 12:18 am, colonel.ender@gmail.com wrote:

What you are asking for seems to be a difficult thing to pin down with
precision, as all of the things that you ask about can vary depending on
details not mentioned.  However....

> I'm having trouble with things like ... when to hand the web views over
> for graphic work, should the graphic designer figure out the layout of
> the views even though the developers will be doing the initial work on
> implementing the views, how to continue back-end work while the visuals
> are being done (if they can be done in parallel), etc...

There should be no reason why this can't be done with a substantial
amount of
parallelism.

Put as many of the details about the layout as possible into the
stylesheet(s), keeping the HTML as simple as possible.  Have the graphic
designer work with the developers to lay out the basic structure of the
site
and of whatever specific pages need to be addressed.  Once that basic
layout
is done, you developers should be able to work on whatever code that
they
need to work on for the dynamic, functional bits, while the graphic
designers
continue to refine the details on the look of the site.

The details regarding exactly how this works may vary depending on the
technology that you are using to build the site, but the general concept
is
the same -- by using the technologies available to keep different
interests
separated, they can be worked on in parallel.

And before you get to that point, there is still developer work that can
be
done on data models and areas of business logic that are going to be
necessary regardless of interface details.

>> I'd also like to get ideas on how to draw up and present the site to
> the client, what to present in the beginning, etc...

The graphic designer should start with conceptual mock-ups of a page or
two of
the site in order to work out the details with the client on how the
site is
to look.  Functionally, just work off the requirements for the site.
Even if
a lot of the details are still fuzzy, you can lay out a general flow, a
high
level storyboard showing how the pieces fit together.

Your requirements exist to guide the project, so make sure you use them
and
refer to them.  If you don't yet have a good set of requirements
documents,
start there.  It's hard to do a large project efficiently if you don't
even
really know what it is that you are expected to deliver.


Kirk Haines
This topic is locked and can not be replied to.