BrickLink Discussion Forum

In Suggestions, revfds writes:

I really wish I didn't have to click into a specific order to see the tracking
#.

It would make a lot of sense, and be really helpful if there was a column on
the Orders page that listed any available tracking number along with the order.
Bonus points if clicking on the tracking number takes me to viewing the tracking
history (via usps website or google, or wherever).

Hmm you have a point, the tracking number field can be switched on and off for
the seller's Orders Received, but oddly it cannot be switched on for the
buyer's Orders Placed list. No idea why not, it could be added.

Also, incentives should be made to encourage tracking numbers. 1st class postage
with tracking can be had for around $3 in the US for small items, most places
have charged me at least that regardless of whether they include tracking or
not. It should be prioritized, and required for purchases over a certain amount
as it alleviates a lot of headache and prevents a lot of bad interactions.

Definitely no. Now you're just talking about America, over here I strongly
prefer shipping without tracking and I wouldn't let a site force my hand
because it has rules that are based on how things work in America.

Author:

Teup

Posted:

May 28, 2020 12:57

Subject:

Re: Why are these Hinges?

Viewed:

29 times

Topic:

In Catalog, SylvainLS writes:

In Catalog, Teup writes:

[…]
As far as I can see I have understood everything you said but it seems that you
honestly misunderstand what I try to say.

What I understand is that you’re sometimes conceding there are problems and then
you go harping on again about how their identified¹ causes are only theoritical,
logical or conceptual considerations that doubtfully cause real problems.
“Oh yes, those are problems. But causes are not problems. And these causes
are only conceptual. So there’s no real problem.”
Guh.

Inconsistency is a no-no in categorization theory. It doesn’t mean the problems
caused by inconsistencies are theoretical.

¹ Yes, the causes are identified:
If the problem is “I can’t identify this part” (which is only one example of
the problems we have), it’s because “I” (the “I” who has the problem, not necessarily
me) looked in categories (plural, “I” is not obtuse and knows they can be wrong
or confused) “I” thought the part would be. And “I” think a part would be in
maybe this or that category because of the names of this and that category and
because the part “I”’m trying to identify looks like the parts that are in this
and that categoriy, or because the part is used like (*brr, shivers*) the parts
that are in this and that category.
So “I” was misguided and confused by the category names and the parts that are
in the categories, by what “I” thought the parts shared.
Same (or worse) with browsing by category: “I” look for parts like such other
parts in the categories these other parts are in, if the parts “I” should see
aren’t in these categories, it’s because “I” didn’t get what the categories “meant”
(what their names meant, what features the parts that are in them share).
Causes: names don’t mean what “I” think they mean, parts don’t share what “I”
think they share.

And what the current project is doing is only addressing the names of the categories,
and then, only by tweaking their definitions, not by changing their names (or
maybe just a little, eventually, if really necessary) and certainly not by regrouping
parts and identifying why people are looking in the wrong categories.
IOW, they are writing down the exceptions to the definitions so that parts will
only be in one category. But if “I” don’t learn these definitions by heart,
“I”’ll still look for them in the wrong places because the names will be the
same and the parts will be in the same place.

Changes to the categories and parts is always on a case by case basis. Sometimes,
one person proposes to split a category or move a couple parts. And then people
discuss this little bit of the catalogue and, maybe, the consequences on another
little bit.
No global view.
“Rearranging chairs” as mfav once put it (well, more than once actually).

[…]
And it seems the story is inconsistent on categories like hinges and boat will
or will not change - right now it's a bit of eating the cake and having
it too, because on the one hand everything will be logically restrucutured but
on the other hand it will not result in major mismatches in jargon or catalogs
across platforms.

It’s simply because we don’t know: we haven’t listed the attributes, we haven’t
prioritized them, we haven’t defined the categories.

You didn't say it would cost nothing, but still, don't assume you oversee
everything. There are a lot of implications for a lot of people. These need to
be assessed.

But we can’t know. The only question we can ask now is “would you be favourable
to a change in the categories.” But we can’t say how important the change.

100% agree that you guys made a very good analysis of what would be the reasons
behind it if there are problems.
Also agree there are these problems.
Not yet sure about the magnitude of the problems, ranging from on the
one hand 'a few guys and gals a day not getting to the part the first try
but reaching it the second time and then memorising it for the next time with
no further difficulty' (the best scenario) to 'lots of people constantly
confused, giving up on placing orders and throwing heaps of parts in the will-do-later-aka-never
bin' (worst scenario)

And yeah, the implications of the solution also depend on how dramatic the rearranging
will be, again ranging from on the one end '99% the same result as we have
now but with perfect definitions' (62Bricks also mentioned this is still
a possibility) to 'forget everything you thought you knew about lego'

on the other end.

That's the prize dimension and the cost dimension.

If changes like this would ever be in the works for real, I guess I would need
to wait with forming an opinion until more would be clear about where we are
on these two scales. I want things to be within reason and proportion (because
there are consequences beyond just getting used to new things), but I would surely
give it an honest chance.

Author:

Teup

Posted:

May 28, 2020 10:21

Subject:

Re: Why are these Hinges?

Viewed:

35 times

Topic:

In Catalog, SylvainLS writes:

In Catalog, Teup writes:

[…]
OK, you're right, here is a problem. If you have difficulties, then
that is certainly important.

There you go again, mocking the reality of problems with the categories because
I avoided repeating (again) the list of troubles people have by summing them
up as “difficulties.”

As far as I can see I have understood everything you said but it seems that you
honestly misunderstand what I try to say. Maybe that's just my fault because
it seems I can't express things well in English, but anyway, you don't
understand what I mean. Wasn't belittling anything, it was the opposite.
I was in fact pointing out that that is the major deal - the difficulties
are THE important thing in all of this (no idea that word was a euphemism, my
bad). It seems to me that you don't see that pointing out an inconsistency
on an intellectual level and figuring out whether or not it is a problem are
two separate steps, it looks like you see it as one automatic, impartible step.
The first can cause the second, but it is not a given - you start with the problem,
then trace its causes.

I think your talents and attention to detail are invaluable for improvements
once those are planned, but I think you seriously miss the point on some things
in the greater picture, and I don't manage to make you see it. Which is OK,
because if there will be changes, it is going to require a combined community
effort anyway.

And it seems the story is inconsistent on categories like hinges and boat will
or will not change - right now it's a bit of eating the cake and having
it too, because on the one hand everything will be logically restrucutured but
on the other hand it will not result in major mismatches in jargon or catalogs
across platforms.

You didn't say it would cost nothing, but still, don't assume you oversee
everything. There are a lot of implications for a lot of people. These need to
be assessed. For me: Rearranging 1 million parts because of a new catalog, sure,
it's a business risk - give me a week and I will happily do it (this is NOT
a strawman - ALL bins will move). Or writing software so that I can keep selling
on both platforms with the same system, sure I will do it. Each time I add parts,
I am going to have to download my inventory, run it through some software to
generate the categories that match BO, then feed it back into BL in XML mass
inventory update chunks (also NOT a strawman, believe me, I know my systems).
Extra work every time, but I will do this. (I have no idea how others will solve
it. tell me if you do)
But I will do it because it improves the user experience for many people in terms
of measurable UX quality. I am not enthusiastic about complicating the tools
I constantly use every day because some users just feel good about logical systems
for their own sake. We need a survey, then I'm going to be impressed.

