After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 671533 - gnome-documents search provider is useless when the user intends to edit
gnome-documents search provider is useless when the user intends to edit
Status: RESOLVED WONTFIX
Product: gnome-documents
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GNOME documents maintainer(s)
GNOME documents maintainer(s)
: 689856 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-03-07 09:14 UTC by drago01
Modified: 2013-03-08 20:30 UTC
See Also:
GNOME target: 3.8
GNOME version: ---


Attachments
shellSearchProvider: Try to open documents with the associated app first (1.04 KB, patch)
2012-03-07 09:37 UTC, drago01
none Details | Review
Step 1 (search for file) (840.40 KB, image/png)
2013-03-08 19:42 UTC, Dave Neary
  Details
Step 2 (No preview, and no close button) (34.88 KB, image/png)
2013-03-08 19:43 UTC, Dave Neary
  Details
Step 3 (to open file, need to right click to choose, then click on the folder icon to open) (37.73 KB, image/png)
2013-03-08 19:44 UTC, Dave Neary
  Details

Description drago01 2012-03-07 09:14:51 UTC
Not sure whether to file this against gnome-documents or here.

When searching for a document and opening it it gets opened in gnome-documents, which is kind of useless if the users intend is to edit the document.

We should just open them with the associated app if any and fall back to gnome-documents if there is none.

This way it handles both use cases (editing and viewing).
Comment 1 drago01 2012-03-07 09:37:11 UTC
Created attachment 209139 [details] [review]
shellSearchProvider: Try to open documents with the associated app first

This allows the user to either edit or just view the document rather
then only having the option of viewing it.
Comment 2 Florian Müllner 2012-03-07 10:51:43 UTC
The whole point of having search provders provided by applications is to create a strong and obvious connection between a result and the application that will open it when hitting enter. See the design[0] for plans on what to do with applications that do not provide their own search provider, I don't see how this patch fits in there (in fact, it just reintroduces a lot of the problems of the "recent items" provider).

So I don't think we want this, but let's give the designers the last word here.

