dominik

(Disclosure: I’m a PM at Google working on the Gemini iPhone app. Would love to hear thoughts / feedback / idea for what you'd like to see next!)

(I'm a PM on the Bard team)

primarily yearly compilations of favorite books I've read, along with a few assorted essays

Hurrah for personal home pages :) https://dominik.net/reviving-ye-olde-personal-home-page.html

Have written up my favorite books I've read each year for the past 6 years, most recent entry: https://dominik.net/favorite-books-read-in-2021.html

Wrote a piece last summer that's much in line with this one :D https://dominik.net/reviving-ye-olde-personal-home-page.html

Partners typically edit bills substantially before sending them out to clients, and I know a partner in my current job spends hours doing this every week for our practice group; I don't think he has much love for the process, so a way of automating it would be amazing, I'm sure.

Reminded me of, all people, Mother Teresa. She started in Calcutta in 1948. People mocked her: What difference do you think taking care of one poor person will make? But that was her focus: One person at a time. "Do small things with great love."

So too in the quite different field of technology startups.

Apple passwords have a max length of 32 characters.

Unfortunately, the change password page doesn't enforce this limit and will blissfully let you think you've changed your password to something that has 50 characters, but actually only stores 32.

Later, when you use a Password Manager that saved the full 50 characters, suddenly your password doesn't work.

Some Apple pages' login password fields cut off automatically at 32, which lets the pasted password work (as you can't paste more than 32), but this is not the case within iTunes itself or on the iPhone.

Solution: Apple needs to limit the new password entry fields on the My Apple ID -> Password and Security page to 32 characters. Or, alternatively, accept and store longer passwords. (as 32 characters is a bit tight if you're using a passphrase)

(And also, is there a possibility that reported reasons are not actual reasons?)

When you search your messages, the buttons to go to the next page of search result are inexplicably only at the top of the results, not at the bottom.

Before I realized this design oversight, I spent a few minutes perplexedly scrolling to the bottom of search results, flabbergasted that those were all the results.

You can imagine my frustration at the design team when I finally realized: Oh, the pagination buttons are at the top...

But for hardware or biotech startups? Licensing patents is oftentimes a startup's business model. And licensing doesn't work if people can use technology without paying (which would be the case with a purely defensive patent).

That said, it does require your entire focus.

The Examiner hasn't even looked at the application yet.

This is a patent application.

It has not been granted. It hasn't even been reviewed by an Examiner yet. All that's happened thus far is that the application has been submitted to the Patent Office and published. That's it.

The filing date (and priority date in this case) is April 8, 2010. i.e. that's the date someone would need to find prior art that reads on the claims of the patent. (Unless Twitter can establish an earlier invention date -- which would likely occur in the course of an actual lawsuit about the patent; e.g. a Git checkin of the first implementation, or a drawing in a notebook with a date on it).

As for the claims, the two independent claims are:

A method claim: 1. A method, comprising: displaying a content area; receiving input associated with a first command, the first command including a request to scroll the content area; and based on the first command, performing a second command, the second command being independent of the first command.

And a device claim: 20. A non-transitory computer-readable medium having computer-executable instructions stored thereon that, when executed by a processor, cause the processor to perform a method, comprising: displaying a scrollable list of content items, the scrollable list of content items including a plurality of discrete content items arranged chronologically; receiving input associated with a scroll command, the input representing touch-based user input; based on the scroll command, displaying a scrollable refresh trigger configured to scroll with the scrollable list of content items; in response to determining that the scrollable refresh trigger is fully displayed, providing an instruction associated with activating the scrollable refresh trigger; in response to determining that the scroll command was completed while the scrollable refresh trigger was fully displayed, refreshing the scrollable list of content items; and in response to determining that the scrollable list of content items has been refreshed, automatically scrolling the scrollable list of content items such that the scrollable refresh trigger is not displayed.