Redisplay Messages: Compact | Brief | All | Full Show Messages: All | Without Replies| Author: | jennnifer  | | Posted: | Dec 6, 2016 17:53 | | Subject: | Inventory Change Request for Set 5892-1 | | Viewed: | 19 times | | Topic: | Inventories Requests (Entry) | | Status: | Open | |
| Please make changes to the following inventory:
* Change 1 Part Black {51011u Tire 17.5mm D. x 6mm with Shallow Staggered Treads (undetermined type) to 42611 Tire 17.5mm D. x 6mm with Shallow Staggered Treads}
Comments from Submitter:
Source: set in my personal collection.
|
 |
| Author: | taxan | | Posted: | Dec 6, 2016 12:54 | | Subject: | Re: Inventory Change Request for Minifig mmf005 | | Viewed: | 18 times | | Topic: | Inventories Requests | |
| In Inventories Requests, Humpfry007 writes:
| | Please make changes to the following inventory:
* Delete 1 Part 3901 Brown Minifig, Hair Male
Comments from Submitter:
The hair of the minifig is female (No.4530) on the picture of the instructions of set 1878-1
|
That Male Minifig still are in set and .
The image of the instructions for set do show a female Minifig
But the correct Female Minifig aren't in the Catalog yet.
It need to be added (with picture) to the Catalog before a change request for
that set can be made.
Have a nice day.
taxan
|
|
| Author: | Humpfry007 | | Posted: | Dec 6, 2016 09:51 | | Subject: | Inventory Change Request for Minifig mmf005 | | Viewed: | 42 times | | Topic: | Inventories Requests (Entry) | | Status: | Open | |
| Please make changes to the following inventory:
* Delete 1 Part 3901 Brown Minifig, Hair Male
Comments from Submitter:
The hair of the minifig is female (No.4530) on the picture of the instructions of set 1878-1
|
|
| Author: | mandr | | Posted: | Dec 5, 2016 23:49 | | Subject: | Re: Inventory Change Request for Set 5599-1 | | Viewed: | 12 times | | Topic: | Inventories Requests | |
| In Inventories Requests, mandr writes:
| | Please make changes to the following inventory:
* Change {3 to 4} Part Red 3039 Slope 45 2 x 2
Comments from Submitter:
Currently, there are 3 red 2x2 slopes. But on page 55 to 56 of the instructions, there are 3 in Step 1, and it looks like 1 more is added in Step 2. This is a similar change to the corresponding set 5600.
|
Here is a snapshot of the relevant pages in the booklet for set 5599:
|
|
|
| Author: | mandr | | Posted: | Dec 5, 2016 23:45 | | Subject: | Inventory Change Request for Set 5599-1 | | Viewed: | 18 times | | Topic: | Inventories Requests (Entry) | | Status: | Open | |
| Please make changes to the following inventory:
* Change {3 to 4} Part Red 3039 Slope 45 2 x 2
Comments from Submitter:
Currently, there are 3 red 2x2 slopes. But on page 55 to 56 of the instructions, there are 3 in Step 1, and it looks like 1 more is added in Step 2. This is a similar change to the corresponding set 5600.
|
|
| Author: | mandr | | Posted: | Dec 5, 2016 23:37 | | Subject: | Re: Inventory Change Request for Set 5600-1 | | Viewed: | 13 times | | Topic: | Inventories Requests | |
| In Inventories Requests, mandr writes:
| | Please make changes to the following inventory:
* Change {3 to 4} Part Red 3039 Slope 45 2 x 2
Comments from Submitter:
Currently, there are 3 red 2x2 slopes. But on page 58-59 of the instructions, there are 3 in Step 1, and it looks like 1 more is added in Step 2.
|
|
|
| Author: | mandr | | Posted: | Dec 5, 2016 23:36 | | Subject: | Inventory Change Request for Set 5600-1 | | Viewed: | 16 times | | Topic: | Inventories Requests (Entry) | | Status: | Open | |
| Please make changes to the following inventory:
* Change {3 to 4} Part Red 3039 Slope 45 2 x 2
Comments from Submitter:
Currently, there are 3 red 2x2 slopes. But on page 58-59 of the instructions, there are 3 in Step 1, and it looks like 1 more is added in Step 2.
|
|
| Author: | randyf | | Posted: | Dec 5, 2016 11:00 | | Subject: | Inventory Change Request for Set 76027-1 | | Viewed: | 19 times | | Topic: | Inventories Requests (Entry) | | Status: | Open | |
| Please make changes to the following inventory:
* Change 1 Book 6112152 Super Heroes Comic Book, DC Comics, Gorilla Grodd & Darkseid (Batman & Superman Logo) {match ID 0 to 2}
* Change 1 Book 6112153 Super Heroes Comic Book, DC Comics, Gorilla Grodd & Darkseid (Justice League Logo) {Regular to Alternate} {match ID 0 to 2}
Comments from Submitter:
Only one of the two books comes with the set. Therefore, one has to be an alternate, and one has to be the regular.
|
|
| Author: | badbob001 | | Posted: | Dec 5, 2016 10:44 | | Subject: | Pick multiple countries for auto-finder | | Viewed: | 49 times | | Topic: | Suggestions | | Status: | Open | | Vote: | [Yes|No] | |
| Please add an option to pick more than one country in the auto-finder feature.
I like to buy from several countries and it's limiting to be restricted to
just one. The region option is also no good since my preferred stores are not
in the same region. For example, I like to purchase from USA and Germany.
Thanks!
|
| Author: | randyf | | Posted: | Dec 5, 2016 09:26 | | Subject: | Inventory Change Request for Set 8821-1 | | Viewed: | 18 times | | Topic: | Inventories Requests (Entry) | | Status: | Open | |
| Please make changes to the following inventory:
* Change 2 Part {Metallic Silver to Pearl Light Gray} 51342pb04 Dragon Wing 19 x 11, Yellow Trailing Edge
Comments from Submitter:
Part is definitely *NOT* Metallic Silver, since Metallic Silver parts are coated in paint. These wings are a multicolor part which are molded from two colors of plastic.
|
|
| Author: | WoutR | | Posted: | Dec 4, 2016 18:40 | | Subject: | Re: Inventory Change Request for Set 005-1 | | Viewed: | 18 times | | Topic: | Inventories Requests | |
| In Inventories Requests, legoman77 writes:
| | In Inventories Requests, WoutR writes:
| | In Inventories Requests, viejos writes:
| | In Inventories Requests, huriel writes:
| | Please make changes to the following inventory:
* Add 1 Part 3004 Red Brick 1 x 2
* Add 1 Part 3003old Red Brick 2 x 2 without Inside Supports
* Add 10 Part 3001old Red Brick 2 x 4 without Cross Supports
* Add 1 Part 3004 White Brick 1 x 2
* Add 1 Part 3003old White Brick 2 x 2 without Inside Supports
* Add 10 Part 3001old White Brick 2 x 4 without Cross Supports
* Add 2 Part 3004 Yellow Brick 1 x 2
* Add 2 Part 3004 Blue Brick 1 x 2
* Add 2 Part 3004 Black Brick 1 x 2
* Add 4 Part 3004 Trans-Clear Brick 1 x 2
Comments from Submitter:
I just acquired a set, which was incomplete but with the original box. Seeing the models there, it is simply impossible to build them with the current BrickLink's inventory. I reconstructed what should be the minimal set to build all the models in the box. This is also evident from the photos which are uploaded in BrickLink, but I can provide new photos with the alternate models in the box, if needed.
Completing the box with all the pieces that I think should be in the inventory and a catalog of that time, the weight is 204 g, please update that as well.
|
For these very old sets, they often came with stock pictures that were not intended
to serve as instructions for what could be built with the set.
|
I Agree. They were inspirational models that were not directly related to the
set contents.
| | Before making
any changes, please check with the submitter of this inventory who is an authority
on such matters.
It is also possible that different contents came at different times and locations
for these old sets, which were little more than parts packs. Often the BL inventory
only serves as a suggestion as to what one might find.
Russell
|
|
I had several of these sets and many matched the bricks that were in each. Here
on Peeron.com it was inventoried by someone and I varied it from the sets I had
in my possession. At the same time, Lego often substituted elements when they
ran short and they did not change building instructions.
http://peeron.com/inv/sets/005-2
John P
John P
|
I think that the first instructions were added to some sets in 1964. Not all
the sets immediately included them. I think this set was made during the transition
period. I agree with Russell that caution is needed for sets from this time period,
and depending on box images to reconstruct the set contents could lead to errors.
PS. Note that you linked to a different set:
|
|
| Author: | legoman77 | | Posted: | Dec 4, 2016 17:30 | | Subject: | Re: Inventory Change Request for Set 005-1 | | Viewed: | 32 times | | Topic: | Inventories Requests | |
| In Inventories Requests, WoutR writes:
| | In Inventories Requests, viejos writes:
| | In Inventories Requests, huriel writes:
| | Please make changes to the following inventory:
* Add 1 Part 3004 Red Brick 1 x 2
* Add 1 Part 3003old Red Brick 2 x 2 without Inside Supports
* Add 10 Part 3001old Red Brick 2 x 4 without Cross Supports
* Add 1 Part 3004 White Brick 1 x 2
* Add 1 Part 3003old White Brick 2 x 2 without Inside Supports
* Add 10 Part 3001old White Brick 2 x 4 without Cross Supports
* Add 2 Part 3004 Yellow Brick 1 x 2
* Add 2 Part 3004 Blue Brick 1 x 2
* Add 2 Part 3004 Black Brick 1 x 2
* Add 4 Part 3004 Trans-Clear Brick 1 x 2
Comments from Submitter:
I just acquired a set, which was incomplete but with the original box. Seeing the models there, it is simply impossible to build them with the current BrickLink's inventory. I reconstructed what should be the minimal set to build all the models in the box. This is also evident from the photos which are uploaded in BrickLink, but I can provide new photos with the alternate models in the box, if needed.
Completing the box with all the pieces that I think should be in the inventory and a catalog of that time, the weight is 204 g, please update that as well.
|
For these very old sets, they often came with stock pictures that were not intended
to serve as instructions for what could be built with the set.
|
I Agree. They were inspirational models that were not directly related to the
set contents.
| | Before making
any changes, please check with the submitter of this inventory who is an authority
on such matters.
It is also possible that different contents came at different times and locations
for these old sets, which were little more than parts packs. Often the BL inventory
only serves as a suggestion as to what one might find.
Russell
|
|
I had several of these sets and many matched the bricks that were in each. Here
on Peeron.com it was inventoried by someone and I varied it from the sets I had
in my possession. At the same time, Lego often substituted elements when they
ran short and they did not change building instructions.
http://peeron.com/inv/sets/005-2
John P
John P
|
|
| Author: | WoutR | | Posted: | Dec 4, 2016 16:40 | | Subject: | Re: Inventory Change Request for Set 005-1 | | Viewed: | 33 times | | Topic: | Inventories Requests | |
| In Inventories Requests, viejos writes:
| | In Inventories Requests, huriel writes:
| | Please make changes to the following inventory:
* Add 1 Part 3004 Red Brick 1 x 2
* Add 1 Part 3003old Red Brick 2 x 2 without Inside Supports
* Add 10 Part 3001old Red Brick 2 x 4 without Cross Supports
* Add 1 Part 3004 White Brick 1 x 2
* Add 1 Part 3003old White Brick 2 x 2 without Inside Supports
* Add 10 Part 3001old White Brick 2 x 4 without Cross Supports
* Add 2 Part 3004 Yellow Brick 1 x 2
* Add 2 Part 3004 Blue Brick 1 x 2
* Add 2 Part 3004 Black Brick 1 x 2
* Add 4 Part 3004 Trans-Clear Brick 1 x 2
Comments from Submitter:
I just acquired a set, which was incomplete but with the original box. Seeing the models there, it is simply impossible to build them with the current BrickLink's inventory. I reconstructed what should be the minimal set to build all the models in the box. This is also evident from the photos which are uploaded in BrickLink, but I can provide new photos with the alternate models in the box, if needed.
Completing the box with all the pieces that I think should be in the inventory and a catalog of that time, the weight is 204 g, please update that as well.
|
For these very old sets, they often came with stock pictures that were not intended
to serve as instructions for what could be built with the set.
|
I Agree. They were inspirational models that were not directly related to the
set contents.
| | Before making
any changes, please check with the submitter of this inventory who is an authority
on such matters.
It is also possible that different contents came at different times and locations
for these old sets, which were little more than parts packs. Often the BL inventory
only serves as a suggestion as to what one might find.
Russell
|
|
|
| Author: | huriel | | Posted: | Dec 4, 2016 16:26 | | Subject: | Re: Inventory Change Request for Set 005-1 | | Viewed: | 28 times | | Topic: | Inventories Requests | |
| | Another photo, of the back of the box |
|
| Author: | huriel | | Posted: | Dec 4, 2016 16:24 | | Subject: | Re: Inventory Change Request for Set 005-1 | | Viewed: | 41 times | | Topic: | Inventories Requests | |
| | As anticipated, here are some photos of the box. |
|
| Author: | Singidunum | | Posted: | Dec 4, 2016 16:07 | | Subject: | Inventory Change Request for Set 7754-1 | | Viewed: | 37 times | | Topic: | Inventories Requests (Entry) | | Status: | Open | |
| Please make changes to the following inventory:
* Add 1 Part 44126pb042L Dark Green Slope, Curved 6 x 2, with Black Geometric Pattern Model Left Side (Sticker) - Set 7754 (Counterpart)
* Add 1 Part 44126pb042R Dark Green Slope, Curved 6 x 2, with Black Geometric Pattern Model Right Side (Sticker) - Set 7754 (Counterpart)
Comments from Submitter:
Counterpart (stickered) parts for the set 7754 Home One Mon Calamari Star Cruiser
|
|
| Author: | therobo | | Posted: | Dec 4, 2016 14:56 | | Subject: | Re: Inventory Change Request for Set 7942-1 | | Viewed: | 26 times | | Topic: | Inventories Requests | |
| In Inventories Requests, hawkbit writes:
| | Please make changes to the following inventory:
* Change 1 Part Light Bluish Gray {3730 Plate, Modified 2 x 2 with Towball Socket, Short, 4 Slots to 63082 Plate, Modified 2 x 2 with Towball Socket, Short, Flattened with Holes and Axle Hole in Center}
Comments from Submitter:
In accordance with the building instructions on the LEGO website.
|
Both variants are already in the inventory as regular and alternate items.
|
|
| Author: | calsbricks | | Posted: | Dec 4, 2016 11:25 | | Subject: | Please add BL part no to xml verify page | | Viewed: | 70 times | | Topic: | Suggestions | | Status: | Implemented | |
| This is now causing some problems as it does not appear on the page after the
initial paste into the file box. Please add the BL part number to aid reconciliation.
|
| Author: | bb435104 | | Posted: | Dec 4, 2016 09:09 | | Subject: | Inventory Change Request for Set 7942-1 | | Viewed: | 29 times | | Topic: | Inventories Requests (Entry) | | Status: | Open | |
| Please make changes to the following inventory:
* Change 1 Part Light Bluish Gray {3730 Plate, Modified 2 x 2 with Towball Socket, Short, 4 Slots to 63082 Plate, Modified 2 x 2 with Towball Socket, Short, Flattened with Holes and Axle Hole in Center}
Comments from Submitter:
In accordance with the building instructions on the LEGO website.
|
|
| Author: | Peettoys | | Posted: | Dec 4, 2016 08:17 | | Subject: | Inventory Change Request for Set 7751-1 | | Viewed: | 26 times | | Topic: | Inventories Requests (Entry) | | Status: | Open | |
| Please make changes to the following inventory:
* Add 1 Part 4150pb002b White Tile, Round 2 x 2 with SW Republic Pattern on White Background (Sticker) (Counterpart)
Comments from Submitter:
As can been seen on the left side of Ahskoka's Starfighter (instruction booklet page 75).
|
| Author: | bb53904 | | Posted: | Dec 2, 2016 16:41 | | Subject: | Inventory Change Request for Set 10252-1 | | Viewed: | 30 times | | Topic: | Inventories Requests (Entry) | | Status: | Open | |
| Please make changes to the following inventory:
* Change {1 to 2} Part White 3024 Plate 1 x 1 (Extra)
Comments from Submitter:
Model built from sealed box contents. Originally thought it was unusual to find 2 spares of this part in the same bag, so triple checked.
|
| Author: | therobo | | Posted: | Dec 2, 2016 16:39 | | Subject: | Re: Country flag ? | | Viewed: | 30 times | | Topic: | Suggestions | |
| In Suggestions, Brickwilbo writes:
| | In Suggestions, peplu06 writes:
| | Hi,
It would be nice and useful to see a small flag matching the
country between "date" and "buyer" in the "feedback" tab.
Is this something possible?
Thanks
Eric
|
Already possible to show country flags: http://www.bricklink.com/feedbackSettings.asp?viewFrom=P
|
Look at the FB tab in stores...
|
| Author: | Brickwilbo | | Posted: | Dec 2, 2016 16:32 | | Subject: | Re: Country flag ? | | Viewed: | 27 times | | Topic: | Suggestions | |
| In Suggestions, peplu06 writes:
| | Hi,
It would be nice and useful to see a small flag matching the
country between "date" and "buyer" in the "feedback" tab.
Is this something possible?
Thanks
Eric
|
Already possible to show country flags: http://www.bricklink.com/feedbackSettings.asp?viewFrom=P
|
| Author: | Grego | | Posted: | Dec 2, 2016 15:42 | | Subject: | Re: Country flag ? | | Viewed: | 29 times | | Topic: | Suggestions | |
| In Suggestions, peplu06 writes:
| | Hi,
It would be nice and useful to see a small flag matching the
country between "date" and "buyer" in the "feedback" tab.
Is this something possible?
Thanks
Eric
|
It probably won't happen.
It would clutter up the triplily redundant FB score, FB coloured brick and FB
brick order number in the block.
Newbies would get confused and want a different country's flag to be displayed
depending on BL's randomized optimization algorithm.
|
| Author: | BTJ2023 | | Posted: | Dec 2, 2016 14:56 | | Subject: | Country flag ? | | Viewed: | 137 times | | Topic: | Suggestions | | Status: | Discarded | |
| Hi,
It would be nice and useful to see a small flag matching the
country between "date" and "buyer" in the "feedback" tab.
Is this something possible?
Thanks
Eric
|
|
| Author: | chetzler | | Posted: | Dec 1, 2016 19:07 | | Subject: | Re: Limit cash payments to approved postal codes | | Viewed: | 37 times | | Topic: | Suggestions | |
| In Suggestions, RobErNat writes:
| | In Suggestions, chetzler writes:
| | I just had a buyer from three states away claim that he sent cash in the mail.
|
He 'claims'...
So I suspect you didn't get it (yet) and that he's getting worried...
|
Perhaps "claims" was poor choice of words, I don't suspect anything underhanded
here. The order is less than 20 USD and he's not worried, he only sent it
two days ago (It'll probably be in the mailbox when I get home  )
| |
| | While this seems very risky to me,
|
That would depend on 'how' it was send, sending cash requires a certain
amount of 'intelligent' wrapping so that it ain't 'obvious'
it's cash...
Bills alot of dark paper will do the trick
Coins glued with tape and between cardboard.
The latter remains a problem if it goes trough 'scanners' (for airplanes
and such)
| | he did indeed select "Cash (no COD)" as a
payment type even though that option states that it is for local pickup only.
|
I even got a couple of 'international' ones, without any hastle, but
those where 'bills' only (and invisably wrapped by the buyer).
| | Since there is no way to actually enforce local pickup, I didn't realize
this until after he mailed the money, frankly because I've never had anyone
do this before!
|
Don't consider it 'unique' 
| | I accept lots of cash payments from members of my LUG, but it
doesn't usually occur outside of that.
|
Once had someone send me a 'ton' of coins between cardboard, I suspected
him to be a minor emptying his 'piggy bank'  , it arrived, I shipped,
no hastle
|
Wow, depending on how many coins, one might have to pay a large shipping fee
just to get the payment to the seller! Still beats the barter system: imagine
mailing a chicken.
| |
| |
Can we get BrickLink to only accept "Cash" payments on an order if that buyer's
postal code is on a seller-selected list? I don't know how postal codes
work in other countries, but in the US (and Canada to, I think) the zip code
gets more specific as you go from left to right. So for example, using wildcard
characters, I could allow cash payments from anyone in Lincoln, NE with a single
entry: 685**.
|
Sounds complicated, as BL would need to split the 'national buyers' into
thousands of states and provinces all around the world, with the option the be
able to select 'multiple' regions in 'multiple' countries (I've
had international buyers picking up orders because they only live about 100 miles
away - I'm in a small country-)
|
I don't see it as being too complicated. I have a list on which I put selected
zip codes. If a buyer selects "Cash" and his zip code is not on the list, he
is asked to choose a different payment method. BrickLink doesn't need to
be concerned with different states/provinces etc. The onus is on me, the seller,
to set up my approved zip codes list. All BL would have to do is give me a way
to use that list to validate payment methods. And of course, the whole validation
system would be optional, no seller would have to use it.
| |
Deactivate 'Cash' if you don't want the hastle, people who wanna
pickup will usually send a mail anyway after seeing your address (and usually
that is *after* they already made the purchase), so just leave in a non instant
payment method (Paypal onsite 'only' would be a problem)
|
|
|
| Author: | cosmicray | | Posted: | Dec 1, 2016 18:54 | | Subject: | Re: Limit cash payments to approved postal codes | | Viewed: | 37 times | | Topic: | Suggestions | |
| In Suggestions, chetzler writes:
| | I just had a buyer from three states away claim that he sent cash in the mail.
While this seems very risky to me, he did indeed select "Cash (no COD)" as a
payment type even though that option states that it is for local pickup only.
Since there is no way to actually enforce local pickup, I didn't realize
this until after he mailed the money, frankly because I've never had anyone
do this before! I accept lots of cash payments from members of my LUG, but it
doesn't usually occur outside of that.
Can we get BrickLink to only accept "Cash" payments on an order if that buyer's
postal code is on a seller-selected list? I don't know how postal codes
work in other countries, but in the US (and Canada to, I think) the zip code
gets more specific as you go from left to right. So for example, using wildcard
characters, I could allow cash payments from anyone in Lincoln, NE with a single
entry: 685**.
Thoughts?
-Chris
|
Well, Cash should have been sent registered in any case. I've had a few rare
cash payments over the years, including one from Japan and another that over-paid
by enough that I had to send change in the return package.
Ray
|
|
| Author: | RobErNat | | Posted: | Dec 1, 2016 14:18 | | Subject: | Re: Limit cash payments to approved postal codes | | Viewed: | 48 times | | Topic: | Suggestions | |
| In Suggestions, chetzler writes:
| | I just had a buyer from three states away claim that he sent cash in the mail.
|
He 'claims'...
So I suspect you didn't get it (yet) and that he's getting worried...
| | While this seems very risky to me,
|
That would depend on 'how' it was send, sending cash requires a certain
amount of 'intelligent' wrapping so that it ain't 'obvious'
it's cash...
Bills alot of dark paper will do the trick
Coins glued with tape and between cardboard.
The latter remains a problem if it goes trough 'scanners' (for airplanes
and such)
| | he did indeed select "Cash (no COD)" as a
payment type even though that option states that it is for local pickup only.
|
I even got a couple of 'international' ones, without any hastle, but
those where 'bills' only (and invisably wrapped by the buyer).
| | Since there is no way to actually enforce local pickup, I didn't realize
this until after he mailed the money, frankly because I've never had anyone
do this before!
|
Don't consider it 'unique'
| | I accept lots of cash payments from members of my LUG, but it
doesn't usually occur outside of that.
|
Once had someone send me a 'ton' of coins between cardboard, I suspected
him to be a minor emptying his 'piggy bank' , it arrived, I shipped,
no hastle
| |
Can we get BrickLink to only accept "Cash" payments on an order if that buyer's
postal code is on a seller-selected list? I don't know how postal codes
work in other countries, but in the US (and Canada to, I think) the zip code
gets more specific as you go from left to right. So for example, using wildcard
characters, I could allow cash payments from anyone in Lincoln, NE with a single
entry: 685**.
|
Sounds complicated, as BL would need to split the 'national buyers' into
thousands of states and provinces all around the world, with the option the be
able to select 'multiple' regions in 'multiple' countries (I've
had international buyers picking up orders because they only live about 100 miles
away - I'm in a small country-)
Deactivate 'Cash' if you don't want the hastle, people who wanna
pickup will usually send a mail anyway after seeing your address (and usually
that is *after* they already made the purchase), so just leave in a non instant
payment method (Paypal onsite 'only' would be a problem)
|
|
| Author: | Grego | | Posted: | Dec 1, 2016 12:39 | | Subject: | Re: Limit cash payments to approved postal codes | | Viewed: | 32 times | | Topic: | Suggestions | |
| In Suggestions, chetzler writes:
| | In Suggestions, qwertyboy writes:
| | In Suggestions, chetzler writes:
| | I just had a buyer from three states away claim that he sent cash in the mail.
While this seems very risky to me, he did indeed select "Cash (no COD)" as a
payment type even though that option states that it is for local pickup only.
Since there is no way to actually enforce local pickup, I didn't realize
this until after he mailed the money, frankly because I've never had anyone
do this before! I accept lots of cash payments from members of my LUG, but it
doesn't usually occur outside of that.
Can we get BrickLink to only accept "Cash" payments on an order if that buyer's
postal code is on a seller-selected list? I don't know how postal codes
work in other countries, but in the US (and Canada to, I think) the zip code
gets more specific as you go from left to right. So for example, using wildcard
characters, I could allow cash payments from anyone in Lincoln, NE with a single
entry: 685**.
|
I accept cash when customers pick it up, but in my shop settings I only allow
Paypal payments. If people want to pay in cash at pickup, we communicate beforehand.
This way customers can't "force" a cash payment when it is not appropriate.
So I would suggest you simply remove the cash payment option in your shop, and
maybe add a little blurb that you allow cash at pickup.
Niek.
|
I used to do it that way, but if it is a local buyer (especially someone from
my LUG) I like to know how they're going to pay because I usually give a
discount, and that discount is often a bit more generous if they're paying
with cash.
|
I go further, I make no mention of cash or even local pickup as an option, but
when asked, I almost always agree to local pickup ...cash only. Why pay PayPal
their cut when you don't need to? Buyer saves on shipping. I save on PayPal
fees, win-win.
And no mysterious cash thru the mail 😁 orders
|
|
| Author: | chetzler | | Posted: | Dec 1, 2016 12:29 | | Subject: | Re: Limit cash payments to approved postal codes | | Viewed: | 33 times | | Topic: | Suggestions | |
| In Suggestions, qwertyboy writes:
| | In Suggestions, chetzler writes:
| | I just had a buyer from three states away claim that he sent cash in the mail.
While this seems very risky to me, he did indeed select "Cash (no COD)" as a
payment type even though that option states that it is for local pickup only.
Since there is no way to actually enforce local pickup, I didn't realize
this until after he mailed the money, frankly because I've never had anyone
do this before! I accept lots of cash payments from members of my LUG, but it
doesn't usually occur outside of that.
Can we get BrickLink to only accept "Cash" payments on an order if that buyer's
postal code is on a seller-selected list? I don't know how postal codes
work in other countries, but in the US (and Canada to, I think) the zip code
gets more specific as you go from left to right. So for example, using wildcard
characters, I could allow cash payments from anyone in Lincoln, NE with a single
entry: 685**.
|
I accept cash when customers pick it up, but in my shop settings I only allow
Paypal payments. If people want to pay in cash at pickup, we communicate beforehand.
This way customers can't "force" a cash payment when it is not appropriate.
So I would suggest you simply remove the cash payment option in your shop, and
maybe add a little blurb that you allow cash at pickup.
Niek.
|
I used to do it that way, but if it is a local buyer (especially someone from
my LUG) I like to know how they're going to pay because I usually give a
discount, and that discount is often a bit more generous if they're paying
with cash.
|
|
| Author: | chetzler | | Posted: | Dec 1, 2016 12:25 | | Subject: | Re: Limit cash payments to approved postal codes | | Viewed: | 40 times | | Topic: | Suggestions | |
| In Suggestions, Brickwilbo writes:
| | In Suggestions, chetzler writes:
| | I just had a buyer from three states away claim that he sent cash in the mail.
While this seems very risky to me, he did indeed select "Cash (no COD)" as a
payment type even though that option states that it is for local pickup only.
Since there is no way to actually enforce local pickup, I didn't realize
this until after he mailed the money, frankly because I've never had anyone
do this before! I accept lots of cash payments from members of my LUG, but it
doesn't usually occur outside of that.
Can we get BrickLink to only accept "Cash" payments on an order if that buyer's
postal code is on a seller-selected list? I don't know how postal codes
work in other countries, but in the US (and Canada to, I think) the zip code
gets more specific as you go from left to right. So for example, using wildcard
characters, I could allow cash payments from anyone in Lincoln, NE with a single
entry: 685**.
Thoughts?
|
Why didn't you catch it at invoicing?
|
Like I said, no one had ever done this before so it wasn't even on my radar.
Of all the things I double-check before invoicing, this is one I never thought
I'd have to worry about--why would anyone risk sending cash in the mail?
|
|
| Author: | qwertyboy | | Posted: | Dec 1, 2016 12:08 | | Subject: | Re: Limit cash payments to approved postal codes | | Viewed: | 37 times | | Topic: | Suggestions | |
| In Suggestions, chetzler writes:
| | I just had a buyer from three states away claim that he sent cash in the mail.
While this seems very risky to me, he did indeed select "Cash (no COD)" as a
payment type even though that option states that it is for local pickup only.
Since there is no way to actually enforce local pickup, I didn't realize
this until after he mailed the money, frankly because I've never had anyone
do this before! I accept lots of cash payments from members of my LUG, but it
doesn't usually occur outside of that.
Can we get BrickLink to only accept "Cash" payments on an order if that buyer's
postal code is on a seller-selected list? I don't know how postal codes
work in other countries, but in the US (and Canada to, I think) the zip code
gets more specific as you go from left to right. So for example, using wildcard
characters, I could allow cash payments from anyone in Lincoln, NE with a single
entry: 685**.
|
I accept cash when customers pick it up, but in my shop settings I only allow
Paypal payments. If people want to pay in cash at pickup, we communicate beforehand.
This way customers can't "force" a cash payment when it is not appropriate.
So I would suggest you simply remove the cash payment option in your shop, and
maybe add a little blurb that you allow cash at pickup.
Niek.
|
|
| Author: | Brickwilbo | | Posted: | Dec 1, 2016 11:30 | | Subject: | Re: Limit cash payments to approved postal codes | | Viewed: | 33 times | | Topic: | Suggestions | |
| In Suggestions, chetzler writes:
| | I just had a buyer from three states away claim that he sent cash in the mail.
While this seems very risky to me, he did indeed select "Cash (no COD)" as a
payment type even though that option states that it is for local pickup only.
Since there is no way to actually enforce local pickup, I didn't realize
this until after he mailed the money, frankly because I've never had anyone
do this before! I accept lots of cash payments from members of my LUG, but it
doesn't usually occur outside of that.
Can we get BrickLink to only accept "Cash" payments on an order if that buyer's
postal code is on a seller-selected list? I don't know how postal codes
work in other countries, but in the US (and Canada to, I think) the zip code
gets more specific as you go from left to right. So for example, using wildcard
characters, I could allow cash payments from anyone in Lincoln, NE with a single
entry: 685**.
Thoughts?
|
Why didn't you catch it at invoicing?
|
|
| Author: | bricksahead | | Posted: | Dec 1, 2016 11:26 | | Subject: | Re: Limit cash payments to approved postal codes | | Viewed: | 34 times | | Topic: | Suggestions | |
| In Suggestions, chetzler writes:
| | I just had a buyer from three states away claim that he sent cash in the mail.
While this seems very risky to me, he did indeed select "Cash (no COD)" as a
payment type even though that option states that it is for local pickup only.
Since there is no way to actually enforce local pickup, I didn't realize
this until after he mailed the money, frankly because I've never had anyone
do this before! I accept lots of cash payments from members of my LUG, but it
doesn't usually occur outside of that.
Can we get BrickLink to only accept "Cash" payments on an order if that buyer's
postal code is on a seller-selected list? I don't know how postal codes
work in other countries, but in the US (and Canada to, I think) the zip code
gets more specific as you go from left to right. So for example, using wildcard
characters, I could allow cash payments from anyone in Lincoln, NE with a single
entry: 685**.
Thoughts?
-Chris
|
No matter what type of payment a buyer selects that buyer can still mail you
cash. All you can do is return the cash if you do not want to accept it. There
is no need to ask Bricklink to check on postal codes if you ask me. I once had
a buyer send me cash. I don't even have that kind of payment as an option.
|
|
| Author: | chetzler | | Posted: | Dec 1, 2016 10:57 | | Subject: | Limit cash payments to approved postal codes | | Viewed: | 137 times | | Topic: | Suggestions | | Status: | Open | | Vote: | [Yes|No] | |
| I just had a buyer from three states away claim that he sent cash in the mail.
While this seems very risky to me, he did indeed select "Cash (no COD)" as a
payment type even though that option states that it is for local pickup only.
Since there is no way to actually enforce local pickup, I didn't realize
this until after he mailed the money, frankly because I've never had anyone
do this before! I accept lots of cash payments from members of my LUG, but it
doesn't usually occur outside of that.
Can we get BrickLink to only accept "Cash" payments on an order if that buyer's
postal code is on a seller-selected list? I don't know how postal codes
work in other countries, but in the US (and Canada to, I think) the zip code
gets more specific as you go from left to right. So for example, using wildcard
characters, I could allow cash payments from anyone in Lincoln, NE with a single
entry: 685**.
Thoughts?
-Chris
|
|
| Author: | paulvdb | | Posted: | Dec 1, 2016 08:53 | | Subject: | Inventory Change Request for Set 70402-1 | | Viewed: | 26 times | | Topic: | Inventories Requests (Entry) | | Status: | Open | |
| Please make changes to the following inventory:
* Change 1 Part Flat Silver {4497u Minifig, Weapon Pike / Spear - Undetermined End to 93789 Minifig, Weapon Pike / Spear - Flat End}
* Change 1 Part Pearl Dark Gray {4497u Minifig, Weapon Pike / Spear - Undetermined End to 93789 Minifig, Weapon Pike / Spear - Flat End}
* Change 1 Part Flat Silver {4497u Minifig, Weapon Pike / Spear - Undetermined End to 93789 Minifig, Weapon Pike / Spear - Flat End} (Extra)
* Change 1 Part Pearl Dark Gray {4497u Minifig, Weapon Pike / Spear - Undetermined End to 93789 Minifig, Weapon Pike / Spear - Flat End} (Extra)
|
|
| Author: | SylvainLS | | Posted: | Nov 30, 2016 18:22 | | Subject: | Re: Tap on thumbnail shows thumbnail - Pointless! | | Viewed: | 43 times | | Topic: | Suggestions | |
| In Suggestions, WoutR writes:
| | […]
I am worried about that integration with the catalog.
I wonder if they thought about the differences between the Bricklink catalog
and other available databases like LDD. We distinguish many mold versions, and
I have not yet seen 3D-models representing those. Also, the Bricklink catalog
groups many colors. That could cause problems for builders. Will the software
contain all parts in the catalog, or only a subset? Which subset and why? What
happens when new parts are added to the catalog, or when existing entries are
split?
|
Stud.io uses LDraw parts for the geometry.
They are presented in the UI under their BrickLink name and ID.
For that, they use a matching table to/from LDraw (for the geometry, for import
and for export) but also LDD (for import only).
Colors are BL colors.
For now, there’re still a few errors when importing from LDraw or LDD. The last
patch corrected some.
The integration with the catalog is that:
* you can know what colors a part is available in (and you’re warned if it isn’t
but you can still paint it as you wish),
* and you can know the price of parts and of your model (current for sale average
new or 6 months for sale average new),
* and their weight and the overall size of your model.
As for what parts are available, only looking at the LDraw file names, they are
LDraw Official + Unofficial + some import from LDD (those that are not in LDraw
yet and don’t use LDraw primitives, about a thousand parts that you can get from
digital-bricks.de).
It doesn’t seem that the LDraw community has been contacted (officially or not).
| | Are the models accurate enough? Will the model software guarantee that bricks
that seem to fit actually do fit without damaging the parts or falling apart?
|
Collision detection is toggable.
For what I’ve experienced, collision data is a bit conservative on some parts.
There’re also errors and missing data.
You can place your parts wherever you want (“snapping” is also toggable when
you place a part).
But, even with collision detection on, there’ll always be errors (as there’re
in LDD).
There’s no physics. Your model may fall apart or be totally unbuildable.
| | Does the software allow "illegal techniques"?
|
As you can place parts anywhere, I’d say they are.
Even if you (as a builder) look at what the collision detection say, there’ll
be errors.
Some could be corrected. Others will be difficult to correct.
The big ones (IMHO) are those using technic holes for SNOT: a technic hole is
higher than a side (anti)stud by 0.12mm.
Note that this illegal technique and others are still in recent official sets.
LDD has the technic hole at 0.2mm higher than a side stud, thus forbidding the
constructions (or you have to play on its tolerances and may end up having parts
“disappeared” the next time you load your model).
LDraw has them at the same place (6541 + 4274 = 87087). So I don’t foresee Stud.io
enforcing that illegality any time soon.
| | There are a lot of practical details that need to be considered, and I really
wonder if they have done that.
|
My opinion is they are going blind, eyes shut. (Using LDraw and not talking to
them? Seriously?)
|
|
| Author: | WoutR | | Posted: | Nov 30, 2016 16:47 | | Subject: | Re: Tap on thumbnail shows thumbnail - Pointless! | | Viewed: | 30 times | | Topic: | Suggestions | |
| In Suggestions, randyf writes:
| | In Suggestions, WoutR writes:
| | LEGO could not get it to work commercially, so let's just take their idea
and try again.
|
It integrates with BrickLink's database, so it may work out just fine. I
like LDD, so I am willing to give Stud.io a chance once it is out of beta as
I believe it will be much easier to buy what you need from it. However, that
all remains to be seen at this point, and I never ever saw something like this
coming and was hoping for much more critical developments (e.g. ***INSTANT CHECKOUT***)
Cheers,
Randy
|
I am worried about that integration with the catalog.
I wonder if they thought about the differences between the Bricklink catalog
and other available databases like LDD. We distinguish many mold versions, and
I have not yet seen 3D-models representing those. Also, the Bricklink catalog
groups many colors. That could cause problems for builders. Will the software
contain all parts in the catalog, or only a subset? Which subset and why? What
happens when new parts are added to the catalog, or when existing entries are
split?
Are the models accurate enough? Will the model software guarantee that bricks
that seem to fit actually do fit without damaging the parts or falling apart?
Does the software allow "illegal techniques"?
There are a lot of practical details that need to be considered, and I really
wonder if they have done that.
|
|
| Author: | SylvainLS | | Posted: | Nov 30, 2016 16:33 | | Subject: | Re: Tap on thumbnail shows thumbnail - Pointless! | | Viewed: | 30 times | | Topic: | Suggestions | |
| In Suggestions, WoutR writes:
| | LEGO could not get it to work commercially, so let's just take their idea
and try again.
|
I think it was not profitable for LEGO because of the cost of picking parts.
BrickLink (’s sellers) already do that (somewhat) profitably.
It’s a good move, in line with the MOC shop.
|
|
| Author: | randyf | | Posted: | Nov 30, 2016 16:30 | | Subject: | Re: Tap on thumbnail shows thumbnail - Pointless! | | Viewed: | 29 times | | Topic: | Suggestions | |
| In Suggestions, WoutR writes:
| | LEGO could not get it to work commercially, so let's just take their idea
and try again.
|
It integrates with BrickLink's database, so it may work out just fine. I
like LDD, so I am willing to give Stud.io a chance once it is out of beta as
I believe it will be much easier to buy what you need from it. However, that
all remains to be seen at this point, and I never ever saw something like this
coming and was hoping for much more critical developments (e.g. ***INSTANT CHECKOUT***)
Cheers,
Randy
|
|
| Author: | WoutR | | Posted: | Nov 30, 2016 16:22 | | Subject: | Re: Tap on thumbnail shows thumbnail - Pointless! | | Viewed: | 24 times | | Topic: | Suggestions | |
| LEGO could not get it to work commercially, so let's just take their idea
and try again.
In Suggestions, tEoS writes:
| | Yea, but we'll be getting BL Studio soon. Nothing like it has ever been
done before and it was certainly the most requested feature from buyers and sellers
alike. 
| | I agree that the setup is not ideal, and it holds out a lot of hope for being
ideal. Something in the interim could have been done, but they did not set it
up that way. I don't know what else to say than I feel your pain and I am
doing a lot of work to make it less painful. With all of the other things needing
to be fixed and developed on this site that are much more important (e.g. instant
checkout, seller inventory tools, settings that don't stick, the awful version
2.0 wanted list changes that are needed, etc.), I don't see them putting
resources into changing this small annoyance anytime soon.
Best regards,
Randy
|
|
|
|
| Author: | tEoS | | Posted: | Nov 30, 2016 16:18 | | Subject: | Re: Tap on thumbnail shows thumbnail - Pointless! | | Viewed: | 21 times | | Topic: | Suggestions | |
| Yea, but we'll be getting BL Studio soon. Nothing like it has ever been
done before and it was certainly the most requested feature from buyers and sellers
alike.
| | I agree that the setup is not ideal, and it holds out a lot of hope for being
ideal. Something in the interim could have been done, but they did not set it
up that way. I don't know what else to say than I feel your pain and I am
doing a lot of work to make it less painful. With all of the other things needing
to be fixed and developed on this site that are much more important (e.g. instant
checkout, seller inventory tools, settings that don't stick, the awful version
2.0 wanted list changes that are needed, etc.), I don't see them putting
resources into changing this small annoyance anytime soon.
Best regards,
Randy
|
|
|
| Author: | WoutR | | Posted: | Nov 30, 2016 16:17 | | Subject: | Re: Tap on thumbnail shows thumbnail - Pointless! | | Viewed: | 21 times | | Topic: | Suggestions | |
| In Suggestions, randyf writes:
| | In Suggestions, WoutR writes:
| | In Suggestions, randyf writes:
| | In Suggestions, WoutR writes:
| | To me, it would make more sense to use the generic large image if the color specific
large image is unavailable. That is a design choice.
|
The high-quality images replace the low-quality images. There is no either/or,
just one image (i.e. no high-quality and low-quality images stored separately).
Therefore, there is only *one* image *per* part *per* color, whether it currently
be low-quality or high-quality. If the code sees a color image for a part for
a color, it grabs the color image unaware of the quality of it. How would it
know to grab the generic large image of the part if a color image *is* available
for that part in that color that you clicked on?
|
Simply use the generic large image if the color image is the 60x80 thumbnail
size.
It is a design choice.
|
Ah, yes. That could be done. I have forgotten much in my years since coding web
pages (12 years ago and counting).
| | | |
| | Every time I open a thumbnail image to see the same thumbnail image, I am annoyed
by what I consider to be another example of sloppy coding. What the designer
intended does not match my user experience.
|
It is annoying *right now* due to the quality of the images. And I think it is
*meant* to be annoying so users will help to move the site to high-quality part
images. I am doing my part to do this.
Cheers,
Randy
|
Thank you for doing your part.
|
You are quite welcome. I am more than happy to help things get better.
| | Did BrickLink ask for help when this new feature was implemented? I might have
missed something, because asking is better than annoying.
|
They received feedback on what would happen if they immediately discarded all
of the old thumbnail images, but they pushed ahead with coding their "ideal"
situation. In other words, we are stuck with this in-between old and ideal outcome.
I will keep working towards the ideal by updating images as I don't believe
they are going to do anything about it with much more pressing issues on hand.
Cheers,
Randy
|
It baffles me that they would even consider discarding all the old images without
having the replacement in place. Sadly, it fits the pattern of what I call "sloppy
design" (I might have other descriptions, but I won't post them here).
|
|
| Author: | altherb | | Posted: | Nov 30, 2016 16:14 | | Subject: | Inventory Change Request for Set 1609-1 | | Viewed: | 27 times | | Topic: | Inventories Requests (Entry) | | Status: | Open | |
| Please make changes to the following inventory:
* Change 1 Part Red {3020 Plate 2 x 4 to 3022 Plate 2 x 2}
|
|
| Author: | randyf | | Posted: | Nov 30, 2016 16:09 | | Subject: | Re: Tap on thumbnail shows thumbnail - Pointless! | | Viewed: | 24 times | | Topic: | Suggestions | |
| In Suggestions, WoutR writes:
| | In Suggestions, randyf writes:
| | In Suggestions, WoutR writes:
| | To me, it would make more sense to use the generic large image if the color specific
large image is unavailable. That is a design choice.
|
The high-quality images replace the low-quality images. There is no either/or,
just one image (i.e. no high-quality and low-quality images stored separately).
Therefore, there is only *one* image *per* part *per* color, whether it currently
be low-quality or high-quality. If the code sees a color image for a part for
a color, it grabs the color image unaware of the quality of it. How would it
know to grab the generic large image of the part if a color image *is* available
for that part in that color that you clicked on?
|
Simply use the generic large image if the color image is the 60x80 thumbnail
size.
It is a design choice.
|
Ah, yes. That could be done. I have forgotten much in my years since coding web
pages (12 years ago and counting).
| | | |
| | Every time I open a thumbnail image to see the same thumbnail image, I am annoyed
by what I consider to be another example of sloppy coding. What the designer
intended does not match my user experience.
|
It is annoying *right now* due to the quality of the images. And I think it is
*meant* to be annoying so users will help to move the site to high-quality part
images. I am doing my part to do this.
Cheers,
Randy
|
Thank you for doing your part.
|
You are quite welcome. I am more than happy to help things get better.
| | Did BrickLink ask for help when this new feature was implemented? I might have
missed something, because asking is better than annoying.
|
They received feedback on what would happen if they immediately discarded all
of the old thumbnail images, but they pushed ahead with coding their "ideal"
situation. In other words, we are stuck with this in-between old and ideal outcome.
I will keep working towards the ideal by updating images as I don't believe
they are going to do anything about it with much more pressing issues on hand.
Cheers,
Randy
|
|
| Author: | randyf | | Posted: | Nov 30, 2016 16:03 | | Subject: | Re: Tap on thumbnail shows thumbnail - Pointless! | | Viewed: | 27 times | | Topic: | Suggestions | |
| In Suggestions, matejo writes:
| | I am not confused, and I am not making sarcastic remarks.
I recognize that the popup window being discussed is likely a new architecture,
however the data for this architecture does not exist, and not surprisingly it
will not exist for a long time.
Thank you for your efforts to create this data.
Presently clicking on a thumbnail, clearly with the intent of attaining larger,
more detailed information, and being directed to the very same thumbnail does
not seem pointless. It is pointless.
BrickLink administrators are placing their utopian vision of what the site should
be, over what the site can be now. And as a result, there are several less efficient
processes under 2.0 compared to 1.0.
In short, these negative process and customer impacts, which can be fixed, are
secondary, tertiary, or whatever to their vision, for long periods of time.
This is simply a fact, as evidenced every single day on the site, and in this
thread.
|
I agree that the setup is not ideal, and it holds out a lot of hope for being
ideal. Something in the interim could have been done, but they did not set it
up that way. I don't know what else to say than I feel your pain and I am
doing a lot of work to make it less painful. With all of the other things needing
to be fixed and developed on this site that are much more important (e.g. instant
checkout, seller inventory tools, settings that don't stick, the awful version
2.0 wanted list changes that are needed, etc.), I don't see them putting
resources into changing this small annoyance anytime soon.
Best regards,
Randy
|
|
| Author: | alahaka | | Posted: | Nov 30, 2016 15:51 | | Subject: | Re: Tap on thumbnail shows thumbnail - Pointless! | | Viewed: | 32 times | | Topic: | Suggestions | |
| I am not confused, and I am not making sarcastic remarks.
I recognize that the popup window being discussed is likely a new architecture,
however the data for this architecture does not exist, and not surprisingly it
will not exist for a long time.
Thank you for your efforts to create this data.
Presently clicking on a thumbnail, clearly with the intent of attaining larger,
more detailed information, and being directed to the very same thumbnail does
not seem pointless. It is pointless.
BrickLink administrators are placing their utopian vision of what the site should
be, over what the site can be now. And as a result, there are several less efficient
processes under 2.0 compared to 1.0.
In short, these negative process and customer impacts, which can be fixed, are
secondary, tertiary, or whatever to their vision, for long periods of time.
This is simply a fact, as evidenced every single day on the site, and in this
thread.
|
|
| Author: | WoutR | | Posted: | Nov 30, 2016 15:45 | | Subject: | Re: Tap on thumbnail shows thumbnail - Pointless! | | Viewed: | 21 times | | Topic: | Suggestions | |
| In Suggestions, randyf writes:
| | In Suggestions, WoutR writes:
| | To me, it would make more sense to use the generic large image if the color specific
large image is unavailable. That is a design choice.
|
The high-quality images replace the low-quality images. There is no either/or,
just one image (i.e. no high-quality and low-quality images stored separately).
Therefore, there is only *one* image *per* part *per* color, whether it currently
be low-quality or high-quality. If the code sees a color image for a part for
a color, it grabs the color image unaware of the quality of it. How would it
know to grab the generic large image of the part if a color image *is* available
for that part in that color that you clicked on?
|
Simply use the generic large image if the color image is the 60x80 thumbnail
size.
It is a design choice.
| |
| | Every time I open a thumbnail image to see the same thumbnail image, I am annoyed
by what I consider to be another example of sloppy coding. What the designer
intended does not match my user experience.
|
It is annoying *right now* due to the quality of the images. And I think it is
*meant* to be annoying so users will help to move the site to high-quality part
images. I am doing my part to do this.
Cheers,
Randy
|
Thank you for doing your part.
Did BrickLink ask for help when this new feature was implemented? I might have
missed something, because asking is better than annoying.
|
|
| Author: | randyf | | Posted: | Nov 30, 2016 15:01 | | Subject: | Re: Tap on thumbnail shows thumbnail - Pointless! | | Viewed: | 26 times | | Topic: | Suggestions | |
| In Suggestions, therobo writes:
| | In Suggestions, randyf writes:
| | In Suggestions, WoutR writes:
| | To me, it would make more sense to use the generic large image if the color specific
large image is unavailable. That is a design choice.
|
The high-quality images replace the low-quality images. There is no either/or,
just one image (i.e. no high-quality and low-quality images stored separately).
Therefore, there is only *one* image *per* part *per* color, whether it currently
be low-quality or high-quality. If the code sees a color image for a part for
a color, it grabs the color image unaware of the quality of it. How would it
know to grab the generic large image of the part if a color image *is* available
for that part in that color that you clicked on?
| | Every time I open a thumbnail image to see the same thumbnail image, I am annoyed
by what I consider to be another example of sloppy coding. What the designer
intended does not match my user experience.
|
It is annoying *right now* due to the quality of the images. And I think it is
*meant* to be annoying so users will help to move the site to high-quality part
images. I am doing my part to do this.
Cheers,
Randy
|
As a sidenote, these new images are better but still not really "High-Quality".
Even if you improve the quality (color, contrast) of the images grabbed from
the Lego Server, their size still remains 192x192, regardless if you fill them
into a 320x240 blank space (you) or if you just upload them in 192x192 size (Jen).
|
Yes, not "high-quality" in the "high-resolution" sense, but much better than
80x60px poorly rendered thumbnails.
Cheers,
Randy
|
|
Next Page: 5 More | 10 More | 25 More | 50 More | 100 More
|
