Requirements- How to collect data?

As I was writing the other “Requirements” question, I came up with a second related question, but I felt it was large enough to justify creation of a second thread.

So, Question #2: How should FSN collect data? What methods and programs should be available? Should FSN have standard programs available for teams to download and use, or should we just provide a standard export format, and let teams run with it? If we make client-side programs, what types of clients should be available? How can we make it easy for teams to get lots of data, and quickly submit it to FSN?

Note: this is not about the data itself, just the methods of collection. If you want to talk about what data to collect, see my first question.

I think that the best way is to ask team members of each team for their basic opinions on the bot, and for team/ bot info, but to also allow people from other teams to comment and to add any missed information.

I think a combination of a standard export format and downloadable programs would be best, with the standard export format taking precedence when time becomes an issue. This way teams that already have a developed scouting program set up can just modify it to fit with the standard format, while teams that don’t have the time/talent to make such a program will be encouraged to contribute to FSN by the program.

As for platforms, I think PalmOS would be the best choice. Lots of people have some sort of palm, and they’re easily portable. You can also find fairly inexpensive ones with little difficulty. A Windows version would be the other alternative, as most people use a Windows operating system. This might not be as popular though because many teams don’t have an extra laptop or several lying around to use for scouting.

try emailing various team members, and try during comp season to use soap 108 to find out where they’re going and to check them out in person.

This is seriously how I think it should be done… The Scouting Network should be just that… a network. The online databases should be the hub of the network, anyone should be able to add data via whatever software they or another team has created. The FSN should not provide any tools, or online methods of dataviewing or creation. In this way, a team like 108 can continue doing what it is doing, online team robot profiles… anyone can go there and insert data. Via the network, the info is uploaded… and then another team, can take that data and display it how it wants. Another team could write a Palm program that anyone can use, and all data would be synched with the network.

I don’t think the FSN should provide any tools, other than documentation, and links to teams and their methods of data entry and retrieval.

as my other post said, AJ has a very unique idea, which is slightly different that mabey some (includeing myself ;)) have invisioned.

I think it really is something we need to think about. After all, If FSN did have a site, who really would to to team’s sites? (Unless they portrayed the data in a better way than FSN did)

Do we like all/some/part of this idea?

Please comment in the other thread.

jack

As far as data collection goes. I think that the FSN community could develope several apps for different purposes. For example a basic web entry system to enter the database through an internet browser. AS well we could also develope basic applications for FIlemaker, access, and also a palm application. Another good idea would be to make a BASIC paper form for teams to fill out.

This is more for the teams that want to help but aren’t going to go too deep into doing their own scouting. The teams that already have databases or systems like soap and wash could easily be intergrated into the FSN system with their curent datacollection methods.

Speaking from a technical standpoint, it is certainly very easy to do data collection that is compatible with Microsoft Excel, and most other spread sheet programs through the use of comma-delimited files (CSV). Since it’s so easy to do that in the technical aspects, I think it would be a viable formatting option, especially given how many people are already familiar with using their favourite spreadsheet program.

This also has the advantage of spread sheet programs being available for many devices that use the CSV format, for example, Windows CE devices are able to process this format using Spread CE, or Microsoft Pocket Excel. I do not have access to a Palm-OS device, but I imagine the spreadsheet software they posess could deal with this information as well.

The main disadvantage to doing this that I can see is what happens if the field names change? That could probably be dealt with easily enough through the use of a header column, though.

Also, for a more obscure system, you could always set up something that uses WML and interfaces with cell phones, if the data is primarily numericial in nature, this wouldn’t be too bad-- since cell phones with internet access are becoming increasingly common, however this would have the disadvantage of requiring the regional database servers to have a constant internet connection in order to receive cell phone submitted data.

I think I should also mention, that all database entries should have timestamps. For the sake of synchronizing, most everything thing that would change should have them so you can know when you need to synch the databases.