ISFDB:Proposed Interface Changes

This page is for proposing and discussing detailed interface change proposals, including examples screenshots. It will be archived on a more frequent basis than some othe discussion pages. Longer term or larger scope changes, particualrly ones affecting the database design, can be proposed and discussed on ISFDB:Proposed Design Changes. Once a change has been implemented or rejected, it is moved to ISFDB:Proposed Interface Changes/Archive.

Change Clone and Edit 'Submit' Buttons

Moved from the community portal -DES ^Talk 02:23, 14 June 2009 (UTC)

Would anyone else like to see this change submitted? Comments welcome. (Would anyone like to see 'for Approval' added to all submit buttons?) Kevin 04:08, 11 June 2009 (UTC)

I know there has been quite a number of times that I've handled submissions that I was sure should have been clones instead of edits, but I don't think this would solve the problem. I think the original links on the Edit Tools menu should be separated. There's been more than one editor who have told me that they simply clicked on the wrong tool. The message at the top of the edit screen was not a clear enough warning to them that they were updating instead of cloning. Perhaps making that message more explicit and bolder would help also. MHHutchins 04:27, 11 June 2009 (UTC)

I could rearrange the links (order) easily with the other change I'm submitting (Perhaps moving 'clone' down to just above 'delete'). Spacing changes would be more problematic. Kevin 04:33, 11 June 2009 (UTC)

It's not the spacing, it's the position. And moving them away from each other may help. MHHutchins 04:40, 11 June 2009 (UTC)

I tend to agree, move clone below the import/export pair. But I don't think this change to the button hurts anything, and it may help in some cases. -DES ^Talk 05:35, 11 June 2009 (UTC)

I agree with the mis-click comments. I know it has happened to me. As for the button, I think the change is too subtle. If you THINK you're doing a clone, "Changed" is not likely to catch your eye any more than the message at the top does. And, random aside, really long button names are not a typical UI practice. To have the desired effect, something very visually different is needed. I did not study the layout, but I'm thinking strongly-worded text above/before the buttons, perhaps in red or with a different background for the Edit case, would help. Something along the lines of Change this existing pub? and Add cloned pub? (they could both have a "Submit for Approval" button). --MartyD 10:22, 11 June 2009 (UTC)

I don't like the long button names, and think the warning should appear earlier - before you start entering data, rather than when you're about to submit. Moving Clone away from Edit will help though. BLongley 21:46, 11 June 2009 (UTC)

I also find that oversize buttons are generally not very effective. Moving Clone away from Edit is probably our best bang for the buck. Ahasuerus 23:23, 11 June 2009 (UTC)

