1 of 1 people found this helpful
Good luck with that Mr. Hopkins. I'm not offering to partner you, but just to comment. I've also got a records management background (many years ago) and looked at or used many RM products then. There are (or were) many truly awful RM products around. I note the large number of systems developed in Australia, and those I looked at were all Australian.
When I was working full time I took up a job which required the use of Australia's then biggest selling RM product, CARMS. Despite some years of FMP experience I was looking forward to what I thought would be a very good product. I soon saw how wrong I was. Imagine having to query the database using SQL language. Or finding that you couldn't use many fields in your search criteria, such as the date correspondence was received. But the worst feature was that, following a query, the hits were returned in form view only, unsorted (and unable to be sorted), and it took 8 (EIGHT!) keyboard presses or mouse clicks to advance from record to record. But that wasn't the end. Because the form view only showed half the fields, it took another 5 (yes five) clicks to go to the second screen - thirteen keyboard presses or mouse clicks to go from record to record.
I complained to management so much that they arranged for me to visit the developers in North Sydney. When I voiced my problems they airily dismissed them with, "Well nobody else has ever complained, so there's obviously nothing wrong with our product". Management let me ditch CARMS after 9 months and replace it with an FMP system I had already developed on the side from experience in previous jobs. And that was a dream to use (well, I would say that wouldn't I).
The postscript to this story is that, 6 or 7 years later, head office in Sydney decided all software was in future to be Microsoft only, and I spent 4 months converting all our local office FMP systems to Access just before I retired, and that was another truly awful experience.
Best of luck with your enterprise.
Thank you Ross,
Sounds as though you have had some rough experiences. At least I can hold your experiences in mind as I develop my product. I've never heard of CARMS; would it be a precursor to TRIM? Too bad HO would not let you stick to FMP for Windows.
CARMS stood for Computer Aided Records Management System. It was produced, I think, by a company called Ortex in North Sydney. Trim was another, higher-end, RM product. I note that there were two North Sydney. I don't know if either of these is the successor to the CARMS producer.
To expand on my original post, the project as it currently stands serves records on all media, analogue and digital, for their entire life cycles and consists of:
•Tables, layouts, and scripts to do with the people who create/receive records, file and have custody of them, use them, circulate them, and manage their life cycle. This functionality is mostly complete though not quite fully so.
•Tables, layouts, and scripts to do with the hardware used to store and circulate records, its funcion within the records life cycle, and its location and custody. This functionality is mostly complete though not quite fully so.
•Tables, layouts, and scripts to support taking inventory of records not yet formalized into a records management system and generating a formal records classification system. This functionality is complete as far as I can take it with my own test data but does require testing by potential users and consequential refinement.
•Tables, layouts, and scripts to support records retention research and to apply resulting records retention schedules to specific record classes. This functionality is missing with most RMS packages listed by my research attachment. It is complete as far as I can take it with my own test data but does require testing by potential users and consequential refinement.
•Tables, layouts, and scripts to store facts of the existance of records: their creation/receipt, their assignment within the records classification system, their actual filing and custody, along with tracking them among users and through their scheduled life cycles. Scripts for tracking records circulation among users remain to be developed. Life cycle flags exist but layouts and scripts to move records through the various stages of their life cycle remain to be developed. This functionality includes partial EDMS in that the system has a document repository container for electronic records that ties in with the records classification system and records retention schedule. Full EDMS functionality with direct placement from document creating/receiving applications into the document repository, appropriately classified and attached to a retention schedule, remains to be developed and is beyond my current skill.
I hope this gives any developer interested in sharing in this project some idea of what I am developing and seek to accomplish. I have health and other issues that limit my attention to my project, yet I hope to bring it to completion and offer it in the market. Thus I seek an interested and skilled partner.Ted.
P. S. I attach a screen shot of the primary window from which all records management actions follow. This is the window seen by a Records Manager; ordinary users see the same window but with the "Choose Custodial Work Space" and "Records Management" buttons hidden. Most labels are actually buttons.
Message was edited by: Edwin M. Hopkins
Records Minder Front.png 503.7 K
1 of 1 people found this helpful
An interesting proposition but my question is, what is the market for this type of product and who are the competitors? Developing in Filemaker puts one behind the 8 ball before you start with many companies refusing to allow the product in to their Windows environments. As for the Mac population, although Mac penetration is increasing, is there really a viable market out there? As a past-developer of a RMS for an Australian state-based Ministry of Housing, I understand the effort involved to do this properly. Rather than jump in at the deep end with my eyes closed, I would like some idea as to commercial viability. Are you proposing some equity sharing arrangement and if so at what percentage or are you prepared to pay an hourly rate? Who pays for the out of pocket expenses, software, etc? Do you have a project plan you can share? Is there a functional specification and a technical specification?
Many questions......no answers.
This reminds me of days of rewriting Wordperfect Macros for the Legal letters! The staging and the filing and retrieval... I'm even certain the diagram has some of the same graduated fills.
I've also heard of CARMS... although I never knew what it was. (we must have crossed paths at some point in the early '90s, Ross.
Now Ted.... I think there is a lot to think about here. Bob asked some relevant questions... but it goes a lot deeper than that. Most developers have a solution or two under their belt that 'just need a few more things done... and it will be ready to sell'. It is a tired old truth that when the database is built... you still have half the work to do in order to get your product to the market.
I think you should do it as a PHP API for FM web solution...
Thank you Bob,
You offer interesting and challenging questions. I am a records manager first and an application developer remotely second, having previously used FileMaker Pro for personal use databases only.
There certainly has to be a market out there; every organization, large and small, generates and receives recorded information and those records must receive proper management to preclude them from becoming a burden. Modern governmental requirements and business standards increasingly demand formalization of all records handling. PC developers certainly see the market; witness the plethora of RMS product for Windows that I found to make up my research list. Though a much smaller market, Mac using organizations must exist and these surely should formalize their records management. The glaring dearth of Mac product for records management suggests opportunity.
I have assumed this project on spec, thus I anticipate that a partner would join me on the same basis. Certainly, I cannot afford to pay an hourly rate up front. It would be some sort of equity partnership as the partner and I would mutually agree, likely percentage of eventual earnings derived from each partner's contribution to table and layout structure and scripting. This has to remain open for negotiation with tnhe potential partner. A potential partner would likely already have FileMaker Pro and probably in a more recent version than I use. I still use version 9, so it would be entirely my own responsibility to upgrade to match the partner, my own expense. I really do not anticipate other out-of-pocket expenses but any that arise would require the two of us to mutually agree on how to cover them.
The front window is my project plan. It is a distillation of my knowledge and experience within the records management business discipline. The tables, layouts, and scripts derive from that knowledge and experience; they are the re-expansion out of that distillation to serve the records management functionality I seek to achieve. Now I have to display my limited experience as an application developer: what do you mean by "a functional specification and a technical specification?" I know what I want the project to accomplish; that is in my head, embedded in my records management knowledge and experience. The partner would likely bring the technical skills of application development and usability polish, derived from what I see as needed to effectively serve the records managemt business discipline.
Hope this, in some way, answers your questions,
Thank you Lyndsay,
No button shows to mark your thoughts as helpful, but they are. You will likely have read my reply to Bob.
Yes, the "half the work to do in order to get" my product to market will be a significant role for a potential partner's participation. I have no experience whatsoever at marketting and my health really limits my energy.
Now, I have to further display my limitations as a developer. What does "PHP API" stand for? Yes, I view my project as ending up as a web based solution, for installation on an organization's intranet. The most substantial RMS applications are web based and have moved away from server/client networking with seat-by-seat installation. Best would be software-as-a-service in the "cloud," but that would mean I'd have to sell the system outright as the complexities of the "cloud" with necessary server support are well beyond both my capacity and my interests.
Good to hear from you again,
I think you are in danger of putting the cart before the horse, as they say.
You really need to not think about technology at this point and to do so will bite you in the bum later on. Focus on what the product is meant to do and for whom. Write down, in a series of simple sentences, what the product has to so. For example, Records Manager needs to be able to add a new file. User needs to be able to open a file to see its contents. User needs to be able to scan new correspondence into a selected file. Etc Etc. Get as detailed as you can as retrofitting a missed function can be very costly in terms of time and money.
This gives you the functional requirements. After that, you work out how to implement them using whatever technology is on your demographic's sights, be it the web, a local server, their own laptop, the Cloud, etc. What about an iPad/Android interface? if that is required then FIlemaker may again be precluded. And mobile is an increasing desirability by users.
You also need to consider the system side of things, such as backup and recovery, archiving, single or multi-user, concurrency (which imports issues of locking and simultaneous access, which may preclude a Filemaker solution), documentation, support, etc. A commercial product has all of these elements and yours will need these also
Then you begin the programming work.
To choose PHP now may end up an overkill that has a pretty high learning curve which may be wasted.
Sounds pretty daunting, doesn't it? But it is all well known and understood in software development circles. So find yourself a competent software developer, AFTER you have done the planning.
Just some thoughts as a seasoned software developer
There is also another (older) PHP API called FX.PHP which does the same things in a different way... with a different language. It is also a viable choice... it is just that the other comes bundled with FileMaker Server.
Don't be frightened by 'the cloud'... it is just other computers... somewhere out there in cyberland... that runs your software and provides storage space with a lot more grunt (generally).
You can host it anywhere... on your box or my box or in the cloud...
...using FileMaker Server for clients using FileMaker Pro and for clients using a web browser with pages written in PHP
...using FileMaker Server Advanced for clients using FileMaker Pro and for clients using a web browser with pages written in PHP and for clients using Instant web publishing in a web browser.
...using FileMaker Pro for clients using FileMaker Pro and for clients using Instant web publishing in a web browser.... but only a handful at any moment in time.
Whichever way you choose... the basics of the structure and relationships must be built in such a way that any method is possible. If you build with PHP you don't have to fuss about database interface... just the web interface. It may be that administrators and editors use FileMaker and the public or members use a web access...so that's what you design for...
There are just some things that you can't do on the web as well as you can using FileMaker... like printing nice tight reports with summary information... and others you can do more easily using PHP... like uploading files, renaming files, sending HTML emails etc. There are also many plugins which allow you to do these things inside FileMaker... There are a host of choices.
I do not fully understand the subtleties of your data ... but I have have used the kind of systems you seem to be describing... such that you might find in places like the "National Archives of Australia" where I search in a narrow field for WWI and WW2 Army records... all of which are being meticulously scanned and uploaded and where there are placeholders for those which have not yet been processed, and when taken for processing the files are logged in and out etc etc...
A database is a database is a database... it's all just columns and rows...
A good database starts with a good plan... as Bob stresses it is defined by who needs to see what when and how... who needs to change it what when and how... A good database will have a solid plan for how the data tables relate to each other... which is usually many times for the same tables for many different purposes. There are some good resources in this site that discuss the pros and cons of various relationships and they are well worth reading.
Now depending... on whether you want the data to be available generally for only viewing and searching... it may be that FIleMaker Go is appropriate.I did a little database for Go that accessed the remote data under one scenario and in another imported and replaced records when connected to a network so the database could be used when no network's available. You could also update via iTunes but this is a bit tedious.
Allow me to be a bit of a cynic. In this game.. an idea is not the asset... it is rather the hours of labour that go into making something like this work. Your health will limit what you can do so you are asking a "Partner" to take all the risk. May I suggest that if you write up the spec properly.. and then try and find an investor with some marketing skills who is prepared to take that risk with you... to then pay/subsidise a developer to build it. That way you are much more likely to interest someone who has the right skills... not just someone with time or inexperience on their hands...
... blunt.. as usual...
Rather daunting, but certainly helpful. A lot for me to think over.
Blunt, but useful advice with depth. You and Bob give me a lot to mull over.