Author:

Teup

Posted:

May 28, 2020 04:47

Subject:

Re: Why are these Hinges?

Viewed:

28 times

Topic:

In Catalog, StormChaser writes:

In Catalog, Teup writes:

We need the community.

We do. And one of the problems there is that historically much of the work on
BrickLink's catalog, from major decisions to the most minor contributions,
has been done by an incredibly small number of people compared to the overall
membership of BrickLink.

If you have suggestions regarding how to engage a larger portion of the community
in catalog decision-making, we will gladly listen.

Good question. I feel like a survey could be useful. If the Bricklink main page
would display it in that big banner, I would think a lot of people will participate.
(I think it's more likely to attract people who are dissatisfied with the
category than people who are satisfied, so that would be erring on the safe side
for those who want to go and change things.)

If this would happen, I'd be happy to help putting together the questions
- I'm thinking a handful of statements with a 5 or 7 point "strongly agree
- strongly disagree" scale setup, and an open question to gather some input on
possible consequences that weren't thought of yet.

Author:

Teup

Posted:

May 28, 2020 03:57

Subject:

Re: Why are these Hinges?

Viewed:

37 times

Topic:

In Catalog, SylvainLS writes:

In Catalog, Teup writes:

In Catalog, SylvainLS writes:

In Catalog, Teup writes:

[…]

“Yet”

Not in a temporal meaning

Come on, adverbs can refer to either time or space, you're a language guy,
you must've figured this "yet" referred to something a bit further on in
the context and not to "now" vs "another time"

I still don’t get the original sentence in any other way than temporal. I don’t
see it applying to something placed further (and later) in the message.

Aw man really?

Here we go:

Saying "the problem is that categories are inconsistent" to me isn't good
enough, because it is not in and of itself a problem yet. Having multiple options
for categories
to put a part in, is not a problem yet. Things like people searching endlessly
or giving yup, yeah, those are problems.

You're a smart guy so you must see the point I keep trying to make..... that
things are not problems just because they violate how we imagine things.. if
I put 10 pens in a cup and one is the other way around from the other 9, you
can perceive it as a problem because it violates some conception of how it "should"
be. But is it a problem in the cup or in the mind? Only if we're talking
about sharp knives, is that really a problem. I'm interested in results
of the way the catalog is, not in intrinsic properties.

Something that upsets people is a problem.

(...)

Do I have a problem with the categories as they are?
Yes.
Proof: I say so

Surely we are changing the catalog to improve its practical usefulness, and not
because its intrinsic properties are upsetting?

Streetmakers don't lay
a street a certain way to avoid people with OCD being upset with how the bricks
are distributed, they lay it so it's comfortable to walk on.

Do other people have a problem?
Yes.
Proof: they say so in forum posts, either directly saying so or having difficulties
with the categories.

OK, you're right, here is a problem. If you have difficulties, then
that is certainly important. (I assumed you were one of those veterans who knew
the catalog by heart.)

Do admins see a problem with the categories?
Yes.
Proof: https://www.bricklink.com/message.asp?ID=1117709
and in https://www.bricklink.com/message.asp?ID=1190847
“””
Do the definitions do their job?

Imagine a part you'd like to see placed into another category. Do the definitions
of the existing category for the part and the category where you'd like to
see the part moved fully explain the necessity for the move?
”””

Their solution is to make a very, very long dictionary (that no one will ever
read and even less learn but them¹) with lots of convoluted phrasing and exceptions
because they don’t want to touch the categories themselves, yet (in the temporal
sense

).

(¹ It’s okay, it’s their main goal: guidelines for the catalogue to make it less
person-dependant. But it can’t really serve as a guideline for simple users.)

The approach for now has been cautious: move parts on a case by case basis, try
to empty the (Other) category, create a few new categories.
Patches, patches, patches.
Plaster on a wooden leg.

But I get it, that’s not enough people, you want a “survey.”

If this plaster on the wooden leg is cause for reduced ease of use (which is
plausible, I just want to know how if it is a small or a big problem), then it
is a problem. If it does the job, then all of what you mention above is fine.

[…]

You had and have no problems but you made your own categorization for your shop….

No, I follow Bricklink's. My 2 Boat bins and my 4 Hinge bins are right here
behind me.

“I've already built my own catalog for my own shop which I can apply to my
Bricklink
shop by automatically assigning my categories to the remark fields.”
— https://www.bricklink.com/message.asp?ID=1200018

Exactly. If things change, then I could create a way of keeping it the way it
is for myself, so this is not going to affect me.

[…]
I just need to see that either A. the solution comes
at no cost,

There’s always a cost.
For the ones who’ll do the job.
For the ones who know the old tricks and will need to learn new ones.

You're a really thoughtful and meticulous guy. But this is almost going over
things quick and carelessly. Seems the story is the catalog is all bad, it
needs to be rewritten because well, using logic you can see it without needing
a survey, and it doesn't really cost anything, just gotta relearn it.
Hey, slow down man! It's great you're contributing to improving things,
but please, please, please let's be a little bit more meticulous in each
of these steps. The catalog is not a brain game. We are talking about things
that affect thousands of people, people for who LEGO is a serious passion and
people who depend on this system for their families livelihoods.

The cost part: Yeah relearning, OK. Now let's think a little bit deeper.
Regardless of what some people say bringing up details, the BL and BO catalogs
are incredibly similar (the hinge and plate modified categories are the same,
so is boat). There is also a third platform that too has the same catalog, and
possibly more (I also see the terminology used outside of it). Changing it means
for example these two things:

- We move further away from a universal or at least mutually intelligible language
for Lego parts. With all platforms having fundamentally their very own way of
classifying things, we're going to have islands rather than 1 strong community.
People will be more focussed on 1 particular platform. That essentially reduces
our power. Also, in the flesh world, people use the English Bricklink category
names in Dutch, and I'm sure that happens all around the world. It's
become jargon.

- Category based sellers are going to be in trouble selling on both platforms
because the picking lists will be inconsistently ordered. I can work around it
because I can do programming, but if I couldn't, I am not sure if I would
want to continue selling on both sites. Most sellers want to start on 1 end of
the stock, and end on the other. Running around in random directions with increased
chance of errors is not appealing.

Now, these things aren't holy - they can be given up. But they surely are
costs. These are my 2 examples, maybe there are more. Let's recognise them.
Putting it polemically: If we're achieving huge usability improvements then
let's do it. If we're achieving the peace of mind of a few people who
just like to see things in logical places when they think about it, at the cost
of sellers making mistakes running around with randomly ordered picking lists,
that is just not worth it. The reality seems to be somewhere in between, but
we don't know where.

IMO We need to know what we gain and what we lose before we would ever make fundamental
changes to the catalog. It takes research that we can't do in an armchair
with just a few people. We need the community.

Author:

Teup

Posted:

May 27, 2020 16:42

Subject:

Re: Why are these Hinges?

Viewed:

38 times

Topic:

In Catalog, SylvainLS writes:

In Catalog, Teup writes:

[…]

“Yet”

Not in a temporal meaning

