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 dwesign, can be proposed and discussed on ISFDB:Proposed Design Changes

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)

1. Added Help Navbar Link
2. Changed Publishers to point at the Wiki Category (Instead of the old ISFDB1 page)
3. 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)

1. Added Help Navbar Link
2. Added Magazines Wiki link to 'Other Pages'
3. Changed 'Author Data' to 'Edit Author Data'
4. Changed 'Titles' to 'Show All Titles'
5. Changed 'Dup Candidates' to 'Check for Duplicate Titles'
6. 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)

1. 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)

2. Added Help Navbar link
3. Added Wiki, Magazine, Recent Edits, and Recent Verifications to 'Other Pages' (This replicates the Main Menu look)
4. 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)

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

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)

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)

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:

1. Skip trying to display the vote record
2. 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)

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)