[DigiChaos]

I just purchased OmniFocus for the iPad yesterday. So far I am really enjoying the application.

I think there is one important thing I would change:
When creating a new item the new item starts in the center of the screen and then moves up to make room for the keyboard. So far so good...
Then, if you choose a context and then goto choose a project the New Item window moves back down but the keyboard comes back up.

I would think this would be a bug... but in the general scheme of things its terrible to move text entry fields while I am trying to type. This slows down data entry for sure.

[whpalmer4]

Definitely an annoying behavior, use Contact Omni (under the gear menu) to add your voice to the chorus to encourage them to fix it ASAP.

[Brian]

I'm not a fan of this, either, but in our defense, some of the keyboard-related stuff is a little bit trickier than it appears. :-)

Standard "I'm not an engineer, I'm paraphrasing conversations I've had with them about this, if it's wrong it's my fault" disclaimers apply from here on out...

We don't have direct control over whether the keyboard is visible or not; we put focus on something that accepts keyboard input, and the frameworks take care of showing/hiding the keyboard.

When the popover for picking a context/project disappears, there's no keyboard focus, so the keyboard animates away until you bring another popover up.

One thing we tried was putting the text cursor back in the Title field if you'd edited that before setting those fields, but a) that doesn't solve every case and b) it sometimes causes the text to flicker, which is just trading one form of bad for another. :-)

In any case, this issue falls into the "things we knowingly shipped without really being fans of" category. Stopping this from happening is on our radar screen, but if we already knew how to avoid it, we would have. :-)

[hypotyposis]

Originally Posted by Brian

I'm not a fan of this, either, but in our defense, some of the keyboard-related stuff is a little bit trickier than it appears. :-)

Standard "I'm not an engineer, I'm paraphrasing conversations I've had with them about this, if it's wrong it's my fault" disclaimers apply from here on out...

We don't have direct control over whether the keyboard is visible or not; we put focus on something that accepts keyboard input, and the frameworks take care of showing/hiding the keyboard.

When the popover for picking a context/project disappears, there's no keyboard focus, so the keyboard animates away until you bring another popover up.

One thing we tried was putting the text cursor back in the Title field if you'd edited that before setting those fields, but a) that doesn't solve every case and b) it sometimes causes the text to flicker, which is just trading one form of bad for another. :-)

In any case, this issue falls into the "things we knowingly shipped without really being fans of" category. Stopping this from happening is on our radar screen, but if we already knew how to avoid it, we would have. :-)

I'm assuming there's no way to click directly "out of focus" into the next one.
How about [return] moves you to the next focus? This might work at least for context>project in quick entry?

[crut]

I would perhaps suggest that simply having the entry window fixed in the top portion of the screen?

Then there is no need to move it.

[Brian]

Originally Posted by crut

I would perhaps suggest that simply having the entry window fixed in the top portion of the screen?

We experimented with that, but it looks off-balance when the keyboard isn't visible. Tons of empty space beneath the editor...

[doodiebrad]

Originally Posted by Brian

I'm not a fan of this, either, but in our defense, some of the keyboard-related stuff is a little bit trickier than it appears. :-)

Standard "I'm not an engineer, I'm paraphrasing conversations I've had with them about this, if it's wrong it's my fault" disclaimers apply from here on out...

We don't have direct control over whether the keyboard is visible or not; we put focus on something that accepts keyboard input, and the frameworks take care of showing/hiding the keyboard.

When the popover for picking a context/project disappears, there's no keyboard focus, so the keyboard animates away until you bring another popover up.

One thing we tried was putting the text cursor back in the Title field if you'd edited that before setting those fields, but a) that doesn't solve every case and b) it sometimes causes the text to flicker, which is just trading one form of bad for another. :-)

In any case, this issue falls into the "things we knowingly shipped without really being fans of" category. Stopping this from happening is on our radar screen, but if we already knew how to avoid it, we would have. :-)

Then it needs to be rebuilt. Or it shouldn't have been built that way.

[doodiebrad]

Originally Posted by DigiChaos

I just purchased OmniFocus for the iPad yesterday. So far I am really enjoying the application.

I think there is one important thing I would change:
When creating a new item the new item starts in the center of the screen and then moves up to make room for the keyboard. So far so good...
Then, if you choose a context and then goto choose a project the New Item window moves back down but the keyboard comes back up.

I would think this would be a bug... but in the general scheme of things its terrible to move text entry fields while I am trying to type. This slows down data entry for sure.

OMG, I 100% agree! I thought I was the only one who found this super annoying.