Talk:ISFDB Feature List

Features needed for beta

Al currently has the pseudonym editor and watchlisting ISFDB data on the feature list for pre-beta. My own list would not include the pseudonym editor, which I think would be handy but not necessary. I'd ask for:

• watchlisting titles
• resubmit rejected records

and possibly

• free text deletion reason field for deletetitle, delete pub
• free text rejection reason field for rejected submissions

An issue occurred to me regarding multiple submissions that would have an impact on resubmitting rejects too. Suppose you have an UpdateTitle submitted by editor A, and later, but before the UpdateTitle is approved, a MergeTitle submitted for the same title by editor B. Now suppose a moderator approves the MergeTitle first. The UpdateTitle is now going to try to update a record that no longer exists.

Rejected records might become "out of sync" in the same way. I don't think this is a showstopper, though; it's going to be relatively rare, I would think, and I can't offhand see a way it would cause data corruption, although I need to think about that some more. Including verification that relevant data had not changed since submission would be quite difficult -- I've written code like that and it's non-trivial. Mike Christie 04:48, 29 Nov 2006 (CST)

Not that I am necessarily advocating implementing something like that pre-beta, but would adding a "last edited" timestamp to all records and to all submissions (to be compared at approval time) help alleviate the problem? Ahasuerus 09:41, 29 Nov 2006 (CST)

A follow-up comment. Though I think there are lots of very useful features that would help, I think Ahasuerus is right that we don't yet know enough about how editors will really operate to assert that we have to have the watchlist and resubmit capabilities. I'd be willing to go along with just getting the bugfixes done and starting the beta. The risk, as Ahasuerus pointed out somewhere, is that we discourage editors who don't then return. I think good support from the moderators can ameliorate that risk.

If I get just one feature, I think it's resubmit rejects. That would cut down on frustration more than watchlisting would. If I get two features, it would be linking "recent edits" to the moderator display, for all editors, so anyone can see what was changed. That would be a crude watchlist. Mike Christie 05:02, 29 Nov 2006 (CST)

Numbering

Any objection to me numbering the features? I'd start at 90001. I think I'd lose the "Series" separator; I don't think there's a need to track those independently, is there? Mike Christie 07:26, 2 Dec 2006 (CST)

Sounds good! Ahasuerus 17:37, 2 Dec 2006 (CST)

For features, should we make the feature numbers wiki links, to say Feature:90023? Many of these features (title charactirization, for instance) will need some amount of requirements gathering on how the feature should look, work, or be documented. It would be nice to collect that information in a single location, and it's a bit awkward to put all of that in the global feature list. Alvonruff 04:56, 15 Dec 2006 (CST)

Title characterization

I'm picking up a thread from Bibliographic_Rules#How_do_you_record_split_publications? which was getting rather long, and also because what I want to suggest is nothing to do with the current biblio rules.

It seems that a lot of what we want to say about a title is a way to characterize it -- it's abridged, fixedup, rewritten, expanded, translated, part 1 of a serial, 1965 edition, and so on. Would it be useful to add a "Characterization" field to the title record which would allow these options? Actually it could be free text, though I'd think we'd want to limit the variations somewhat. Then you could have title="Jem", characterization="", distinct from title="Jem", characterization="Part 1 of 4". Mike Christie (talk) 22:47, 14 Dec 2006 (CST)

What you are describing sounds similar to what I mentioned over on Bibliographic Rules the other day with two exceptions. First, I was thinking more along the lines of a dropdown list of allowed "characterization", but free text may well be a better way to go. Second, I was thinking that this "Characterization" field would apply to Variant Titles only and would be more of a "Relationship [to the parent title]" field. You seem to be suggesting that this field could be populated for any title, including standalone titles. How do you envision it being used for parent titles? Cases like "cut by publisher" so that subsequent Variant Title information, e.g. "text restored", would make more sense when displayed? Ahasuerus 00:02, 15 Dec 2006 (CST)

My 2-cents says I’m fine with a characterization field. In my own book list I thought about such a field but then realized I was adding notes all over the place (titles, sub-titles, author names, publisher names, etc.) and so I instead went with allowing (notes in parentheses) and the logic truncates those off as needed. Al may already be truncating at the "(" as the code already deals with “(part 1 of 3)” serialized titles. Marc Kupper 02:56, 15 Dec 2006 (CST)

Titles would be grouped and characterizations would be grouped and/or sorted. Translations could have the pubtitle in the actual pub language, the title title in the canonical version language, and a characterization on the title of "translation". Then they'd list under the canonical title if we want, or could be grouped separately as translations (ultimately a preferences checkbox). Mike Christie (talk) 22:47, 14 Dec 2006 (CST)

That would be certainly ideal, but first we would need to add some form of language support and populate the language field for some [unknown] thousands of records. That will take a while :-\ Ahasuerus 00:02, 15 Dec 2006 (CST)

Abridged, fixup, rewritten -- these are just displayed as parentheses after the title, but aren't part of the links, so the length of the hyperlink would be the only difference between this display and the approach of incorporating the parenthetical characterizations into the title field. Mike Christie (talk) 22:47, 14 Dec 2006 (CST)

