New blog on Excel ’12’


David Gainer has started a blog discussing the next version of Excel. David is the GPM of the Excel team, and this should be a great blog for those of you interested in Excel. http://blogs.msdn.com/excel


In David’s first post, he talks about an old limitation in Excel that is being increased. Because of the move to the new file formats, Excel is now able to increase the limit on the number of rows & columns that can exist in a spreadsheet. While the goals and reasons for moving to the new format weren’t related to functionality like this, by moving to the new XML formats a whole new world of possibilities opened for us. Dave will discuss in future posts some of the other limitations that are changing. Here’s a blurb from David’s first post:



Probably the most common question the Excel team gets from our customers is “when are you going to add more rows/more columns/more rows and more columns”.  There are many different scenarios behind these requests.  Some customers want to be able to analyze more data than Excel has rows, some customers want to track more daily information than Excel has columns, and other customers want to perform matrix math on large matrices of thousands of elements.  There are plenty of other scenarios too.  Well, the answer to the question is “in Excel 12.”  Specifically, the Excel 12 grid will be 1,048,576 rows by 16,384 columns.  That’s 1,500% more rows and 6,300% more columns than in Excel 2003, and for those of you that are curious, columns now end at XFD instead of IV. 


This is an exciting feature for us, because it is a feature that helps a very broad range of our customers, and we are looking forward to seeing what folks create with a bigger grid.


Of course, rows and columns aren’t the only things customers have been asking for more of.  Next time, I will review all of the other places where Excel 12 gives you “more”.


-Brian

