The Extension Warehouse Needs Some Love

Extension Warehouse
1

It’s long past time but I think the Extension Warehouse needs some love. The 3D Warehouse seems to get continual attention but not the Extension Warehouse.

The Free indication for extensions that aren’t free needs to be removed or changed.

It needs to be made more clear to users when non-free extensions are purchased directly from the author or outside source instead of directly through the Extension Warehouse. Maybe that “Free” button should be changed to say something like “Go to the author’s site to get this extension.”

It needs to be possible for users to release extension licenses for old versions of SketchUp and old devices. We shouldn’t have to rely on @colin to release them for us.

Maybe the images on the extension pages could be made smaller and the descriptions and usage text could be made larger.

Some authors include usage information in their descriptions–what to look for in which menu but not all authors seem to do that. Maybe that should be required information in order for an extension to be published.

None of this seems to me to be particularly difficult.

30 Likes
2

You have my vote Dave, all great suggestions.

4 Likes
3

I agree on all points!
I would perhaps add that the associated - outdated picture illustrated, help page would also be a good idea to update.

6 Likes
4

When extensions are approved after submission the next required step in the email notification is to publish the extension. In my opinion there should be an option to download approved extensions without publishing them. I just learned that the EW encryption/signing process can break extensions (edit: this isn’t correct. see follow-up post). Although it is the responsibility of the person submitting extensions to make sure they work, it ‘seems’ implied that approved and returned, encrypted and signed extensions would work. The work around, for now, is to: publish → download → unpublish → test → publish or resubmit.

I believe part of the issue with free vs. paid extensions on EW is that if one becomes a vendor, they are becoming a vendor with Trimble/EW. I can understand EW only having free and paid (Try or Purchase / Install) options because that’s what they do. I think the Try or Purchase option is clear. But some ‘vendors’ will want to do their own selling. They can’t select ‘paid’ because that’s for selling as a vendor with Trimble/EW. I think that’s the case with the extension that was recently highlighted in another thread. My impression was that they did a good job (working with the available options) by adding their own links stating that the extension is not free in the description.

So, what is the solution? Should the “Free” button link shown on search results be changed to “Free”, “View” or “Listing Page”?

There could be another button option (a categorization option when uploading extensions) in the EW extension specific page. It could be a “See Description” button label option. Basically, that button would behave like the existing “Price / Free / Install” button allowing users to download (and would require the least amount of change because only the label “Free” would be changed to “See Description” and search results would show “View”). The labels could be “Price / See Description / Install”. If the extension description omits that information, users can reject it for that reason if they wish. The extension developer can then specify how they want (Free Trail, Subscription, License, Donate, add links, etc.). The solution needs to put the onus on the developer and not create additional work in the future for EW team. Some developers might abuse this and list as “Free” when they ought to select “See Description”. But the benefit is that ALL existing “Free” extensions would not have to be recategorized as either Free or See Description by the EW team and all developers would be able to do so (at their leisure, which solves the ‘herding cats’ problem).

Should there be mutually exclusive “Free” and “Trial” tags? Search filters?

Just to note, there is an option (Listing Page) to add something like:

That one just doesn’t quite capture the sellers who want to cut Trimble out of the deal and don’t have a website.

How do we get Trimble to add the elusive EW universal buttons of love? :slight_smile:

1 Like
5

Also, needed is a new timestamp integer line in the "extension_info.txt" file, so that versions can be better compared. Currently the EW and Extension Manager can only tell when there is a difference, not that the one we have installed is newer or older than what is in the EW.

…

:+1: I just cannot imagine why there was not a “Trial” choice to begin with.

Thise are the extensions that have this problem. I was always against these Listing pages as it puts the cost of advertising on the “little guys” who sell through the EW.

(Off-topic): Signing & Encryption breaks extensions ... [ click to expand ]

Sorry, J.D., I must disagree with ya’ here. The SketchUp Ruby API documentation is quite clear in the use of Sketchup::require. So it isn’t the encryption breaking the extension.

The signing and encryption step does not test or “approve” the extension. Even extensions that will be hosted elsewhere can run their RBZs through this signing process. I’ve done it for free extensions that I’ve only posted in the forums or have hosted on SketchUcation.

:face_with_raised_eyebrow:
But the signing process returns a signed and (optionally) encrypted RBZ. I’ve done it many times.

Get your returned RBZ and install it locally to test how it loads from encrypted code before submitting it to the EW for publication.

ADDENDUM (Also sent via private message)

What you may be missing is that there are two workflows.

What I do when I wish to only sign (and optionally encrypt) a RBZ is I go to the Signing Portal: https://extensions.sketchup.com/extension/sign and click the blue Sign Extension button.
It will ask if you wish to have the extension code rb files encrypted to rbe format. (You decide)
This portal immediately returns the RBZ using the same name as it was uploaded but with a signature certificate and the appropriate files encrypted (if you chose that option.) The new RBZ will likely be downloaded to your Downloads folder.
This workflow does not check the extension using Rubocop for SketchUp nor is it examined by the SketchUp Extensibility Team in any way.

Be careful not to comingle unsigned RBZs from the signed and encrypted ones. I keep them in separate folders myself.

Anyway, this workflow is separate and distinct from the EW submission process. It is explained in the first paragraph of the following Help Center page.
The Extension Warehouse Submission process is explained in the last paragraph (and bulleted list) of this linked page.

Extension Warehouse User Guide: Extension Signing and Encryption

3 Likes
6

Thanks Dan for taking a look at my comments. I want to take this opportunity to clarify a few things I wrote, what I understand the processes to be, and what you may have identified as my mistakes along the way.

Sorry, J.D., I must disagree with ya’ here. The SketchUp Ruby API documentation is quite clear in the use of Sketchup::require. So it isn’t the encryption breaking the extension.

Taking the example of the Make Group and Tag extension I submitted:

It loads and works on my computer. My usual way of working on any extension is not to install it using the Extension Manager. Generally, I have a file (extension_name.rb) that I move in and out from the extension folder (extension_name) or rename to have the extension load or not load. In the case that I might have zipped or unzipped an extension folder (for whatever reason), I didn’t change the file extension to .rbz and use the Extension Manager.
ERROR: The unchanged files, packaged together as a ZIP and re-named .rbz fails to install using the Extension Manager. This is what I FAILED TO TEST BEFORE uploading to the Extension Warehouse. When I renamed the ZIP to .rbz, I broke it. I’m going to edit my incorrect statement about EW above.

The solution was pointed out to me by Dezmo (Requirements Cops - RuboCop SketchUp: SketchUp Extension Best Practices). To belabor the point a bit. The two reasons .rb was there are that 1) It works! And 2) It’s easier for me to see that a file is needed when .rb is there. So that’s how it ended up in my extension template and is now propagated in every extension I have.

The signing and encryption step does not test or “approve” the extension. Even extensions that will be hosted elsewhere can run their RBZs through this signing process.

The reason I used that terminology is that the email I received from EW used it: [Extension Warehouse] Your Extension Has Been APPROVED - Action is Required!

I don’t know that they “test” submitted extensions. But I don’t know what else to call it. I presume that someone in EW received the .rbz, changed it back to ZIP and unpacked it. That would explain why it ‘worked’ for them. I’m also presuming the code was looked at and someone did a ‘does it do what it says it does’ check in SU. Had they taken the submitted .rbz and tried to install it using the Extension Manager, it would have failed for them (as it would have for me had I tried installing my .rbz before submitting as I should have done) and it would have been rejected. Even though I submitted a doomed extension, I think it was reasonable -though mistaken- that I concluded encryption broke the extension.

Get your returned RBZ and install it locally to test how it loads from encrypted code before submitting it to the EW for publication.

The reason I published was that step was indicated in the approval email:

Action Required! You need to publish it by going to your My Extensions page and selecting the extension from the “Approved Extensions” list and clicking the “Publish” button from the drop down menu.

It seemed like a good idea at the time! But also, unless I just can’t find the download option, publishing to EW and downloading is the only way I see in the EW My Extensions or My Downloads sections. I don’t see any option with Unpublished Extensions other than “Publish Extension”. Unless there’s another option to download, it seems publish → download → unpublish → test → publish is the way to do it.

Anyway, it seems my mistake slipped through the cracks. “All errors are the authors’ alone” and apologies to anyone at the EW who may have seen my misattributed mistake.

On top of having the air go out of my tires right when I was going to ‘hit the big jump’ and have an extension in EW, it’s embarrassing to have to go back over what happened. Hopefully this reply is useful to others who can now avoid these mistakes. But I’m not going to stop using IDK_Programming as that name still seems appropriate. :wink:

1 Like
7

If I may chime in here - from a users point of view! Buying anything from the extension warehouse is a pain. I would buy MANY more extensions from here, if the setup would be better.

  1. Trimble has my payment data from my regular subscription - why do I need to always go through this tedious (and often not working) checkout process?
  2. I cannot (last I tried) get a proper bill of the extensions you buy here. So how do I deduct this as company expenses?
  3. Why can’t I manage my purchased extensions from my Trimble-Account?
  4. Why isn’t the licensing tied to my Pro License user-account? After installing Sketchup 2025 my Eneroth Replace Components extensions doesn’t work any more - licensing issues. No hint of how to solve it either. This should not be an issue AT ALL if Sketchup has already checked out my Pro Licences
  5. We have 14 Sketchup Pro Licenses. I can manage them very nicely, assigning or unassigning users to them (there is always some fluctuation in the team-setup). But what happens to extension licenses that I bought for employeeXYZ@… when that user leaves the company and I reassign the Sketchup Pro license to employeeABZ@… ? Do the Extension licenses just disappear? I don’t know…

I think many extension developers set up their own payment system, because the native one is broken at best.

8 Likes
8

According to my moral standard, this is the most urgent problem to be solved:

I understand that it may not be technically possible to solve this quickly. As a temporary compromise, I could accept something like this:
Until we can clearly distinguish between non-free and free, I suggest that every extension that has “Free” next to the Price tag include a banner at the top:

[Please note that my mother never spoke English to me. Feel free to correct any grammatical or spelling errors.] Or have a native English speaker write it so that it’s clear to everyone.

Warning!
Extension Warehouse lists all extensions that are not sold on Extension Warehouse as “free”.
Please carefully review the extension description and any associated links for details, as these may contain information about additional fees or usage restrictions!
In case of unclarity, please contant to the developer of the Extension of question directly [Contact Developer] button, or report to us directly [link to contact form]

Example draft:

image
image1197×1056 344 KB

3 Likes
9

I would say that it is a simple change. But as Chris said (some 5 years ago now,) it just is not high priority enough. I think that each cycle the product managers and other marketing types have the most sway and new “sexy” features always get the highest priority, pushing the mere housekeeping chores down the list.

It “blows my mind” that this is a legal issue and that it has been procrastinated about for going on 12 years. Don’t forget that the Extension Warehouse debuted with the SketchUp 2013 release. It has gone through several redesigns but this mislabeling “can has just been kicked down the road” again and again.

And this would just be another mislabeling and scare off clueless users from downloading or installing actual free extensions.

The EW backend should be quite able to know what listing pages are and a simple JavaScript function could replace the word “Free” with something else like “Trial”, “Demo” or “Commercial Link”.

My latest pet peeve for the latest design quirk in the Extension Warehouse is that I can no longer just look at an extension’s store page and immediately see what version is hosted.
They’ve now hidden the extension version on a subtab of the page. (I’ve got arthritis in my hands and have suffered from carpel and tendinitis in the past.) Adding clicks to an interface is not good UX design folks!

4 Likes
10

Good to read you.

And what about the home page with both lists Featured Extensions and Top Extensions that never really change. There’s no challenge for developpers there.

A special note for the Top Extensions which are sorted by number of views whereas now it is the number of downloads which is displayed…

About the price tags “Free”, “Trial”, “Paid”… where to put extensions with donations :wink: ?

8 Likes
11

Well, I wrote a long post that was far from devoid of emotion, but I won’t publish it because it might hurt the feelings of others. Let’s just say that I agree with you, and:

My opinion is that extensions (so, EW) are one of the wheels on a Sketchup vehicle. Tightening the wheel bolts is more important, or just as important, as sometimes changing the tire.

9 Likes
12

Yes, exactly my experience as a manager of a team… have been asking for those features for years.
These days I’m extremely reluctant to pay for any extension. Too many lost extensions, or ones that never work out for various reasons (ie becoming obsolete or just not workign right).

For a professional firm like ours the process to research, test, validate, roll out, document, make payment for, and maintain a single extension worth $10 is costing us $2000 in our labour/admin cost. We need to get the admin side down…bundling with subscription payments just makes sense.

You should see our IT Team’s response when I say I want them to give the company credit card details to some random website and then download their unverified data to our company servers.

The Extension Warehouse needs to become the Extension STORE

3 Likes
13

Agree. Trimble should take a page from the Apple / Android playbook and make it easier to vet, buy and update extensions.

2 Likes
14

Exactly!

Basically - when I want an extension from the warehouse my - I pay with my private credit card. When one of my employees wants one, I tell them to do the same and give them the money from my pocket. It’s easier for me then to figure out of how to get this through accounting. But that also means - only 10€ extensions. Nothing fancy from the store. Basically what I would want as a company manager is to purchase extensions from my main trimble company account - like 14x Eneroth Replace Componants - one bill. Done. And then I can assign them to my users.

5 Likes
16

Please open a new topic for that, because this topic is about something completely different.

17

Quick update. A couple of extensions with the error discussed above were denied. That’s a pretty good sign the extensibility team does watch the forum and does make changes/improvements when they can.

18

Can you please elaborate winch one with witch error, and what exactly the “denied” means?

19

Yes. First just to make sure you have the context… I submitted 4 extensions at the same time with the same problem. 2 of them were “Approved”. Those are the ones you’re aware of: you pointed out the information I needed. There’s an email response for each submitted extension… So, I received emails about the other extensions stating that they are “DENIED” (yesterday). There’s a reviewer comment that:

Rejection: Load error. By default Extension Warehouse encrypts extensions and convert .rb files to .rbe files. To load these files, use SketchUp’s own SketchUp.require instead of Ruby’s require, and omit the file extension. Also omit the file extension when creating the SketchupExtension object.

The comments in other emails were similar. So, because 2 were “Approved” but they actually had the error and then the other 2 were later rejected I presume they first unzipped the .rbz files and the extensions worked for them. But the returned .rbz files that I published did not work! Just a guess that they saw comments here (or maybe in my resubmitted versions) and they then tried to load using the Extension Manager. That’s the little ‘loop hole’ that may have let those extensions through.

Regardless, they were correctly rejected and that’s a good thing. Thanks to Dan too, he pointed me at the extension signing portal so I could make testing versions before submitting.

20

Thanks! Sounds like good news…
However as most of the users - who have no dev account -cant see this… so fingers crossed, if they really start doing things, or just two different person judged your extension.
I’m still a little sceptical, but I’ll be the happiest if I’m wrong about this. :slight_smile:

1 Like