Discussion Forum: Suggestions(Post New Message)
Redisplay Messages: Compact | Brief | All | Full      Show Messages: All | Without Replies

 Author: SylvainLS View Messages Posted By SylvainLS
 Posted: Jan 2, 2020 06:49
 Subject: Re: Policy change - Undetermined versus Unknown a
 Viewed: 44 times
 Topic: Suggestions
View Message
View
Cancel Message
Cancel
Reply to Message
Reply
But but but… The Price Guide!?!!!
 Author: hpoort View Messages Posted By hpoort
 Posted: Jan 2, 2020 03:51
 Subject: Policy change - Undetermined versus Unknown a
 Viewed: 221 times
 Topic: Suggestions
 Status:Open
 Vote:[Yes|No]
View Message
View
Cancel Message
Cancel
Reply to Message
Reply
With the takeover by TLG, it may be time that some fundamental changes to the
site get implemented. Hence the posting of this idea - that has been bothering
me for years.

— requires programming and website extension —

Currently in the Bricklink catalog are parts that signify ‘undetermined variant’,
commonly marked for deletion or already deleted, and corresponding parts that
represent the specific variants of these. The current system requires sellers
to determine the specific variant type – even if they would prefer not to distinguish.
The same system requires buyers to exactly specify which variant they are interested
in buying – even if they don’t actually care which is commonly true. My suggestion
would be to distinguish the two concepts as are the processes: the process of
specifying what is for sale (which may be undetermined) and the process of specifying
what you want to buy (which may be ‘don’t care’). Both processes are already
separate on Bricklink (store inventory and wanted lists), but the concept of
‘undetermined’ is not.

For the catalog policy
• Keep all undetermined variants in the catalog and even add undetermined
variants for those parts that are similar. This information may be extracted
from the relation type ‘part is similar to’.
• Drop the deletion marks for all the undetermined entries and solely use
this marking for wrong or outdated entries.

For sellers
For sellers to don’t want to distinguish between part variants: list these parts
under the undetermined entry only. The BL system should be modified to show these
entries amidst the specific variants for any non specific search as through wanted
lists.

For buyers
For buyers it should be possible to specify an undetermined variety or in
effect a search pattern instead of a single part number. If a buyer does not
care whether a p=4085 is of type a, b, c or d, the buyer should be able to add
p=4085* to his wanted list and the search engine should have no trouble in matching
4085a, 4085b or 4085d with this. Similarly to the 0 color (labeled N/A or Not
Appicable while in this context it actually means Irrelevant).
Buyers should be assisted by the website to specify a specific variant if applicable,
but default to the don’t care form.

For the Bricklink website
• Add a feature to the ‘Add to Wanted List’ and ‘Edit Wanted List’ forms
to allow adding of (a) this specific variant only or (b) include variants. Then
populate the wanted list with the appropriate search pattern instead of the single
part number. This would take the form of either a complete enumeration of all
varieties like ‘4085|4085a|4085b|4085c|4085d’ (plate 1x1 with clip) or the more
general entry of ‘4085*’ or ‘4085@’; I would think the enumeration is more robust,
as it would also allow ‘3794|3794a|3794b|15573’ (jumper 1x2) and would also
allow manual exclusion of one or more variants.
• Adjust the ‘Items for sale’ pages or page fragments that show all matching
parts to include all variants when searching for the don’t care variety.

For the Bricklink database
• Widen the field WantedListItems.ItemNumber to allow for longer patterns.
100 chars would be enough for most enumerations of varieties I can think of.

For the Bricklink search engine
• For matching wanted lists with store items: presume that wanted list entries
may contain a search pattern instead of a single entry. Change the SQL from ‘=’
to ‘LIKE’ wherever necessary or drop the quotes around the field. (But make sure
no malicious code may be entered through this field).

Extra
• A similar feature might be implemented to search for approximate colors
such as ‘any gray’ or ‘any green’, similar to how Studio groups the colors.

Any thoughts of whether this would be helpful for you as a seller or for you
as a buyer?
 Author: Gaston.La.Brick View Messages Posted By Gaston.La.Brick
 Posted: Dec 30, 2019 14:52
 Subject: Re: Don't set "Ready" as default order status.
 Viewed: 56 times
 Topic: Suggestions
View Message
View
Cancel Message
Cancel
Reply to Message
Reply
In Suggestions, C0lsanders_ writes:
  You can manually set it to paid. Bottom of the order page 'Edit page',
then 'Payment status'.

I know: you are referring to "Payment status".
However, sometimes the order status is set to "Paid". And that is not logical,
if you know there is a separate status field for payment status.

  I have to manually set it as not paid sometimes, when an "idiot" buyer set it
as paid, without having actually paid. I may then message them, as they usually
think they have paid (but didn't).

Miles (C0lsanders_)
 Author: Gaston.La.Brick View Messages Posted By Gaston.La.Brick
 Posted: Dec 30, 2019 14:50
 Subject: Re: Don't set "Ready" as default order status.
 Viewed: 26 times
 Topic: Suggestions
View Message
View
Cancel Message
Cancel
Reply to Message
Reply
My reason is two-fold:

1) to keep track of orders that need to be processed
2) I actually had the situation where the (recurring) buyer requested to pickup
and he was under the impression it was picked already. So when the buyer showed
up on a Sunday at 9 AM, it was clear (to me) the status "Ready" gave an incorrect
perception.
 Author: C0lsanders_ View Messages Posted By C0lsanders_
 Posted: Dec 30, 2019 08:45
 Subject: Re: Don't set "Ready" as default order status.
 Viewed: 59 times
 Topic: Suggestions
View Message
View
Cancel Message
Cancel
Reply to Message
Reply
You can manually set it to paid. Bottom of the order page 'Edit page',
then 'Payment status'.
I have to manually set it as not paid sometimes, when an "idiot" buyer set it
as paid, without having actually paid. I may then message them, as they usually
think they have paid (but didn't).

Miles (C0lsanders_)


In Suggestions, Gaston.La.Brick writes:
  After a user places an order, it gets the default status "Ready".*
This confuses buyers: they think the order was processed and is ready for shipping.
I would like to suggest setting the default order status always to "Pending".


*(Unless they pay at once using BL, it is set to "Paid" automatically. I can't
set it to that status manually. This is confusing since there is a payment status
as well. So that's double info and I would remove that possible value for
the status.)

Next Page: 5 More | 10 More | 25 More | 50 More | 100 More