Jump to content
Kuuzu Forum
frankl

What the software should be

Recommended Posts

Another item reported from osC-land: people are saying that their hosts are dropping MySQL in favor of MariaDB, so Kuuzu can't count of MySQL (MySQLi) being available. If it isn't already (in 2.4), all database usage should be written so as to be able to use MySQLi, MariaDB, PostgreSQL, SQLite, (MongoDB, noSQL, noDB?), and possibly "big boy" DBs like Oracle and DB2. If it's just a matter of semantic details in SQL statements (comment format, LIMIT, engine name, such stuff), that shouldn't be too terribly hard (just tedious). If it requires major surgery...

For dealing with things like inventory management in a different product and database, we shouldn't lock ourselves in to just one database at a time for a store, but should be able to do views (I think that's the term) into other databases. Something to think about, anyway.

  • Like 1

Share this post


Link to post
Share on other sites

Currently running Edge on MariaDB for a number of clients.  No problems reported.

Share this post


Link to post
Share on other sites

Is there any mileage in starting some structure to the requirements getting listed in this thread? Perhaps set up a github repo and list them as issues? That would give some traceability as to what if anything happens with them (and maybe when or why).

Share this post


Link to post
Share on other sites

A few more thoughts on language support. Since translations to non-English always seem to lag behind, how about the following:

  1. 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).
  2. 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).
  3. 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.

  • Like 1

Share this post


Link to post
Share on other sites
On 5/31/2018 at 11:03 AM, burt said:

Currently running Edge on MariaDB for a number of clients.  No problems reported.

same here

Share this post


Link to post
Share on other sites

Here's what I think we need for a basic cart. All of these would be Apps so all would be modifiable/replaceable if desired. Remember that additional Apps will be just one click away, so think really basic requirements.

  1. Front page
  2. Categories page
  3. Products page
  4. Shopping Cart page
  5. Checkout page(s)
  6. Basic SEO (automated)

Each of the above (except SEO) would include an Admin section. We would have to include shipping and payment modules as well, but those are not necessarily Apps.

Thoughts?

Regards

Jim

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, Kymation said:

Here's what I think we need for a basic cart. All of these would be Apps so all would be modifiable/replaceable if desired. Remember that additional Apps will be just one click away, so think really basic requirements.

  1. Front page
  2. Categories page
  3. Products page
  4. Shopping Cart page
  5. Checkout page(s)
  6. Basic SEO (automated)

Each of the above (except SEO) would include an Admin section. We would have to include shipping and payment modules as well, but those are not necessarily Apps.

Thoughts?

Regards

Jim

My thoughts almost to a T. 

1 step simpler for me:  get rid of categories as we now understand them...

Instead only have the following pre-set "categories" available for selection when adding/editing a product;

https://www.google.com/basepages/producttype/taxonomy.en-US.txt

Let's "disrupt"...

Share this post


Link to post
Share on other sites
26 minutes ago, burt said:

Instead only have the following pre-set "categories" available for selection when adding/editing a product;

https://www.google.com/basepages/producttype/taxonomy.en-US.txt

It's a great idea to disrupt, but whenever I've needed to work with that taxonomy I've found them too narrow.