Come on, adverbs can refer to either time or space, you're a language guy,
you must've figured this "yet" referred to something a bit further on in
the context and not to "now" vs "another time"

Those are problems now.

This is not a problem,

Indeed not. It’s an introductory sentence for the following sentences that explain
the problem.

No, really. It is too quick to immediately label things as problems without us
knowing anything about the effects. If a part could be two categories and it's
up to randomness in which category it belongs, then that in and of itself is
not the problem. The potential problem is difficulty shopping, but so far we
don't know anything how big that is. The catalog is for humans, not for robots.
You could look at a human language and spot tons of "problems" in it, yet they
don't prove problematic. Inconsistency in and of itself is not a problem,
we're surrounded by it. If the solution is possible and free, then sure.
If the solution is not free, then we need to be able to weigh the problem's
magnitude vs the sacrifice.

and there too people are asking. It's just within reasonable
limits. Is the BL situation within reasonable limits? We would need to test it.

If first time findability is a huge problem, then yeah, we need to put
all efforts in designing a new catalog and give that 100% importance. If it is
a small problem, then we can afford to balance it with attention to categories
that are nice sets of parts that are relevant to browse.

Then there’s no way to measure the extent of the problem to your satisfaction.

My satisfaction... wish it was everyone's satisfaction. I would expect
anyone interested in this topic would be interested in finding out if, well,
they're problems. Not liking it from a logical perspective isn't a problem..
unless we were gonna print the catalog and hang it on a wall to enjoy it. I think
we really need to research this. Bricklink could easily create a survey about
this and then we would know a lot more. I don't really care about how many
things we could think of that "don't make sense if you think about it". I
just care about the shopping experience.

I know, just saying it worked very conveniently for me. Sure, you're right,
a lot of those parts can very well be in other categories. But I had no problems.

You had and have no problems but you made your own categorization for your shop….

No, I follow Bricklink's. My 2 Boat bins and my 4 Hinge bins are right here
behind me.

As long as whoever fleshes out the improvements says that they keep a balance
of those two perspectives in mind, then I really am fine with any outcome. […]

Then you’re fine because we’ve said it from the beginning.

I never heard anyone about creating meaningful categories because there are no
examples. So I have no idea if that example would be a strawman. But sure, in
that case we're cool. I just need to see that either A. the solution comes
at no cost, or B. that its cost weighs up against the magnitude of the problem
- for which we need a survey.

I really hope Bricklink can make this happen. Not because I want to prove any
particular point, I am just genuinely interested in the catalog user experience.
If that would turn up a great degree of dissatisfaction then drastic changes
will probably receive wide support, also from me.

Author:

Teup

Posted:

May 27, 2020 11:34

Subject:

Re: Why are these Hinges?

Viewed:

39 times

Topic:

In Catalog, SylvainLS writes:

In Catalog, Teup writes:

[…]
I won't deny there are these problems, but I would really like to have some
kind of data, say a survey, so that we have something to talk about. Saying "the
problem is that categories are inconsistent" to me isn't good enough, because
it is not in and of itself a problem yet. Having multiple options for categories
to put a part in, is not a problem yet.

“Yet”

Not in a temporal meaning

Those are problems now.

This is not a problem,

People can’t find parts without looking everywhere now.

this is. And I would like to know more about the size and the nature of this
problem. We're now concluding things are problems because it sounds unsatisfactory,
and that's not enough (it always will be).

Parts are put into categories (and sometimes moved from one category to another)
arbitrarily (on whims) now.

This is not the problem. The problem is the implicitly assumed result: Difficulty
finding things. And that I just want to know more about the problem, not by reasoning
about what logically are problems, but by measuring the actual
problem.

The supermarket example is not just an analogy, it's an example of another
business where categorising is an issue. Is it an issue? Yes, because there too
people are searching, and there too people are asking. It's just within reasonable
limits. Is the BL situation within reasonable limits? We would need to test it.

If first time findability is a huge problem, then yeah, we need to put
all efforts in designing a new catalog and give that 100% importance. If it is
a small problem, then we can afford to balance it with attention to categories
that are nice sets of parts that are relevant to browse.

