Jump to content
Kuuzu Forum

MrPhil

Members
  • Content count

    79
  • Joined

  • Last visited

  • Days Won

    11

MrPhil last won the day on August 5

MrPhil had the most liked content!

Community Reputation

48 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. MrPhil

    The Plan

    Please, a reasonably stable snapshot of osC Edge/CE/Frozen as the first release (with names changed) 1.0 (not Legacy). Then work on BSv4 at your leisure and at a reasonable pace. Eventually 1.x will be superseded by 2.0 (based on osC 2.4?) when it's ready, but Kuuza needs something out there right away, if we want to start making an impression. Don't forget that the window is closing fast for a release this year. Online shops want to be tested and operating smoothly by October (at latest) so that they can be confident about handling the holiday rush. They don't want to see a release in November -- they'll ignore it (and forget about it), as they can't risk instability that late in the season.
  2. MrPhil

    The Plan

    While the example of the Chevy Nova may be partly an urban myth (Nova is fine in Spanish, no va is a problem), there are well-documented examples of problems with names that hurt sales in another language. Two that come to mind are the Buick LaCrosse (lacrosse is supposedly a sexual slang term in Quebec) and the IBM G4. What I heard was that IBM had to change the name (possibly before marketing in China) because the number "4" at the end of a word is very close to the ideogram for "death" in Mandarin, or something like that. I was recently on a cruise ship originally built for the Chinese market, and none of the cabins had numbers ending in "4" for this very reason. Without a thorough search through hundreds of languages, it is possible to get caught with a name which means something nasty in another language. I don't know what sort of online dictionaries are available to the general public to check such things; I'm sure major marketers do have access to such lists.
  3. MrPhil

    The Plan

    Also, in this (sad) day of news fakery and deliberate misinformation, if we're not right out in the open with what Kuuzu/Kuuza means, troublemakers will be spreading all sorts of dirt: "It's a-rab for 'young girl genital mutilation'" and all sorts of shit like that. Sorry, but that's the name of the game these days, and it doesn't have to be your competition doing it. "I run a little pizza parlor in DC. What could possibly be done on the Web to harm me?" Look up "Pizzagate" if you don't know the reference. Any name that's not clear and obvious to English speakers can be trouble.
  4. MrPhil

    The Plan

    If confirmed, is "Suffering" what we want as a name? I'm not sure how to spin it as a funny mistake...
  5. MrPhil

    The Plan

    A few things: I thought the name was going to be Kuuza rather than Kuuzu, as Kuuzu didn't mean what you thought it did? Schedules slip, and this one is already on a one-per-year rate. Keep in mind that if a product isn't refreshed/updated at least once a year (12 months), the market regards it as dead. This is what has killed osC, and is what will kill Kuuz* if you're not careful. Please plan for some intermediate releases so that even if schedules slip a bit, we're still going no more than 12 months without a major update. You can't afford to lose momentum in product releases. For example, a current stable CE/Frozen could be 1.0, with BS4 as 1.1 4 to 6 months later. Be careful about naming and numbering conventions. "Legacy" should be "1.0", the osC 2.4-based release should be 2.0, etc. You want to have a clean, consistent system, and not a hodgepodge of names and out-of-sequence numbers that sows confusion. And you never want to do like osC did and have a "Milestone" or "Release Candidate" out there for years as the official release.
  6. MrPhil

    The Plan

    Obviously the sample product set needs a refresh, just enough items to show off the store. As discussed somewhere, the samples need to be easily disposed of when you decide to start loading in your real products, without tiresome one-by-one operations (perhaps an SQL script to be run from an admin button, that only removes specific products and not everything?). It might be desirable to install a new store without sample products and categories/taxonomy, but if the samples can be disposed of with one button press (plus confirmation) that may not be a great burden. Can anyone think of a good reason to add sample products back into a (presumably empty) store? Is there any good reason to have a "remove all products and categories" button?
  7. MrPhil

    What the software should be

    Well... say we have the basic data baked into the store -- is it feasible to have several different codes to handle taxonomy vs. categories vs. ?, all working on the same data, or is a store owner's choice of organization going to affect what data needs to be used? If the store owner makes the decision up front of which they want to use, their data could be tuned to one method or another. However, they might not be able to easily switch back and forth (e.g., let the customer select which view). It could be possible to switch from one to another, but that would likely require a DB revision (offline, with store temporarily down). Should all the data be present at all times for both/all methods (and will a store owner keep the unused data up-to-date)? What kind of data are we talking about, per product, per category/class, etc.? Is there enough overlap that much of the data could be in common? For non-overlapping parts, if the store owner chooses one search/classification method over the other(s), how easy is it for them to go back and update missing data if they decide they want to switch views, or give customers the choice of views? Don't wed yourself to taxonomy just because it's hip and kewl -- it may be the wrong choice for some merchants. It would be best to give a choice of which one(s) to use (or none at all!), but we have to first think about the impact on the data we need the store to keep.
  8. MrPhil

    What the software should be

    Regarding a "basic" cart, something to keep in mind is how it gets upgraded when the next version comes out. Some CMSs replace all PHP files, assuming that all customization should be in the database contents. It should be a one-button operation (at the least, check for updates to both core code and all official additions, with hooks for checking third-party additions/extensions, and inform the owner if updates are available in a big banner in the admin area and possibly an email). Same goes for language support files -- know what core languages are being supported, and what national variants (e.g., Spanish, updated by Argentine Spanish, on top of built-in English), and inform when updates are available. I think it was over in the osC forum somewhere that I recently discussed this at length. Templates/skins might be handled in the same manner. If a store owner has modified core files, selective upgrade (deltas/diffs) might be applied, or just tell the owner that the current file cannot be replaced because it's been modified, and throw it in their lap to manually upgrade (load in the new file with a .new extension, so it's available for comparison). Come to think of it, you might want to upgrade all or none, rather than do a partial upgrade. Above all, keep the store owner informed about upgrades and make it as painless as possible to upgrade, so we don't have people asking for support on 15 year old installations ("my store is heavily modified..."). Regarding categories vs. taxonomy, I've seen some long discussions on it (can't remember if it was here or over in osC land). It's not clear to me that one method has a clear advantage over the other, so making it modular and giving the owner the choice of using either might be a good approach. That is, don't bake categories into the basic structure of the product data, but make it something on the side. Is it even possible to enable both, leaving the search choice to the customer?
  9. MrPhil

    What the software should be

    A few more thoughts on language support. Since translations to non-English always seem to lag behind, how about the following: US English as base install, acting as fallback for anything not supplied in another language (no missing string errors, but could get English text in the middle of a page). Generic "other language" (e.g., Spanish/Espanol as written in Spain) installation that any "es_*" language would first point to. It would supersede the US English strings, hopefully with most if not all defined for Spanish. Anything not defined would fall back to US English. US English would be treated as the generic form for any en_* language (or UK English, if most developers would prefer that, for base install and generic English language). Country-specific terms that differ from the generic form of the language (e.g., Argentina versus Spain). It would not necessarily be a complete replacement for the Spanish package, and would probably lag even further behind than the Spanish package. If you have a common or generic Spanish language package (core + add-ons), and country-specific terms for various Spanish-speaking countries, would a merchant still need to add their own terms to fine-tune their store? I'm not sure how different something like Catalan is from "standard" Spanish (Castilian?), so Catalan might be "another language" or it might be a country-specific term pack on top of Spanish. Let's not get involved in autonomy disputes, etc. Regarding add-ons, any thoughts on the best way to handle them? An add-on might hit multiple modules or pages, so I don't know if it's possible to put everything into one file with a standard name, and automatically have the module or page try to load the add-on's base US English, then the language, then the country pack, if they exist (the base should, at a minimum). It would require standard naming conventions and possibly one file per module or page. Putting languages into a database might be a bit cleaner, with the same search order, and the database updated during add-on installation. Any idea how much slower or faster reading from the database is, versus a file? An add-on is likely to go out in US or UK English (base install) with sometimes one additional language. Some mechanism for checking and notifying the store owner when additional or updated language packs are available for an add-on (or core) would be good. The database could keep a list of what languages and countries are in use, and check for updates on a regular basis (check for new core and add-on versions at the same time). In the meantime, I suppose a merchant might supply their own translation as either a country-specific file, or even a merchant-specific override. The code might even solicit them to offer their translation as part of the language library, or advise them that their override may not be necessary any longer. On the subject of installation in other than English, it could be feasible to supply a handful of major languages. Wouldn't each not be a full Kuuza store, but just the text necessary to perform an installation and configuration? Perhaps a few dozen entries for each language? It really wouldn't bloat the installer all that much (even less if it can be requested and downloaded as the first step of installation), and can be erased after installation.
  10. MrPhil

    Waiting...

    _____)) <(O^O)> *
  11. MrPhil

    Waiting...

    I would give him until June 30 to offer "Edge" as the official 2.3.5, with a commitment to bring out "Frozen"+BS4 as 2.3.6 by the end of the year (provided that Gary's happy with it and it's been reasonably tested). I'm all for being "fair" to Harald, but he has left osC in the lurch for far too long (even predating his recent disappearance). If he has had confirmed health or family issues (we don't need to know the specifics, just that he has a legit excuse confirmed by reliable sources) and can't immediately resume his duties, he should turn over control of osC to trusted lieutenants to carry on. If osC is moving along vigorously, we can then discuss whether a Kuuza replacement is still needed (is that the official name now?), or if it would be better to work on osC 2.4 (provided Harald opens up support and development to others). Otherwise, it's the same old same old, and we should forget osC. My apologies in advance if this comes across as too harsh, but if we don't want osC to wither and die, something has to be done. If it's not clear that this fate is to be avoided, full speed ahead on Kuuza.
  12. MrPhil

    Waiting...

    As Gary listed in the 9.5 year old discussion, there are lots of things that could be done with a good attribute system, from both the shopowner and customer point of view. Let's take everyone's favorite example, tee-shirts. I want to sell 5 designs in 4 sizes (S, M, L, XL) in 3 colors (red, white, green background) in two design variations (crew and vee neck). That's 5x4x3x2 = 120 variations, each needing their own inventory count. From a customer standpoint, I'd like them to see 5 products (designs), each with a selection of size, color, and neck attributes to choose from. A few complications: one of the designs does not go well with red, so it's only available with white or green. One of the designs is a bit saucy for kids, so we only offer it in adult (L, XL) sizes. For some reason, crew necks are not available with green. It should be easy for the shopowner to mark which combinations are allowed, and track inventory separately. The customer should see 5 products, and then select an allowed attribute combination that is in stock. If there are 5 SKUs (one per design), some means must be found to internally extend the SKUs to show the various combinations, for stockkeeping, etc. On the other hand, it could be 120 different SKUs, but then a means to gather and group them into 5 product displays (one per design) is needed. Oh, and be careful about how you handle extended SKUs or product IDs. osC had a lot of problems with using curly braces {} in external product IDs, which more recent PHP and server levels are often configured to ignore (security problems). You probably would be safe to use dashes/hyphens or similar characters.
  13. MrPhil

    A Reason eCommerce is Tough!

    Very few shoppers bother to. States are losing a boatload of sales tax revenue, as well as local jobs when brick and mortar stores close. Yet they're too stupid to close ranks and come up with a streamlined sales tax system. Apparently, they're more interested in trying to poach shoppers from other states that have higher tax rates (race to the bottom). Be careful of FBA. I have purchased a few times from Amazon sellers (presumably FBA), and the sales tax is usually way low (0% or 4% state tax only, no local county/city tax), requiring extra declaration of "use tax" at the end of the year (if you care to be a schmuck good citizen). Yes, it would be good (i.e., fair to all) to force all sellers to collect and remit the proper sales tax from their customers, but that won't happen until it's a reasonably simple and consistent system (the same tax classes nationwide, rate lookup by ZIP Code or by state, one-stop remittance). It will require Federal law changes, and possibly the overturning of a Supreme Court ruling or two. I think "Avalara" does something like this for you (for most states) on a voluntary use basis, but last time I looked they only covered general sales tax (one tax class) and had problems with tax credit on returns, etc. They take a cut of the tax revenue you collect, to pay for the system, so there's no direct cost to you. If they're collecting the correct sales tax for their customer, that helps level the playing field. But as I said above, it's easy to undercharge sales tax, and no one holds their feet to the fire. Not "having to" pay sales tax is a big draw for online shoppers, and without doubt contributes to loss of business for brick and mortar stores, and the loss of jobs and tax revenues. Often the extra shipping costs (to your home versus to a store) outweigh the tax "savings", but for some reason shoppers don't seem to notice (and shipping charges can be wholly or partially buried in the price).
  14. MrPhil

    A Reason eCommerce is Tough!

    Uh, you are still legally required to pay your sales tax when you buy out of state! It's just that the seller doesn't have to collect and remit it if they don't have a "nexus" in your state. It falls to you, the consumer, to declare your purchase and pay what's usually called "use tax" (equivalent to your local sales tax). The vast majority of online buyers blow it off, and that's a major reason why brick and mortar stores are dying. If the States want to force all online sellers to collect and remit sales tax, they're going to have to greatly simplify the process: a uniform set of tax classes, rates by ZIP Code (at worst) or statewide, and a one-step centralized payment system. I doubt it's going to happen.
  15. MrPhil

    Magento sold, again

    The software used to drive the system aside, are we heading away from "install your own copy" of software, and towards "SaaS" instead? I could see that being of value to a lot of small merchants who are not software engineers themselves, and basically want an appliance to sell for them. A small monthly cost (rental) could be more cost effective for many than free software where you have to supply your own domain, hosting, and lots of time (or specialist fees) to get running and keep it running. After all, how many brick and mortar stores own their own stores, rather than renting them?
×