MS4 - What are/should be the criteria

[♥bruyndoncx]

Tomorrows meeting in Antwerp is supposed to discuss which contributions should be (considered for inclusion) in MS4.

 

I think the general assumption is that you take the most popular contribution and add these, but maybe that is just to much bloat for certain kinds of stores.

 

E.g. Credit class and gift voucher, what if you are setting up a pure wholesale shop, gift vouchers are not really applicable in that case.

 

While other contributions are pretty popular, but also very easy to install, e.g. product listing in columns, so why would you include such a contribution into MS4 if it can be easily added afterwards.

 

So I was thinking of these dimensions:

- does the contribution change the database scheme ?

- does it touch upon a lot of files ?

- does it help the retail shops ?

- does it help the wholesale shops ?

- does it help the developers ?

- is it purely an admin (GUI) enhancement ?

- is it purely a catalog (GUI) enhancement ?

- is it easy/difficult to install ?

- is the contribution bug free/stable ?

- does the contribution have serious limitations that would need to be adressed ?

- does the contribution have known incompatibilities (with other contributions) ?

- how many forks/loaded versions offer this functionality out-of-the-box :D

- does it improve the site performance ?

- does it save time in operating the store from the admin ?

 

and then there are other potential functional enhancements not yet available as contributions that might be time better spent, just to throw in something hot/sexy: e.g. AJAX based advanced search and/or product listing

 

Voila that's my braindump, so what else to consider ?

 

Please, refrain from listing particular contributions, this topic is not to vote for the best contribution, but take a step back and see why you want to include it and if it's a reason that has not yet been covered, make sure to post it here.

[burt]

I'd like to see MS4 become much more modular. This will require most al contributions to be re-written but that'll need doing anyway due to the function name changes.

 

The existing PaypalIPN module (the one released by osCommerce) is a good example. Drop it into your site using FTP, enter Admin and enable it.

 

Wouldn't that be perfect for all Contributions? Then any contribution could be added without affecting any other...

 

Re: Hot'n'Sexy Ajax based advanced search - did you read my blog today?

[♥bruyndoncx]

I'd like to see MS4 become much more modular.  This will require most al contributions to be re-written but that'll need doing anyway due to the function name changes.

I agree, but I don't know how much of this ultimate modularity is envisioned in MS4.

 

The existing PaypalIPN module (the one released by osCommerce) is a good example.  Drop it into your site using FTP, enter Admin and enable it.

As the oscommerce design for MS2 already is modular in this area, it's easy to do. I don't know if the same modularity mechanism can/have been used in MS3. Time or some one more knowledgable will tell !

 

Wouldn't that be perfect for all Contributions?  Then any contribution could be added without affecting any other...

Unless you want to combine contributions ...

Like the way attribute sorter is repackaged with different other contributions. Or in the future that might just mean that the design hasn't been made modular enough.

 

Re:  Hot'n'Sexy Ajax based advanced search - did you read my blog today?

<{POST_SNAPBACK}>

No, I've seen Ajax mentioned a lot recently, even made me wonder if FC Ajax opened up a webshop :D

It was triggered by a posting from mikeq on a another forum, plus the fact that I've been building my own faceted search for which the AJAX way of doing things is more appropriate. Guess I'll wander over to your blog for my daily dosis of blogspotting !

[bcwright]

Tomorrows meeting in Antwerp is supposed to discuss which contributions should be (considered for inclusion) in MS4.

 

I think the general assumption is that you take the most popular contribution and add these, but maybe that is just to much bloat for certain kinds of stores.

 

E.g. Credit class and gift voucher, what if you are setting up a pure wholesale shop, gift vouchers are not really applicable in that case.

<{POST_SNAPBACK}>

I don't know about gift vouchers, but in some product areas it's not at all uncommon for wholesalers to offer some kind of coupon program a few times a year. Still it's not nearly as common as in retail.

 

I would say that the biggest criterion would be how generally useful a contribution was. There are a number of contributions which have great utility in certain limited areas but are completely useless outside those areas - the custom computer contribution being one example. The ones I'd give the highest preference would be the ones that fill in the most obvious gaps in the software - even if they're easy to install.

 

For examples, the basic software doesn't allow changing the product or attribute sort order, but does allow changing the category and language sort order - to someone new to osCommerce this just seems silly and arbitrary. Likewise with enabling/disabling categories and attributes - this is allowed for products but not anything else; it should at least be allowed for categories. (The latter can be useful for example for seasonal items or items that aren't always available, where you don't want to have to delete the entire category at the end of the season to prevent it from showing up - you anticipate that you'll just be re-creating that category next year). Those are just a couple examples where the existing choices of what's included seem arbitrary - if it's allowed one place, why isn't it allowed in this other similar place?

 

