The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniFocus > OmniFocus for iPad
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
Moving text input elements = bad Thread Tools Search this Thread Display Modes
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.
 
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.
 
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. :-)
 
Quote:
Originally Posted by Brian View Post
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?
 
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.
 
Quote:
Originally Posted by crut View Post
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...
 
Quote:
Originally Posted by Brian View Post
We experimented with that, but it looks off-balance when the keyboard isn't visible. Tons of empty space beneath the editor...
I, for one, wouldn't mind it looking odd. I can't tell you how many times I put in a context and went to hit project only to have it move and pick context again. Very frustrating.
 
Quote:
Originally Posted by jjlucsy View Post
I, for one, wouldn't mind it looking odd. I can't tell you how many times I put in a context and went to hit project only to have it move and pick context again. Very frustrating.
I'll second that.
 
I also find the bouncing window to be annoying. As for the off-balance argument, the normal position of the window is 9/16" from the top of the screen. When the keyboard is visible, the gap between the bottom of the window (after it moves to the top) and the top of the keyboard is a little more than 6/16". That means that if you moved the window up a mere 3/16", there wouldn't be a need to move it when the keyboard became visible.

Well, perhaps that looks off-balance too, so here's another idea. Extend the height of the window that extra 6/16" so it fits precisely between the top and the keyboard without any gaps.

The taller window may not look so off-balance when the keyboard is not visible. An added benefit is that there is a little more room for additional data. If for nothing else, by my reckoning, that would make three more lines visible in the Notes field.

Also, that extra length is almost the same height as the tabs on the right side of the window (Info, Dates, etc.). So you could create a fifth tab if you thought you could use one.

I don't have any suggestions for additional data (though I would like to see the creation and completion dates somewhere), just trying to think of ideas to prevent the need to have the widow moving around.

P.S., I also mailed this to the Ninjas
 
Quote:
Originally Posted by brt View Post
That means that if you moved the window up a mere 3/16", there wouldn't be a need to move it when the keyboard became visible.
Keep in mind that not all keyboards are the same height (different languages have different keyboards), and we aren't currently aware of API to find out how tall the keyboard is before it appears.

We just say "show the keyboard, please", and once Cocoa Touch is done with the animation, then we can ask it how tall it is.
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
Super simple text only input for iPhone app gshankar OmniFocus for iPhone 6 2011-07-18 02:04 PM
Disconnect elements trinix OmniGraffle General 0 2011-06-04 01:03 AM
Moving target tail indent when text wraps RFBriggs OmniOutliner 3 for Mac 0 2010-07-27 01:23 PM
Elements in OG that aren't scriptable? browniejr OmniGraffle Extras 0 2009-09-19 09:32 AM
Aqua Elements? Flounder OmniWeb Feature Requests 4 2007-05-29 01:17 PM


All times are GMT -8. The time now is 06:20 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.