Comments on: A little advice for Miva Merchant module developers http://www.mc2design.com/blog/a-little-advice-for-miva-merchand-module-developers Web development and marketing from the squares at MC² Design Group Thu, 21 Aug 2008 21:59:51 +0000 http://wordpress.org/?v=2.6.1 By: Luke Visinoni http://www.mc2design.com/blog/a-little-advice-for-miva-merchand-module-developers#comment-467 Luke Visinoni Fri, 03 Aug 2007 16:19:59 +0000 http://www.mc2design.com/blog/a-little-advice-for-miva-merchand-module-developers#comment-467 You make some very good points, Susan. The bit about self-closing xhtml tags further exemplifies my point about the inflexibility of module developers providing their own html. As for the upgrade your modules argument, there are always things on the developer end that are not immediately apparent to the end-user. I guess I should have qualified the whole article with the statement, "I am not a Miva module developer, so please do not take any of the things I say as law". I realize that some of the things I mentioned are like they are for very good reason, but that doesn't mean I can't complain about them. ;) Thank you for your perspective Susan. You make some very good points, Susan. The bit about self-closing xhtml tags further exemplifies my point about the inflexibility of module developers providing their own html.

As for the upgrade your modules argument, there are always things on the developer end that are not immediately apparent to the end-user. I guess I should have qualified the whole article with the statement, “I am not a Miva module developer, so please do not take any of the things I say as law”. I realize that some of the things I mentioned are like they are for very good reason, but that doesn’t mean I can’t complain about them. ;)

Thank you for your perspective Susan.

]]> By: Susan Petracco http://www.mc2design.com/blog/a-little-advice-for-miva-merchand-module-developers#comment-466 Susan Petracco Fri, 03 Aug 2007 16:04:56 +0000 http://www.mc2design.com/blog/a-little-advice-for-miva-merchand-module-developers#comment-466 Luke, I have a few thoughts on this as well. First of all, I completely agree with the forced HTML issue. Even if the module's code is well-written, however, there's no way for the developer to know if you want to use HTML4 tags, or XHTML tags (self-closed at the end via "/>", for example). Therefore modules should either provide the ability to template the code internally, or offer tokens that allow the HTML to be written around the tokens. Yes, the interface on some modules is complete hell. I think some developers are brilliant coders, but don't understand usability. But software has always suffered from the conflict between being robust, or being easy. For example, the "advanced" shipping modules from Viking Coders are extremely robust, but the sheer number of options makes the admin interface unwieldy at times. It's a classic tradeoff, and not one unique to MIVA modules. I do want to disagree with you about upgrades to MM5 however. Do you have a background in this? Just curious. In my experience, however, it's not an easy shift to upgrade modules. The database access is quite different, unless you are going to force the user to have DBF files for the module, even if they use MySQL instead of the "mivasql" DBF format. The API is completely different. And of course, the templating engine is new. OpenUI is gone. It's not as simple as it sounds. Also keep in mind that most development firms - whether a one-man shop or a larger agency - has to prioritize their development efforts. A port to MIVA 5, which wasn't adopted as quickly as the community had hoped, may not be as high a priority as other development efforts. For our company, since we're both module developers and system integrators, we've prioritized ports to MM5 below our clients' needs, and below another larger project that's been in development for awhile. Sometimes it's a matter of covering the right bases from a business perspective. --Susan Luke, I have a few thoughts on this as well. First of all, I completely agree with the forced HTML issue. Even if the module’s code is well-written, however, there’s no way for the developer to know if you want to use HTML4 tags, or XHTML tags (self-closed at the end via “/>”, for example). Therefore modules should either provide the ability to template the code internally, or offer tokens that allow the HTML to be written around the tokens.

Yes, the interface on some modules is complete hell. I think some developers are brilliant coders, but don’t understand usability. But software has always suffered from the conflict between being robust, or being easy. For example, the “advanced” shipping modules from Viking Coders are extremely robust, but the sheer number of options makes the admin interface unwieldy at times. It’s a classic tradeoff, and not one unique to MIVA modules.

I do want to disagree with you about upgrades to MM5 however. Do you have a background in this? Just curious. In my experience, however, it’s not an easy shift to upgrade modules. The database access is quite different, unless you are going to force the user to have DBF files for the module, even if they use MySQL instead of the “mivasql” DBF format. The API is completely different. And of course, the templating engine is new. OpenUI is gone. It’s not as simple as it sounds.

Also keep in mind that most development firms - whether a one-man shop or a larger agency - has to prioritize their development efforts. A port to MIVA 5, which wasn’t adopted as quickly as the community had hoped, may not be as high a priority as other development efforts. For our company, since we’re both module developers and system integrators, we’ve prioritized ports to MM5 below our clients’ needs, and below another larger project that’s been in development for awhile. Sometimes it’s a matter of covering the right bases from a business perspective.

–Susan

]]> By: Luke Visinoni http://www.mc2design.com/blog/a-little-advice-for-miva-merchand-module-developers#comment-437 Luke Visinoni Thu, 02 Aug 2007 15:34:21 +0000 http://www.mc2design.com/blog/a-little-advice-for-miva-merchand-module-developers#comment-437 Indeed, that is very frustrating, and a point I certainly missed in my article. Many developers provide minimal documentation, and no insight on how to integrate with a store that has been customized in any way. There are some modules that install so easily (Sebenza for example) that documentation doesn't need to be very verbose. Others require much more involvement from the user, and therefore should contain more documentation. Unfortunately it's generally the former that are well documented (go figure). I must say though, that there are several developers who respond so quickly to inquiries that their sparse documentation can be forgiven (William Weiland of Emporium Plus for example). Indeed, that is very frustrating, and a point I certainly missed in my article. Many developers provide minimal documentation, and no insight on how to integrate with a store that has been customized in any way. There are some modules that install so easily (Sebenza for example) that documentation doesn’t need to be very verbose. Others require much more involvement from the user, and therefore should contain more documentation. Unfortunately it’s generally the former that are well documented (go figure).

I must say though, that there are several developers who respond so quickly to inquiries that their sparse documentation can be forgiven (William Weiland of Emporium Plus for example).

]]> By: Chuck Lasker http://www.mc2design.com/blog/a-little-advice-for-miva-merchand-module-developers#comment-428 Chuck Lasker Thu, 02 Aug 2007 01:37:12 +0000 http://www.mc2design.com/blog/a-little-advice-for-miva-merchand-module-developers#comment-428 Many of your thoughts I understand the developer perspective. What do I not like? The lack of quality documentation, especially with some examples. Some docs have install steps that were accurate during beta MM5, but are no longer accurate. Some just don't have docs. To me, a module isn't ready until there's documentation available. Maybe right at release - minimal docs is okay - but a few months later, docs should be up to date and complete. Many of your thoughts I understand the developer perspective. What do I not like? The lack of quality documentation, especially with some examples. Some docs have install steps that were accurate during beta MM5, but are no longer accurate. Some just don’t have docs. To me, a module isn’t ready until there’s documentation available. Maybe right at release - minimal docs is okay - but a few months later, docs should be up to date and complete.

]]>