I didn't previously own iWork, I just bought Number 2.x at the Mac App Store - that's why mine got wiped out (again, simply moving Numbers 2.x to a different folder before downloading Numbers 3, I'm sure, will preserve it).
On the other hand, I was able to download Pages 3.0 and Keynote 3.0 for free yesterday, even though I only bought Numbers.
So Apple giveth and Apple taketh away :-)
If the file format is compatible between Numbers 2 and 3 and you can work on a given spreadsheet switching between the two, then fair enough. I thought I'd read comments that this was not the case - can anyone confirm either way?
I can't agree that these lost features are better handled in a relational database. These are standard spreadsheet features. Present in Excel also. I don't need to start building relational databases - I'm not performing SQL type queries.
Mavericks was a free upgrade. Are you saying that I should have zero expectations for that also? Whenever any app developer releases a free upgrade to their app shall we accept it if key features are removed - because it was a free upgrade?
I tried what you suggested, growing the table of my previous HLOOKUP/MyTable example - I added a fourth column
so now MyTable is a 3 x 4 table instead of a 3 x 3 table.
I tried the following under both Number 2.x and Number 3. I changed the cell F2 containing the first argument in HLOOKUP from a B to D, to attempt to access the value in the new column, so the formula looks like this:
=HLOOKUP( F2, MyTable, 2 ) < Numbers 2.x>
=HLOOKUP( F2, MyTable::A1:C3, 2 ) <Numbers 3>
In Numbers 2.x:
HLOOKUP returned 80
In Numbers 3.0 (as you would expect, because the second argument of MyTable::A1:C3, didn't change automatically when I expanded the size of the table):
HLOOKUP returned 60 <the last value in the 3 x 3 table>
I had to change the Numbers 3 formula's rows-range second argument to MyTable::A1:D3, to get it to return 80.
No you cannot move the same file back and forth between 2 & 3.
Once you save a file in 3 you cannot open in 2 therefore hopefully you have older
version backed up in time machine or whatever.
As far as expectations, it seems a bit unrealistic to think Apple would be trying to turn Numbers into
an Excel killer- what would be the point?
If someone needs the power of Excel then thats what they should use-
On the other hand- a lightweight easy to use app compatible with the ipad and the iphone
seeems like a good void to fill and I would think Excel would be unable to fill that.....
Finally, defining a "key feature" is a tricky thing to do. Good software (good design in general) should give you what you need not what you think you need.
I just sent feedback hoping they would restore some of the dropped features in the near future. I could be wrong but I think that this is a first step in having a fully unified version of iWork for iOS and OSX. Since I heard they redesinged it from ground up, they probably didn't have enough time to add in all the features, but I think they will be adding them in future updates. I would encourage everyone to send feedback so that they don't forget the features they dropped and add them in future updates. The cool thing I find about this is that if apple actually gets all the dropped features back up, iOS, iCloud Web App for PC, and OSX will be 100% sync compatible with the former glory of Numbers 2.
After attempting my same HLOOKUP test in my post of Oct 23, 2013 9:49 PM, in iCloud for both Mac OS 10.9/Safari and Window 7/Chrome, I am convinced that this HLOOKUP difficulty is simply a bug in Numbers 3.
There is a difference when you do it on iCloud vs Numbers 3:
After you've typed in this much in either Numbers of iCloud
=HLOOKUP( D2, MyTable
here's what the autofill shows:
=HLOOKUP( D2, MyTable:: <notice the extra :: that I didn't type in myself, it's part of the autofill >
In iCloud, on either platform, if I then type a comma, I see this
=HLOOKUP( D2, MyTable, <the :: has been erased, and the formula thingy is ready for the next argument >
On Numbers 3, after you type the comma, NOTHING HAPPENS,
I BELIEVE THIS IS A BUG - in Numbers 3. It's not intentional.
I also believe that if this bug did not exist, then manually growing the table would work in Numbers 3. So for now, typing in the MyTable::A1:C2 is simply a cheap workaround, just to get the HLOOKUP to work in Numbers 3 - but you'd really want just MyTable rather than MyTable::A1:C2, because of the lack-of-growth of the table that sjlawton brought up in an earlier post.)
So I will use the Numbers 3 File -> Provide Numbers Feedback (and, as an aside, SGIII, now that I think about it, I'm pretty sure that lack of Numbers 3 option in the "What version of Numbers are you using" is, in fact, an oversight - or a bug if you want - that Apple also needs to made aware of. I will report both.)
BUG REPORTING STARTING NOW.....
I never said I wanted an Excel killer. I was trying to make the point that I didn't need a relational database as you suggested. I need a spreadsheet with standard spreadsheet functionality. I have what I need in Numbers 2 and won't be upgrading.
It now transpires (see Johnny Hands post below) that any reference function, such as VLOOKUP and HLOOKUP cannot handle extra rows or columns being added to the table that is being referenced, without going to each individual formula that uses these references and amending the function.
Spreadsheets should allow you to add more data without having to edit referencing formulas - surely?
I have two key spreadsheets, both of which I constantly add data to. One makes extensive use of Categories - the other makes extensive use of Lookups. Both spreadsheets would be rendered completely useless to me, if I moved to version 3 (I won't use the term upgrade anymore).
It is my opinion - that any upgrade to an app should not remove features that are commonly used. Lookups and categories are commonly used - you only have to read the comments in this thread and on the App store reviews to see this. You may not see these as key features. Others do.
We are not looking for Excel killers - we are just looking to continue to use our spreadsheets as we were before. I don't think that was an unreasonable expectation of an upgrade - free or not.
I think you and I will just have to agree to disagree about the impact of this upgrade. To you, the loss of these particular features is unimportant. To me, and to others, it is a great loss.
I agree with you about one thing. I have no reason to whinge. I didn't upgrade, so I have lost nothing. My sympathies go to those early adopters who did upgrade and now have lost features, that they use, on their spreadsheets. It must be especially painful to those who bought the original on the App store and cannot go back to the previous version. Remember, most of these people did pay for the app originally.
If you haven't already, see my post of Oct 24, 2013 1:29 AM, where I think I've shown that the Numbers 3 HLOOKUP problem that I first brought up earlier as a missing feature, is just a simple bug, that, when fixed will bring back the standard HLOOKUP functionality we're all used to, and thus the table can grow in the future and will be accomodated.
But, I agree, you should wait until the bugginess is fixed. I wonder how many of the other "what has been lost" items are also, simply bugs, not feature removals.
I believe Apple released Numbers 3, yesterday (Sept. 22, 2013), because they had a deadline that had to be met - for marketing purposes - to make the biggest splash of releasing the entire iWork suite, for free, as part of the event's announcements.
And, BTW, I did write up both the HLOOKUP problem and the feedback form not having a Numbers 3 option for "Which version of Numbers are you using?"
That is good news. Reference functions that couldn't handle expanding tables would have been devestating. Glad to hear they can.
Do you happen to know how well Numbers 3 handles multiple filters? Can it handle the example below?
"Show rows that match any of the following:
Column A is True
Column B is Not Blank"
Numbers 3.0 seems to have decent filters on multiple columns. I'm able to get it to handle your example pretty easily:
There doesn't seem to be a way to filter directly on TRUE/FALSE yet so I multiplied the TRUE/FALSE column by 1 (since under the hood TRUE is 1 and FALSE is 0) and filtered by the calculated column as a number. Not too bad.