I would just like to take a moment to point out a few of the things that drive me insane about Miva Merchant modules. If you are a Miva developer, please take note.
Let me write my own HTML
It’s bad enough the Miva Merchant itself doesn’t allow me 100% control over my HTML without module developers doing the same thing to me. Miva and its third party module developers have proven time and time again that they are completely incapable of writing HTML from this decade. I am thoroughly sick of seeing tag soup like the following when I render a Miva module component.
<BR><TABLE border=0 cellspacing=0 cellpadding=0 nowrap> <TR> <FORM METHOD=POST ACTION="http://www.example.com/shop" name="ch"> <input type="hidden" name="Screen" value="OINF"> <input type="hidden" name="Store_Code" value="EX"> <TD> <INPUT CLASS="ch_text" TYPE="submit" value="Checkout"> </TD> </FORM> </TR> </TABLE> <BR><BR> <TABLE border=0 cellspacing=0 cellpadding=0> <TR> <FORM METHOD=POST ACTION="http://www.example.com/shop" name="cs"> <input type="hidden" name="Screen" value="PROD"> <input type="hidden" name="Store_Code" value="EX"> <input type="hidden" name="Product_Code" value="1501T"> <input type="hidden" name="Category_Code" value="women"> <input type="hidden" name="Search" value=""> <input type="hidden" name="Offset" value="0"> <TD> <INPUT CLASS="cs_text" TYPE="submit" value="Continue Shopping"> </TD> </FORM> </TR> </TABLE>
Not only does code like this make it impossible for me to have a w3c-compliant website, it also limits me in many ways. What if I don’t want to post to the page you have so boldly assumed I wanted to post to? Now I have to get another third party module just to fix the mess you made for me. What if I don’t want some of the input elements you have forced me to use? In this case, I’m just plain screwed. If your module needs to render HTML code, let the developer have access to this code.
When developing modules for version 5 or higher, use the template system that is already in place
Don’t provide me with some archaic, proprietary “token” system. There is a half-way decent template system in place in Merchant version 5 (or higher) for you to use, so why reinvent the wheel with your own, less flexible system? I realize that some of this is just left over from version 4 modules, but if you’re going to develop modules, there’s no reason you can’t update the template system, which brings me to my next point.
Update your modules!!
There are so many module developers out there who create a module and never address it again. There are several modules that were created for version 4 of Merchant that still (it’s been about 2 years) have not made the port to version 5 (attribute upload anyone?). Why is this? It can’t be that difficult to update your modules.
Don’t require javascript for your module to work properly
There is absolutely no reason for you to require that javascript be enabled for me to use your backend module. Now, I can understand the requirement of javascript in the case of something built for the front end, but even in this case, the javascript should be loosely coupled enough that it isn’t really required. Take for instance the thickbox component we use on several of our ecommerce sites. If javascript is enabled, it allows for a very nice modal-like experience when you want to see an enlarged photo of a product, otherwise, it just takes you to the larger image via http (view in browser).
Gee, your module is very useful, but the interface looks like hell
This is the most common thing I see in not only modules, but Merchant itself. Merchant’s backend is hideous, and to go along with it, so are just about all module interfaces. Is it a requirement to create ugly interfaces in the Miva community?
Well, that’s my list. What irritates you most about Miva modules?
Chuck Lasker Says:
August 1st, 2007 at 5:37 pm
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.
Luke Visinoni Says:
August 2nd, 2007 at 7:34 am
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).
Susan Petracco Says:
August 3rd, 2007 at 8:04 am
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 Visinoni Says:
August 3rd, 2007 at 8:19 am
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.