Comments (17)

  1. anon says:

    So you are breaking Excel forever now. Older versions won’t be able to read the new file format with full-fidelity. That contradicts what you said a couple of months ago.

    great job!

  2. BrianJones says:

    Anon, in every version new features are introduced that may not work in prior versions. If that weren’t the case, there would be no innovation.

    Just to be absolutely clear here, older versions can absolutely read the files as long as there aren’t more rows & columns than that version supports. But if you happen to use this new added capability, then yes, that won’t be readable. We’ve actually done a ton of work to report to people if they are using something that might not work in a previous version so if that’s a concern people can avoid it.

    What are you suggesting exactly? That we don’t improve the product based on what customers are requesting?

    -Brian

  3. Stefano Colasanti says:

    Great news!

    Thanks a lot Brian

    Stefano

  4. anon says:

    "What are you suggesting exactly? That we don’t improve the product based on what customers are requesting?"

    Of course customers have been asking for this for moren than a decade, just like they have been asking to be able to store unlimited content in a single cell. And that makes so much sense to be able to store 64k or more of content in a single cell right?

    There is may be a problem. May be it’s actually about giving proper tools to users. In this case pivot tables or other analysis tools help — but users barely know those tools exist –.

    If you are about to break Excel, then make more changes. One of the things you should fix is the color palette. Allow free 32-bit color, not the 1980ish 56 color anymore. Allow to add objects within cells, like pictures. Also, increase the size of range definition string limits (more than 32K). Increase just about anything.

  5. anon says:

    Since you are setting yourself for a big big big $migration$ nightmare, please don’t call this Excel anymore. Call it Excel+ or Excel Vista, or YourNextExcel. But it’s not Excel anymore.

    I expect more breaking changes like this anyway. What is the dependency with Avalon graphics by the way? There is some blogs out there saying that Office 12 requires WinFX. And is an opportunity for shapes to be described and rendered with Avalon.

    Ironically enough this announcement comes a few days after Massachussetts showed you the finger. I am pretty sure that you didn’t want to announce that you would break Excel when Massachussets was still discussing whether or not MS Excel file formats would last two decades or more.

    You’re showing your true intentions…

  6. Step says:

    anon, you don’t seem to be adding any useful information to this. What exactly is going to break for you with this new change to Excel? And while you make a few suggestions, you assume that increasing the row size or column size is equivalent to "raise just about everything", whether or not it’s even similar type of change (which it’s not).

    And please, lay off the attacks on Bryan – he’s doing his best to let us know what’s happening in the new version. You may hate Microsoft, but spewing that here doesn’t get anybody anywhere.

  7. Charlie Ellis says:

    Anon,

    Check out Dave’s second post for some of the other limits that Excel 12 rolls back.

    http://blogs.msdn.com/excel/archive/2005/09/26/474258.aspx

    Charlie

  8. Gene says:

    Brian-

    Thanks for the link to David’s blog,and for your earlier link to Jensen’s UI blog. How about getting one of PowerPoint team to start as well? I know that they aren’t on the campus, but surely you can apply some pressure. Shawn V. perhaps?

  9. BrianJones says:

    Hey Gene, I’ll talk to them and see what we can get. 🙂

  10. Etoile says:

    At last, any one who has ever modelled mortgage backed securities on a monthly basis has been frustrated by the 256 columns (22 years). WE have been crying out for at least 50 years or 600 columns.

    Forget about using rows, looks ugly and time series should always run left to right.

  11. Eric DeFazio says:

    Brian,

    Thanks again for providing such detailed information about these new file formats. I’ve posted a list on your blog earlier about what I think (Selfish me) would be an improvement on these formats as apposed to the original (SpredsheetML) formats. Thanks for taking the time look into those things.

    Currently I’m developing an solution to create Spreadsheet documents in multiple file formats (BIFF8, SpreadsheetML, Office Web Components, Open Document Format, Office 12), and while researching these formats, and I came across something that I believe could be one of the coolest things with respect to Office Web Components, and I was wondering if you could humor me and think about how this may be applied with respect to the new file formats within Excel 12.

    I’m currently reading Dave Stearns’ book "Programming Microsoft Office 2000 Web Components", and he’s got a section concerning "Property Binding and Real-Time Data" (p 33). Basically the Spreadsheet and Chart Components in OWC allows things to be bound to "properties", (example: An OWC Chart Component is bound to cells within an OWC Spreadsheet Component, and one of the cells within the Spreadsheet is bound to a select box within it’s containing HTML page… if the value of the SelectBox changes, then the cell’s value changes, then the chart updates itself…)

    this got me thinking….

    What if all of the raw "embedded" cell data contained in a spreadsheet is just data saved as separate XML document(s)…(Let’s call this an XMLDataDocument) The XMLDataDocument does not have any real notion of it being within a spreadsheet, it’s just Data

    <Data>

    <Range key="r1">

    <Field id="f1" type="xsd:string">Time</Field>

    <Field id=”f2” type="xsd:number">12.022</Field>

    </Range>

    </Data>

    Cells defined within a spreadsheet "reference" the data within the XMLDataDocument by using a "DataSource" reference…

    <DataSource name="embedded1">

    <type>XMLDocument</type>

    <location>data1.xml</location>

    <schema>someShema.xsd</schema>

    </DataSource>

    Cells could be defined similar to this:

    <cell><data source="embedded1" id="r1f1"></cell>

    Likewise, Cells could be bound to more dynamic data sources…

    <DataSource name="dynamic1">

    <type>URL</type>

    <location>http://someaddress.com/somedata</location&gt;

    <schema> http://someaddress.com/somedata.xsd</schema&gt;

    <refresh-interval>10sec</refresh-interval>

    </DataSource>

    <cell><data source="dynamic1" id="r1f1"></cell>

    When all is said and done, what a spreadsheet “is” is a “harness” for data.

    I realize these concepts are not really “new ideas” (Excel has had the ability of integrating real time data for a while). What I’m proposing is that these concepts be integrated consistently as the underlying standard for how the files are formatted. (i.e. ALL cells which contain data values be defined to use a datasource…

    So I guess the next “logical” question comes to mind is “Why?” here are a few reasons I could come up with off the top of my head:

    1) Great separation between the underlying data and the actual “view” of the data within the spreadsheet document. (this is one of my big gripes with the ODF, they seem to mix features, data, and “view” properties, which makes programmatic solutions “messy”.)

    2) Consistency… all cells require a data source, whether the data is remote or local is “changeable”. This is great for “templating” and “snapshotting”…Maybe I want to take a snapshot of what the data looks like now, save a document and refer to this document later… Maybe whenever I open a document I want it to represent the “current” state of the data.

    3) flexibility … anyone could write a script to “clean” the data, without having to wade through tons of style information, etc.… the fact that the data is being used within a spreadsheet is not imperative, I could theoretically “rip” this data out of the Excel Document file, and throw it into a table in Word … If I want to search the data within many spreadsheets, I can do so… Data is saved “cleanly”, not intermingled with spreadsheet specific information.

    Anyways, just wanted to throw that out there… Most of these ideas were really “lifted” from Dave’s book. I wasn’t able to go to PDC, so hopefully I’ll be able to express some new ideas here that haven’t already been thought of/considered. I think ODF attempted to go a similar route (separate data from view), however, in application the ODF file format seems muddled.

    Cheers,

    Eric

  12. arno says:

    Hello,

    I am wondering if the passwords of Excel 12 will be secure, the content unreadable/encrypted and if the files cannot be cracked anymore.

    So, how secure will files be with:

    – sheet protection passwords

    – vba project passwords?

    Currently, it’s very annoing that I hide and protect sheets, hide and protect my VBA-project and still it takes me only minute to crack the file…

    arno 🙂

  13. Steve says:

    Ref from Etoile "At last, any one who has ever modelled mortgage backed securities on a monthly basis has been frustrated by the 256 columns (22 years). WE have been crying out for at least 50 years or 600 columns"

    Some people view time as left to right, other people view it as infront and behind. Many of my spreadsheets have time going down rather than across and it works fine. But that said breaking the 256 column limit will be great

  14. I teaching auditing at my college and do a fair amount of outside work with the internal and external auditing community. This row increase is the best news that I’ve had for a long time. For years now auditors have used Excel when the auditee’s data set had fewer than 65,536 records and for larger data sets they either used (a) nothing, or (b) specialized audit software (Access, IDEA, ACL). This row increase will promote efficiency in that auditors will be able to analyze large data sets in the format that they are most familiar with.

  15. BrianJones says:

    Hey Mark, thanks for the comments. It’s definitely something we’ve had people request for awhile now. We had been limited by the architecture of the existing binary formats, but now with the move to XML we can increase this limit which is great!

    -Brian

  16. arno says:

    will I ever receive an answer?

    arno

  17. xp says:

    Will ADO be supported in the new version? Please, please say "Yes"!

    Otherwise, I have my work cut out for me…