Working alone on a webapp

Do you design first the develop? Develop first then design? Do both
simultaneously?

Just curious, because I’m working on a site right now doing a little of
both
at the same time.

On Sat Jun 24, 2006 at 10:46:43PM -0400, Matt R. wrote:

Do you design first the develop? Develop first then design? Do both
simultaneously?

anectodal evidence, based on my one (three) rails project(s)

design first, in the structural sense (schema), so first i write a crazy
migration. then develop/design in the order of one controller then one
view, since a view without some data to display is pretty pointless.
controller development is basically writing stuff in irb then pasting it
into a file in emacs when it works. im sure a proper IDE could unify
this (ive been meaning to write one in rails). design of the view mainly
consists of mindless tweaking of the CSS file (no sliced images harmed)
which is a diversion after "damn i just rewrote the model so the query
wasnt ass slow or “just learned 3 more gotchas”…

then refactor it slightly so i can reuse it for 2 other projects. theres
a bit of a fine line between too much user reconfigurability and
indirection and optimized rigidity, but what i settled on tends to be
pretty much RDF, so for 2.0 im going to get rid of SQL entirely and
replace it with Kowari…

Just curious, because I’m working on a site right now doing a little of both
at the same time.


Matt

Matt R. wrote:


Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

I wrote up how I do things a few days ago. Check it out at
http://blog.mattmargolis.net/articles/2006/06/17/how-i-design-web-applications

There are a lot of different ways to approach web application design,
some will work better for you than others. There is some discussion of
this on the wiki at
http://wiki.rubyonrails.com/rails/pages/HowtoDesignYourRailApplication

Best of luck,
Matthew M.
blog.mattmargolis.net

I find data design always comes first, but you always end up missing a
few things (which makes Migrations rock).

  1. DB Model a piece of functionality
  2. Scaffold it (generate or otherwise)
  3. Play with the application flow, designing, testing with users (if
    you can), and iterating. Detail of this step:
    a. Diagram your routes
    b. Find out the navigation elements that are needed
    c. Tinker with Ajax/non features
  4. Clean up the XHTML
  5. Detailed visual design, iconography, etc.

I find that staying in step 3 the longest yields the best applications.
This is where your usability hangs. Of course if it is client work,
they always want to see you work backwards from step 5 (not ALL
clients). :slight_smile:


Timothy J.
www.foundinteractive.com

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs