Fist impressions of OurGroceries, Grocery IQ, and ToMarket

In many ways, smartphones and tablets are struggling to meet their potential.  In my opinion, nowhere is this more evident than in the grocery shopping application.

(Note I used to use ToMarket, then stopped using it because it was not handy any more.)

---

Everyone thinks of shopping apps as a 'simple' application.  It is anything but simple.  It is, in fact, quite a problem in information management.

The ideal shopping app would theoretically have all of the features below:

-  Very quick app setup
-  Enter large amounts of information quickly
-  Create lists quickly, including remembering recurring/favorite items
-  Track items by category, store, and location
-  Determine total cost from a given list
-  Guide you through the store quickly and efficiently
-  Track coupons, discounts, and sales
-  Sync shopping lists across multiple devices
-  Add ingredients from recipies instantly

To accomplish this, you need a comprehensive database that tracks and relates a list of items to buy against a list of stores.  To create this database, you need a way to create that database as quickly and painlessly as possible, implying a web/PC interface of some sort.

None of the apps currently on tap appear to have both of these features together.  And that is a crying shame.

---

Before going further, I will note that apps often attempt to address the various issues as follows:

- Addressing the  items/stores/locations conundrum by using "Categories" rather than aisles.  For example, rather than listing an item in Aisle 5, it will be listed in "Breakfast & Cereal". 

Obviously these categories are not going to relate to the physical store layout at all.  This is useful only if you know where these sections are in the store and and willing to keep track of where you are so that you don't pass a section by.  So this defeats the purpose, since items are not actually tagged by location.

-  Adding items by barcode or voice recognition.  Voice is obviously sketchy at the best of times.  Barcode appears cool, but standing there pulling items out of the fridge one-by-one to be scanned is actually more work, plus it is brand-specific.  I want "Instant coffee", and not "Maxwell House Extra-Special Blend Fair Trade Instant Coffee 592g Vacuum Sealed Can".

-  Importing Handyshopper lists.  Useful only if you have such a database and it has not been obsoleted by in-store changes.  Given that HandyShopper is many years old now, I'd hazard a guess that either new stores have opened and/or many old stores have reorganized by now, making this option of limited value.

--- 

Most people will solve the information-entry problem by making their list a work in progress - adding items over time.

Note that the WORK part of this is the problem.

Like the smart fridge of the 1960s, grocery apps expect us - in addition to entering necessary information like our shopping list - to slave away in creating, maintaining, and organizing the comprehensive shopping and database necessary for the app to run.  This is the fallacy of automation at its worst, where the apps start to demand more time and effort than they save.

If you were to use every feature on these apps, you would theoretically need to add the following information for every item:

 - Category
 - Aisle (for every store)
 - Price (for every store)
-  Package type (for every store)
 - Sale status (for every store)
 - Coupons (for every store)
 - Tax exemption status
 - Favorites status

This is in addition to the bare minimum name and quantity you would obviously need, for any list, including a paper one.

This information generally needs to be entered by HAND, on the target device in question - meaning your tablet or smartphone.  Which is stupid in the extreme, given that neither platform is well suited to bulk data entry.

As discussed above, barcode and voice entry do not solve this - not even for ongoing maintenance purposes - and slowly building a list is, well, slow.  A web interface or direct database entry are the only available solutions for quickly building even an initial database right now.

Sure, once the database is all set up, it is handy and workable - to an extent.  Once will argue that having to start up the app and keep it open throughout the shopping trip is a burden, but that's a necessary evil.  Support for favorites / frequently used items help too.

But what happens when your grocery store re-organizes?  Both my primary grocery stores underwent complete re-orgs in the past two years, and everything but everything was moved. 

This is one of the reasons I dropped ToMarket - re-doing the entire database was not worth it for the 5-10 items I shop for daily, and the 30 items I shop for occasionally.  It was not worth the effort - I would have spent more time than I would have saved.

Now, once can easily argue that by-store by-aisle specific information should NOT be entered into these apps for this very reason.  I personally have spent far too much time wandering the aisles looking for an item to buy into this.

Besides, if the feature is there you don't need to use it if you don't want to.  I personally want to, and apps that don't have the feature don't give you the option, which they should.

