Firefox Mobile Design Session: In-page Find
This is the second installment in the ongoing experiment to open the face-to-face design meetings we have at Mozilla. This design meeting centered around in-page find for Fennec (Firefox Mobile). This feature is as invaluable tool on the desktop, letting you home in quickly on the information you’re looking for once a search engine has got you to the right page. It’s incremental nature means you never have to type a key more than you need. Conspicuously missing from mobile Safari, incremental in-page find on mobile may prove to be even more of a killer feature than on it’s desktop counterpart.
We’ve tried to learn from the feedback to the last video (which, at the time of writing, has almost 350 views!—I was expected a number that could be counted on two hands). We changed the format of our white-boarding to be more like slides: Each board contains a title with its purpose, and has more focused content.
Video is a low information density medium, so for this video we are trying Viddler which allows viewers to make in-line comments to increase its time-information density. The hope is that you guys can annotate, call out interesting sections, or providing feedback on ideas discussed. (Thanks to Patrick and Ian for suggesting this change).
Also, feel free to comment on particular design decisions, or give your own, in the comments here. My favorite feature to come out of this session was the idea of pre-filling your in-page find with the search term, if you had just come from a search engine. When looking for a particular piece of information, the work flow is often (1) search engine the term to get to a potential page, (2) in-page find for the same term to see if the information exists. By defaulting to the search term, it halves the amount of typing (more if you have to check multiple pages), without burdening the user if the guess is wrong.
Here’s the video:
RT @azaaza Firefox Mobile Design Session: In-page Find | Follow @azaaza on Twitter | All blog posts
Tags: fennec, find, firefox mobile
Anders
Here are my main issues. It seems like find involves:
1) sliding to bring out the try
2) choosing find
3) exposing the find overlay
4) typing the search tearm
5) finalize or cancel search
which seems pretty involved. I’m not really sure what some of the requirements are built in keyboard? onscreen keyboard? should all ui elements be exposed over touch? If you have to have an onscreen keyboard there’s going to be a ton of missing space if you have a built in keyboard
you could use focus, key commands, etc.
ChrisJF
Do you have PDF’s of the slides available for this video like the other videos? Thanks.
Also, why invoke the find feature by using a button the control strip? Like Madhava said, those tool bars take up screen real estate. I always imagined the find feature would be integrated into the Awesome bar kinda like this:
http://chrisjf.googlepages.com/find-feature-fennec.png
Steps one and two can be reversed (doesn’t matter which order). If the user does 1 then 2, then terms are suggested for popular words on the current page as the user types.
I dunno if that’s UI overload but I thought it kind of makes sense since the Awesome bar is transforming into less of a URL bar and more of a general search bar.
The scrollbar idea is genius!
Also, I like the idea of selecting text in the webpage, and then having that automatically filled into the find search box when the find feature is invoked. This minimizes typing for the user.
Tobias
Thanks for sharing! (Comments on the video — great you use viddler now).
Aza Raskin
@ ChrisJF: The slides got corrupted somehow. I’ll ask Madhava to resend them. I also love that you mocked up an idea. It would be cool if you put that on Flickr and tagged it “mozconcept” to make it part of the Concept Series. There is a lot of legs to your idea.
@ Anders, ChrisJF, Tobias: Great comments. I’ll try to respond to them soon. I promse! :)
Ian
@ ChrisJF: “I always imagined the find feature would be integrated into the Awesome bar”
I absolutlly agree, Great concept! :-)
Philip
@ChrisJF: Plus, if it’s not found in the page, you can search the web without having to retype. If you hit Control+F, the Awesomebar is focused and the “Find-in-page” mode is activated without having to tap “Find on page”. The idea extends to searching bookmarks, tabs and history too.
What about finding the previous match in the page? Should there be a “Previous in page” and a “Next in page” button, plus a “Match case” check box, instead of “Find in page”? (The “highlight all” button is redundant because all matches should always be highlighted while the search interface is displayed.)
Aurelien
Hi,
a few HCI research papers that could be of interest in the discussion.
About scrolling: Orthozoom , http://www.lri.fr/~appert/website/orthozoom/orthozoom.html check the videos.
The works by Patrick Baudisch (in particular shift ) and Amy Karlson (in particular ThumbSpace) on interaction on mobile devices is interesting:
http://research.microsoft.com/users/baudisch/projects/
Check also Anne Roudaut’s Taptap and magstick selection techniques : http://www.anneroudaut.fr/publications.php?language=
http://research.microsoft.com/~karlson/
madhava
This is all great feedback — I’m really delighted. We’ll definitely do more posting of videos, and the Viddler approach seems to help too.
ChrisJF – thanks for the mockup! I think you’re absolutely right — there’s got to be away of extending “search for a page” to “search within a page” to complete the finding task. I think we’d also want a way to initiate find-in-page that doesn’t require bringing in the screen-consuming and conceptually separate “go to somewhere new” UI, though. And in desktop Firefox, where the awesomebar is always on screen, I think this makes even _more_ sense… especially if the awesomebar starts being a method for finding other things going on at the moment, like open tabs or downloaded files…
Anders — I’m inclined to agree with regards to initiating find in page from the control strip being cumbersome. It’s a lot of taps/clicks, as you point out, but it also means moving the content area around, which may take the user away from where he or she is trying to find something. Keyboard shortcuts would certainly help, but we’d still want a way to get at the functionality on-screen…
As for the PDFs — they seem, unfortunately, to be corrupt even on the whiteboard computer, and resaving doesn’t seem to help. I’ll keep at it.
ChrisJF
@Aza Raskin One Flickr Photo coming right up! http://www.flickr.com/photos/christopherjf/2855978349/
Kazeldjd
Hi webmaster!
Kazelqfk
Hi webmaster!
buy nolvadex
Hi webmaster!