Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Responsiveness to user input - formative period ?
andrew_troup
Member, Mentor Posts: 1,584 ✭✭✭✭✭
in General
Has it occurred to anyone else that there is a natural arc to this, and that this may be the "Golden Era" phase with regard to Onshape?
I have a number of issues, for instance, with Chromebooks and Google Docs ... but I don't kid myself I would get anywhere, as an individual, trying to get these improved.
In a couple of cases I think these are burning issues which must bug a lot of users. To give one example: the actions available for a document discovered using "Recent" do not include deleting that document (a minor irritant) nor discovering where the document lives (a major one).
I can only assume that the dilution effect (whether perceived or real) means that, like me, some users are refraining from suggestion ... and perhaps others are making suggestions which get drowned in the ocean of input, much presumably of doubtful applicability.
As often happens, what is technologically possible is trumped by what is socially achievable.
And sometimes the wisdom of small crowds - especially if they share some sense of common purpose -- might exceed that of large ones.
I hesitate to draw any conclusions for others, but for me, this thought experiment does emphasise the current importance of thoughtful, rather than reactive, (aka 'knee-jerk') input, because it is currently being taken about as seriously as input ever gets taken, and -- realistically -- that state of affairs is probably not going to last forever ... nor could it.
As the Jesuits used to say, on the topic of the so-called formative years: "Give me the child, and I'll give you the man"
I have a number of issues, for instance, with Chromebooks and Google Docs ... but I don't kid myself I would get anywhere, as an individual, trying to get these improved.
In a couple of cases I think these are burning issues which must bug a lot of users. To give one example: the actions available for a document discovered using "Recent" do not include deleting that document (a minor irritant) nor discovering where the document lives (a major one).
I can only assume that the dilution effect (whether perceived or real) means that, like me, some users are refraining from suggestion ... and perhaps others are making suggestions which get drowned in the ocean of input, much presumably of doubtful applicability.
As often happens, what is technologically possible is trumped by what is socially achievable.
And sometimes the wisdom of small crowds - especially if they share some sense of common purpose -- might exceed that of large ones.
I hesitate to draw any conclusions for others, but for me, this thought experiment does emphasise the current importance of thoughtful, rather than reactive, (aka 'knee-jerk') input, because it is currently being taken about as seriously as input ever gets taken, and -- realistically -- that state of affairs is probably not going to last forever ... nor could it.
As the Jesuits used to say, on the topic of the so-called formative years: "Give me the child, and I'll give you the man"
Tagged:
-2
Comments
Funny enough, part of that natural arc is that I, a habitual early adopter, will be test driving some other new generation of CAD and using Onshape only as customers need it.
@john_f_carr / Onshape
possibly the issue is that there is no underlying directory structure. Trying to find a document in this list is quite annoying to say the least. I would have felt that this would be a priority issue and a very temporary condition.
I have even been seriously considering creating my own directory with microsoft file explorer and putting the Onshape links into folders and not use the Onshape frontpage at all. Sorry but to me it is actually that annoying. Honestly how can I search for something if I don't remember it's name or even that it exists.
At the very least the organization list should be able to be sorted alphanumerically with subgroups within. This could work well has a directory structure and should be relatively simple to implement.
Dave
TAGs, yes please! Currently it's like Google would make a list of websites for you to 'just select' which one you wan't to open.
I haven't created any ticket on this because I thought it's self explanatory..
I was instancing that environment as a formerly highly responsive one, whose degree of connection with their user base appears now to be reaching a plateau, and improvements to usability stagnating, as the scale passes from niche to mainstream.
I raised that trajectory in that specific instance, in order to speculate on whether it might form part of a more general pattern, and I think in my last two paragraphs, I should have made it clear that I was now reverting, as I had been in the first paragraph, to talking about Onshape.
Sorry for being opaque.
I've worked at a startup where we had paying customers but no feedback. It was very frustrating. How do we know what to improve if we don't know what's broken? (A former coworker described selling to a highly classified TLA. The bug report was basically, the output is wrong and if I told you any more than that I'd have to kill you.) Sometimes little issues we think can wait until next year are easy to implement and make customers happy right now.
Internally we use Onshape differently than customers. I never have many active documents. On the production system I have a Free plan. When I get a document to look at, I get a link rather than a search term. If the document list is killing your productivity, I wouldn't know.
Thanks
Dave
The lack of a directory structure in Onshape's filing system has not bugged me yet,
(I'm nowhere near being able to do anything more than fool around with Onshape)
but it had never occurred to me it might be invisible to Onshape as a show-stopping limitation looming for serious use, so that's helpful to know.
We know (or suspect) this. I think there is a little bit of learned helplessness on our side. Many of us are coming from the existing CAD/CAM culture where it feels like the voice of the individual user never reaches the developer. Thanks to your subscription model, many of us are coming from the maker world with has now been steeped in open-source culture where if you want a new feature and you can't convince someone to make it for you, you can make it yourself.
So half of us are suspicious of Onshapes communication to us and the other half are used to speaking loudly while looking for the access panel.
I think it is safe to say that there is still room for improvement in the communication between end users and Onshape.
Some observations:
It's pretty common for issues I file (or present on the forum) to be misunderstood. Sometimes all the way to feature implementation. I doubt I'm alone in this and this is something more communication can fix.
The forum is a forum. Lots of community discussion. I'm sure if you do a bit of searching you'll find conversations on the usability of the documents list, whether folders should be there, whether tags are enough, etc.
The ticket system is not public. It's a one-one conversation. There are certainly conversations about issues between onshape and us that need to be one-one but it's not a good place for us to be talking about how well a feature's implementation works for us in the real world. There are too many of us coming from too many places for this to be viable.
Your internal issue tracking system is not available to us, it's not public. This is difficult for those us used to open-source projects. I understand the issues around making it public and I'm not suggesting you do. But you are missing out on the conversation that happens around every new bug or feature that helps everyone get on the same page and makes sure that the feature the developer is working on is the same as the feature the user needs.
The new improvement request system is interesting, but it will need time for people to learn how to use it. And it won't work if Onshape developers don't participate.
Anyway, you guys still have a way to go before you are hearing the voices of us in the forums clearly. I would expect you guys have real users on hand to write user stories and help the developers with misinterpretations of them. It feels like you need to use them more or reach out to us more.
We're all here because we're excited about what you are doing. It's a fresh take on CAD that's also being made accessible to new types of users.
You made the job harder for yourself. I think that's a good thing.
This process allows us to make sure every ticket can be addressed, implemented, deployed and update you as the submitter. As you can imagine, there are some improvement details that might not make the first cut or in some occasions cannot be implemented due to conflict with future updates in the roadmap.
We look at a number of factors in choosing which new features/improvements we implement but as you can imagine we are also implementing fixes, performance improvements and a variety of other things that take higher priority since they impact the general user base. As we grow and the system is pressure tested, we will be scaling and tuning the service every release.
In our development cycle (currently about 3 weeks) we can iterate on features and get the base functionality to you sooner and then increase the capabilities with upcoming updates. This is somewhat unique in the CAD area since many products are on a yearly release cycle. We are not plateauing and ignoring improvement request however the pool of requests is growing and we are using that input to help guide priority and help with planning what Onshape will become in the future.
Thank you for the input about our process and we will always look for ways to improve our support and improvement request processes.
For the avoidance of doubt:
I did not and do not see any signs (nor would I expect to anytime soon) of Onshape's responsiveness plateauing.
I was observing that Google's responsiveness, in the instance of Google Docs, and the Chromebook, had apparently reached a plateau, and speculating that part of this was an inevitable function of scale.
I was floating the idea that the present responsiveness of Onshape was at a level of intimacy which could not realistically be expected to last indefinitely, and that we should each preferably use the opportunity wisely (including maximising our signal to noise ratio)
My comments were motivated by the realisation that it's currently something of an incidental privilege to have our individual input carrying quite a significant proportion of the total user influence, for a product which may become rather useful and important.
The bigger point of feedback being quite valuable in determining what and how to develop is true. While many of us have a CAD system with workflows in mind, it might not be the most unilateral. Different people have different experiences and crowd sourcing input for functionality helps us make the best system for our users. While we don't always implement our features exactly how a ticket requests it, we don't ignore or discard feedback and try to take in full consideration of what makes sense for our system, our users, and our process of iterative design.
I'm pretty sure most of us here have experienced first hand what you and Lou are describing. You eat your own dog food. You keep yourselves open to input. You make sure there is a very short (or zero) distance between the user and the developer. All really good stuff.
The main point I was trying to make is that it feels like there is still room for improvement.
We all understand if Onshape doesn't implement critical feature X in service of your vision of the perfect CAD. But it can be disheartening to have your request misunderstood and lumped in with an unrelated one. Lost in the shuffle.
We just want enough feedback from you that we know you understand what it is we need before closing the conversation. Technical communication is full of pitfalls, especially in situations like this where the vocabulary is not shared by all, and one really has to close the loop carefully to be sure what you are hearing is what the other person is saying.
I'm not saying that you guys don't close the loop at all. Just that it could be better.
Case in point: Both Jake and Lou's responses did a great job illustrating Onshapes internal process and why they think they are good. Neither said "Feedback and communication are important to us and we thought we were doing a pretty good job but it sounds like it's not working for you yet. Can you elaborate on what's missing for you or what you'd like to see? Are there others here feeling this way too?"
You guys are doing a good job. I don't think you need to defend anything you are doing. Just ask a few more questions.
I've been using and abusing software for many years now and like many here enjoy nothing more than taking a peek into the future and perhaps in some small way offering the pearls of my lack of wisdom. Over the years I've bought and used a lot of design software - a lot....right back to mainframe based ROMULUS in the 80s (when if you wanted a screenshot you photographed the screen).
As a result I've known a lot of software developers from all over the world. Maybe it is just my experience but I have had fairly direct access to the people actually doing the coding or the people running the programmes - from Ashlar, to Think3, to VX, to SolidWorks, to Nemetschek and many others.
First up, I'm no coder. I have zero interest in writing code. I did dabble in it way back but its not my thing. I am only interested in actually using software and creating things with the software. So I come from this from the point of view of the user.
In all the years I've been part of alpha and beta programmes the one thing that always is a rich source of information from the actual users are the beta forums or email lists. In these environments the testers can debate and highlight things as they use them (how many of you have the software open in one window and the forum or email in the other?). Users like forums.
Yet, in every single application I've worked on, the developers insist on logging bugs and suggestions using their bug logging/request systems. I truly hate JIRA or the equivalent. As others have alluded to above the reporting systems are one way and private (except if you have an email list system that posts the submitted issues to the list - as JIRA offers if it is turned on). But even there the report is wrapped in the formatting of the reporting system.
Now the Onshape approach is, in my opinion, spot on. You can raise an issue right in the modelling window, attach a screenshot, even open a dialogue. No daft forms to fill in and steps to repeat while trying to recall the build number it applies to or getting frustrated by having to fill in the OS every single time!
I think having guys like Lou on board gives credibility to the process, and I know he fills in the forms on our behalf from forum input.
For other CAD vendors listening in here, and I know you all are, how hard is it - seriously - how hard is it to assign one or two people to trawl the beta forums to pick out hotspots of concern and for them to feed that into the internal systems, rather than asking the user to do it? That is the beta testing user who is doing it in their own unpaid time for no reward, and who often (especially in the CAD sector) actually have to be on subs in order to participate in the first place. Sorry this little aspect of alpha and beta testing always riles me.
Onshape might be far from production ready for my use but as far as I'm concerned they have the best beta reporting system in the CAD industry already. Now...just get back to it, stop fiddling around with free vs paid issues and get focussed on getting those drawings and feature patterns and configurations into the system!
I think it is premature to change the free/paid plans before the improvements are in the system. Once the Onshape software is truly "up to snuff" fair enough try to shove people towards the paid for pro plan. Until then surely they want as many people to design on the software using the free plan and giving back input through the forum on how to make Onshape the leading 3D Cad system.
Often I would just like to link a thread in the forum and say read these 10 pages to get the idea.
If my request is for example 'system to create live model based animated assembly instructions and external web links to them' and they mark it as done (I'm not saying they would) when there is the very first introduction of animation - no good.
If I make 50 tickets like: animations, exploded views, control over this and that, dimensioning possibilities to 3d space, better named views, external links to views - they don't have a clue what would actually make me happy or what I'm trying to achieve with all the requests.
Maybe we should be able to create main- and sub-tickets to give better idea of main thought and still divide in small pieces which Ons could set as done when implemented. This might also give better idea what is actually needed to achieve certain things.
I tried to offer a constructive suggestion as to how to collect the various improvement requests including sub-numbers so the ideas could be better defined and explained. When those individual sub-numbers were implemented they could be marked and dated, but don't try to tell me the whole improvement has been implemented when only its surface has been scratched as is currently done.
Please refer to: https://forum.onshape.com/discussion/comment/7908#Comment_7908
This also included a method to prioritize with votes and see where that stood with the community. I've been involved with something very similar to this with previous development efforts and it was very helpful at gathering the nuances to define the real issues. It was also fluid and flexible. We updated the system with dates of implementation and the folks that had a vote on those issues were notified by automatic e-mail so they could then "move" their vote to an unfinished item. I still think this should be implemented with Onshape's Improvement Request system, which is cumbersome and too limiting. The current system also does a poor job of encouraging the constructive comments in the IR area. We mostly resort to discussing those items in the open forum instead because that is much more convenient.
I'll say it again and sorry if the Onshape leaders don't like this, but you are asking us to use the software and feedback so that you can make it better so that ultimately you can make money by selling it back to us. So in return the least I expect is for Onshape to fill in whatever forms they want to use for their internal systems. So this is why I've got a pile of cases in the system all filled by Onshape employees not me.
That might seem harsh to some but time really is money.
The thing is, currently I need software that doesn't exist.
Onshape (software&company) is my best shot to get the software I need. I'm not expecting them to code everything I need, but it seems they could provide something 'close enough' to be a real time saver / productivity raiser for me in the future.
So this is kind of investment for me, cheaper than writing the code on my own but more expensive than just to wait if such software appears in the market.
Point is: I'm sorry, I'm only here to make more money by using Onshape in the future.
I've a distrust of environments (typically larger enterprises buying corporate IT systems, but even by extension things like advertising supported free products) where all too often it feels like the person paying is NOT the person using the software at the end of the day. My (perhaps naive) view is that situations like that lead to products engineered for the purchaser and not the user - and at the end of the day the user is left dissatisfied with everyone.
I'm very proud of the fact that I work in an environment where we can identify closely with our customers - our ability to take in all your feedback from different systems and use it to quickly iterate towards what you want is key to that. From time to time we have to make choices in priority and sometimes we have to compromise on an item in order to deliver something that meets a clearly identified need of many promptly. When that happens we're not done - we iterate and continue, so keep the feedback coming: "Adding X was great, but it still really needs to have Y too to be complete"
Now to one of @andrew_troup original questions:
Perhaps one of the biggest challenges we have is the environment shifting away from a file & folder based approach to information organization to one based on search. I personally think the world is moving (being dragged perhaps) towards a 'just search for it' approach to information presentation & discovery. Our presentation of the list of documents is part of that. There is no hierarchy behind things: documents are collections of data stored in a database and we retrieve yours on the basis of search: "Fetch the documents owned by user X or shared with user X and sort them by last modified time". If you think our current presentation could be improved by adding the ability to tag a document, or giving it a description, and then improving our search and filter capabilities to include that extra metadata (or other data that already exists within a document) then please let us know by using the feedback mechanisms we have.
If you don't know the name of a document, or the time it was last modified what else would you use to identify it? Something rather freeform "The one with a lot of extrudes" (I'm only half kidding :-) or something more precise "The one with a part called 'Primary Water Pump" please make those sorts of suggestions too - what are the key properties of a document that you'd want to be able to use to find it again later?
I challenge you to go do some homework on the search vs folder issue. I recommend you dig deep, down to the psychology studies. People never think alike or approach problems the same way.
What's obvious about search vs folders is that people care. The interesting question is whether Onshape will support the customers that value folder-type organization and access to their information.
I endorse what @traveler_hauptman said about your second point: I think the "folder vs search" binary you propose is an artificial one: both methods have coexisted happily ever since Apple perfected "find file" (ie decades, as has been said) and both are superb in their respective domains. These domains overlap, but not a lot.
As regards your first point:
I think there are probably several desirable tweaks to the improvement process, some of which might alleviate the current frustration some users are reporting, when their ideas for future enhancements vanish from the system whenever some present change is made in that direction.
You seem to be saying: "resubmit those future enhancement ideas when we take them down, if they matter enough to you".
Please correct if I have that wrong.
If that's approximately right: I'm not sure that's the best compromise between what works best for Onshape's internal processes, and what motivates users to keep interacting.
I'll think some more about what a few tweaks might look like, and post if anything seems worth putting forward.
I think tags can fully replace folders, I don't mind if they are built to look like folders but keep the main advantage and let one document belong in multiple 'folders'.
I have built erp-system and I tested many different approaches to search tables that have 10 000+ instances (think invoices on product level = 'invoice lines'). I found the 'google system' to be most usable, familiar and there is barely a learning curve for anyone. This means search box with popup list which begins searching when you write first letter and will narrow down as more letters are given in search box.
@traveler_hauptman , as I understand him, is saying: It's not a new thing that computer users have sophisticated search capability, so the fact that we typically have not evolved away from using folders suggests that folders have unique advantages for organising information.
Some exceptions apply, for instance many photographers use a single folder for all their photographs - but photos (and their processing workflows, and their naming systems) have unique characteristics. It's also fatally easy to end up with exact duplicates of photo files, which a single folder helps to avoid ... but that's hardly a problem we face.
Use the directory column for the tag/search type organization.
Then Use the Organization column as a file folder type organization.
...I was going to say that I was not worried because the UX team would have a background in this. However, scrolling through the Onshape team I see no one with an HCI background. Which reminds me that SolidWorks piggybacked on the Windows UI, so they didn't really have to think about the fundamentals....
@jon_hirschtick Please tell me you have an in house HCI expert or someone like these guys that actually know about this stuff on call?
@andrew_kimpton As Onshape has a Document based system where for me a document becomes a project which is basically my folder for collecting all the related project info. Therefore I'd be happy for Onshape to stay away from a folder based system for documents but the "Home Documents Screen" need's filtering and searching which drills down to the part, assembly and meta properties level. I'd also love to see an option for all parts to come up in a list as you get in assemblies and now with derived parts (I love finding things though visual searches). It would be also great to have an image based search like Google photo's.
What I really want to be able to implement Onshape into Small to Medium manufacturing businesses is not folders but a way to tag a part or assembly as an approved (signed off) which then allows it to be used with in all company docs.
Twitter: @onshapetricks & @babart1977
Being able to select a set of thumbnails from inside a document to be displayed while browsing for a document seems like it would be useful. I print up a index sheet of thumbnails and part numbers for my projects to post on the wall and refer to. Having that accessible in Onshape would be great.
I really like the github contributions tab (https://github.com/your_user_name?tab=contributions&from=2014-11-19) which lets you see what you worked on over a date range, or on a certain day. It works in a lot of cases where created and modified dates aren't enough and is one of the cool things version control commit meta data gives you.
Like you, approval meta data is a key need for me. I'm happy to add it as a custom property.