The Big Picture: Time to start over

We are entering our sixth year of data collection. Originally, there was no plan - everything you see just happened. It's time to take a step back and look at the big picture. Using what we've learned from the last five years, it is time to do a complete redesign focusing on self administration, user features, scalability, analytical tools and data warehousing.

The goal is still to provide an affordable, easy to use, reliable and accurate data collection systems to

  • give lay beekeepers a noninvasive view into the hive to observe, understand and manage the colony and to maximize honey production..
  • research colony management techniques, hive designs and materials,
  • monitor climate, environment and land use,
  • provide free access to data preserved for future generations.

The main factor limiting growth is the lack of an inexpensive (bee keepers are cheap) appliance (something that is easy to use by non technical people). The number of developers, testers and users has reached critical mass. Development will accelerate. I view everything we have in place as a first attempt/rough draft/proof of concept/ver 0.1 cobbled together erector set sort of system. It is time to take a step back and do a complete redesign focusing on self administration, user features, scalability, analytical tools and data warehousing.

I am trying to manage Dev Kit orders using a spreadsheet and email searches. It's not working. We need an end-to-end self administered system that would start with order entry/account creation and allow partners or subcontractors access for order fulfillment and tracking. It should also track purchases and inventory of parts and load cells, and provide accounting both for transparency and to demonstrate fiduciary responsibility for grant applications. I have experience with LedgerSMB and am considering trying to use it. http://ledgersmb.org/ Any other suggestions? Maybe a Drupal module or online storefront software?

We are currently running 2 websites with servers located in the west and northeast US, running two installations of Mediawiki and Drupal. Perl scripts and other SQL databases are used for hive data ingress, research, archive and visualization. Part of this is redundancy, part to isolate the hives from the users, part happenstance. Hivetool,net is used for beekeepers and the public to see recent data. Hivetool.org is being used for development. Is this the best way to organize the site and use the URLs?

Comments

I somewhat agree. There is some great stuff developed over the years. But as with everything, you get smarter along the way. And the last months a lot of great ideas have come up. The forums really are an added value.

Do we need complete rewrites. I guess not: We need to shape and adjust and really define a design. This way we can point our noses in the right direction.

By the way. I ran into this one some time ago: http://12factor.net/ . Not to long but great read. I could be great for the data collector webservice. To have it scalable when we monitor 100+ hives :)

This is one of my 1st posts. I am relatively new to Hive Tool, and I want to say upfront that I truly appreciate all the hard work and dedication of the developers of Hivetool . I think you've developed a great research tool. I have a few suggestoions regarding Paul's recent post.

Paul said, "I am trying to manage Dev Kit orders using a spreadsheet and email searches"

Quickbooks is an accounting software program I used for years. If set up properly, it can do everything from ordering to shipping; you can enter serial numbers and auto reorder materials.
With the printouts, you can get a complete picture of the operation at any moment in time.

Paul also said, "The main factor limiting growth is the lack of an inexpensive (bee keepers are cheap) appliance (something that is easy to use by non technical people)."

For this, I suggest the possibility that the product be split into three devices:
1) an inexpensive, quick to mount, totally complete device with little or no set-up required. This device would provide a minimum of information - basically a "go/no go" on hive health
2) this device is what Hivetool sells today - an inexpensive, expandable research tool for developing new concepts in monitoring, and maybe some control in the future releases. This device would not be as easy to set up, requiring some technical experience.
3) this device would be on the cutting edge of technology, and would be comprised of extremely low-power. substantial computing capabilities, and pointed towards commercial apiaries, willing to pay for advanced features.