I hear you on the topic of 'the big button seems wrong', but it's an easy fix, within our capabilities today, and easily changed again tomorrow. Yes, a warning on the area above the button is probably called for also, but I am personally throwing out Bill's arguement above about warnings 'above' the data entry fields (at the top, above a section, whereever). We cannot dictate the height of the monitor a user edits from (I'm on a laptop 90% of the time). We cannot control editor emotion or purpose (They are looking for the text entry field they need to change, possibly scrolling down before the page finishes loading, and they are excited about submitting a change/clone). We can control what is in front of them at the moment of truth when they hit the submit button. Yes a warning or descriptive text immediately above the button could also serve this purpose, but is not in my toolbox at this time. So I'm putting it back for discussion... please suggest button text to help differentiate Clone and Edit submission. "Submit Cloned Pub. for Approval" and "Submit Changed Data for Approval" are my new suggestions. Kevin 01:38, 12 June 2009 (UTC)

Well, how about "Clone Publication" and "Edit Publication" then? The part about moderator review/approval will be covered on the next page when we display the new warning text, right? Ahasuerus 03:50, 12 June 2009 (UTC)

"Change This Pub" and "Add This Pub"? --MartyD 10:38, 12 June 2009 (UTC)

For short and sweet, (especially if we drop 'for approval') yet different - how about "CHANGE Record" and "Submit CLONE" - All caps moves to different 'ends' of the button (It is visually weighted differently), no duplicate words on button pair, and the edit feature implies immediacy and permanence, while clone implies just one step in a process, which kind of matches, an EDIT is a permanent change even though we review it, and a Clone is one of the safest things for a new editor to submit. Also Marty gave me the code to apply color to on the webpage (and maybe buttons?) so I can also add some text above the button. Perhaps ... Click below to Change this record ... or ... Click below to Clone this record. More thoughts? Kevin 00:55, 13 June 2009 (UTC)

Yellow on white has a horrid low contrast at least on my display. I am dubious about using different colors here, much more about expecting a difference of color between buttons on different screens to alert those in need of alerting. I would also prefer the word "submit" in each button, whatever else you do. Perhaps "Submit RECORD change" and "Submit CLONE"? Just a thought. -DES ^Talk 22:47, 13 June 2009 (UTC)

Yellow-on-white is particularly difficult for our colorblind contingent (i.e. me). I generally like the following approach to this issue adopted by the US government:

Color is used to enhance, but color coding is not used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. If color is used to convey information, the information is also displayed in another format. (adapted from Section 508 of the US Rehabilitation Act of 1973)

Perhaps we could use colors in conjunction with something else, e.g. bolding or italics? Ahasuerus 23:11, 13 June 2009 (UTC)

Not meaning to offend.. but the information is in this little invention called words (chuckle). The color was intended to be the second method of information transmission. Also, the background isn't the same, it's light blue, so the effect will be different. Kevin 23:43, 13 June 2009 (UTC)

Hey, I'll take any color scheme as long as I can see the words! :) Ahasuerus 00:03, 14 June 2009 (UTC)

And I'll admit, I haven't made the change to test yet. I haven't even seen it - but I will promise to experiment to make sure it can be seen. Kevin 00:08, 14 June 2009 (UTC)

End of discussion moved from the community portal -DES ^Talk 02:23, 14 June 2009 (UTC)

Add publication to this title, from a shortfiction work

Discussion moved here from ISFDB:Community Portal#Patch r2009-05, because it was getting off-topic there. -DES ^Talk One Non-intuitive thing with Chapterbooks (At least non-intuitive to me)... we cannot go to a short fiction title, and use the 'Add publication to this work' link. If you do that, you can create chapterbook, but it's wrong, and it doesn't display correctly. (If you do this, you then have to unmerge the Chapterbook title, change the new Title from shortfiction to Chapterbook, add the shortfiction content and then merge. (Obviously it's much easier to just create a new title, and then merge). We may want to look into upgrading the support in this area so if you 'add' a chapterbook title to a publication. Kevin 03:20, 30 June 2009 (UTC)

That is true. Of course, you can't go to a shortfiction title, chose "add publication" and put in an anthology or collection that works properly, either. In fact currently, using "add publication" on a title record for a work of short fiction won't under any circumstances give you a correctly formed record without further tweaking. Perhaps "add publication" should be disabled when the current record is for shortfiction until/unless it is made to do something more useful? -DES ^Talk 11:38, 30 June 2009 (UTC)

See Bug #2814531 (Add pub doesn't work from short fiction) and the related FR #2814535 (Add pub should create a proper container for shortfiction) on source forge. -DES ^Talk 12:16, 30 June 2009 (UTC)

I've always considered "Add publication to this title" for content-only types a bit of a bug (and the number of times I've seen new editors try to add their own Shortfiction or Essay works in Magazines or Anthologies that way seems to prove it encourages some strange practices), so I'd be happy to support the prevention of such activity in the short term, and add support in the long-term. The long-term looks difficult - can we guess what type of Container title they should be adding from what's submitted, or just redirect them to Help on possibly suitable options? Some research on the problematical submissions might help, but I don't think we have enough data in the backups about submissions to do that, and Moderator observations might be a better clue. BLongley 20:34, 30 June 2009 (UTC)

My feature request for the long-term fix suggests a new screen or popup, on which the editor must chose from the available container pub types. I think this is better than any attempt to guess what might be meant, as the same work of shortfiction might very easily be found in a collection, an anthology, a chapbook, or a magazine, and possibly an omnibus. See User talk:Johnjosephadams#Someone is Stealing the Great Throne Rooms of the Galaxy for a recent case of an attempt to create an anthology in this way, and User talk:Johnjosephadams#Mazer in Prison for an attempt by the same editor to create a Magazine record. Take a look at the sourceforge item for the long term FR (linked above). -DES ^Talk 20:50, 30 June 2009 (UTC)

