Hacker News Reader

Comment by jtaby | Hacker News Reader

Thanks a lot for your comment, callahad. I'll try to respond to your comments.

1. You're right, I hadn't actually noticed that until after I wrote the blog post. I think it's because I hide the Dock by default (still doesn't explain why I didn't notice it in the app switcher)

My point was, there are three places to manage downloads. I have to manually close the Downloads bar. Worst of all (and this is something I forgot to point out in the post) is that closing the downloads bar actually makes the browser window smaller!

2. You're right, there are nice parts of having the preferences be in the tab.

3. I didn't mean the search field covers search results, it covers the website's UI. Here's another example of it blocking the UI, this time in github: http://cl.ly/1t450T1S0s2J2V0I3O1W

View on HN

I see your point about #3, but to be honest, I've been using Chrome since v1 and I have never once had this be an issue. Not a single time. There is simply never a case where what I'm searching for is in the very top right 10 pixels of a page. In your github example, why would you ever be searching for "dashboard", "inbox", "account settings", or "log out"?

Also I don't really understand your complaint about the bookmarks bar. Why do you have it up at all if you don't like the UI? If I want to go to a bookmarked page, I hit ctrl-shift-b to bring up the bar or, much more often, I open a new tab. I think the thing that separates Chrome from other browsers is the huge content real estate, and keeping the bookmarks bar up there takes away from this in a big way.

> There is simply never a case where what I'm searching for is in the very top right 10 pixels of a page. In your github example, why would you ever be searching for "dashboard", "inbox", "account settings", or "log out"?

I think jtaby made it very clear that he wasn't referring to cases where it covers search results, but that it covers the website's UI. In fact, those were his exact words.

In that case, I don't really see any validity in the complaint. The search function is a temporary UI addition with a single purpose that goes away the moment you hit escape. Better yet, if you hit ctrl-f again, it comes back with the same text already entered.

Okay. These are all facts with respect to the find UI; yes, the things you say regarding hitting the escape key and the keyboard shortcut to make the find UI reappear—these are all true, factual things.

But this isn't a concession. You can say these things, but every one of them is immaterial to point that the find UI, when present, obscures parts of the page, where potentially those parts are functional UI for that page.

So? If it doesn't cause a problem... it isn't a problem.

This is another factual statement which is also immaterial to the discussion, in much the same way that "an apple is an apple" is a factual statement, but immaterial here.

If you think that I'd summarize my comment above as, "there's no problem", you've misunderstood.

Hm. I don't know that this is a defense either - but this design decision was at least made deliberately, with awareness of the trade-offs involved.

" The find bar is presented as an overlay in order to prevent page relayout when the bar is shown or hidden. If the text the user is looking for is under the bar, it will scroll the page, or slide out of the way."

http://www.chromium.org/user-experience/find-in-page

There seems to be a consistent, understandable aversion to pop up windows within Chrome. Excepting the Downloads bar, there also seems to be an aversion to shrinking the display area of the screen. Putting the Find in Page UI overlaying the site causes the browser to show more of the page than if it shifted the page down, something that is clearly a high priority for them (see the Status bar for an example).

Every design involves compromise. I think I prefer the way Chrome went on this one.

Worst of all is that closing the downloads bar actually makes the browser window smaller!

It actually doesn't -- or at least, it doesn't seem to on the Dev Channel or Canary. If there's enough screen real estate, the downloads panel grows out of the bottom of the window, and shrinks away when dismissed. The viewport retains the same dimensions before and after.

If there isn't enough space below the window, the panel does indeed overlay the bottom ~47px of content, but in that case, dismissing it doesn't change the size of the window, restoring the viewport to its previous size.

That's the most frustrating thing about Chrome: it's inconsistently polished, and in many cases, it feels like its relationship to ChromeOS is akin to the tail wagging the dog.

But if you're searching for specific content it seems to fall into two categories:

A) The content _is_ the UI element that's being covered and the search box moves out of the way.

B) The content _is not_ the UI element that's being covered and you are looking to find something else on the page.

I don't leave the "Find on Page" box open when I'm normally using a page. So when searching I'm not really interacting with that UI, and when not searching it isn't being obstructed... so does this really constitute a UX issue?

There's one detail ignored here. You hint at it when you say that, regarding yourself:

> I don't leave the "Find on Page" box open when I'm normally using a page.

(emphasis mine)

When you have the find UI open and you click on a link within the page, the find UI disappears when it navigates to the new page.

This allows you, for example, to open the find UI and use it until you've reached your goal, then promptly drop the find UI from your mind, focusing on your new goals. It's not necessary to focus back on the find UI to consciously close it. Eventually, it gets "garbage collected", to use an analogy.

But under certain conditions, this isn't the case. The conditions are when one of the page elements you would come to interact with—without otherwise ever needing to bring the find UI back to the forefront of your mind—is obscured. You must now focus back on the find UI, close it, then switch back to whatever you were trying to do.

Alright, I can see the case where someone doesn't habitually close it and stumbles upon a site where it is obscuring. It seems rather mild to me, but I guess I could regard that as a UX failing.

The only solutions that immediately come to mind:

A) Place the "Find on Page" box at the bottom of the window.

Advantages: It would get out of the way for the common practice of placing web UI at the top of the viewing pane. Also the tradition of putting other UI elements at the bottom (namely the download bar comes to mind) means that it wouldn't be too unfamiliar.

Drawbacks: This _would_ put it rather far from it's omnibox UI-sibling and the rest of the prefs UI, breaking some of the association for the UX. It doesn't resolve the problem of UI elements being obscured the bottom of the viewing pane.

Seen also in: I know at least Firefox does this.

B) Have the "Find on Page" UI element displace the page so as to not cover any page UI while "active"

Advantages: Won't cover UI. Potentially more room for search terms.

Drawbacks: Takes up more screen real estate.

Seen also in: I know at least Firefox does this as well.

Alright, so those are potential solutions... what I'm more interested in are the ones I _haven't_ thought of. Does anyone in the HN community have a brilliant solution for how to deal with designing a "Find on Page" UI?

Another approach could be something that sort of resembles B.

When the find UI opens, it has the same effect as displacing the page, the way full-width find bars do. The difference would be that the UI stays as it is and isn't changed into a full-width find bar. The null space to the left and right of the find bar would still allow whatever it's overlaying to shine through.

The only move to make now is figuring out what happens when the user isn't sufficiently scrolled down far enough, i.e., the null space around the find UI when the user is scrolled to the very top of the page is actually void space. What do you put there? I suggest silently[1] extend the scrollable area of the page by adding a quasi-content area. It's quasi-content because it's not actually part of the page--it's just part of the scrollable area. It pulls its color/background pattern from the page's background style.

Another approach would just be to have the find UI extend into the browser chrome, temporarily shrinking the location bar.

[1] being careful here not to set off any events or changing the way, e.g., event coordinates look to script on the page

In regards to #1 - I'm not sure what you mean by "manage".. the 3 places cater to 3 distinct use-cases -

- The downloads bar works in the 90% use case - we just want to download something and open it. When you click a download(s) in the bar, the bar closes after the download is complete.

- The dock icon lets you know how the download is going, when you're in another app / away from the browser.

- The download tab gives you your complete download history, for when you want to look back for old downloads.

Making the browser window smaller after closing the downloads bar is actually a bug, it doesn't do this on other platforms. I think this is fixed in the newest dev builds.

Reply on news.ycombinator.com