can't touch this

so been plating with the iPod touch for a few days now and am trying to type out an entry as fast a the keyboard will let me. not too bad word replacement is happening and I can type out reasonably quickly. for posts re rich text we does not work but is fine ss HTML. amy caps you see are actually word replacements.

well a good test to say the least. makes me hopeful that a lims app is not so far fetched.

Easy Gbarcode

A few posts ago I had mentioned that my Gbarcode project should really be a bit more user friendly as well as provide an easy way to create PNGs without loading memory hogging libraries like RMagick. I investigated using the Cairo libraries for this here.

Good news for every one that uses Gbarcode, and those thinking of using it, I created a small wrapper module that is more Ruby-ish and also uses Cairo to print out to PNG. The functionality is bare-bones, with a fixed height of 150 pixels and width is determined by the length of the encoded barcode. It works well for Code 128 barcodes. Grab the ruby file here.

To use this module, here is an example (note that bad encoding schemes will result in a raised excpetion, hence the begin/rescue block):

require 'gbc'
require 'gbarcode'
require 'markaby'

begin
b = GBC::Barcode.new(ARGV[0], Gbarcode::BARCODE_ANY)
puts b.ascii, b.partial, b.encoding
b.to_png("out.png")
b = Markaby::Builder.new()
b.html do
body do
img(:src => "out.png")
end
end
f = File.open("out.html","w")
f.write(b.to_s)
f.close
rescue Exception => e
puts e.message
end


ITMArT: Design: Part 1.2 "The competition revised"

During the last post, we took a look at two open-source procurement solutions out in the wild. Today I noticed that there is a third project that we should take a look at, Coupa. Coupa is a commercial venture that also provides an express edition of their product (e.g. a bit less features than the supported product).

Simply put, their mission statement is very similar to ITMArT's, namely that purchasing should be simple, intuitive and serve the needs of both the managers and users of the system, not just the managers. Taking a look at the demos, Coupa blows ITMArT out of the water feature and UI wise, while retaining some pretty advanced capabilities. There are very nice reporting modules, web forms, invoice ability, role and group based access to data and actions, very nice email integration, etc. If I where a finance guy at the University level, I would stop all in-house development right now and switch to their platform. Its that nice.

Having said that, I am not at the University level, or even departmental level. ITMArT's audience is a much smaller group, namely the medium to large laboratory, and they rarely need such things are approval hierarchies, approved vendor catalogs, etc. Those needs are usually at a higher organizational level and hence ITMArT development does not stop here.

A bit of good news is that I have lots of good ideas from the Coupa demos that I will ut on the feature request list of ITMArT. Another good bit is that Coupa express edition is a Ruby on Rails application, the same as ITMArT! So I can take advantage of some of their codebase for a few nagging concerns of mine, like authentication, group assignments/permission, and role based authorities.

ITMArT : Design : Part 1 "The competition"

So far my posts have focused on the bencher's quest (to learn code). This is mainly because it is infinitely easier to write about small and helpful scripts than about complex issues like application UI design. But since I introduced the ITMArT application, I might as well go through the design process for it. This will be a mutlipart post covering a couple of areas of the application and design process. First up will be the history and requirments of the app.


History

ITMArT began as any project does:Outlining a set of requirements and then looking to see if some existing application already does what you want to accomplish. In this case, the requirements consisted of:

1. an application that tracks purchase requests and purchase orders
2. users would often have recurring request, a searchable catalog would be ideal
   
3. new types of requests come up often so adding vendors and items should be easy and flexible
   
4. orders can only be placed by select group of users with access to funds
5. monthly report of expenditures would be great
6. email alerts of requests from request to order to receiving
   

You'd think there would be some open source ERP system out there that would have these component in it, and there are: Openbravo.com and TinyERP are just two examples. The trouble is that ERP systems generally tend to focus on the needs of the business processes and not so much on the requirements of the end user. I'll get to what that means in a minute, but suffice to say this type of focus would not have worked for us.

The ERPs

Let's first look at Openbravo, a Zope application and UI nightmare. Pop-ups all over the place, difficult navigation and difficult to use forms. Tons of click-through dialogs and switching between keyboard and mouse, essentially MSDN design taken to the web. But don't just take my word for it, demo it yourself and see.

TinyERP is much better, but still focuses on the business case. For instance their forms (and top menu) make a distinction between creating a purchase order and creating the line items for that order. Which means that the user must know ahead of time that they need to create an order request first, which means that the system is not intuitive enough and will either require documentation (which no one reads) or training (which you have to pay for). Much worse, when creating the order line items, you need to specify a ton of fields and know the purchase order ID! OK, so the AJAX search helps you out for finding the order ID, but one typo and you have a clean up on aisle 9.

The last thing that makes an ERP unsuitable would be my first point, namely the focus on business processes. Usually this is not a problem, since you can make the assumption that the community is relatively stable and business oriented. The user community we have to service is a mix of bench scientists, admin assistants and business office types. There are no resources for training and the usability expectations are high.

This means that we have to shoot for the Lowest Common Denominator in terms of the overhead placed the ordering process. Making a purchase request should be as simple as creating an email, and if it is not, then there had better be some work savings later to make up for it. Order placement in TinyERP is less than ideal, but not completely onerous as Openbravo, and the work savings are that the reporting, catalog searching and order processesing are streamlined.

The deal breaker comes in the catalog management aspect. Adding items and vendors is not intuitive or easy enough for the majority of our user base. This is where focusing on the business process of catalog management really takes a pounding on usability. The central assumption here is that catalogs come from a preferred set of vendors and are bulk updated (and not very often). The broad user community means that the vendor list will be constantly changing, that pricing will be variable, and the various catalogs will be fluid. The burden of catalog management must be passed on to the purchase requester for the application to be scalable (e.g. roled out to other departments or laboratories). Centralized management of the catalog would incur too high a cost otherwise.

Conclusion

Based on these quick reviews of existing systems, I decided that further trolling through open source projects would not be worth my time. If even a simple, easy, and good looking application like TinyERP did not fit the bill, what would? A custom application, that's what.

On the next ITMArT post, we'll dicuss the actual design choices made to fulfill the list of requirements that we had mentioned at the start.