Hope all is well.

#2 is less favorable design.

- On the web, there are high application abandonment rates.
-Because of this you should assume that 60% of the site's users will complete #1, and drop off before completion.
-This will undoubtedly lead to extra rows in what could be an otherwise clean database
-This in turn would slow down DB operations which, even if by milliseconds, is not desirable

In general, you want to limit DB traffic, and make calls only when necessary. Having the over head of an extra call is not desirable from a user experience point of view (longer page load, even if slight), and performance (high DB concurrency -with lots of users- will lead to a drop in overall performance)

Even if you foresee the site having only 20 visitors a year, good architecture has scalability in mind.


Question: Why are you concerned with the image upload? Sending the image alone versus sending the image+form text over the wire will have negligible difference ( plain text is a light load ).

Here's a fun analogy, If you're carrying a heavy box from the house to the car, it makes little difference if you put some books on top.

I have done something similar with a real estate site I did last year, complete with image upload. It might not be the best approach but I would say:

Based on experience, i would go with the first approach. I don't know much about DBs but I would imagine that updates are expensive operations. Besides, instead of continuously updating, y not just insert once, especially, if you anticipate a heavy user population?

The part of your first approach that gives me goose bumps is the session variables part. I would just pass the field vars as hidden form fields, unless you want a situation where if the person leaves the site and returns, the values are still saved. In ASP (back in 2001 when I touched it last, so it might have changed since then) and JSP I know session vars are "expensive" and would imagine the same with PHP. Since you are using POST (I assume) for the form action, the form field values are stored and can be passed via hidden fields.

Now, where we might differ is this:
What I did was, after collecting the form fields, I inserted the values in the database, then provided a link, with the property's unique id, to the image upload page (/imageUpload.php?prop_id=Bleep, for example. So I basically had 2 steps - one for collecting data and two for uploading the image(s)). All the upload did was create a directory with the property's unique id as its name and insert the image(s) in that directory. That way, technically, I am not even storing links to the images in the DB. The links are in the code and in the code, I just hardcode the image path up until where I need to dynamically add the name of the directory (which again, is the unique id of the property).

I hope this makes sense and I hope this helps. Bottomline: again, based on experience, go with approach 1.

Single step is faster and easier to handle.

i go with AFAM, a single form will be good. despite the fact that some of this wite ppl who build a website like Dating website uses what you intend in using, but i will prefer single to multiple

and smart:
what happens if there are 100 fields? I am expected to scroll to oblivion? From a usability standpoint, that isn't good. Rather, you should see what fields go naturally together and then group them together. To aid in the process, you can then offer a progress bar (step 1 of 5 - user information, for example).

I think that is better than one long form, where applicable of course.

To me, in order not to lose people like me, it's all about usability and keeping me engaged through the process, irrespective of steps. I am very impatient. If an application process or whatever goes beyond 2 steps, I get angry. However, if there are some visual cues to let me know how much longer I have to go, I am willing to forgive. Here is an example on a site that is based in Nigeria. Bottomline, from a usability standpoint, it's the best way to go, as long as you inform the user where they are and how much longer they have to go:

Just visit https://www.virginnigeria.com/en/ng/bookflightsandmore/bookflights/index.jsp for an example.

I am finding it difficult to understand why using a single step is old fashioned, I had thought it was an improvement from the old way of filling forms especially when people did not know how to integrate an upload field in a typical form based system and would rather have more than one step.

If you believe what makes you a better developer is for you to have 5 or even 10 steps go ahead, fact remains that more people will abandon the process when faced with multiple processes, it is not about whether we agree with this or not because you cannot argue with facts.

To begin with, who will be setting up a system that requires a million fields or even thousand fields or even hundred fields? No body, at least not an online application where people are not ready to waste time.

A simple, clear single step form submission system is a winner any day, let us not us our inability to achieve a task as a basis to rubbish those that can achieve such tasks faster and more efficiently.

This is why I hardly comment on issues like this one because before you know it it boils down to people trying to outshine or outdo others.

Una goodluck abeg.

You may just build the form to receive only the
login details and a few essential fields at first.
Then when the users login they can fill the rest of the
form at any convenient time.Or may be I didnt get your
picture right.When i work with multistage forms,i usually
use location headers to go from page to page and pass any
variable i need to pass via the query string or hidden form fields.