One idea would be to show a list of most common searches or most read articles.

hi @Jcasariego - thanks for tackling this one, here's the asset attached as svg and xml.

Change 354056 had a related patch set uploaded (by Jcasariego; owner: Jcasariego):
[apps/android/wikipedia@master] Update design of empty Search screen

https://gerrit.wikimedia.org/r/354056

Thanks @RHo

Change 354056 merged by jenkins-bot:
[apps/android/wikipedia@master] Update design of empty Search screen

https://gerrit.wikimedia.org/r/354056

hi there, noticed a couple of minor visual design issues, and also some inconsistency when search is invoked from an article vs the Explore feed.

Visual design:

• Background is using #FFF instead of the expected base80 color (#EAECF0)
• "Search and explore...." text has a shorter line-height (looks like ~20dp) than the expected 24dp for the Material Subhead secondary text-style
• Not so much a bug, but wanted to confirm that "Search and read the free encyclopedia in your language" string should be included in translation

Bugs in behavior

1. When search is invoked from the Article tab stack, the empty search graphic and text is not being centered on the screen:

Feed - search with keyboard	Feed - search with keyboard hidden	UNEXPECTED Search invoked in Articles stack (with keyboard)

2. The 'no search results' message and graphic no longer appears to work in this version:

Expected prod version	UNEXPECTED version 2.5.195-alpha-2017-05-23

Change 355561 had a related patch set uploaded (by Mholloway; owner: Mholloway):
[apps/android/wikipedia@master] Search empty view design tweaks

https://gerrit.wikimedia.org/r/355561

I've got WIP to fix some of these but wanted to follow up on a couple of things...

In T137116#3288949, @RHo wrote:

• Not so much a bug, but wanted to confirm that "Search and read the free encyclopedia in your language" string should be included in translation

It's being included as usual. I'm not sure I'm following the train of thought here—shouldn't it be?

Bugs in behavior

UNEXPECTED Search invoked in Articles stack (with keyboard)

Based on testing earlier @ commits, this isn't a new regression; the "no results found" has always been centered likewise in the context of the Page activity. Fixing this will take some investigation into how the Page activity view hierarchy isn't like the others. Can we punt this to a new task rather than blocking here?

In T137116#3288949, @RHo wrote:

2. The 'no search results' message and graphic no longer appears to work in this version:

It looks like a separate patch of mine caused this one. Fixing now.

Change 355566 had a related patch set uploaded (by Mholloway; owner: Mholloway):
[apps/android/wikipedia@master] Fix: Unbreak empty search results set handling

https://gerrit.wikimedia.org/r/355566

In T137116#3290610, @Mholloway wrote:

I've got WIP to fix some of these but wanted to follow up on a couple of things...

In T137116#3288949, @RHo wrote:

• Not so much a bug, but wanted to confirm that "Search and read the free encyclopedia in your language" string should be included in translation

It's being included as usual. I'm not sure I'm following the train of thought here—shouldn't it be?

Ah I was double-checking, since the nature of the text is about being able to search different language wikis, it might come across extra silly if not translated :p

In T137116#3290610, @Mholloway wrote:

Based on testing earlier @ commits, this isn't a new regression; the "no results found" has always been centered likewise in the context of the Page activity. Fixing this will take some investigation into how the Page activity view hierarchy isn't like the others. Can we punt this to a new task rather than blocking here?

Sure, is it fine that I've appended this to the bug T166151: "No results found" message not visible when keyboard active when triggered from the **Article** view ?

In T137116#3291604, @RHo wrote:

Ah I was double-checking, since the nature of the text is about being able to search different language wikis, it might come across extra silly if not translated :p

Ah, quite true. :)

Sure, is it fine that I've appended this to the bug T166151: "No results found" message not visible when keyboard active when triggered from the **Article** view ?

Perfect!

Hi @RHo

Visual design:

• Background is using #FFF instead of the expected base80 color (#EAECF0)

I updated with base80 color and this is the result

• "Search and explore...." text has a shorter line-height (looks like ~20dp) than the expected 24dp for the Material Subhead secondary text-style

Sorry, but I don't understanding to which text are you referring? Is it the text "Search..." in the Toolbar or the text below the image?

