Please *describe* the actual proposal here in case that you want to proceed via a bug report (and update the bug report description).

I updated the proposal. If you want I can copy the text here, too. Yet I think it's not the best to post everything twice. The 'bugs' are also listed in the proposal above.

PS: How can I alter my initial bug report?

Talk with the designers on IRC during weekdays. See: https://live.gnome.org/Design/

Hey t|ask,

Thanks for the notes and designs. There's some good stuff here. As Jasper mentioned, if you ever want to talk about design issues, just ask on #gnome-design during the week. We'd be really happy to talk through any ideas you have.

I've had a look at the wiki page. Some of the issues you mention will hopefully be going away, such as the interference between the message tray and search results (bug 687787). 

It seems to me that some of the issues you point out can be solved within the current design, and could be simply be layout/visual issues. I don't think there's anything intrinsically wrong with having a heading icon in one column and results in another, for example (this pattern is used in other search designs I've seen). If you'd like to help to refine the existing design, you can grab the mockups from git.gnome.org [1] and have a play around with them.

My view is that a list is more appropriate for search results than a grid. It allows you to have longer titles and even snippets from documents or conversations.

Another thing to consider when designing the search results view is that matches can be narrowed down very quickly. It's important that the results look good when there is only one or two hits - I'm not sure that would be the case with your design.

[1] http://git.gnome.org/browse/gnome-shell-design/

Hi t|ask. Thanks again for these design ideas. It's always interesting to see other ideas.

If you have any less wide-ranging suggestions for the search design, please feel free to report them as separate bugs.

I updated the proposal and tried to clarify some text sections. Also, pictures are now thumbnails. I'm not sure how to go further with this proposal, cause this bugreport is marked RESOLVED WONTFIX.

Does this mean, I didn't gave enough information how it works or would it help if I add more information? I still have the impression, the wall of text makes it difficult for readers to understand the idea behind it. IRC chats gave me a similar impression. I would like to spend more time on it if there is a chance that this proposal gets attention. 

If you think it's a real WONTFIX issue for future versions and this is a final decision, please let me know. After two years of uncertainty, I really would like to have a final decision on this, please.

Thanks.

Oh and the proposal move to:
https://wiki.gnome.org/Design/Playground/GnomeSearch

It means that we don't see the need for a radical redesign of search. Some of the problems you mention have been fixed (both dash and message tray are hidden during search), and the proposal has its own set of design issues:

  - it breaks the "<super>type<enter>" workflow which we
    advertise as the preferred way to launch apps

  - it lumps everything that is not an installed application
    under "Personal Data"; there are a lot of existing
    search results that don't fit that categorization at all
    (terminal tabs, installable apps, calculations, current time
     at a given location, ...)

  - it heavily relies on custom keyboard navigation that is
    completely different from keyboard navigation everywhere
    else in the shell (or gtk+ for that matter)

So no, this is a "real" WONTFIX for that particular design. As mentioned in comment #5, we would still welcome incremental improvements on the existing design of course.

First, thanks for the reply. I see, that my proposal isn't as good understood as I thought. Therefore, I just want to add some comments to explain it better:

(In reply to comment #8)
> It means that we don't see the need for a radical redesign of search. Some of
> the problems you mention have been fixed (both dash and message tray are hidden
> during search), ...

Yes, the message try provides now vertical space for one more entry. Hiding the left dash panel improves readability a bit, while the unclear "guessing on icon's meaning" and limited search results per category stays the same. The eye-movement and scrolling is still complicated.

> ... and the proposal has its own set of design issues:
>
>   - it breaks the "<super>type<enter>" workflow which we
>     advertise as the preferred way to launch apps

No, it doesn't. The user still can choose which search behaviour (Apps/Personal Data) he wants as default "<super>type<enter>" workflow. If the user wants to search applications by default, then his cursor is focused in the Apps section and search term related Apps are listed here.
 
>   - it lumps everything that is not an installed application
>     under "Personal Data"; there are a lot of existing
>     search results that don't fit that categorization at all
>     (terminal tabs, installable apps, calculations, current time
>      at a given location, ...)

"Personal Data" is just an example name for this section, where simply everything is listed as the current 3.14 search result can offer. And Yes, you can also add all your suggested categories here if needed. It just provides a personal view on all your enabled data/categories. 
 
>   - it heavily relies on custom keyboard navigation that is
>     completely different from keyboard navigation everywhere
>     else in the shell (or gtk+ for that matter)

Are you referring to the "TAB=Switch Sections" and "Cursors=Navigate Categories/Data" suggestions? This is easily customizable. It's a suggestion, because it's intuitive to navigate that way. IMHO the Search results don't actually look like a GTK dialog. It's simply the same cursor navigation as 3.14 has within the search results, Just that TAB switches the main search results on the fly.

> So no, this is a "real" WONTFIX for that particular design. As mentioned in
> comment #5, we would still welcome incremental improvements on the existing
> design of course.

Well, actually it is exactly that. When just changing the layout and adding a second column is so complicated, then it isn't an incremental improvement. From my point of view it's more design related than heavy code development. It simply lists the results a bit different. 

Considering your reply, I think, the proposal isn't easy to understand and looks like it's very different and difficult to adapt with the current code base. While I actually think it's just a redesign of the current search results. Furthermore. it's keyboard navigation is almost as it is now. The user might even won't feel any difference. Also, it's not a manifest. All mockups are just examples of how the design could look. Categories, icons and positions can vary, sure.  

Ok, probably the wall of text just made it look like this proposal is making things very different and difficult, while it is actually the opposite!

On one hand I could offer to improve the mockups to make things clearer, while on the other hand I think it's not worth the effort if there is no chance to get this running.

Ok, I understand ...