---

Now, if there ever was a gold standard for shopping apps, it was HandyShopper.  Handyshopper had nearly all of this sussed out back in the PalmOS days.  I know, since I used it.  But even HandyShopper did not have it all.

What it did have was the ability to manage items and stores independently.  You could enter "Paper towels", and list it as being at Canadian Tire (aisle 3), Co-Op (Aisle 7), Dollarama (Aisle 1) and Superstore (Aisle 25). 

To my mind, this feature is KEY - items MUST be handled independently from stores.  The benefits are obvious and meaningful.

What Handshopper lacked was a way to get information entered quickly.  You either needed to add items one at a time (manually) or directly edit a .csv file for the database.  Both had dis/advantages, and neither was optimal. 

Of course, back in those days, sync and web interfaces were not readily available as they are now.  So it was as good as it got, for the times.

And good it was - in fact, forums are packed with people seeking Handyshopper replacements, comparing new apps to Handyshopper, and looking for ways to re-use Handyshopper data.  At some point, any new app will be compared to Handyshopper.

---

So how do modern apps stack up?

First up, OurGroceries.  OurGroceries is a good looking app that handles multiple lists, recipies, and such.  A web interface lets you add items relatively quickly and in bulk, and it is free (ad supported, unless you upgrade).  And - best of all - OurGroceries does seamless and fast web syncing across devices. 

OurGroceries has a deceptively simple website interface that makes you think it is pretty stupid.  It isn't.  It's almost Apple-esque in being very functional without adding work or clutter.

For example, the website has a fairly good list of default items preloaded for you.  They are generic - not brand-specific - and can easily be added to any of your lists in bulk.

The app will also remember your categories or aisle names, which can be added to multiple stores.  You won't see this until you try it, but it is there.

It remembers your items as well and allows you to add items to a new store by picking from the list, which is very quick.  You can also import item names from a file or by entering them in bulk by hand.  These are great features to have and makes initial setup relatively quick.

For sync, all you need is an email address.  You can use any address you want.  You enter it on the website and on each device, and you are done. 

Syncing appeared fast enough so that two people could tag-team in a store without duplicating items.  Pretty cool.

Where OurGroceries falls down is stores.  It does not handle multiple stores - to do multiple stores, you need to do multiple lists.  Adding an item to one store does not add it to another.

This is bad, bad, bad.  Everyone has multiple options available for buying things.  If I need milk, it should not matter if I decide to buy it at one store or another, and a shopping app should reflect this.

But OurGroceries forces me to either add the item to multiple lists (more work, confusion) forces me to go to a particular store (unhelpful) or lacks all guidance information while I'm in an alternative store (unhelpful).

So, great website / interface and great sync.  No store support.

---

Next, GroceryIQ.  Without going into details - this is already much longer than I expected - it has just about the same feature set as OurGroceries.  And no store support.

Grocery IQ mitigates the issue - slightly - by adding an "any store" option.  So you can add any given item to all shopping lists at the same time, which is a help.  But this doesn't include per-store aisle or pricing support.  Also, as adding milk and eggs to the Home Depot list doesn't make any sense, I don't see how this feature is terribly useful.

Again, you can use categories instead of aisles, but this is not optimal.  It is workable for many, but not optimal.


Grocery IQ also has an annoying feature that attempts to match your items with name-brand items.  On the web site, entering "2% milk" and hitting Enter will get you Similac Step 2 Baby Formula or something, which is obviously not what I wanted.

Grocery IQ is run by Coupons.com, so obviously they want you to be brand-specific. But most people will not care which brand of tomatoes, dish detergent or trash bags they buy, so this is rather stupid.  Also, multiple stores rarely carry identical brands across all items. 

You can override the matching feature, but you need to do it for every item as you enter it.  To my mind this just gets in the way and significantly detracts from the utility of the site.

Store and house brands also don't show up, and you can probably forget about relevant brands being included if you live outside of the United States.

---

Last is ToMarket.  ToMarket is the only app in this list to handle multiple stores and items on a per-store basis.  It is also the only one not to have a web interface and it does not offer sync. 

