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.
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.
Now you can sync Zendesk Tickets, Groups, and Organizations to Fibery. Find Zendesk template in Integrations section and configure the sync.
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
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)
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.
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.