In T137116#3291909, @Jcasariego wrote:

Hi @RHo

Visual design:

• Background is using #FFF instead of the expected base80 color (#EAECF0)

I updated with base80 color and this is the result

Great!

• "Search and explore...." text has a shorter line-height (looks like ~20dp) than the expected 24dp for the Material Subhead secondary text-style

Sorry, but I don't understanding to which text are you referring? Is it the text "Search..." in the Toolbar or the text below the image?

I'm referring to the text below the image:

Change 355561 abandoned by Mholloway:
Search empty view design tweaks

https://gerrit.wikimedia.org/r/355561

• "Search and explore...." text has a shorter line-height (looks like ~20dp) than the expected 24dp for the Material Subhead secondary text-style

Sorry, but I don't understanding to which text are you referring? Is it the text "Search..." in the Toolbar or the text below the image?

I'm referring to the text below the image:

Ah, Ok ok :)

Investigating a little the project layouts I could see that an attribute called "lineSpacingMultiplier" is used to modify this height. And the ones that are usually used are the values: 1.2 and 1.4. This is the result of how it would look:

Sorry @Mholloway, but I didn't see that you already did the update of this yesterday :/

In T137116#3292143, @Jcasariego wrote:

Sorry @Mholloway, but I didn't see that you already did the update of this yesterday :/

No worries, I did a quick patch while I was looking over Rita's feedback but it hadn't gotten any review feedback yet. I can revive that one, or if you've got a patch ready to go, please feel free to push it up and I'll review and merge!

Change 355566 merged by jenkins-bot:
[apps/android/wikipedia@master] Fix: Unbreak empty search results set handling

https://gerrit.wikimedia.org/r/355566

In T137116#3292115, @Jcasariego wrote:

Investigating a little the project layouts I could see that an attribute called "lineSpacingMultiplier" is used to modify this height. And the ones that are usually used are the values: 1.2 and 1.4. This is the result of how it would look:

Hi @Jcasariego – since the text is 16sp, my presumption would be 'linesSpacingMultiplier" can be set to 1.5 (to get the 24dp leading per the Material spec).
However, I am not sure if changing this attribute may affect other sections of text... @Niedzielski was playing with line-heights on something else a while back so he may comment if this is fine or not?

In T137116#3292661, @RHo wrote:

since the text is 16sp, my presumption would be 'linesSpacingMultiplier" can be set to 1.5 (to get the 24dp leading per the Material spec).

One could reasonably assume that the lineSpacingMultiplier attribute works straightforwardly that way, but it doesn't. Unfortunately, I have not found any way of translating values accurately between a line-height and the lineSpacingMultipler/lineSpacingExtra. We usually use our best approximation, which in practice in most instances usually falls somewhere between 1.2-1.25.

@RHo, T157147 tracks investigating adding exact line height support across Android versions and devices. If I understand correctly, @Jcasariego is only changing the line height attribute of one TextView so that's the only place this would have effect.

IOW, what I'm saying is that there is no sane way to specify a line-height in a native (non-WebView) Android View.

(A lineSpacingMultipler value of 1.5 will almost certainly be too big.)

hi @Jcasariego – based on the ^ comments regarding funky line height behavior, seems like 1.25 is a safer bet :)

Great @RHo . I'll update the attribute and then push it up

Change 355732 had a related patch set uploaded (by Jcasariego; owner: Jcasariego):
[apps/android/wikipedia@master] Search empty view design tweaks

https://gerrit.wikimedia.org/r/355732

In T137116#3292230, @Mholloway wrote:

In T137116#3292143, @Jcasariego wrote:

Sorry @Mholloway, but I didn't see that you already did the update of this yesterday :/

No worries, I did a quick patch while I was looking over Rita's feedback but it hadn't gotten any review feedback yet. I can revive that one, or if you've got a patch ready to go, please feel free to push it up and I'll review and merge!

@Mholloway I created a new patch and I pushed it up. It's the same as your patch

Change 355732 merged by jenkins-bot:
[apps/android/wikipedia@master] Search empty view design tweaks

https://gerrit.wikimedia.org/r/355732

LGTM:

Tested on Pixel (Android 7.1.2, Wikipedia version 2.5.195-alpha-2017-06-05)