Tag: gui blooper

iPhones and the need for responsiveness

There’s a pattern I fall for, about once a day, while browsing the web on the iPhone. It goes something like this: follow a link to a new page as the page starts filling in, read the first screenful do the “scroll up” gesture to make more content visible watch as the iPhone randomly does … Continue reading “iPhones and the need for responsiveness”

There’s a pattern I fall for, about once a day, while browsing the web on the iPhone. It goes something like this:

  1. follow a link to a new page
  2. as the page starts filling in, read the first screenful
  3. do the “scroll up” gesture to make more content visible
  4. watch as the iPhone randomly does one of three things:
    • ignores the gesture completely.
    • waits about a second and then scrolls a few pixels
    • starts loading the page pointed at by the link you happened to be over when you started the scroll up gesture

Ok, so it’s not like I don’t understand what’s going on here: The poor thing is busy painting the page, and it just can’t deal with the added processor requirements of recognizing all of the events that make up the gesture. It either misses them all, or gets just a few of them, which leaves it either scrolling “a bit” or treating the gesture as a click on the link.

The thing is, it really doesn’t matter to me whether this is processor limited, or a bug in the OS (i.e. events get lost), or it’s just a bad design (i.e. input handled in the same thread that does the drawing), but the end result is that because I can’t trust what the phone will do in response to my touch, I have to wait until the page fully “settles” before I start scrolling. On pages that have lots of content and go off to ad services to fill in side bars, etc., this means I wait for a long time.

I mean, c’mon Apple; do I really have to tell you about the need for responsiveness?

Anyway, as frustrating as this is, the only real reason I started ranting about it is because it got me thinking about Eclipse, the UI thread, and the multi-core CPU trend. We’re pushing more and more work into multiple threads, drastically increasing the contention at the glass. The Jobs framework and UIJobs are interesting, but don’t address issues like recognizing when multiple jobs are attempting to paint conflicting (or even exactly the same) information in the UI… Anyway, there are aspects of the e4 “modeled UI” that are related to this, but it’s not clear that we’ve thought enough about it yet. Hm…

GUI Bloopers: Paste Special

So in case you haven’t seen it, “Paste Special” is a common feature in many applications that support rich content of one form or another. The intent is that, instead of having the application decide (based on the available content types of the object in the paste buffer) the best format to use when pasting, … Continue reading “GUI Bloopers: Paste Special”

So in case you haven’t seen it, “Paste Special” is a common feature in many applications that support rich content of one form or another. The intent is that, instead of having the application decide (based on the available content types of the object in the paste buffer) the best format to use when pasting, it offers the user a dialog with a range of available formats, something like this:

Paste Special

The typical behavior, in this case, is to open the dialog with the format that would have been chosen if the user had simply picked “Paste” already selected. I guess this is done so that, if the user hits return when the dialog opens, they will get the same behavior as Paste provides. The thing is though, no one who opens that dialog ever wants that behavior. The only reason why a user would go through the extra pain of the dialog is because they want to paste in some way that is not the default, so in point of fact, picking any other choice would be better than picking the one that does what Paste would do.

The question is then, what should the dialog have as the default selection?

In 99.9% of the times Paste Special is used, the intent is to remove any rich formatting from the content in the paste buffer, so that it can pick up the surrounding formatting of its destination. Given that, when there are multiple possible formats, always pick the “plainest” one. So, for example, in the above dialog, it should have “Unformatted text” selected by default.

Of course, as usual, the Apple guys have understood the underlying problem better. Instead of a Paste Special command, in Pages I get this…

Match Styles

… which does what you (almost always) actually want, without putting up a dialog at all.