We would be effectively replicating the standard encyclopedic functionality whereby titles are printed in one font (e.g. italics) and any additional information like "abridged" is printed in a different font. Which sounds eminently reasonable. Ahasuerus 00:02, 15 Dec 2006 (CST)

That gave me an idea for the DAW list and it was less then five minute’s work to fix the hyperlink generator for links to end the link before the " (". Marc Kupper 02:56, 15 Dec 2006 (CST)

Prioritizing features

Here's my list of features that I'd most like to see; I thought it would be useful to Al to get everyone's input on what would be most beneficial. I haven't paid attention to whether a given feature is easy or hard to implement, just to desirability. These are in order, with the most desirable (in my opinion) at the top. Any other opinions?

1. 90044 Historical display of edit contents (very hard)
2. 90050 Query to find edits relating to a title or pub (easy once 90044 exists)
3. 90075 Pseudonym and vt sourcing (need to create requirements)
4. 90063 Support for chapterbooks in bibliography displays (need to discuss if we want this)
5. 90047 Unmerge selection checkbox to unmerge individual pubs (easy/medium)
6. 90034 Separate "non-fiction" flag from "publication type" flag (medium)
7. 90065 Colour-code links to wiki to show if they have contents (needs research, probably easy)
8. 90067 Add Help link to wiki from ISFDB (easy)
9. 90072 Sort contents records in editpub display (hard)
10. 90074 Interior art display (medium, but error prone)
11. 90037 Resubmit capability for rejected edits (very hard)
12. 90017 Free text reason field for merge/delete edits (easy)

It should be noted that occasionally Al will ditch the suggested list and just do something fun.

-- Mike Christie (talk) 08:49, 27 Dec 2006 (CST)

Per Al there's a moratorium on "it would be nice" stuff for a bit while to better ensure that fixes are not introducing new problems and so I suspect he'll be selective about which items get worked in for the next couple of days. I've been linking the DAW list to ISFDB and in the process cleaning up author bibliographies. Overall, I'm happy with ISFDB with the biggest area that created confusion being pseudonym support. Marc Kupper 13:45, 27 Dec 2006 (CST)

My Library

Moved here from ISFDB:Verification requests where it really didn't fit, durign archiving of that page. -DES ^Talk 07:05, 11 Feb 2008 (CST)

Something I've been thinking about as a feature request would be a way for people to flag that they have a copy of a book but may not have verified it yet. This would allow for two things; 1) if someone has a question about a story then it would be easy to get a list of who has a copy so that they can be asked directly. 2) A couple of days ago I was interested in a particular short story but had no idea if I had a copy as I have not entered the contents of all of my anthologies/collections into my own book list. Thus I had to look down the list of publications that contained this short story and see if any of them rang a bell - it turned out I did have the story. I suspect this "My Library" thing would have to allow for that I have a copy of the title but ISFDB may not have a publication record and that it should allow for fast input of a list, either importing a file, or having a text box where I could copy/paste structured data. Marc Kupper (talk) 17:07, 28 Mar 2007 (CDT)

Some kind of "My Library" implementation would be very handy, but I am not sure how to go about it. For example, 95%+ of my personal catalog's records cover Titles, so it would be useless for Publication level work. And if you have access to the physical books in your collection, would a two pass approach be optimal?

I suspect that in a year or two, once existing data has been cleaned up, we will implement something similar to the IMDB's "My Movies" feature. Ahasuerus 20:30, 31 Mar 2007 (CDT)

I had not thought about that most people probably only have a list of titles/authors and probably have not made an effort to ensure they match the publications exactly meaning that if we did support a data import of a "My Library" it would need a list of records for things in the import list that did not match ISFDB and people could edit them to match, add the title to ISFDB, or choose to delete the record from their MyLibary as it was not for specfict. Marc Kupper (talk) 22:37, 2 Apr 2007 (CDT)

While checking to see if an author had a web site I found www.librarything.com - Maybe Al will be motivated by http://www.librarything.com/about which says this about the project "I conservatively predict the revenue will enable me to recline all day on an enormous pile of gold." Of course, I was the bank yesterday and they have some sort of kickback scheme going called "keep the change" and on the front counter is a jar of change. But, it's a jar of plastic coins and so if banks are handing out funny money then I'm sure Al's gold will be fool's gold. :-) Marc Kupper (talk) 22:55, 4 May 2007 (CDT)

Is this page still current?

Or are we working from the Sourceforge list now? BLongley 22:27, 1 June 2009 (UTC)

Based on the approach agreed upon on the Development page, it looks like we need to copy all outstanding feature requests (and bug reports, for that matter) to Sourceforge and then retire/archive this page. Ahasuerus 00:10, 2 June 2009 (UTC)

I have cleaned up the pag a bit, noting featues that were implemented some time since, and duplicate or related feature requests. -DES ^Talk 16:40, 3 June 2009 (UTC)