Sometimes you need to convert Bug to User Story, User Story to Feature, Issue to Task, etc. Finally, you can do it via Convert action.
Convert action is available from several places, like Entity View, Board View, Table View, etc. Here is the video that explains Convert action in some details.
Notes:
Original entity is not deleted after convert action, you can delete it manually if needed.
Content is copied from the original to the new entity only if the field names are the same. For example, if you have a Description field in a Task and Steps to Reproduce field in a Bug, then when you convert Task to a Bug Description field will NOT be copied.
Zendesk Integration
Now you can sync Zendesk Tickets, Groups, and Organizations to Fibery. Find Zendesk template in Integrations section and configure the sync.
Now you can track schema changes (what happened with Apps, Types and Fields) in Audit Log. You should enable Schema filter to see the schema changes, like this:
Interested to try the conversion process, since this was something i was just thinking about. It says you copy the data to a new entity. Is there any relationship added to the old one?
The āApps & Templatesā thing was something a little confusing before, but Iām not sure this helps. Iām guessing there was the desire to add the āGet a Demoā option and you needed to consolidate. The thing that might be a little confusing for someone with the āApps & Templatesā or just shortening to āApps,ā which I think would be an improvement, is that it is odd to see a link to go see something in the same context where the thing can be seen already. In other words:
It is kind of like going to youtube and seeing a tab that says āVideos.ā Am I not already in the place to see the Videos? Or going to amazon and seeing a link for āProducts.ā
Additionally, I think calling both Apps & Templates out separately makes them seem like two distinct concepts. Personally, I think a label like āManage Appsā would be closer to describing the page you go to. The reference to templates makes sense in the context of the page where you Manage Apps. You are also prompted to choose from template or from scratch when clicking the CTA for āNew Appā. Introduce them to the āAppā concept, then that is all they need to know. If i want more functionality, i need to add an App. When they go to add the app, then you can introduce the Template concept.
Another option would be to use section headers for the left nav to label what you are seeing (see material design specification that calls out nav labels here, and ant does something similar on their doc website), then leveraging the same actions to the right. So, the settings icon would go to the page to manage all your apps. The ā+ā icon button would do what the āNew Appā button currently does. I mocked it up to show what it could look like below:
Interesting, and nice to see initial functionality here. I guess, however, I was hoping there would be field (re)mapping, as in the case of e.g. CSV import, where the UI/UX is actually quite excellent (one of the best CSV import processes Iāve seen in fact). Is that something you plan to add in the future?
Yeah, I think Iām pretty much with you here. I also like the idea of a āget demoā (or something) link that is highly visible, since app/type/etc. concepts can be difficult for people.
Yes, following on - and I suspected to see you in here and discussing what I was intending after my initial cuts at using conversion:
Per this point:
I second this, it was also part of one of the original requests:
Jira does this well, so does the .csv mapper. Without that, you have a lot of manual work here Iāve found in my few attemptsā¦
Other points on the conversion:
I would really like to see a link to the two. Ideally, both 1) an autogenerated comment, and 2) evidence of the original Entity in the activity log. In fact, it would be great if you could decide upon conversion, perhaps on a separate screen that would also do the mapping, what to do with the original:
keep it open
close it
delete it
Right now I have to say that I donāt really see much time savings with this feature vs. doing this manually. There is no mapping, nor any connection between the two entities. So the difference between doing this manually, and converting with this feature we have now, is:
Manually I can copy the name of the initial entity, hit āctrlā + K to create a new one, paste in that name, select the new entity type, and I have a new, unrelated Entity, just like with this feature
With this feature, I click āconvert to entity,ā choose the new entity type, click through the warning page, and then, if I happen to have identically named fields, get the benefit of saving a few more instances of copying manually.
In either case, any connection between the two I am setting up manually. That includes deleting the previous Entity.
So the only real benefit Iām seeing so far with this version of this feature is copying over identically-named fields. A big disappointment is the generic Rich Text field, which is typically ādescriptionā in other similar tools to Fibery, wonāt come over unless it is named identically across Types. The thing is, I intentionally name my Description fields differently in Fibery, which is something that is a differentiator and a feature Iām glad to have!. But that in turn renders the benefit of this converting of Entities to other types a lot less useful.
Curious @Oshyan if you have other feedback. Another thing I was really hoping for is Bulk Conversion, as weāve often created a series of entities that turned out was in the wrong Typeā¦
Thanks and looking forward to the next iteration of this feature, itās really needed and unfortunately in my opinion we donāt have much usefulness yetā¦
Yes, I think this highlights a good, specific example of why 1:1 field name matching being the only (current) option is a problem.
Iām going to (mostly) reserve further comment until we hear back from the team to know if they plan improvements to this feature. I would guess so, although sometimes features are explicitly labelled as āv1ā (or whatever), implying future improvements in itself, which is nice. Hopefully the omission of that here doesnāt mean that more work is not planned on this.
I do think itās worth pointing out, if itās not already in mind, that the value of this feature extends beyond what it might be even in a tool like Jira, and is in my opinion a notable part of what I think will ease adoption concerns (possibly what you call āFear Managementā). One of the challenges in Fibery that comes with its great flexibility is trying to make good choices about how to organize, name, and relate data. It is unlikely this is ever done perfectly, and the first time you encounter having to deal with overhauling some aspect of your config, you may well dread any future such tasks. Having features that allow powerful, flexible, and easy to use changes to accommodate āOops, I changed my mindā and āDang, it looks like I need a sub-type now that I have all these fields hereā can really help mitigate this dread and keeps people positively oriented toward Fibery IMO.
We were thinking that the main case for convert is for entities with similar structures (like Story/Bug/Task/Feature or Conversation/Meeting). Not sure how often you need to convert very different entities, like Meeting to a Task. Iād like to hear your cases.
Because of the assumption above, there is no manual mapping. One more thing about the mapping. Imagine the mapping does exist, but if the structures are very different it will bring close to zero value since you have nothing to map in fact.
Indeed rich edit field quite often has different names in different entities, I think weāll fix this by adding a simple heuristic to copy rich edit field regardless how it is named if there is just 1 such a field
Itās easy to add a reference to the original entity, but we were not sure that it is required, since we thought that original entity will be deleted in most cases.
Batch convert does exist, you can do it in Table View so far (other views have no batch actions anyway yet)
Our assumption was that original entity will be deleted in most cases. If weāll learn that it is not true, weāll add a relation for sure.
Good point, weāll rename it.
This will make it harder to discover in fact. Not sure that is something we want to have, but your overall idea to try to merge these things is very good, weāll tink how to make it happen.
@Oshyan@B_Sp@rothnic
Side question about your Favorites section usage.
Do you want to have it always open sometimes or would it be OK to always hide it? Like you click on Favorites, see a list of items, click on any item and the list hides?
Itās funny, I thought about this for a bit and felt surprisingly ambivalent about it. My current use would suggest keeping it always open is ideal for me because I have just a very few items in it (2). And I do think the very nature of āfavoritesā is for them to be quick accessā¦
I did have an out-of-the-box idea that I personally would like, though many might hate, which is for Favorites to pop open on-hover, either pushing down the items below it on the left, or overlaying them, or even extending out to the right of that button. I realize nothing else in Fibery behaves this way (AFAIK), but when it occurred to me it seemed like it might be a good solution, at least to this specific needā¦
Yesss - anything that saves my poor right index finger from some unnecessary clicks is a good thing! (No RSI emoji?) I would love to see this in more places.
The Themify WordPress WYSIWYG page builder uses the hover-to-open pattern everywhere, very successfully, and it is an option you can easily turn off. At first it seemed gimmicky, but after some use I am amazed that it is not more common, because it truly saves my mouse finger a good bit of stress.
If this remapping as complex as describe then the user has usually a kind of reorganization job to do I assume. Should such task really done half automatic by the fibery application(s)? What about making the Export - CSV - some reorg magic - CSV - Import attempt? Is this not much more appropriate for such tasks usually seldom happen once the Application Domain model has worked outā¦
Interesting point. I havenāt fully thought through the consequences of what you suggest, and I should look at some practical examples in my own apps. But my first reaction is that this does sound like a somewhat reasonable alternative, especially if you take into account development prioritization. I know that the team has a āfear managementā project that encompasses export functionality so people donāt feel like they are locked-in. So this suggested approach would actually link this otherwise perhaps unrelated functionality (convert entity) to another strongly important one (export/fear management), thus strengthening the case for the latter, and reducing overall dev effortā¦ I think.
Exactly thatās how I was thinking. We should look where fibery creates most value to the user AFTER the creator role has done the job of creating the app. Creating a app has a lot of āALTER Tableā activities while creating your app(s) model. And yes Conversion might help here. BUT is this really the main use case for fibery to support the app dev lifecycle? Or should it shine with the developed apps towards the users of your apps? If I need to assign dev resources I would focus on the User Valuable Features, and they have a plenty of them to tackle
We in fact see quite a bit of use out of this. In some cases, you might not necessarily close the original entity, which is why I was suggesting the option for varied states. This allows you to do very interesting things like trace the origin of new entities to previous ones that are very similar. I think @rothnic may be wondering about similar capability with this question in fact:
There are concrete examples of this in other apps that I have found useful: Asana has a very key feature of āconverting a task to a project,ā and you can see how much itās needed in Wrike right here:
Incidentally I doubt youāll see a better example of a company not following user feedback in its own public forum anywhere if you look at that post
Aha also has a great feature - which I think is particularly relevant to you guys now that youāre putting such a focus on Product teams - and that is to convert an Idea to another entity, then link and update the original Idea as the new Entity evolves. And to answer your question Michael, Aha lets you convert to various types of entities:
So drawing from these two examples, and since my team uses Types for Projects and Ideas, we have a need to convert those entities to pretty different Types - Projects to Tasks, and in our case, we have a Type āIdeaā that can be converted to just about anything, not just those three that Aha accounts for.
Since we are āall inā on Fibery, we use it for all kinds of biz management tracking, so we have things like vendor accounts, provided services, āoccurrencesā you name it, and we have had a need to convert any of these at times to something else. We used to use Jira, and if you know Jira well, you know that you can configure it very deeply, almost to the degree of Fibery, and the remapping / conversion is a real cornerstone feature I think when you get into some deep set-ups with a ton of āIssue Types,ā the equivalent of āTypesā in Fibery.
I am very glad to see the ability to bulk convert entities, that may save some more time. However, this also brings some need for, ideally, both of these features:
writing some reference to the conversion in the comments
Keeping a reference in Activity Stream that the entity originated via conversion from another Entity
ā¦because you could have, say, a list of 15 entities you convert. I think it could get hard, with the existing iteration of this feature, to keep track of those 15 new entities, and the 15 old, if you donāt immediately delete all the old ones. But if you donāt want to delete (and we are a team that does not want to delete as a rule), you are stuck making 15 references between the new and the old to make sure you keep traceability.
To this point:
we do have many Types that are quite different from each other, true. But we have a ton of common fields, like ābusiness functionā or āproduct,ā things that weād otherwise use a tag for in other tools, that cover a large range of Types. So not being able to Map them means we are stuck with a lot of manual work.
So I hope thatās useful. Really think you guys have a bunch of deep potential with this feature, including when automations come out the ability to map workflows to keep ālinkedā entities automatically tracking when the related entity moves in its workflow. This is what Aha does with its Idea feature, and you guys can easily emulate this. Itās a powerful feature Iād love to see in Fibery, in fact I already wrote about it!:
Besides product development, my other hat is building and running AB tests for our website, which has a decent amount of traffic (~1m unique visitors per month) and have run probably a couple hundred experiments using Optimizely and google optimize. I would just caution on having preconceived notions on what is more discoverable. To accurately predict that youād have to have a pretty accurate model in your head of what size devices people are using, how many apps they have setup, how they use the app, how the rest of the app influences where they are most likely to look on the site, and 100 other different things and how they interact. I typically expect something will perform better than another option, but have been surprised by outcomes many times.
The second idea was reusing the current elements that are next to the apps, but could easily be more prominent. The core idea is just that having a label above the apps calling out what they are help reinforce your appās concepts and hierarchy, while pulling double duty of providing a natural place for those buttons. Hierarchy is a pretty powerful concept because it implies some kind of relationship, and that is something you are currently missing out on. The other nice thing is just that it is consistent with your existing pattern of going up to the parent to add something beneath it. To add a view in an app, you go up to the app and click the +. But again, you very well could be right.
Personally, Iāve clicked on that element maybe 2 times before this and it was all early on and had kind of forgotten about it. Having a link on an appās Type management view would likely provide better contextual discoverability, since if Iām viewing an apps types and relationships, I might want to view them all. A screenshot of what Iām talking about:
Also, not sure if it is just me, but when I viewed that page it was difficult to see the types because they off the edges of the viewport. Not related to the change, but wasnāt sure if that is a known bug.
Yeah, my personal experience in using this kind of feature has been mostly in JIRA. There are two cases that come up.
Internal Things: We typically want to convert something from one type to another because you donāt really care about maintaining the history of where it came from, since it is something you are already responsible for. This is often where you have a Story that you realize is too big, so you turn it into an epic.
External Things: We want the original maintained with a link for things that come in externally. So, if a user reports a bug, that comes in as a bug via an issue handler. We donāt want to change anything about that bug since that was how it was reported. Letās say that it actually wasnāt a bug, but was a missing feature they expected. Weād copy the ticket into a story in the correct JIRA project, which would include a relation of āDuplicated Fromā back to the original, then modify the contents of the story. JIRA works with a much more narrow type of entities though, so i get that it is hard to address. We then used automation to transition the original bug to done when the story was completed.
I do think a relation is super important for no other reason other than being able to clean things up, like transitioning the state of some originating entity based on the one it was converted intoās state. There is some potential to work around it with relations, but youād end up having to define relationships that map entities based on rules for every combination of things you could convert between and youād have to keep the names consistent.
To me this is something that should exist and most people would expect, but I think there are a bunch of other important things Iād care about ahead of it.
FWIW I think Nickās mockup is on the money, and I donāt think discoverability is reduced (but I am quite familiar with Fibery, so what do I know?!)
This is an annoyance I have overcome by moving the Apps into alignment, and gradually the bottom ones reappear. But agree the āApp Mapā you are talking about (this also needs a name in the Fibery vernacular) should not have this happen by default, or at least there should be info on how to fix it easier. This took me an age to figure out, and asked support to help, who didnāt actually know how to fix it, either!
This is a great feature though, and Iād like to plug again for a feature that would do the same automatically, but at the Type level. Would help solve some of the missing āauto-generatingā whiteboard functionality, too:
ā¦and wanted to respond separately re: these points:
Very glad to get that commentary! 100% I am somebody who expects traceability between the newly generated Entity, and originating one. It is very had to keep track of the origin of the new ones without this relationship as your Fibery instance starts to proliferate. One of the great benefits of Fibery is its near Roam-like ability to trace links between docs, Entities, etc. which is great for Augmenting Knowledge as the team is highly focused on now. So itās puzzling to me why they would leave out such linking between an Entity that is created out of an existing one. For those that do know Roam, think about how this looks in Roam: you simply write ā[[ā and you create a new Page - the equivalent of Entity I think - from an existing one. The relationship is created, and Roam wouldnāt be Roam without this essential piece.
I have set up relations, and also my team takes care to make sure that if an Entity in our Fibery originates from another, we make a reference. I was really hoping not to have to do that manually anymore with this feature. so I consider it incomplete without the auto-linking of some sort.
Guys, wanted to flag up this issue again, and the very similar conversation over in
My team is working in some multi-level structures in a software system. Basically, three apps, One has 4 levels, the other 3.
As we build it out, we are seeing that stuff we thought was at the very bottom is actually a level up, or even something at the top of one should be down two levels. But once an item is created at one level, then commented on, referenced, and related to, you canāt move it easily to another level without losing all that context. This incidentally is another problem I spoke of here in the above-referenced thread:
We are now getting stuck on how to move things to the proper level because some of these entities have months of references, comments, etc. which will all be lost. Manually recreating that stuff is a ton of work, plus you will lose the original time that that content was created, which is very key. Itās important for us to see that a Meeting entity referenced a server solution we are considering 2 months ago. If I delete the server solution because it belongs in another area of my hierarchy, and then go manually recreate the reference, the reference is now from today, and not when it was made originally in the meeting.
Thanks for considering and hope to see movement on this soon!
Fixed Bugs
(No RSI emoji?) I would love to see this in more places.
