Basic layout is there. As @mvahowe mentioned we need to decide whether we want forked bundles to show up when expanding the originating revision. I think for now, we can try to live with them being separate bundles and see what that's like.
@ericpyle Well, if we do the auto-fetch thing we seemed to be agreed on, and we use the DBL Unit Test credentials, you're going to get 600 revisions for one entry.
(If we don't download all the revisions, we need a way for the user to ask for a specific revision of an entry that isn't local, which takes us back to a second way to list bundles.) If we have an entry/revision hierarchy, we can grab the most recent revision of each entry and then have an "other revisions" thing for each of those entries.
@mvahowe we don't want to show all uploaded revisions. Just latest. I'm sure of that. We could allow them to fetch an earlier revision somehow, if needed
@mvahowe just curious. what is a viable use-case for a user fetching previous revisions in order to make a bundle from them? I know DBL is an archive, but for uploads and downloads, I've only known users to care about the latest revision of an entry.
Obviously bundles of previous revisions that are already on disk should show up unless the user deletes them. That's kind of like clean-up. I kind of think we should wait until users explain why they'd really want to get those back.
If we do support showing previous revisions, we could collapse them under the latest revision as you suggest, or we could have essentially a navigation that just shows the revisions of one entry. If they select one to download, then it would be added to the list of bundles.
@mvahowe also, if dbl dot local wants to download all the revisions, I'd say okay as long as it downloads the latest revisions first, and Nathanael will filter them out unless the user does something special to get at them.
@ericpyle I know that the current workflow with UBS/Compass is to specify a specific revision from which to make the braille. I believe that the logic is that braille readers in a "mixed" congregation want the same text as whatever the sighted people have in their pews.
Another case is audio which is often not related to the most recent text.
We'll also rapidly accumulate revisions when people start making modifications. ie
I download revision 3
I start work on it, at which point I have revision 3 plus revision 0
I upload revision 0, which turns into revision 4 (to avoid having to download the new entry for which we may have all the resources), so now we have revision 3 and revision 4
I think that automatically downloading the latest revision metadata is the way to go. We can then hang some sort of "download a previous revision" button off that latest revision. But I can still see users rapidly ending up with 5 revisions of the same entry locally, and that's going to fill up most of the screen with your current design, if they filter by entry, language, title and everything else apart from revision. So I think planning from the start to group revisions under entries is a good idea because, if not, I expect it to be among the first changes users ask for.
I don't think this requires a huge UX redesign, at least at the "pixels" level. On the abstract mockup above we could replace the text "Revision 3" with a pop-up menu or dialogue that lists all the revisions, with some way to see
which revisions are local
the mode of the local revisions (eg are they uploading or downloading or being drafted)
is this revision the latest
and then we show details of whichever revision is selected (by default, latest), below. I can't think of a case where the user will need to actively work on two different revisions to perform any one specific task, so I don't think we need to worry about seeing multiple revisions of the same entry at the same time. (Or, if we ever decide to that, it would be a "compare revisions" sort of thing with its own UX.)
We can provide a dbl_dot_local "tell me about an entry" endpoint to make generating that menu relatively painless.
@mvahowe I like your suggestion re: Revision. Given that the user will not need to work on two different revision to perform any one specific task, we can make the Revision a button or pull down that allows them to select previous ones.
Also I just realized that Nathanael is not showing the Revision yet.
@ericpyle commented on Thu Apr 19 2018
Remaining tasks:
@ericpyle commented on Thu Apr 19 2018
From Abstract mockup (https://app.goabstract.com/projects/7e90e100-1d85-11e8-b899-693607ce4830/branches/master/commits/860acf905190d4c41e1d5cc616671d174f6a3778/files/FADEAC04-A97F-401E-8B8F-EB5C4D3793AF/layers/71379139-377A-44AC-8790-454563320974?pageId=0EC89917-F949-4461-A7B3-32A5201FD2A2)
@ericpyle commented on Thu Apr 19 2018
Currently looks like
@ericpyle commented on Wed Apr 25 2018
@ericpyle commented on Wed Apr 25 2018
Basic layout is there. As @mvahowe mentioned we need to decide whether we want forked bundles to show up when expanding the originating revision. I think for now, we can try to live with them being separate bundles and see what that's like.
@mvahowe commented on Wed Apr 25 2018
@ericpyle Well, if we do the auto-fetch thing we seemed to be agreed on, and we use the DBL Unit Test credentials, you're going to get 600 revisions for one entry.
@mvahowe commented on Wed Apr 25 2018
(If we don't download all the revisions, we need a way for the user to ask for a specific revision of an entry that isn't local, which takes us back to a second way to list bundles.) If we have an entry/revision hierarchy, we can grab the most recent revision of each entry and then have an "other revisions" thing for each of those entries.
@ericpyle commented on Wed Apr 25 2018
@mvahowe we don't want to show all uploaded revisions. Just latest. I'm sure of that. We could allow them to fetch an earlier revision somehow, if needed
@ericpyle commented on Wed Apr 25 2018
@mvahowe just curious. what is a viable use-case for a user fetching previous revisions in order to make a bundle from them? I know DBL is an archive, but for uploads and downloads, I've only known users to care about the latest revision of an entry.
Obviously bundles of previous revisions that are already on disk should show up unless the user deletes them. That's kind of like clean-up. I kind of think we should wait until users explain why they'd really want to get those back.
If we do support showing previous revisions, we could collapse them under the latest revision as you suggest, or we could have essentially a navigation that just shows the revisions of one entry. If they select one to download, then it would be added to the list of bundles.
@ericpyle commented on Wed Apr 25 2018
@mvahowe also, if dbl dot local wants to download all the revisions, I'd say okay as long as it downloads the latest revisions first, and Nathanael will filter them out unless the user does something special to get at them.
@mvahowe commented on Thu Apr 26 2018
Nathaniel - I like it!
@ericpyle I know that the current workflow with UBS/Compass is to specify a specific revision from which to make the braille. I believe that the logic is that braille readers in a "mixed" congregation want the same text as whatever the sighted people have in their pews.
Another case is audio which is often not related to the most recent text.
We'll also rapidly accumulate revisions when people start making modifications. ie
I think that automatically downloading the latest revision metadata is the way to go. We can then hang some sort of "download a previous revision" button off that latest revision. But I can still see users rapidly ending up with 5 revisions of the same entry locally, and that's going to fill up most of the screen with your current design, if they filter by entry, language, title and everything else apart from revision. So I think planning from the start to group revisions under entries is a good idea because, if not, I expect it to be among the first changes users ask for.
I don't think this requires a huge UX redesign, at least at the "pixels" level. On the abstract mockup above we could replace the text "Revision 3" with a pop-up menu or dialogue that lists all the revisions, with some way to see
and then we show details of whichever revision is selected (by default, latest), below. I can't think of a case where the user will need to actively work on two different revisions to perform any one specific task, so I don't think we need to worry about seeing multiple revisions of the same entry at the same time. (Or, if we ever decide to that, it would be a "compare revisions" sort of thing with its own UX.)
We can provide a dbl_dot_local "tell me about an entry" endpoint to make generating that menu relatively painless.
@ericpyle commented on Thu Apr 26 2018
@mvahowe I like your suggestion re: Revision. Given that the user will not need to work on two different revision to perform any one specific task, we can make the Revision a button or pull down that allows them to select previous ones.
Also I just realized that Nathanael is not showing the Revision yet.
@ericpyle commented on Fri Apr 27 2018
Added Revision column (not yet a button/control)