Jump to content

Fred Slota

Members
  • Posts

    1,129
  • Joined

  • Last visited

  • Days Won

    16

Posts posted by Fred Slota

  1. So, I searched for ItemDescription = "Variant Cover" and only "Variant Cover", and started adding descriptions to all the variants of an issue (where a scan existed) when there was a Variant with a generic "Variant Cover" ItemDescription.  I did a couple of titles and waited to see what would happen.

    The title "Archie" ended up having quite a few starting at 641/A, and I also did a few in Amazing Spider-Man such as #570, #666 and #691, among others.

     

    When I posted these updates, I moved Cover Artists names to the CoverArtist field if necessary, retained any other variant description, and added a cover description in the form "Cover shows xx xx xx xx".  I think I used the "cover shows" wording consistently, but I can't be sure since the last updated overwrote my ItemDescriptions, which I wasn't expecting.

    In the Amazing Spider-Man issues, the descriptions were added for all variants, but my submitted descriptions were placed in parenthesis, and the cover artist references were retained.

    In the Archie issues, the descriptions were added only for issues where the ItemDescription was empty, and were added using my submitted "Cover shows..." instead of in parenthesis.  And all the entries, which already had cover artist names in the CoverArtist field only did not have their cover artists copied into the Item Descriptions when Item Descriptions were added.  Oh, and it looks like all my descriptions starting at 700 were dropped, I guess because starting with those issues the ItemDescription started including the cover artist information.

     

    So, which is it?  Cover descriptions: yes, no, sometimes yes, sometimes no?  Cover descriptions in parenthesis or as "cover shows..."?  Cover Artists duplicated in ItemDescription, or not, or sometimes yes, sometimes no?

     

    I'm also mildly annoyed that among the Archie's I found that the regular and 5 variants of #666, which was a series ender issue, were a 6-panel connecting cover set, and that that detail was dropped along with my cover descriptions.

     

  2. If we're going to sanction the database madness of repeating Cover Artist in both its dedicated CoverArtist field and the Notes field, can we at least settle on a consistent nomenclature?

     

    I suggest "Cover by Joe Smith" or "Retailer Incentive Cover by Joe Smith", as opposed to "Joe Smith Cover" or "Joe Smith Retailer Incentive Cover".  This would allow searching for cover artist in the notes field.

     

    As a related suggestion, notes about photo covers should use the form "Cover of model Jane Doe" as opposed to "Cover by model Jane Doe", clarifying the difference and allowing for consistent searches.

  3. Ahhh, had a pair of earlier not-yet-consolidated boxes...

     

    2020 Iron Manual, one-shot, 4"x6.5", 28 pages, no adds

    Cover price FREE, IIRC my store had a stack of them at the counter...

    first page is a reproduction of the cover for Iron Man 2020 (2nd Series) and a 4 page sneak peak of the same, followed by single page handbook-style character sheets for related characters and teams.

    So, mostly no story or sequential art.

  4. I have both, but oddly, the more recent one is hiding at the moment...

     

    Iron Manual, (1993), one-shot, 32 pages, no adds.

    Cover Price $1.75, sold in stores, not a giveaway.

    No story, no sequential art

    Done in the style of looking through a computer archive with personal noted by Tony Stark, shows illustrations, schematics and exploded views of suits, tech and buildings/labs.

     

    The cover includes the statement "The Ultimate Operations Handbook of the Golden Avenger's(tm) Armor"

  5. I'd recommend using custom checkboxes and custom Text Fields.  You could then search and produce different lists.

     

    Additionally, if you have a complex situation, such as 10 copies of a book were you want to keep 3, are slabbing 4 and selling 3, consider duplicating the item so you can count and tag the three entries separately.

  6. 1) I wasn't aware of the GradingNotes field. Functionally, this sounds like what I was thinking of.  Maybe more of an AA question, but where does that show in an AA listing?  Is it concatenated with the Notes field?

    2) I did address the changeover question with my final sentence - If a listing has no SellerDescription (or GradingNotes), then show the Notes for their entry.  I don't want to unnecessarily annoy people, either.  Or at least, any more people... ?

  7. Apologies if this already exists, as I've never posted for sale on AtomicAvenue.

     

    Currently, when you look at an individual issue, the top part of the screen shows the official ComicBase Notes field, and for each sale listing, you see the possibly modified Notes field from the seller.  In many cases, these individual entries contain a repeat of the official note.  In many cases, many of the entries contain the same repeat of the official note.  When a seller adds custom notes, it makes it harder to notice alongside the official note.  When multiple entries contain the same repeat of the official note, it is harder to notice one custom addition among the multiple repeats of the official note.  Also, when the official note states "bagged" or "with card", and the seller has both the official note and a custom addition stating "unbagged" or "without card", you get a confusing posting.

    I propose a separate field, SellingDescription, meant for the separation of the official  notes from the custom sale note.

    To avoid the disruption on people selling from different version of ComicBase, or people who don't switch over to using this field, a selling submission with a blank SellingDescription would show the submissions Notes field instead.

  8. Mainly for my curiosity, but what is the background on its value difference from the other 4 first-print variants?  I see that there is an odd  AtomicAvenue offering of a a VF-NM at $294.99.  Does that have an effect on the valuation?  Or is that Deadpool card really that much more popular?

  9. Okay, I suspect something deeper is wrong.  Since I've been cleaning up my database the last couple of weeks, I've been using manual Updates (not automated with Sidekick) so I can get a report of the unrecognized items.  Not only am I still getting the error with trying to integrate my ComicBase Mobile scanned purchases from last week using "Check for new sales and purchases", but my recent attempts to "Check for Updates" continue to say I have the most recently updated content.  A new update should have been pushed in the last couple of days, right?  The most recently generated Unrecognized items listing is from 1/26/22.  Can I please get some feedback?

  10. 2 hours ago, Douglas W. McCratic said:

    I'm able to sit here typing this because I have had redundancy at critical times in my life.  Things fail, they get used incorrectly, they get misplaced but redundancy allows us to move forward when it happens.  That's very different from a database, I get that.  Having seen redundancy in action, I will take it any day of the week. 

    Yes, exactly.  That middle part.  And then you go and completely undercut the contrast you set up with your first two sentences and contradict it with your third.

     

    Respectfully, now it sounds like you are grasping at straws in attempt to justify or strengthen the argument.  Databases are not meant to have redundancy.  They are meant to organize information in an efficient and consistent manner.  Repeating "cover by" thousands of times makes a database larger, take longer to load, longer to search, longer to longer to rebuild notes, etc.  Using a free-form text field allows multiple styles of recording a a piece of information such as "cover by Joe Smith" and "Joe Smith cover" and cover artist Joe Smith" and Joe Smith (cover artist)", making searching and sorting difficult and/or unknowingly incomplete and/or impossible. 

    If you want redundancy against errors, or catastrophes, or personal info versus supposed public info, keep parallel databases or backup databases.  Or when attempting to submit modifications for acceptance in the master database, copy the data (temporarily or permanently) in one of the custom text fields.  The desire to carry a piece of information officially in two places in a database "just in case" is a really poor justification.

     

    Also, wanting printing doubled in Notes or ItemDescription?  Why.  The book should be identified as -2, or -3; if it's not, that's bad.   If "Staring at a screen for long periods of time, it's easily to lose track of things like -A, -3, -A-2, -B-2", then make the "Printing" or "Type" or "Variation" field visible and more prominent in grid view.   Having a Note or ItemDescription that reads "Second Printing" provides no information to help you identify how you would tell a second printing from a first printing, no more than having the issue tagged as -2 or -3 does.  You tell them apart by notes like "Foil Cover" or "blue background" or CoverArtist "Joe Smith" or "Steve Jones".

     

    Cover Artist is useful information.  So useful that after, what, 15 years, it was elevated out of the catch-all of "Notes" and given its own separate "CoverArtist" field.  Just like a description of what separates different variations from each other was also pulled out of "Notes" a couple of years later and given its own separate "ItemDescription" field.  I realize there is history in using this information in the old way, and that the migration of this information out of "Notes" and into "CoverArtist" and "ItemDescription" is inconsistent and incomplete.  But we should embrace the change and use it.  

  11. I guess my memory retained what I wanted to hear.

     

    Printing is a necessary piece of information to identify a book; should that also be repeated in the Notes/ItemDescription?  Annuals are separate items, yet that can safely be kept in its own field.  UPC is also useful to differentiate issues;  I notice no one is advocating repeating this information in Notes/ItemDescription.  

    I suspect part of this difference of opinion is that the other fields have been separate since the beginning, while CoverArtist  was only recently introduced.  Earlier, the information was deemed so useful and with no other place to go, it was being entered in the freeform Notes, and now carried over to ItemDescription.  We have thousands on thousands of Cover Artists mentioned in Notes/ItemDescription collected over the years, and people have been using it that way for all those years.  

    We've always had cover identification information in the Notes field; that's where we'd go to identify books in the past.  Yet I don't see people asking for the cover description information to be retained in Notes while being copied into ItemDescription.

     

    I understand Cover Artist is useful information for issue discrimination.  For those who find it so, why not rearrange the presented field order to place Cover Artist next to Item Description?  I suggest that would make Cover Artist centric folks' lives easier, as it will require less reading and processing of long Notes fields to find this apparently critical piece of information.

  12. Paraphrasing and synthesizing from todays ComicBase TV stream, it sounds like the best-of-both-worlds answer is that the Cover Artist should be in the Cover artist field, while the Item Description field should have enough of a description to identify the cover differences, whether that be "Blue Background", "Foil Cover" or "Variant Cover with Cobra Commander in a dress".  No duplication of information, and a description is a faster means to identify different covers than the artist name.  This might take a while...

×
×
  • Create New...