Barcode and voice are possible, I think, but neither is optimal.  There is a reason why every PC still has a full-size keyboard on it.  Until true natural-language processing engines come along, typing will always be faster than any other method for entering unstructured data.

Direct edit of the ToMarket database is possible.  It is obviously not for everyone, but the dedicated could theoretically construct a good initial database in short order.

---

I heard about rShopping list, but it does not offer a web interface or direct database edit, as far as I know.  There is also no sync, as far as I know.  So it wasn't worth pursuing.

--- 

So, there you are - none of the offerings have both key features of multiple store support and a useful web interface, both of which should be key items for any such app.

Sync is cool and could be a killer feature for many families.  I know we could use it, though it is not essential.  But even those people who prioritize sync over multiple stores seem to feel the pain.


I first expected I would have to use ToMarket simply because the ability to have multiple stores is more important than a web interface, multiple device sync, or peripheral items like recipie handling.  But I wish I didn't have to give up these features.

To my mind, ToMarket would be close to ideal if they just added a web interface.  Sync would naturally follow, which would be awesome, but just being able to enter stuff on my PC in natural language would be tremendously helpful.

Now, I can go ahead and manually edit the ToMarket database.  Again, it is just a pill.  But it is, arguably, the most efficient way to get all the relevant information into one of these programs.

On further thought, however, I expect I may just use OurGroceries.  This is because I handle my two primary stores (Co-Op and Superstore0 very differently.

Superstore is the problem.  It's cheaper, but it is huge, crowded, and difficult to navigate.  I do not know where stuff is, because I avoid the store whenever possible, but for larger buys I should really go there.  My wife pretty much refuses to shop anywhere but Superstore, and having the ability to sync for that single store would potentially be of benefit as well.

I am unlikely to use the app for routine trips to the local Co-Op.  If I do, I know where stuff is in Co-Op anyway, the store is relatively small, and rarely pick up more than five items, so through-the-store guidance is not so critical.  I don't even mind having a separate list for Co-Op since it should always be very short.

Plus, I really, really want the website interface.  It seems so much simpler than entering by database or by hand or by any other available method.  And I really need it for bulk buys, where I have to enter tons of stuff.  Camping comes to mind, in which case the recipes function of OurGroceries will definitely be handy.

I know it won't support stores exceeding these two very well, so I'll need to have an "Other Store" category for everything else.  Not NEARLY as nice as having proper stores for Dollarama, Canadian Tire, Home Depot, etc.  So maybe I'll just keep using my paper notebook for those stores, for now.

--- 

Finally, I'm going to talk about the issue of store setup.  Specifically, the location of items in specific stores. 

(This goes to pricing and other things too, but sorting lists by aisles is supposed to be the killer feature of these apps.  Price info is optional, but location info is not.)

There are millions of stores.  For the shopping app to be relevant and useful, it is necessary to define the locations of items in each relevant store.  There is no way to do this right now aside from entering the store location information per item, per store. 

This is an amazingly tedious thing that web reviewers gloss over all the time, implying that such "setup" is a quick process.  Go to any Superstore, Costco or Supercenter and you will find it is anything but, with 1,000s of items stocked per aisle.


I should think that ideally, the apps would crowdsource such things.  I don't know why they couldn't.

Certainly there is a possibility that no other app user will go to the Co-Op that I shop at daily, but hell - if there were, it's no skin off my nose to let them know that paper plates are in aisle 5.  On the other hand, someone else probably shops at the Superstore, and it would be a tremendous help for me to know that parchment paper is in aisle 27, left, near the back.

This is not hard.  Matching a store by name and address (or just zip/postal code) would be easy, as would be storing the lists. 

There would be no user effort required, either - as soon as an item is entered or edited, it could be synced to the store list automatically.  And stores will get 1,000s of unique shoppers weekly - far more than many restaurants can handle - so building up such a database should be pretty easy.

Name variation would be an issue.  For example, the list might include "Aluminum foil", "Tinfoil", "Tin Foil" and "Foil, Aluminum", all referring to the identical item.  Same for location variations, where the dairy section might be Aisle 4, 5, or 6, depending on your point of view.

This could be solved, to an extent, by having a decent set of pre-defined item names.  For the rest - well, it is just storage, and the search feature of the apps will aid people in locating pre-existing item names.  If it made an app $1 more, I think people would go for it.

Hell, the app developers might even be able to convince some major chains to create and upload their own store directories.  The stores know where everything is anyway - possibly not in a simple format, but it would obviously be possible to make a fairly comprehensive store database, complete with pricing and up-to-date location information for most items. 

IKEA and Canadian Tire do this anyway, for their own websites, apps, and internal store "product finders", so why would it be hard to upload the same information to OurGroceries?


Anyway, these seem like obvious things, especially the crowdsourcing.  But nobody supports it yet.  Hopefully in the future.

Because, without building up such data, the onus will always be on the app user to do the up-front work.  And that just isn't right.

"Installation failed" - cannot install HP 2600n to print over network

This is the usual story - printer works fine, laptop works fine, printer works from elsewhere in the network, blah blah blah.  The HP is hooked directly to the network without a print server PC attached to it.

The "Full" Hewlett-Packard installation package consistently refused to install the printer.  Which was strange, since it had been installed before!  And worked before!

Symptoms were that you would run the install, and after a few seconds of "Adding Network Port", it would say "Installation failed", and give you some bullshit instructions for fixing the issue.

Running the installation package from local drives vs. network drives made no difference.  Uninstalling and reinstalling the HP software made no difference.

I suspected that Windows 7 x64 was having trouble adding the virtual TCP/IP port.  I did some research and found a registry hack that purported to solve the issue.  I removed 5 port, four of which were "_1", "_2", etc. and were redundant.  This did not help.

Here is what finally worked for me. 

Notes:
-  You need to know the IP address of the HP printer you are trying to install.  If you can't find that out from another PC or a router status page, I think you can print out a physical configuration page from the HP front panel somehow.  I don't know how to do that and some models might not support it, I suppose.

-  This worked after multiple attempts to install via the HP program, so I do not know if that is a necessary first step in order to get the right driver on your PC or not.


1.  Go to Devices and Printers in Control Panel, and click "Add a printer".

2.  Select "Add a local printer".  Don't use network printer!

3.  Click "Use an existing port".  Scroll down until you find the TCP/IP port that has the same IP address as the printer.

Notes:
-  If you have more than one port with a matching address - probably with tags like _1, _2, etc. - just ignore them and use the first one that has no suffix tag.

-  If you can't find it, go to "Create a new port", "Advanced TCP/IP port Monitor" and follow the prompts.  Enter the IP address of the target printer.

-  If your PC doesn't have "Advanced TCP/IP Port Monitor", then I guess you can use a standard TCP/IP port.  I don't know as I did not have that issue.

4.  Find the HP 2600n driver in the list that pops up.

After that, hopefully the HP will install itself with next to no fuss in just a few seconds. 

Again, if you don't actually have the HP 2600n driver installed, you might have to go through the extra work of finding and installing the driver via Windows Update or by manual installation via "disk".  I did not have those issues; you can Google to figure these steps out.

To delete the unwanted / unused / unnecessary TCP/IP ports - the ones with _1, _2 tags - here's what to do:

A.  Go to the HP 2600n in the "Devices and Printers" panel of Control Panel. 

B.  Right-click and select "Printer properties".  Note this is not the same as "Properties" at the bottom.  This can be on the 2600n or (I think) on any other printer as well.

C.  Select the "Ports" tab.

D.  Select the unwanted / unused / unnecessary TCP/IP ports one at a time, and press "Delete port".

If you mess up, you can always re-create the port again and assign it to the existing HP 2600n printer that has already been installed.  So this seems low risk.


Now, on my system, the registry hack noted above showed 5 TCP/IP ports on the same address. 

Using the method described in A-D, above, the list showed 10 TCP/IP ports on the same address - including the 5 ports that I thought I had deleted!!!  WTF!?!?

So obviously the registry hack did absolutely nothing, and those ten ports - or, at least 5, of the 10 - were living someplace else on the machine.  The hack did not find them all and did not delete them as intended.  The "Printer properties" method found them all and appeared to work.

Now, you're unlikely to have issues with the "extra" ports once you've got your 2600n working again.  But you never know - the same issue could pop up again if you ever need to reinstall again.  So I recommend deleting what you do not use.