Please Offer an Excel Export Option
evanmiller.org
evanmiller.org
I disagree. Information is consumed by people. Data underlies information, and sometimes is mistaken for it. But raw data is absolutely parsed and processed before being consumed by the average audience. Some analytic folk will read raw data, but only to serve a higher level purpose - to answer some question or gain some knowledge.
But in general, data is analyzed and filtered and summarized and visualized before being consumed. This author may just work too close to the data on a day to day basis to realize where the average audience really fits.
If we want to talk about ease of use for the consumer, we need to ask what kind of person downloads datasets from websites.
Not normal people, that's for sure. The target demographic for that is probably 5% researchers and 95% idly curious developers and statisticians.
The researchers can take the time to deal with an XLS format, but why would they want to? The developers and statisticians are doing this in their off time, and are going to want or need (I wouldn't expect a statistician to be able to work with the XLS documentation) an easier format to deal with. So if you give it to them in XLS, they're just going to have to turn it into a CSV immediately before starting to hack up an interpreter for it.
So why not skip the middle man and deliver it in CSV? This author has the situation almost exactly 180 degrees backwards.
To give it to them in JSON is, well, just useless.
Handing your average user a JSON file doesn't "let them decide", it means you've decided that their needs are less important than your holy war. That's fine, and your choice to make as a developer (unless they're paying you), but don't pretend it's in the user's best interest.
I've always assumed that programmers output to CSV because they are too lazy to implement an Excel output function.
Excel files have row limitations, potential file format incompatibilities.
Depending on the language being used, it can be the same level of effort to emit XLS file as a CSV file, so unless we are talking about programmers how don't bother learning how to use output libraries, I suspect CSV is more common for reasons of compatibility.
That's the thing. For 99.99% of users there is no anything. There is only Excel. And dealing with CSV files is headache for them.
It's as if you designed parking garages to accommodate both horses and cars - because someone out there might be coming on a horse.
Noting Excel can open CSV natively (again with the caveats mentioned in the post), my users want a garage not limited to cars, but trucks and bicycles too.
When did he write this? It says Nov 2014 at the top but that doesn't seem accurate.
Then again the WinXP EoL should have changed that, but watch it not have.
As for the article, personally I'd say drop XLS support and go for XLSX. The more that users are aware their version of Excel is no longer supported, the more noise they'll make about wanting upgrades. Plus, it's not limiting, in the sense you can get free tools that open XLSX (LibreOffice, etc...).
I would imagine there'd be XLSX-handling libraries for most mainstream programming languages. I've used XlsxWriter with Python, it's fairly intuitive... https://xlsxwriter.readthedocs.org/
The problem with XLS is that its internal format (called BIFF8) has no official specification. It has been reverse engineered to a great degree, but every implementation I've used outside of actual "excel.exe" has show stopping bugs that you will encounter at some point.
XLSX, on the other hand, has an actual published spec (OOXML). There is plenty of political strife surrounding OOXML, but at least we have a spec we can develop against. It has also been my experience that "simple" XLSX files can be constructed more reliably than their BIFF8 counterparts. Because XLSX files are XML internally, there are a great number of libraries that can be used to construct the required XML structures, while avoiding edge-case errors in composition that are inherent to reverse-engineered binary formats. At a bare minimum, software authors can use something like libxml to construct valid XML, rather than some ad hoc BIFF8 serializer.
FWIW, we use the axlsx gem for our Ruby app, and it hasn't let us down yet. It even supports some pretty eccentric Excel features like data validations.
Deleted comment
Deleted comment
Of course open formats are best, but sometimes they're not a good option.
Like it or not, most of the businesses in the developed world are still using MS and the associated file formats, and will be for quite a while yet.
If you just create a text file and put an old fashioned html table in it and rename it to .xls Excel will complain a little, and then open it, and even respect font tags like <b> and <i>
https://github.com/OfficeDev/Open-XML-SDK
Someone has also created a javascript version of the SDK - http://openxmlsdkjs.codeplex.com/
I work in JSON mostly do wrapped the excellent XLSX library it was very useful https://goo.gl/S7rlFm
Apple has failed to support OpenDocument Spreadsheets, and their XLS importer regularly crashes altogether for the operations people at my office, though maybe it's super stable elsewhere.
XLSX works fine, though (for the features that Numbers supports)
http://msdn.microsoft.com/en-us/library/aa140066%28office.10...
It only describes the data part and doesn't document Excel options such as print settings and filters; if you need them, create a sample in Excel, save it as XML Spreadsheet 2003 and examine the result.
(The 'big' Excel format that is a part of Office Open XML format is also called Spreadsheet ML, but they're different; from what I understand this one is a subset.)
If the first thing the the user is doing is bringing the file into excel and you don't need multiple tables per file what is the difference to the end user other than the file having a csv instead of a xls or xlsx file extension?
the number of times i've opened a csv to find that excel has tried to determine the dates, and decided that the year thats being referred to is 1914 instead of 2014...
I should have been more precise and said if your data isn't using the set of features described in the article there isn't a big difference. Not all data has dates, time durations, percentages, and number formatting.