Jump to content
Kuuzu Forum

MrPhil

Members
  • Content count

    41
  • Joined

  • Last visited

  • Days Won

    4

MrPhil last won the day on May 25

MrPhil had the most liked content!

Community Reputation

20 Excellent

Recent Profile Visitors

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

  1. MrPhil

    Welcome!

    This means different things to different people. I don't think it means that we have to sit down with a blank sheet of paper and reinvent everything. We can certainly borrow ideas, algorithms, and even lots of code from existing projects (e.g., osC 2.4), without having to maintain any compatibility with that implementation. Is that the intent?
  2. MrPhil

    What the software should be

    Arrgh. The allowed edit time is too short. Frank? Add: We still need to think about additional definitions needed for add-ons and other extensions. They are likely to be in English, but lag far behind in getting translated. Perhaps an English default or fallback should be part of any add-on, to be overridden by a translated pack later? That still leaves the issue of whether, say, Argentine Spanish is going to be one monolithic language pack with all add-ons, or an admin is responsible for pulling in a translation file for each add-on that site uses. That should probably be automated in some manner, so that a site always has the desired languages at the proper version for its add-ons.
  3. MrPhil

    What the software should be

    Just because code and comments are written in English doesn't make English somehow "core". Neither the owner/administrator nor the customer will see MI_HEADER_THING, just whatever the define translates into for their selected language. The administrator selects one or more language packs to install and be available. US English could be the default, but it doesn't necessarily have to be installed (depending on how language support is structured, it might be a fallback for missing definitions in other language packs). When running the site, an available language is selected (first, querying the browser; second, logged-in user or admin has a stored preference; third, anyone can select another installed language from a menu).
  4. MrPhil

    What the software should be

    Bingo! That's something that we all have to keep in mind at every step... that business people (who are rarely computer experts) and their customers will be using what we produce, not just compsci experts. Always remember who the end user is.
  5. MrPhil

    What the software should be

    The matter of language support has been extensively discussed with osC, so you might want to go back there and read it before reinventing the wheel here. I seem to recall that more of the discussion was whether language files should be used, versus database entries, versus something else; than which language is "core". If you were going to ship the base install with just one language, en_US would probably be the safest bet, as a lot of people around the world have at least a passing familiarity with it, and developers are most likely to write US English text for new code. However, you might have a store where no one (including the owner) will use US English, so it would be good to have it as "just another" language pack (perhaps included by default, and by default is the only language selection available). Don't forget that non-English language support tends to lag behind English. Before installing Kuuzu, owners could select one or more additional language packs in some format, so they can install in a language they're most comfortable with. Additional languages can always be added later (or removed, as when Le Republique de Quebec outlaws English). The issue of how to support languages is big enough that it should probably be split off into its own sub-area of the forum. I would expect multiple threads to emerge, and keeping them grouped together might be useful.
  6. MrPhil

    Where to post.

    I'm most familiar with osCommerce and OpenCart, and in neither case are their forums well organized. osC has, really, just one version that should still be supported (e.g., 2.2 should be EOL'd and discussion cut off). OC has 3 or 4 "current" supported versions, and while each has its own section of the forum, idiots can never figure out that 2.3.0.2 is version 2, not version 3. You can't fix stupid; just be brutal about moving wrongly-posted content to the right place. Even if you had a separate forum in a subdomain for each major version, I think you'd still have such troubles. About all you can do is clearly label sections for versions, and patrol postings constantly. And don't label something "suggested enhancements for version 1" if you intend for that section to also handle version 2, version 3, etc. Otherwise, create "X for version Y" sections for each version.
  7. MrPhil

    Where to post.

    I'm wondering if people are getting lazy and just starting threads in the Team Discussions rather than over here, out of force of habit. TD should be limited to things which need to be kept out of the public eye (such as proposed product name). Once that's settled, perhaps these discussions could be moved back to the public area. By the way, "New Store Proposal" will eventually become obsolete, and we will need new development and support areas. NSP will eventually become just an archive of early work, unless someone wants to rename it to "Development". We also should think, in advance, on how different versions of the product will be handled, and how the forum will be best organized to support product versions. It needs to be very clear, or we will end up like osCommerce or Open Cart and have dimwits constantly posting in the wrong area (e.g., a question for version 2.3.0.2 posted in the Version 3.x area).
  8. MrPhil

    osCommerce Forum - NO LINKS

    If we're going to (at least) start by copying chunks of code from osC 2.4, we'll need to leave in their copyright statements for the time being. Otherwise, any mention of osCommerce (except in text or comments acknowledging Kuuzu's debt to that project) should probably be removed or changed. There's no point in confusing people by mentioning osC where we don't have to. That brings up a question -- how about the "tep" prefix on a lot of functions (The Exchange Project, osC's predecessor)? Eventually their code will diverge from osC's and they will not be interchangeable, so maybe it would be good (if it hasn't been done already) to rename tep_ functions to ku_ or something? If there's going to be further discussion of such things, perhaps a new thread would be appropriate, rather than hijacking this one.
  9. MrPhil

    Welcome!

    That's always been a minor annoyance, particularly for those with no SQL skills to do it in bulk. I do like the idea of installing no samples, or of having several suites of samples, but make sure there is some "one button" way to reset to empty (maybe reset the product ID, etc. to 1, if that bugs people). Either hide this very deep in admin, or have a confirmation dialog ("I just entered 1500 products by hand, and accidentally wiped it all out when I thought I was removing the last product! You guys suck!"). Speaking of which, something like Easy Populate (read a CSV file) should be built in, so people don't have to go through manual entry for their initial load.
  10. MrPhil

    Welcome!

    OneKnob(tm) ecommerce solution. I like it!
  11. MrPhil

    Welcome!

    OK, let's look at this from another angle. If you were a business person (with no unusual computer skills), and you wanted to go online, what would you be looking for in a shop? Are you looking for a tool or appliance to help you sell, while consuming minimal time, or do you want a new hobby? Is it important to be totally free, or is your time worth something? You install on your own hosting, or rent a shop with a low monthly payment depending on your turnover (the shop would know what you're making)? Primarily WYSIWYG, or Wizard-led (with ability to edit configuration/layout files available)? What other features would have wide appeal? Maybe we should figure out our audience first, before trying to built the Perfect Shop.
  12. MrPhil

    What the software should be

    I can sympathize with that, but inertia is poisonous. First of all, they screwed up if they did not keep good records of what changes they made (anything that's not pure vanilla out-of-the-box release). Not just what they did, but also why they did it. Sometimes a new version comes with something built-in, and an old add-on or tweak can be dropped or done much more easily. That's why you must record why you did something. We can help by clearly documenting such things and how to move from the Old Way to the New Way. I know it's tempting to iteratively twiddle and tweak files until it looks "just right", but you'd better write down what you did and put it in a safe place, before you forget. Sure, making a fresh start can be daunting -- who enjoys looking at a blank sheet of paper when you have to write an essay and the clock is ticking? What we can do is make configuration and getting everything "just right" a simple task for shop owners. Some people prefer WYSIWYG, and others like text configuration files (.ini, etc.), and still others appreciate a Wizard to lead them around, and in an ideal world you have all available. You might use a Wizard to do the initial work, then WYSIWYG to tune feature selection and layout (once you know what's there and what you can do with the system), and finally edit .ini files to get the last little changes in. Data (database and images) should have an easy, mechanical one-button transfer process. What programmers and hobbyists keep forgetting is that most of the people using this system will be business people -- mom & pop store owners for the most part -- who have no interest in learning a complex system... they just want an appliance to help them sell, and to take as little time and effort on their part as they can.
  13. MrPhil

    What the software should be

    Reading through that GitHub entry, I'm not quite sure how HPDL intended to integrate v3.0 with other stuff. How much of that is actively running today? Is the osC forum actually integrated with an osC apps store, or is there an umbrella or shell over a discrete set of applications? What I have in mind is an application-agnostic framework that handles login, session, permissions, theme, and provides commonly-needed utilities. Then, an application (such as the new Cart) provides a library of modules to plug in to the framework. One would be to manage the shopping cart, which connects to checkout. Another would be catalog search and display (as well as sales, clearance, new, featured, etc.), where you could instead choose to have your own hard coded product or service pages with a "buy now" or "add to cart" call to a Cart shopping cart module (the same call as used in a catalog page). That is, you would not have to use the provided catalog pages, database entries, etc. but can roll your own (such as needing very different pages for different categories of things, or offering just a few items). The Admin side (however separated that is) might largely be a DB view of your store POS product database, rather than using the provided admin functions. Mix and match type of thing. As shipped, the Cart would provide a basic store-only framework, which you can use to get going quickly, or you could plug in the various pieces to a more elaborate framework that will eventually drive a separately-offered forum, blog, gallery, etc. I think that ecommerce is far more complicated than any of the other applications, so something that works for ecommerce should make forums, etc. easy. Note that things like product reviews and feedback could share a lot of code with a forum or blog application. Pages in any application could be hard coded PHP like osC currently is, or could be more of a CMS-style of page content (preferably PHP + HTML, not just HTML like most CMS's) being in a database. A given site might have a mixture of the two styles. Anyway, that's the dream. It may be too much for an initial release of the new Cart, but we should consider architecting the system so that it could become reality some day.
  14. MrPhil

    What the software should be

    This is the last chance to "get away" with breaking osC compatibility, so let's make the most of it. We don't have to maintain compatibility with existing osC releases, so if something needs fixing (by changing it), now is the time. There are a lot of things in osC that appear to have been initially implemented in a simple manner, and more and more cruft was grafted on over time to accommodate user needs. For example, product information update was done as an edit page. Later, someone wanted to bulk-import product data, and CSV-import add-ons came along. Perhaps we should think in terms of a CSV (and/or XML) update file or data array, with the edit page merely creating this file, and the base mechanism is the file import/process. In general, a clean architecture for both importing and exporting data (such as accounting data) is needed, as well as APIs to talk to other applications in real time (e.g., your warehouse inventory system, or your brick and mortar store POS system). Perhaps the inventory could be separated out so it could be easily integrated with another system? Even as a different database than the rest of the new Cart uses! Another area that has gotten very complicated is figuring taxes -- something very modular to insert tax at the appropriate time should be considered. Prices too have gotten well beyond a single number in the product database -- coupons, membership clubs, discounts, credits, sales, etc. I don't think we can cover all the bases in a first release, but if the architecture is suitably modular, new capabilities can be plugged in later. Speaking of "plug-ins", the ideal would be for the new product to be considered as easy as Wordpress to install, configure, and upgrade. Yet, you don't want developers (function or theme) to be put in a straitjacket and severely limited in what they can do. It's a difficult balance to strike in consistency and structure, versus freedom to innovate. Beginners have constant struggles with osC, and anything we can do to streamline things for them would be much appreciated, while not putting a ball and chain on developers. We seem to forget that most store operators are not Computer Scientists or even programmers; they're not looking for a new hobby, but for a tool (appliance) to help them. For instance, why are there two configure.php files? It it really still necessary? Do we still need to separate out all the code for admin so it is in a separate directory structure? If security concerns require a separate directory under password control, can we have a single source of files (especially just one configure.php file) that somehow automagically gets copied over to the other side when updated? Besides the configure.php files, I'm thinking of all the utility files that have over time slightly diverged, and are no longer compatible between storefront and admin. Speaking of modular structure, I think it would be great to have a Cart provided as a module library that are to be plugged into an application framework. The framework provides session control, signon, theme, common utilities, etc., and the Cart library modules do the Cart work. The Cart would provide a simple framework to use out of the box, but that could be replaced by something more elaborate if so desired. We should get away from applications that think they own the entire website and won't play nice with your forum or blog or gallery application. An example would be a cart status page module (with leads to checkout) that could be plugged into your standard page header. Even if you were over in the forum, you could still see your cart with a reminder that you have stuff in it. If you logged out while in the forum, the Cart would remind you that you're about to lose your shopping trip -- do you really want to log out? That sort of thing. With the right framework, other parties could provide forums, blogs, galleries, and whatnot that just plug right in, and you can bounce between applications on the same sign-in and session. One of my biggest gripes with osC is that a product is dead and buried if it doesn't have at least an annual major release -- and osC can go many years between releases, necessitating a reintroduction to the ecommerce community! The new ownership of this osC follow-on will need to commit to frequent releases so that the world sees it as alive. Don't fall into the OpenCart trap, where almost everything has a price tag (and some authors get really wound up over people not wanting to buy their code), which discourages people from getting on board. I would have no problem with a free basic system, with payment for more deluxe or capable content. If someone wants to offer free code, great, so long as they don't steal code copyrighted by someone who is trying to make a living selling it. If someone wants to sell a deluxe version of something, great, so long as they aren't stealing someone else's code given to the community. I may or may not be able to contribute much in the way of code, but am willing to discuss architecture, and am willing to write documentation once others have provided the information. I think this is an opportunity to make something that's not just another "me too" shopping cart application.
×