[…]
I'm responding based on my buying experience, which was the very first years
of me being a (casual) member (pretty soon I realised it was a too expensive
hobby for me

But LEGO is all about using parts for anything and everything.

“Boat stuff”? Parts for a boat? What’s that? All the parts you can use to
build a boat (bricks, plates, etc.)? They are all in different categories now.
The giant boat hulls? The sails? The oars? The windscreens? The porthole
windows? The hatches? The rigging? They are all in different categories now.

You’ve never been able to find or browse for all the “boat stuff” in one category.

I know, just saying it worked very conveniently for me. Sure, you're right,
a lot of those parts can very well be in other categories. But I had no problems.
If others do, then sure. It's just that in my work I have encountered so
many people saying "well I don't have a problem, but probably other people
do" and then it turned out those people never existed. That is why I am this
kind of skeptical and want to hear it from the people who have the problem. The
signals I'm picking up are limited, but they're more "just take a moment
to learn it" than "omg the BL catalog is so difficult".
And this discussion all started pretty much with everyone in agreement that those
items are not hinges because they have clips. I don't think all is terrible.

I just want
a buyer-friendly catalog that takes into account but not overfocusses on first-time
identification of a part, but also on producing relevant categories that are
pleasant and supporting to browse around. If a more principal system could still
do that, then that's alright.

At least, it shouldn’t prevent that anymore than the current unprincipled system
does

It would if it would be something too technical like based on dimensions
only. It is not a guaranteed improvement - there is also a lot to lose here,
and we forget that if we bash everything about the catalog. We just need to be
careful.

Well, let's wrap it up. There are lots of things that could be both better
or worse about the catalog. The reason I'm posting is that all the time I
see it is being talked about from the perspective of the part - where
it is and if it is easy to find. But I never hear about the perspective of the
category - what assortment of parts it contains and if that is a meaningful
set of parts to browse and if it is nicely sized (this is definitely not perfect
now, but it could be worse). The tag system is a good example too: While it is
a good idea, it's exemplary of the 100% focus on that individual part and
how that can be found, but it says nothing about what browsing a store will look
like (you will see the same things many times if they don't have 1 category
location) or what storage is going to look like (both sellers and buyers may
adopt the categories).

As long as whoever fleshes out the improvements says that they keep a balance
of those two perspectives in mind, then I really am fine with any outcome. I
just don't want super-easy-to-identify categories if they are going to be
"everything with 3 studs, everything with 2 clips, .." etc. In that case I prefer
a common-sense hinge category with 3 parts you expected elsewhere that you just
need to memorise. But if it will be better, then go ahead. Maybe we end up in
total agreement once an example is put forth, or when we have data on the problem,
so I'd say let's continue this when it's less hypothetical

Author:

Teup

Posted:

May 27, 2020 09:29

Subject:

Re: Why are these Hinges?

Viewed:

49 times

Topic:

In Catalog, SylvainLS writes:

In Catalog, Teup writes:

[…]

What other aspects? You still haven’t given examples.

As you define “meaningful,” shape is meaningful and function isn’t, or is less
meaningful.
Function is like alphabetical order: you need prior knowledge, arbitrary prior
knowledge, prior knowledge that you can’t guess by looking at a part.

Navigability: You can know where a part is, but if it would take many clicks
or staring at the screen, it is still inconvenient to use. For example if the
system would have many subcategories, which we don't at this point, or if
the category would be so large that it has many pages, which we do have.
[…]
So what I'm saying is that these are separate interests, that can sometimes
can conflict. […]

That’s what the prioritization of the attributes does.
You first find the attributes, then you prioritize them to have categories of
reasonable sizes while keeping simpler, more basic, attributes first (because
they simpler, more direct, to see in a part), and avoid conflicts.

It’s still arbitrary but systematic, needing less arbritrary / specialized prior
knowledge.

The problem with the catalogue now is that it’s inconsistent: there’s no system,
or rather, there are several conflicting systems. Some categories are shape-oriented,
others are function-oriented. Some categories are almost empty, others are full
to the gills.
When a new part arrives or when you’re searching for a part, there often are
several categories in which it can fall, because they are orthogonal categories
(one is shape, one is function) or because there’s no priority (the part mixes
two shapes with the same priority (is 43093 a pin with an axle or an axle with
a pin?)).

What the current project is trying to do is to first refine the categories’ definitions,
but not the categories themselves, hoping it will allow to define clear boundaries.
It might solve the Plate vs. Tile problem but it won’t solve the problem that
a hinged-plate is both a plate and a hinge, it will just put a lot of exceptions
in the definitions and the need of prior knowledge to prevent putting it and
looking for it in the Plate, Modified category.

We already know most of the attributes because they are already used in the category
names: brick, plate, round, hose, decorated, etc. There even is a prioritization
(brick ≫ round ≫ decorated).
What should be done is determine which attributes conflict and need prioritization
or deletion. That means the attributes need to be defined (what’s “hinge”?
it’s a function, it’s orthogonal with primary shape-attributes like brick and
plate, how do we prioritize them?) not the categories (what parts are in “Hinge”?
oh, they could also be elsewhere, let’s massage all the definitions to keep
(most of) them there).

By the way, I also think we mustn't forget which problem we are trying to
solve. Is it about solving practical problems with its use, or is it about solving
our feeling of dissatisfaction on some intellectual level? I feel a bit of both
are involved.

True.

So how big are the practical problems with the catalog really?
I'm honestly curious. I wonder what info we have that suggests dramatic overhauls
are needed. You'd have to watch people use Bricklink in order to find out
I guess. But if I had to go by the number of ID topics, the people who ask are
vastly outnumbered by the people who answer.

Not true. It’s always the same people who answer.
(Old timers who know the parts, and how they are arranged in the catalogue, or
have developped tricks to circumvent its inconsistencies, or have simply memorized
those inconsistencies.)

But of course, that doesn't count the times someone had to search for too long.

Or abandoned and didn’t come to the forum to ask, putting the part in their “what’s
that?” bin for later (a.k.a. never).

I won't deny there are these problems, but I would really like to have some
kind of data, say a survey, so that we have something to talk about. Saying "the
problem is that categories are inconsistent" to me isn't good enough, because
it is not in and of itself a problem yet. Having multiple options for categories
to put a part in, is not a problem yet. Things like people searching endlessly
or giving yup, yeah, those are problems.

Supermarkets btw have the same inconsistency, the categories are also a hybrid
there. It's not the end of the world (but sure, also not an argument to defend
inconsistencies)

I'm responding based on my buying experience, which was the very first years
of me being a (casual) member (pretty soon I realised it was a too expensive
hobby for me

). I would look around thinking "so what kind of boat stuff does
this shop have?" and it would not have been convenient for me if that whole category
was broken down into a too technical approach to part attributes - but yeah,
that is going to depend on what precisely the proposed catalog would look like.

As for my selling experience, I don't care either way anymore, because I've
already built my own catalog for my own shop which I can apply to my Bricklink
shop by automatically assigning my categories to the remark fields. I just want
a buyer-friendly catalog that takes into account but not overfocusses on first-time
identification of a part, but also on producing relevant categories that are
pleasant and supporting to browse around. If a more principal system could still
do that, then that's alright.

Author:

Teup

Posted:

May 27, 2020 09:01

Subject:

Re: Why are these Hinges?

Viewed:

40 times

Topic:

In Catalog, 62Bricks writes:

In Catalog, Teup writes:

That is an extreme example, but it is a good point. So the conclusion might be
that "First letter of the common English name" is not a suitable attribute for
grouping items. It tells you nothing about the item itself and so leads to categories
that are not meaningful.

And while size is a physical attribute of the item itself, it is not meaningful,
because people do not generally select food by size. It is in the selecting of
the attributes that the final groups are shaped.

What a supermarket actually does is a good real-life example of what a part catalog
could do. It uses meaningful attributes and the end result is meaningful organization.

Usually, the most general attribute is whether the item is fresh or packaged.
Produce, meat, flowers, fresh-baked goods all have their own sections separate
from the packaged goods.

The next level of attribute you find applied in, say, the produce section is
"Fruit or vegetable?" Fruits are grouped with fruits, vegetables with vegetables.
That is based on some foreknowledge on the part of the shopper of the difference
between the two, but it is common knowledge, not specialized knowledge.

Finally, an attribute based on how the item grows is used - roots, bulbs, vines,
leafy plants, trees, etc.

And so running everything through those levels you find the apples, pears and
oranges near each other. You find the turnips and potatoes together. Onions,
garlic and shallots are usually close by. Tomatoes and peppers are together.
You'll find the cauliflower by the broccoli, celery and greens, usually.
By choosing meaningful attributes you get useful and meaningful categories.

But now imagine the supermarket added a category called "Ingredients for pizza."
Now the top-level attribute is no longer a general one like whether it is fresh
or packaged, it is based on a specific usage: whether it can be used to make
pizza. Now the tomato sauce, cheese, flour, yeast and salt are pulled out of
their respective aisles, where they were previously grouped with like items based
on the general-to-specific model, and put together in a separate part of the
store.

Is that a meaningful category? It is for someone who wants to make pizza. Is
it meaningful for someone who wants to make pasta sauce?

That person might reasonably go the aisle that has all the canned tomato products
expecting to find tomato sauce. But it won't be there. To track it down he
has to know two things - this supermarket has a "pizza ingredient" section, and
tomato sauce is a pizza ingredient. That it is also an ingredient in countless
other dishes makes no difference, this supermarket has determined that "pizza"
is its primary purpose and so has stuck it away in a different spot.

He might ask the manager, "Why is your supermarket organized in such a strange
way?"

"Good point," the manager might reply. "Here let's fix that - we've re-written
our definition of 'canned tomato goods' so now it reads 'canned tomato
goods that are not also pizza ingredients.' We'll be posting this on
the bulletin board at the back of the store by the restrooms so everyone will
know where to find the tomato sauce."

True, even though actually they have such things - there is/was an isle for wrap
ingredients here. There's an isle for Mexican dishes, for Asian dishes..
and you're right that's where it gets tricky. Because jalapenos are in
the Mexican section and not in the pepper section with the chilis. Greek peppers
may be somewhere else. Conserved fruit cans are in the section with the conserved
vegetables, but conserved fruit cans that are intended for pies are in the baking
section. So yeah, this is definitely where it gets tricky.