There are lots of useful contributions - the category heading/description contribution, for example, and EasyPopulate - that probably ought to be included because they add functionality that would be widely useful without adding a lot of overhead, even though they're pretty easy to install afterwards.

 

One thing to consider is that while a number of these contributions are pretty easy to install by themselves, once you have several installed it can get harder to install more because you may not be able to follow the install directions to the letter for your modified cart. I don't think this is likely to become a serious issue for me personally - I've done a lot of programming and web development so even if it requires major changes to a contribution to get it to work in my environment I expect I'd be able to do it. But it does raise the bar for those with less experience.

 

Even out of the box osCommerce is pretty far from a "basic cart" - it's really pretty close to a full shop. I wouldn't try to put every possible layout and theme contribution into the basic distribution but I do think it would be a good idea to include the contributions that fill in obvious gaps (some of the biggest I've listed above) even if they're relatively easy to install - it makes life easier for everyone but especially for those with less software development experience.

 

Bruce

[burt]

Probably a good criteria would be whether osCommerce (ie, the "Team") is willing to take on support issues for the added Contributions...

 

Combining Contribs; urgh! I didn't think of that.

[♥bruyndoncx]

wouldn't the support then fall under 'general support' - not sure who is mostly fielding those requests ... imo it is just like any other support provided on the forum.

 

or looking at it from the opposite angle,

maybe some contribution developer would rather have their contribution included in the core shop, no longer feeling obliged to having to support their contribution in the support thread, but also forego any potential income from the implicit advertising in the contribution area

[bcwright]

Combining Contribs;  urgh!  I didn't think of that.

<{POST_SNAPBACK}>

Yes - one example would be the category headings/descriptions contribution and the enable/disable categories contribution. The first one replaces the "edit category" function with a separate page - so if you want to be able to enable and disable categories from the GUI then you need to add that capability to the "edit category" page. Not a big deal, I've done it for my shop without a lot of trouble ... but daunting if you're not a software developer.

 

That's why I think that there should be preference for that type of "core functions" that might have some interactions with each other but which don't add too much overhead.

 

Bruce

[dreamscape]

Unless you want to combine contributions ...

Like the way attribute sorter is repackaged with different other contributions. Or in the future that might just mean that the design hasn't been made modular enough.

<{POST_SNAPBACK}>

 

If the code was written that it could be extended through "plugins" or "modules" (call them what you want, they are the same thing for what we're talking about), i.e, had a number of places to hook into for extending the program without modifying core code... And if the plugin system was also designed so that one plugin can communicate with other plugins, this would be pretty much a non-issue... though the contributor would need to code in general hooks so that other plugins can communicate with his plugin if they wanted to, and if it was something special, both contributors would likely need to collaborate with each other on working out how they are going to hook into each other, but the point is, if the basic functionality for a plugin system is there, it can be done. However, osCommerce is most likely pretty far from this scenario... You can't exactly drop in a plugin API for the entire application overnight.

 

As for the original question, off the top of my head, all I can think of is, "Is the coding well formed, and does it adhere (at least closely) to the osCommerce coding standards?" Maybe I didn't work it correct or ask the right things, but the basic gist of this question is "Is the code written in a way that it can easily be integrated to the core, or are we better off writing something of our own that performs the same function?"

 

This might seem a bit odd of a question, and alot of people say why reinvent the wheel... well the truth is there are alot of different types of wheels, and when you need one, you don't just go picking one up from anywhere... it might not fit, and might not be the right type or size... you might be better off making your own wheel.

 

I hope I don't get flamed for this, but take for example the gift voucher contribution. It is a great idea, and something alot of online stores use, but at the same time, if you look at the code, the contribution is a steaming pile of ****. No offense meant to whoever wrote it, but there are several things about it that don't make alot of sense, and IMO, the coding in several places is just a hack job, and not well formed. To add it to the code base would be a huge mistake, IMO. The dev team would be much better off writing their own from the ground up if they wish to add this feature.

[bcwright]

Another thought. The kinds of overhead that would most concern me would be speed and complexity, rather than space. If a few files sit around on the disk in my shop unused, it's not a big deal. (osCommerce is small enough that most shops won't have a problem with the size of the cart's files overflowing their disk size or quota - more likely if that's a problem it will be because of product images and database size rather than code size).

 

Speed is obvious - you want the response time on an OLTP system to be quick, and if you're on a shared server you don't want to hog all the resources which might mean you get kicked off.

 

Complexity would relate to how difficult it would be to install contributions or fix bugs in the code. Ideally you'd like to do both without a lot of trouble. A plugin system for contributions would be a great step in that direction but I'm afraid that for a lot of contributions it would be hard to do. Languages, payment and shipping modules, and infoboxes being the only ones that I can think of offhand where that would be easy to do and for some of those it's pretty much there already in MS2. A lot of the contributions involve database modifications and that's hard to provide safely in a pure plugin architecture.

 

Bruce

[Guest]

My impression is that after certain contributions are incorporated to become MS4, that they'd become an official part of the code, no longer "contributions" but part of core MS4. Community updates to those areas of code would still be contributions, just as they are now.

 

Maybe I'm reaching a bit, but that's how I understood it.

 

-jared

[bcwright]

My impression is that after certain contributions are incorporated to become MS4, that they'd become an official part of the code, no longer "contributions" but part of core MS4.

<{POST_SNAPBACK}>

My understanding as well, I thought the reason the thread started was to think about what kind of contributions might be worth integrating into MS4 to become part of the core.

 

The plugin idea could reduce the demand for contributions to be integrated with the core, I'm just not sure how easy or possible that would be for some types of contributions.

 

Bruce

[dreamscape]

The plugin idea could reduce the demand for contributions to be integrated with the core, I'm just not sure how easy or possible that would be for some types of contributions.

<{POST_SNAPBACK}>

 

I'm not exactly sure but I think the idea behind that was then even certain "core" components could be written and distributed as plugins (either with or separate from the "core" distribution), in addition to having an API for developers to hook components into. If designed and modeled with an emphasis on forward thinking, it would be possible for nearly any type of contribution, but osCommerce is a long ways from that type of architecture.

 

One thing the team might want to do for any contribution being considered for integration, is to look at the support forum and weigh the number of known issues it has and how easy it would be to fix them vs. a new solution to accomplish the same feature (if it is desired enough).

 

Another might be "how easy is it to use for an average user?" For example, my dynamic mopics, I and some others find extremely useful and easy to use, while others find it incredibly hard to understand and grasp the concept; so it would not be an ideal candidate.

 

I think some of the questions you have are ok, but it seems to be a little "developer oriented" heavy on the questions to ask... when considering what features to add to software, you need to step out of your developer's cubicle and walk down the hall and talk to or think like the end user might. Then when you have a list, you can go back in your cubicle and figure out how to best implement them. Think like a customer, but code like a developer ;)

[dreamscape]

As a followup to my last sentence, "Think like a customer, but code like a developer" it might not make sense. What I means is think like a customer in terms of what the program should do, but code like a developer in terms of how it should do it.

 

A better approach to the whole situation might be that instead of considering "contributions" the team should consider "features" from the perspective of customers, i.e, from the viewpoint of shop owners, businesses, business executives, etc... This might also include some market research or a survey to the community on what features they would like to see.

 

Then, when there is a list of the top or most necessary features, the team can switch and begin thinking like a developer, i.e, what is the best way to incorporate these features... and here is where contributions might come into play, because some viable questions to ask might be, is there an existing contribution that works well that we can incorporate?, is there one we can use to get a running start?, are we better off developing a wholly internal solution?, is this feature even viable at this stage in the development path?

 

This may not be what you're looking for, and is just a simple example, but in my own opinion, considering features to be added is a much better approach than strictly considering what contributions should be added. Then when you have a feature set, you can consider if there are any contributions that fit the bill.

[devosc]

dreamscape, hit the same notion I had earlier when reading through this thread in regard to featues in difference to contributions...

 

I've mentioned my thoughts elsewhere re concepts so no point here again, for whatever that was worth back then...

 

However I would mention something, that might have some bearing in towards future thinking... an imagemanager, an uploadmanager... if these were available as isolated features, then for example in the products description, the only thing that needs to be specifed and thus handled by the products.php script is the image path to be directly inserted into the corresponding products table etc... What trying to say is, for example, without an ImageManager (which would implicitly handle the actual image upload), the back end scripts then require additional scripts to handle the uploads of the images, thus adding in additional scripting requirements for that script etc...

[♥bruyndoncx]

A better approach to the whole situation might be that instead of considering "contributions" the team should consider "features" from the perspective of customers, i.e, from the viewpoint of shop owners, businesses, business executives, etc... This might also include some market research or a survey to the community on what features they would like to see.

I agree, that's why I had those last lines about Ajax.

But I think the original assumption from the team was that the most 'needed' features in osCommerce would have been developed as a contribution. That might not be 100% true, but it is probably true for the majority of features.

I also agree that MS4 won't incorporate an exact copy of the contribution, but more like reverse engineered and then fitted into MS4 to provide the same (or better) functionality.

 

jcall

After MS4, regular updates/patches will be provided, so bug fixes that you know find in the contribution area, should be part of a patch release.