History of WebShop/UnderDevelopment
Older Newer
2010-01-20 11:37:22 . . . . MembersPage/MarcellGal [webshop friendly URL]
2005-11-03 14:57:20 . . . . MembersPage/MarcellGal [shopping cart should be more flexible: visibility and add/merge]
2005-08-16 12:05:26 . . . . MembersPage/MarcellGal [new page for ReferralID]
2005-04-14 09:47:03 . . . . MembersPage/JuhaK [Maybe MPX5700 drop-in MAP?]
2005-04-13 08:59:30 . . . . MembersPage/MarcellGal [proposal for patch or script between testing - production.]
2005-03-26 11:24:44 . . . . MembersPage/MarcellGal [linked new wiki pages]
2005-03-24 22:08:53 . . . . MembersPage/MarcellGal [linked ...MultipleShopInstance]
2005-03-03 21:30:54 . . . . MembersPage/MarcellGal [now some duplicate orders]


Changes by last author:

Changed:
Priority TODO (David H., a guy who provides professional services for oscommerce since years made this for us for reasonable cost, but I don't like the limitations, and it didn't even pass basic testing):

* we should add 9% extra fee for paypal and 5..9% for moneybookers payments - there are serious porblems with these

** to bias people towards IBAN

** cover cost of freud done by paypal - see WebShop

Priority TODO

If you have any suggestions for VEMS related web development, take note here.

* main page

* products

* page headers

* meta tags

* webshop URLs should be /products/sensors/ ... not categoriID=13

** maybe OScommerce has a "friendly-URL" patch ? In any case, must be tested in the test-system, not the live webshop

* WebShop/ReferralId

* wiki => tiki only when tiki finally works well (in the test system). Tiki broke {img src=...} in the wysiwyg edit mode (so it had to be fixed at every edit!).

** Tiki broke object inclusions (like youtube or other flash video) when saving (by changing object to ob<x>ject : no user-level cure for this). Newer tiki must be tested if it still has this stupid bug or not.

Changed:
The webshop is most certainly not bad from this perspective, however there needs to be some work done on descriptions. For instance if I buy a Motec, the website gives me information on what type of engine the ECU will drive, what additional components are required and what the kit comes with. The assembled V3 controller has you will probably want to order (which I think should reworded to be forceful, In addition you will require) and a link to the WIKI. It states there are 12 FETS and 8 IGBT's. At this point you have lost your end user, and probably over half the MS community.
The webshop is most certainly not bad from this perspective, however there needs to be some work done on descriptions. For instance if I buy a Motec, the website gives me information on what type of engine the ECU will drive, what additional components are required and what the kit comes with.
Changed:
It's difficult to know what to order, as the descriptions aren't very thorough. Dependencies are obviously being checked manually once the order is placed. However it's disconcerting placing an order for a product you know is a system of components and wondering if you are going to have to place another order to complete the ECU. An automated check once going to the checkout would be helpful.
It's difficult to know what to order, as the descriptions aren't very thorough. Dependencies are obviously being checked manually once the order is placed. However it's disconcerting placing an order for a product you know is a system of components and wondering if you are going to have to place another order to complete the ECU. An automated check once going to the checkout would be helpful. (eg. warn if he ordered assembled but neither EC36-wire nor EC36-harness)
Added:
Shopping cart flexibility

The shopping cart we use now has several unreasonable restrictions.

* visibility: the customer should have control over the visibility of the cart. Most often, he wants public visibility for the cart content at least before checkout

** cart contents (read) This is probably most important, so the customer - after pointing his MembersPage to his cart - can expect help from others about what is likely missing

** cart contents (add) hints on the MembersPage should be suitable

** cart contents (delete) (not needed often)

** customer data (read). We might leave this invisible for now, not needed often.

** add / merge the contents of another cart. If cartX has 2 injector connectors, cartY has 8, adding will result in 10 injector connectors, merging results in 8.

*** Only items with very same options are added/merged.

*** read permission is needed for cartY and write permission for cartX, of course

Added:
Eg. WebShop/CommonPackages could just contain links to carts of common content. This way it is easy to make "kits", where the content can be fine-tuned as needed (eg. include a minimal number of injector connectors, say 6, in the kit, the user can bump it up easily).

----