Fred Slota
-
Posts
1,131 -
Joined
-
Last visited
-
Days Won
16
Content Type
Profiles
Forums
Blogs
Downloads
Posts posted by Fred Slota
-
-
(sorry, hit Shift-Enter trying to make a new line, then took to long to edit the original... continues here)
Title: The Dark Crystal
Subtitle: A Discovery Adventure
Creator: Jim Henson
FullTitle: 'Dark Crystal, The: A Discovery Adventure (Jim Henson's...)'
Title: The Bells
Subtitle:
Creator: Edgar Allen Poe
FullTitle: 'Bells, The (Edgar Allen Poe's...)'
Separated out, you can guarantee consistent formatting of the FullTitle. Separated out you can more easily deal with related title groups as a block, which might make for interesting reports broken down by Title versus FullTitle. Separated out, you can more easily group by Creator. Separated out, maybe you could consider Alphabetizing without using unimportant words in Subtitles (like leading 'The').
*ducks behind a crenelation to avoid the inevitable ensuing slings and arrows*
-
Data Structures 101...
If you have a pattern in your data, and especially if you want to enforce consistency in the representation of the pattern, you should organize your data structure to control it and then generate a consistent presentation from that structure.
I recently saw a reporting of non-standard Title naming being requested to be corrected. Things like:
Dark Crystal, The: A Discovery Adventure -> Dark Crystal, The: A Discovery Adventure (Jim Henson’s…)
and
Bells (Edgar Allan Poe’s…), The -> Bells, The (Edgar Allan Poe’s…)
Which leads to my probably unpopular suggestion
Just like Item# (such as a potential Anl 1/A-2) is a presentational compound field built out of the more basic subfields of Type, Number, Variation and Printing, I suggest that Title should be transformed into a presentational compound field built out of the more basic subfields of Title, Subtitle and Creator.
Title: The Dark Crystal
-
I was getting this error consistently a few weeks ago with Check for New Sales and Purchases. Was eventually corrected by emptying the %temp% directory in file explorer. Might give that a try.
-
Let me be clear.
I hate, hate, hate, hate, HATE the mixed use of the Notes field. It requires programming contortions to support it and instead of allowing the maintenance of a clean, unified dataset across users, it produces local databases that either gradually diverge because old info is blocked from get updated with new, or that gradually bloat because old info is retained as new info is concatenated. Or worse still, info is never changed because HC doesn't want to cause the bloat in the first place.
I understand how we got to this point. Evolution over time, expanded user base, entrenched system, maintain the status quo. I can understand the unwillingness to change this, because it would impact so many people and so many entries per person.
But the willingness to continue to live with this, I don't understand.
Doubly so if, by not just adding Grading Notes to the selling presented information (which makes perfect sense, a buyer would obviously want to know the condition of the offered item, if the info is available), you are telling me that Grading Notes "... is the recommended place for that kind of info [user-level descriptive info]."
The first step has been taken. If this is the preferred place, than let's gradually proceed to make it the only place.
Yes, the shift will make people unhappy. I sympathize. Do it gradually. Give warnings ahead of time. Provide voluntary tools that allow migration early. And eventually, bite the bullet and enforce with a mandatory shift that either automates the split or that grandfathers the original Notes field into a wholly local field alongside a new, clean, official Notes field.
-
If I'm understanding what you wrote...
So, that middle field is [(Submitted notes) - (Official Notes)] concatenated with (Grading Notes)? To a non-seller, that was not clear.
In practice, I'm glad that there is a full user or local field being used alongside Notes. Functionally and descriptively, I'm not sure that a field called "Grading Notes" is the best solo field to use. While I'm sure actual grading notes are useful for a prospective purchaser, I'm equally sure that there is additional information a seller wants to convey to a purchaser and that a purchaser wants to see that would not be considered "Grading Notes", and that there are people who take recording their grading information serious enough to not like having to multiplex it with additional selling details.
If Grading Notes is to be the preferred field for AtomicAvenue display, is there a timeline for the removal of Notes from AtomicAvenue and the end to its mixed use in the database?
As an interim step, is there a way to detect and generate a warning message to people posting sales that they are posting with modified notes? And I said warning message - a "The submission will work as previously, but you are using a datafield in a way that will eventually be discontinued in favor of xxxxx". Preferably before submitting, but possibly during or after? Or to send an e-mail when submissions are received? I'd picture this being implemented for a year or so, just as a warning, providing the seller a timeframe to be aware of the upcoming change and make adjustments.
If AtomicAvenue is performing [(Submitted notes)] - (Official Notes)], could a tool be created that could be downloaded and run for the user to strip Notes modifications into a new or custom field, to aid the transition? I'd further imagine that this tool would be an automated part in a Comicbase Version update with underlying database version update, so that when Notes is finally stopped from its double duty, conversion of older databases would automatically separate out modifications from baseline.
-
So start the transition. Add the replacement fields, wait a year or two, and then BURN THE NOTES FIELD WITH FIRE!!! ?
Seriously though. If Grading Notes is an equivalent to what I am suggesting, then good. It is hard to tell (for someone who doesn't sell), as AtomicAvenue is inconsistent in whether it labels columns in grids, so while I can see that there is user information provided in listings, I can't always tell what field that information is coming from. When I look at a grid in AtomicAvenue of issues for sale, I thought that the unlabeled column of data taking up most of the middle of the grid was from Notes. How does one see Grading Notes on an issue posted on AtomicAvenue?
-
Turn it off with a programmable setting, setting initially on for the new user?
-
While it might not always, I'd imagine that the Item Description would go a long way to answering the obvious question to be asked when looking at these reports, namely "Why are these comics on this list?"
-
I can use custom fields to hold information like that, but I can't get ComicBase to use them like that.
I can type supplemental information to the Item Notes, Title Description and Item Description in Custom Fields I call Local Item Notes, Local Title Description and Local Item Description, but I can't get all the reports generated to include those fields merged with the Official fields for compactness and maintaining the current look and feel. I can't submit my Local Item Description to AtomicAvenue and have that information provided to the customer.
And, this idea was not born out of wanting new fields for new information. I make this suggestion more than just a complaint about the current mixed-use Notes field, but as a positive solution to the current negative situation. ComicBase continues to not just support the Notes field as a mixed-use field for legacy purposes, they continue to require it to be used in this way as the only method for AtomicAvenue users to convey how their copy for sale of Shanda the Panda #123/A-2 is different from all the other solicitations. Because the official and the local information is inseparable in the current implementation, they are hesitant to make changes to the official. Because the official and the local information is inseparable, when they make changes those have to be rolled out by concatenating new info onto old. They are maintaining a Database where every record has a field that is an unreconcilable crowd-sourced document co-authored by every user of the software.
This implementation would be a lot simpler for new users to learn, for continuing users to use, and for ComicBase to code for and support.
-
1) Okay then, bold font.
2) I don't know that you can't use different colors in columns as in rows... blue rows for ownership and pink columns for local fields, with purple cells for overlaps.
3) the fonting/coloring could also be applied to the headers
I'm trying to suggest a way to better inform the user at the point of deciding to make edits, not at the point of downloading updates. Warning before the data is overwritten, while friendlier than no warning, is too late. Warning before entering data that could be overwritten is better.
-
Thought for a brief segment on the next ComicBase TV...
Dissection of a UPC code. Current practices, past practices, compare and contrast how different publishers handle them...
-
First, let's get the distractors out of the way...
Most typical cases, it doesn't make any difference where the setting is, at the program level or at the database level.
- The basic user with the default install never touches it.
- The user with multiple databases all pointing to the official store, as long as the setting is consistent/is copied across all databases, doesn't care.
- The common computer with multiple users, again as long as the setting is consistent/is copied across all databases, doesn't care.
For the user who relocates the storage location, it's slightly more convenient immediately after the relocation that the setting is at the program level and not the database level, as if at the database level, that user would have to adjust the stored location in each pre-existing database. But, once that adjustment has been made, new and copies of databases would carry that new location over.
The main usage case is for those people who have multiple different picture stores. For those who do, why do they have them? Those who do have multiple picture stores because they find a reason to have more than one. Meaning, they have times when they will be switching between them. For this purpose, at this time, I want to interact with picture store 1. For this other purpose, at this other time, I want to interact with picture store 2.
Now, maybe these people have specific, discrete, separate databases that they associate with the different picture stores; For example, a personal databaase matched with personal scans vs. an online sales database with sales scans vs. a purchasing database with official scans. These people definitely associate database -> picture store. With sidekick, it doesn't matter how many different databases you maintain - it can automate weekly updates on multiple databases. They load database 2, and switch to picture store 2. They load back to database 1, and switch back to picture store 1. and if they forget, things go wrong.
That leaves the people who maintain a single database and flip back and forth between the separate picture stores as they perform the different tasks that they feel require the different picture stores. They could maintain separate databases, but since they have to switch stores anyways, why bother?
Well, for this I remind you of what currently happens when you change picture storage locations. Picture references are cleared. Whether flipping back and forth on a single database, or pointing custom database to custom picture storage location, picture references are cleared. And, depending on what you're trying to do with the database with the different picture storage location, that probably means that you have to run Rebuild Pictures. Every time.
If the setting was at the database level, after you set a database up with a new location and rebuilt pictures, you wouldn't have to rebuild pictures every time you changed between databases that used different picture stores.
Currently, it doesn't matter whether you use separate databases or a single database; you swap between picture stores, you probably need to rebuild picture references with each swap.
If the setting was moved to the database level scope, users with multiple picture stores would maintain separate databases for separate stores, and would never have to run Rebuild Pictures when swapping between different tasks/databases.
And again, anyone who uses a single picture store would pretty much never notice and never care.
-
How about the ability to use custom Media?
Either provide a fourth hard-coded Custom Media table, or the ability to add multiple Custom Media tables (which, if not provided, a user who really wanted to could simply make multiple databases to have access to multiple Custom Media tables.)
This table would not be involved in user submissions to the Master database. This table would not be modified by Content updates. This table would not be involved in AtomicAvenue. This table could be used for report generation.
Use it to track card collections. Poster collections. Record Collections. Pogs. AtomicAvenue SWAG.
-
Color Code the grids and data entry screens to show which fields can/will be overwritten by data updates.
I would prefer the color coding to be the background of the cells, but could also be bold vs. regular font or colored vs. black font. Either a third style/shade could be used for those that are optional (cover date, Creators, etc), or the current/last used setting could just be reflected on those fields.
For those who say "Eww, I know which fields are which, I don't like this change, it's ugly.", provide a programmable setting that will turn off this feature. But, make this feature default on for new databases, so that new users will see this detail and understand that while all fields can be changed, not all fields will retain these changes.
-
Let's clear up this public/private Item Notes nonsense and extend the capabilities while we're at it.
Official Item Notes, Title Description and Item Description are under the control of Human Computing. A user modifies these with the intention to submit changes. These fields are transmitted up with submit changes. These fields can and will be overwritten by content updates.
Local Item Notes, Title Description and Item Description are under the control of the user. A user modifies these for their own purposes. These fields are not transmitted up with submit changes. These fields will not be overwritten by content updates.
In the grid, these will be separate columns/fields.
In reports, you can choose whether to show Official, Local or both, and if both, they will be concatenated.
Sellers in Atomic Avenue would post with their Local Item Notes/Item Description. AtomicAvenue grids at the title level will show Official Notes and Descriptions in the grid. AtomicAvenue grids at the issue level will show individual sales with their submitted Local Notes and Descriptions.
-
1
-
-
Update this week, Total comics 1,004,310, delta 864, 2M in 22+ years.... What, did Vampirella not come out last week?
-
I think that a part of the Find process is acting on the media you were browsing before changing to the media that you selected in the Find dialog.
In my initial post, look at the first two scenarios BrowseMag/FindMag vs. BrowseComic/FindMag. I had requested to sort on ComicTitles.AlphabetizedTitle. That raised an error and died in the first scenario (Browse selected Mag), while it did not raise an error (Browse selected ComicBook) but did switch media to Magazine and loaded a list of all the issues of the currently focused Magazine.
I'm thinking something like this...
The search is done on the Browse media selection, not the Find Media selection. Scenario 1, throws an error (Comic term on Magazine data), and the process stops right there, leaving you back at the original browsing view. Scenario 2, I think the search actually happens as I thought was going to happen without error (Comic term on Comic Data), but then it wants to display in the Find Media context. The media is switched from Comic to Magazine, and instead of showing the Comic search result that was run, it tries to show a Magazine search result (which wasn't run), and ends up showing as a search result the last set of Magazine entries displayed, which was the last browsed set of issues.
-
Again, you're not addressing what I'm actually reporting...
Browse in the main window for Comic Books. Wandering through "Uncanny X-Men, The". Decide "I want to search for currently entered Comic Books". Open Find. Make sure Find is set to search Comic Books. Load my stored search as described above. Run the search. Search results is a list of currently entered Comic Books, sorted. As Expected.
Dismiss the search results. return to browsing "Uncanny X-Men, The".
In the main window, switch to browsing Magazines. Wandering through "DC Connect". Decide "Hey, let me do that search I just did a moment ago for currently entered Comic Books" Open Find. Find is still set to Comic Books. My search is still loaded. Run the search. Search results is a list of all the issues of the last Comic Book title I had been browsing, "Uncanny X-Men, The" (which, incidentally, does not include an issue that matches my search criteria). Not as expected.
This is the essence of what I'm reporting. Why does the search in the second scenario not give the same results as in the first scenario?
-
Thank you for responding, but I'm not sure that you addressed the point of my question...
My question was not "Why when I open Find does it not open searching in the same Media that I was browsing in the Main Window?"
My question was "Why does a search for Comics work if I was browsing Comics, but if I decide to search for Comics while browsing Magazines does it fail?", or put differently "What is the point of allowing you to change media in the Find dialog if changing the media in the Find dialog doesn't consistently work?"
I'm not pointing out an inconvenience; I'm pointing out that the program presents a feature that doesn't appear to consistently do the thing that it seems it was meant to do.
-
I enter new books through the ComicBase Mobile app and temporarily add the current date in the Notes field. After import, I can search for the date to produce a sorted list so I can verify that all the books were added, the quantities are correct, I can add the cover scans with drag-and-drop without mucking about with the directories, and then I can delete the date in the notes field. My search, which I have been using for many months now, is:
Where: I.[Notes] LIKE "%3/2/22%"
Order by: ComicTitles.AlphabetizedTitle, I.[ItemType], I.[IssueNum], I.[Variation], I.[Printing]
Today, my additions included a magazine, which did not scan, but I added manually, including the date in the Notes. This lead to some confusion on my part, but has also lead to the observation of inconsistent behavior under four different initial conditions.
When I started, the last thing I entered was the magazine, so the main screen was set on the medium of Magazines. When I went to the Find, that too was set on Magazine. Under those conditions, when I perform my Find, an error is thrown over "no such column: ComicTitles.AlphabetizedTitle". After realizing that I was focused on Magazines and that was probably the cause, I changed the main screen medium focus to ComicBooks. When I went to Find, I didn't notice that it was still set to Magazine. When I now performed the Find, there was no error, but the search results switched back to Magazines, returning a list not of Magazines with that Notes field, but a list of all the entries in the Magazine Title that was last viewed.
Changing the Main Screen focus to ComicBooks, launching the Find and setting its focus to ComicBooks, my search returns a sorted list of the ComicBooks (without the one magazine) with the matching Notes field.
And, for completeness sake, if the Main Screen is set to ComicBooks and the Find is set to Magazines, I get a repeat of the second result, switched to Magazines and a list that consists of all the entries in the Magazine Title that was last viewed.
Normally, I would be calling this to your attentions because the program threw an error, but I understand that this is an error of my own making, mucking about with Advanced Find using secret words from magic languages and meddling with forces beyond my understanding.
However, in this case, I think the deeper issue is in the fact that I'm getting three different behaviors, not two... Why don't I get two different behaviors, one when attempting to do the Find on Magazines and one when attempting to do the find on ComicBooks? Why does the system throw an error in only one of the four above scenarios, instead of either doing it for two of the four, or for none of the four? Why do I get a successful list of matching Comic Books only when the Main Screen is focused on ComicBooks and the Find is focused on ComicBooks? Shouldn't the selection in the Find window override the selection in the Main window?
Actually, the question of "Why" is of lesser importance than the question "Is this the way we want this to behave?".
-
How do you force run an update?
-
Is there a way to update the notes field by replace and not by concatenate?
Or alternately, is there a way to create a clean database with current Notes fields and port over quantities from an already-populated database?
-
Update last week, Total Comics 1,000,004
Update this week, Total Comics 1,003,446
3,442 in a week, 178,984 in a year...
A little more than 5-1/2 years to 2M?
-
Is there a way for the screensaver to be aware that Rebuild Pictures is taking place, so that it can avoid attempting to access the database and interfering with the process?
And now, for my next probably unpopular suggestion... Title subfields
in Feature Suggestions
Posted
Add subfields of Series, Volume and Publisher to my above list, as these are also repeated information types that are included in FullTitles.