SitePoint Sponsor

User Tag List

Results 1 to 5 of 5
  1. #1
    SitePoint Mentor silver trophy
    Rubble's Avatar
    Join Date
    Dec 2005
    Location
    Cambridge, England
    Posts
    2,198
    Mentioned
    72 Post(s)
    Tagged
    3 Thread(s)

    Complicated order form with part picking.

    A customer of mine has a very complicated price list and I have avoided making it interactive so far. The users currently fill in a price list and email/post it to him.

    I will explain what the options are:

    1/ Full kit - everything included appart from some accesories.
    2/ Small kits - e.g. Wheel kit or fixing kit etc.
    3/ Pick what you want from the full list.

    Things start to get complicated now as there are things like alternate power sources; for example twin instead of single motors. If you have the full kit and upgrade to twin motors you pay a premium for the extra motor BUT you will then also need two drive shafts rather than one and possibly an updated controler.

    I suppose I could have a kit for single motors and a kit for twin motors but there are other options like smooth tyre or off road tyres and all of a sudden I need 6 price lists and there are more options and 4 different models!

    Any ideas how to approch this? I can use php and Mysql but would it be better using another laungage. But this would mean a lot of "if" "else" options or would "switch" be better?

    What we are trying to do is reduce the time to process the orders and talk to confused people who are not sure if the need a twin drive kit to go with a twin motor setup etc.

    I suppose I need a flow chart type of order where the user picks the main items and they are offered options. Depending on the choice the order is updated with the other items that need to go with the option choice.

  2. #2
    SitePoint Mentor silver trophy
    Rubble's Avatar
    Join Date
    Dec 2005
    Location
    Cambridge, England
    Posts
    2,198
    Mentioned
    72 Post(s)
    Tagged
    3 Thread(s)
    I have started a method of using forms at the moment which takes you down different paths.
    Pick a full kit > options > no options > end
    Pick a full kit > options > confirm options > end
    Individual parts ( including small kits ) > options > no options > end
    Individual parts ( including small kits ) > options > confirm options > end

    I am saving the prices and descriptions into a database.

  3. #3
    SitePoint Mentor silver trophy
    Rubble's Avatar
    Join Date
    Dec 2005
    Location
    Cambridge, England
    Posts
    2,198
    Mentioned
    72 Post(s)
    Tagged
    3 Thread(s)
    As I have steps would it be better to save the order information into a database and just keep an order number in a session; rather than keeping the whole order in a session?

  4. #4
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,233
    Mentioned
    47 Post(s)
    Tagged
    1 Thread(s)
    Well, I have a rambling set of vague ideas, but I think your architecture question isn't really usability yet, and might also need to sit over in Programming somewhere (since we don't seem to have a place for architecture questions). Below is my completely uninformed opinion spew.

    I don't think you should be doing many if-elses and stuff. I believe the product objects should determine everything whenever they are asked (called from the db) such as when a product page is called. Your front-end template would be checking these things... for example our products, we'd have something like this:

    {% if product.variants %}
    (if there are variants of this product, otherwise none of this HTML gets rendered)
    <table>
    ...blah blah...
    {% for v in product.variants %}
    <tr>
    <td>{{ v.name }}</td>
    <td>{{ v.whatever }}</td>
    <td>{{ v.whatever else }}</td>
    {% endfor %}
    </tr>
    etc..
    </table>
    {% endif %}

    This table may be inside a form and we may have, for example, checkboxes with product and variant id's attached in the table cells.

    So the form knows nothing, the template adds more formy-stuff to the form depending on what the object's information has, in the DB.

    I suppose where you store each product object on the back end, those products will have individual "requires" lists attached to them. These "requires" are themselves other objects, and so would also have their own "requires" lists as well. A nice webby mess.

    If the optional objects are truly optional but have related use to the main object, then possibly each object not only has a "requires" list but also an "options" list. Again each object in the "options" list would have its "requires" list.

    Obviously a part of one sort like a wheel would have an empty requires list: it is more likely itself listed in many other objects as a required thing. So someone requesting just that one object would only get that one object. Maybe if that one object only fits certain other things then it need a list of "matches" like you get with ink cartridges. So while each printer object has in its requires list at least two ink cartridges of certain models, the individual ink cartridges themselves have a list of who lists them in their requires lists.

    I would think these needs, options and matches lists are intrinsic parts of each object (thing you can buy) and so I don't think the forms or the session should have to determine these things. Just like a product may have an attribute like being red or having screw holes of a certain size, the "requires" is also an attribute.

    So when you have groups of product-objects like kits, I suppose they would come in two forms: complete kits (where every object member of the kit also has its requires list of objects also as part of the kit) and complete kits + options lists (and whenever an option is selected, its "requires" list of fellow-objects gets included). Everything else is an individual part with its own requires and options list.

    It sounds like if you have a normal (relational) database you'll have lots of many2many tables and an ORM that knows which tables to add which objects to. If you have an object database then basically every object has attributes which are lists (I guess these lists would use the unique name/number to reference things).

    Seems if all this is part of your products in the back end, the front end will merely be meeting requirements and showing what is required based on the client request. Your forms (or front-end template) will be stupid and will simply be told "this product HasRequireds and HasOptions so add the form chunks that would contain those". That way what shows on the screen has only everything to do with the intrinsic knowledge coming from the requested object and nobody else needs to know diddly squat.

    I think the only way a customer would be able to see a total price is *after* they have dealt with each selections' "requireds". They can see the individual part-price, but not the "full" price. Only after that can you decide things like coupons, shipping, etc.

    If you have a page listing all these products, parts, and kits all together, I don't think you can fairly state the prices listed there are "full" prices and would have to have text near the top of the page stating this... *unless* the thing you're showing is
    - a complete kit where all requireds of objects inside are included in the kit
    - a part with no requireds of its own.

    Everything else can only show a base price at best.

    I suppose I need a flow chart type of order where the user picks the main items and they are offered options.
    In our db's we have all the info on each particular product. When a user goes to a product page, everything known about that product is called from teh DB (actually usually from our cache-index and then the DB). So in your case the information on the product on the product page would have these requireds, options and matches lists.

    Product -> shows product info, requireds list, options list, matches list. If product has empty requireds, add an add-to-cart form. If there is a requireds list, there can be a form but it now must list more products with their own checkboxes to add-to-cart.

    Product: a Foobar
    type: part
    requireds: []
    options: []
    matches: [model1, model2, model15]
    variants: []
    price: price.


    Clicking on a Foobar from your total catalog brings up a Foobar product page with the above listed and an option to add to the cart. Its price is stable unless you have discounts, coupons, etc.

    Product: a Group Thingamajig
    type: Machine
    There are two versions of this Thingamajig: the basic and the extra-large.
    requireds: [power supply model x, batteries model y, antenna model a]
    options: [special alloy wheels models d or b, remote control models b or d, plastic flashing models a, g, and h]
    matches: []
    variants: [green, blue, red, yellow]
    price: [base price: price, othermodel: otherprice]

    This page does not allow an add-to-cart, because there are two sorts. This is an intermediate product page IF your products are set up this way. Ours are not, btw: we would consider basic and extra-large versions of a product to be two completely separate products who fall under the same rubriek (so if users search under the rubriek, both these elements appear in the product listing of course). However I don't know how your customer is doing this. So if you're doing like the above then the user must first choose a version. They choose "basic".

    Product: a Thingamajig
    type: Machine
    version basic
    requireds: [power supply model x, batteries model y, antenna model a]
    options: [special alloy wheels models d, remote control models d, plastic flashing models a, h]
    matched: []
    variants: [green, blue, red, yellow]
    price: price

    Users get presented with a price, but like on a clothing shop, this page (which has a form because it has an add-to-cart button) lets the options->plastic flashing models a or h be chosen (or left blank). Since these options are products themselves, they will have their own lists. If they choose nothing, they can add to cart. Otherwise they may choose an option. This would call another product (maybe the same page) and show everything about this product, since it might have requireds. It probably doesn't have options. It probably does have matches, and Thingamajig version basic is in its matches list.

    Depending on how much configuration there is, it could get very nested very quickly. The Back button should be able to bring users back to earlier forms. The session should only keep track of what has been viewed, and separately what has been added to the cart (and therefore what the current running total is), but it should not keep track of requireds for things added to cart.

    You could maybe have it that if a user tried to go further in the cart (go actually order these things) that each item's requireds lists are checked that they are also in the in-cart list, and if not either stop the user or give them a warning and let them choose not to fulfill all requirements (who knows what users actually plan to do with this stuff).


    Well anyway that's my go at it, and I probably made a lot of assumptions that don't match your setup.

  5. #5
    SitePoint Mentor silver trophy
    Rubble's Avatar
    Join Date
    Dec 2005
    Location
    Cambridge, England
    Posts
    2,198
    Mentioned
    72 Post(s)
    Tagged
    3 Thread(s)
    Thanks for the information Stomme poes and I will digest it later; it may be as you say I need more tables or more information in the tables. A bit of lateral thinking required - possibly need to post something in the database section.

    So far I just have two tables: All the standard items which also go into the standard kit and a table with all the options and accessories.

    I am awaiting feedback from the site owner before I get any further into this, as I do not want to spend loads of time on it and the owner does not like it.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •