Amos Publications Is Completely, Utterly Useless.

I just sent Amos Publications a long nastygram, but I feel like venting publicly... so I will do so.

I have been trying for the better part of a day now, using multiple browsers on multiple computers in two different locations, to reach my purchased Scott eCatalogs... no dice. I log in, I choose the catalog, the Olive reader interface comes up, but nothing ever loads.

There is nothing that [CENSORED] me off more than being unable to access content I have paid for. At least with the old iPad version I could use the materials offline.

Amos needs to get their [CENSORED] together and provide a way for purchasers to use the content without Internet access.

[CENSORED] incompetent fools. These idiots couldn't find their way out of the 1970s with a map, a compass, a guide, and a seeing eye dog.

AUGH!


There. I feel better....

It's hard to believe that in soon-to-be-2016 there are still content/information providers like Amos that are so backwards digitally. It's going to literally kill them if they don't improve their offerings at some point.

The best that can be said is that they are better than Gibbons. Their website is an utter wreck, the search option brings up hundreds of useless results.

Hi

I am going to add my two cents, which is based on observations as a 40 year software/hardware consultant.

In my day, we were taught to "think". Software was fairly well designed and implemented and it worked (some still running today). I taught two semesters of a class that was designed to teach "how to design software". Only a few students liked the class, or thought it was useful, so the school dropped the course.

I have tested quite a bit of software and have found "bugs" galore and poor design. It seems that the old methodologies of design and testing have been flushed down the toilet.

I am not sure if it is just in the United States that students are not learning the "how" of design, testing and implementation. I think the foreign studies are much different. A lot of software I use originates in Australia, Great Britain, France and Germany. It is "user friendly", well thought out and most importantly it works!

So, based on the comments, I am not surprised that it seems very little thought went into "user friendly" eCatalog. For systems I have worked on, one of the first steps was to have a forum with the users to find out what they needed and/or wanted. The system was then designed using this information, with corporate approval of course. Maybe Scott should have asked, in some manner, what the users wanted in an eCatalog.

Just some thoughts from antiquity

Jerry B

At the risk of suggesting alternative perspective…
I understand the frustration of the posters and do not mean to defend poorly designed or implemented software but web developers today face an ever increasing landscape of varying browser capabilities. No longer is it an advantage to write browser based applications which traditionally were thought to be 'write once – run anywhere'. Years ago a developer could simply target a browser based app and then bank that it would run properly on the majority of browsers available in the marketplace. This is no longer true at all.

Currently a developer must not only account for vastly different browsers but also have a solution for greatly varying operating systems and devices. Anyone have a good solution for a screen layout that works well on a modern desktop monitor and a smart phone?

Even testing has become a huge task; not all browsers/OS/devices will display the code in the same way. If you only target the most popular browsers/OS/devices with your testing then you will most certainly miss an issue which will come back and haunt you. So how many browsers/OS/devices combinations would a company like Amos need to support? And how far back (version-wise) do they go in their support?

Frankly, unless you have very deep pockets with a large engineering staff to deal with the massive testing project (or to outsource the testing), you will end up testing for months and months. By the time you finish the testing, several newer browser/OS/devices version will have been released. Talk about a moving target.

And of course these obstacles are also in conjunction with making other difficult usability issues such as whether or not the content is accessible offline. Bottom line is that a browser based app is no longer a simple, inexpensive no brainer piece of development.

I will say that if Amos had not waited for a decade before embracing this digital transition they would now be in a better position to provide a stable decent app. Of course Amos is not the only philatelic entity in this position, groups such as APS are now in the same boat. The legacy approach of charging for information no longer works in the current marketplace and they have shot themselves in the foot by being late to this party. Many groups are now in the position of relying upon the good will of their memberships instead of meeting the actual market demands.

Those groups which did not quickly adapt to the new digital age are now facing the music. They will either have to commit very large amounts of resources to a monstrous effort or close the doors. This is the age where even a company like Playboy is forced to change. Amos should be offering both Linn's and their catalog online without a fee. In my opinion Amos should have began using a business model like You Tube ten years ago; the content delivered with advertising but for a fee a user can access it without the ads. If they could have developed their digital resources over the last decade the requirements for bringing a new browse based app to market would not be as daunting now.
Don

I'm sure it's wishful thinking, but it would be so nice if someone who matters at Amos (or Gibbons or the APS or wherever) frequented this board and saw this thread and others like it.

Reply from Amos customer service this morning:

Unfortunately, the Olive Software program is down at the present time.

Olive Software is working as quickly as possible to get the program restored.

I apologize for the inconvenience.

It's not just the Scott eCatalogs, but Linn's online issues as well.

Hi Studebaker

First off, nice avatar.

I agree with you 100%.

Being late to the party is prevalent (IBM and its PC comes to mind, along with some other machines I remember).

What you say is true but the bottom line is that any sort of instruction in how to design and implement an application is not being taught and everything today seems to be, basically, "seat of the pants" design. I have been in companies where the concept was "let's release it and fix it later".

I do not know how many times I have heard "look at this new concept". Well people, most, not all, of the "new" we were doing in the 60's & 70's. It was just called by a different name.

In reference to browsers, there are not that many out there. Testing for the top 3 or 4 browsers should not be an impossible situation.

Bottom line. I do not think that multiple platforms and programming languages is the reason for poor software. It really boils down to poor basic instruction.

