ISFDB:Proposed Interface Changes/Archive

This is an archive of Proposed Interface Changes. Sections are moved here once the change has been implemented or rejected.

Series parent display

Moved from community portal -DES ^Talk 05:55, 14 June 2009 (UTC)

Feature requests 90004 and 90041 on ISFDB, now Feature Request 2800716 on Sourceforge (thanks to DES).

Is this the sort of thing desired? You can click on the link after "Child of" to move up a level, and such won't display if you're at the top level. You can also click on sub-series to move down a level, but it will still show the series level you came from as a "Child of" link. I know "Star Trek" isn't exactly a priority for most of you, but neither is "Star Wars", "Doctor Who", "Buffy the Vampire Slayer" or other such hierarchical nightmares. (No, I'm not inviting comments on sub-series ordering or such, just on links to parent series for now. Other editing nightmares will have to wait.) BLongley 02:54, 7 June 2009 (UTC)

Looks like a good idea. The only way to know is to click "Series Data" and see if it shows a parent.Kraang 03:22, 7 June 2009 (UTC)

I like the feature, not sure on the wording or placement. Could we call it "A Sub-Series of ..." and put an empty line between it and the series actually shown. This will help separate that it is 'extra' information, and not part of the series data selected for display. Kevin 03:24, 7 June 2009 (UTC)

The wording is easily changed if people want. "A Sub-Series of" might imply that there are other sub-series though, and that's not always certain. BLongley 03:49, 7 June 2009 (UTC)

I did look at various placement options and found that separating the position of the parent made it look unrelated, whereas a parent series seems just as valid a relationship as a child series, so I put it back to where it is in that example. Highlighting the level you're actually looking at in some other way might be another option though. BLongley 03:49, 7 June 2009 (UTC)

"Sub-series" is probably better than "child", but otherwise it would be a good addition. We will also need to enhance that screen by adding Variant Titles, but that's a different and probably more complex issue. Ahasuerus 04:11, 7 June 2009 (UTC)

