|
User must be granted access to their data, as the data they feed can also be used by them in a way which our S/W is not using - possible reason might be - New Requirement.
AnupKumarYadav
Delhi,India
|
|
|
|
|
It's your code, you shouldn't be required. If your customer wants import/export capabilities then you should probably provide them. Of course doing so might add considerable development time to your app and for what benefit to you. Example: Word .doc format. I'm sure this is a pretty tough format to export to, however, if Word still reads RTF, then perhaps exporting to that might be reasonable.
|
|
|
|
|
Word reads plain text. 
|
|
|
|
|
True that!
However, if your app were such that the formatting of the data was what made it special--like desktop publishing--sure you could export plain text, but I don't think that would be what the user who wrote a book in it would want. Of course in that instance exporting to PDF would be the key. Plain text would be simple to do from many apps and useless for many others. XML might be a good ticket, but then the importer would need a program to take the XML and put it in whatever format they wanted...I can't see the average user doing that.
|
|
|
|
|
During pre-specification talks I would always suggest that some sort of export facility were in place.
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
|
|
|
|
|
look lets say you are developing an ERP/CRM suite etc... and we all know we require objects like customer, users, employees, vendors etc and these objects produces invoices, sales, gl entries etc.. however in a large enterprise your application will have to live with other applications like Peoplesoft, SAP, Oracle to name a few. that said to be a winner having an open interface to ETL in/out Master Data and transactions is a must, managers do not want users to key data twice also maybe they have a huge data warehouse for other reporting needs and now the customer wants all transaction data ETL into the warehouse.
you should always have an interface (web service, dll, or something) that will accept a denormialized record layout and normialize it to work with your application and also the other way around, along with error handling and record tracking. these features will set your application apart for your competitors.
funny story that relates to this exact topic, a few months back I was tasked with finding an alternative solution to replace a legacy app, so I called in a few vendors to demo their application, I was very impressed with one application and was ready to sign a 7 digit agreement until I asked the vendor if they had an API or source code available to us so that we could customize it and provide interfaces to integrate their application with other applications in the enterprise, the vendor replied to me with "why would you want to change something, our application has everything you require" need less to say we went with a different vendor who worked with us to develop interfaces and customizations, and today it is part of our core business even though we may be utilizing 10% of the application because of having to support legacy apps (for now)
|
|
|
|
|
Regarding your funny story... A few jobs ago, we were looking at a third-party product for a client. We needed it to be able to import data from our system. The salesman said, "Yeah, sure it can!" We bought it. It was handed to me to figure how to perform the import and automate it. After struggling for a while, I asked their tech support. They said that the import routine was only intended for internal testing and shouldn't be used in production.  Eventually, of course, I got it working, but it required that the database be wiped and completely reloaded each time we had a change. 
I'd prefer that the salesman had said that it couldn't be done.
|
|
|
|
|
I export my data to SQL Server -- you can read it from there. 
|
|
|
|
|
If the customer needs it, then yes.
If the customer don't need it, then no.
Is it a good thing? Yes.
If you do an app on your own, then choosing a solution like that is great.
If you have someone evaluating the customer need, then you're not the one to choose.
|
|
|
|
|
Simon Dufour wrote: If you do an app on your own, then choosing a solution like that is great.
If you have someone evaluating the customer need, then you're not the one to choose.
Exactly.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek dissappointment. If you are searching for perfection in yourself, then you seek failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Which customer do you mean? The one you talked to yesterday or the one you will talk to tomorrow?
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
You're right. Each cases are different. If you don't know who'll use your system in the future, you have to predict their needs.. or at least, prepare for them. If it's your job, then fine! If it's not, then just make sure your code has an high enough cohesion to make changes easy and a low enough coupling to make some parts easy to replace or extend.
There's no magic. All I know is that the client is the one to decide what he needs. If you feel it's important for them, then sell them the idea.
Perhaps we should avoid to talk about "client" since a small part of us actually work for other kinds of apps that don't necessary have a known client.
Anyhow, if you ever have the choice to do it or not, the answer is pretty simple.
|
|
|
|
|
I'm going to agree with him, but I'd like to translate it a bit differently. It's not the customer, but the one who is responsible for the project that makes this decision. That's often a representative of the customer, for larger projects - or a senior developer from your own company if there's an anonymous product with a large userbase.
Point is that we mostly do what money dictates - programmers in a group, developers with a boss, hired employees can rarely make a strategical decision like this. Influence it, yes. Not make it.
I personally do not like the vendor-lock in that lots of applications and platforms bring. If it's my data, then I wanna be able to carry it around - but that's me talking as a user.
More people will be inclined to use your product if they can easily import their old data. That implies;
- You could get more users by being able to import a lot
- You'd loose less users if they can not export their data
I'm not judging whether the latter is a good idea or not.
I are Troll 
|
|
|
|
|
We should not be required to, but we should anyways.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
We should develop our own standards and force everyone else to adopt our standards!
Sincerely,
Bill Gates
|
|
|
|
|
And you wonder why people call Microsoft a monopoly.
|
|
|
|
|
yes you should offer a web service and make all data public.
|
|
|
|
|
|
One can look at it as as the developers vote of confidence (or lack thereof) in their work:
If you're too afraid to allow your data to be exported, well maybe it's because you know the users will find something better.
My wife has to use some of that sort of turd-ware: the only way she can get anything like her work back is cut-and-paste from the screen. The application is amazingly non-intuitive, the site where the application resides will shut down for 'maintenance' at odd hours, and even making changes is an absurd route. Users universally hate it and the general consensus is that someone got a fine kick-back when they selected the junk.
So why not change? - because, as noted above, there is no piratical export mechanism. Eventually they will drop it - but the fees will be collected for a much longer time.
So - if you're deathly afraid your product can be replace by something better and cheaper, be sure to make export difficult or impossible.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek dissappointment. If you are searching for perfection in yourself, then you seek failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
yes - let's publish salaries - or decrypted vouchers for air time ...
Yeee
|
|
|
|
|
? ? ? ? ?
What, exactly, were you drinking when you came up with that answer ? ? ?
? ? ? ? ?
Or, perhaps I hit a bit close to home!
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek dissappointment. If you are searching for perfection in yourself, then you seek failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
If you work for a government agency you may be subject to a 'Freedom of Information Act' (FOIA) in which case it makes sense to plan on/program for exports from the start of a project (where time/resources allows).
IE: In Richmond VA a local newspaper obtained via a FOIA request the name, position and the wages of every state employee and 'published' this info on a searchable website (which may be what the respondent above was b*tchin' about).
GoodTime Charlie, VA
|
|
|
|
|
OK - for the moment, let's presume that your scenario was what he was referring to.
I still fail to see the relevance: The FOIA would exist, anyway, and they would have been compelled to give them the data, anyway. All that would have changed (maybe) is that they state had an easy way to give the required data (which they could have printed to paper if they wished, and still complied with the law).
The issue, as one would most commonly interpret it, is that one has an application which contains arbitrary data that is the property of the application owner (and possibly, the users). Should their desired use of their own property be inhibited or eased? Not having access to ones own property (and paying for the privilege) seems wrong to me.
A rather loose analogy would be that of a bank storing your deposits in 'proprietary' format so that you can't deposit them in another bank. Is a person's/business' data anything less than money?
Transferring the data will take time - and without a proper export mechanism, plenty of it. That unnecessary consumption of one's time (==life) is a very high cost, indeed!
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek dissappointment. If you are searching for perfection in yourself, then you seek failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Your points are well taken.
My point was: If you know (or have good reason to suspect) that "your data" must be released in some form, planning for that release ahead of time can cut tremendously your expense to release the data (time, labor and/or materials).
FOIA was just an example of how you might know/suspect that data may have to be released.
And, of course, my choice of example of what was released was simply an attempt to offer a possible reason that the other respondent was so ticked ... ie: lots of us state workers in VA were really upset by the fact that we do not have the typical privacy one would expect from ones employer and a number of us are concerned about this info being released making ID theft easier, etc.
GoodTime Charlie, VA
|
|
|
|
|
I'm not totally separated from your situation of public availability of my personal information: I worked for US Dept of Energy for 11 years.
GoodTime Charlie, VA wrote: lots of us state workers in VA were really upset by the fact that we do not have the typical privacy one would expect from ones employer and a number of us are concerned about this info being released making ID theft easier, etc
It was long ago, but I went into public service knowing there are various trade-offs (lower pay, for one!). Another was being fingerprinted, and they did send investigators out to question neighbors about me. That's some serious intrusion. I don't know the extent of the info that VA released, but it shouldn't contain anything to substantially increase identity theft. Were I a betting man, I'd bet most employees have revealed more on FaceBook, and other such sites (none of which I belong to, neither do I tweet). Admittedly, in this latter sense, they did so of their own free will and accord. Some might even use gmail - which is, for someone concerned with privacy, insanity at its best . . . I don't even like send mail to gmail addresses.
This is more of a misery-loves-company note: In NY, the Dept of Motor Vehicles sells your Driver's License and Vehicle Registration information. You can opt-out of a lot of it - if you can remember to at the time and can find the opt-out check-box.
Maybe I can summarize my philosophy as simply the Golden Rule, as applied to software.*
* Perhaps why I never became wealthy
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek dissappointment. If you are searching for perfection in yourself, then you seek failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