End of Discussion moved here from ISFDB:Community Portal#Patch r2009-05 -DES ^Talk 20:58, 30 June 2009 (UTC)

I did have a quick look at the FR, but it doesn't cover ESSAY (yet?). So NONFICTION container is another possibility to consider. A Shortfiction entry is unlikely to be added to such (although not impossible) so we could try some intelligence-based options. BLongley 21:10, 30 June 2009 (UTC)

That would be possible, but perhaps just askign the editor what s/he wants would be simpler, it's not like the list of possible types is so huge it needs tio be cut down for the user. -DES ^Talk 21:23, 30 June 2009 (UTC)

Ummm Why do we need to ask them (Again)? Isn't there already a drop down where the editor can pick the container type? What we need is for the 'short work item' to be prepopulated as an automerge content item within the new publication whenever they select this choice on a short work title. Kevin 02:27, 1 July 2009 (UTC)

I don't see such a drop down currently. Maybe I am missing something. The scenario I have in mind is: a) a user navigates to the title record for an item of type SHORTFICTYION (or perhaps ESSAY). b) The user clicks "add a publication to this title". So far there is nothing to tell the code what type of publication to create. Yes, once the pub form is dispalyed there is a dropdown to change the publication type, but I think by that time the setup has already been done. If not, if we can use that dropdown and only create the new title record at submit time. so much the better. i agree we need to preload the shortfiction or essay title as a content item and set it to automerge. -DES ^Talk 12:14, 1 July 2009 (UTC)

This is looking like quite a big change. addpub doesn't even have contents at present. newpub does, and it's simple to specify which type of container title you want: but you can't specify any default contents. Only clonepub handles default contents and automerge, but that currently only works for container titles and all their contents. Is this really worth the effort at present? I know I've never particularly wanted to use this. BLongley 18:35, 1 July 2009 (UTC)

Well, this was specified as the long-term half of a two-part solution, where the short-term half was just to disable the link when a shortfiction (or I guess essay) is displayed. That said, it would be a handy way to handle the case when a secondary source shows that a given work of shortfiction was published in a pub for which we have no other contents info -- non-genre magazines come to mind.It would also be a handy way to create new chapterbooks, or whatever they wind up being called, and if we try to implement a "new chapterbook" function, similar issues may arise. There was also a suggestion that if "New collection" (or perhaps new novel) was chosen from an author page, the author should be pre-loaded, which would face some of the same hurdles. So they may be worth facing in time, but none of these are must-do-right-now stuff, IMO. -DES ^Talk 19:19, 1 July 2009 (UTC)

I'm getting a little worried about the number of Bugs/Feature Requests being recorded - OK, in this case they're at least referring to each other, but there's over 100 things to choose to work on now and even if we could force people to only look at approved changes, each one seems to be leading to more obvious changes to the same piece of code: or shows an obvious need to change the same sort of thing elsewhere. I think we need some effort placed into cross-referencing and prioritising the bugs and FRs at Sourceforge - and I'd rather we don't try and stick with "keep the FR exactly as stated, we'll deal with the rest in another FR" or it will get worse. BLongley 21:00, 1 July 2009 (UTC)

This is a part-time hobby for most of us, and none of us is going to be able to keep on top of hundreds of potential changes, so I think we do need to start consolidating Bugs and FRs a bit more - fortunately any requester or reviewer can help. So mentioning that "author should be pre-loaded" is a suggestion somewhere is good, having that cross-referenced on the other affected requests would be better. Nobody will be able to get them all right, but any sort of linking you can spot and record helps: I'll try and spot things that are functionally unrelated but tied to particular modules (maybe Sourceforge can record such for us, I'm still pretty new to it and haven't stretched the capabilities yet) but I can already see that one "Outstanding change" is actually dependent on one "On Hold" change, so we're not doing it right just yet. BLongley 21:00, 1 July 2009 (UTC)

