search

aurimasv / zotero

https://zotero.org
Other
1 stars 1 forks source link

Feed Discovery: UX #6

Open aurimasv opened 10 years ago

aurimasv commented 10 years ago

This is an issue to establish the non-technical aspects of the user interface/experience

The project requirements state that

New publications will appear in dedicated, read-only collections within the Zotero application, and users will need only to drag and drop these items into their personal or group library to collect the full object metadata and any associated files like PDFs and web snapshots

I propose that the feeds will be displayed in a separate pseudo-library:

In the right-hand pane, information about individual items in the feed will be displayed.

The center pane will display a list of items from a feed or a collection of feeds:

Remaining questions:

Blocker for #4

CC @dstillman @simonster @stakats

dstillman commented 10 years ago

(You can assume agreement with anything not quoted, except where noted.)

I propose that the feeds will be displayed in a separate pseudo-library

Yes, precisely.

Feeds will function similarly to how collections function currently (right-click on library or collection to add a feed)

Yes, and probably an Add Feed button next to Add Group. Alternatively a single Add button for the left pane with a drop-down menu, but that might be a bit too much friction for the New Collection action.

"Add Feed" dialog will request the user for the feed URL and an optional feed title (e.g. the new "Add link to URI" dialog)

Feeds already have titles, so the title should probably just be editable after the fact.

Also, definitely not necessary for the first version, but if it's easy it'd be nice to load a given non-feed URL in the background and see if we can auto-discover a feed URL from there.

Feeds will be editable via right-click menu and will display the same dialog as for adding the feed.

Well, what's editable? The title can be edited inline. I'm not sure the feed URL should be editable. It's not in Thunderbird or Feedly, for example. If the feed URL changes, it's quite possible the ids would also change, which would cause everything to be redownloaded and marked as unread anyway. Probably easier to just delete and recreate the feed.

But there may be other options that need to be editable, such as update frequency.

When feeds are fetching new information from the web, they will display an indicator.

A status indicator to the right is tricky — at least when I played with it before, I could only do it in another column, which meant that collection names were artificially shortened. It's probably possible to update the left icon, though. I can give some pointers for this when the time comes, though this obviously isn't a priority.

does it need to be configurable per feed? Some sites update content much more often than others

Yeah, I guess this would be nice.

Dragging feeds between collections will move them. I cannot think of a good use case for making copies of a feed.

Yes, just moving, no copying.

Raw data will be displayed under "Feed" tab

That's what I was thinking too (maybe not called "Feed", but the same idea), but I'm not sure that actually makes sense:

description (same as Abstract, but always expanded, since this should be the main focus)

Since this is the main focus, it actually doesn't seem great to take up space with metadata that will mostly be a repeat of what's in the middle pane. I wonder if we want to either A) have the metadata available only in the middle pane and have the right-hand pane just be the summary/content or B) have the primary tab be the content and a second tab be info (which is weird in the context of Zotero's usual item pane configuration, but probably more appropriate here). Or C, I suppose, use a different sort of layout in the right-hand pane that's mostly content but shows the title/author/date at the top without taking up too much space. (With C, you could arrow-key through the feed without moving your eyes from the right-hand pane, and the title might also be longer than is displayed inline in the middle pane.) I think C is the place to start. (I also had a D, which was to display the content as an attached note, but that seems annoying to navigate.)

For items that have available translators, we will display fetched metadata in the same format as we do now.

OK, so I don't think we want to do this. The way we've always envisioned it, translation happens when you drag a feed entry to your library, not before. Particularly since translators trigger one or more HTTP requests per entry, doing that for every item in every feed seems like a bad idea. Obviously there are feed readers that can cache target pages, but usually not for all entries by default, and our traffic also has a somewhat different pattern that can look more like abuse. It seems totally sufficient to me to just show the metadata from the feed, particularly since you can still double-click to go to the actual web page, which for these will always work.

[Skipping various things that are irrelevant given the above.]

It will be possible to drag and drop items from the center pane into personal or group libraries

Yes, and this will trigger translation if possible.

What would dragging the same item multiple times do?

I think skip, using the same sort of behind-the-scenes link as other inter-library drags? That will let people drag things of interest without worrying about whether they were already dragged.

How many items from the feed do we display? All? Configurable? Do we keep items that were previously retrieved from the feed? How long do we keep them for? (probably configurable)

Don't know on these.

In either case, is there any need to be able to mark items that should be kept indefinitely? While this is a common feature in feed readers, I don't think it is necessary here, since whatever item you want to keep, you can just drag to your library.

Agreed.

Do we need to be able to clear/delete items from the list?

I don't think so.

Does the feed list sync?

Yes, unfortunately.

I'm guessing that yes, in which case, I think we would want to sync the list, the viewed/not-viewed info, and the fetched metadata (so we don't have to re-fetch it on each client).

Yes to the first two (and maybe some feed-specific settings). If by fetched metadata you mean translated metadata, then no, as per above. If you mean the metadata from the feed, I really don't want to sync that — that's a ton of additional synced data, and having multiple clients download a feed isn't a big deal. The only complication is if we want to be able to view feeds online, but I'm not sure we care about that — and if we do, the server could fetch for itself, using aggregated subscriptions.

