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.
Comments - How should they evolve next?
jakeramsley
Member, Moderator, Onshape Employees, Developers, csevp Posts: 661 
Hi everyone,
As part of our update today, we've shipped the first iteration of document level comments. We've had a lot of ideas about what comments could be, how our users would use them, and what functionality we need to bake in. Ultimately this leads to a near endless amount of work; we cut it down to some basics and decided to release it to our users with the hopes that you all could help guide us in how to improve comments.
With that said, we'd love your feedback on the comment functionality as it is today and if possible what needs to be added/changed to make them perfect for you. What did we do well? What do we need to improve on? What are we missing?
A couple questions we've had to kick off the discussion:
1) How would you like to be notified of new comments and when should you be notified?
2) Where would you like to view your comments? Is in the document adequate?
3) Would you use comments as a way to do design reviews and/or use it as a social tool?
4) As a way to do design reviews, how would you like to handle obsolete comments?
5) As a way to do design reviews, how much associativity to parts/assemblies does there need to be?
As part of our update today, we've shipped the first iteration of document level comments. We've had a lot of ideas about what comments could be, how our users would use them, and what functionality we need to bake in. Ultimately this leads to a near endless amount of work; we cut it down to some basics and decided to release it to our users with the hopes that you all could help guide us in how to improve comments.
With that said, we'd love your feedback on the comment functionality as it is today and if possible what needs to be added/changed to make them perfect for you. What did we do well? What do we need to improve on? What are we missing?
A couple questions we've had to kick off the discussion:
1) How would you like to be notified of new comments and when should you be notified?
2) Where would you like to view your comments? Is in the document adequate?
3) Would you use comments as a way to do design reviews and/or use it as a social tool?
4) As a way to do design reviews, how would you like to handle obsolete comments?
5) As a way to do design reviews, how much associativity to parts/assemblies does there need to be?
Jake Ramsley
Director of Quality Engineering & Release Manager onshape.com
0
Comments
a) on the user clicking on the Comments icon, tiny same-shaped icons would appear with thin, pale leaders to various entities on the part or assembly (to minimise distraction). To ease accessibility, the icons would remain a constant distance outside the silhouette of the part or assembly, regardless of viewpoint
b) hovering over a balloon icon would flash up the comment (like a tooltip)
c) a mouseclick on the comment would cause it to remain visible until dismissed the same way
d) there would be a flexible tagging system for comments, so the user could impose an appropriate type of organisation or hierarchy for their particular review process
I'm not wedded to any of this, but something along these lines would probably satisfy my needs.
- 3D pin positions for the comments like grabcad that store visibility of parts, sections... and the ability of drawing markups over the 3D viewport.
- Conversations stored inside each pin.
- Tagging of the comments so you can categorize them like you like (questions, tasks, alerts...)
- Attaching images to the comments so you can add a photo or a drawing. Animated GIFs would be great.
- Reporting system so you can view for example all the open questions, modifications that were asked by the client (very important), modifications in progress, under review...
- Assigning comments to users (one or several).
- Assign a code to the modification so you can refer to it later more easily.
If we could use Onshape like a Trello or Redbooth in 3D I would be a very very happy manMaybe I'm missing a feature for this in Onshape, but right now every image that you upload appears as one horizontal tab, right? I could end having tens of tabs only for the images in my document.
Of course you're quite right, but I think it's safe to assume a hierarchical structure for tabs will be on the plan. (OnS, please add a couple of votes!)
Onshape's expressed intention is for a "document" to act as a viable container for all the files pertaining to the project, but the software is still in fairly early gestation. It seems the rationale is to have lots of public involvement from a very early stage, presumably gambling on the putative "wisdom of crowds". It's brave and ambitious; may or may not work, but it sure is fun!
I imagine all photos eventually being able to be consolidated on one or more tabs (but each photo able to be individually linked to, say, a comment)
Also checkout this thread https://forum.onshape.com/discussion/comment/1363/#Comment_1363 Tab link to cloud storage. I think I'd prefer to have my big project files (pic, pdf's, etc) stored in a dropbox directory that was shared to a tab. However tabs with pic etc are great for smaller projects
Twitter: @onshapetricks & @babart1977
1. This should be manageable for each part document, like on LinkedIn, where you can pick for every new comment/daily/weekly/none, as the frequency would vary for each person/part/project.
2. 99designs.com has a cool comment feature, where icons are dropped right onto the screen (in this case, perhaps tied to a piece of geometry like a 3D note?), but the comment is not shown unless the icon is clicked/hovered over. Also, you can toggle all comment icons on/off like a visibility layer.
3. Design review all the way. There are already plenty of solutions out there for social communication, since a web browser is open anyways, you can have your fb, g+, [in], etc tab open. On Android/Apple there will certainly already be a social app running in parallel.
4. Strike through the text so it is still readable just in case. And if you use an icon, such as what I mention in #2 above, perhaps a different color icon for obsolete, like blue vs. red.
5. A leader arrow is fine for this. The comment doesn't move, but the other end of the leader arrow/dot moves with the geometry spin/pan/zoom.
My two cents! (And awesome update yesterday by the way!)
Jim
Linked[in]
a) Email, include whole conversation, allow answers by email (set on/off)
b) Ons document list (show icon on the doc row, hover for view, allow answer without opening doc)
c) In the document, change Icon color, add number of new comments
d) In the document, popup like forum does (on/off)
2) According to no1. + Icons tied to geometry, feature or sketch.
Possibility to drag comment window into new browser on another screen and use as a live chat.
3) Design review and tool to communicate with other participating designers. Voice would be nice addition.
4) Strikethrough or greyed out
5) Arrow or icon with id link to comment, hover to highlight in comment list.
In general:
- Create a database of all comments with links to original comment/document/studio.
- Good filtering and search.
- Allow many type of links but not much content to keep comments short (add create link to RMB menu on tabs).
- Add note "#user# is currently writing a comment..# (like messenger had) to avoid difficulties on communication.
Note, this is based on one comment added & answered - but something to begin with.
Mostly agree with @Andrew_Troup @rimeiQuer @FastwayJim
There are tickets for annotations on the model and in sketches... As long as those are still active then I'd want comments to be per-tab. Otherwise there will be a million hacky ways to try to communicate which tab each author is talking about. "The M6 screw on the left side of the second bolt circle on the flubber panel in the verecork subassembly needs to be longer..." vs "This screw [link to model annotation] needs to be longer"
Design reviews. I don't need you guys to create a sub-par chat ap. I've got that covered with a VBscript that sucks in all my twitter/skype/facebook/viber/whatsapp/google+ feeds into a word document that get's printed every 10 minutes for me to read with my morning coffee.
Sometimes one needs to delete things for real. Either due to mistake, misunderstanding, or to consolidate and clean up notes. The version control is there for capturing history if we need it. Strike-through as a formatting option would be useful.
As long as one can link to model annotations in the comments, I think that's enough. In design reviews there will be annotations that pertain to the design (which the model represents) and there will be annotations to the model itself. I'd expect model annotations to be at a fine granularity (if the user can create it, they can annotate it) so sketch elements, features, parts, subassemblies, mates, etc. As noted above, document level comments would be a whole lot easier if one could just link to the annotation.
Generally, model annotations are much more useful to me than document comments. We can add a text tab easily enough for document level issues and if you guys attached an editor to that tab we'd be half-way to everything we need for document level communication.
I'd much rather see model annotations than further work on comments.
With regards to associativity to parts/features, where would you like the text to be shown? Do you want something to popup over the part/feature in the graphics area or something that track backs to the comments area right now? Is the point in history when the comment was made important or should it follow the part/feature as the document progresses?
I think I need to rephrase #2. I was wondering if you thought seeing comments only while in the document was adequate or if we need to add something to the documents page/user profile/some other place to be able to read and reply.
How do you want comments to work with versions, branching and merging? Right now they are per workspace meaning that you won't see the comments migrate to new branches or get saved with versions.
I'd like to see it attached to the target entity by an unobtrusive leader (which only showed when the balloon mini-icons at the ends did)
Perhaps "Zoom to Fit" could behave more generously when the display state of the mini-icons was "Show", than when they were hidden.
I guess it could "track back to the comments area", rather than show the text locally, but one advantage of having it show at the end of the leader is (provided it's implemented, presumably it would require a keyboard shortcut because the text is floating under mouse control) a png could be generated showing the comment in context, for printing or filing or sharing as part of an offline discussion or archiving of that comment.
Considering workflow, one use for commenting would be that I have someone 'non-cad' person following and commenting while I create a model.
In other words, if you wan't to buy a custom bookshelf from me rather than asking you to create a drawing in paint I would invite you to hop on into some basic design and modify it to suit your needs.
I think it's valid both to treat them separately, or to treat them with a universal commenting/annotating system. But for me the discussion is easier I if know which approach you are interested in discussing.
For me, annotations should be discoverable, and I should be able to hide them all at once when I don't want the distraction. For model element annotations, hidden, icon-with-tooltip-on-hover, and visible are the three states I would use.
It would be cool if every comment/annotation had a unique url (a query string on the end of the workspace element) as this would make cross linking trivial.
The location of the comments does not matter to me as long as you keep in mind the context in which they are used....
Document comments, because of the way you have set them up, will likely be used as a poor mans chat by collaborators. This means that users will try to manipulate the model with the comment flyout open. The flyout is currently huge and zoom to fit does not account for it, nor are the view tools available. I'm sure you will improve this as things evolve... (The other option for document level communications would have been a comments tab.)
Model annotations will be there to help the reader understand what the F is going on.. so please don't cover the element being annotated with the comment. An intellegently placed modal dialog or a designated flyout on the periphery are all good.
I don't understand you question about Comments should be timestamped ("was this comment made before or after I gave them the new information?" "Do I need to contact them to clarify a misunderstanding or is this effectively old information?") An annotation attached to a feature, sketch element, part, mate, etc should follow what it is attached to.
In document. This is not email or forum private messages we are talking about.
For me, comments are meta-information that belongs with the model it is discussing. Versions must capture the state of comments at that point in time. I'd prefer comments to be copied with the rest of the workspace with the option to bulk delete them. The benefit of a good comment system that copies with workspaces is that tutorials can be richer.
I'm really looking forward to improvements in Onshape's annotation/commenting....
For those of you that made it to the end of this too long post here's a couple fun commenting hacks you can do in Onshape...
Add comments to sketch dimensions by adding c-style comments to the end of your dimension "10mm" -> "10mm /*+/- .1 per catalog pp998*/". Sadly only visible when editing the dimension.
Add comments or breaks in the feature tree by creating an empty sketch with no plane (who knows why Onshape allows this) and then rename it to the note or use "------------------" to create a break. You will get a nice red comment. (Apparently Onshape uses the red for features that don't rebuild correctly. My models are perfect and error free so...
1) I use Asana for project management, and have been quite impressed with the way that they balance organizing information both by project, and temporally. I think that their model could be adopted - either directly leveraging their API, or rolling your own - to provide pretty powerful functionality.
- Each Document is a Project.
- Each tab within that document is a task
- Everything in the feature tree within that tab - features and parts in Part Studios, parts and mates in Assemblies - is a sub-task.
- Each of these sub-tasks can have a description/other metadata added (properties), be commented on, or have sub-tasks added.
- Sub-tasks of sub-tasks have the full Asana feature set: they can be assigned, marked complete/incomplete, given due dates, commented on, have attachments made, etc.
This model would take care of email notifications (Asana does this already), tracking engineering development, managing and assigning tasks, attaching information to geometry (although dealing with comments and subtasks that are orphaned when their parent feature/part/mate is deleted would be interesting). It would also allow easier integration with other services, like time-tracking or bug-tracking.(FYI: I swear I don't work for Asana - I just really like using their system, and would love to see a really deep integration with Onshape)
2) A great feature to build on top of this would be a tool for visualizing a design's progression from start to finish. I'm imagining a timeline view of a Document, where you could drill down to tabs -> parts & features -> comments, subtasks, etc., and see how each of those things sprung up, evolved and died off as the design matured. Today, I use SW Explorer frequently for precisely this purpose - to go back through old revisions of designs in PDMWorks and look at CAD data and check-in notes to try to understand past engineers' design intent. What becomes frustrating is when I have to switch mediums to find old design information - find a check-in date in PDM, and then go track down that engineer's notebook to see if I can find out why they made the decisions they did. Both suggestions 1 and 2 would help address this.
3) I think @Traveler_Hauptman's point about comments being used as poor-man's chat is very well made - that's exactly what I'd be doing, if I was working collaboratively. I think an in-screen chat function that's associated with collaborative mode is important, but that the current comment system - or what I've proposed above - isn't the way to do it. A better design might be:
I know you say both are valid, but what would be the best solution in your eyes?
Right now comments are orthogonal to the edit history of a document. They live in their own space and making edits/restoring to a previous point in history has no effect on them. If we apply a comment/annotation to a feature at an instance in time, should that comment point to that feature at that point in time or should it follow the feature as future edits to the document are made? For example, if I add a comment "Fillet is too big" would you like the comment to reference the fillet while it is too big or the current state of the fillet (which may or may not exist).
Could it be in the same system but you could choose type of comment to be
1. annotation (with pointer)
2. official comment
3. collaboration chat about the weather
4. custom type
??
I think there is a lot of merit in graphic markup, but we will leave it for another discussion. If Onshape does things right, graphic markup will only be used for illustrating changes to the shape of a design. Using circles, arrows, and lines to call attention to geometry relevent to a comment will not be necessary because onshape will generate that automagically.
So let's say that we limit our comments to chunks of html5. Other than the fact that it's rectangular in shape, it's not much of a limit because we can stuff rich text, images, vector graphics, and video inside. We get it for free so we may as well use it. From here on out I'm going to call comments and annotations "notes" because it's a little more generic.
The fundamental premise is that we are enabling communication between people (or notes to oneself), rather than capturing a geometric model of the design which is handled by the rest of Onshape.
Context is everything in communication, so each note we create is enhanced if we can associate it with the context it's meant for. Let's say that we can... Let's also assume that each note has a URI and can be linked to from other notes.
Because context is everything, and different versions of a workspace have different contexts, notes must be part of the versioned information.
What contexts are important? It varies by person but is informed by the structure of the information. Here's the structure I see and the contexts one might want to associate with a note. Hopefully others can chime in here:
The listing: Info on what's special about this document that you can see without opening up the document itself. Currently handled by the 'description' of the document.
The document: An overview of what the heck is going on, why there are 5000 tabs and what they each are used for, and links to key notes that the reader needs to be aware of.
The tab: Overview information for each tab (element) in the document.
...From here we get specific to each tab type. I think it's ok for Onshape to only handle Assemblies and Studios. I'll list the key things that I think might have notes attached:
Assembly instances (parts and sub-assemblies), mates, mate connectors, features, parts.
Finally, and probably controversially, feature parameters and sketch elements (lines, dimensions, etc).
...So...
For each of the items above, a context menu entry "Add note" to bring up the note dialog.
At this point I can associate an html5 note with each of the things above, and each note has it's own URI. Requesting that URI (assuming I'm authenticated) will focus the document on that thing the note is associated with, with the note placed as you like (as long as it does not obscure the context item).
What remains is how does one discover notes.
Rendering a notes icon next to each thing in the document that has a note is a good way to go as long as you can hide the notes when you don't want the distraction.
Having a global list of notes that one can walk through one-by-one when first becoming acquainted with a new document would probably be helpful. This should be in a flyout so that one can see the context of the note when they read it in the global list.
That's it. Notes are not part of the realtime communication. I think supporting realtime communication and collaboration is important and a few screen sharing type markup tools would be great for that. I'm happy to use voice+chat program X rather than have Onshape try to include this functionality.
I know I'm ignoring a lot of implementation details. Since internally documents & tabs, features, and sketch elements all have different ways of being uniquely identified; linking a note to a thing is not as easy as attaching a reference to the thing in the note. Choosing where to render the note is not trivial. The list goes on...
In both instances, I would expect the view to revert to the status quo ante on dismissing the comment.
I'm sure this can be easily done inside onshape with a partner if not making own. Collaboration without chat&voice is just forking.
And I would finally like to see cad system that can actually reach from designer all the way to the end customer. There is many request for no-sign-in links to models for serving customers, if there is no chat/voice possibility; your customer will be alone with cad system never seen before.
And if you like to collaborate from some random computer without favorite chat installed..
Otherwise good points.
I think re-orientating the model to the view when the comment was created is essential. Gets across the question/point just as intended.
http://www.theverge.com/2015/4/28/8507073/dropbox-comments-announced-hosted-files-collaboration-feedback