Anyway - back on this specific topic - I think Bug #2814531 might need to be sorted soon (Stop people doing it) if people are seeing such broken activity happening, but FR #2814535 can wait until we've covered all the other issues and there's enough people demanding it. BLongley 21:00, 1 July 2009 (UTC)

I agree with your final point, Do the big fix to disable the link that gets it wrong, then consider making it work right at our leisure. There have been cases of people getting this wrong -- two are linked above. Not every day or even every week, but now and then -- I think it is one of the "classic newbie errors" here, along with changing the content items in an anthology or collection. -DES ^Talk 21:07, 1 July 2009 (UTC)

I also agree that we need better sorting and cross-referencing of FRs. I have tried to add notes about related ones when i am aware of them, which is at least a start. -DES ^Talk 21:07, 1 July 2009 (UTC)

I think anything anyone can constructively add at Sourceforge will be a help, when it gets here we get into really long discussions. BLongley 21:11, 1 July 2009 (UTC)

I now see "author should be pre-loaded" is already on this page (and I mentioned it!), but I've still no idea if we have a FR for it. BLongley 21:16, 1 July 2009 (UTC)

It is now, see FR #2815480 Pre-load author or editor. I've also just cross-referenced some FRs. -DES ^Talk 22:12, 1 July 2009 (UTC)

Title Deletions and Votes: Two Questions

Deleting a title does not delete the votes for the title, resulting in a Python error in the My Votes display. This latter error has been logged as 2815724. --MartyD 12:44, 2 July 2009 (UTC)

Question 1: What should the display do?

The two options are:

Skip trying to display the vote record
Display the vote record with the title's id and an indication it has been deleted (and the other columns blank or "-")

I lean toward #2 only because #1 (a) would tend to go unnoticed and (b) gives the editor no identification assistance should the deletion go noticed and the editor want to complain or follow up with a moderator. --MartyD 12:44, 2 July 2009 (UTC)

I strongly favor #1. If a title is deleted all info about it should be deleted, and there is no reason to try to display the title in any form. Voting is not, or should not be, a proprietary activity. -DES ^Talk 14:01, 2 July 2009 (UTC)

Agreed, 100%. -- Dave (davecat) 20:50, 2 July 2009 (UTC)

We have a grand total of 14 orphan vote records in the database and they will no longer be created once this fix goes in, so hopefully this issue will become academic shortly. Skipping should be fine as long as we don't accumulate any more of them in the future. Ahasuerus 01:18, 3 July 2009 (UTC)

I am committing a two-level fix for this. The main level modifies the selection to exclude votes for which there is no title (i.e., "skipping" them). I also modified the level below to rended such votes intelligently, should they ever come into the routine again in the future. --MartyD 10:20, 3 July 2009 (UTC)

Question 2: What should title deletion do?

Regardless of the answer to Question 1, there's still the problem that deleting a title leaves the vote record around AND there is no way through the current interface to do anything about that orphaned vote. Do we consider that a problem I should log, and, if so, which is the problem: the creation of the orphan or the inability of the editor to deal with the orphan?

I consider the combination a problem and lean toward allowing the orphan creation, but then needing some way for the editor to remove the vote record. I think since the editor took the time to vote, drawing some attention to the deletion is appropriate. The orphan can be used to do that, but once notice has been taken, the orphan has served its purpose and is otherwise useless. --MartyD 12:44, 2 July 2009 (UTC)

I would strongly favor deleting the vote at the same time as the title is deleted. IMO a dangling vote serves no purpose. If you really want to auto-send a message to an editor who has voted for a title when/if that title is deleted, log that as an FR, it could be done i think. But I doubt that most editors will care, and most editors will not notice the "orphan" vote record anyway, unless we add a notification message. Cleanup may be needed for existing orphans, but once it has been done, no more should be created, ideally. I think the creation of orphans is a bug. -DES ^Talk 14:05, 2 July 2009 (UTC)

I'd delete, even though that will affect the Top Voters list. (I don't care as I'm not on it.) If people care about that then I guess we have to keep the orphans and deal with the display issues, but it doesn't look heavily used and probably not for competitive purposes.BLongley 18:09, 2 July 2009 (UTC)

