A few Documentation Suggestions

I just finished my second full installation of HikaShop for customers and think it would be a good idea to drop a few suggestions on the experience - mostly to suggest where Hika should spend some time beefing up the documentation. I believe it would make a real difference in user experience and might bring to light a lot of powerful advantages Hika brings to the table.

First of all, the experience was very good. As complex software installs go, it went very, very smoothly. Hika's basic install is remarkably easy: one of the primary reasons we run with Hika when given a choice. I have no complaints at all.

Uploading inventory is an extremely powerful tool in running a store, especially when dealing with complex inventory. It's not hard for a programmer to decipher the intricacies of uploading Products that make use of Characteristics by looking at the data being stored, but it's absolutely inscrutable if a customer is trying to understand it through the documentation. Your docs are all about building the inventory by hand, and that is ABSOLUTELY the most inefficient and painful way to do it. For people with large inventories which change quickly, importing is the only way to handle it efficiently.

SUGGESTION: for those that manage inventory through importing, perhaps there could be a carefully safeguarded "purge and reset" capability? I have a manual procedure for this, but a systemic solution would advantageous.

From the documentation, a user would never guess that a product can effortlessly switch descriptions, pictures, prices and many other product values on the fly, just from the selection of a characteristic. You can't even configure some of these capabilities within the current administrative interfaces. At the very least, add complex examples to your overly-simple example. List the fieldnames Importing can utilize, possibly include a sample spreadsheet: It will save most users hours of setup labor.

The developer docs for building custom shipping and payment plugins are fairly good, but they don't explain everything - particularly the relationship between the shipping plugins and the "shipping modes" field within the payment plugins. Without a single forum message, I would never have know to deselect ALL "shipping modes" within the payment plugin's list to be certain that all the options provided by would remain available. (I still don't understand why the UPS plugin provides one list of shipping options to the payment plugin and a different, largely incompatible list of options to the User during checkout.) It would also be good to mention in the docs that most new UPS developer accounts are pointed at a test environment and must be transferred to their live servers by request: my customers already had their own UPS account and set up an associated developer account under their name, but they aren't developers and did not understand or relay all the details UPS provided to them. I only knew which required field values I needed to activate the UPS plugin. Many users would benefit greatly from longer discussion of both the UPS plugin (as well as how all shipping plugins work behind the scenes) than the one page bullet list you provide (though that list IS very helpful).

There's also tons of ways to customize the appearance of the store, both through the interfaces you provide, and through more traditional Joomla means, like User Templates and CSS.

There are dozens of other facts and tricks I learned in this install that I found ONLY after hours of scouring the forums - things that really should be included in the formal documentation, not only for completeness, but because they unlock strengths in the software that could genuinely attract more users. And I strongly recommend that Importing and inventory management gets it own manual.

Thanks for putting together such a strong, versatile product. I'm really enjoying it.
We're still waiting on a little more photography, but the new store can be found at heggysnutshop.com

I will add on that a Hikashop Glossary would be helpful. The terms used for different Hikashop features do not seem as apt and precise as they could be and as a result a user's mental model of how the software should behave is mislead by the choice of words.

In the US, people have come to understand the terminology used by the automotive industry and if terms are used consistent with this, there is instant understanding. Hikashop's terms are not consistent with this and that is why some overview explanation would be helpful to prevent users from expect the software to work differently than it does.

Some examples:

All products have attributes that describe features. Intuition would suggest that the list of attributes should be loaded as Hikashop Characteristics, but this causes variants to be improperly constructed when in fact what is being described are non-changing features of the base product to compare it with other products. It is not expected that a Custom Field must be used for storing the basic attributes of a product that are not already found within the product file, to use in descriptions and comparisons. The name 'Characteristics' misleads people to load a product's attributes (the wattage of a light bulb) using the Characteristics feature and to load the choice of options (like shirt size and color) using the Options feature instead of the Characteristics feature.

When buying a car, you have Options - The Luxury edition or the Sport edition. 5 speed manual or automatic transmission. They are called options because the user has a choice and can select one of the provided options, not because they are "optional" as in you can't choose "none" for transmission. When buying that car you can also get some optional accessories as add-ons, like air conditioning or a towing package. So users come to expect that making the choice of color or size when buying a T-shirt should be loaded as Hikashop "Options" instead of Characteristics. It is not intuitive that Add-Ons or Accessories should be loaded as Hikashop "Options" as opposed to separate but related products.

The choice of words for "Catalog Mode" is equally troublesome because that has so many different meanings. It took a long time to figure out that whoever named it had in mind to emulate a paper or PDF catalog that isn't clickable. My first impression is that catalog mode is what Hikashop calls a Product Listing and Joomla calls a Category View. Without a tooltip to explain it, better would be to name it by what it does, as in "Hide the Add-To-Cart button Mode".

Semantics is an incredibly important aspect to reducing the amount of user support requests on the forums and out-of-the-box user satisfaction. I would love to see a process flowchart for the workflow. Also, tooltips added to the configuration screens to explain the impact of each setting right there, in context.

I am very impressed with the detailed work that has been done. A bit of time spent on helping users get acclimated to the software with some goal-oriented examples (Our boss/client wants a page that displays ..., to set it up we ...) will make adoption that much easier and support much less of a time consuming burden.

Boy, am I ever glad I found this post! Duke3D and MonkeyT: Thank you for taking the time to write your posts ...many of my rookie questions have been answered just by your suggestions, interpretations and things you found out the hard way. I'll be bookmarking this one for sure.