Supermarkets are highly professional and adapted businesses where everything
down to what exact songs are being played is laid out to get the most out of
everything. If even they struggle with these issues, I think we are doing really
well here. Not as an excuse not to do anything, but having some dilemmas doesn't
mean we failed.

I do think some degree of less technical and more thematic categories are good,
even if it causes a bit of gray area. A supermarket couldn't do without a
baking section, or a section for different kinds of lunch snacks, a section for
stuff to put on a sandwich, etc. You're definitely right it shouldn't
go overboard. But I do think it's great we have a "windscreen" and a "panel"
section even if there are some panels that work as windscreens and some opaque
windscreens. The general concepts of windscreens and panels are meaningful when
you're building and shouldn't be tossed away because we can't reach
a 100% logical consistency there.

All in all, I think the important thing is that when a customer goes to some
aisle/category with a certain thought, they should be surrounded by items in
that area that are relevant and that allow them to choose or pick a few more
things. If you're thinking about putting egg salad on a sandwich and you
see there's also hummus and slices of this and that, that is really helpful
and you might also buy more. Whatever catalog system still provides categories
that are helpful for the buyer and give them some overview to brainstorm, is
fine with me.

Author:

Teup

Posted:

May 27, 2020 04:40

Subject:

Re: Why are these Hinges?

Viewed:

52 times

Topic:

In Catalog, 62Bricks writes:

In Catalog, Teup writes:

In Catalog, 62Bricks writes:

In Catalog, StormChaser writes:

In Catalog, Teup writes:

Well, maybe if you would put together a catalog according to your philosophy
and show it and then it'd convince me that it makes sense, then I will agree
with you.

I would also like to see a reasonably comprehensive organizing of the catalog
using 62Bricks' vision. I'm confident he has good ideas, but I would
like to see an actual category tree with a decent selection of parts assigned
to categories (along with an explanation of how categorizing decisions are made).

You can already see what it looks like, because the catalog already follows it
up to a point. It is where the catalog departs from it that we run into issues.

Categories like Tile, Round, Decorated are based on three independently observable
attributes of a part, placed in a ranked hierarchy from general to specific.

1. Primary shape/type (tile)
2. Secondary shape/attribute (round)
3. Decoration (yes)

using the title and info from inventories, it is possible to add more specific
information like mold variants, descriptions of the decoration, and the color.
General to specific.

None of these key attributes describe the part's usage. Each of them describes
something that can be observed by any user with no special knowledge of the part's
usage. That is how categories should be determined. If part usage is considered
important, it can be added in the title, at the "specific" end of the hierarchy.
Putting usage at the "general" end of the hierarchy means we lose all that general
information that is most useful in finding the part.

Look at the parts. Think about the attributes of the parts themselves that best
distinguish them and that can be determined by someone with no special knowledge,
then rank them in order from the most general to the most specific.

Then run each part down that list of attributes and classify it accordingly.
You don't have to imagine how it would work. It is already working in many
categories. We just need to take those categories that short-circuit this process
by putting the specific information at the wrong end - like "Hinge" - and put
their component parts back through the list of attributes above to see where
they end up. Then, if it appears that there is another level of attributes that
should be added based on the parts, a new category may form based on that.

It works.

I'm sorry but it still just looks like a personal preference to me... not
a bad one, but I don't yet see how this elimiates all problems.

The catalog is always a compromise. Findability of parts, usefulness of the categories,
a balanced size of the subcategories, other aspects probably...

It seems from your preference that you've assigned findability utter and
utmost importance and all choices are made based on that aspect. OK, but personally
I think findability is less important than meaningful categories that you can
browse to look for related parts or alternatives. For example, when I was building
and I was looking for some hinges to make a sloping roof, I could look at the
part I had in mind but also browse around other types of hinges that might work.

I think findability is something that is useful but only as long as you don't
yet know the catalog. After that - which is going to be the longest time - other
aspects become more important. Or at least, in my opinion.

I am willing to believe that your catalog would be the champion in findability.
I just don't agree it's the most important thing. I think this will always
be a personal preferences thing..

It might well be that after setting a hierarchy of attributes, all the hinges
end up in the same category again - but that would be the result of making choices
about what the attributes should be and where to rank them when sorting parts.
It's not an either-or proposition.

I well understand the resistance to thinking about the catalog in a systematic
way. People who have spent years using it do not want anything moved. But there
appears to be general agreement that it is a bad thing that so many similar parts
are scattered around the catalog, and so many apparently dissimilar parts are
grouped together.

My point is not one about personal preference, it is simply to point out that
the cause of that issue is not that the categories are not defined clearly enough,
it is that many of the existing categories were not built from the ground up
based on attributes of the parts. They were imposed from the top down, and redefining
them simply re-imposes them from the top down with a new set of criteria. It
does not fix the root cause.

In fact, creating a system like this would eliminate the "personal preference"
that is built into the current system, and which is a major source of this problem:

The most common usage for this part

60583b Brick, Modified 1 x 1 x 3 with 2 Clips (Vertical Grip) - Hollow Stud
Parts: Brick, Modified

is to hold parts that swing back and forth like gates, doors, and shutters. In
other words, as part of a hinge. But you did not see it when you were browsing
the hinge category looking for solutions to your roof build, because it is not
in the hinge category. It's a Brick, Modified.

Why is it there? Because someone made a judgement call about where it should
go. I don't know what criteria they used, but the catalog is full of examples
like this where parts can fit into more than one category and there seems to
be no evident reason for choosing one over the other aside from personal preference
of the submitter, the admins, or both.

An attribute-based system would not necessarily eliminate the issue that a part
might fit in more than one category, but it would rank the attributes so it was
clear and consistent which ones have priority when assigning it to a category.
This is just as it is done currently when we make "brick" more important than
"round" and "decorated," and we make "decorated" less important than "round."
It's not a revolutionary idea. It is already in place. It just needs to be
expanded.

I think the current project to redefine the categories is an acknowledgment that
leaving these kinds of decisions up to personal preference is undesirable. But
the approach to resolving it is from the wrong direction.

Well, true, the catalog mostly just grew this way, which means that it is likely
that there are things to gain by thinking about it more systematically.

I guess I just need to see an example of part of that catalog to really be able
to say something about it. Because right now I'm just imagining it would
be some kind of system where you have a perfect taxonomy to determinate a part
you have in hand, but the categories would not be semantically coherent. Probably
I am imagining something too radical than how you intended it.

Like you could classify animals based on their taxonomy and put them in mammals,
birds, fish, amphibiae etc. Then you can systematically identify them beyond
a doubt, but those groups are not necessarily relevant if you look on a semantic
level of what "type" of animals they are. I can even connect the metaphor literally
to Bricklink: "Animal, Air/Land/Water" are imperfect categories (I believe frogs
are in "land"?). Rearranging them according to "Animal,Vertebrate", "Animal,Anthropod"
etc., would logically solve the problem perfectly and give us 100% consistency
and logic. But those categories would feel less relevant and meaningful when
you're shopping and browsing.

Now I'm just warning in general that a too technical systematic could defeat
the purpose. I cannot say to what extend that applies to what you propose. Just
saying we have to keep in mind the problem we really are trying to solve with
it, which is practical problems in its use - even if that would mean having imperfect
intellectually unsatisfactory categories that leave a bit of gray area.