Much as I hate to add to the stuff that's got to be looked at & done when a title is deleted, I think leaving orphan votes is just plain bad design. -- Dave (davecat) 20:53, 2 July 2009 (UTC)

Titles have two user-specific attributes associated with them, votes and tags. I think it's pretty clear that we want to delete all of them when a Title is deleted since it's really a bug that orphan records get left behind. Additionally -- and this will be a feature request rather a bug if we decide to do this -- do we want to display a list of votes and tags when the editor is presented with the "Deletion reason" screen? Similarly, do we want to show this information to the approving moderator when approving Title deletion? And what do we want to do when two Titles that have votes and/or tags get merged? Move them to the merged Title? Ahasuerus 01:16, 3 July 2009 (UTC)

I can't see that votes are a reason not to delete something, so I see no point in displaying votes to a deleter or moderator of deletes. Tags might possibly indicate that a deletion for "Not SF" is mistaken, so there might be some point in presenting them. -DES ^Talk 03:58, 3 July 2009 (UTC)

I would think that votes and tags of merged titles should be attached to the keepID, avoiding duplicate tags if possible. -DES ^Talk 03:58, 3 July 2009 (UTC)

Merge moves the tags and votes. I did not study how intelligent it might be about doing so. Deletion leaves the tags orphaned, too, but it causes only a minor display issue (each tag's count is off by the number of deleted titles). I have logged the deletion-leaves-orphans issue as Bug #2816243. Thanks for the input. --MartyD 10:40, 3 July 2009 (UTC)

I think we want to get rid of orphan tags as well. I played with them a bit as part of my testing and if a user has only one Title tagged, say, "Paranormal", deleting that Title leaves the tag behind and the user still has it in his list of "My Tags". It doesn't cause an error when you follow the link, but it's probably confusing. Ahasuerus 23:55, 4 July 2009 (UTC)

FR #2805588 -- "new talk" alert within ISFDB

Here is a first pass at adding a "new talk" link from the main ISFDB navigation bar(s) to the logged-in user's talk page in the Wiki.

A few thoughts behind this: (1) I am thinking a permanently present link would be helpful to the more casual/less frequent users, versus, say, having a link appear only when there is new talk. (2) I think the option should be in the same relative position in the menu, independent of browsing/editing/moderating context. (3) For folks who like to let talk accumulate, I thought a count might be useful.

I propose adding a My Talk link to the "Logged In As" section of the navigation menu. If the logged-in user has new talk, an additional trailing (n new) would appear after the link. The Edit and Moderator versions of this menu currently have just three entries: username non-link, Log Out link, and Help Navigating link. The browsing version of the menu follows those with a series of My xxx links. Giving the new link a "My" label causes it to look best at the top of these additional links, after the "Help" link:

I opted for "Talk" instead of "Messages" because common vernacular among the moderators and within Wiki posts seems to be to refer to "your talk page". I thought this would help tie it together. I'm of course open to other labels, other positioning, and other behavior. Feedback welcome. --MartyD 13:20, 4 July 2009 (UTC)

I think that might be good for experienced or even relatively experienced users. However, I fear it would not be obvious enough for newcomers, and IMO the most important part of this change is to alert newcomers to the fact that they have messages, and thus to the importance of the wiki to editors. I would suggest something like what the wiki software does, in addition to (or instead of) your suggestion: a large, contrasting link (say orange background) across the top of the page that appears when and only when the logged in editor has new messages. -DES ^Talk 14:10, 4 July 2009 (UTC)

Also, you show a count of "new" messages. I'll bet that what the wiki software gives you, if it gives you a count at all, is a count of edits to the talk page since the user last displayed it. If I edit Joe Blow's talk page (User talk:JBlow) to leave a message, then add a {{P}} link to the message, then fix a typo in it, I'll bet you'll get a count of 3, not 1. If so, i suspect this will be more confusing than helpful -- we'll see/hear lots of "where did the other two messages go?". Better check what the wiki actually gives you, and if I'm right, just show a binary "New/None new" -DES ^Talk 14:10, 4 July 2009 (UTC)

BTW, the phrase "your talk page" and the like is borrowed from the mediawiki software, and particularly from Wikipedia. It will be obvious to anyone who has done more than trivial editing there, I think -- but those are the exact people who will already jump at the link labeled wiki. For people who are not accustomed to a wiki, I think the link ought to include the word "messages". -DES ^Talk 14:10, 4 July 2009 (UTC)

When and if we develop stored preferences, a user should IMO be able to turn off the banner link, and depend on the more subtle style shown above. But the banner should default on for new editors. -DES ^Talk 14:10, 4 July 2009 (UTC)

I agree that "Talk" is Wiki-speak and if we are trying to target less tech-savvy users, then "My Messages" may be more self-explanatory. I am not sure how easy it would be to implement a banner, though. Ahasuerus 14:15, 4 July 2009 (UTC)

Mind you, by a "banner" I mean simply a link in the upper left or upper central part of the screen, present only when there are new messages, displayed in a bight, contrasting color and background color, possibly overlaying something already there. But failing that, can we at least dis ply the "new" part of the link in a bright, contrasting color, when and only when there are new messages? We want this to be something that screams at the new user, not something that gently hints, IMO. -DES ^Talk 14:28, 4 July 2009 (UTC)

BTW, I think Al was having problems getting the info from the wiki software that a user had new msgs. Has that been solved? -DES ^Talk 14:30, 4 July 2009 (UTC)

That's right, we found the secret code a few weeks ago :) Ahasuerus 14:54, 4 July 2009 (UTC)

Great. -DES ^Talk 16:13, 4 July 2009 (UTC)

Oh it occurred to me, in the absence of a preferences dialog, the wiki probably allows you to determine the number of edits by a particular userID. If that is over some fairly low threshold, say 50, consider the user to be an "old hand" and drop the banner, perhaps. -DES ^Talk 16:13, 4 July 2009 (UTC)

I suggest we limit ourselves to working within the current layout. Or log the banner idea as a further enhancement if we deem whatever we come up with within the bounds of the current layout to be inadequate. To answer the earlier question, yes, MediaWiki's new talk table tracks edits, so a count would be edits, not necessarily messages. Just detecting new talk, as opposed to counting, is easy. I tried going with something like "Messages" and "New Messages", and even with highlighting it's really not clear. So how about something like this:

The edit and moderator menus would be similar. The trailing "(new)" or some other indicator is needed to cater to people who can't distinguish the colors. This indicator could just as easily be a count (as illustrated above). --MartyD 17:03, 4 July 2009 (UTC)

I like this much better. I fear that a count would be misleading to many, and thus would avoid it, even though it might help experienced wiki users. -DES ^Talk 17:15, 4 July 2009 (UTC)

The latest layout looks good! <sorry, in a hurry at the moment> Ahasuerus 19:39, 4 July 2009 (UTC)

This has been committed. I centralized it, so it should be easy to change. And I implemented the background via a new style in the biblio.css stylesheet, so tweaking the rendering should be easy, too. --MartyD 20:56, 5 July 2009 (UTC)

Title Biblio - Display Artwork in List

See Image:Title-Biblio-Cover-Display.jpg for an example. I like having it 'at times' on my home system. ANy desire to tweak this for general distribution? Kevin 20:02, 12 July 2009 (UTC)

Interesting. I think I'd like that as an option - but with default of OFF. Can/are you deduplicating identical images? Similar images? BLongley 20:55, 12 July 2009 (UTC)

How do you see the selection of such working? Another option on the title page to turn it on after you've got there? BLongley 20:55, 12 July 2009 (UTC)

If not, perhaps we need to sort out storing "User Preferences", as the list of options down the left-hand side is already getting rather long, and often still doesn't include things I want easily available. (E.g. Just because I'd done something as a Mod doesn't mean I don't want the "Editing Tools" section available, I often do: why should I have to click the "Home Page" to get them back?) BLongley 20:55, 12 July 2009 (UTC)

