The Invisible2013-02-25T10:54:11+00:00http://theinvisibl.com/Basil SafwatHow the iPhone mail app decides when to show you new mail2011-01-24T00:00:00+00:00http://theinvisibl.com/2011/01/24/iphonemail<p>Here’s a question.</p>
<p>You’re in the iPhone mail app, and you’re looking at your inbox, when a new email arrives. What happens?</p>
<p>Let’s have a look at the inbox. I’m at the top of the list, and the out-of-view emails are shown in faded grey.</p>
<p><img alt='Email inbox' src='http://theinvisible.s3.amazonaws.com/2011/iphonemail/1.png' /></p>
<p>If an email arrives now, it pops into the top, and pushes all the other emails down.</p>
<p><img alt='New email arrives, old emails move down' src='http://theinvisible.s3.amazonaws.com/2011/iphonemail/2.png' /></p>
<p>Yay, new email!</p>
<p>So far, so obvious.</p>
<p>Next question: what if you have scrolled down the list a little bit, so you’re not at the top of your inbox? What happens when you get a new email now?</p>
<p>Here is your view before you get the email — you have scrolled down to email 4:</p>
<p><img alt='User has scrolled down to email 4' src='http://theinvisible.s3.amazonaws.com/2011/iphonemail/3.png' /></p>
<p>In this case, when you get a new email, you are <strong>auto-scrolled</strong> to the top of the list, where the new email is sitting there waiting for you:</p>
<p><img alt='New email arrives, user is returned to top' src='http://theinvisible.s3.amazonaws.com/2011/iphonemail/4.png' /></p>
<p>So the behaviour is:</p>
<ol>
<li>if you’re at the top of the list, the new email pushes down the existing emails and you stay at the top.</li>
<li>if you have scrolled down the list a bit, you are returned to the top of the list to see the new mail.</li>
</ol>
<p>This makes sense until you think about what happens if you have a lot of emails in your inbox. Imagine you have scrolled down a long way to find a certain email, and then, at that moment, a new email arrives.</p>
<p>Being pulled to the top of the list would be annoying in this case. You’d be proudly presented with an email almost-certainly-not-relevant to your reason for being buried halfway down your inbox. You’d have no accurate way of quickly returning to where in the inbox you were, and, over time, you would probably adopt an unconscious worry that this could happen without warning while you were looking for something in your inbox. A worry that you would be pulled to the top of the list because someone, somewhere decided to send you an email. Come on, Apple. Sort it out.</p>
<p>Luckily, they have sorted it out. Good news!</p>
<p>Here’s what happens. If you’ve only scrolled down <em>a little bit</em> and you happen to get a new email, you’ll be returned to the top (which is no big deal, because you knew you were only a little bit below the top, so it’s easy to get back to where you were), but if you are deeper in your inbox, getting a new email <em>does nothing</em>. Have a look.</p>
<p>Here’s the view before the email arrives — we’ve scrolled down further this time, to email 6:</p>
<p><img alt='User has scrolled down to email 6' src='http://theinvisible.s3.amazonaws.com/2011/iphonemail/5.png' /></p>
<p>If an email arrives now, <em>nothing happens</em>:</p>
<p><img alt='New email arrives, but user not returned to top' src='http://theinvisible.s3.amazonaws.com/2011/iphonemail/6.png' /></p>
<p>You’re not returned to the top. You get the alert sound and all the other indicators that a new email has arrived, but you stay where you are in the list. Someone has realised, maybe during testing, that it is annoying to be yanked to the top of the list when you’re a long way down, but it is less annoying when you’re near the top.</p>
<p>The magic distance is three messages.</p>
<p><img alt='No-scroll distance: three emails deep or more' src='http://theinvisible.s3.amazonaws.com/2011/iphonemail/7.png' /></p>
<p>That is, if you are less than three messages down into your inbox, you’ll be returned to the top when you get a new email. Any more than this and you’ll stay where you are. Send yourself an email and try it.</p>
<p>This is serious attention to detail. It’s not something people will show off to each other on the bus, or something that you can put on an advert or trumpet on a feature list. It just makes the app a bit quieter and a bit more well behaved. The addition of this extra detail has made the app <em>less visible</em> than if the detail wasn’t there. Lovely.</p>A piece with a lot of screenshots about the close tab behaviour in Google Chrome2009-12-08T00:00:00+00:00http://theinvisibl.com/2009/12/08/chrometabs<p>Ah, tabs.</p>
<p>Tabs, tabs, tabs. The specialist subject of UI experts everywhere. Should tabs just rearrange horizontally or also detach? How much vertical scroll buffer should a tab have before it detaches? Under what circumstances should it detach? What about reattaching?</p>
<p>This is a short piece concerned only with the different behaviours when <strong>closing tabs</strong> in Google Chrome, as I think these behaviours are fantastically thought through.</p>
<h2 id='closing_tabs_a_masterclass_by_google_chrome'>Closing tabs: a masterclass by Google Chrome</h2>
<p>Let’s start by looking at some tabs in Safari (which was once what Chrome is before Chrome was).</p>
<p>If you add a number of tabs over the course of a session you will get something like this:</p>
<p><img alt='Tabs in Safari' src='http://theinvisible.s3.amazonaws.com/09122009/tabs/1-safari-tabs.png' /></p>
<p>And in Chrome you will get this:</p>
<p><img alt='Tabs in Chrome' src='http://theinvisible.s3.amazonaws.com/09122009/tabs/2-chrome-tabs.png' /></p>
<h2 id='closing_tabs_from_the_right'>Closing tabs from the right</h2>
<p>The first difference to notice is that Safari puts the ‘close tab’ control on the left of the tab, while Chrome has it on the right.</p>
<p><img alt='Close button placement on Safari vs Chrome' src='http://theinvisible.s3.amazonaws.com/09122009/tabs/3-left-v-right.png' /></p>
<p>So what? Let’s close a tab from the <strong>end of the row</strong> and see what happens. Here’s a before and after in Safari:</p>
<p><img alt='Closing a tab from the end of the row in Safari' src='http://theinvisible.s3.amazonaws.com/09122009/tabs/4-closing-from-end-safari.png' /></p>
<p>And in Chrome:</p>
<p><img alt='Closing a tab from the end of the row in Chrome' src='http://theinvisible.s3.amazonaws.com/09122009/tabs/5-closing-from-end-chrome.png' /></p>
<p>What’s the difference here? Well, both browsers have resized their tabs to fill the newly-freed window space, but due to the placement of the close button on Chrome, the mouse pointer is immediately in position to close the next tab:</p>
<p><img alt='Closing a tab from the end of the row in Chrome' src='http://theinvisible.s3.amazonaws.com/09122009/tabs/6-closing-from-end-chrome-hl.png' /></p>
<p>While Safari is not.</p>
<p><img alt='Closing a tab from the end of the row in Safari' src='http://theinvisible.s3.amazonaws.com/09122009/tabs/7-closing-from-end-safari-hl.png' /></p>
<p>See how the close-button target moves when closing a couple of tabs in Safari:</p>
<p><img alt='Showing where the close target moves when closing two in a row on Safari' src='http://theinvisible.s3.amazonaws.com/09122009/tabs/8-closing-two-end-safari-hl.png' /></p>
<p>There are no such problems in Chrome:</p>
<p><img alt='Showing where the close target moves when closing two in a row on Chrome' src='http://theinvisible.s3.amazonaws.com/09122009/tabs/9-closing-two-end-chrome-hl.png' /></p>
<p>The Safari user has to hunt for the next close button each time, while the Chrome user can click the mouse button as many times as required in succession, with no movement of the mouse. Aha! It starts to make sense.</p>
<h2 id='closing_tabs_from_the_left'>Closing tabs from the left</h2>
<p>Or does it? This advantage is surely to be reversed when closing tabs from the left of the window? Quite right. Here is how the mouse pointer is required to move in Safari when closing a number of tabs at one time <strong>from the left</strong>:</p>
<p><img alt='Closing a tab from the left of the row in Safari' src='http://theinvisible.s3.amazonaws.com/09122009/tabs/10-closing-from-left-safari-hl.png' /></p>
<p>Nice work, Safari. Let’s watch Chrome screw this up:</p>
<p><img alt='Closing a tab from the left of the row in Chrome' src='http://theinvisible.s3.amazonaws.com/09122009/tabs/11-closing-from-left-chrome-hl.png' /></p>
<p>Egads! It worked!</p>
<p>What has happened here? Well, while Safari resizes the width of the remaining tabs to fill the newly available space each time a tab is closed – Chrome does not. So when a tab is closed from the left in Chrome, no resizing takes place, the rest of the tabs move along one, lining up the next close button directly under the mouse pointer, ready for the next click.</p>
<p>Now, Chrome <em>will</em> resize the tabs to fit the remaining space, but only after the mouse has left the functional area at the top of the browser; that is, after the user has finished interacting with the tabs and has moved their attention elsewhere. Here it is, before and after:</p>
<p><img alt='Resizing tabs in Chrome' src='http://theinvisible.s3.amazonaws.com/09122009/tabs/12-resizing-tabs-in-chrome.png' /></p>
<p>When the mouse moves from the toolbar area, the tabs resize.</p>
<p>Closing tabs from the middle of a group of tabs has exactly the same effect as above in Chrome – the tabs do not resize on close, only when the mouse pointer has left the toolbar. Safari immediately resizes the tabs. This means that closing tabs from the middle requires the user to hunt for each close button in Safari, while in Chrome, the buttons are lined up for the next click.</p>
<h2 id='a_couple_of_notes_conclusion'>A couple of notes, conclusion</h2>
<ol>
<li>
<p>Note that if tabs are closed by use of a keyboard shortcut in Chrome, this ‘delayed resizing’ (i.e. remaining tabs not filling the newly freed space after a tab has been closed) does not happen – the tabs resize immediately, just as they do in Safari. This is, therefore, a very clearly considered assist for those using the mouse.</p>
</li>
<li>
<p>This resizing trait, although nuanced, is almost invisible to the user. In fact, it <em>was</em> completely invisible to me, for weeks, even though I was benefiting from this behaviour every day. <em>It just worked correctly</em>, in all cases – whether closing tabs from the left, right, or middle.</p>
</li>
<li>
<p>My conclusion is probably this: when a system’s UI is designed in such a way that its behaviours start to disappear – that’s what I call ‘the invisible’.</p>
</li>
</ol>
<h2 id='endnote_why_is_the_close_button_on_the_right'>Endnote: Why is the close button on the right?</h2>
<p>Here’s a point: the ‘delayed resizing’ behaviour in Chrome that has been described above means that placing the close button either on the left or right of the tab would have produced the same effect – the ability to close a number of tabs without horizontal movement of the mouse pointer. So why have Google chosen to place the close buttons on the right? I don’t think it’s just to <a href='http://daringfireball.net/linked/2009/12/08/chrome-for-mac'>annoy John Gruber</a>.</p>
<p>In this case, I think Google were governed by this thought: <strong>by default, an application should exhibit the <em>least-funky behaviour</em>.</strong> Although the delayed resizing trick is subtle, natural, and almost completely invisible (as long as the user isn’t actively considering the nature of the tabs themselves), it is still <em>less normal</em> than if the application did not exhibit that behaviour at all.</p>
<p>In placing the close button on the right, Google have assumed that in the majority of cases, users are going to be wanting to close the most recently opened tabs first (likely to be the ones to the far right of the tab group) and have accordingly placed the close button on the right. Why? Because not only does this give the user the ability to close a number of tabs in one go without moving the mouse pointer (which Safari does not), it also means that the app does not need to exhibit the ever-so-slightly less normal behaviour of the ‘delayed resizing’ in the most-common case.</p>
<p>One final point. Tabs open left-to-right because we read left-to-right. If all of the above really was considered by some genial, tab-obsessed Google employee, you would expect a <em>right-to-left</em> language version of the browser to not only open tabs the other way around, but to also put the close button on the left.</p>
<p>Here’s Google Chrome in Arabic:</p>
<p><img alt='Google Chrome in Arabic' src='http://theinvisible.s3.amazonaws.com/09122009/tabs/13-google-chrome-arabic.jpg' /></p>
<p>I suppose Gruber could just use that.</p>