I've been thinking a little bit about how to upgrade the save function in Serendip-o-matic, and I thought I'd describe what I have in mind and get some feedback before doing anything. So here's my idea:
The save function would open a modal dialog with a list of results. Each line would have a small thumbnail, the image title, the image date, its source, the aggregator we got from, and its URI. The thumbnail would be mainly for identification, but it and the title could certainly be links opening the source in a new window.
About the easiest way to do this is to write the
containing the modal content as the page is loading, but I'm not really a fan of crowding the DOM with lots of hidden elements (especially if we start displaying larger numbers of results), and it makes it a little more awkward to generate a download. Typically, the results would be written to a temporary file or to a session variable. Rebecca or Eli, what is the current status of session handling? Is there an approach you'd recommend?
Assuming we can save the results to a session or temporary file, it would be possible to put checkboxes next to each result so that the user could select or deselect them. We could even make the thumbnails function as checkboxes (though they wouldn't then be links). Of course, we could also do "Select All" and "Unselect All" buttons/checkboxes.
There would also be a Download button (text/csv) and a Save to Zotero button (can we do this?).
What do people think of this approach? Any features I have missed?
I think we definitely need to consolidate the 'saveme' page with the primary results page, because otherwise it's going to be too easy for the result generation logic to get out of sync (particularly given that there's already some randomness at least to the order, and I think we're hoping to add a bit more randomness in the results selected).
We could save the data in the session (we've already got django sessions configured in use, so that part is not hard), but I think we'd have to save quite a bit of data to be able to generate the results page we need. I'd prefer not to go that route if we can avoid it.
@mialondon described a possible implementation to me, something like embedding the save format on the page and using some javascript to adjust the styles dynamically - I didn't totally grasp the details, but I'd like to hear more about it because it seems like it could be an elegant solution.
As for the download to Zotero, I think our best bet is to embed COinS (see http://www.zotero.org/support/dev/exposing_metadata/coins if you're not familiar). I'm not certain yet how type-specific we will need to be with our COinS metadata, but I'm hoping that maybe in the first pass we can be a bit more generic (this may relate to the discussion about types of items that came up with regard to icons). We may even be able to add the COinS alongside the revised save/download functionality.
Yes, saveme was originally a separate template because it was quick and
dirty.
If we used a Django session, I think we would just need a dictionary
containing the results. It's not that much data, unless we are planning on
returning hundreds of results. My only real experience with this type of
thing is using sessions in PHP. When I researched storing large amounts of
data in PHP sessions, there didn't seem to be any practical limitation. I
don't know if it's the same in Django.
I'd actually prefer that solution to reformatting with Javascript, though
maybe I'm just scared of what Isotope has done to DOM elements. I can
certainly see some advantages (not having to load images twice, for
instance). Worth brainstorming.
I'm a little confused by the need for COinS. If we want to save results to
Zotero can we use the Pyzotero library write API methods?
On 7 August 2013 20:33, Rebecca Sutton Koeser notifications@github.comwrote:
I think we definitely need to consolidate the 'saveme' page with the
primary results page, because otherwise it's going to be too easy for the
result generation logic to get out of sync (particularly given that there's
already some randomness at least to the order, and I think we're hoping to
add a bit more randomness in the results selected).
We could save the data in the session (we've already got django sessions
configured in use, so that part is not hard), but I think we'd have to save
quite a bit of data to be able to generate the results page we need. I'd
prefer not to go that route if we can avoid it.
@mialondon https://github.com/mialondon described a possible
implementation to me, something like embedding the save format on the page
and using some javascript to adjust the styles dynamically - I didn't
totally grasp the details, but I'd like to hear more about it because it
seems like it could be an elegant solution.
As for the download to Zotero, I think our best bet is to embed COinS (see
http://www.zotero.org/support/dev/exposing_metadata/coins if you're not
familiar). I'm not certain yet how type-specific we will need to be with
our COinS metadata, but I'm hoping that maybe in the first pass we can be a
bit more generic (this may relate to the discussion about types of items
that came up with regard to icons). We may even be able to add the COinS
alongside the revised save/download functionality.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22300054
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
My suggestion was to restyle the existing page content for print to make it easy to select and copy the text.
Thinking aloud, what other implications would sessions have? Would it help with other functions like re-running the search with the same text input (i.e. re-doing the mix of extracted terms and API queries)? I think it's important that we don't save the original text because we don't want to risk accidentally leaking someone's essay text (for example).
Is adding checkboxes to select only particular records re-scoping serendip-o-matic from a discovery experience into a service one? It'd be easy for people to edit the records once they had them in a document so while it's a nice feature I don't think it's vital.
COinS is so that you can add the results to Zotero with one click. I suspect it doesn't need a button to function, but it could be a nice visual hint to the affordance of the page (i.e. letting people know we've set up the page so they can save everything to Zotero)
Ah, we don't need to worry about the button: 'When COinS are detected by Zotero a book, chapter, article or collection icon appears in the address bar of the browser. Just as normal, users can click on the icon to capture the reference data and place it in their reference library. ' https://www.zotero.org/support/dev/exposing_metadata/coins
On the zotero api question: we could implement save functionality that way, but it would be more complicated-- requires people to log in, when we request a token we need to get read/write access instead of just read, and we'll have to write at least some custom code (including some kind of UI) to handle people triggering the save, pushing to zotero, handling errors, etc. So COinS is a much lower bar.
On the session data conversation-- there's probably not a real problem with storing the data in the database; it just seems like it's not the best solution. (Perhaps I'm reacting this way partly because I don't love the way we're putting the search terms in the session between the input and result display views, although I haven't thought of a better way to do that yet.) I definitely get the concern about adding more javascript to what is already a complicated page.
Working backwards, there are obviously some things I need to learn about
how Zotero reads (as opposed to writes) COinS. We can certainly wrap the
current results in COinS, but can Zotero create multiple records from COinS
tagged entries on a single plage? If Zotero can pull records directly from
the results page, that would be ideal. Agreed about the visual hint of a
Save to Zotero button. We would then have a separate Save to Text or Save
to File or Download button.
I also agree that the checkboxes are not vital, and they would force us to
write to Zotero through the API, rather than the method described above. On
the other hand, it should be a pretty easy UI feature, and I don't think it
really pushes the experience into new territory. If we opt for a save
function that is compatible, and I have a few extra minutes... Otherwise,
not vital.
That said, I would prefer a proper download, rather than using the
browser's save function (or Zotero's icon in the browser bar). It just
creates a better UX.
Using session would definitely help with other functions, particularly
creating a download. I don't think there is a risk in saving the original
text to the session; it dies when the session dies. But I don't really see
why we would want to save it. I would rather save the keywords or the
results in the session. Just one submission of the text through POST to
extract these. We might have to re-run the search internally (e.g.
through and Ajax request), though I would like to avoid this, but I don't
think there's any need for this on the front end. The user can just start
over and re-input the text. If they don't get exactly the same results,
tough. That's what the save function is for.
Restyling the page for print might work, but the Javascript might be
brittle. The current function effectively does the same thing on the back
end. In my view, this is an easier method if we want to include a download
button.
On 8 August 2013 02:31, Mia notifications@github.com wrote:
My suggestion was to restyle the existing page content for print to make
it easy to select and copy the text.
Thinking aloud, what other implications would sessions have? Would it help
with other functions like re-running the search with the same text input
(i.e. re-doing the mix of extracted terms and API queries)? I think it's
important that we don't save the original text because we don't want to
risk accidentally leaking someone's essay text (for example).
Is adding checkboxes to select only particular records re-scoping
serendip-o-matic from a discovery experience into a service one? It'd be
easy for people to edit the records once they had them in a document so
while it's a nice feature I don't think it's vital.
COinS is so that you can add the results to Zotero with one click. I
suspect it doesn't need a button to function, but it could be a nice visual
hint to the affordance of the page (i.e. letting people know we've set up
the page so they can save everything to Zotero)
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22312397
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
Rebecca's comments came in whilst I was writing mine. If we can confirm
that Zotero can create multiple records from a list of COinS-tagged items
on a single page, I'm down with that.
Amidst the pre-launch chaos, I thought I heard the words "we are no longer
using a database", but, of course, I had no context. Are we still using a
database to record session data? Is that necessary (I know that it isn't in
PHP)? Perhaps we should create some Mia-style diagrams of data flow for
discussion.
On 8 August 2013 08:08, Rebecca Sutton Koeser notifications@github.comwrote:
On the zotero api question: we could implement save functionality that
way, but it would be more complicated-- requires people to log in, when we
request a token we need to get read/write access instead of just read, and
we'll have to write at least some custom code (including some kind of UI)
to handle people triggering the save, pushing to zotero, handling errors,
etc. So COinS is a much lower bar.
On the session data conversation-- there's probably not a real problem
with storing the data in the database; it just seems like it's not the best
solution. (Perhaps I'm reacting this way partly because I don't love the
way we're putting the search terms in the session between the input and
result display views, although I haven't thought of a better way to do that
yet.) I definitely get the concern about adding more javascript to what is
already a complicated page.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22330113
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
If you want to test the Zotero saving multiple objects on a single page via COinS, try it on my blog, http://www.briancroxall.net. I do think that's the best implementation.
Thanks, Brian. I tested in Zotero Standalone for Windows, and it worked
beautifully. Zotero implements the checkbox functionality I was talking
about. It isn't as pretty as we could have made it, but that wasn't
strictly necessary anyway.
So I say we go with COinS. Does anyone know how to trigger a Zotero
download with a button?
On 8 August 2013 08:45, Brian Croxall notifications@github.com wrote:
If you want to test the Zotero saving multiple objects on a single page
via COinS, try it on my blog, http://www.briancroxall.net. I do think
that's the best implementation.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22332822
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
Doesn't the button appear automatically when COinS is detected? I don't think we should try to introduce a new behaviour for Zotero users, they'll already have their own workflows and habits.
It sounds like we need a general architecture discussion to work out how queries are bandied about - perhaps after the PM chat Brian's organised for next week, when we should have more of an idea of which functionality is in scope and which is prioritised? e.g. if the 're-run the query' thing is in scope, it'd be nice to do it from the results page, not least because you could get a real sense of new results pouring in - more delight, less entry form chore?
Actually, the Zotero bookmarklet code seems to trigger Zotero, thoughI get
"No items could be saved because this website is not supported by any
Zotero translator." I'm hoping that's just because nothing on the page is
currently wrapped in COinS.
On 8 August 2013 09:03, Scott Kleinman scottkleinman@gmail.com wrote:
Thanks, Brian. I tested in Zotero Standalone for Windows, and it worked
beautifully. Zotero implements the checkbox functionality I was talking
about. It isn't as pretty as we could have made it, but that wasn't
strictly necessary anyway.
So I say we go with COinS. Does anyone know how to trigger a Zotero
download with a button?
On 8 August 2013 08:45, Brian Croxall notifications@github.com wrote:
If you want to test the Zotero saving multiple objects on a single page
via COinS, try it on my blog, http://www.briancroxall.net. I do think
that's the best implementation.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22332822
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
The browser address bar icon appears when COinS is detected; however, the
user may not see it. Having a button on the page itself to trigger the
behaviour is a good idea for UX.
I just grabbed a couple of entries from Brian's blog and added them to the
results page with the code from the Save to Zotero bookmarklet (just using
it as a normal button, not a bookmarklet). It worked beautifully (except
that the "Saving via Zotero Standalone...…" dialog doesn't go away--but
that's minor)! I now have a Brian Croxall library generated from the
Serendip-o-matic results page, and it even includes just those entries I
selected from the checkboxes.
If I can work out how to wrap our results in COins, I will try to push a
version of this later today so that we can test in multiple browsers and
Zotero implementations.
On 8 August 2013 09:07, Mia notifications@github.com wrote:
Doesn't the button appear automatically when COinS is detected? I don't
think we should try to introduce a new behaviour for Zotero users, they'll
already have their own workflows and habits.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22334551
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
OK, I'm punting. Does anyone have enough experience with COinS to create a
sample entry based on the fields image_title, image_uri, image_date,
image_source, aggregator?
NB. Zotero does not appear to have an image entry type. Perhaps we should
record as document?
On 8 August 2013 09:43, Scott Kleinman scottkleinman@gmail.com wrote:
The browser address bar icon appears when COinS is detected; however, the
user may not see it. Having a button on the page itself to trigger the
behaviour is a good idea for UX.
I just grabbed a couple of entries from Brian's blog and added them to the
results page with the code from the Save to Zotero bookmarklet (just using
it as a normal button, not a bookmarklet). It worked beautifully (except
that the "Saving via Zotero Standalone...…" dialog doesn't go away--but
that's minor)! I now have a Brian Croxall library generated from the
Serendip-o-matic results page, and it even includes just those entries I
selected from the checkboxes.
If I can work out how to wrap our results in COins, I will try to push a
version of this later today so that we can test in multiple browsers and
Zotero implementations.
On 8 August 2013 09:07, Mia notifications@github.com wrote:
Doesn't the button appear automatically when COinS is detected? I don't
think we should try to introduce a new behaviour for Zotero users, they'll
already have their own workflows and habits.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22334551
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
What about 'web page' or 'document' as the default type? (As you're not really intending to add the preview image, it's the resource you'd be interested in following up?)
I've just had a look with Brian's blog as an example, and the menu bar icon for COinS enabled pages is really subtle. Maybe rather than triggering something via a button, we could just include text along the lines of 'these results are ready to go into Zotero' or 'this page is Zotero-friendly' so people have a hint add to Zotero as they normally would?
@patrickmj can you suggest someone who can give Scott some examples?
I've implemented COinS before and could probably throw up a simple document citation fairly easily, if no one else wants to take a stab at it. -- Maybe if I implement a simple, generic document citation that would give someone else a starting point?
That would give me something to go on. I tried, but I couldn't find a
complete list: just sample fields for books and journal articles...
On 8 August 2013 11:14, Rebecca Sutton Koeser notifications@github.comwrote:
I've implemented COinS before and could probably throw up a simple
document citation fairly easily, if no one else wants to take a stab at it.
-- Maybe if I implement a simple, generic document citation that would give
someone else a starting point?
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22343303
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
"There are quite a few item types that cannot be exported into COinS. The
only ones that can are:
book
bookSection
conferencePaper
journalArticle
patent
thesis
I think we can certainly add report to that list. Unfortunately this will
require a Zotero update (rather than just a translator) and I'm not sure
when I would be able to get to it (maybe someone else will before me). I'm
sure a patch for this would be welcome if someone is inclined to do it."
I wonder if this means that you cannot import either?
On 8 August 2013 11:51, Scott Kleinman scottkleinman@gmail.com wrote:
That would give me something to go on. I tried, but I couldn't find a
complete list: just sample fields for books and journal articles...
On 8 August 2013 11:14, Rebecca Sutton Koeser notifications@github.comwrote:
I've implemented COinS before and could probably throw up a simple
document citation fairly easily, if no one else wants to take a stab at it.
-- Maybe if I implement a simple, generic document citation that would give
someone else a starting point?
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22343303
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
Ok, I think I have it basically working. The lack of documentation is kind of annoying (I think I remember running into that a few years ago when I implemented COinS for theses and dissertations-- possibly worse now because some of the resources seem to be gone).
I went ahead and committed this to master, because I think it's functional and could go out if needed, although it may need some refinement. It looks like Zotero is importing the content as web pages, which seems reasonable enough. Maybe some of you can try it out on the dev site once it is updated.
Some resources I found while adding this (may or may not be useful to others):
FYI, @scottkleinman if you do work on this and change any of the mappings I added, make sure you update the unit tests I added (you can email me or IM or something if you need help getting started on that). Because django will silently swallow any errors that occur when generating template content, I thought it was important to add some simple tests so we can easily ensure the methods continue to work.
Thanks, @scottkleinman and @rlskoeser! I agree with @mialondon that it would be useful to make it clear to users that our results are ready for Zotero via some text on the results page. Shouldn't be that hard to get something clear and with the proper tone for the Serendip-o-matic.
Yes, it does work. Thanks for putting this together, Rebecca. I'll read
over the resources when I get a chance. In the mean time, I'll try to push
a trigger button on the web page tomorrow, and we can see if people like it.
On 8 August 2013 18:19, Rebecca Sutton Koeser notifications@github.comwrote:
Ok, I think I have it basically working. The lack of documentation is kind
of annoying (I think I remember running into that a few years ago when I
implemented COinS for theses and dissertations-- possibly worse now because
some of the resources seem to be gone).
I went ahead and committed this to master, because I think it's functional
and could go out if needed, although it may need some refinement. It looks
like Zotero is importing the content as web pages, which seems reasonable
enough. Maybe some of you can try it out on the dev site once it is updated.
Some resources I found while adding this (may or may not be useful to
others):
FYI, @scottkleinman https://github.com/scottkleinman if you do work on
this and change any of the mappings I added, make sure you update the unit
tests I added (you can email me or IM or something if you need help getting
started on that). Because django will silently swallow any errors that
occur when generating template content, I thought it was important to add
some simple tests so we can easily ensure the methods continue to work.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22370058
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
I've now pushed a Save to Zotero button to master. It will need some
extensive testing. So far, it works with Google Chrome for Windows and
Zotero Standalone, though Saving with Zotero Standalone message does not go
away (seems like a Zotero Standalone issue which we can't control). For
reference, the javascript trigger is copied from
http://www.zotero.org/downloadbookmarklet. Please test.
I converted the home and save links to buttons (with changed text) and
copied the styling from the site above. That's how you'll know that the dev
server has updated. I'm not really happy with the result, so suggestions
are welcome.
Maybe we should write a script that pulls from your Zotero library, saves
the results back, pulls from your Zotero library again, saves the new
results back, pulls from your Zotero library again... Or maybe not. :-)
On 8 August 2013 20:38, Scott Kleinman scottkleinman@gmail.com wrote:
Yes, it does work. Thanks for putting this together, Rebecca. I'll read
over the resources when I get a chance. In the mean time, I'll try to push
a trigger button on the web page tomorrow, and we can see if people like it.
On 8 August 2013 18:19, Rebecca Sutton Koeser notifications@github.comwrote:
Ok, I think I have it basically working. The lack of documentation is
kind of annoying (I think I remember running into that a few years ago when
I implemented COinS for theses and dissertations-- possibly worse now
because some of the resources seem to be gone).
I went ahead and committed this to master, because I think it's
functional and could go out if needed, although it may need some
refinement. It looks like Zotero is importing the content as web pages,
which seems reasonable enough. Maybe some of you can try it out on the dev
site once it is updated.
Some resources I found while adding this (may or may not be useful to
others):
FYI, @scottkleinman https://github.com/scottkleinman if you do work on
this and change any of the mappings I added, make sure you update the unit
tests I added (you can email me or IM or something if you need help getting
started on that). Because django will silently swallow any errors that
occur when generating template content, I thought it was important to add
some simple tests so we can easily ensure the methods continue to work.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22370058
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
Next step is to create a text/csv file download function for the results.
Rebecca, do you have some ready-made code for this?
On 9 August 2013 11:10, Scott Kleinman scottkleinman@gmail.com wrote:
I've now pushed a Save to Zotero button to master. It will need some
extensive testing. So far, it works with Google Chrome for Windows and
Zotero Standalone, though Saving with Zotero Standalone message does not go
away (seems like a Zotero Standalone issue which we can't control). For
reference, the javascript trigger is copied from
http://www.zotero.org/downloadbookmarklet. Please test.
I converted the home and save links to buttons (with changed text) and
copied the styling from the site above. That's how you'll know that the dev
server has updated. I'm not really happy with the result, so suggestions
are welcome.
Maybe we should write a script that pulls from your Zotero library, saves
the results back, pulls from your Zotero library again, saves the new
results back, pulls from your Zotero library again... Or maybe not. :-)
On 8 August 2013 20:38, Scott Kleinman scottkleinman@gmail.com wrote:
Yes, it does work. Thanks for putting this together, Rebecca. I'll read
over the resources when I get a chance. In the mean time, I'll try to push
a trigger button on the web page tomorrow, and we can see if people like it.
On 8 August 2013 18:19, Rebecca Sutton Koeser notifications@github.comwrote:
Ok, I think I have it basically working. The lack of documentation is
kind of annoying (I think I remember running into that a few years ago when
I implemented COinS for theses and dissertations-- possibly worse now
because some of the resources seem to be gone).
I went ahead and committed this to master, because I think it's
functional and could go out if needed, although it may need some
refinement. It looks like Zotero is importing the content as web pages,
which seems reasonable enough. Maybe some of you can try it out on the dev
site once it is updated.
Some resources I found while adding this (may or may not be useful to
others):
FYI, @scottkleinman https://github.com/scottkleinman if you do work
on this and change any of the mappings I added, make sure you update the
unit tests I added (you can email me or IM or something if you need help
getting started on that). Because django will silently swallow any errors
that occur when generating template content, I thought it was important to
add some simple tests so we can easily ensure the methods continue to work.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22370058
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
Not exactly ready-made, but csv output should be pretty straightforward. You should go ahead and stick the list of items we generate in the main display view (after it's all combined and shuffled) into the django session - something like
request.session['items'] = items
You'll need a new view method to generate the csv output, and you should use the unicodecsv python module (will require a pip install) - works exactly like the built-in python csv functionality except that it handles unicode transparently. And then I think you just need to make sure you set the text/csv content type on the response - in fact, see the django docs on outputting csv - we want roughly the first example, except with unicodecsv. It would be good to write some simple unit tests for this, just so we can more easily ensure we handle errors and don't break the csv output with future updates. I can help out with this where you need me to, but may not be able to get to it right away. Depending on how much time you have and how soon you think you can get to this, it might be good to put it in a feature branch because I was hoping to update production sometime this weekend, if master is stable enough.
I can't see any way to do this besides sticking the items in the session, so while you're at it you might as well update the current 'save me' page - based on comments and reviews, it seems like people liked the way you were generating that list, and we've already got the code.
I think this needs a separate branch for now, as I won't be able to get to
it this weekend.
Rebecca, before you update production, I need to change the button so it
says something like "Save as Text" instead of "Download Results", which
makes more sense for the current save implementation. I'll make sure the
saveme function duplicates the view_results function so that the full list
of results is displayed. More importantly, we need to test the Save to
Zotero button more extensively.
On 10 August 2013 07:24, Rebecca Sutton Koeser notifications@github.comwrote:
Not exactly ready-made, but csv output should be pretty straightforward.
You should go ahead and stick the list of items we generate in the main
display view (after it's all combined and shuffled) into the django
session https://docs.djangoproject.com/en/dev/topics/http/sessions/ -
something like
request.session['items'] = items
You'll need a new view method to generate the csv output, and you should
use the unicodecsv python module (will require a pip install) - works
exactly like the built-in python csvhttp://docs.python.org/2/library/csv.htmlfunctionality except that it handles unicode transparently. And then I
think you just need to make sure you set the text/csv content type on the
response - in fact, see the django docs on outputting csvhttps://docs.djangoproject.com/en/dev/howto/outputting-csv/- we want roughly the first example, except with unicodecsv. It would be
good to write some simple unit tests for this, just so we can more easily
ensure we handle errors and don't break the csv output with future updates.
I can help out with this where you need me to, but may not be able to get
to it right away. Depending on how much time you have and how soon you
think you can get to this, it might be good to put it in a feature branch
because I was hoping to upda te production sometime this weekend, if master
is stable enough.
I can't see any way to do this besides sticking the items in the session,
so while you're at it you might as well update the current 'save me' page -
based on comments and reviews, it seems like people liked the way you were
generating that list, and we've already got the code.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22440664
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
Really quick UX comment from the train - plain text might be more humanist-friendly than CSV?
Cheers, Mia
Sent from my other handheld computing device
----- Reply message -----
From: "scottkleinman" notifications@github.com
To: "chnm/serendipomatic" serendipomatic@noreply.github.com
Cc: "Mia" github@miaridge.com
Subject: [serendipomatic] Enhancing the Save Function (#131)
Date: Sat, Aug 10, 2013 16:15
I think this needs a separate branch for now, as I won't be able to get to
it this weekend.
Rebecca, before you update production, I need to change the button so it
says something like "Save as Text" instead of "Download Results", which
makes more sense for the current save implementation. I'll make sure the
saveme function duplicates the view_results function so that the full list
of results is displayed. More importantly, we need to test the Save to
Zotero button more extensively.
On 10 August 2013 07:24, Rebecca Sutton Koeser notifications@github.comwrote:
Not exactly ready-made, but csv output should be pretty straightforward.
You should go ahead and stick the list of items we generate in the main
display view (after it's all combined and shuffled) into the django
session https://docs.djangoproject.com/en/dev/topics/http/sessions/ -
something like
request.session['items'] = items
You'll need a new view method to generate the csv output, and you should
use the unicodecsv python module (will require a pip install) - works
exactly like the built-in python csvhttp://docs.python.org/2/library/csv.htmlfunctionality except that it handles unicode transparently. And then I
think you just need to make sure you set the text/csv content type on the
response - in fact, see the django docs on outputting csvhttps://docs.djangoproject.com/en/dev/howto/outputting-csv/- we want roughly the first example, except with unicodecsv. It would be
good to write some simple unit tests for this, just so we can more easily
ensure we handle errors and don't break the csv output with future updates.
I can help out with this where you need me to, but may not be able to get
to it right away. Depending on how much time you have and how soon you
think you can get to this, it might be good to put it in a feature branch
because I was hoping to upda te production sometime this weekend, if master
is stable enough.
I can't see any way to do this besides sticking the items in the session,
so while you're at it you might as well update the current 'save me' page -
based on comments and reviews, it seems like people liked the way you were
generating that list, and we've already got the code.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22440664
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
I think that's probably right. It be nice to offer both, but I think plain
text is priority. The main challenge is just doing a file download.
On 10 August 2013 08:22, Mia notifications@github.com wrote:
Really quick UX comment from the train - plain text might be more
humanist-friendly than CSV?
Cheers, Mia
Sent from my other handheld computing device
----- Reply message -----
From: "scottkleinman" notifications@github.com
To: "chnm/serendipomatic" serendipomatic@noreply.github.com
Cc: "Mia" github@miaridge.com
Subject: [serendipomatic] Enhancing the Save Function (#131)
Date: Sat, Aug 10, 2013 16:15
I think this needs a separate branch for now, as I won't be able to get to
it this weekend.
Rebecca, before you update production, I need to change the button so it
says something like "Save as Text" instead of "Download Results", which
makes more sense for the current save implementation. I'll make sure the
saveme function duplicates the view_results function so that the full list
of results is displayed. More importantly, we need to test the Save to
Zotero button more extensively.
On 10 August 2013 07:24, Rebecca Sutton Koeser <notifications@github.com
wrote:
Not exactly ready-made, but csv output should be pretty straightforward.
You should go ahead and stick the list of items we generate in the main
display view (after it's all combined and shuffled) into the django
session https://docs.djangoproject.com/en/dev/topics/http/sessions/ -
something like
request.session['items'] = items
You'll need a new view method to generate the csv output, and you should
use the unicodecsv python module (will require a pip install) - works
exactly like the built-in python csv<
http://docs.python.org/2/library/csv.html>functionality except that it
handles unicode transparently. And then I
think you just need to make sure you set the text/csv content type on the
response - in fact, see the django docs on outputting csv<
https://docs.djangoproject.com/en/dev/howto/outputting-csv/>- we want
roughly the first example, except with unicodecsv. It would be
good to write some simple unit tests for this, just so we can more easily
ensure we handle errors and don't break the csv output with future
updates.
I can help out with this where you need me to, but may not be able to get
to it right away. Depending on how much time you have and how soon you
think you can get to this, it might be good to put it in a feature branch
because I was hoping to upda te production sometime this weekend, if
master
is stable enough.
I can't see any way to do this besides sticking the items in the session,
so while you're at it you might as well update the current 'save me'
page -
based on comments and reviews, it seems like people liked the way you
were
generating that list, and we've already got the code.
Boo! The Save to Zotero button only works for Zotero Standalone. If you
don't have Zotero Standalone open, you have to use the Save to Zotero
(COinS) icon in the browser address bar. Lacking a Zotero expert, I'm not
sure we can get around this.
My tentative plan is to give the button a tooltip which explains which
option to choose.
On 10 August 2013 08:15, Scott Kleinman scottkleinman@gmail.com wrote:
I think this needs a separate branch for now, as I won't be able to get to
it this weekend.
Rebecca, before you update production, I need to change the button so it
says something like "Save as Text" instead of "Download Results", which
makes more sense for the current save implementation. I'll make sure the
saveme function duplicates the view_results function so that the full list
of results is displayed. More importantly, we need to test the Save to
Zotero button more extensively.
On 10 August 2013 07:24, Rebecca Sutton Koeser notifications@github.comwrote:
Not exactly ready-made, but csv output should be pretty straightforward.
You should go ahead and stick the list of items we generate in the main
display view (after it's all combined and shuffled) into the django
session https://docs.djangoproject.com/en/dev/topics/http/sessions/ -
something like
request.session['items'] = items
You'll need a new view method to generate the csv output, and you should
use the unicodecsv python module (will require a pip install) - works
exactly like the built-in python csvhttp://docs.python.org/2/library/csv.htmlfunctionality except that it handles unicode transparently. And then I
think you just need to make sure you set the text/csv content type on the
response - in fact, see the django docs on outputting csvhttps://docs.djangoproject.com/en/dev/howto/outputting-csv/- we want roughly the first example, except with unicodecsv. It would be
good to write some simple unit tests for this, just so we can more easily
ensure we handle errors and don't break the csv output with future updates.
I can help out with this where you need me to, but may not be able to get
to it right away. Depending on how much time you have and how soon you
think you can get to this, it might be good to put it in a feature branch
because I was hoping to upda te production sometime this weekend, if master
is stable enough.
I can't see any way to do this besides sticking the items in the session,
so while you're at it you might as well update the current 'save me' page -
based on comments and reviews, it seems like people liked the way you were
generating that list, and we've already got the code.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22440664
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
I have now pushed some changes to master. There are three buttons: Try Again, Save as Text, and Save to Zotero. The latter two have tooltips explaining usage. Please feel free to suggest modifications to the text, but from a code point of view, it should be stable enough for production.
Thanks for all your work on this, Scott! Perhaps we need to talk to the Zotero team or post on their forum re the expected user experience for different types of Zotero users? I'd imagine that the browser plugin has a bigger installed user base than the standalone app, which would direct us to serving their needs first.
I think we might need to take a step away from fixing code and look at the results page as a whole and separate out the UX path (including decisions on items on https://github.com/chnm/serendipomatic/wiki/Wishlist-items-and-future-development-road-map) and the technical tasks required so that we're not accidentally edging the app experience from 'delight' to 'utility' through small tweaks. For example, we had nice chatty text previously https://github.com/chnm/serendipomatic/issues/109 ('Go home and feed the machine new text!' and 'Like what you see? Save these results') so moving to buttons means we might be forced into more concise, functional text that risks confusing the user - e.g 'Try again' currently dumps you back to the front page where you'd have to re-enter your text to try it again rather than re-loading the page with a new mix of results. It'd also be good to have things like button styling and 'active text' documented as a reference for people working on technical fixes. This sounds like something the team leads can work on in our call on Monday (cc @briancroxall @mfrazer @JackDougherty )
In terms of functionality, a quick test on dev found a few quirks. The results page seemed to give 30 items; 'save to Zotero' added 28 items to my library, and the 'save as text' page had 4 results (one from each source, though this may be coincidence). Can anyone else replicate this? [Actually now it's just breaking so I can't replicate it either]
The 'save as text' page 'Sources Used' line only listed DPLA, Europeana, Trove but did include a Flickr Commons result.
Yes, we might well have to talk to the Zotero team. I wasn't trying to
serve the Zotero Standalone people first; it just seems that the
bookmarklet code to trigger the import only seems to trigger Zotero
Standalone when used "in-page". I'm not sure why.
I changed the text to buttons precisely to elicit the sort of feedback Mia
gives with respect to UX. These are really just links, so their appearance
is easily tweaked. Should I open this as a new issue in order to get more
direct feedback?
"The 'save as text' page 'Sources Used' line only listed DPLA, Europeana,
Trove but did include a Flickr Commons result." This should be fixed in the
next update to the development server.
I am also seeing a discrepancy between the number of items on the results
page and the number of items picked up by Zotero. Could it be that Zotero
cannot read some of the COinS we are generating?
On my local installation, I am also getting a different number of results
on the save as text page. Also, one time the page hung while loading. I
closed the tab, tried again, and it worked. Mia, does this sound like the
"breaking" issue you experienced?
On 11 August 2013 06:09, Mia notifications@github.com wrote:
Thanks for all your work on this, Scott! Perhaps we need to talk to the
Zotero team or post on their forum re the expected user experience for
different types of Zotero users? I'd imagine that the browser plugin has a
bigger installed user base than the standalone app, which would direct us
to serving their needs first.
I think we might need to take a step away from fixing code and look at the
results page as a whole and separate out the UX path (including decisions
on items on
https://github.com/chnm/serendipomatic/wiki/Wishlist-items-and-future-development-road-map)
and the technical tasks required so that we're not accidentally edging the
app experience from 'delight' to 'utility' through small tweaks. For
example, we had nice chatty text previously #109https://github.com/chnm/serendipomatic/issues/109('Go home and feed the machine new text!' and 'Like what you see? Save
these results') so moving to buttons means we might be forced into more
concise, functional text that risks confusing the user - e.g 'Try again'
currently dumps you back to the front page where you'd have to re-enter
your text to try it ag ain rather than re-loading the page with a new mix
of results. It'd also be good to have things like button styling and
'active text' documented as a reference for people working on technical
fixes. This sounds like something the team leads can work on in our call on
Monday (cc @briancroxall https://github.com/briancroxall @mfrazerhttps://github.com/mfrazer
@JackDougherty https://github.com/JackDougherty )
In terms of functionality, a quick test on dev found a few quirks. The
results page seemed to give 30 items; 'save to Zotero' added 28 items to my
library, and the 'save as text' page had 4 results (one from each source,
though this may be coincidence). Can anyone else replicate this? [Actually
now it's just breaking so I can't replicate it either]
The 'save as text' page 'Sources Used' line only listed DPLA, Europeana,
Trove but did include a Flickr Commons result.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22457457
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
Do you think you could post on the Zotero forum outlining what we're trying to do and what is happening instead while I take up the UX stuff with the other team leads? They might also be able to suggest ways of testing whether the COinS output is functioning correctly.
Good news about the 'sources used'!
The breaking I experienced was proper 500-error stuff - it's in debug mode so wrote it to the screen, but I figured it might be transient so didn't save it. (Also I assume it's going to email).
Yes, thanks a lot for all your excellent work, Scott. And thank you, Mia, for your macro- and micro-level guidance, which has been outstanding. Much appreciated!
Sure, but possibly not in the next couple of days (some deadlines
approaching).
On 11 August 2013 09:52, Mia notifications@github.com wrote:
Do you think you could post on the Zotero forum outlining what we're
trying to do and what is happening instead while I take up the UX stuff
with the other team leads? They might also be able to suggest ways of
testing whether the COinS output is functioning correctly.
Good news about the 'sources used'!
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22460835
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
I was hoping to push out an update to production this weekend because we have a lot of bug fixes, text clean up, etc plus some new features sitting in dev waiting to go out, but I'm not sure if we're happy with the current version. Where do we stand on the zotero buttons? Are they good enough to move to live or is there more work that needs to be done first? I meant to ask sooner so people would have time to comment, but I forgot. I'd like to update production once we get it to a point we're happy with it & think it's stable.
Zotero browser plugins work fine. The only problem is the in-page button,
which only works with Zotero Standalone. I can always comment it out and
then say in the tooltip for the main Save button/link that users with the
Zotero plugin can click the icon in the address bar to save to their
libraries.
On 11 August 2013 12:54, Rebecca Sutton Koeser notifications@github.comwrote:
I was hoping to push out an update to production this weekend because we
have a lot of bug fixes, text clean up, etc plus some new features sitting
in dev waiting to go out, but I'm not sure if we're happy with the current
version. Where do we stand on the zotero buttons? Are they good enough to
move to live or is there more work that needs to be done first? I meant to
ask sooner so people would have time to comment, but I forgot. I'd like to
update production once we get it to a point we're happy with it & think
it's stable.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22463954
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
Can we revert to the pre-button version with the old 'go home' etc text and still have the other 'save page' fixes? (It'd be good to branch a version to work on the 'fancy Zotero save' options)
It'd also be good to check with @elirose to see where he's at with the Zotero library input integration - is there anything we should be aiming to test more widely before pushing to live?
Cheers, Mia
Sent from my handheld computing device
On 11 Aug 2013, at 21:18, scottkleinman notifications@github.com wrote:
Zotero browser plugins work fine. The only problem is the in-page button,
which only works with Zotero Standalone. I can always comment it out and
then say in the tooltip for the main Save button/link that users with the
Zotero plugin can click the icon in the address bar to save to their
libraries.
On 11 August 2013 12:54, Rebecca Sutton Koeser notifications@github.comwrote:
I was hoping to push out an update to production this weekend because we
have a lot of bug fixes, text clean up, etc plus some new features sitting
in dev waiting to go out, but I'm not sure if we're happy with the current
version. Where do we stand on the zotero buttons? Are they good enough to
move to live or is there more work that needs to be done first? I meant to
ask sooner so people would have time to comment, but I forgot. I'd like to
update production once we get it to a point we're happy with it & think
it's stable.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22463954
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
—
Reply to this email directly or view it on GitHub.
On 11 August 2013 13:34, Mia notifications@github.com wrote:
Can we revert to the pre-button version with the old 'go home' etc text
and still have the other 'save page' fixes? (It'd be good to branch a
version to work on the 'fancy Zotero save' options)
It'd also be good to check with @elirose to see where he's at with the
Zotero library input integration - is there anything we should be aiming to
test more widely before pushing to live?
Cheers, Mia
Sent from my handheld computing device
On 11 Aug 2013, at 21:18, scottkleinman notifications@github.com wrote:
Zotero browser plugins work fine. The only problem is the in-page
button,
which only works with Zotero Standalone. I can always comment it out and
then say in the tooltip for the main Save button/link that users with
the
Zotero plugin can click the icon in the address bar to save to their
libraries.
On 11 August 2013 12:54, Rebecca Sutton Koeser notifications@github.comwrote:
I was hoping to push out an update to production this weekend because
we
have a lot of bug fixes, text clean up, etc plus some new features
sitting
in dev waiting to go out, but I'm not sure if we're happy with the
current
version. Where do we stand on the zotero buttons? Are they good enough
to
move to live or is there more work that needs to be done first? I
meant to
ask sooner so people would have time to comment, but I forgot. I'd
like to
update production once we get it to a point we're happy with it &
think
it's stable.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22464711
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
OK, reverted to text go home and save links. However, mousing over the save
link will generate a tooltip with instructions for saving to Zotero with
the browser plugin, so that functionality is preserved.
On 11 August 2013 13:54, Scott Kleinman scottkleinman@gmail.com wrote:
Yes, that's easy. I'll do it.
On 11 August 2013 13:34, Mia notifications@github.com wrote:
Can we revert to the pre-button version with the old 'go home' etc text
and still have the other 'save page' fixes? (It'd be good to branch a
version to work on the 'fancy Zotero save' options)
It'd also be good to check with @elirose to see where he's at with the
Zotero library input integration - is there anything we should be aiming to
test more widely before pushing to live?
Cheers, Mia
Sent from my handheld computing device
On 11 Aug 2013, at 21:18, scottkleinman notifications@github.com
wrote:
Zotero browser plugins work fine. The only problem is the in-page
button,
which only works with Zotero Standalone. I can always comment it out
and
then say in the tooltip for the main Save button/link that users with
the
Zotero plugin can click the icon in the address bar to save to their
libraries.
On 11 August 2013 12:54, Rebecca Sutton Koeser <
notifications@github.com>wrote:
I was hoping to push out an update to production this weekend because
we
have a lot of bug fixes, text clean up, etc plus some new features
sitting
in dev waiting to go out, but I'm not sure if we're happy with the
current
version. Where do we stand on the zotero buttons? Are they good
enough to
move to live or is there more work that needs to be done first? I
meant to
ask sooner so people would have time to comment, but I forgot. I'd
like to
update production once we get it to a point we're happy with it &
think
it's stable.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22464711
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
I've only tested on my iPod but the reverted text looks good and more importantly the 'save results' page now shows all the results. Thanks for all your great work on this!
Cheers, Mia
Sent from my handheld computing device
On 11 Aug 2013, at 22:02, scottkleinman notifications@github.com wrote:
OK, reverted to text go home and save links. However, mousing over the save
link will generate a tooltip with instructions for saving to Zotero with
the browser plugin, so that functionality is preserved.
On 11 August 2013 13:54, Scott Kleinman scottkleinman@gmail.com wrote:
Yes, that's easy. I'll do it.
On 11 August 2013 13:34, Mia notifications@github.com wrote:
Can we revert to the pre-button version with the old 'go home' etc text
and still have the other 'save page' fixes? (It'd be good to branch a
version to work on the 'fancy Zotero save' options)
It'd also be good to check with @elirose to see where he's at with the
Zotero library input integration - is there anything we should be aiming to
test more widely before pushing to live?
Cheers, Mia
Sent from my handheld computing device
On 11 Aug 2013, at 21:18, scottkleinman notifications@github.com
wrote:
Zotero browser plugins work fine. The only problem is the in-page
button,
which only works with Zotero Standalone. I can always comment it out
and
then say in the tooltip for the main Save button/link that users with
the
Zotero plugin can click the icon in the address bar to save to their
libraries.
On 11 August 2013 12:54, Rebecca Sutton Koeser <
notifications@github.com>wrote:
I was hoping to push out an update to production this weekend because
we
have a lot of bug fixes, text clean up, etc plus some new features
sitting
in dev waiting to go out, but I'm not sure if we're happy with the
current
version. Where do we stand on the zotero buttons? Are they good
enough to
move to live or is there more work that needs to be done first? I
meant to
ask sooner so people would have time to comment, but I forgot. I'd
like to
update production once we get it to a point we're happy with it &
think
it's stable.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22464711
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
—
Reply to this email directly or view it on GitHub.
Grrr... I didn't change anything that would have affected the number of
results--one way or the other. I think the Hippo is playing with me.
-S
On 11 August 2013 14:22, Mia notifications@github.com wrote:
I've only tested on my iPod but the reverted text looks good and more
importantly the 'save results' page now shows all the results. Thanks for
all your great work on this!
Cheers, Mia
Sent from my handheld computing device
On 11 Aug 2013, at 22:02, scottkleinman notifications@github.com wrote:
OK, reverted to text go home and save links. However, mousing over the
save
link will generate a tooltip with instructions for saving to Zotero with
the browser plugin, so that functionality is preserved.
On 11 August 2013 13:54, Scott Kleinman scottkleinman@gmail.com
wrote:
Yes, that's easy. I'll do it.
On 11 August 2013 13:34, Mia notifications@github.com wrote:
Can we revert to the pre-button version with the old 'go home' etc
text
and still have the other 'save page' fixes? (It'd be good to branch a
version to work on the 'fancy Zotero save' options)
It'd also be good to check with @elirose to see where he's at with
the
Zotero library input integration - is there anything we should be
aiming to
test more widely before pushing to live?
Cheers, Mia
Sent from my handheld computing device
On 11 Aug 2013, at 21:18, scottkleinman notifications@github.com
wrote:
Zotero browser plugins work fine. The only problem is the in-page
button,
which only works with Zotero Standalone. I can always comment it
out
and
then say in the tooltip for the main Save button/link that users
with
the
Zotero plugin can click the icon in the address bar to save to
their
libraries.
On 11 August 2013 12:54, Rebecca Sutton Koeser <
notifications@github.com>wrote:
I was hoping to push out an update to production this weekend
because
we
have a lot of bug fixes, text clean up, etc plus some new
features
sitting
in dev waiting to go out, but I'm not sure if we're happy with
the
current
version. Where do we stand on the zotero buttons? Are they good
enough to
move to live or is there more work that needs to be done first? I
meant to
ask sooner so people would have time to comment, but I forgot.
I'd
like to
update production once we get it to a point we're happy with it &
think
it's stable.
—
Reply to this email directly or view it on GitHub<
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
—
Reply to this email directly or view it on GitHub.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22465629
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
I looked at the code, and it looks like the save results is generating Trove data but not including them. It also doesn't have the error handling I added to the main results view. I'm going to go ahead and do a quick update to store the items in the session to ensure that the item-discovery logic and shuffled list of items displayed stays in sync (which will be more important if & when we add more sources and revise the selection & shuffling logic) the items displayed on the text listing page. I assume that the save results page should list items in the same order they are displayed on the main view page?
As a side note I'd like to rename the view/url from saveme but not sure what it ought to be. If /stash/ becomes /discoveries/ is this /discoveries/list/ ? /discoveries/text/ ?
The updated save could use some testing once it gets pushed to dev, if folks can take a look. Also, when I tested the COinS functionality with my zotero library as input today I got a unicode error - I think I've fixed it, but would appreciate if other people could test it some as well.
I actually like saving the results in session. This would have been my
initial recommendation, but the framework I am used to, Flask, is a bit
weird with sessions, and I didn't want to take that on for Django in the
time we had available. Please do go ahead with this. I'm sure the results
will be more consistent.
As far as names go, here are some more suggestions:
/discoveries/resultlist, /discoveries/textlist, /discoveries/output-text,
/discoveries/output-list. I think I'd be happy with any of them.
On 11 August 2013 14:48, Rebecca Sutton Koeser notifications@github.comwrote:
I looked at the code, and it looks like the save results is generating
Trove data but not including them. It also doesn't have the error handling
I added to the main results view. I'm going to go ahead and do a quick
update to store the items in the session to ensure that the item-discovery
logic and shuffled list of items displayed stays in sync (which will be
more important if & when we add more sources and revise the selection &
shuffling logic) the items displayed on the text listing page. I assume
that the save results page should list items in the same order they are
displayed on the main view page?
As a side note I'd like to rename the view/url from saveme but not sure
what it ought to be. If /stash/ becomes /discoveries/ is this
/discoveries/list/ ? text/ ?
—
Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/131#issuecomment-22466141
.
Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge
@mfrazer This was flagged as nov. release, but the fix is actually in place and the code will go out in the oct. release (unless we do something to prevent that). Hopefully we can get it tested before then. :-)
I've been thinking a little bit about how to upgrade the save function in Serendip-o-matic, and I thought I'd describe what I have in mind and get some feedback before doing anything. So here's my idea:
The save function would open a modal dialog with a list of results. Each line would have a small thumbnail, the image title, the image date, its source, the aggregator we got from, and its URI. The thumbnail would be mainly for identification, but it and the title could certainly be links opening the source in a new window.
About the easiest way to do this is to write the
Assuming we can save the results to a session or temporary file, it would be possible to put checkboxes next to each result so that the user could select or deselect them. We could even make the thumbnails function as checkboxes (though they wouldn't then be links). Of course, we could also do "Select All" and "Unselect All" buttons/checkboxes.
There would also be a Download button (text/csv) and a Save to Zotero button (can we do this?).
What do people think of this approach? Any features I have missed?
I think we definitely need to consolidate the 'saveme' page with the primary results page, because otherwise it's going to be too easy for the result generation logic to get out of sync (particularly given that there's already some randomness at least to the order, and I think we're hoping to add a bit more randomness in the results selected).
We could save the data in the session (we've already got django sessions configured in use, so that part is not hard), but I think we'd have to save quite a bit of data to be able to generate the results page we need. I'd prefer not to go that route if we can avoid it.
@mialondon described a possible implementation to me, something like embedding the save format on the page and using some javascript to adjust the styles dynamically - I didn't totally grasp the details, but I'd like to hear more about it because it seems like it could be an elegant solution.
As for the download to Zotero, I think our best bet is to embed COinS (see http://www.zotero.org/support/dev/exposing_metadata/coins if you're not familiar). I'm not certain yet how type-specific we will need to be with our COinS metadata, but I'm hoping that maybe in the first pass we can be a bit more generic (this may relate to the discussion about types of items that came up with regard to icons). We may even be able to add the COinS alongside the revised save/download functionality.
Yes, saveme was originally a separate template because it was quick and dirty.
If we used a Django session, I think we would just need a dictionary containing the results. It's not that much data, unless we are planning on returning hundreds of results. My only real experience with this type of thing is using sessions in PHP. When I researched storing large amounts of data in PHP sessions, there didn't seem to be any practical limitation. I don't know if it's the same in Django.
I'd actually prefer that solution to reformatting with Javascript, though maybe I'm just scared of what Isotope has done to DOM elements. I can certainly see some advantages (not having to load images twice, for instance). Worth brainstorming.
I'm a little confused by the need for COinS. If we want to save results to Zotero can we use the Pyzotero library write API methods?
On 7 August 2013 20:33, Rebecca Sutton Koeser notifications@github.comwrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
My suggestion was to restyle the existing page content for print to make it easy to select and copy the text.
Thinking aloud, what other implications would sessions have? Would it help with other functions like re-running the search with the same text input (i.e. re-doing the mix of extracted terms and API queries)? I think it's important that we don't save the original text because we don't want to risk accidentally leaking someone's essay text (for example).
Is adding checkboxes to select only particular records re-scoping serendip-o-matic from a discovery experience into a service one? It'd be easy for people to edit the records once they had them in a document so while it's a nice feature I don't think it's vital.
COinS is so that you can add the results to Zotero with one click. I suspect it doesn't need a button to function, but it could be a nice visual hint to the affordance of the page (i.e. letting people know we've set up the page so they can save everything to Zotero)
Ah, we don't need to worry about the button: 'When COinS are detected by Zotero a book, chapter, article or collection icon appears in the address bar of the browser. Just as normal, users can click on the icon to capture the reference data and place it in their reference library. ' https://www.zotero.org/support/dev/exposing_metadata/coins
Some of this conversation will also relate to https://github.com/chnm/serendipomatic/issues/117 and https://github.com/chnm/serendipomatic/issues/66
On the zotero api question: we could implement save functionality that way, but it would be more complicated-- requires people to log in, when we request a token we need to get read/write access instead of just read, and we'll have to write at least some custom code (including some kind of UI) to handle people triggering the save, pushing to zotero, handling errors, etc. So COinS is a much lower bar.
On the session data conversation-- there's probably not a real problem with storing the data in the database; it just seems like it's not the best solution. (Perhaps I'm reacting this way partly because I don't love the way we're putting the search terms in the session between the input and result display views, although I haven't thought of a better way to do that yet.) I definitely get the concern about adding more javascript to what is already a complicated page.
Working backwards, there are obviously some things I need to learn about how Zotero reads (as opposed to writes) COinS. We can certainly wrap the current results in COinS, but can Zotero create multiple records from COinS tagged entries on a single plage? If Zotero can pull records directly from the results page, that would be ideal. Agreed about the visual hint of a Save to Zotero button. We would then have a separate Save to Text or Save to File or Download button.
I also agree that the checkboxes are not vital, and they would force us to write to Zotero through the API, rather than the method described above. On the other hand, it should be a pretty easy UI feature, and I don't think it really pushes the experience into new territory. If we opt for a save function that is compatible, and I have a few extra minutes... Otherwise, not vital.
That said, I would prefer a proper download, rather than using the browser's save function (or Zotero's icon in the browser bar). It just creates a better UX.
Using session would definitely help with other functions, particularly creating a download. I don't think there is a risk in saving the original text to the session; it dies when the session dies. But I don't really see why we would want to save it. I would rather save the keywords or the results in the session. Just one submission of the text through POST to extract these. We might have to re-run the search internally (e.g. through and Ajax request), though I would like to avoid this, but I don't think there's any need for this on the front end. The user can just start over and re-input the text. If they don't get exactly the same results, tough. That's what the save function is for.
Restyling the page for print might work, but the Javascript might be brittle. The current function effectively does the same thing on the back end. In my view, this is an easier method if we want to include a download button.
On 8 August 2013 02:31, Mia notifications@github.com wrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
Rebecca's comments came in whilst I was writing mine. If we can confirm that Zotero can create multiple records from a list of COinS-tagged items on a single page, I'm down with that.
Amidst the pre-launch chaos, I thought I heard the words "we are no longer using a database", but, of course, I had no context. Are we still using a database to record session data? Is that necessary (I know that it isn't in PHP)? Perhaps we should create some Mia-style diagrams of data flow for discussion.
On 8 August 2013 08:08, Rebecca Sutton Koeser notifications@github.comwrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
If you want to test the Zotero saving multiple objects on a single page via COinS, try it on my blog, http://www.briancroxall.net. I do think that's the best implementation.
Thanks, Brian. I tested in Zotero Standalone for Windows, and it worked beautifully. Zotero implements the checkbox functionality I was talking about. It isn't as pretty as we could have made it, but that wasn't strictly necessary anyway.
So I say we go with COinS. Does anyone know how to trigger a Zotero download with a button?
On 8 August 2013 08:45, Brian Croxall notifications@github.com wrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
Doesn't the button appear automatically when COinS is detected? I don't think we should try to introduce a new behaviour for Zotero users, they'll already have their own workflows and habits.
It sounds like we need a general architecture discussion to work out how queries are bandied about - perhaps after the PM chat Brian's organised for next week, when we should have more of an idea of which functionality is in scope and which is prioritised? e.g. if the 're-run the query' thing is in scope, it'd be nice to do it from the results page, not least because you could get a real sense of new results pouring in - more delight, less entry form chore?
Actually, the Zotero bookmarklet code seems to trigger Zotero, thoughI get "No items could be saved because this website is not supported by any Zotero translator." I'm hoping that's just because nothing on the page is currently wrapped in COinS.
On 8 August 2013 09:03, Scott Kleinman scottkleinman@gmail.com wrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
The browser address bar icon appears when COinS is detected; however, the user may not see it. Having a button on the page itself to trigger the behaviour is a good idea for UX.
I just grabbed a couple of entries from Brian's blog and added them to the results page with the code from the Save to Zotero bookmarklet (just using it as a normal button, not a bookmarklet). It worked beautifully (except that the "Saving via Zotero Standalone...…" dialog doesn't go away--but that's minor)! I now have a Brian Croxall library generated from the Serendip-o-matic results page, and it even includes just those entries I selected from the checkboxes.
If I can work out how to wrap our results in COins, I will try to push a version of this later today so that we can test in multiple browsers and Zotero implementations.
On 8 August 2013 09:07, Mia notifications@github.com wrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
OK, I'm punting. Does anyone have enough experience with COinS to create a sample entry based on the fields image_title, image_uri, image_date, image_source, aggregator?
NB. Zotero does not appear to have an image entry type. Perhaps we should record as document?
On 8 August 2013 09:43, Scott Kleinman scottkleinman@gmail.com wrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
What about 'web page' or 'document' as the default type? (As you're not really intending to add the preview image, it's the resource you'd be interested in following up?)
I've just had a look with Brian's blog as an example, and the menu bar icon for COinS enabled pages is really subtle. Maybe rather than triggering something via a button, we could just include text along the lines of 'these results are ready to go into Zotero' or 'this page is Zotero-friendly' so people have a hint add to Zotero as they normally would?
@patrickmj can you suggest someone who can give Scott some examples?
I've implemented COinS before and could probably throw up a simple document citation fairly easily, if no one else wants to take a stab at it. -- Maybe if I implement a simple, generic document citation that would give someone else a starting point?
That would give me something to go on. I tried, but I couldn't find a complete list: just sample fields for books and journal articles...
On 8 August 2013 11:14, Rebecca Sutton Koeser notifications@github.comwrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
From the Zotero forum 3 days ago:
"There are quite a few item types that cannot be exported into COinS. The only ones that can are:
I think we can certainly add report to that list. Unfortunately this will require a Zotero update (rather than just a translator) and I'm not sure when I would be able to get to it (maybe someone else will before me). I'm sure a patch for this would be welcome if someone is inclined to do it."
I wonder if this means that you cannot import either?
On 8 August 2013 11:51, Scott Kleinman scottkleinman@gmail.com wrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
Ok, I think I have it basically working. The lack of documentation is kind of annoying (I think I remember running into that a few years ago when I implemented COinS for theses and dissertations-- possibly worse now because some of the resources seem to be gone).
I went ahead and committed this to master, because I think it's functional and could go out if needed, although it may need some refinement. It looks like Zotero is importing the content as web pages, which seems reasonable enough. Maybe some of you can try it out on the dev site once it is updated.
Some resources I found while adding this (may or may not be useful to others):
FYI, @scottkleinman if you do work on this and change any of the mappings I added, make sure you update the unit tests I added (you can email me or IM or something if you need help getting started on that). Because django will silently swallow any errors that occur when generating template content, I thought it was important to add some simple tests so we can easily ensure the methods continue to work.
Thanks, @scottkleinman and @rlskoeser! I agree with @mialondon that it would be useful to make it clear to users that our results are ready for Zotero via some text on the results page. Shouldn't be that hard to get something clear and with the proper tone for the Serendip-o-matic.
Yes, it does work. Thanks for putting this together, Rebecca. I'll read over the resources when I get a chance. In the mean time, I'll try to push a trigger button on the web page tomorrow, and we can see if people like it.
On 8 August 2013 18:19, Rebecca Sutton Koeser notifications@github.comwrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
I've now pushed a Save to Zotero button to master. It will need some extensive testing. So far, it works with Google Chrome for Windows and Zotero Standalone, though Saving with Zotero Standalone message does not go away (seems like a Zotero Standalone issue which we can't control). For reference, the javascript trigger is copied from http://www.zotero.org/downloadbookmarklet. Please test.
I converted the home and save links to buttons (with changed text) and copied the styling from the site above. That's how you'll know that the dev server has updated. I'm not really happy with the result, so suggestions are welcome.
Maybe we should write a script that pulls from your Zotero library, saves the results back, pulls from your Zotero library again, saves the new results back, pulls from your Zotero library again... Or maybe not. :-)
On 8 August 2013 20:38, Scott Kleinman scottkleinman@gmail.com wrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
Next step is to create a text/csv file download function for the results. Rebecca, do you have some ready-made code for this?
On 9 August 2013 11:10, Scott Kleinman scottkleinman@gmail.com wrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
Not exactly ready-made, but csv output should be pretty straightforward. You should go ahead and stick the list of items we generate in the main display view (after it's all combined and shuffled) into the django session - something like
You'll need a new view method to generate the csv output, and you should use the unicodecsv python module (will require a pip install) - works exactly like the built-in python csv functionality except that it handles unicode transparently. And then I think you just need to make sure you set the text/csv content type on the response - in fact, see the django docs on outputting csv - we want roughly the first example, except with unicodecsv. It would be good to write some simple unit tests for this, just so we can more easily ensure we handle errors and don't break the csv output with future updates. I can help out with this where you need me to, but may not be able to get to it right away. Depending on how much time you have and how soon you think you can get to this, it might be good to put it in a feature branch because I was hoping to update production sometime this weekend, if master is stable enough.
I can't see any way to do this besides sticking the items in the session, so while you're at it you might as well update the current 'save me' page - based on comments and reviews, it seems like people liked the way you were generating that list, and we've already got the code.
I think this needs a separate branch for now, as I won't be able to get to it this weekend.
Rebecca, before you update production, I need to change the button so it says something like "Save as Text" instead of "Download Results", which makes more sense for the current save implementation. I'll make sure the saveme function duplicates the view_results function so that the full list of results is displayed. More importantly, we need to test the Save to Zotero button more extensively.
On 10 August 2013 07:24, Rebecca Sutton Koeser notifications@github.comwrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
Really quick UX comment from the train - plain text might be more humanist-friendly than CSV?
Cheers, Mia
Sent from my other handheld computing device
----- Reply message ----- From: "scottkleinman" notifications@github.com To: "chnm/serendipomatic" serendipomatic@noreply.github.com Cc: "Mia" github@miaridge.com Subject: [serendipomatic] Enhancing the Save Function (#131) Date: Sat, Aug 10, 2013 16:15
I think this needs a separate branch for now, as I won't be able to get to it this weekend.
Rebecca, before you update production, I need to change the button so it says something like "Save as Text" instead of "Download Results", which makes more sense for the current save implementation. I'll make sure the saveme function duplicates the view_results function so that the full list of results is displayed. More importantly, we need to test the Save to Zotero button more extensively.
On 10 August 2013 07:24, Rebecca Sutton Koeser notifications@github.comwrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
Reply to this email directly or view it on GitHub: https://github.com/chnm/serendipomatic/issues/131#issuecomment-22441457
I think that's probably right. It be nice to offer both, but I think plain text is priority. The main challenge is just doing a file download.
On 10 August 2013 08:22, Mia notifications@github.com wrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
Boo! The Save to Zotero button only works for Zotero Standalone. If you don't have Zotero Standalone open, you have to use the Save to Zotero (COinS) icon in the browser address bar. Lacking a Zotero expert, I'm not sure we can get around this.
My tentative plan is to give the button a tooltip which explains which option to choose.
On 10 August 2013 08:15, Scott Kleinman scottkleinman@gmail.com wrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
I have now pushed some changes to master. There are three buttons: Try Again, Save as Text, and Save to Zotero. The latter two have tooltips explaining usage. Please feel free to suggest modifications to the text, but from a code point of view, it should be stable enough for production.
Thanks for all your work on this, Scott! Perhaps we need to talk to the Zotero team or post on their forum re the expected user experience for different types of Zotero users? I'd imagine that the browser plugin has a bigger installed user base than the standalone app, which would direct us to serving their needs first.
I think we might need to take a step away from fixing code and look at the results page as a whole and separate out the UX path (including decisions on items on https://github.com/chnm/serendipomatic/wiki/Wishlist-items-and-future-development-road-map) and the technical tasks required so that we're not accidentally edging the app experience from 'delight' to 'utility' through small tweaks. For example, we had nice chatty text previously https://github.com/chnm/serendipomatic/issues/109 ('Go home and feed the machine new text!' and 'Like what you see? Save these results') so moving to buttons means we might be forced into more concise, functional text that risks confusing the user - e.g 'Try again' currently dumps you back to the front page where you'd have to re-enter your text to try it again rather than re-loading the page with a new mix of results. It'd also be good to have things like button styling and 'active text' documented as a reference for people working on technical fixes. This sounds like something the team leads can work on in our call on Monday (cc @briancroxall @mfrazer @JackDougherty )
In terms of functionality, a quick test on dev found a few quirks. The results page seemed to give 30 items; 'save to Zotero' added 28 items to my library, and the 'save as text' page had 4 results (one from each source, though this may be coincidence). Can anyone else replicate this? [Actually now it's just breaking so I can't replicate it either]
The 'save as text' page 'Sources Used' line only listed DPLA, Europeana, Trove but did include a Flickr Commons result.
Yes, we might well have to talk to the Zotero team. I wasn't trying to serve the Zotero Standalone people first; it just seems that the bookmarklet code to trigger the import only seems to trigger Zotero Standalone when used "in-page". I'm not sure why.
I changed the text to buttons precisely to elicit the sort of feedback Mia gives with respect to UX. These are really just links, so their appearance is easily tweaked. Should I open this as a new issue in order to get more direct feedback?
"The 'save as text' page 'Sources Used' line only listed DPLA, Europeana, Trove but did include a Flickr Commons result." This should be fixed in the next update to the development server.
I am also seeing a discrepancy between the number of items on the results page and the number of items picked up by Zotero. Could it be that Zotero cannot read some of the COinS we are generating?
On my local installation, I am also getting a different number of results on the save as text page. Also, one time the page hung while loading. I closed the tab, tried again, and it worked. Mia, does this sound like the "breaking" issue you experienced?
On 11 August 2013 06:09, Mia notifications@github.com wrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
Do you think you could post on the Zotero forum outlining what we're trying to do and what is happening instead while I take up the UX stuff with the other team leads? They might also be able to suggest ways of testing whether the COinS output is functioning correctly.
Good news about the 'sources used'!
The breaking I experienced was proper 500-error stuff - it's in debug mode so wrote it to the screen, but I figured it might be transient so didn't save it. (Also I assume it's going to email).
Yes, thanks a lot for all your excellent work, Scott. And thank you, Mia, for your macro- and micro-level guidance, which has been outstanding. Much appreciated!
Sure, but possibly not in the next couple of days (some deadlines approaching).
On 11 August 2013 09:52, Mia notifications@github.com wrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
I was hoping to push out an update to production this weekend because we have a lot of bug fixes, text clean up, etc plus some new features sitting in dev waiting to go out, but I'm not sure if we're happy with the current version. Where do we stand on the zotero buttons? Are they good enough to move to live or is there more work that needs to be done first? I meant to ask sooner so people would have time to comment, but I forgot. I'd like to update production once we get it to a point we're happy with it & think it's stable.
Zotero browser plugins work fine. The only problem is the in-page button, which only works with Zotero Standalone. I can always comment it out and then say in the tooltip for the main Save button/link that users with the Zotero plugin can click the icon in the address bar to save to their libraries.
On 11 August 2013 12:54, Rebecca Sutton Koeser notifications@github.comwrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
Can we revert to the pre-button version with the old 'go home' etc text and still have the other 'save page' fixes? (It'd be good to branch a version to work on the 'fancy Zotero save' options)
It'd also be good to check with @elirose to see where he's at with the Zotero library input integration - is there anything we should be aiming to test more widely before pushing to live?
Cheers, Mia
Sent from my handheld computing device
On 11 Aug 2013, at 21:18, scottkleinman notifications@github.com wrote:
Yes, that's easy. I'll do it.
On 11 August 2013 13:34, Mia notifications@github.com wrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
OK, reverted to text go home and save links. However, mousing over the save link will generate a tooltip with instructions for saving to Zotero with the browser plugin, so that functionality is preserved.
On 11 August 2013 13:54, Scott Kleinman scottkleinman@gmail.com wrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
I've only tested on my iPod but the reverted text looks good and more importantly the 'save results' page now shows all the results. Thanks for all your great work on this!
Cheers, Mia
Sent from my handheld computing device
On 11 Aug 2013, at 22:02, scottkleinman notifications@github.com wrote:
Grrr... I didn't change anything that would have affected the number of results--one way or the other. I think the Hippo is playing with me.
-S
On 11 August 2013 14:22, Mia notifications@github.com wrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
I looked at the code, and it looks like the save results is generating Trove data but not including them. It also doesn't have the error handling I added to the main results view. I'm going to go ahead and do a quick update to store the items in the session to ensure that the item-discovery logic and shuffled list of items displayed stays in sync (which will be more important if & when we add more sources and revise the selection & shuffling logic) the items displayed on the text listing page. I assume that the save results page should list items in the same order they are displayed on the main view page?
As a side note I'd like to rename the view/url from saveme but not sure what it ought to be. If /stash/ becomes /discoveries/ is this /discoveries/list/ ? /discoveries/text/ ?
The updated save could use some testing once it gets pushed to dev, if folks can take a look. Also, when I tested the COinS functionality with my zotero library as input today I got a unicode error - I think I've fixed it, but would appreciate if other people could test it some as well.
I actually like saving the results in session. This would have been my initial recommendation, but the framework I am used to, Flask, is a bit weird with sessions, and I didn't want to take that on for Django in the time we had available. Please do go ahead with this. I'm sure the results will be more consistent.
As far as names go, here are some more suggestions: /discoveries/resultlist, /discoveries/textlist, /discoveries/output-text, /discoveries/output-list. I think I'd be happy with any of them.
On 11 August 2013 14:48, Rebecca Sutton Koeser notifications@github.comwrote:
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
Just a note to say there's a spot for working out and documenting decisions on the wiki - https://github.com/chnm/serendipomatic/wiki/Serendipomatic-architecture
Looks like this one is a matter of getting on and finishing the fix, or @scottkleinman @rlskoeser are there any decisions still to be made?
Looking at code in master, I think this has been fixed and just needs someone to test and confirm.
Thanks! I've assigned it to @mfrazer so she can delegate the testing as necessary!
@mfrazer This was flagged as nov. release, but the fix is actually in place and the code will go out in the oct. release (unless we do something to prevent that). Hopefully we can get it tested before then. :-)
Can do. Sent an email a few minutes ago with a request for more info on a couple things.