I'm fine with dropping the A. I'm even fine with simply labeling it Parent Series:. The phrase 'Child of' just strikes me as odd (even thought it's technically correct) Kevin 04:21, 7 June 2009 (UTC)

"Sub-series" it is then. BLongley 12:09, 7 June 2009 (UTC)

Variant titles also added to the display. BLongley 15:42, 7 June 2009 (UTC)

End of discussion moved from community portal -DES ^Talk 05:55, 14 June 2009 (UTC)

Cover art supplied by ...

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

Initial Discussion

I have successfully gotten a local server up and am working on a feature that I think is within my grasp. New and improved 'Cover art supplied by ...' links for our many cover art files hosted by other organizations.

Now for discussion... I believe everyone is ok with adding links for the people who have voluntarily let us use their images and bandwidth per ISFDB:Image_linking_permissions. These should be links to a top level directory for each website. Some questions...

Should we implement a link (as shown in the example) to Amazon?
- Should we monetize the link with the ISFDB affiliate code?
Should we put in code for Ace Image Library (They haven't said yes, but I don't think we've asked them and I know there are lots of offending records in the database).
Should we put in a link to ourselves for 'Cover Art Hosted by ISFDB' with a link to the (Mainpage? Wiki Main Page? The Image again? The Image's Wiki Page (with rights stuff on it)).
Should we put in code to capture 'other' hosted images to attempt to credit other sites through automagic code that extracts the top level URL for the other host site?

Thanks for all your input, Kevin 00:01, 7 June 2009 (UTC)

My views:

A link seems fine to me, and I have no objection to adding an affiliate code for those sources that support such.
I urge that we ASK the Ace image library. If they don't say yes in a reasonable time, we should find the offending pages, and down load the images and upload them to the wiki, and remove the links.
There is already a Feature Request in the system for linking to the image description page rather than the raw image for locally hosted images. Perhaps this could be implemented at the same time. If not, a link to the image description wiki page for "image hosted by the ISFDB" would be a VERY good idea, IMO.
It is not the case for all sites that the top level URL is related to the given URL. particularly if a hosting service is employed without a custom domain, as may be the case for smaller/older fan sites. Since hovering shows the URL, I don't think trying top construct a link is a good idea.
Being able to search for image URLs from domains not on the white list (to remove them, replacing with a downloaded copy) would be very handy.

Is that workable? -DES ^Talk 00:20, 7 June 2009 (UTC)

Ooh, we're crosstalking tonight! Here's my comments:

I wouldn't add more Amazon links, we have those in the Navbar anyway. I actually think (given that they're unreliable links) that an Amazon Image should link to a warning that we'd prefer a local copy.
A credit for Ace Image library would be good, but it might be time to check whether they're upset with us. A link might cause them even more bandwidth problems.
For local images, DES has already recorded Feature Request 90159 here. This might be a way to implement it?
Feature 90139 might also apply.
The long term goal IMO would be to have a table of image sites, with some sort of indicators on whether we can use the image at all, how to credit the images, how to link to the image or the site, and the software should use that to ban submissions, or flag up warnings to mods, or credit images appropriately. BLongley 00:32, 7 June 2009 (UTC)

Responses to Bill's comments:

I agree with Bill on the long term goal. (IMO an image URL should be banned only if it is from a site known to refuse permission, i.e at the moment only Wikipedia. An unknown site should IMO be flagged but not banned, ideally.)
I do think that the text "Image supplied by Amazon" (or the like) would be good whether it is a link or not. As I understand it, Kevin's proposal that such text would link to http://www.amazon.com not to the amazon page for the specifc pub, am i correct? This seems to me at worst harmless.

Hope that helps. Other people's views? -DES ^Talk 00:47, 7 June 2009 (UTC)

An unknown site might be best dealt with by not using the image directly but by providing a link to the image, or the page the image is on, so we don't get accused of bandwidth theft. For most-abused sites, this might be quicker to implement in software (and easier on our disk space) than downloading and reuploading all their images, but software deployments here have unknown timescales so far. BLongley 01:16, 7 June 2009 (UTC)

I'd still prefer that Amazon links under the image (especially for ZZZZZZZZ images that may be replaced at any time by something totally different) do not link to Amazon but to a warning page. And if it's decided they MUST link to Amazon, I think they should go to the appropriate Amazon rather than assume that the US site is the correct one. This is not determinable from the URL, as far as I can see - Marc Kupper has pointed out that images seem to be centrally stored, but they're not necessarily used on all Amazon sites. So for instance, the hundreds of images I've uploaded to Amazon.co.uk will usually not be visible on Amazon.com. The only quick fix if such is really desired would be to use the currency symbol in our price field, and unfortunately for Amazon.de that's not consistent as to whether it's leading or trailing. BLongley 01:16, 7 June 2009 (UTC)

(after edit conflict)I see your point about the different amazon sites, and i fully agree about the ZZZZZZZZ images. +

On a numnber of occasions a new editor has supplied an image link to an author site, and self-identified as the author and granted linking permission. I wouldn't want to have to have a code change to approve such images. If there was an interface where ethe mods could easily add sites to the whitelist table, that would be different. But that is obviously a larger step. -DES ^Talk 01:37, 7 June 2009 (UTC)

The proposed link to amazon would just be to the top level 'Amazon.com'. I might be able to have it check the price and if it begins with the lb symbol, throw the link to 'Amazon.co.uk', But I have zero desire to duplicate the full links that already appear on the left hand side of the page to the specific pubs. Kevin 01:30, 7 June 2009 (UTC)

Asking the Ace image library folks sounds like an obvious idea. I am not sure why we haven't done it yet or, if we have, why they haven't responded.
Linking to the main Amazon.com page seems harmless. Even if we were to link to the specific book with the affiliate tag, it would still be OK since we are already using this tag when linking from the navbar. However, a local copy might be eventually better for the reasons that Bill outlined -- also see below.
Linking to the related ISFDB Wiki pages for local images seems to be a no-brainer.
Since Amazon.com (and some other) images are often unstable, at one point I wrote a script which downloaded all images that we link to and put them in a directory tree on my local server. I am not sure what we should do with this data (2.2Gb zipped), but it gives us more options, e.g. we could use it to replace Amazon images with local copies when Amazon's stuff becomes unavailable. Unfortunately, image uploads take time and at the moment I have my hands full with software testing, deployment, etc. Still, it's nice to have a backup. Ahasuerus 01:33, 7 June 2009 (UTC)

Of course, your backup will include a load of duff images. Even if it was for a verified pub when you took the backup, Amazon may have changed the image since the verification. I've caught one editor adding Amazon images as if they must be right because the Amazon link worked, and it was only when he tried to update one of mine to a cover I'd never seen that I stopped him. Whatever is in your backup from Amazon should NOT be uploaded as a replacement to anything verified, and quite probably not for anything that's still commonly reprinted. It should be a good source for our more obscure titles though. BLongley 01:49, 7 June 2009 (UTC)

I am sure many of the images that we link to (which are, by extension, stored in my backup) are bad, so I wouldn't want to upload them automatically. However, the image backup repository could be a good place to check if we find that a previously docile image has gone AWOL and we have no other image handy. Ahasuerus 02:47, 7 June 2009 (UTC)

The owner of 'Ace Image Library' is away from the office for a few weeks. I will ask again once he is back answering email. Kevin 03:34, 7 June 2009 (UTC)

He's been "away from the office for a few weeks" for the last two or three years, hasn't he? Maybe more. BLongley 03:53, 7 June 2009 (UTC)

Actually this page on his website was updated Feb of this year, and even mentions and links to the ISFDB. Kevin 04:00, 7 June 2009 (UTC)

Oh good, he is home occasionally! I see he could do with some help on the Doc Savage doubles, he's only found one. BLongley 12:46, 7 June 2009 (UTC)

Permission Received - Ace Image Library info updated on linking permissions template. Kevin 03:23, 9 June 2009 (UTC)

Round 2 - ISFDB Hosted Images

Okay. It seems like everyone is onboard for the basics. There may be consensus for amazon links, but Bill would prefer I not be .com centric. I will see if I can make something work to be less US based. There also appears to be consensus that this is a possible place and time to implement links to wiki pages for the ISFDB Hosted images (and I prefer this solution... I like clicking the artwork to see just the artwork). Lastly, the consensus appears to be 'no' for Ace Library credits (prior to permission), and 'other' assorted credits at this time. Please chime in if this recap doesn't fit with what you are thinking, etc. Kevin 04:08, 7 June 2009 (UTC)

I have managed to learn enough python tonight to generate an auto link to the Image Page (not the Image) for all locally hosted cover art images.

As you can see, I initially went with some different language... do we really want to say 'Cover art supplied by the ISFDB'? Seems pretentious. Regardless, I am VERY open to language suggestions for this link from the publication page to the locally hosted image page in the wiki. Thanks Kevin 06:37, 7 June 2009 (UTC)

The wording looks fine. Ahasuerus 04:15, 8 June 2009 (UTC)

Looks fine to me too. BLongley 17:19, 8 June 2009 (UTC)

I concur. The ISFDB hosts images, it doesn't supply them, as we normally record a source for all iamges, either a scan from a specified book, or another web site. -DES ^Talk 17:29, 8 June 2009 (UTC)

Round 3 - Amazon EU Hosted Images

Images hosted by the EU Amazon server will now show a link to Amazon.co.uk - How does this look? Kevin 04:09, 8 June 2009 (UTC)

Probably the best we can do given the vagrant nature of Amazon images. Ahasuerus 04:16, 8 June 2009 (UTC)

How are you determining that it's on an EU server? BLongley 17:21, 8 June 2009 (UTC)

A percentage of the Amazon image links are hosted on a server name EU-images or something similar. There is an example in my sample test links on the development page. Kevin 02:18, 9 June 2009 (UTC)

OK, I wondered if you had solved the "g-ecx.images-amazon.com/something" (US) versus "g-ecx.images-amazon.com/something" (UK) thing yet. I guess that's going to be impossible. I'd still make it a warning for ZZZZZZZ images though, whichever site it's on, and not link to either ("any" really as there's Amazon.de too). BLongley 19:52, 9 June 2009 (UTC)

Bill your last comment about still preferring no link due to the different Amazon's involved got lost in the shuffle. If you still feel strongly about this I'll happily resubmit a change that removes the amazon linking code, or just displays text "Image supplied by Amazon". Let me know. Kevin 03:31, 14 June 2009 (UTC)

Well, Amazon already get links from the sidebar, so I wouldn't add more. "Image supplied by Amazon" would be OK by me, although it's probably actually a customer image if it's good. But for the ZZZZZZZ images, I think a warning "Unstable Image from Amazon, may not reflect this edition" would be better. They can and do change, and are often wrong in the first place. BLongley 11:37, 14 June 2009 (UTC)

Round 4 - Code for Image Credits in the CVS

Download and test as you like. Kevin 02:19, 9 June 2009 (UTC) End discussion moved from community portal -DES ^Talk 02:33, 14 June 2009 (UTC)

Feature Request 2809517

Summary: Link REVIEW Titles to the reviewed Titles (Ahasuerus)

Description: For REVIEW Titles, hyperlink the REVIEW Title in title.cgi to the reviewed Title when the ID of the reviewed Title is known.

Comments: I suspect that this functionality was simply overlooked when the last round of changes to this page was implemented. Ahasuerus 03:50, 29 June 2009 (UTC)

Done. biblio/title.py 1.8 committed. BLongley 18:53, 29 June 2009 (UTC)

This could be made prettier, as a "known" title id of 0 will lead to the usual "title record error", but someone can build on my change for that if it's considered important. Long-term, we probably want to fix links to Authors that only exist because of this review as well. Somehow. And maybe sort out "Reviewed by a Pseudonym" author links to go to the Canonical author, e.g. "Frederick Patten" reviews might more usefully go to "Fred Patten". But maybe those need separate feature requests? BLongley 20:21, 29 June 2009 (UTC)

Err umm yes Please.?. Could we go ahead and 'escape out' a known title id of '0'. There is no reason for putting hyperlinks to no-where, when one if/then statement will remove the errant links before they ever exist. Kevin 00:45, 30 June 2009 (UTC)

Done - version 1.9 committed and tagged as r2009-06. I am not sure it likes my tabs, so I will nee to test it some more tomorrow. Ahasuerus 05:34, 30 June 2009 (UTC)

What have you got against "The Warrior Who Carried Life" by Geoff Ryman? ;-) BLongley 18:18, 30 June 2009 (UTC)