i.e. categories for onesies for babies, which come in sizes 000, 00, 0, 1, 2, 3 etc; boys and girls; different zips etc (i.e. https://www.bonds.com.au/baby/zippys.html)

There is only one taxonomy for the entire range: Apparel & Accessories > Clothing > Baby & Toddler Clothing > Baby One-Pieces

One way to keep that taxonomy would be to include product filters, but that just adds another layer of complexity (which I'm not against per se).

Or were you thinking of another way to refine the way products are categorised?

 

Share this post


Link to post
Share on other sites
2 hours ago, frankl said:

 

2 hours ago, burt said:

Instead only have the following pre-set "categories" available for selection when adding/editing a product;

https://www.google.com/basepages/producttype/taxonomy.en-US.txt

It's a great idea to disrupt, but whenever I've needed to work with that taxonomy I've found them too narrow.

 

Why not both? Use the google taxonomy out of the box and an app to extend - for your own “personalized” categories. 

Lets face it the google taxonomy is becoming “the standard” (even FB catalogs use the google taxonomy)  - but that may not last forever. For example maybe amz gets its shit together (when it comes to categories amz is, right now, a mess) and takes over the world.

Almost exactly opposite to what I/we do now.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

@MrPhil  has the right idea here. I was thinking of leaving Categories out of my list altogether, but the idea of a very simple Category App won out. Want something more than that? Click, now you have Google Taxonomy. Or whatever else we can dream up.

One of the reasons for separating these items out the way I did was to allow for removal/replacement. Want a one-page checkout instead of three? Click, done. Don't need Categories because you only have 5 products? Click, done. More advanced SEO? Click, done.

Think Modular.

Now, any changes to my list? If not, we can move on to Core Apps that should be available but not included in the basic install.

Regards

Jim

  • Like 1

Share this post


Link to post
Share on other sites

Taking my own thoughts one step further: There is no reason to make any decision about how any part of the cart will work. We can just code up any methods that we think shopowners might like and let them chose.

A lot of the arguing I have seen here and on the other forum is about what features a cart needs. Here we can literally have them all. When a change is a matter of a single click in the App Store, modifying how your store works becomes trivial.

This, to me, is the truly disruptive part of what we are doing.

Regards

Jim

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

That's why I don't get much into how a cart should work...

 

1 hour ago, Kymation said:

This, to me, is the truly disruptive part of what we are doing.

 

Share this post


Link to post
Share on other sites
6 hours ago, MrPhil said:

so we don't have people asking for support on 15 year old installations ("my store is heavily modified...").

100%

Share this post


Link to post
Share on other sites

Taxonomies not work like categories.

it is HUGE misunderstanding that you can run a shop based on 3Th party taxonomies. 
That will NEVER work with a customer. (not in this era).

If you "want that".

You need to learn what is many to many/one/etc*.
 



 

Share this post


Link to post
Share on other sites
On 7/8/2018 at 7:43 PM, clustersolutions said:

That's why I don't get much into how a cart should work...

 

That is not the good approach, it is hypocrite.
If your main job is to deliver a shopping system to a client, you should know.

But that i why you are just users of "a opensource" script that provides you of a shopping cart you can deliver to your clients.

Where is your own Cart then?
You ever made one from scratch? 

Share this post


Link to post
Share on other sites

i think both can work, but it's just different approach...

On 7/22/2018 at 3:21 PM, OSCOMMARKET said:

Taxonomies not work like categories.

it is HUGE misunderstanding that you can run a shop based on 3Th party taxonomies. 
That will NEVER work with a customer. (not in this era).

If you "want that".

You need to learn what is many to many/one/etc*.

 

Share this post


Link to post
Share on other sites

Yeah, but by I don't get into it it doesn't mean that I am not aware of it. True?

And I would be delusional to think that I could develop this yet another cart single-handedly.

Can't say I ever built a cart from scratch, nor had I ever that desire. Don't jump the gun so quickly, there's are a lot more in the repertoire that needs to be carefully considered and be utilized properly...

OSC and the CMS that @Kymation  had bought up should make great lessons learned.

 

On 7/22/2018 at 3:28 PM, OSCOMMARKET said:

That is not the good approach, it is hypocrite.
If your main job is to deliver a shopping system to a client, you should know.

But that i why you are just users of "a opensource" script that provides you of a shopping cart you can deliver to your clients.

Where is your own Cart then?
You ever made one from scratch? 

 

Share this post


Link to post
Share on other sites
On 7/8/2018 at 12:36 PM, Kymation said:

We can just code up any methods that we think shopowners might like and let them chose.

A lot of the arguing I have seen here and on the other forum is about what features a cart needs. Here we can literally have them all.

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.

Share this post


Link to post
Share on other sites

Some things that keep coming up on osC, over and over, need to be thought about in the architecture of Kuuza. These are things like pricing, shipping costs, and taxes; which have so many ins and outs and special cases that simple solutions just can't handle. While no store owner wants to write their own custom modules for these, it may be necessary to do so, or at least we can provide some sample code that can be customized and plugged in. There's also how to handle incorrect or inconsistent addressing (affecting shipping, taxes, and interfaces to payment systems).

From a customer point of view, they want to see all the correct shipping costs presented (that the store supports), with the cheapest listed first. Every shipper/post office has its own way of doing things, that needs to be accommodated, as well as "buy X amount, ship free" deals, multibox shipments and drop shippers, and restricted shipping lists (e.g., physical goods by US Mail only to US addresses, downloadables to any place worldwide not embargoed).

Every US state has its own idiosyncrasies on what tax class to apply on what product, and how to map addresses to tax jurisdictions and their own set of rates for tax classes. Simple solutions such as "item -> national tax class, state -> list of rates per tax class" simply don't exist. Of course, the proper solution is to impose a national rationalized system (consistent tax classes, consistent state+ZIP mapping of rates, one-stop payment) but like that's ever going to happen...

And pricing gets ever more complicated with "member" or "buying club" discounts, "buy N, get M free", volume discounts, repeat customer discounts, coupons, credits, etc. Buyers would like to see prices update "live" depending on what they've already got in their cart ("regular price: $X.XX, member price: $Y.YY" sort of thing), and their buying history and knowledge of coupons and credits the buyer is holding. It gets very complicated very fast, and an architecture that allows new modules to be plugged in to take care of these cases could be useful, rather than grafting more and more cruft on to the side of what once were simple modules.

Oh yes, and make it simple enough to work with that a non comp-sci business person can easily do it. Granted, it's a lot on the plate, but at least we should be thinking about how it could be done. Do other carts out there do anything like this?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×