Author:

Teup

Posted:

May 27, 2020 04:23

Subject:

Re: Why are these Hinges?

Viewed:

41 times

Topic:

In Catalog, SylvainLS writes:

In Catalog, Teup writes:

The catalog is always a compromise. Findability of parts, usefulness of the categories,
a balanced size of the subcategories, other aspects probably...

Define “usefulness of the categories.”

I note that you have dfficulties finding the “other aspects” a categorisation
would have that could serve better (or at all).

(...)

What other aspects? You still haven’t given examples.

Well here's what comes to my mind right now.

Meaningful categories: You could sort a supermarket based on size of the products
of based on alphabet, and it would be extremely easy to find a cauliflower. But
the aisles would not have meaningful categories. The result is that it is easy
to find a single product while at the same time browsing the store is very inconvenient.

Navigability: You can know where a part is, but if it would take many clicks
or staring at the screen, it is still inconvenient to use. For example if the
system would have many subcategories, which we don't at this point, or if
the category would be so large that it has many pages, which we do have.

I don't want to pretend I know what "the" functions of the catalog are, probably
other users have other concerns too, that's why I was vague.

Sorry to say, but that “meaningfulness” of categories you describe is actually
also findability.

You want a “Hinges” category so you can find hinges more easily.
You can do that by looking for the term “hinge” in descriptions.

(...)

Furthermore, you’re saying once one knows the catalogue, they don’t need to find
parts anymore.

Well, first, you still need to find parts, it’s just that you know where many
of them are or should/would be.

I understand you can also use "findability" as an umbrella term for all three
aspects that I mention here, but I do think there they can be separated. The
latter is what I call navigability. You are right that they often are in line
with each other, but they can also conflict. Something can be easy to find for
a new user but take time to reach, or something can be reached instantly but
hard to find if you don't yet know where to look. Something can be in a meaningful
category, but based on the one single part you have in your hand, with no prior
knowledge, you could not know what group it's been put into. For example
a product in the supermarket may be hard to find in and of itself, but once you
see it's in the baking aisle you can see how it's useful to have there
for people that are baking things.

So what I'm saying is that these are separate interests, that can sometimes
can conflict. It's about weighing their importance, which by definition means
a catalog is a compromise and does not have a single correct answer that we should
look for. If the catalog had 1 single function and everything could be rearranged
in one mathematically correct solution to cater to that function, I'd say
go for it. But since it is a compromise, it will be replacing one compromise
with another.

That's not to say though that we shouldn't move parts. We definitely
should. It's just that I don't feel that reimagining the catalog would
ever bring us further than where we are now. But maybe I'm imagining 62Bricks
proposed changes as something more dramatic than they really are intended. Right
now I'm just thinking about a system that would have perfect findability
(e.g. categorising all part according to their footprint dimensions or whatever)
but semantically incoherent categories. But I guess it wasn't meant like
that.

By the way, I also think we mustn't forget which problem we are trying to
solve. Is it about solving practical problems with its use, or is it about solving
our feeling of dissatisfaction on some intellectual level? I feel a bit of both
are involved. So how big are the practical problems with the catalog really?
I'm honestly curious. I wonder what info we have that suggests dramatic overhauls
are needed. You'd have to watch people use Bricklink in order to find out
I guess. But if I had to go by the number of ID topics, the people who ask are
vastly outnumbered by the people who answer. But of course, that doesn't
count the times someone had to search for too long.

Author:

Teup

Posted:

May 26, 2020 17:47

Subject:

Re: Why are these Hinges?

Viewed:

38 times

Topic:

In Catalog, 62Bricks writes:

In Catalog, StormChaser writes:

In Catalog, Teup writes:

Well, maybe if you would put together a catalog according to your philosophy
and show it and then it'd convince me that it makes sense, then I will agree
with you.

Author:

Teup

Posted:

May 26, 2020 13:17

Subject:

Re: Disable Buyer's Ability to mark order Paid

Viewed:

36 times

Topic:

In Suggestions, BasKrie writes:

In Suggestions, Teup writes:

In Suggestions, BasKrie writes:

In Suggestions, Teup writes:

In Suggestions, SezaR writes:

In Suggestions, Teup writes:

In Suggestions, SezaR writes:

In Suggestions, sparesleftovers writes:

In Suggestions, SezaR writes:

- Buyer placed an order and made a payment without getting an invoice

Hmmmm, so the buyer paid (via PayPal offsite) without getting an invoice? How?
How was he even able to pay you?

He used the email address of my store, which is the wrong address anyway.

Yes great! That is what I did too, because one buyer paid a wrong amount (ex.
$50 Canadian dollars instead of $50 American dollars) another buyer decided to
pay via friends and family,...
I changed the email of my PayPal and now buyers cannot mess up with payment.

They can't? When they send it, isn't it up to you to figure out how to
collect it?

No it is not! If they send it to a wrong email address, I would not even get
any notification that they paid. So I send them a remiander to pay and if buyer
says he paid, I would request more information....and then explain that they
were supposed to pay via PayPal onsite as instructed and this is the only payment
method I accept. I believe mostly would understand their mistake but if they
insist, NPB is upon them

Well seems the system works differently here... it's kind of up to the seller
to figure out how to claim it. If the alias system would work properly that would
be no problem, but right now I don't know how to fix this.

Why is it up to the seller to figure it out?
Buyer sends to an incorrect address, nothing the seller can do about that. The
buyer should contact PayPal about it.
When payment is done to an address that PayPal doesn't know, a mail is send
to that address from PayPal and the receiver can open up an account with PayPal
and claim the money. When the address doesn't exist the mail with bounce,
but PayPal doesn't do anything with that. Only after the money hasn't
been claimed for a period of time (that can be the 2 months mentioned below)
it will be returned to the sender of the money.

Well, that's pretty much what I mean. It does not bounce if the address exists.
So the seller will either need to figure out a way to claim it, ask the buyer
to cancel it, or wait 2 months and then instruct the buyer to send it again.
There are no other options for the seller, the only way to turn down the payment
is by not claiming it, which takes 2 months. I guess you're right you could
consider it the buyer's problem, but I just don't like it....... It is
a clumsy situation because I want to provide service and don't like taking
my customers' time with requests. Especially if that involves them having
to contact PayPal customer support which is a pretty tedious process because
they've hidden themselves pretty well. I rather do such things myself.

And why wait for it to bounce? Buyer could
have send the money to the correct address right away. It's the buyers choice
to wait, no obligtion.

Well, I don't know what it looks like from their side. I've had a buyer
refuse to do that in the past because they didn't know how to cancel it and
I could not help either. They did not want to send it a second time before the
first one returned to them (which makes sense), so the only option left was to
wait.

Right now I just hope that I can add the alias email address to my account once
their "problems" are over. As long as PayPal doesn't provide any kind of
"refuse" button, that seems to be the only viable option for avoiding these situations.

If they have sent it to a mail address you also use, then I can imagine they
won't send it a second time. But still, it's their problem, not yours,
from PayPal's point of view, you are not even part of the transaction, so
you can't do anything to get it corected.
Same if the buyer paid to the wrong IBAN account, only the buyer and IBAN account
holder can do anything.
I agree that you want to provide service, but you can only do that for the things
that you have some control over. And buyers sending money to incorrect places
isn't that