Hint: it's title 1. BLongley 22:30, 30 June 2009 (UTC)

Oops! Thanks, fixed in 1.10 and committed. Ahasuerus 23:44, 30 June 2009 (UTC)

Disposition: Implemented in r2009-06

Minor Navbar Changes Proposed - Edit Author, Show All Titles, Magazines and More

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

Feature 2803286 and 2800737 (Absorbs Wiki Feature 90148 & 90019): Minor Nav Bar Improvements
- This change will make minor improvements to the NavBar (The left hand side of the screen with lots of links).
  - On an Author Page: Change "Author Data" to "Edit Author Data" (Originally documented in Wiki Feature 90148)
  - On an Author Page: Change "Titles" to "Show all Titles"
  - On all pages (with 'Other Pages' section): Add "Magazines" link as on the main page. (I HATE having to go out to the main page just to find a magazine title)
  - On all pages (where it already appears): Change 'New Book' to 'Add New Book', etc for all 'New' Links
  - On an Author Page: Change "Dup Candidates" to "Check for Dup. Titles" (or "Check for Duplicate Titles"?)
  - On a Publication Page: Clone the "Edit Pub" selection and ADD "Add Contents to this Pub" - Same Function, Different Description.
  - On Main Page: Link Publishers to Category:Publishers.
  - Add Link to Help:Navigation_Bar
  - Examine New * links for possible rearranging of the code to allow prepopulated fields to be triggered in rev 2 of Navbar updates.