In general, I think the larger question for all of this is whether we're actually trying to compete with people's normal feed readers or whether we have a more limited goal of giving them an additional way to get things into Zotero.

aurimasv commented 10 years ago

In general, I think the larger question for all of this is whether we're actually trying to compete with people's normal feed readers or whether we have a more limited goal of giving them an additional way to get things into Zotero.

Hmmm, if we're not going to be performing translation for the items in the feed (before they are dragged), then this introduces very little benefit to just having a feed reader, following the link to the article you want to save, and clicking the URL bar icon (there's possibly even a way for us to make drag-drop from the feed reader work). I'm not so much interested in the general metadata (which is actually quite rich in, for example, Nature's feeds), but I would definitely like to allow an easy way for the users to get to the PDF of the article (not present in the feed).

Yes, some feeds are long and fetching metadata for all items would generate a ton of HTTP requests, but that should only happen when the feed is initially added. For feed updates, we're probably looking at around 20-40 items per update per feed, which is not that bad. I don't think we would flood the server with requests, but do this in small chunks. That's where caching the data and then syncing it comes into play so we don't do this more than we need to.

I'll have to think about this some more, but I would like to offer the user some more convenience than just displaying abstracts (though I don't suppose a lot of people use Feed readers, so this may be a nice improvement for them anyway)

dstillman commented 10 years ago

I would definitely like to allow an easy way for the users to get to the PDF of the article (not present in the feed)

Well, that's kind of on the feed author. Feeds provide a mechanism for making a file available (and that file could easily be gated). Just because Nature doesn't happen to be doing that doesn't mean that we should add a huge amount of complexity and resource usage to Zotero to make up for what should be a single additional line in each feed entry.

though I don't suppose a lot of people use Feed readers, so this may be a nice improvement for them anyway

This is more the point, I think. But even for people already using feed readers, it's also just to make triage of Zotero-related feeds much easier, so you don't have to go to each article page to add it (though translators for more web-based feed readers would help too).

(On an unrelated note, testing this out with Nature's feeds, I noticed that our proxy support may be a problem here, at least with aggregated subscriptions on the server — with Nature's feeds, the proxied URIs make it into all elements of the feed. So I think we'll want to bypass proxying for the feed itself.)

dstillman commented 10 years ago

But we certainly could display an attachment if there's one in the feed, and we could perhaps let the user manually kick off a translation for a feed entry to open the attachment without saving the item.

dstillman commented 10 years ago

And some sort of searchable crowdsourced directory when adding a feed (like what Feedly does) could also be a possibility down the line, particularly since this project is all under the heading of "discovery". Zotero for Firefox (and maybe the connectors at some point) could also notice available feeds on the current page and offer to add them (somehow, though I'm not sure where).

aurimasv commented 10 years ago

Well, that's kind of on the feed author. Feeds provide a mechanism for making a file available (and that file could easily be gated). Just because Nature doesn't happen to be doing that doesn't mean that we should add a huge amount of complexity and resource usage to Zotero to make up for what should be a single additional line in each feed entry.

That's the thing though, I'm not seeing links to PDFs on any of the feeds:

Zotero for Firefox (and maybe the connectors at some point) could also notice available feeds on the current page and offer to add them (somehow, though I'm not sure where).

Yes, I was thinking the same. My thought was to add an additional URL bar icon and offer a feed on pretty much any page that the translator recognizes (if a feed for the related journal or section or search is available). Finding feeds for some of these sites takes some time and you have to know what you're looking for.

aurimasv commented 10 years ago

But we certainly could display an attachment if there's one in the feed, and we could perhaps let the user manually kick off a translation for a feed entry to open the attachment without saving the item.

I guess that could be a good start. We'll see where this takes us.

aurimasv commented 10 years ago

Also, some of the feeds have very poor description elements (e.g. ACS and Science), so I would really like to fetch at least abstracts where this is the case. We could maybe make this configurable per feed, though I feel like it would be too technical for the user to understand (why would you not want to always fetch more info?)

dstillman commented 10 years ago

we could perhaps let the user manually kick off a translation for a feed entry to open the attachment without saving the item

We talked about this a bit more. It does seem like we need to do some sort of translation pre-drag, since the data is often so bad. With no abstract and no PDF, how do you even know whether it's worth importing the item?

We're still uncomfortable with automatic translation of new items, but we think it'd be sufficient and acceptable to do two things:

1) Kick off translation when an item is selected and display the results in the right-hand pane (and/or a separate abstract pane, wherever that might go)

2) Load the attachment on double-click, falling back to the URL (waiting for the translation kicked off by the single-click to finish)

I think with those two things, and the ability to then drag the item into a library, we provide a good amount of value over a regular feed reader.

I don't think we need to sync the fetched metadata.

We probably want to pair this with the previously discussed but unresolved redesign of the Info pane (which maybe can be paired with finding a more suitable place for abstracts in general).