Likewise, when I'm there, I don't want "Tools Used to Create This Site", "Policies", or "License". (The last is particularly confusing - which Creative Commons License are we working with?) BLongley 20:55, 12 July 2009 (UTC)

Yes, I've gone off topic extremely fast - sorry! BLongley 20:55, 12 July 2009 (UTC)

Not really. I had similar thoughts when coding this up. It really should not be set as default, but unlike the author biblio display, we are currently only setup for a single 'title list' display. THe sooner we have the ability for preferences, the easier it will be to propose and release some 'experimental' interface choices. Kevin 21:18, 12 July 2009 (UTC)

I agree this would be useful at times, either with a user preferences option, or with a mode-change link on the title display page, or even both, so that a temporary mode-switch could override a long-term user option setting. I also agree that a user preferences feature would be helpful in many ways. -DES ^Talk 21:32, 12 July 2009 (UTC)

No de-duplicating of identical or similar images. This is to let me 'see' the flow of cover art and editions more clearly. (It also makes finding defunct cover art's extremely easy across a title, as well as see titles that need artwork added. Kevin 21:18, 12 July 2009 (UTC)

De-duplicating identical images should be possible - don't show an image whose URL you've already shown. De-duplicating "Similar" would need assumptions - e.g. same Cover Artist credit for another publication of a title is likely to mean it's similar art (but not always). We might need both options - sometimes I like to check whether the cover blurb or prices or serial numbers are different, so we need all covers at publication level, sometimes it's just to check if it's the same general art (the "edition" level we don't have, which might be better represented on COVERART entries). BLongley 21:37, 12 July 2009 (UTC)

As a test, how does "The Colour of Magic" look to you? I know that's had the same Josh Kirby art on several editions, and cut-down versions on others, and other artists have done other covers. And the entries in Omnibus editions probably shouldn't look similar. Or is the code available for the rest of us to try? BLongley 21:37, 12 July 2009 (UTC)

The code is rather small... At line 273 in title.py change the one line

output = "<li>"

to

+         if pub[PUB_IMAGE]:
+            try:
+               output = "<br><li>"
+               output += '<a href="%s"><img src="%s" height=100 alt="picture" border=2 align=middle></a><ul><li>' % (pub[PUB_IMAGE], pub[PUB_IMAGE])
+            except:
+               continue
+         else:
+            output = "<li>"

And then add these two lines before the closing /UL to close the extra indent near line 340 (my line numbers are different due to comments)

+         if pub[PUB_IMAGE]:
+            print "</ul>"
+
       print "</ul>"

As to the Colour of Magic, take a look. You can see the artwork shift over time. Kevin 04:10, 14 July 2009 (UTC)

Interesting. I can see it "makes finding defunct cover art" a lot easier, which makes me think even more strongly that the "Cover art supplied by Amazon" is a mistake if we're showing it for pubs they obviously haven't supplied it for. As to artwork shifting over time - well, I see lots of different sections of the same artwork appearing. It'd start a discussion on what "same coverart" means at least though, and maybe that'll lead to some more merging - if not, then I still want to remove COVERART records from simple title search results. BLongley 21:27, 15 July 2009 (UTC)

Larger Note box in Publication Editor

A very simple request: It would be useful to double (at least) the size (both horizontal and vertical) of the 'Note' box in the Publication Editor ('Edit This Pub'). Editing a publication with a somewhat longer list of notes (say this one, it's now too easy to lose track of what you're editing. After all, most of us have bigger computer screens than we used to. Horzel 12:13, 16 July 2012 (UTC)

I am not sure what browser you are using but at least in both the recent versions of Mozilla Firefox and Google Chrome (which I have tested), this pub_note field is rendered in a form textarea that defaults to 40 columns wide and four lines but can be easily stretched to any size by dragging the bottom right corner. It might be cumbersome to do this for each edit that needs such. Of course the default size can be changed but I am not sure this is really required. Uzume 10:21, 7 September 2012 (UTC)

It wouldn't be difficult to do, but I agree that it's not been considered a priority. It might be quicker to document the fact that the textarea can be resized - although I'm not sure how many browsers that works in, I've not tested many. BLongley 15:45, 7 September 2012 (UTC)

It works under Firefox 15, but not under IE 9. Ahasuerus 00:21, 8 September 2012 (UTC)