Comments, Suggestions, other similar requests while I have the file open? Kevin 04:04, 9 June 2009 (UTC)

Looks generally good, but I would suggest "Enter New Book" rather than "Add New book" and the smae for the other "new" functions.

Can you add a link to a wiki page such as Help:Navigation Bar where the available choices can be explained? -DES ^Talk 04:34, 9 June 2009 (UTC)

That will require a bit more digging into the code (as opposed to cutting and pasting into different sections, and minor text changes) but I'm game. Kevin 04:45, 9 June 2009 (UTC)

All i am sugesting is a single fixed link to a single wiki page, anywhere that it is handy in the nav bar. I hope that won't be too hard to create. If it is too hard, it is hardly vital. :) -DES ^Talk 04:49, 9 June 2009 (UTC)

It's more making sure it shows up on every page. The navbar coding is a snakes nest of if then statements, but I'm happy to work on it. Heck I'm just excited to be able to contribute simple code fixes like this, and leave more time for complex changes to Bill, Marty, etc. Besides, it's the simple stuff I've been complaining about since day one it seems (chuckle). Kevin 04:57, 9 June 2009 (UTC)

I see. Well if you can. Thanks. -DES ^Talk 05:02, 9 June 2009 (UTC)

Links to the wiki are fairly easy if they're static (we already have many), though the programmers should probably consider future-proofing against another move of hosts just in case we end up with something other than "www.isfdb.org/wiki" at some point. Kevin, feel free to ask for advice if it looks tricky. BLongley 20:06, 9 June 2009 (UTC)

I already learned how to use %s and HTMLHOST to trigger dynamic links to the wiki just in case we ever have a need for a different URL. The links to the wiki in the code I submitted yesterday are already dynamic. Kevin 22:34, 9 June 2009 (UTC)

As for the last suggestion, I think there's a feature request to pre-populate the author fields when adding contents to a COLLECTION. Which seems reasonable to me, but might move above the "simple" fix level. As it might also be wise to make the first record in an ANTHOLOGY an ESSAY as there's usually an introduction by the EDITOR(s)... the ANTHOLOGY default is looking to be more of a nuisance on most types too... just keep the fixes small and we should be fine for a while though. BLongley 20:06, 9 June 2009 (UTC)

We definitely need to change ANTHOLOGY to something else, although I think that SHORTFICTION is a better choice than ESSAY. Feature request 2803759 created. Ahasuerus 20:39, 9 June 2009 (UTC)

Small change for SHORTFICTION default committed, we can discuss the others more widely. E.g. OMNIBUS should probably have NOVEL defaults. BLongley 16:14, 11 June 2009 (UTC)

Supportive comments added on Sourceforge. We might need to split Kevin's small but useful improvements from the rest though - some Bug reports or Feature requests are just too big for the new crop of developers to look at in their entirety, we are learning from the small fixes. BLongley 21:07, 9 June 2009 (UTC)

