skydivingdutch 0 #1 October 4, 2003 I am writing a (web-based) software package for dropzones, and I would like some input, before i get too far. I have 7 screens: -Finances -Manifest -Schedule -Packing Log -Events -People -Inventory Finances is for dealing with finaces, not suprisingly. you can sell stuff to people (like tshirts, jumps, gear) or buy/pay people for packs , doing videos or so. It will link into the pack log, allowing people to pay for jumps with packs. Also it will generate reports Manifest lets you view the loads that are going up, who is on it ( numver based on plane capacity), if they have paid. It will alert you if someone who hasnt fillout a waiver is manifested, keep an eye on total weights etc. Schedule lets you manage the appointments for the day/week/month/year. See if new or edxisting students are coming out, make new appointments etc (sorta like outlook) Packing Log keeps track of pack jobs. Add, edit and remove jobs, transfer them to finaces. It requirs the packer to be cleared by the DZ for packing Events keeps track of trainings, get togethers etc People, is kindof an address book, and also inncludes weights, license info etc. inventory lets you mangage what you've got, like rigs, airplanes, jumps (prices altitude etc), things for sale n such When done, in like a month or so (got school too ) ill post a working version. So what do you think? I'm sure that somthing is missing, I've never owned a DZ before (somday?) so i don't have a great insight into things required. http://dropman.com Quote Share this post Link to post Share on other sites
timmyfitz 0 #2 October 5, 2003 If you what to know what a DZ needs are for software, work in manifest at several DZ's. Every DZ will not be the same. I have no experience in what goes on behind the counter but I do know that probably the best way to improve a system is to understand the current system and find some weak points or something that the manifesters "wish" they had. I do tandems and I understand that. I try to improve our training when I see a need but before I started doing tandems I couldn't tell you JACK about how to make it better. Get involved in the area you want to improve, ask a lot of questions to the people's lives you are trying to improve and go from there. Good Luck. Quote Share this post Link to post Share on other sites
skydivingdutch 0 #3 October 5, 2003 I am involved at my DZ, and all the functionality i describe here is based off what i hear from my DZ. Most of it is done on paper, so an upgrade is worthwhile i think. What I would like is when this package is done for it to be usefull for lots of DZ's. How cool would it be to see my system at an other DZ when I'm on vacation? http://dropman.com Quote Share this post Link to post Share on other sites
Kris 0 #4 October 5, 2003 I like the system at Skydive Dallas. They have several TV's around the DZ which shows the load times for the Otter and the Caravan which is fed from their manifest system. The system also keeps track of jump credit and jumper accounts along with pretty much everything else on your list. It's a pretty nifty setup.Sky, Muff Bro, Rodriguez Bro, and Bastion of Purity and Innocence!™ Quote Share this post Link to post Share on other sites
skybytch 273 #5 October 5, 2003 QuoteIt's a pretty nifty setup. Yup. Perris has an equally nifty set up - wonder if it's the same program? I know there are at least a couple manifest/dz software packages on the market in the US. Quote Share this post Link to post Share on other sites
skydivingdutch 0 #6 October 5, 2003 only one i've heard of is JumpRun, and it costs like $1700 This will be such a better way to go. Sounds like i got most everything covered, but specs change all the time in software development land. http://dropman.com Quote Share this post Link to post Share on other sites
vonSanta 0 #7 October 5, 2003 Make sure you have an easy to use billing component that logs all transactions, their type etc. Your software won't be used if it doesn't ease the lives of those in the manifest, and having to go through more than one screen to (for instance) show someone why they're paying say $50 more than they thought they should is just not good enough. Don't get too technical - that ain't impressing anyone but other fellow geeks. Include users as early as you can in the process - prototyping is a good tool here. And make sure yer system keeps (several) logs of what's happening. Last advice: think about odd errors, consistency and redundancy. I've seen bad handling of these last items f@rk up otherwise nice systems. Just my €0.2 Santa Von GrossenArsch I only come in one flavour ohwaitthatcanbemisunderst Quote Share this post Link to post Share on other sites
Fast 0 #8 October 5, 2003 The ability to look at reports and print them for just about everything listed above that you have in there. There is some degree of recordkeeping required that I am sure your DZ is doing on paper at the moment, so they will probally want some print outs. Ability to print a jumper log for a particular jumper? ...Plane? ...Day? hmm, thats all I can think of.~D Where troubles melt like lemon drops Away above the chimney tops That's where you'll find me. Swooping is taking one last poke at the bear before escaping it's cave - davelepka Quote Share this post Link to post Share on other sites
skydivingdutch 0 #9 October 5, 2003 Yes that is all plannned. I've written stuff like this before fo illiterate people and there will be lots of error checking and no cryptic codes and such. Reports are good. http://dropman.com Quote Share this post Link to post Share on other sites
tombuch 0 #10 October 5, 2003 The ability to list the same person by several names or knicknames. The ability to gang people into groups so a team can be entered with just one team name, and set up so team members can be changed quickly. The ability to bill by the person or team. The ability to set different jump prices for different jumpers such as club rates, visitor rates, bulk rates, team rates, staff rates, special one time discount rates. Rates should be available by category, but should also be adjustable by the manifester. Thus, if a jumper has an established "cheap" rate it should automatically appear when that persons name is added to the manifest. Likewise for teams. the ability to tally a log of rates so a DZ can see how many slots were sold at what price. A quick-view tally of the current number of jumpers on a load and the current income being generated by the load. Some DZ's may set minimums for either the number of jumpers, or the amount a revenue a plane must generate before being launched. The ability to manifest different types of airplanes like Cessnas and Skyvans, and the ability to change the maximum number of jumpers allowed on each load, a value that might change based on fuel level, temperture, headwind/tailwind. Status of each load...has it been "called" yet, and how long until it takes off. Is it in the air, and how long until exit/landing? The flight time needs to be adjustable for each airplane, and quickly adjustable for fuel or maintenance delays. The ability to track activity by airplane so a DZO knows how many loads have been flown by each plane, how many jumpers have been flown by each, and the overall income each plane generated for a selected time period. The ability to flag a jumper for an out of date reserve, waiver, USPA membership, outstanding balance, or whatever. The ability to set those flags so they alert manifest to the problem and allow the manifestor to over ride, or the ability to turn off the over ride possibility. The ability to set those flags independently so manifest can be alerted if a reserve is out of date, or if they choose two days from going out of date. Likewise, the outstanding balance flag should be adjustable so manifest can allow each jumper to establish his/her own "credit" line, yet flag the account when the jumper is over the line and trying to manifest. Perhaps a few user adjustable hot links on each screen that manifest could use to click through to the USPA site, or Weather, or the DZ's own web site, all without leaving your software to dig back to the main desktop. The ability to network so multiple machines can be accessing the same data. The ability to export some data, but firewall other material, so things like current loads could be exported to a DZ screen or web site checked by jumpers using their wireless computers, all without compromising sensitive data like individual jumper rates, account balances, etc. Good luck with your project... Tom Buchanan Author JUMP! Skydiving Made Fun and EasyTom Buchanan Instructor Emeritus Comm Pilot MSEL,G Author: JUMP! Skydiving Made Fun and Easy Quote Share this post Link to post Share on other sites
skydivingdutch 0 #11 October 5, 2003 Wow, thanks for all that helpful info. Most of that is planned, I added team sup[port to my list. The system is inherently networkable, due to web-based nature, Come completion, I could write another front-end that is publicly accessible, good idea. http://dropman.com Quote Share this post Link to post Share on other sites
nathaniel 0 #12 October 6, 2003 Quote Status of each load...has it been "called" yet, and how long until it takes off. Is it in the air, and how long until exit/landing? The flight time needs to be adjustable for each airplane, and quickly adjustable for fuel or maintenance delays. It should predict fuel loads, maybe prompt manifest to confirm predicted fuel loads. The logic and UI will be key in turning this from a mistake into a must-have. Go-arounds and generalized inconsistency in load times should be tracked and predicted. Quote The ability to list the same person by several names or knicknames. The ability to gang people into groups so a team can be entered with just one team name, and set up so team members can be changed quickly. The ability to bill by the person or team. And multiple accounts per name if required. Sometimes packaged jump accounts are distinguished from regular accounts. User accounts for manifestors and 100% logging of all actions by manitestor, and reporting on the logs. Next door to this is auto-lockout after x minutes of inactivity. Maybe a staff screen for maintaining who's owed what and who is qualified to do what, eg, no tandems allowed in manifest without assigned + qualified TM. ACLs so only authorized users can access certain screens. Quote The ability to export some data, but firewall other material, so things like current loads could be exported to a DZ screen or web site checked by jumpers using their wireless computers, all without compromising sensitive data like individual jumper rates, account balances, etc. The ability to export all data to tape or CD-R or DVD-R. The export should be in human readable ASCII based or similar format so in the worst catastrophe it could be easily recovered. Reminders if the data hasn't been archived every so often. The ability to export + import data to/from Excel, Access, Paradox, Quickbooks and other productivity software suites. On the accounting and money handling side of affairs I don't know whether you have any proper accounting experience...if you haven't then picking up a book on (sound) accounting practices would probably give you some good ideas. nathanielMy advice is to do what your parents did; get a job, sir. The bums will always lose. Do you hear me, Lebowski? Quote Share this post Link to post Share on other sites
skydivingdutch 0 #13 October 6, 2003 About load time predictions: At my DZ it its really not predicatable at all (hectic sometimes), especially this time of year, with all the weather. The interface is really simple, no hidden shift-click stuff or anything, what you see is what you get. Every person will ahve their info in the system, but they dont have their own control center, because there isnt really a whole lot they can do, except maybe change the phone number. The person at the desk is the one who uses this. System wont care if you make more than one account with the same name, although it might be consusing when you have to choose one. Qulifications are already taken care of Everything that is done to the system goes into a database, so nothing is ever discarded. Export to different sofware will be tricky, and are not a priority at this point, but its a good idea. The data is easily backup-able. http://dropman.com Quote Share this post Link to post Share on other sites
CrazyDave 0 #14 October 6, 2003 QuoteI am writing a (web-based) software package for dropzones, and I would like some input, before i get too far. I have 7 screens: -Finances -Manifest -Schedule -Packing Log -Events -People -Inventory why dont you just use a database program like access to do it??? it would most likley be a lot more useful, and less hassle Quote Share this post Link to post Share on other sites
skydivingdutch 0 #15 October 7, 2003 Iam using database software, just not access. http://dropman.com Quote Share this post Link to post Share on other sites
ianmdrennan 2 #16 October 7, 2003 ummm no. We (the company I currently work at) have a resource dedicated to removing the crap that is MS access while the rest of us write applications for the company. Thanks to the MSAccess database wizard you too can now create a support nightmare for your development and IT staff Access is the devils tool (anyone who's had to deal with user created access wizard databases will understand my hatred of the product). A database should be exactly that, not MS's version of a hybrid vb'eqsue front end with a crippled database backend. Do it properly or don't do it at all. Blue skies Ian ps: Did I mention I hate access? Performance Designs Factory Team Quote Share this post Link to post Share on other sites
tictoc 0 #17 October 7, 2003 I asume you are also puting in resurve packing dates and info to flag manifest when a resurve is out of date?-------------------------------------------------------- Some one must go to the edge for others to be able to find it. But if you go be sure you can make it back. Quote Share this post Link to post Share on other sites
skydivingdutch 0 #18 October 7, 2003 but ofcouse :) Yes Access sucks something fierce. IF you want to know, the database system used is MySQL. http://dropman.com Quote Share this post Link to post Share on other sites
tkhayes 348 #19 October 7, 2003 if you want it to really be successful, tie in an online web-based reservation system and possibly credit cards payments with the process. Quote Share this post Link to post Share on other sites
Kris 0 #20 October 7, 2003 Quoteif you want it to really be successful, tie in an online web-based reservation system and possibly credit cards payments with the process. The DZO has spoken! That's actually a pretty novel concept, TK.Sky, Muff Bro, Rodriguez Bro, and Bastion of Purity and Innocence!™ Quote Share this post Link to post Share on other sites
nathaniel 0 #21 October 8, 2003 Quote The person at the desk is the one who uses this. Some DZ's have more than one manifest bitch. If someone screws up the data after a spat with the DZO it would be real nice to know who did it. NathanielMy advice is to do what your parents did; get a job, sir. The bums will always lose. Do you hear me, Lebowski? Quote Share this post Link to post Share on other sites
skydivingdutch 0 #22 October 8, 2003 Great idea. This is the kind of input that will make this package rule all. And there is no way Im charging $1000's for it. My aim here is to make DZ management more, well, managable, ..... and score some free jumps http://dropman.com Quote Share this post Link to post Share on other sites
skydivingdutch 0 #23 October 11, 2003 Do think someone's weght should be required in the software or optional? The weight makes plane and wingloading calculations possible. http://dropman.com Quote Share this post Link to post Share on other sites
QuickDraw 0 #24 October 11, 2003 After looking at the Netheravon fatality, maybe a check-in system might be useful. Maybe a bar-code system ? -- Hope you don't die. -- I'm fucking winning Quote Share this post Link to post Share on other sites
hipgnosis 0 #25 October 11, 2003 I admire your effort! However, as this sounds like one of your first forays into commercial software, let me share with you a couple of hints : 1. Support. If you write it and sell it you will be expected to support it. Are you up for the task of dealing with an emergency out in the dropzone because Mitch the Manifest Monkey pressed the "Do Not Press this Button" button? Or if database corruption occurs because of stray sunspots? Or your program just screws up? And of course how long will you support it? How much will you charge to support it? These questions need an answer, and that answer needs to be on a contract. Plus, how many places will want to spend the time and money to move to your system if they have no guarantee of support. They will want to be able to call you at any time of day and get an answer to any problem, even if it's not remotely related to your program. 2. Liability. Say your software makes a minor error and deletes the days receipts? Or makes some other error that causes the dropzone money? Are you liable? For how much? Again, get a signed lawyer approved contract. If you are serious about moving this to any point beyond a hobby, then you need to answer these questions and consider how much time you'll be spending after the sale supporting them. Products like this that run an office (ie Dental/Medical software, etc.) typically go for a steep initial fee, plus a yearly maintenance fee that includes discounted upgrades. This would be the route I'd suggest to you. Remember, just because you sold the software and have it installed on the users systems, your job isn't even close to being finished! Incidentally, I am not involved in any products used at any dropzones. This post is based solely on 6+ years of developing commercial software used at amusement parks, banks, ATMs, convenience stores, oil fields, etc. Best of luck to you! Bill Morrison Quote Share this post Link to post Share on other sites
