We use cookies on this site to remember: your settings, your history, whether you are logged in and to give you a better experience.
More info about cookies
Accept Cookies
Opt Out
You have an excellent choice of browser. Why not add our quick launch app so you can easily manage your shop in the future.Get our free app from the Google Chrome Store.
Login       Register

Product QR Codes

Ok, so what's a QR Code and how can it help you sell more products on your GroovyCart shop?

QR Codes are a handy way of giving smart phone users easy, direct access to a web-site, without the need for the user to manually enter a URL web-address into the browser.

The QR Code is a checkerboard square made up of black and white squares, generally with large squares in three of the corners to help the scanner locate the QR Code.

They can be any colour, although they are generally black, and can be any size.

Example QR Code that goes to our homepage.
Example QR Code that goes to our homepage.

You may have seen them appearing in magazines and shop windows.

On GroovyCart, we have taken this one step further. A shop-owner can print-off labels which contain a picture of a product with a QR Code that contains the URL web-address of that product. In addition, a shop-owner can even print-off a label with a QR Code that just has the URL of the shop home page.

The labels are designed to fit Avery L7165 sticky labels 2x4, however you don't have to use sticky labels.

A customer can simply scan the QR Code using their smart phone, and the product will be displayed on their smart phone browser. They don't have to type the URL web-address, it is done automatically for them. They can even purchase the product using their smart phone. Incidentally, GroovyCart will detect that the device is a smart phone and will display the product so it fits the smaller screen, and is easy to read.

This is another great way to market your products. Here are some ideas on what you do with the printed labels...

  • 1) stick them in a window, so customers can purchase when you're not in,
  • 2) stick them on parcels,
  • 3) use them on business cards,
  • 4) make a printed book of your products,
  • 5) stick them on post-cards,
  • 6) fill a whole space with all your products.

You can find the QR Codes labels functionality under the Marketing button on your GroovyCart Admin-Panel.

If the smart phone doesn't have a QR Code scanner app by default, there are many QR Code scan apps available, including free ones.

There is enough redundancy in the QR code to put your own image in it.
There is enough redundancy in the QR code to put your own image in it.

View/Leave Comments



Extending the Google Shopping Content Model.

Extending the Google Shopping Content Model.

Warning, this article may include technical content, jargon, waffle and fluff.

This article is intended to help other developers that are working with the Google Shopping (or Google Merchant) API.

Once again, if you're a shop owner using us we have already done all this for you, we have only put this article up to try and help others and share our knowledge.

This article will explain how to extend the model to read "warnings". These are returned by Google and generally contain useful suggestions on how to improve a product description to ensure it is found by buyers searching.

To ensure products on GroovyCart get both a high ranking and appear on Google Shopping, we have a direct feed to Google. This product feed program runs at regularly times during the day and uploads new and changed products to Google using the Google Shopping Content API.

The program is written in Java and is based on the Google sample program (http://code.google.com/.../developers_guide_java.html). The Java program uses a "model" to map API data items to Java variables, thus simplifying the Java application This model is supplied by Google. However, the model is missing some useful items which have been added recently.

http://code.google.com/apis/shopping/content/getting-started/usingapi-products.html#Warnings

This is an example of a warning:

<sc:warnings> <sc:warning> <sc:code>validation/missing_recommended</sc:code> <sc:domain>ProductSearch</sc:domain> <sc:location>brand</sc:location> <sc:message>We recommend including this attribute.</sc:message> </sc:warning> </sc:warnings>

To get Google to return warnings you need to include "warnings" at the end of the URL, e.g. /items/products/schema/batch?warnings

Ok, now let's change the model com.google.api.client.sample.structuredcontent.model

1) As the warnings element is part of the AppControl, we need to edit public class AppControl to include warnings.

@Key("sc:warnings") public Warning warnings;

The @Key is clever, it maps the API XML item "warnings" to the Java data structure "warnings".

2) Next we need to define the data structure warnings in a new file "warning.java".

package com.google.api.client.sample.structuredcontent.model; import com.google.api.client.util.Key; public class Warning{ @Key("sc:warning") public List<WarningDetail> warningdetail; }

3) Finally, to complete the model, create new file "warningdetail.java":

package com.google.api.client.sample.structuredcontent.model; import com.google.api.client.util.Key; public class WarningDetail { @Key("sc:code") public String code; @Key("sc:domain") public String domain; @Key("sc:location") public String location; @Key("sc:message") public String message; /** * Returns a formatted string for displaying the information of the * warning. */ @Override public String toString() { return "Warning: Domain: " + domain + " Code: " + code + " Location: " + location + " Message: " + message; } }

Now let's use the structure in our Java application:

/* Do we have any warnings? */ if (p.appControl.warnings != null) { /* We have warnings. */ haveWarnings = true; /* Google returns a list of warnings - concaternate into a single string. */ if (p.appControl.warnings.warningdetail != null) { for (WarningDetail w : p.appControl.warnings.warningdetail) { /* This will go in the log (full message with all returned fields). */ warningTextLog = warningTextLog + "["+w.code+" "+w.domain+" "+w.location+" "+w.message+"] "; /* This will be displayed to the shop-owner (short friendly message). */ warningText = warningText + w.location+"="+w.message+" "; } } } if (haveWarnings) { /* We have warnings. */ logit(EM,"WARNING, batchID="+p.batchID+" : "+warningTextLog); }

We hope that can help someone!


View/Leave Comments



Development Methodologies - Rapidly Building Useful Websites.

Warning, this article may include technical content, jargon, waffle and fluff.

We have all heard of horror stories of big software developments which are late, overrun budgets or simply don't delivery functionality. Generally, this is down to a long development cycle where requirements are gathered up front way before the software is built, resulting in the final system being "this isn't what I asked for".

So I thought I would take a bit of time to tell you about how we work at GroovyCart.

To avoid these catastrophes, the GroovyCart team have adopted an Agile approach to software development. Broadly, the team adhere to the following:

  • Developments are split into fixed iterations of, generally, 2 weeks.
  • Every iteration has deliverables.
  • The requirements scope fits an iteration.
  • Each iteration goes through the full life-cycle of development, test and deploy.
  • There is a review at the end of the every iteration meaning the client can monitor development.
  • The scope for the next iteration is decided at the end of the previous iteration.
How GroovyCart builds its software in an idea world.
How GroovyCart builds its software in an idea world.

Ok, so what happens in practice? The very first 2 week iteration is about identifying the key deliverables and roughly allocating these to iterations. For the first release of GroovyCart we planned for 6 iterations. At the start of each iteration we would collectively decide what deliverables will be developed. Generally, these deliverables will form the test plan/specification for that iteration. Where a deliverable is more than 2 weeks work then it is split up into smaller deliverables. At the end of the iteration, the development is tested and "driven to live". So at the end of the 2 week iteration there is a working, demonstrable system, which the client can view. We then decided what is going into the next iteration. Ok, so what happens when things go wrong. If a piece of software is taking longer to develop then work on that individual deliverable it is split across iterations, i.e. the iteration is still deployed on the due date. If the client doesn't like the look of a deliverable then the subsequent iteration will address this.

What does this mean for GroovyCart?

Our Agile approach ensures we are develop features on GroovyCart quickly, and be responsive to our shop-owners requirements for new functionality.


View/Leave Comments



Be groovy and share us around:
You might be interested in:
You can also find us on: