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.

31 Likes
2

You have my vote Dave, all great suggestions.

4 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
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
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
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.

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.

21

Normally, they test by running Rubocop with a SketchUp specific gem installed that has rules that apply to both good coding practice and API etiquette in a shared environment.

The rule for proper use of Sketchup::require should is already be in the ruleset.

So it may be that someone was in a hurry and did not run Rubocop on the first two submissions.

* Note that the Sketchup module is spelled incorrectly in the email quote.

22

Hi Everyone,
Thank you very much for all the comments and suggestions in this thread.
Extension Warehouse completed a painful but necessary code-base refactor over the past couple of years, a program that was completed late 2024. This also involved new e-commerce systems. Most of the improvements will probably not be noticed but were important for us in getting the system up to scratch.
Last year we hired a developer advocate (many of you will have met him) who is constantly soliciting feedback from the developer community.
This year the Extension Warehouse development team has increased in size and we are processing a pile of requests to improve the platform. It’s great for you to share requests here and we are taking note of what customers report as painful aspects of that feature. If you run into issues using it I would encourage you to report them on the forum or in support tickets. We want to fix them.
One of our core priorities is to support the sale of extensions as subscriptions, the absence of which is a major blocker to most developers looking to sell via the warehouse.
In short we’re committed to making Extension Warehouse the best place to find and purchase extensions. We know we have a lot to do but please be assured we are very actively working on improvements.
best regards
Andrew

6 Likes
23

To begin with a little humor, or horror, depending on how you look at it:

“RunCounterSU”: 4406

I don’t use much of a development environment or even a reload method. When I was setting up, I saw much hubbub about the debugging not working and the Peng Lv VS Code plugin was deprecated. Same with RuboCop. I looked around, saw that there were issues, and passed. So, from my side I ought to have caught the issue and will now look again at installing RuboCop.

At the end of the day, they got it right. I don’t know what happens in the ‘black box’ of the Extension Warehouse/SketchUp/Trimble. I see what, IMO, are valid critiques of SketchUp -removing/moving release notes, inability to set extension icons for the Extension Manager, etc. – but there are also those criticisms/inferences that seem less well-supported. The one I disagree with the most is the general claim, variously expressed as: ‘they don’t give a hoot!’. Not that you are in that camp. Maybe I’m giving too much benefit of the doubt to the back box? :slight_smile:

1 Like
24

On the overall topic of the EW needs a little love:

  1. Turnaround time for extension submission to approval/rejection. I’d heard it could take a while (someone mentioned over a month) and that’s a primary reason I didn’t submit anything until recently. A follow-on catch, (that I’d shared with SketchUp when they sent out one of their feedback questionnaires), is that if a bug is found, the developer can be responsive and fix it immediately, but the review might take however long. That could create the appearance that a developer is non-responsive when they are.

  2. Vendor status. When applying to be a developer with EW, the option to become a vendor requires business information. In my case I have a business, but extensions are outside the scope of what’s included in that. So, during the sign-up process, I stopped. It raised questions in my mind as to whether I would be a sole proprietor, need to submit a DBA in my state for ‘Biz Name’, start a registered LLC, etc. Turns out I was registered as a developer anyway. Which is fine (probably good and all I need for now). But if one can be a vendor without submitting business info, that should be disambiguated in the sign-up process. For example, if one can ‘decide later’ it would be good to know that a business domain isn’t required. The reason to be picky about this is that the ‘sole proprietor’ option is the lowest bar to entry. It encourages people to ‘give it a shot’. If they learn that no one will pay for their extension they can switch the extension to free and there’s no overhead (as there is for LLC or even to a lesser extent DBA). Incorporated dev companies aren’t going to have an issue here and can go the Listing Page route anyway.

  3. Donations. Should this be included? If so, just under “Free” (with “Free” button)? If Trimble ‘takes a cut’ then we’re back to more of a vendor model and it would create overhead for Trimble if they used pages that emulate the features of gumroad or lemonsqueezy. If donations are accepted, should those extensions have Listing Pages? It’s my impression that Listing Pages are somewhat discouraged and that they are intended for paid extensions. A simple solution would be to add an “Accept Donations” toggle that can be switched on in EW for individual extensions in “Extension Details” tab. When activated it accepts a url and displays it under the “Description” field, as a sort of footer. Could be PayPal, a website, whatever. That’s basically how some developers do it now by adding their own links. If donations are accepted, the extension is free so the “Free” button stays the same. Aside from setup, it wouldn’t create additional work for the extensibility team.

  4. Trial option. With another toggle, “Trial”, under Extension Details (because Try or Purchase is an option for Trimble Vendors in the “Pricing & Support tab” and those options display the price on the button) paid and free extensions by non-Trimble partner ‘vendors’ could be sorted. The Trial option would change the button from “Free” to “Trial”. Trimble puts the option out there and is then ‘hands off’ and the issue of non-Trimble partner vendors misleading people is resolved.

2 Likes
26

I replied to the feedback near the end of the most recent “rebuild”. The feedback was opened “late in the game” when the interface had already been finalized.

This rebuild (as I recall) came as a surprise and Labs participants did not have the opportunity to restress the issues that we had the most challenges with before the rebuild.

I also am destressed to see that three aspects of the EW are either still present or went backward.

  1. The extension version number has been removed from the extension store page proper and now hidden on one the “Release Notes” subtabs. This causes wasted time and more clicks to get at the answer as to “What version is hosted on the EW?”

  2. The extension_info.txt file stills lacks a timestamp (integer seconds since the start of the epoch) entry that can be better used to determine whether the RBZ hosted is actually newer than what is installed in SketchUp.

  3. The splash image with the centered search bar at the top of the landing page takes up too much space. (I gave y’all this feedback during the late “rebuild” on the 3DW and it has the same problem.)
    I have a UHD display at 150% scaling and this splash image takes up half of the vertical space! (We must have the option to collapse this splash div to only the search bar at the top of the page. Same for the 3DW!)
    And of what is the splash image? Perhaps a wavy ceiling? What does this have to do with an extensions store?

Except that successive Trimble employees have been saying this for twelve years since the EW first went live in 2013.

Again … 12 YEARS …

What is different now that will make us not think that this is just more virtue signaling from the SketchUp team?

1 Like
27

I see this mismatch too. The version number is in the [Edit Extension] → Extension File Tab along with Release Notes. But in EW, Version is under the Extension Overview tab and there is a separate Release Notes tab.

The Extension Overview tab in EW seems fine to me and the layout above is ‘cleaner’ without version, but a small display under the title or next or under the “SketchUp Compatibility” field would put that information out front.

e.g.,

SketchUp Compatibility (v 1.0.1)
SketchUp 2024, SketchUp 2023, SketchUp 2022, SketchUp 2021

or,

SketchUp Compatibility
(v 1.0.1)
SketchUp 2024, SketchUp 2023, SketchUp 2022, SketchUp 2021

1 Like
28

The version number was previously on the front page in the righthand column. I did not have to go searching for it.

I have arthritis and have in the past suffered from tendinitis in my right arm due to excessive mouse clicking (like 50+ hours a week using AutoCAD.)

Adding mouse clicks is poor UX design, in my opinion.

1 Like