Development and improvements are entirely different than adapting extensions developed by someone outside their company. Not at all something any company would consider daily.
That’s where you’re wrong. Sure, some decisions are daily operations and some are long-term planning, but product development is product development–regardless of what flavor it is. I’m talking about choices made at the highest level about where you’re going with your product. That’s where all that’s right and wrong with your planning comes to a head. That’s where the ultimate calculus takes place about where to go with your product to retain existing users and attract new ones. You can’t look at whether to develop your own extensions, fix bugs, or improve performance as isolated silos that don’t affect each other.
Every company has finite resources and has to choose it’s path wisely while examining all options simultaneously. The company leadership has (or should have) a clear vision and defined goals that guide their day to day operations. They should have revenue and cost projections under multiple financial scenarios and product development choices. Ultimately, bug fixes, improvements, and new feature development are all paid for out of the same pot. Different departments will have their own unique objectives, but each must serve a cohesive and compelling vision for the product.
No I’m not. You think acquiring another developers plugin is the same as internal development? That’s just a tad naive. Far too many factors for outside acquisition…determining which plug-in to incorporate, acquiring the rights assuming the developer wants to, then implementing it into the UI.
Considering SU was recently polled as one of the top softwares in the architectural community, their road map appears on pace.
I know I’m not the only one that would be disappointed to see SU and LO become some bloated 3D program like Autodesk has implemented…and let’s not even bring up that cost.
So I guess we just have to agree to disagree.
I’ve run companies for 40 years–I’m not new to this. First of all, you said “acquire” other developers’ plugins. That’s only one option. And while operationally it is different than building something in house, that’s beside the point to the end user and is just another corporate decision.
You also keep harping on cost and bloat while ignoring observations by myself and others that point to ways of managing both. I like SU, too, but no company can afford to sit back and pat themselves on the back because of a poll. Polls are a snapshot in time. I’ve been around long enough to see many beloved professional products swiftly abandoned when an unexpected competitor turns the tables. Keep your eye on the rearview mirror–somewhere back there is likely an unseen hotshot closing fast. Not recognizing that reality is naive.
The more I think about it, the more I agree with the “keep it simple” approach.
Some base-operations are so native to my work-flow (like Fredo-Scales “Box-Stretching-to-Target”) that I think they might be worthwhile incorporating in the basic program.
What does make it more tricky nowadays are the two “non-desktop-versions” that don’t support extensions - so this must be solved: If Sketchup-Web und Sketchup-iPad won’t support extension ALOT needs to be done natively to enable an easier “semi-pro” workflow. IF extensions are incorporated in these two versions than we can all relax a bit.
So my wishlist would be:
- Speed, speed, speed, speed, speed
- Layout: speed
- massive import/export improvements (inkl. native STP support)
- Layout: extensions support (would solve a million problems)
- Section fills with multiple fillings
- More possibilities to fiddle with Layout-Viewport-Settings (like changing the style of individual tags, etc - this way one wouldn’t need to do so much view-port-stacking. Vectorworks has done a great job on this - it may be worthwhile borrowing a some of their ideas)
- Possibility to add a radius-measurement to an arc or circle in Layout.
- did I mention speed?
Please, please, please make LO faster. It has been dreadful on my iMac. Soul crushingly slow for some projects.
And make the LO tools work like native SKP tools. the UX is dreadful in LO, especially when one moves back and forth between the two multiple times a day.
Couldn’t have said it better, particularly the soul crushing bit. The UI runs like molasses, constant beach-balling. Parts of the UX have not been thought through & the ‘oven mitt’ selection behaviour is baffling.
Still makes lovely drawings through.
The problem with paid extension bundles is even within a given industry there is a wide variety of methods and creative pathways. If you get 5 designers together over drinks (as I often do) you will likely get 5 different answers to just about everything, including which extensions to include.
I’m not saying “never change SketchUp” it’s not perfect and I’m glad there is a thoughtful conversation about improving it. But it’s pretty awesome, so let’s be careful not to mess it up either. I don’t think development should be steered toward any specific industry. I do think there is some low hanging fruit that SketchUp could incorporate in a similar way to how weld was so beneficially added. Simple things to improve the way existing systems flow.
Auto-invisible layer ON/OFF
Demo Tag/Layer by components definition
rotate plan view
Of course there are many other fantastic more complex Extensions that I use every day, and I admit, I would be very hard pressed to achieve my work with only the native SketchUp toolset. But I like building my own set of tools, and not buying packaged collections off the shelf. I pay for the capabilities I want and I don’t pay for the ones I don’t need, and I don’t want to push my preferred collections of extension on anyone else. It’s this flexibility to use SketchUp in ones own unique way that is one of it’s greatest strengths. Through unique methodology, comes unique work.
Yes it would certainly involve some difficult decisions and compromises. Trimble must have stats on how many active pro users are using X extensions already. Plus most of the top extension developers now work at Trimble so perhaps that’s also a place to start?
Sandbox, Weld, Dynamic Components, and Advanced Camera Tools were added.
I’d add Face Creator, SubD, Upright Extruder, DropGC, Selection Toys…?
All easy functions to integrate (and not just for archiects’ benefit
I’d love to see optional native Toolbar buttons for these. @thomthom I’d also like to see Selection Toys updated from “Select All on selected Layers” to Tags…feel like I may be waiting some time for this…
These are the top 9 extensions currently shown to me under the category “Architecture”
Several aren’t in English. Some are really are nothing to do with Architecture. One doesn’t work at all (store page is dead). At least one is a 99% duplicate of a different extension. One (Simlab DWG importer) is redundant unless you are using Make 2017.
If I were Trimble, that dependence on 3rd party extensions would worry me. We’ve heard from some in this thread who proudly claim to only use the native toolset. But from a business perspective, would Sketchup survive with only those users? My takeaway from this discussion is that most feel the native tool set is pretty stripped down, and 3rd party extensions are critical to their work. It’s not a question of how much you use a particular plugin, it’s a matter of whether it is necessary in your work.
If I was top dog at Trimble, I’d want to make sure my vision for the company wasn’t too dependent on these 3rd party extensions. Sure, it’s great that SU can be customized with creative new tools from others, but it’s a matter of striking the right balance. 3rd party extensions are vulnerable to code changes, and SU may even be reluctant to make sweeping changes out of fear of disabling key extensions. That’s a trap. Furthermore, using these extensions can make SU feel more complicated due to their different UI’s and sometimes minimal instructions. This is not how you optimize and shape the user experience and control your destiny.
I don’t think that SU should try to acquire or duplicate all the top 3rd party tools out there, but I do think they would be wise to beef up their tool set with the key tools most often needed by their core users. Addressing performance issues seems to be of at least equal or greater importance (depending on who you ask). These priorities need to be addressed and there needs to be user confidence in the vision. Seems to me that this thread is evidence that SU’s vision and plans are not well understood, which creates uncertainty, which is never good for a business when there are a growing number of contenders in the market.
Yes, I can’t bring myself to entertain going back to DWGs or anything else. The ability to make lovely presentation and construction drawings from SKP is too powerful, but there are times I think I could export and assemble drawings in Photoshop or Infinity Designer faster (I probably can’t - but I spend no time waiting around for things to zoom or beachball in those apps…)
Would love to have a native way to control layer visibility when you already have 20-30 scenes created. Currently working on a project that doesn’t fit into my normal workflow and layer + scene management is tedious. I know how to quickly get through my scenes and update and change - but the more detail I add to a building that was handed to my by another architect, the more I see a need for better layer + scene control in SKP.
And also in LO. I would love a ‘copy style’ option for SKP viewports - sometimes I don’t really want to blast through 40 pages and reset line styles, dash styles and etc. when my client tells me that their printer isn’t handling how my template is outputting on their end.
Same goes for layer visibility. Visible on and off per page is great - but can we add a global on and off? Especially considering we have ‘on every page’ - but I need to manually go through the document to turn some of them on and off.
Regarding your image meme - yes! I have done buildings, structural drawings, softwoods (backpacks and small bags), furniture, and recently some Airstream plans. Different tools for different jobs, for sure. Having a rock solid toolset for the basics is key, with plugins available for the specialty work.
I do have an experimental extension here you may try:
The main goal is to be able to change “every possible visibility” from scene to scene — even bulk at once — without having to go through, modify, and update each scene manually.
(Currently it is “neglected” due to my other personal occupations… )
Good for you on 40 years! Not sure why that matters here.
I mention acquiring other developers plug-ins because that is exactly the discussion. Look at the tools people are wanting. Or are you implying they develop their own plug-ins that do the same thing? That would be a pretty poor business decision from a legal perspective. I also think you have the “relying on 3rd party development” reversed. It’s the other way around.
My point in cost has more to do with the constant complaining you see here in our microcosm of users that blew a gasket when SketchUp went to subscription for a whopping $299/yr.
Also for those commenting on SU for architecture, I am well aware the user base has far more depth. I’ve been using it long enough and attended enough basecamp events to know that. I’m an architect so I speak from my perspective of use.
I’d much rather see the SU team focus on increased performance, specifically in LO, than go in a direction of expanding the toolset in SU.
Yes, more of this please. And wish I could make it to another BaseCamp and share a beer with you Nick… but I’m so so far away these days. Perhaps if it makes it closer to the East Coast next time around.
Will have a look… thanks.
Thanks for the reminder. I forgot about that.
I was going to say that, although the Scene manager is quite a useful Swiss Army knife of control, it may be over taxed now. First, of course, we need better management of massive numbers of scenes. While it can be used to control just tag visibility, and leaving other properties alone, I wonder if it’s time for Tags to get their own separate “Saved Tag Sets” control, and it’s being driven by Layout. It’s no real problem to use scenes in SU to get mix and match both a camera view (one click) and a set of visible Tags (second click) to cycle through multiple views and multiple design options. The problem is in Layout where you pick your saved scene for the viewport, and you can only choose one scene. Yes, you can manually override the tag settings, but that defeats the efficiency of having saved Tag visibility sets. Wouldn’t it be helpful for a view port in LO to have the existing pull-down men for scene selection plus a new, separate pull-down menu for Tag visibility set?
@dezmo 's Matrix seems to try to address this two dimensional matrix of combinations of Tag visibility and Camera or other property, yes?
That would be great. Many of my scenes are created just to control tag visibility. A saved tag set seems like it would be quicker, easier, and use less system resources.
Just curious on how often you folks would need to constantly update tags per scene?
I rarely have the need for that as my templates already have the scenes set with the required tag visibility preset. The only thing I typically adjust in scenes are the camera view, shadows and fog.
For detailing which tend to have a different tag structure, nesting groups in a tag hierarchy allows you to toggle on and off multiple entities with different tags in a single click.