|
Programmers' Opinions Needed- To Change or Not?
Hi- I have a question I am not qualified to answer myself on a technical level, and I would also welcome general feedback on the business aspect of the question.
I have created and been selling, as part of a larger package, a tool for creating a type of financial statements. I made it in MS Excel, and it works by gathering 17 worksheets worth of input (entered manually by the user), and then spitting out 4 worksheets of output.
It works great, except that my customer set is limited to people with access to MS Excel. Since my customers are home users, this actually rules out more than you would think- and also a lot of the Mac crowd. It also somewhat lowers the perceived value of the tool, as in "oh, it's just a bunch of Excel sheets, I thought it was going to be software."
So the question is, can the MS Excel tool be successfully ported into a stand alone program that:
A) more people would be able to use than can use it now
B) would recquire not much more customer technical support than present
C) be ported at a price that I can cover
B and C require a little more explanation, probably. Since very few people with Excel already installed have problems running it, using my tool hasn't resulted in any customer support issues. A standalone program isn't likely to be nearly as trouble free, so the question is will the additional customer base support the additional support cost?
For C, I don't expect you can give me any hard numbers but does this sound more like a one guy working 3 months problem or a 4 guys working 12 months issue?
So is this worth pursuing because it isn't that big a deal or is it so expensive to build and support that the additional sales aren't likely to help much.
Thanks for your input.
Joe Entrepreneur
Thursday, December 11, 2003
You could take the thin-client approace and use excel as a server with some ASP scripts...
It's completely scriptable.
You could even use the spreadsheets you have now.. make some new web forms, use ASP to push the data in, call calculate, then read the data back out to the web page.
mhp
Thursday, December 11, 2003
Has anyone requested a non-excel version? If a bunch have, perhaps you should port it. If no one has, you should try to figure out if anyone wants it.
_ #137
Thursday, December 11, 2003
If you consider Mac users to be a large potential customer base you might want to look into RealBasic. I imagine you could port the application to RealBasic relatively quickly - I've taken VBA code and moved it to RealBasic with no outstanding problems. RealBasic compiles native code for Windows and Macintosh.
Lou
Thursday, December 11, 2003
You might want to check out Developer Express' Express Spreadsheet product: http://www.devexpress.com/products/vcl/product.asp?ProdID=28
Or there is an ActiveX control made by a company called "Formula One" that has a high degree of Excel compatibility. http://www.reportingengines.com/products/activex/overview.jsp
If either of those products is "excel-compatible" enough you could easily wrap a program around them that would be distributable without the customer having to have Excel. The Express Spreadsheet product could be used only with Borland tools (i.e., Delphi, C++ Builder, Kylix) while Formula One could be used anywhere an ActiveX control worked (and there are versions of it that work with Java also, I think).
Herbert Sitz
Thursday, December 11, 2003
The main problem with reporting is the report's visual format. If you are dealing with pre-written VBA code, it wouldn't take long to port into another language, such as C/Visual Basic/Java. But the real problem is how you want the final report to appear.
Excel is a versatile reporting tool for visual formatting. There are few reporting packages out there that won't break your bank that have the visual formatting capabilities that Excel has built in. However, if you are not looking for visually complex reports, you should be able to pick up a package that fits your needs fairly easily. I'm sure this board can recommend quite a few embedded components that would take care of this for you. After that, rewriting the report is a matter of a few weeks, since you have most of the logic written. Then you just need to decide on the complexity of the visual interface, installation, and testing.
Dustin Alexander
Thursday, December 11, 2003
You can tell excel to make graphs and then save them as jpg's all through asp, and have your web server serve up the jpg's that excel just made. So you can even use excel as the visual display.
mhp
Thursday, December 11, 2003
Perhaps an effective compromise would be to make an OpenOffice[1] version available.
OpenOffice's spreadsheet has almost all of the features of excel, plus a very VBA like macro language.
You could provide OpenOffice with your worksheets to users who do not have Excel already.
Of course you would have to consider the cost of developing the sheets on two platforms, but you would get cross platform.
[1] http://www.openoffice.org
Ged Byrne
Thursday, December 11, 2003
The question is what does the program do, what use of graphics and other things peculiar to Excel does it make?
If the data manipulation is all in code then I would have thought the runtime version of Access would do the trick. However if it uses a lot of graphs, or a lot of Excel's built-in calculation functions, then that would not be practical.
However I would not think of porting it to anyting else but Access, since the above mentioned problems will still be there.
Stephen Jones
Thursday, December 11, 2003
Joe Entrepreneur, the port you describe would have many non-obvious issues to contend with and would be a much bigger task than it seems at first.
As Dustin points out, a lot of the display and calculating that Excel does, automatically and reliably, is non-trivial. Replicating it is not hard in itself, but it's a job that expands very fast. The issues are in working out how to replicate and how much to ignore, and also in ensuring the perfect stability that Excel provides.
Your Excel users would be intolerant of the many glitches that could arise.
If you tried to get past the above issues by using a third party control, you might find the same problems. Alternatively, if it was not done well, it might introduced lots of compatibility problems.
You could start the project as a 1-man 3-month gig on an experimental level, while not committing to ditching your existing product. You would want another three months for testing and reliability. The results at that stage would depend on the Windows expertise of the developer.
Must be a Manager
Thursday, December 11, 2003
Thanks to all who have replied so far.
The output actualy doesn't require any graphing or visual presentation- just four sheets of numbers which the user must be able to print with minimal formatting.
The logic is also very simple, no built in functions other than depreciation, which is a basic formula and can be replicated with standard math.
There would be no problem in providing the Excel version as well as the new version, and leaving the choice up to the end user if they had Excel available, but that might cause some confusion.
Hmmm... I guess I am still not much closer to the answer, other than as I suspected it is a fairly non-trivial task with a variety of ways it can go wrong. Sounds like a pretty standard project, I guess!
Joe Entrepreneur
Thursday, December 11, 2003
From what you say this is a prime candidate for producing a stand alone Access database.
Slam all the math into calculated fields in a query.
Stephen Jones
Thursday, December 11, 2003
Two things to consider.
1) Do you want to market this to customers who can't or won't buy Excel? Chances are your low support costs are influenced by the fact that your customers are already spreadsheet literate.
2) Is a spreadsheet the best tool for the job? It can be a good data entry mechanism. If so you could make the product a lot less usable by forcing it into a less well suited user interface.
If you still want to rewrite it, keep you hand on your checkbook; this could be a real money hole for you.
Tom Hathaway
Thursday, December 11, 2003
why not do it through COM in some language and give the user a installer.
Tom Vu
Thursday, December 11, 2003
Email me privately through this BBS by clicking on my name below. I port apps to Windows and develop original Windows applications as a main business focus.
Shrinkwrap Developer
Thursday, December 11, 2003
What did this program do? I would recommend a web-based application that you sell as a service.
Dwilliams
Thursday, December 11, 2003
Ugh, I shudder every time I hear someone suggest Access. :)
If you make this a web-based system using PHP and database of your choosing (Interbase 6 is free and/or open source, IIRC), you'll be able to output reports into Word, Excel, HTML, XML, plain text, and I'm told even PDF.
It's saved us a huge hassle, as we have different reporting requirements for one PHP-based system, and have to have text, Word, and excel, reports almost weekly, and XML "data dump" daily.
The length of time for this kind of thing depends on you, of course, but the guy who wrote our initial system got it pretty thoroughly developed in 4 months, and he didn't know any PHP or database concepts before he started. It was pretty easy for him to learn on the fly.
van pelt
Thursday, December 11, 2003
I recall using, years ago, a program that compiled an Excel worksheet into a Windows .exe file. So the job you want to do would take an hour. I googled for it, and can't find that program. But here are three similar ones, which I identified by Google but haven't used:
http://www.knowledgedynamics.com
http://www.exceleverywhere.com
http://www.bized.ac.uk/virtual/vla/autopublisher/
Harvey Motulsky
Friday, December 12, 2003
---"Ugh, I shudder every time I hear someone suggest Access. :)"-----
Have you seen the doctor about it?
Stephen Jones
Friday, December 12, 2003
Harvey's comment about "spreadsheet compilers" reminded me of one that's been around seemingly forever: Baler, or now, Visual Baler:
http://the-ciba.com/vbaler/index.html
If your Excel spreadsheet can be translated into something that works with Visual Baler, then generating the Windows app, as Harvey said, may take just an hour.
I haven't heard anything about Visual Baler recently, but I remember when its predecessor got good press ten or more years ago.
Herbert Sitz
Friday, December 12, 2003
I shudder when someone suggests a OS SQL database instead of MS Access.
For things where you barely need a database and you're on Windows, using MDB files with the JET engine is extremely convienent. Perhaps MS Access itself isn't the answer, but VB/Delphi or some other language where it's easy to work with COM and and MDB file is a great tool.
Now just compiling the database itself into an EXE sounds like a better solution altogether...
pdq
Friday, December 12, 2003
mph: You can tell excel to make graphs and then save them as jpg's all through asp...
Ah, so you're the one who does that.
The rules is - if it's a line drawing (especially with few colours), use .GIF. If it's a photo, use .JPEG.
Saving charts as .jpegs makes the lines go all fuzzy. People keep doing that to circuit diagrams as well, it's really annoying, so stop it
AJS
Saturday, December 13, 2003
 Recent Topics
Fog Creek Home
| 