BTW: I am retired and doing VB.NET for my own little projects. I still use flowcharts when something is complicated and I still write "modular" code. Guess one cannot teach an old dog new tricks

Jerry B

Or they may have hired people who worked for startups or publicly traded companies. In that world, the mantra is, "Released is Better Than Perfect." In other words, it's better to have buggy software in the hands of customers now, than to have bug-free software that takes forever to release. Market pressures are the reason: private investors or Wall Street want to see products available, with customer adoption, even if in the long term those customers depart. Only "this quarter" matters.

Good Day Jerry,
Thank you for your thoughtful comments, my avatar was a car I got from the original owner and took to the Studebaker National Meet.

Developing a web app is far different than a standard desktop app, there are literally thousands of browser/OS/version combinations. For example here is a popular web site for checking browser compatibility http://browsershots.org/, note how many are listed on the page. Please also keep in mind that this example does not cover the OS or device combinations that also might introduce issues.

I concur that there are many reasons for poor quality software and its implementation. But the days of hiring a single person to drive digital development in a company like Amos past about 10-15 years ago. (And even if they had done this a decade ago, the person would have had to been a VERY strong personality who commanded resources for the effort. And the company itself would have had to recognize the importance in contemporaneously shifting their business model.)

For them to consider this change now is an even bigger change for them as a company. Heck, they don't even have their existing content such as their Scott catalog in a decent database digital format now. Just this alone would require a good database system architect, a group of database coders, and a substantial amount of data entry people. And we haven't even started to develop a web based app to access the data.

I would estimate that this effort would easily consume a total of 3-4 man years (based upon my experience as VP of Engineering at a technology company.) Of course if they committed they could apply a staff of 6-7 people who might get this done in 6 to 8 months. But the ability to apply a single resource to this key foundational aspect of their future as long past. It appears that they are attempting to catch up now without applying the required resources; look at what it has gotten them. For years Amos was satisfied with a simple web presence when what was really required was a true commitment.

In my opinion they are now looking at a paradigm shift in the way they do business. The jury is still out if they will make this commitment, but time is quickly running out. Not having the required commitment also leads to doing things poorly, this includes releasing products without proper testing or not having redundancy in your systems. Given Dan's original post outlining and today's issue, this is apparently is the situation.
Don

Still, it's an excellent free tool. If you need specific device or OS rendering on a specific browser, I recommend http://www.browserstack.com

I use it at work and it's very effective. Here is the list of testable configurations:

https://www.browserstack.com/list-o...uct=live#ios

I have heard in business you can choose any two of three with software projects especially.

1. On budget
2. On time
3. Perfect

But bottom line, when you shell out big money for digital Scott catalogs at virtually no discount to paper catalogs (the value is the knowledge not so much the paper) then you ought to be able to view them offline. The code for downloading content on virtually any device seems to have existed for some time now, so what is the pronominal at Amos? It's not 2009 anymore.

I think Amos is overly paranoid about people illegally sharing digital copies of the information they sell. As if people didn't already buy older, used versions of the catalogs, that they now get nothing from. Not saying they want to discontinue the print version, but they'd probably come out ahead if they went with digital-only catalogs, potential for piracy and all. That way if someone wanted a Scott Catalogue, they'd have to get it from Amos, and nowhere else. Again, I'm not actually suggesting that they kill off the print version, I'm just making a point.

Crouse,
True enough. But can Amos ask that each user downloads hundreds of thousands of images for the catalog? Would users be ok with filling their device's storage up with these images? And what about the bandwidth to download them? (Some devices have monthly bandwidth limitation or charge bandwidth extra fees.) Software updates are also far less expensive to load and test once on a server as opposed to having thousands of update to do in the field. And support costs are also much lower with a server based app.

Amos should have ported their catalog data to a SQL format 15 years ago. They could then have easily generated both their catalog and albums using the SQL data as the source. They then could also use it for all online apps. A single data source feeding multiple products. But they did not do this and instead have separate efforts for each product. If they change one Scott number, they have to update it in multiple places (Scott catalog, Scott album pages, any online apps).

Now they are woefully behind and have less chance of making the transition. They are trying to dabble with online efforts instead of making the necessary commitment. I kind of understand why APS missed the boat, there are very powerful personalities fighting to keep the traditional approaches in place. But Amos is a not an organization with elections and lots of volunteers. They should have seen this coming and at least put the foundation pieces in place years ago.
Don

I was thinking about the online version this year instead of a printed copy. Does anyone know if it's possible to print out just certain pages from the digital version. I like to take just the revenue section with me to shows and in the past I've simply copied the pages from the printed version, but that's a pain to do. It's a lot more convenient than lugging the big specialized around.

Hi

I used to work with Tandem systems. There were no printed user manuals. All manuals and documentation was stored on their site. To read a manual you had to log into the site, i.e.; only Tandem installations could log into the site. If desired, one could print a manual but not store the manual on a desktop drive.

Maybe AMOS Publishing could do something similar.

Don:
My parents had a Studebaker but I do not know what year it was. Once we moved to Maine it was totally Mercury.

Crouse:
On Time, On Budget, and Perfect does not exist in the real world. In all my years I have never seen it happen unless the project was ultra simplistic.

cjpalermo1964:
I do not totally agree. I have friends who are top-notch people work for Start-Up companies. Unfortunately it is the corporate attitude that is the cause for poor work.

Jerry B