Feedback by UserVoice

Kenneth Barber

My feedback

  1. 2 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Kenneth Barber supported this idea  · 
  2. 244 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Hi folks,

    Thanks for your passion around this. We’ve been discussing this item off and on for some time now and we’d love to get your input.

    The reason we’ve resisted this is because the R runtime & various packages (and updating their versions) aren’t straightforward for other users to install. This limits sharing such queries across a workgroup.

    What do you think?

    For others reading this that’d like us to prioritize this work, please be sure to add your vote since we’re prioritizing our backlog based on these.

    thanks

    Ashvini Sharma
    Lead Program Manager
    Excel

    Kenneth Barber supported this idea  · 
  3. 9 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Kenneth Barber supported this idea  · 
  4. 47 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Kenneth Barber supported this idea  · 
  5. 4 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  6. 1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Excel for Windows (Desktop Application) » Editing  ·  Flag idea as inappropriate…  ·  Admin →
    Kenneth Barber shared this idea  · 
  7. 1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Kenneth Barber shared this idea  · 
  8. 1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Kenneth Barber shared this idea  · 
  9. 1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Kenneth Barber shared this idea  · 
  10. 40 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Kenneth Barber supported this idea  · 
  11. 30 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Kenneth Barber supported this idea  · 
  12. 1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Kenneth Barber shared this idea  · 
  13. 3 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Kenneth Barber commented  · 

    In your HLOOKUP formula, change {1,2} to {1;2}. Your array constant needs to match the orientation of your ranges.

    Also, if you use INDEX($A$1:$D$1,MATCH(J2,$A$9:$D$9,0)) instead, you avoid the problem entirely. Soon, you'll be able to use XLOOKUP(J2,$A$9:$D$9,$A$1:$D$1).

  14. 3 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Kenneth Barber commented  · 

    In response to The Thinker 1958, thank you for the clarification. I misinterpreted "enter the $ on the range" as being an instruction for the reader, not the actual suggestion.

    In response to Roy, I think that you are reading too much into what I said.

    As for the suggestion, I'm actually OK with it. In fact, here is a spin-off suggestion that I just posted:
    https://excel.uservoice.com/forums/304921-excel-for-windows-desktop-application/suggestions/38843821-for-2d-ranges-specified-by-selection-use-absolute

    However, I should mention that the "A1:A9" style of reference is best avoided outside of quick-and-dirty calculations. If all of your data is stored in tables (available from the "Format as Table" on the Home tab), then your formulas will look like this:
    XLOOKUP([@[Customer Name]],Customer[Name],Customer[Age])
    rather than this:
    XLOOKUP(A5,$D$1:$D$80,$G$1:$G$80)

    Not only is the former formula more readable, but the column references don't change as the formula is dragged down (i.e. the problem in the suggestion is avoided), and the column references grow as the lookup table grows.

    Kenneth Barber commented  · 

    This sounds more like an observation than a suggestion.

  15. 1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Kenneth Barber shared this idea  · 
  16. 1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Kenneth Barber commented  · 

    I agree with Roy's 1st sentence. Fortunately for Pam, if you really want to see a formula, you can forcefully unprotect the sheet with this free add-in:
    https://www.spreadsheet1.com/password-protection-remover-free-office-excel-add-in.html

    Since all password protection in Excel can easily be broken, companies are best off removing sensitive information before sharing spreadsheets rather than relying on the password to keep people out. Unfortunately, not everyone knows this, and I have encountered a case where a company relied on the password protection for a public-facing spreadsheet. They have since switched to sharing PDFs with the public instead.

    The password protection in Excel is probably purposely weak so that people can unprotect a critical spreadsheet if they really need to, especially if the developer left the company or forgot the password. This saves Microsoft quite a few angry and frantic tech support calls from users insisting that "there must be a way" to get into the spreadsheet.

  17. 2 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Kenneth Barber supported this idea  · 
  18. 3 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Kenneth Barber commented  · 

    I forgot to mention another problem that I have with introducing date literals: they represent hard-coded values. It would be better to keep the dates in separate cells, label them, and then reference them in formulas.

    In response to Roy, saying that Excel can store date literals however it likes and display them in a default format is a long way of saying that dates need to be their own data type, treated differently from other numbers. I agree with that idea, but for different reasons. See my suggestion below:
    https://excel.uservoice.com/forums/304921-excel-for-windows-desktop-application/suggestions/38778028-add-64-bit-unix-time-as-a-data-type

    Kenneth Barber commented  · 

    The problem with using dates in strings is that you are depending on some sort of setting, which is not saved in the spreadsheet, for the string to be interpreted correctly as a date. This becomes a problem when the spreadsheet is shared, since not everyone will have the same settings set in Excel or in Windows, and different people will get different results for, say, "01-02-03". DATE avoids these issues because it forces the year, month, and day into a specific spot. I view DATE as the solution, not the workaround.

    Also, if we really want to introduce dates as text in SUMIFS, you could simplify ">="&"1/1/2015"to ">=1/1/2015".

    Kenneth Barber commented  · 

    The problem with dates is that there are so many ways to represent them. "Jan 15, 2015" isn't so bad, but no one types that either. Everyone likes their "12/09/05" or "12-9-5" format, which is of course the one that no one agrees on, and each region will argue that it's "obviously" yy-mm-dd, or dd-mm-yy, or mm-dd-yy, or whatever. Then there's "Jan-02". January 2 of this year or January 1 of 2002? You get the idea.

    The least debatable and cleanest date representation is probably the DATE function. If a user is advanced enough to be using VLOOKUP, they can surely learn DATE. If you insist on some other format, try DATEVALUE, which converts your string to a date and is much clearer than --, albeit a bit longer.

    Another thing to keep in mind is that, usually, the dates that we need are in other cells anyways, so just reference them. Hopefully you're not asking users to enter data into formulas directly. Have a data entry cell.

    BTW, your SUMPRODUCT formula uses an obsolete technique. They introduced SUMIFS a while back, so now you can just go SUMIFS(B2:B100,A2:A100,">="&DATE(2015,1,1),A2:A100,"<="&DATE(2015,12,31)). Alternatively, give yourself a "year" helper column and just use regular SUMIF over the year.

  19. 2 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Kenneth Barber commented  · 
    Kenneth Barber shared this idea  · 
  20. 15 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

← Previous 1 3 4 5 36 37

Feedback and Knowledge Base