Well, I got some instructions from support and now it's fixed, I managed
to add the email address as an alias

The reason it didn't work is that
apparently I have sent that address (myself) a payment request (probably someone
asked me to use that feature and I wanted to test it). I had go over my activity
history and cancel the request before I could add it. Seems it's a rare enough
situation for PayPal to not have a scenario or an error message for this

Author:

Teup

Posted:

May 26, 2020 09:15

Subject:

Re: Why are these Hinges?

Viewed:

43 times

Topic:

In Catalog, 62Bricks writes:

In Catalog, wildchicken13 writes:

In Catalog, Teup writes:

In Catalog, StormChaser writes:

In Catalog, wildchicken13 writes:

Under the new definitions,

60478 Plate, Modified 1 x 2 with Bar Handle on End
Parts: Plate, Modified

could fall under either plate modified or hinge. Should we make an exception
for handles? Or should we handle these cases by defaulting to the existing categorization?

It's your catalog. What would you like to see and how would you revise the
category descriptions to make it happen?

I agree with the OP these examples are not hinges as they work with the clips
system. Clips and hinges have always been a clear mutual exclusion. I'd keep
the Hinge category for the parts with the hinge systems that we all know and
understand as hinges: The 2/3 finger systems, the swivels, the 1x2 hinge bricks,
pretty much the way it is now, with the examples from this topic removed because
they work with clips and bars.

I think removing the category is thowing away the baby with the bathwater. Sure
you can think up some reasons why some hinge would be hard to find or why something
wouldbe inconsistent if you think about it, but if the conclusion is category
elimination, we will eventually end up with 1 category called "parts"

That is actually not a bad idea. It is generally easier to identify an unfamiliar
part by searching for its function and/or physical characteristics than it is
to find it in the catalog, unless you are good at guessing. So as long as part
names are descriptive enough and the catalog is searchable, the only function
of categories is to start arguments over what is a plate modified and what is
a hinge.

No, you would not end up with one single category called parts. You would end
up with categories that describe the parts themselves so that someone not already
familiar with the part's complete usage or who is not current on 20 years
of forum debate can use the categories.

What is happening here is exactly backwards.

The problem is the categories, not the definitions of the categories.

What is happening here is people are imagining what they want the categories
to include, then arguing backward from that to come up with a definition that
will get them as close to that as possible.

That is backwards.

The way forward is to look at the attributes of the parts themselves and decide
how they can be meaningfully grouped. Any attributes that are subjective or
ambiguous - like how a part may sometimes be used - are not suitable for
basing categories on.

The parts should not be defined by the categories. The categories should be defined
by the parts.

This is possible even given the current limitations imposed by Bricklink's
"flat" category structure. But it requires turning the thinking around to be
done effectively.

Well, maybe if you would put together a catalog according to your philosophy
and show it and then it'd convince me that it makes sense, then I will agree
with you.

Until that time, I really feel like the way you prefer it is still.. a preference.
Changing one imperfect system for another will leave us worse off than we were,
because we lost the history. It's kind of like designing a new language from
scratch because English is illogical. Don't forget that people worldwide
are not talking about "Plate modified", "Hinge".. (yes, the English words. Dutch
AFOLs have al learned to adopt the Bricklink terminology) To completely eradicate
the way we have talked about parts for 20 years and replace it with something
else, would really take a perfect system to make that worth it.

But sure, if your system is perfect, then we should do it. I just need to see
it before I will believe it

For me the current system makes a lot of sense,
and at first glance a system that would ignore the common sense use of parts
does not sound appealing to me at all. But maybe I will just need to see it to
understand.

Author:

Teup

Posted:

May 26, 2020 07:02

Subject:

Re: Don't show impossible discounts

Viewed:

48 times

Topic:

In Suggestions, yorbrick writes:

Why does bricklink show this? A simple IF statement could be used to only show
a discount when it is possible for a buyer to achieve. Then it doesn't make
the store look stupid by offering discounts that a buyer cannot possibly take
advantage of.

I notice almost every day that the perfect way to ensure Dutch people will never
buy croissants or buns, is by putting a sign "4 for €1" when there's 3 left.
Pretty sure that if they'd remove the sign, people would be willing to pay
€1 each

Author:

Teup

Posted:

May 26, 2020 06:08

Subject:

Re: Comments during instant Checkout

Viewed:

32 times

Topic:

In Suggestions, paulvdb writes:

In Suggestions, Teup writes:

Ah I forgot, in the case of onsite payment, instant checkout does not trigger
an invoice, right? This is always a bit confusing because the invoice does show
up as checked, indicating that an invoice was sent.

Anyway the purchase confirmation is not an invoice as it's neither a payment
instruction (pro forma invoice) nor a valid receipt. You always need to get an
order confirmation first (in the EU it gives you rights to the items, provided
that the seller can deliver). Also, changing it to "invoice" would cause the
buyer to receive two "invoices" if they are not paying onsite.

That is not correct. There are three message templates related to orders being
placed. Purchase confirmation is used when the buyer pays at instant checkout.
Order Notification and Order invoice are sent if the buyer does not pay at checkout.
For example if they choose a shipping method and/or payment method that can't
pay at checkout.

Further information on this: the order invoice is sent immediately when the order
is placed if the shipping method qualifies for instant checkout but the buyer
selects a payment method that does not qualify for instant checkout.

The seller has to manually send the invoice if the buyer selects a shipping method
that does not qualify for instant checkout.

Ooooh I see. I had no idea there were three. I think now I get it, and I see
why someone could want to make the purchase notification an invoice.

OK, so, the OP probably has in their Order Notification message the BUYERSCOMMENTS
macro tag. Now, it has to also be in the Purchase Confirmation message. The help
section shows that this macro tag is available to both:

https://www.bricklink.com/help.asp?helpID=661

So, go to: My Store - Settings - Message Templates. Then, click "edit" on the
Order Notification message (sent for non-instant checkout purchases), look what
you have in there that you would like to have in the other one, copy it, then
click "edit" on the Purchase Confirmation and paste in there whatever was missing.
This should fix it.

By the way, I see that Bricklink's descriptions are a bit off and need improvement

"Purchase Confirmation: Sent to a buyer who made a purchase with Instant Checkout"

Not true, only when it is paid onsite. Otherwise it is not sent.

"Order Invoice: Sent to a buyer who you issued an invoice to"

...or sent instantly by Instant Checkout, unless the order is paid onsite.

Author:

Teup

Posted:

May 26, 2020 05:29

Subject:

Re: Disable Buyer's Ability to mark order Paid

Viewed:

26 times

Topic:

In Suggestions, BasKrie writes:

In Suggestions, Teup writes:

In Suggestions, SezaR writes:

In Suggestions, Teup writes:

In Suggestions, SezaR writes:

In Suggestions, sparesleftovers writes:

In Suggestions, SezaR writes:

- Buyer placed an order and made a payment without getting an invoice

Hmmmm, so the buyer paid (via PayPal offsite) without getting an invoice? How?
How was he even able to pay you?