I don't mind tackling the pre-population on edit screens, but would prefer to do those updates one at a time after I do the minor navbar updates. (and besides those each will need individual discussion and consensus) Kevin 22:30, 9 June 2009 (UTC)

(unindent) an additional navbar update. "Publishers" on the main screen now links to an out-of-date page that is a hangover from ISFDB1, as i understand it. I would link to Category:Publishers instead. -DES ^Talk 22:38, 9 June 2009 (UTC)

Accepted suggestions to date added to list at top. Help:Navbar Link, Publisher Category Link, Begin to investigate prepopulated edit screens. Kevin 22:51, 9 June 2009 (UTC)

Navbar Questions

There are 'Two' Navbar functions defined that I have found (so far, there might be a third? Who knows). The first Navbar function is defined in Common.py, and Biblio.py calls Common.py and has 5 arguments. So any file that calls Common or Biblio gets the Primary navbar. There is a second Navbar defined in isfdblib.py with only two arguments. This is the stripped down Navbar you see when on an Edit Page, because the edit pages (and the Moderator pages) call isfdblib instead of Biblio. Is there any desire (beyond mine) to attempt to reconcile this double Navbar situation? This will greatly expand the scope of files, but perhaps only slightly expand the scope of coding required to make this change. Comments, Suggestions, etc welcome. Kevin 04:03, 10 June 2009 (UTC)

The second Navbar includes logic which checks for login for editing purposes. Instead of rewriting the code and repointing, etc. I added the following 'other pages' links to the Edit Navbar under an 'Other Pages' heading.

Home Page
ISFDB Wiki
Magazines
Recent Edits
Recent Verifications

Comment Away. Kevin 04:53, 10 June 2009 (UTC)

The two different nav bars drives me nuts. I can see why we wouldn't want the editing links available while editing, but the others seem harmless and worthwhile. (And the coder in me would like to see centralized code, perhaps with arguments controling visibility of nav bar sections). --MartyD 10:05, 10 June 2009 (UTC)

I agree that having different navigation bars on different pages is problematic. When you're in edit mode, there's no need for any nav bars at all. There shouldn't be more than three sets of menus for any page of the database: one for publication level pages, one for title level pages, and one for everything else. MHHutchins 04:45, 11 June 2009 (UTC)

And one for Author pages, One for Moderator Pages, and one for Edit pages (Surely you sometimes at least need Advanced Search or from the Edit page) - Also When you Tab-Browse as opposed to Window-Browse your need for menu functions is much different. I have 23 tabs open at the moment for example). Look at it this way, we have Object pages (Author, Title, Pub), Public Function Pages (Edit), and Private Function Pages (Moderator); and the object pages each have unique requirements (Author (Edit Author, Psuedonym), Title (Add Pub to Title, Variant, etc), and Pub (Import contents, export, clone, edit, etc). In a perfect world, we would have one Programming function for Navbar, and trap each option or section depending on the page type. At the moment we have three different functions, with optional sections only on one function (main NavBar). Consolidating the code and putting real logic behind what's displayed is a bigger change. Kevin 05:01, 11 June 2009 (UTC)

There must be a way to determine which functions apply specifically to the page you're on and place those somewhere different on the screen from those functions that apply to every page. Or somehow make the page-specific functions appear different from other menu items, let's call them static links, because they stay in the same place on every page. You still haven't convinced me that you need any links on an edit page. Why not use one of the 22 other tabs that are open and leave that page for editing? I can't imagine navigating away from a page I'm editing with dozens of content entries, taking a chance that it'll be the same when I return. I use Firefox and wouldn't take that chance! MHHutchins 05:18, 11 June 2009 (UTC)

(after edit conflict) When i am editing i routinely right-click on navbar links to open the link in a new tab or window. Or sometimes I realize I have made a mistake and use a navbar link to go on to another place. I also sometimes enter edit mode with no intention of making a change, because edit mode is the only way to see exactly what is stored in some fields. Having seen, I may want to navigate away. -DES ^Talk 05:31, 11 June 2009 (UTC)

There is definitely a way to make every link page specific with one monolithic function block of code. I'm just not doing it. That is what I would call Major Navbar Changes. Each and every link or function call will need a discussion and somewhere between 15-40 code files *..py will need some changes based on it. Feel free to submit it as a feature request and I'll probably get around to it. At the moment I'm just looking for low hanging fruit to learn the language, and to learn the code. As for needing links on an edit page, you are welcome to submit a feature request to 'Remove all Links from Edit Submission Page' and can pretty near promise you that not a single developer will touch it without a near unanimous vote that all links should be removed from that page. Kevin 00:35, 12 June 2009 (UTC)

While we're talking about tabs, I maintain three: 1)Wiki 2)Submission Queue 3)Main Database (from which I do most of my searching and editing). These last two get switched around from time to time if I need to do some searching while I'm editing, or approving what I submitted. MHHutchins 05:25, 11 June 2009 (UTC)

I contemplated a centralized solution, but that's more of a Medium to Large change... The easier method might be to break Navbar out of common.py and isfdblib.py and moving it to navbar.py. Otherwise I'm afraid there might be other duplicate functions if we just centralize in common.py. Once it's developed we could then possibly try moving it back to common at a later date. (shrug) - Either way it's good idea, but I know i don't feel comfortable branching out that far yet (And I think Ahasuerus might faint if we had a single fix which touched 20-30 files this early in the 'getting our feet wet' process of development). Kevin 23:27, 10 June 2009 (UTC)

Turns out there IS a third Navbar defined in the code. There is a Primary one, an Edit one, and a Moderator one. Planning on doing updates to all three. Speak out if this bothers anyone! I will post screen shots prior to uploading for final comment. Kevin 02:54, 11 June 2009 (UTC)

Navbar Update Example Screenshots

<--Moderator_Menu <--Publication_Menu <--Author_Menu <--Edit Menu <--Main_Menu

Feedback desired. Kevin 03:26, 11 June 2009 (UTC)

Feedback

Some of these I like (particularly the renaming of the tools on the Author Menu), but some need more explanation. I don't understand why someone would need two links on the Publication Menu for the same purpose. Wouldn't "Edit This Pub" lead to the same edit screen as "Add Contents to This Pub"? (Unless you plan to create a new function in which the edit page doesn't include the pub header fields, only a set of content entry fields.) Another thing, why single out the Magazine link above all other links to the Wiki? The link to the Wiki should be sufficient. I'd rather have the Moderator link at the top of most pages, but I can see why it wouldn't be of any interest to the non-mods. MHHutchins 04:37, 11 June 2009 (UTC)
You are correct, Add contents and Edit this Pub are the same function. Duplicating the link may hopefully make it more obvious that you 'can' (and where to) add contents to a pub to a casual browser / user / New Editor. As for the Magazine link, since Magazines aren't searchable, they are a pain to get to from anywhere in the database except the front page. This new link to magazines brings that information forward? in the user experience. (I know that I regularly gripe to myself when I need to get to a magazine. Kevin 04:44, 11 June 2009 (UTC)
Most of the popular magazine titles have their editor records in a series. Do a search for the magazine title under series. This should bring up most titles. If not, then that's one that needs to be put into a series. MHHutchins 05:02, 11 June 2009 (UTC)
Have at it. Making an additional manual step just to make something easily findable is way outside my realm of desires. While most popular magazines may have series, all magazines are supposed to have a link from that wiki page or sub-page. Kevin 00:25, 12 June 2009 (UTC)

I agree with Mike that the duplicate links to "Edit this pub" and "add content to this pub" are unneeded and potentially confusing. I don't feel strongl about the magazine link. When editing I genrally keep a tab open to teh wiki, and could reach the wiki magazine page that way, but I don't work with mags much anyway. Note that teh various "Top xxx" links are NOT "Moderator only" they are open to non-mods. Perhaps they should be "submission-related links" or some such. Perhaps "Clone this pub" should be moved to below "Import content" to separate it visually from "edit this pub" and avoid mis-clicks. -DES ^Talk 05:18, 11 June 2009 (UTC)

As the system is currently set up, those particular links are Moderator Only links. They only appear on Moderator navbar pages, to my knowledge. I simply labeled the Moderator Navbar better. Kevin 00:28, 12 June 2009 (UTC)
I think you will find that if a non-mod clicks on the "moderator" link from the main page, s/he gets a page where the only available functions are the navbar links to Top Contributors, Top Verifiers ans (I think) Top moderators Moreover, i think this is the only way for a non-mod to get to those lists. i know that I viewed my edit count\ regularly, perhaps too regularly, before I was a mod. Try it with a non-mod account. -DES ^Talk 04:18, 12 June 2009 (UTC)

"Edit this Pub" and "Add Content to this Pub" are not confusing to me, I'm not sure why they are to you. There are two different editing areas on a publication edit screen. The Pub itself, and the contents of the pub. In the future I personally wouldn't mind if we separated those two areas as an edit function. (I'm not talking new submission, I'm talking edit only). The reason we have two different editing areas on the screen, is because we are performing two different tasks. I can assure you, that as a new editor I was seeings links about 'Import contents', 'Export Contents', and 'Remove Titles', but there was no link to 'Add Titles' or 'Add Contents'. I did learn to use the 'edit this pub' link to add contents, and it didn't take too long. This is my attempt to prevent other new editors from experiencing the same confusion I experienced. If we make the system so 'obvious' to us with experience, that newbies can't find the function they need, they will be more inclined to leave and not contribute. If there is a great deal of angst on this issue, I'll let it lay fallow as an Idea for now, but I will submit to you that for an uninformed person, who comes to the site, that a 'complete set' of "Import, Export, Add, Remove" Content Titles will be much more intuitive, than adding content by editing the publication. Kevin 01:10, 12 June 2009 (UTC)
It is not o much that they are confusing it is that as long as they lead to the same screen, they are redundant. And such redundancy might confuse some editors, who would rightly expect different links to lead to different functions/screens. -DES ^Talk 04:25, 12 June 2009 (UTC)
I think there is a longer-term plan here, and not the "split the editing screens". Consider the example of a Collection. If there's no SHORTFICTION contents, "Add contents to this title" could provide a screen with several empty SHORTFICTION entries, pre-populated with Author. Whereas "Edit this Pub" would just show the existing contents (INTERIORART maybe). If there are contents, "Edit this Pub" would still just show existing contents whereas "Add contents to this title" would show existing contents and add a few more empty SHORTFICTION entries, pre-populated with Author. Same screen, but different initial state, based on the intent expressed by choosing one option or the other. BLongley 19:30, 12 June 2009 (UTC)
That might make sense, but if that is the plan, I think the new "add contents" link should not be added until it does something different. Otherwise editors will get used to it being redundant, and may not discover the new functionality when it is implemented. Moreover, no such plan was mentioned above when reason for this change were put foreword. -DES ^Talk 19:57, 12 June 2009 (UTC)
Given current organisation of future developments (i.e. none) I think it's sometimes best to do something harmless in the meantime. I can look at several feature requests and think "those should go together for now", and also see a longer-range goal. But there are others I can look at and see are totally contradictory. Presumably big changes will get announced widely, but we're not going to get big changes if we quibble over the small. BLongley 20:57, 12 June 2009 (UTC)
Don't mean to quibble, feedback was asked for. It seems to me that having at any point in the development process, two navbar links which, at that time, do the exact same thing is a mistake. I have indicated my reasons for this view above I think. I will not go on about the issue, and i don't think this would be a horror if a view other than mine prevailed. -DES ^Talk 21:19, 12 June 2009 (UTC)

A "development strategy" (or some approximation thereof) is something that we will need to come up with over the next couple of months since there is no reason to spend time implementing minor changes in areas that will be completely redone just a few months later. Al's original plan was to (eventually) implement an AJAX interface that would eliminate the need for most Title merges, but we are probably not there yet in terms of our programming capabilities. On the database side, the two things that Al planned to work on were eliminating the "lexical match" logic for Serials (similar to what he did for Reviews last year) and finishing an Award editor. Come to think of it, we need to find the version of the latter that Al had in the works and see if we can finish it on our own. Making CHAP(TER)BOOKS into Container pubs is another thing that is fairly high on the agenda. Ahasuerus 21:34, 12 June 2009 (UTC)

The code is in the source. The Awards entry is available to Al's usernumber only, and there are hints of award editing functions sprinkled around and commented out of the remainder of the sourcecode. Kevin 00:40, 13 June 2009 (UTC)

It's under Al's usernumber only, as the editing screens need some work to make them more user friendly. It's pretty easy to make a mistake that requires direct hand editing of the database to correct. It works fine for me though. :) Alvonruff 12:00, 14 June 2009 (UTC)

Now as to a proposal to split the editing screens, so that the metadata and the contents would appear on different screens, that is another and a larger matter. it might well make things simpler for the new editor. But i think it would slow me down, and quite possibly other experienced editors. When I have a pub in hand, and am comparing it against a record, particularly an amazon or other stub record, i typically correct the metadata, add notes, and enter the contents in a single edit session, of the going back and forth from the metadata to the contents, particularly to copy the title for a parenthetical on Introductions and Author's notes, and to copy an author or editor's name when the same person also wrote content items. Having to do these in separate edits would not be an improvement for me. -DES ^Talk 04:25, 12 June 2009 (UTC)

UNindent - I will remove the 'Add Contents' clone of the 'Edit This Pub' link from this proposed change. Thanks Kevin 00:41, 13 June 2009 (UTC) End of discussion moved from community portal -DES ^Talk 02:29, 14 June 2009 (UTC)

Screenshots Round Two

If there are no strenuous objections I will upload these changes to the server tomorrow night (Tuesday 23 June). If there are any additional small changes, they can also be implemented. Kevin 04:35, 23 June 2009 (UTC)

No strenuous objections (I'm not a big fan of "strenuous" stuff), most look good to me and the rest are harmless at worst. Additional small changes might be moving "Key Maintenance", "Edit Ref List", and "Log Out" somewhere I'll never accidentally click on them - I've used the first once and that's all I'll need, the second doesn't currently work (although might if one of my proposed fixes gets in), and the last is something I almost always do by accident rather than design. BLongley 21:05, 23 June 2009 (UTC)

- Good Idea. I had it myself. I just wanted to limit 'grand rearranging' to a different change discussion, possibly connected with centralizing the three menus. Kevin 03:06, 24 June 2009 (UTC)

Looks good to me also. I would add the "Top Lists" to the main menu if designing a-la-carte, but that is a very non-urgent issue. Some things I don't much care about, but won';t affect me negatively. If "Check for Duplicate Titles" were changed to "Look for Dupl Titles" (or something similar) would it fit on a single line? I would prefer to avoid wrapped navbar entries when possible. But we already have some, so... -DES ^Talk 21:25, 23 June 2009 (UTC)

- Good Idea on the Top lists. I had it myself. I just wanted to limit 'grand rearranging' to a different change discussion, possibly connected with centralizing the three menus. As to the wrapped menu choices, I also had the same thought... can I cut it down and wanted clarity over brevity for now. Kevin 03:06, 24 June 2009 (UTC)

- "Find Possible Duplicate Titles" is probably more accurate, I don't think we have the problem with it not checking Variants sorted yet, and such still throws up some dangerous suggestions like merging a shortfiction work with a collection or omnibus named after it. And we probably should work on making it clearer when there is a "these are NOT the same work, do not merge them under pain of having your testicles chewed off by my pet hyena" note or suchlike. But I digress - what should the short menu option be? "Find Possible Dups"? BLongley 21:49, 23 June 2009 (UTC)

- - Clarity over Brevity for now (no Dups, or Pubs, or Tits, or Auts (Why Titles and Authors, of course... Get your mind out of the gutter). I am open to alternate language, but I would really prefer to try this out for a month or so. Kevin 03:06, 24 June 2009 (UTC)

- - I don't think "Check for" or "Look for" implies that all dups will be found. And strictly speaking two works with the same name by very different types (such as short fiction vs Novel or Novel vs Omnibus) are duplicate titles. Getting back to the navbar text, "Find Possible Dups" is OK, but I think "Look for Dup Titles" is better because it reminds you what is being checked for duplication -- the title string. The old "Dup Candidates" was not bad either, because it reminded the user that judgment was still required. It also fit on one line. Not a huge deal in any case, IMO. -DES ^Talk 22:39, 23 June 2009 (UTC)

Main Menu Comparison

Three key changes to the Main Menu. Kevin 04:35, 23 June 2009 (UTC)

Added Help Navbar Link
Changed Publishers to point at the Wiki Category (Instead of the old ISFDB1 page)
Changed all 'New' links to 'Add New' links.

Author Menu Comparison

Six key changes to the 'Author' Menu. Kevin 04:35, 23 June 2009 (UTC)

Added Help Navbar Link
Added Magazines Wiki link to 'Other Pages'
Changed 'Author Data' to 'Edit Author Data'
Changed 'Titles' to 'Show All Titles'
Changed 'Dup Candidates' to 'Check for Duplicate Titles'
Changed all 'New' links to 'Add New' links.

Edit Menu Comparison

Four key changes to the 'Edit' Menu (Any Data Entry Screen). Kevin 04:35, 23 June 2009 (UTC)

Added 'Advanced Search' Blue button below basic search. Note this placement is tighter than on Main menu - Can be moved down with an extra
line. (This replicates Main Menu look)
Added Help Navbar link
Added Wiki, Magazine, Recent Edits, and Recent Verifications to 'Other Pages' (This replicates the Main Menu look)
REMOVED extra Brackets from all menu options (This replicates the Main Menu look)

Moderator Menu Comparison

Five key changes to the Moderator Menu Kevin 04:35, 23 June 2009 (UTC)

Items 1-4 from Edit Menu
Rearranged links into Moderator Only links, and Top Lists. (Note: We may want to consider putting the top lists elsewhere someday)

Disposition: Implemented in r2009-07

Series Wiki Link - Not Currently Red

Bug 2812300 - Empty Wiki links from Series pages are not Red. Work Completed. To be uploaded upon request. Kevin 18:23, 25 June 2009 (UTC)

Current Behavior

Proposed Behavior

Looks ok to me. I presume this is a required preliminary step to implementing FR 2805090 (Make state of wiki links clearer) and FR 2805093 (Preload wiki links). If so, all the more reason to go ahead with this change, IMO. -DES ^Talk 18:34, 25 June 2009 (UTC)

Yes. If not implemented before those changes, it would have to be implemented concurrently with those changes for those features to be available on Series links to the Wiki. Kevin

Bump - For Approval? Kevin 02:29, 1 July 2009 (UTC)

Looks good! Ahasuerus 05:03, 1 July 2009 (UTC)

I like, go for it. BLongley 21:05, 1 July 2009 (UTC)