views:

115

answers:

2

We have lots of data and some charts repesenting one logical item. Charts and data is stored in various files. As a result, most users can easily access and re-use the information in their applications.

However, this not exactly a good way of storing data. Amongst other reasons, charts belong to some data, the charts and data have some meta-information that is not reflected in the file system, there are a lot of files, etc.

Ideally, we want

  1. one big "file" that can store all information (text, data and charts)

  2. the "file" is human readable, portable and accessible by non-technical users

  3. allows typical office applications like MS Word or MS Excel to extract text, data and charts easily.

  4. light-weight, easy solution. Quick and dirty is sufficient. Not many users.

I am happy to use some scripting language like Python to generate the "file", third-party tools (ideally free as in beer), and everything that you find on a typical Windows-centric office computer.

Some ideas that we currently ponder:

  • using VB or pywin32 to script MS Word or Excel

  • creating html and publish it on a RESTful web server

Could you expand on the ideas above? Do you have any other ideas? What should we consider?

+1  A: 

Instead of using one big file, You should use a database. Yes, You can store various types of files like gifs in the database if You like to.

The file would not be human readable or accessible by non-technical users, but this is good.

The database would have a website that Your non-technical users would use to insert, update and get data from. They would be able to display it on the page or export it to csv (or even xls - it's not that hard, I've seen some csv->xls converters). You could look into some open standard document formats, I think it should be quite easy to output data with in it. Do not try to output in "doc" format (but You could try "docx"). You should be able to easily teach the users how to export their data to a CSV and upload it to the site, or they could use the web interface to insert the data if they like to.

If You will allow Your users to mess with the raw data, they will break it (i have tried that, You have no idea how those guys could do that). The only way to prevent it is to make a web form that only allows them to perform certain actions that You exactly know how that they should suppose to perform.

The database + web page solution is the good one. Using VB or pywin32 to script MSOffice will get You in so much trouble I cannot even imagine.

You could use gnuplot or some other graphics library to draw (pretty straightforward to implement, it does all the hard work for You).

I am afraid that the "quick" and dirty solution is tempting, but I only can say one thing: it will not be quick. In a few weeks You will find that hacking around with MSOffice scripting is messy, buggy and unreliable and the non-technical guys will hate it and say that in other companies they used to have a simple web panel that did that. Then You will find that You will not be able to ask about the scripting because everyone uses the web interfaces nowadays, as they are quite easy to implement and maintain.

This is not a small project, it's a medium sized one, You need to remember this while writing it. It will take some time to do it and test it and You will have to add new features as the non-technical guys will start using it. I knew some passionate php teenagers who would be able to write this panel in a week, but as I understand You have some better resources so I hope You will come with a really reliable, modular, extensible solution with good usability and happy users.
Good luck!

Reef
Thanks, that is the direction that we are most likely going to take. P.S.:I like the "i have tried that, You have no idea how those guys could do that" ;-)
stephan
+2  A: 

I can only agree with Reef on the general concepts he presented:

  • You will almost certainly prefer the data in a database than in a single large file

  • You should not worry that the data is not directly manipulated by users because as Reef mentioned, it can only go wrong. And you would be suprised at how ugly it can get

Concerning the usage of MS Office integration tools I disagree with Reef. You can quite easily create an ActiveX Server (in Python if you like) that is accessible from the MS Office suite. As long as you have a solid infrastructure that allows some sort of file share, you could use that shared area to keep your code. I guess the mess Reef was talking about mostly is about keeping users' versions of your extract/import code in sync. If you do not use some sort of shared repository (a simple shared folder) or if your infrastructure fails you often so that the shared folder becomes unavailable you will be in great pain. Note what is also somewhat painful if you do not have the appropriate tools but deal with many users: The ActiveX Server is best registered on each machine.

So.. I just said MS Office integration is very doable. But whether it is the best thing to do is a different matter. I strongly believe you will serve your users better if you build a web-site that handles their data for them. This sort of tool however almost certainly becomes an "ongoing project". Often, even as an "ongoing project", the time saved by your users could still make it worth it. But sometimes, strategically, you want to give your users a poorer experience to control project costs. In that case the ActiveX Server I mentioned could be what you want.

Behrang Dadsetan
+1. This is a very interesting view of the MS Office integration that I was unaware of. I also appreciate that You provided some example problems that might occur if this solution would be used, as it would be very hard to find this kind of experience on the web.
Reef