_______ 
(  ____ )
| (    )|
| (____)|
|  _____)
| (      
| )      
|/       
         

___  ___
|  \/  |
| .  . |
| |\/| |
| |  | |
\_|  |_/
        
        

           
     /\    
    /  \   
   / /\ \  
  / ____ \ 
 /_/    \_\
           
           

         
#### ### 
 ##   #  
 ##   #  
  ## #   
  ###    
   ##    
         

         
         
 ######  
    ##   
   ##    
  ##     
 ######  
         

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
'''This page lists brainstorming ideas to make the shop more convenient''' '''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. ---- '''Source easy to mount HALL sensors''' - preferrably from US, help please * Honeywell GT is a '''proven''' sensor that has exactly the right specs. * easy to mount * FYI: the type which has the magnet on the same size of the wheel as the sensor has in fact 2 sensors 2.5 mm apart, it calculates the difference internally. * price for 50..100 (must be under 40 USD) * ask 1stvwparts ? ---- '''Items related wishlist''' Items that would be nice to host. If you have ideas where to get (what types, and for how much, in quantities of ~100) them from (especially if you can supply): * "Genboard Onboard" stickers (previously in stock, in black-red and red-black colors) - no stickers currently * fuel injectors - new (some at Jorgen's place, in shop already) * fuel injectors - used but tested (sources?) * ignition transformer: COP coils. VW has some cheap-ish COP transformers. Around $18 USD each from memory. See VW part 06B905115E, $17.61 - is this the coil that breaks all the time? Could someone explain what is different with part 058905105 ($50) ? * ignition transformer: wasted spark coils. Is someone like MSD worth calling for this? Possibly for their fuel injectors too - or should we be talking nicely with Bosch instead and single sourcing most of these supplies? Denso is another option for most components. I suggest dual transformers of Peugeot 206 GTI (part number?). Those must work in your 4 cyl. engine, and because it is a popular type, can't be too hard to buy them. * connectors: Deutsch - depends what line is needed, but Deutsch is quite approachable and will redirect to the appropriate distributor (eg http://www.servoconnectors.co.uk/) if volumes are too small. http://www.deutsch.co.uk/ * connectors: GM weatherpack - [http://order.waytekwire.com/cgi-bin/lansaweb?procfun+wordpr01+webfunc+m37+FUNCPARMS+WEBCMP(S0020):01+WEBID(S0020):01 Waytek Wire] has these at good prices - look under multi-pin connectors -> Packard weather pack. * fuel pumps * fuel pressure regulators (oops, I need this myself :-) * higher grade wires: sourced, used in the harness (not sold separately) http://www.steinair.com/ has good prices for Tefzel wire, and Waytek above for SXL. * cheap 12V and 230V solderer (not metcal, just connectivity solution, but must be able to solder smd-s): sourced should be added to shop * sensors: GM temp sensors (iat and clt) * sensors: Bosch/GM TPS pot * sensors: Wabash non-contacting TPS: http://www.wabashtech.com/pdf/1047%20leaflet%20aw.pdf * pressure sensors, [http://cgi.ebay.com/ebaymotors/ws/eBayISAPI.dll?ViewItem&rd=1&item=7923998260&category=6763 Ebay Link], for fuelpress, oil, exh.backpressure..... * [http://www.freescale.com/files/sensors/doc/data_sheet/MPXH6400A.pdf new MAP option] for higher kPa range. Or maybe drop-in [http://www.freescale.com/files/sensors/doc/data_sheet/MPX5700.pdf MPX5700]? * cheaper purchasing source for the expensive VW MAP and MAP sensor * [http://catalog.tycoelectronics.com/TE/bin/TE.Connect?C=11710&M=FEAT&LG=1&I=13 pressure line fittings] (from any manufacturer) Please help make a list of useful items (exact part numbers). **[https://www.delcity.net/tstore/servlet/pagebuilder?frame=catalog_browse&category=Grommets%20%26%20Hose%20Clamps&page=1 fuel injection hose clamps] * Some might be interested about pin extractor tools [http://www.t-g-s.de/Gabel.htm ex.1] [http://www.stahlwille.de/katalog_engl/show_kat.php?kat=stahlwille0000313&ebene=3&show_tree=1 ex.2] * etc... write new ideas ---- '''software Todo''' list of improvements: * Add two images one thumbnail and one larger size (640x480) like the other sites use. having the client scale is very bad. The image can look very bad do to bad scaling on the client. It also makes the page load very slow. And uses more bandwidth then needed. We need to get this done soon so we can. It will take some time to remake all the Images and the sooner we getthis the better. it is important to improve our shop infrastructure because * we want better service for customers (customer focus improvements) * easier for the service stuff: shopkeeper focus improvement * headquarter focus improvement. Since VEMs is becoming multisite (because of efficiency and good support worldwide) ---- '''Customer Focus Improvements''' Ultimately we need an interface that is incredibly easy to use. Simplistic choices that break down into greater complexity on demand. This way we can target a market from an end user to the MS type customer to an experienced EE. 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. 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) Also a more thorough list of dependencies would be fantastic, even if this is just a pointer to the a single WIKI page. Remember there are no hard dependencies. The "dependencies" are just recommendations. RedMist wrote: That most certainly is an issue. Perhaps we should rewrite some of the descriptions and make them necessities. If someone is knoledgeable enough to determine they don't need a component then they simply won't order it even if it states its a necessity. "BEFORE YOU CHECKOUT ENSURE YOU HAVE CHECKED THIS WEBPAGE TO ENSURE YOU HAVE CONFIGURED YOUR GENBOARD CORRECTLY." Pointing people to the wiki is a good idea (in fact almost every page does that). I had noted that, however they point to descriptive pages on the website that give little indication of what exactly to order. IE if you require this feature you WILL NEED. In the end it would mean less work in regards to ensuring everyone's individual BOM is correct. see MembersPage/RedMist/GenboardOrder || '''Feature''' || '''Requirement''' || || Direct Drive Fuel Pump (no relay) || 1 x FET for each pump|| || Wide Band O2 || 1 X FET: FQPF20N06L for each WBO2 sensor || It seems to me there are 2 choices for this: * '''simple''': let people use a '''wiki page''' to plan their project and BOM. This would allow manual verification of BOM, but experts can do this very fast. Prices should be much higher for anyone who cannot describe in short what he wants to do, or unable to ask for help. The reason for this is the support nightmare. * '''superfluous''' the project can be planned in ofbiz or in the tuningsoftware (starting from a template that closely matches the project) to a large degree. This would allow real control over dependencies, and automatically warn about "missing" items. The entry cost of such a system is very high. Also, experts wouldn't need it, and beginners could get confused easily. It's likely that manual review would still be needed. Because of the high price and small benefit I estimate that the return of such a decision-support system is about 2000..3000 sold units. (I might be wrong) In any case, '''templates and examples are of great value'''. This is the 2nd reason I always ask people to scratch their plans in wiki. (the primary reason is that in email it finally takes 5x more time for them, and 20 times more time for the support crew). I started WebShop/CommonPackages to help customers pack their shopping carts in less time with less intimidation and more confidence. ---- '''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 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). ---- In addition should we not just increase the price of the kit and add minimal amount of IGBT's and FETs to suit a basic 4 cyl engine,to the rescue kit? Would make pick and pack alot more simplistic and would also decrease potential client frustration. We always had a kit with increased price (the cased unit). The client should plan his install to some degree, especially when chosing the cheaper option. * requirements, and from that revise a * BOM * ask for review RedMist wrote: Very good point Marcell, there is little point in differentiating the product more. If he is unsure, he should make a wiki page first and ask for help. The shop infrastructure is not sufficient for this process (unless one invests significant time and makes it possible in ofbiz.org), but it's hard to make it simpler than a wiki page. Remember that this is one the simpler parts of the project: if someone is not confident, he should ask. If unable to ask on a simple page to help with his BOM, his project will fail anyway. He should buy a complete car. RedMist wrote: This again depends on our target audience. If we state we wish to attract the MS style community then we most certainly cannot expect them to construct BOM's. Personally I'm very much on the low scale of experience with engineering, however would rank well up on the MS scale. The MS is simple, fun relitively flap B goes in slot A. I would hope that the VEMS product is heading in this direction, otherwise my project will also fail. But this is the same as you suggested: pointing people to wiki for planning their BOM in wiki is the simple, yet very efficient tool. I doubt that anything more complex would be easier to use or more efficient. When selecting an option. Such as Case holes, the "return to shopping" just returns you to back to the case selection screen. Where should it take you ? Attempting to alter quantities isn't self explanitary. There is no "Update" key, you must adjust the number then hit enter (which I would have thought would have taken me to checkout) ---- '''shopkeeper focus improvement''' * Reduce "edit invoice" to one click. (maybe the edit order could contain links at the top for some other orders, eg. prev. 3 and next 3). Since we don't have too many items, even a matrix of order,item (containing pieces+price) would be possible. * DONE: [http://www.oscommerce.com/community/contributions,1168 make cart => checkout before payment confirmed] to avoid phantom payments. Funny enough, a duplicate is created for many orders in the "problematic orders" listing. Easy to delete it, but Annoying. Some only end up there. * DROPPED: merge orders. This looks harder. ** custumer could add to his previous order, if the order's shipping-status is less than (say) ''packaged'' or ''sent-out''. ** the shopkeepers could merge orders too Add a payment status and target (since recipient can be many!!) - in our situation parts ship sometimes after, but usually before payment is done. We need to keep track easily. Some mechanism to assign warehouse '''and status''' (ordered-item parameters that can have value from a given ''set'', in general) to ship from by individual item (eg. WBO2 and Connector to ship from US while other parts ship from Hungary). No strict relation with the order status needed. If we set the whole order as ''sent-out'', we don't much care about the individual order-items any longer. But before that, it can be nice... * for each (wearhouse,item) a field for the sum of stockquantity that is scheduled to arrive in the future, and a long comment field. It would be too complex to have a record somewhere for each scheduled future stockin (that takes us to ERP functionality), but it would be nice to maintain the data somewhere near the actual stock, even if it is updated manually. We could take notes in the comment for when the items will come and where from. ---- '''headquarter focus improvement''' NOTE: ofbiz solves most of this, we just need to migrate slowly (stock is in ofbiz already, sales should be from ofbiz too..) This must help planning, supply chain, margin reports, etc... We will grant license for enterprises who want to sell VEMS related items. We want to have some regulations on reports, commission (part of the profit will stay at the shop, and some will be passed on that finances the common developments) but be flexible in some other means. * add siteid to transactional data so it can be easily distributed (and syncronised). In the simplest case, this would just be number ranges for orderid-s. site1: 1000000..1999999, site2: 2000000..2999999 etc... This would make it possible to have several shops (maybe some not available to customers), any of them could record initial orders and used to process shipments. * multisite stock-keeping would be nice (not as hard as it seems). It would be nice to see availability for each items in each of our stock warehouses. Maybe we want to make it possible to have someone's items stocked at another warehouse, but if prices don't change too fast, it's OK to do the clearing at material movement time using MAP. * besides calculating MAP (moving average price, which is the effective purchase price) we want to have a service fee which is for the shop 100%. Eg. the harness is basically zero profit, the shop can have all profit if it makes from wire + recepticles, while other items are very simple to stock and sell - profit on genboardv3.1 will be shared, some part passed to common distribution. * make a script or patch that converts the production tree to the testing tree and back (updates hostname). Without this, testing is a PITA ---- '''Prices:''' * the harness price should be raised a bit, I think, it's a loss when it's ordered alone without genboard... * price of other items had been decreased (improved supply chain) ---- '''pictures for broadband capable gimpers:''' http://www.american.hu/GenBoardv31 especially the new, shorter EGT with nice ''bung'' and the application of the new recommendation highZ FlyBack (SMB diode and SMB transient suppression diode) - I should ask GF to redo the pictures, what I make with her camera are horrible without exception: http://mail.american.hu/GenBoardv31/EGT_short/ Q: What the fitting specifications are cause I'm building a header and like to weld a bolt on it for the EGT right now thx. The header must have a hole, with female thread (4..7 mm length is OK): the outer diameter of the male thread (sensor-part) is 1/3 inch (standard piping /NAPA?/, not metric). We plan to have metric soon, that will most likely be M10 10mm thread. Fero, you measured yours more precisely (header done), can you put results here just to double-check ? '''Currently the K-thermocouple is available only with 120mm long sensor element, the connection is +30mm and 2.5m cable. The sensor can be bent if needed.''' It takes nothing to order shorter thermocouples (in fact we have a very cheap ~9 Euro one perfect for head-temperature - should be uploaded to shop) but if the tip is 1000..1100C and environment is also hot, it will be harder to keep the cable connection to max 400C with a say 60..80 mm short probe. ---- '''See also''' * CompenSation/Distribution * WebShop/UnderDevelopment/MultipleShopInstance * WebShop/UnderDevelopment/NewItemIdeas * WebShop/UnderDevelopment/ImageIssues
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.