[0] http://live.gnome.org/GnomeShell/Design/Whiteboards/Search
Comment 3 drago01 2012-03-07 11:16:03 UTC
(In reply to comment #2)
> The whole point of having search provders provided by applications is to create
> a strong and obvious connection between a result and the application that will
> open it when hitting enter. See the design[0] for plans on what to do with
> applications that do not provide their own search provider, I don't see how
> this patch fits in there (in fact, it just reintroduces a lot of the problems
> of the "recent items" provider).

Which problems are you talking about? When I search for a document I do intend to edit it as well as reading it (OK might be different for some types like PDF) but still by opening the "real app" you can as well read and edit the document there is no additional burden here neither any "problem". 

The current state OTOH introduces the problem that you can no longer use the search when you want to edit a document, which is a huge regression IMO.
Comment 4 Jakub Steiner 2012-03-07 11:27:07 UTC
So you propose to open up GIMP for every image because it allows to edit as well as view? The new design, which isn't quite there yet, presents the search result grouped by handler and alleviates the issue of unexpected default action. Not only will the association be clear, but you will have a chance to enable/disable certain backends.
Comment 5 drago01 2012-03-07 11:36:48 UTC
(In reply to comment #4)
> So you propose to open up GIMP for every image because it allows to edit as
> well as view? 

No unless GIMP is set as the default handler for images. In that case the user edits images quite often (and nautilus will open GIMP as well) and explicitly want that. 

> The new design, which isn't quite there yet, presents the search
> result grouped by handler and alleviates the issue of unexpected default
> action.

How so? Telling me that "this won't allow editing" does not help much it forces me to go the long way of opening the editing app or using nautilus instead of "Super + type part of name + enter" ... which is quite convenient and the whole point of the search.

> Not only will the association be clear, but you will have a chance to
> enable/disable certain backends.

What is a "backend" ? Search provider?
Comment 6 Florian Müllner 2012-03-07 11:52:10 UTC
(In reply to comment #3)
> Which problems are you talking about?

Mostly that it is very intransparent which application will launch a result - to predict that, you first need to know the mime type of the document (which is not necessarily obvious, as the filename is only used as fallback, and has its extension stripped if used), then you must know which application is configured as the default handler.
While that was unfortunate with the "generic" docs provider in gnome-shell, it is actually worse now, given that the results are associated with a specific application. Just think of the browser exposing its history in shell search, where some results are launched in an HTML editor instead - it doesn't make much sense.


> When I search for a document I do intend to edit it as well as reading it (OK
> might be different for some types like PDF) but still by opening the "real app" 
> you can as well read and edit the document there is no additional burden here 
> neither any "problem". 

But gnome-documents *is* the "real app" - if you search from within gnome-documents, activating the result will not launch a "random" other application, it will open a preview instead. Doing anything else in the shell would be okay-ish for a generic "documents" provider, but not for an application-provided "gnome-documents" one.


> The current state OTOH introduces the problem that you can no longer use the
> search when you want to edit a document, which is a huge regression IMO.

Yeah, it's a regression, as well as no longer providing results for non-documents (images, videos, "downloaded stuff", ...) - how about reintroducing the "old" GtkRecent provider as an (off-by-default) option until the new design is fully implemented?
Comment 7 drago01 2012-03-07 12:16:08 UTC
Review of attachment 209139 [details] [review]:

Given the clear NAK by the designers there is no point in trying to get this in so unfortunately we have to live with this regression until we get the new search design in 3.6.
Comment 8 Giovanni Campagna 2012-03-07 16:50:53 UTC
This cannot be RESOLVED, the original bug is still there.

(In reply to comment #6)
> (In reply to comment #3)
> > When I search for a document I do intend to edit it as well as reading it (OK
> > might be different for some types like PDF) but still by opening the "real app" 
> > you can as well read and edit the document there is no additional burden here 
> > neither any "problem". 
> 
> But gnome-documents *is* the "real app" - if you search from within
> gnome-documents, activating the result will not launch a "random" other
> application, it will open a preview instead. Doing anything else in the shell
> would be okay-ish for a generic "documents" provider, but not for an
> application-provided "gnome-documents" one.

Ok, so you open gnome-documents. That's fine, it's predictable, has no side-effects and everything. And then?
I want my 300 page long PDF in evince, with sidebars, ctrl+f, annotations... I want my OD* in LibreOffice, so I can edit them. I want my ODP presentations in LibreOffice presenter view, with the animations, the sounds, the notes.
You cannot, even if you want, reimplement all these features in gnome-documents, and I believe no one will argue for removing them in the sake of consistency.

You need a way to escalate from the shell to the actual application, possibly through gnome-documents.
(A small "Open with Evince" / "Open with Libreoffice Writer" in the top bar would be cool. Feel free to reassign to gnome-documents)
Comment 9 drago01 2012-03-07 17:08:54 UTC
(In reply to comment #8)
> This cannot be RESOLVED, the original bug is still there.

Yeah I know but I failed to convince jimmac that there is a problem to fix so I gave up.
Comment 10 drago01 2012-03-07 17:10:34 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > This cannot be RESOLVED, the original bug is still there.
> 
> Yeah I know but I failed to convince jimmac that there is a problem to fix so I
> gave up.

Oh and the new search design in 3.6 intends every application that wants to show up there and handle documents to provide each one search provider so libreoffice ought to provide one, evince too etc.

Hence it "will get fixed with the 3.6 design".
Comment 11 Florian Müllner 2012-03-07 17:12:36 UTC
(In reply to comment #8)
> This cannot be RESOLVED, the original bug is still there.

It is not a gnome-documents bug. We could rename the bug to "implement the new search design once the design is ready" and reassign to gnome-shell, but tbh that feels rather pointless (still, not gonna start a close-reopen war here, so leaving that report as-is)


> Ok, so you open gnome-documents. That's fine, it's predictable, has no
> side-effects and everything. And then?
> I want my 300 page long PDF in evince, with sidebars, ctrl+f, annotations... I
> want my OD* in LibreOffice, so I can edit them. I want my ODP presentations in
> LibreOffice presenter view, with the animations, the sounds, the notes.

That's fine, but using gnome-documents to launch a "random" application (from g-d's point of view) is absurd. The provider title of "DOCUMENTS" refers to the application name (e.g. "the application that provides the results and launches when a result is activated"), not to a set of mime types. You are asking for Evince and LibreOffice providers, which is fine (but obviously not doable in the 3.4 timeframe - unfortunately the design update linked above only dates back a couple of weeks). It does not make sense in gnome-documents, so the only way to address this regression in the 3.4 cycle is via an extension imo.
Comment 12 drago01 2012-03-07 17:19:12 UTC
(In reply to comment #11)
> (In reply to comment #8)
> > This cannot be RESOLVED, the original bug is still there.
> 
> It is not a gnome-documents bug. We could rename the bug to "implement the new
> search design once the design is ready" and reassign to gnome-shell, but tbh
> that feels rather pointless (still, not gonna start a close-reopen war here, so
> leaving that report as-is)

But there is no point in leaving it assigned to gnome-documents if we are not going to change gnome-documents at all but fix it at the shell side.
Comment 13 Giovanni Campagna 2012-03-07 17:28:14 UTC
(In reply to comment #11)
> > Ok, so you open gnome-documents. That's fine, it's predictable, has no
> > side-effects and everything. And then?
> > I want my 300 page long PDF in evince, with sidebars, ctrl+f, annotations... I
> > want my OD* in LibreOffice, so I can edit them. I want my ODP presentations in
> > LibreOffice presenter view, with the animations, the sounds, the notes.
> 
> That's fine, but using gnome-documents to launch a "random" application (from
> g-d's point of view) is absurd. The provider title of "DOCUMENTS" refers to the
> application name (e.g. "the application that provides the results and launches
> when a result is activated"), not to a set of mime types. You are asking for
> Evince and LibreOffice providers, which is fine (but obviously not doable in
> the 3.4 timeframe - unfortunately the design update linked above only dates
> back a couple of weeks). It does not make sense in gnome-documents, so the only
> way to address this regression in the 3.4 cycle is via an extension imo.

Uhm... if evince and libreoffice should provide their own search provider, what's the point of gnome-documents then?
I mean, why should I even open a file in "documents" (which is a generic term, btw, is not at all associated with a specific application), if all I can do there can be done better in another specific application?
And on the other hand, what if I launch g-d and search from there? What if I want to edit view a google docs file in evince?
gnome-documents is part of the Finding And Reminding series, it's not a task on its own. There is nothing you can do within g-d, and the preview is just that, a preview helping you understand what you need to do next.
The design you propose is like saying that nautilus should only open files in sushi, it's just absurd. So yes, this is a gnome-documents bug.
Comment 14 Jasper St. Pierre (not reading bugmail) 2012-03-07 17:34:09 UTC
(In reply to comment #11)
> That's fine, but using gnome-documents to launch a "random" application (from
> g-d's point of view) is absurd. The provider title of "DOCUMENTS" refers to the
> application name (e.g. "the application that provides the results and launches
> when a result is activated"), not to a set of mime types.

I don't know what kind of alien language you and the designers speak, but when I see "DOCUMENTS" somewhere I expect it to refer to the English word "documents", not a brand name like "GNOME Documents" or even "Google Documents".

> You are asking for
> Evince and LibreOffice providers, which is fine (but obviously not doable in
> the 3.4 timeframe - unfortunately the design update linked above only dates
> back a couple of weeks). It does not make sense in gnome-documents, so the only
> way to address this regression in the 3.4 cycle is via an extension imo.

That's the wrong way to address this. He's not asking for Evince and LibreOffice search providers (now he has two entries when he searches, and the difference is in the application launched and maybe the thumbnail... wtf?), he just wants to open the document in something more featureful. If GNOME Documents had all the things that Evince/LibreOffice had, he wouldn't be complaining. We need to treat the intermediate step as a preview.

Effectively, GNOME Documents is a tool to find/sort/file documents and not really do anything to the document itself. When I search for a document in GNOME Shell, my goal there isn't to find/sort/file it. An edit/open button in GNOME Documents would be more than enough.
Comment 15 drago01 2012-03-07 17:37:13 UTC
Just for the record here is the IRC discussion we had today:
----
<drago01>	fmuellner, jimmac : are you both really suggesting that search should not be used for editing documents?
<fmuellner>	drago01: no, I'm suggesting that results provided by app "foo" should never open in app "bar"
<jimmac>	drago: we can of course move forward and argue how Documents is useless for you
<drago01>	jimmac: huh? 
<jimmac>	it doesn't edit thus shouldn't be a default handler?
<jimmac>	but if a provider is Contacts, the default action is to open it up in contacts
<drago01>	jimmac: I use it to group / organize documents ... opening a collection with documents makes sense so you can then view and edit them (yes documents allows opening the real app)
<drago01>	jimmac: but opening a document directly with it is kind of pointless yes
<fmuellner>	drago01: it does, but not as the primary action (e.g. click or enter)
<drago01>	fmuellner: I know and don't have a problem with that
<drago01>	jimmac: so asking again should the search in the shell not be usefull for editng purposes?
<fmuellner>	drago01: I think you are missing the point - if a result is provided by LibreOffice, I expect it to open in LibreOffice
<jimmac>	drago01, the search in shell should aggregate a prioritized search from apps
<jimmac>	note that this is just a random iteration, but perhaps an image like this this will illustrate the link between a result and handler better -- http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/search-results.png
<fmuellner>	(note how the new design asks for a fallback provider based on recent-items for applications that don't actually implement their own provider)
<drago01>	jimmac, fmuellner : well doesn't that mean that 1) basically every app should have its own search provider 2) you get the same document (or file) multiple times in the search result
<drago01>	i.e one from libreoffice, one form documents
<drago01>	fmuellner: how would that fallback work? 
<jimmac>	you might need to explicitly enable 3rd party app search providers
<fmuellner>	drago01: that's my understanding of the design, yes (allowing users to selectively enable/disable providers though)
<fmuellner>	drago01: filtering GtkRecent items by application I'd say
<drago01>	fmuellner: I mean when to decide when to use recent items and when not ... lets say you have foo.odt ... gnome-documents provides a search provider , libreoffiice does not
<drago01>	fmuellner: so what do we do? show the result twice? (wasn't that the very reason why we killed the recent items search?) ... exclude it from recent items because a provider exists? (which brings us back to the edit problem)
<fmuellner>	drago01: (note that I first read about the new search design two weeks ago, so I'm not 100% clear on that myself) I would expect that providers for core applications are enabled by default, while users would need to explicitly enable other providers (like LibreOffice) - if they don't disable the corresponding core provider (gnome-documents) at the same time, then I'd expect overlapping result sets, yeah
<fmuellner>	drago01: "unfortunately we have to live with this regression until we get the new search design in 3.6." - compromise suggestion in comment #6 is not an option?
<drago01>	fmuellner: oh sorry missed that
<drago01>	fmuellner: well "off by default" ... we don't have the provider UI yet either
<fmuellner>	(mmh, though an extension might actually be more visible than a hidden option)
<fmuellner>	drago01: yeah, I was thinking gsettings here
<drago01>	fmuellner: yeah in that case we could as well leave it to extensions
-----
Comment 16 Giovanni Campagna 2012-03-07 18:02:22 UTC
... I just discovered that you right-click documents and find a nice (...) popup menu with the "Open with..." I asked for.
I wouldn't call it discoverable, but yeah... it works...
Comment 17 drago01 2012-03-07 18:16:34 UTC
(In reply to comment #16)
> ... I just discovered that you right-click documents and find a nice (...)
> popup menu with the "Open with..." I asked for.
> I wouldn't call it discoverable, but yeah... it works...

That only work when viewing the documents though not in the preview mode. When you are in the preview mode all you can do is to click "back" and the ctrl-f search again and then use right click -> open

In that case what is the point in using the search in the shell at all? You could as well just search open documents directly and search there.

I still think that we should open collections with gnome-documents and documents with the real apps. Everything else is just pointless and does not achieve anything useful from a users POV. 

In the end it boils down to this: we broke search in 3.4 and there is no way to fix it before release and make everyone happy while doing so.

I should have noticed this earlier but oh well ...
Comment 18 Giovanni Campagna 2012-03-07 18:25:45 UTC
No, it works in the preview too (not the nice overlay with the honestly confusing folder icon, just a gtk popup menu). And yes, it makes search in the shell a lot slower, as you need to load the document first in g-d and then in the real app, but oh well...
Comment 19 drago01 2012-03-07 18:28:54 UTC
(In reply to comment #18)
> No, it works in the preview too (not the nice overlay with the honestly
> confusing folder icon, just a gtk popup menu). And yes, it makes search in the
> shell a lot slower, as you need to load the document first in g-d and then in
> the real app, but oh well...

Right click does not do anything here (3.3.90).
Comment 20 Giovanni Campagna 2012-03-07 18:33:57 UTC
(In reply to comment #19)
> (In reply to comment #18)
> > No, it works in the preview too (not the nice overlay with the honestly
> > confusing folder icon, just a gtk popup menu). And yes, it makes search in the
> > shell a lot slower, as you need to load the document first in g-d and then in
> > the real app, but oh well...
> 
> Right click does not do anything here (3.3.90).

Works here (0.3.91-13-geeecdca, which is master + bug 671169). Maybe it was added recently.
Comment 21 Matthias Clasen 2012-10-15 19:12:06 UTC
I think we need to reopen this. The designers may NAK this all day long, but I am receiving overwhelming feedback that it is a problem for people.

gnome-documents is not a useful application to open e.g. a spreadsheet in - the pdf preview it offers is just confusing. And in all cases where I am working on a document and intend to edit it, going first to gnome-documents just to open the editor from there is an annoying detour that people rightly complain about.
Comment 22 Jasper St. Pierre (not reading bugmail) 2012-10-15 20:26:16 UTC
Opening multiple documents is also a pain, as gnome-documents just happily replaces my open document, losing all the state I had.
Comment 23 drago01 2012-10-15 20:53:14 UTC
Review of attachment 209139 [details] [review]:

This patch still applies as is ... removing the rejected based on the recent comments (i.e results of real world testing).
Comment 24 Florian Müllner 2012-10-15 21:06:02 UTC
(In reply to comment #21)
> I think we need to reopen this. The designers may NAK this all day long, but I
> am receiving overwhelming feedback that it is a problem for people.
> 
> gnome-documents is not a useful application to open e.g. a spreadsheet in - the
> pdf preview it offers is just confusing. And in all cases where I am working on
> a document and intend to edit it, going first to gnome-documents just to open
> the editor from there is an annoying detour that people rightly complain about.

But isn't that addressed by the Files search provider? That one behaves exactly like Adel's patch, e.g. it opens results in the preferred application. Having search providers for two core applications do exactly the same sounds completely pointless ...
Comment 25 Allan Day 2012-10-15 22:10:38 UTC
I haven't extensively used the documents and files search providers in conjunction, so I don't feel that I can comment with a huge amount of personal insight. A few preliminary remarks, though:

 * I think we probably should make it clearer how to open a document from within documents. Perhaps an Open With menu could be put in the toolbar when previewing?

 * According to the model that we've been pursuing so far, I would expect files search results to be opened in a preview within files itself. See the wireframes for an example of how such a preview could work: https://live.gnome.org/Design/Apps/Files#Tentative_Design

 * When the identity of a search result is uncertain, a preview is *super* useful before launching a potentially heavy-weight editing app.

 * As Documents matures, it will offer more options for things you can do with a document, like sharing it.

 * We are planning to allow people to customise which search providers are used by the shell, as well as the order in which results are presented.

That said, I understand that this issue is causing some frustration, and I do think we should keep an eye on it this cycle. I'm sure that there are other options that would be consistent with the overall approach that we're trying to take for content/search providers.
Comment 26 drago01 2012-10-15 22:14:42 UTC
(In reply to comment #24)
> (In reply to comment #21)
> > I think we need to reopen this. The designers may NAK this all day long, but I
> > am receiving overwhelming feedback that it is a problem for people.
> > 
> > gnome-documents is not a useful application to open e.g. a spreadsheet in - the
> > pdf preview it offers is just confusing. And in all cases where I am working on
> > a document and intend to edit it, going first to gnome-documents just to open
> > the editor from there is an annoying detour that people rightly complain about.
> 
> But isn't that addressed by the Files search provider? That one behaves exactly
> like Adel's patch, e.g. it opens results in the preferred application. Having
> search providers for two core applications do exactly the same sounds
> completely pointless ...

Yeah true (for 3.6) if we start to eliminate duplicates in 3.7/8 (i.e have
nautilus filter out files that are handled by other core apps) we'd have this
problem again.

Regardless of that having documents under the FILES section doing the right
thing from the users POV and having the same results in a section called
DOCUMENTS that do not are kind of odd ... users will probably find out whats
the difference between the two is after some time but I doubt many users will
associate the generic word "DOCUMENTS" with the app gnome-documents rather then
with the word documents i.e "those are my documents" not "those are the files
that are going to be opened by the documents app".

This whole thing is a mess really and needs to be fixed somehow.
Comment 27 drago01 2012-10-15 22:27:20 UTC
(In reply to comment #25)
> I haven't extensively used the documents and files search providers in
> conjunction, so I don't feel that I can comment with a huge amount of personal
> insight. A few preliminary remarks, though:
> 
>  * I think we probably should make it clearer how to open a document from
> within documents. Perhaps an Open With menu could be put in the toolbar when
> previewing?

The discoverbility of the "Open with" isn't the problem here .. but the fact that one has to go through this indirection in the first place is.

>  * According to the model that we've been pursuing so far, I would expect files
> search results to be opened in a preview within files itself. See the
> wireframes for an example of how such a preview could work:
> https://live.gnome.org/Design/Apps/Files#Tentative_Design

That's just as broken as this. This is not what users expect. We should fix this problem instead of doing the same mistake again.

>  * When the identity of a search result is uncertain, a preview is *super*
> useful before launching a potentially heavy-weight editing app.

Yeah in that case you should have an option to open a preview (ex. sushi) but it shouldn't be the primary action.

>  * As Documents matures, it will offer more options for things you can do with
> a document, like sharing it.

I don't see how this is relevant here. Sure you can do a lot of things with gnome-documents but the primary action should be to just open whatever app is supposed to handle the file in question, if you want this to be documents because your primary use of documents is reading and sharing them you can configure documents to be the default app for that particular file type (we probably need a better UI for configuring that). 

>  * We are planning to allow people to customise which search providers are used
> by the shell, as well as the order in which results are presented.

This does not really help, ordering isn't the problem here.

> That said, I understand that this issue is causing some frustration, and I do
> think we should keep an eye on it this cycle. I'm sure that there are other
> options that would be consistent with the overall approach that we're trying to
> take for content/search providers.

I am sorry but as long as you assume that editing documents is a corner case rather then a primary use case any design you create would not address this (i.e you are designing in the wrong direction).
Comment 28 drago01 2012-10-18 18:01:04 UTC
(In reply to comment #27)
>
> I am sorry but as long as you assume that editing documents is a corner case
> rather then a primary use case any design you create would not address this
> (i.e you are designing in the wrong direction).

Well or after looking at the design pages it seems the the problem comes from the fact that you base your designs on the designs of both WebOS and iOS, which is not a problem in itself but given that this OSes are mainly used for content consumption devices (tablets, smartphones) it explains why editing is considered a corner case (because it is on the devices where both of this OSes are used).

So please think about this when designing for an interface that is supposed to be used on general purpose computers, because people do use them to create and edit content. Not just viewing and reading. Editing documents is *not* an obscure corner case here.
Comment 29 António Fernandes 2012-10-21 16:04:15 UTC
(In reply to comment #27)
> >  * According to the model that we've been pursuing so far, I would expect files
> > search results to be opened in a preview within files itself. See the
> > wireframes for an example of how such a preview could work:
> > https://live.gnome.org/Design/Apps/Files#Tentative_Design
> 
> That's just as broken as this. This is not what users expect.

Why not? Which users?

Taking into consideration the information from the recent user observation hackfest [0], this sort of intermediate step matches what users from Largo expect [1]. Please note that editing documents is a primary use case there, as documented by observation notes [2,3].

[0] https://live.gnome.org/Hackfests/UserObservationOrlando2012
[1] Relevant data: «Only ONE person out of 800 disabled the MIME helpers for a more traditional PC environment!» http://people.gnome.org/~federico/misc/2012_user_observation.pdf 
[2] https://live.gnome.org/Hackfests/UserObservationOrlando2012/ObservationNotesGroup1
[3] https://live.gnome.org/Hackfests/UserObservationOrlando2012/ObservationNotes2/
Comment 30 Jasper St. Pierre (not reading bugmail) 2012-10-21 16:12:24 UTC
(In reply to comment #29)
> Taking into consideration the information from the recent user observation
> hackfest [0], this sort of intermediate step matches what users from Largo
> expect [1]. Please note that editing documents is a primary use case there, as
> documented by observation notes [2,3].

The MIME bars there were small intermediate Python scripts, not a fully-fledged application that requires Clutter and takes 10 seconds to load.

The big deal breaker for me is that again, gnome-documents can only see one document at a time. Making it a multi-window application or tabbed application would help a lot.
Comment 31 drago01 2012-10-21 17:28:10 UTC
(In reply to comment #29)
> (In reply to comment #27)
> > >  * According to the model that we've been pursuing so far, I would expect files
> > > search results to be opened in a preview within files itself. See the
> > > wireframes for an example of how such a preview could work:
> > > https://live.gnome.org/Design/Apps/Files#Tentative_Design
> > 
> > That's just as broken as this. This is not what users expect.
> 
> Why not? 

Because it wastes time instead of having quick access to something you get an intermediate step that is adding no value at all. The overview search has always been a way to quickly access stuff and it worked very well in practice, we broke it in 3.4 with the removal of the recent search provider and the introduction of the gnome documents search one. In 3.2 it was a nice and quick way to access the files you are working on. In 3.4 I have never used the overview search to open documents or files I have been working on anymore. It just does not work. While in 3.2 I have always used it multiple times a day. In 3.6 this works again because of how the nautilus search provider works. This design asks for breaking it again. We should learn from the mistakes we did in the past (3.4) and not repeat them again. The designers so far failed to identify a problem they intended to solve with the new design (neither in this bug nor in the numerous IRC discussions). Adding search providers for special cases like contacts makes sense the rest isn't really.

Showing a preview only makes sense when you see them directly when chosing the results (thumbnails) in that case they help you find what you are looking for (like when browsing photos or videos). Opening an application to just show the preview breaks your workflow; you have to close it or if you don't you have to go back to the overview to search and try again in case you have opened the "wrong" file. What would you (as a user lose) by opening the file in question in the app configured for it? You have to start an application anyway. If you just want to read the document you can still do so. If you want to edit the document you can do that. If it is the "wrong" one you have to go back and try again. so it adds a cost without a gain. If the only problem is "the apps takes to long to start" ... we should fix that (and in fact you would have to pay that cost only once when opening the app for the first time).

> Which users?

Pretty much all users I have talked to or got them to use GNOME3. I have so far pointed them to the tracker search extension which brings back sane search behaviour.
Comment 32 drago01 2012-12-09 20:24:43 UTC
*** Bug 689856 has been marked as a duplicate of this bug. ***
Comment 33 William Jon McCann 2013-01-21 09:51:44 UTC
Wow, lots of drama here.


It is a cute trick to suppose that the shell or anything else can know what the user "intends" to do. The best we can do is deliver the (hopefully correct) document to the user. That is what we are doing. Once we deliver the document to the user we do the obvious thing in order for the user to verify it is indeed the desired item: we display it. 

If the preview of any type of document is poor - we need to find a way to fix it. We need them to be accurate for the file chooser, Nautilus etc. as well.

After displaying it we attempt to present the most common actions. Yes Edit is one of them. For some documents, it may be the primary action. For others it will be secondary. For still others it will not be available - if the content is read-only and/or shared by someone else.

Documents already has the ability to quickly launch an editor once you are sure the document you've found is the right one. This will improve very soon as I hope to land support for editing Google documents directly from the Documents app window - without launching another tool.

It makes sense to separate these read and edit modalities.

If you hate this, you now have the ability to turn off the Documents search or put it lower than Files searches.

Additional functionality will be landing this cycle and next that makes it more likely you do what you need done in Documents rather than going to another app. Things like:

 * Emailing a doc
 * Presenting a doc
 * Sharing a doc online
 * Editing google docs
 * Editing annotations and comments

Now, if any of you want to help out with this stuff that would be great. But I don't think any of that stuff is going to get done in this bug report.
Comment 34 drago01 2013-01-21 10:08:50 UTC
(In reply to comment #33)
> Wow, lots of drama here.

Not drama but a problem that needs to be solved.
 
> It is a cute trick to suppose that the shell or anything else can know what the user "intends" to do.

It shouldn't and can't know that it just makes the live harder for one action for no real gain.

> The best we can do is deliver the (hopefully correct)
> document to the user.

We already do that but then make the user jump through hops unnecessarily. 

> That is what we are doing. Once we deliver the document
> to the user we do the obvious thing in order for the user to verify it is
> indeed the desired item: we display it. 

OK.

> If the preview of any type of document is poor - we need to find a way to fix
> it. We need them to be accurate for the file chooser, Nautilus etc. as well.

Poor preview is not the primary issue here (just one thing noted).

> After displaying it we attempt to present the most common actions. Yes Edit is
> one of them. For some documents, it may be the primary action. For others it
> will be secondary.

Yes and the way we handled this in the past was by having a specific app configured for the file type. A pdf opens in evince and spreadsheet in calc. A image is opened in the image viewer in case a user thinks "I regularly edit images a viewer is not enough" he/she can configure another app as default (like GIMP).

Yes we don't have the best UI for that but that can / should be fixed.

> For still others it will not be available - if the content
> is read-only and/or shared by someone else.

Most editing apps can deal with that just fine ... try to open a read only document in writer for example.
 
> Documents already has the ability to quickly launch an editor once you are sure  the document you've found is the right one.

Not really ... it provides a way to edit it but that is not quickly. 
Before I could do Super + "whatever" + enter and edit right away.
Now a different window is opened where I have to go and click on the edit button / menu entry (I do have to switch to mouse / touchpad). 

If I could do something like press a shortcut to close the window and open the "real app" it might indeed work as a preview (even though a bit slower then the direct opening).

> This will improve very soon as I
> hope to land support for editing Google documents directly from the Documents
> app window - without launching another tool.

That's good and makes a lot of sense ... in that case opening Google Documents with Documents makes sense and should be the default action. As for other (local) documents it cannot do that so it isn't the appropriate app.
 
> It makes sense to separate these read and edit modalities.

Why?

> If you hate this, you now have the ability to turn off the Documents search or
> put it lower than Files searches.

I though Files is going to change to to the same behavior? (At least that is what Florian told me). 

If that is not the case this is reasonable to say "then move files up".

(Files search does not work at all right now but that's a bug).

If the intend is to leave the Files search provider as is (i.e opening the real app) then we can close the bug.

Otherwise we just have a temporary solution.
Comment 35 drago01 2013-01-21 10:18:31 UTC
Thanks Jon, best way ever to have a discussion.
Comment 36 Milan Bouchet-Valat 2013-01-21 10:41:26 UTC
I'd like to note I stand with Adel here, because I believe he expressed the concerns that many users will agree with. This is going to create another big rant against GNOME designers that feel their users are silly, and I don't like giving these solid arguments to trollers.

Opening Documents as a means to launch the appropriate application does not make any sense. I wouldn't dare arguing why it works that way to users I upgrade to a new version - they will simply don't understand. It's just like opening the file in Nautilus: it's nice and you can do many things with the doc, but it's not what you would expect by default.

Turning off Documents search is not a solution, it's a workaround, as the proposed solution is not optimal for anybody.
Comment 37 t.ask 2013-01-22 19:20:09 UTC
Good to see the discussion is still open. I opened the upper duplicate bug report and I'm still concerned that with Gnome 3.8 nothing is getting clearer with this important issue.

I can't see why Gnome Documents is still in discussion. Previewing files of any kind in one large previewer without any edit functions is only useful for presentations, "send to" operations and maybe for previewing the documents before printing them.

Why do we open Documents at all? Working with the old and nice "file type = action" mechanism just works fine. Define which file type opens with which application is just fine. And this should be the default action within Gnome Shell Actions, too. It's logical and easy to customize.

If someone likes to open files with Documents first, then he simply assign the files to Documents. Forcing the user to accept that Documents opens for everything by default will bring up trouble for sure. Consider Gnome is installed as default Desktop in a company with thousands of clients :(

Please remove Documents like it's implemented currently and maybe let file icons show previews or add a small preview thumbnail into the Gnome Shell Actions search results.

Maybe it would be an idea to start a survey on these kind of topics?!
Comment 38 t.ask 2013-01-22 19:20:27 UTC
Good to see the discussion is still open. I opened the upper duplicate bug report and I'm still concerned that with Gnome 3.8 nothing is getting clearer with this important issue.

I can't see why Gnome Documents is still in discussion. Previewing files of any kind in one large previewer without any edit functions is only useful for presentations, "send to" operations and maybe for previewing the documents before printing them.

Why do we open Documents at all? Working with the old and nice "file type = action" mechanism just works fine. Define which file type opens with which application is just fine. And this should be the default action within Gnome Shell Actions, too. It's logical and easy to customize.

If someone likes to open files with Documents first, then he simply assign the files to Documents. Forcing the user to accept that Documents opens for everything by default will bring up trouble for sure. Consider Gnome is installed as default Desktop in a company with thousands of clients :(

Please remove Documents like it's implemented currently and maybe let file icons show previews or add a small preview thumbnail into the Gnome Shell Actions search results.

Maybe it would be an idea to start a survey on these kind of topics?!
Comment 39 t.ask 2013-01-22 19:25:15 UTC
Yes, let the user open the default app first. That's handy and intuitive, too.

Maybe, we could enter a mechanism, that on the first opening of one unassociated file type, pops up a list for selecting the default app and possibly action once.
Comment 40 t.ask 2013-01-22 19:57:56 UTC
Yes, let the user open the default assigned app first. That's handy and intuitive, too.

Maybe, we can enter a function that opens a list of possible default apps for this "unassociated" app.
Comment 41 Dave Neary 2013-03-08 19:40:46 UTC
Just catching up with this bug report. I was about to report it myself, because in combination with a different issue it adds up to a lot of frustration.

When I type a few characters of a filename, and I see it in the heads-up view, I click on it. If it's an OpenOffice file, I get the message attached. Then I go back to the Documents view, re-search for the file, and then have to right click to select the file, and then click on the folder icon to open it.

I realise I'm using 3.4, and some of this has been updated in 3.6 and 3.8 (right-click "Open with..." in the desktop view, for example) but when I'm looking for files with Shell, my expectation was that this would (basically) be a nice shortcut to finding files on the filesystem, and that clicking here would do the same thing as a double click in Nautilus. For the longest time (until I discovered that the folder icon opened the file) I reverted to "Open Nautilus, and spend time hunting for the file".

If clicking on a .ods or .odp file in the Shell search opened OpenOffice, I would be very happy.
Comment 42 Dave Neary 2013-03-08 19:42:09 UTC
Created attachment 238395 [details]
Step 1 (search for file)
Comment 43 Dave Neary 2013-03-08 19:43:59 UTC
Created attachment 238396 [details]
Step 2 (No preview, and no close button)
Comment 44 Dave Neary 2013-03-08 19:44:37 UTC
Created attachment 238397 [details]
Step 3 (to open file, need to right click to choose, then click on the folder icon to open)
Comment 45 António Fernandes 2013-03-08 20:00:57 UTC
(In reply to comment #41)
> I realise I'm using 3.4, and some of this has been updated in 3.6 and 3.8
> (right-click "Open with..." in the desktop view, for example) but when I'm
> looking for files with Shell, my expectation was that this would (basically) be
> a nice shortcut to finding files on the filesystem, and that clicking here
> would do the same thing as a double click in Nautilus. For the longest time
> (until I discovered that the folder icon opened the file) I reverted to "Open
> Nautilus, and spend time hunting for the file".
> 
> If clicking on a .ods or .odp file in the Shell search opened OpenOffice, I
> would be very happy.

This is what happens in GNOME 3.6 and what will happen in GNOME 3.8 when you click on a "Files" search result.

This report is about the "Documents" search results, not the "Files" search results. "Files" provider did not exist in GNOME 3.4, but it does since 3.6.

Most likely, this report wouldn't even exist had "Documents" and "Files" providers been introduced at the same time. GNOME 3.4 was a transitory step from the old "Recent Documents" implementation to the new search providers system, and resulted in a regression of sorts.
Comment 46 Florian Müllner 2013-03-08 20:30:21 UTC
Exactly.

Activating a result from Documents => do the same thing that happens when clicking a document in Documents

Activating a result from Files => do the same thing that happens when clicking a file in Files

(however I'll readily admit that our use of generic application names is utterly confusing here)