He used the email address of my store, which is the wrong address anyway.

They can't? When they send it, isn't it up to you to figure out how to
collect it?

And why wait for it to bounce? Buyer could
have send the money to the correct address right away. It's the buyers choice
to wait, no obligtion.

Author:

Teup

Posted:

May 26, 2020 05:02

Subject:

Re: Comments during instant Checkout

Viewed:

36 times

Topic:

In Suggestions, bje writes:

In Suggestions, Teup writes:

In Suggestions, BHamBricks writes:

I recently decided to add instant checkout to my store. I received my first
ever neutral feedback because I didn't include a note as requested in the
buyer's comment section. My suggestion is to add the buyer's comments
section on the sellers invoice (like it always has been on the invoice when an
invoice was requested). There is no buyer's comments section on the email
I receive notifying me that an order has been placed. In this instance, this
caused an unpleasant experience for the buyer.

Did you put the BUYERCOMMENTS in your template? Then it should work.

Not even sure how you managed to have a different invoice for IC than for manual?
I wish there was a INSTANTCHECKOUT-EQ conditional macro tag to handle that, but
there isn't...

https://www.bricklink.com/v2/mystore/message_templates.page

The one you want to edit is "Purchase Confirmation", that is supposedly an invoice
you issue for instant checkout. I am thinking of adding some lines to that so
it can serve as a sort of an invoice and a receipt in one, or well, just something
better than basically telling the buyer he has ordered a thing from somewhere
with not even a thank you for the payment and no terms.

You of course cannot edit the header and call the thing an invoice, grrr

Author:

Teup

Posted:

May 26, 2020 03:49

Subject:

Re: Comments during instant Checkout

Viewed:

41 times

Topic:

In Suggestions, BHamBricks writes:

Author:

Teup

Posted:

May 26, 2020 03:40

Subject:

Re: Disable Buyer's Ability to mark order Paid

Viewed:

36 times

Topic:

In Suggestions, SezaR writes:

In Suggestions, Teup writes:

In Suggestions, SezaR writes:

In Suggestions, sparesleftovers writes:

In Suggestions, SezaR writes:

- Buyer placed an order and made a payment without getting an invoice

Hmmmm, so the buyer paid (via PayPal offsite) without getting an invoice? How?
How was he even able to pay you?

He used the email address of my store, which is the wrong address anyway.

They can't? When they send it, isn't it up to you to figure out how to
collect it?

I wish the payment would simply bounce, but unfortunately it doesn't...

If you send a payment to an email address that is not associated to any PayPal
account, you can easily request a refund from PayPal. It should easily work.
Am I missing something?

I don't think it can be cancelled like that.. I rememeber I once had to wait
2 months with a buyer for their payment to finally bounce, so they could send
it again. Not really an acceptable situation, because you'll just have to
hope the buyer is trustworthy. But as usual PayPal does everything for the buyer
and nothing for the seller.

Author:

Teup

Posted:

May 25, 2020 18:44

Subject:

Re: Disable Buyer's Ability to mark order Paid

Viewed:

18 times

Topic:

In Suggestions, SezaR writes:

In Suggestions, Mistress_Lisa writes:

Someone just ordered from me and marked the order paid when I haven't even
sent an invoice yet! But now the line is grayed out, and I am unable to send
an invoice! Why is there even the option for a buyer to mark the order paid?
As a seller, it doesn't matter to me if the numbers are in bold (showing
'paid'

since I don't think it is paid until I check Paypal to make
sure it is in my account. (or received the check in the mail or whatever).
Like Scrooge, I don't ship until I have the 'cash in hand', so I
should be the only one to mark it paid. (or the Paypal link, that is fine too,
just not the buyer).

Lisa at Brick Dungeon

This is a problem. A buyer can take a profit and act unfairly. He just mark the
order "paid" and then, as the seller receives many orders, he may not check his
PayPal accounts to see if all orders were paid them. Then he ships the order,
and then, the buyer still do not pay (request to cancel)....

You always need to verify them yourself. But it's a great help that it indicates
that they (claim to have) sent it so you know when to look, especially for payment
methods that don't produce any notifications.

Author:

Teup

Posted:

May 25, 2020 18:39

Subject:

Re: Disable Buyer's Ability to mark order Paid

Viewed:

25 times

Topic:

In Suggestions, SezaR writes:

In Suggestions, sparesleftovers writes:

In Suggestions, SezaR writes:

- Buyer placed an order and made a payment without getting an invoice

Hmmmm, so the buyer paid (via PayPal offsite) without getting an invoice? How?
How was he even able to pay you?

He used the email address of my store, which is the wrong address anyway.

They can't? When they send it, isn't it up to you to figure out how to
collect it? I wish the payment would simply bounce, but unfortunately it doesn't...
Happens pretty often that buyers just assume that addres is gonna work.. it's
kind of like throwing with money and they have full confidence that you will
catch it

Luckily it is possible within PayPal to add alias e-mail addresses.
Unfortunately though, that system is bugged and gives me errors if I press the
verification link it sends to that alias address... I currently have an amount
stuck in limbo because of a buyer using my communication email address and so
far I haven't figured out how to unstuck it.

Author:

Teup

Posted:

May 25, 2020 18:33

Subject:

Re: Why are these Hinges?

Viewed:

28 times

Topic:

In Catalog, qwertyboy writes:

In Catalog, Teup writes:

Maybe a good (part of the) definition of hinges is that the parts do not appear
without a counterpart (unless used creatively)? That would include the toothed
hinge plates, swivels, hinge bricks and their top plates, and as far as I can
see pretty much everything else that is in Hinge.

In fact, I would prefer if it would include turntables - the same logic applies
to their bases and top plates (when they're not Plate,Rounds that can be
used in isolation).

208 turntable bases in these two sets beg to differ...

10189-1 (Inv) Taj Mahal
5922 Parts, 2008
Sets: Sculptures

10256-1 (Inv) Taj Mahal {Reissue}
5923 Parts, 2017
Sets: Sculptures

Niek.

True.. that's why I made an exception for "used creatively"

It's more
of an AFOL'ish way to use that part than how it was intended.

Author:

Teup

Posted:

May 25, 2020 14:40

Subject:

Re: Improved Method for Requesting Insurance?

Viewed:

35 times

Topic:

In Suggestions, kurtcrazy writes:

Is it possible for Bricklink to improve the method of requesting insurance for
an order?
Currently one has to add a comment to another area, which I am not sure if the
seller sees.
Also when doing instant checkout through Paypal, there is no way to add insurance,
as the order gets paid for before the seller even sees it. (To the best of my
knowledge, as I am not a seller.) I do add the comment anyway, but it seems
kind of pointless once the money has been sent.
Not sure if I am in the minority with my consistent request for insurance. If
so, then it is more understandable why this may not have been addressed previously
and/or may not be addressed soon.
Thank you for your time and consideration.

In my opinion that entire field should be ditched. It's been taking up space
in the middle for my screen for 15 years and I never understood what exactly
it's for. BO doesn't have it either. But that's my perspective, maybe
I'm just missing something..

Author:

Teup

Posted:

May 25, 2020 14:20

Subject:

Re: Disable Buyer's Ability to mark order Paid

Viewed:

34 times

Topic: