Hi Corey,
Thanks for your feedback.
On May 5, 2011, at 8:15 AM, Corey Ballou wrote:
Your new OAuth authentication handler does a check to determine if the
window has been opened in a new window and triggers a resize.
I'll preface this message by saying that I have a high res monitor at
1920x1600. I currently have handling to center the window. Your new
JavaScript is essentially resizing the window outside of the viewport,
giving no consideration to the end user's window height or current
window position.
Is this something that can be resolved? It's kind of a nuisance. I'll
repost in the tracker.
The auto-resize is not something I'm a massive fan of either, but we
implemented it after the redesign because we found that whilst a lot of OAuth
implementations are using pop-ups of a fixed sized, a great number of them are
also invoking those pop-ups with scrollbars disabled at the window level, which
makes important parts of the interface impossible for users to access.
Alas, though I appreciate that centering the window is aesthetically desirable,
content hidden through disabled scrollbars was a bigger problem, so it's been
patched for now.
I emphasise ‘for now’ because I know and agree that this isn't an ideal
solution. Web content is by its nature of variable length. In this case:
• Additional status messages can be displayed in the content. The
authenticate flow has an extra header message, and users adding their first app
are also given a special greeting message, and offered a link to the help
section to explain what apps are.
• Items on the page, and in the permission list may be changed, shortened,
lengthened or removed outright based on feedback and experience. And, of
course, Twitter will add new features over time, or might redesign the site
again some day.
These are all changes that developers should expect to happen to every web
service, not just Twitter, and should code for defensively. What's more, users
can, will, and do use browser features such as resizing page text based on
their needs, which throws all page size expectations out of the window. Given
all of this, it mystifies me slightly that browsers allow scrollbars to be
disabled at all, but here we are.
I'm keen that we assemble issues like this into a best practices guide. Not
disabling scrollbars, and keeping the address bar (and SSL verification stamps)
visible are important. There's more too, and I'd like to collect the feedback
and experience of developers to help assemble thorough and relevant advice.
(Please write in to the usual address.) (This one.)
My hope and preference is that after documenting these issues and encouraging
their adoption, we can remove the janky resize code and return all pop-up size
and shape related issues entirely to the domain of the app developer.
Thanks,
Ben
--
@benward
--
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group:
http://groups.google.com/group/twitter-development-talk
