[❓ FEEDBACK NEEDED] Publish Fibery Space to the Web

We are thinking about a way to publish Fibery Space to the world. Imagine you can give anyone access to a space with the all Fibery power (search, bi-directional links, multi-panels navigation, etc). There are many interesting use cases for this:

  • Changelog space with all recent changes (replace Changelog - Fibery Community)
  • User Guide (replace Fibery Help Center)
  • Domain Specific knowledge resource. Imagine something like this for product management domain that looks/works like this (Start Here)
  • Roadmap (however, it will be not your REAL features roadmap, you will have to create a separate database, like Roadmap Items, and sync it with your real features. However, it is more flexible, since maybe you don’t want to share all features)
  • Feedback collection (like this https://feedback.canny.io/)
  • Community (the hardest case, but it’s possible to replace Discourse in theory for our needs)

To give you some deeper perspective, here is how it might work.

  1. Admin can “Publish” space. In this case space will be visible to all people.
  2. Allow people to sign up. It will be possible to allow commenting, or even add new entities (imagine Contributor access level for Product Feedback Portal, she can add new Requests, but not change other people requests)
  3. Maybe custom domains for public spaces (not sure how hard it is to implement).

Changelog use case

User guide use case

Do you think it might be useful for you?
Do you have specific cases for your company?
Any other feedback?

This is actually a long-wanted-for feature for us if I imagine it correctly.
What I see it doing for us – a game design studio rendering game design external services to different clients and their projects:

  1. We could share a link to the design space which might be easier and comfier for the recipients. At the moment we have to add everyone willing to take a look at the workspace with their e-mails and give them access to the space.

  2. We could probably merge all our work inside one studio workspace? Currently we have one separate workspace per one client, but that means that our team has their tasks spread all over the several workspaces. Also it complicates the report creation and analytics since workspaces don’t have any easy way of “talking” to each other. Several workspaces are a little easier on the eyes and mind since everything is more compartmentalized, but I’d like to have all the info in one workspace to be able to play around with analytics.

  3. I’d try this solution for feedback gathering and knowledge base too. I’m currently on the lookout for a good tool to collect data from the playtesters. I am already processing the info acquired inside Fibery, but it is gathered elsewhere.

  4. Could Fibery space be a good choice of presenting one’s design portfolio? I don’t know, but that’s the thought I had.

1 Like

I am working on a side-project with some friends (using Fibery its project management, naturally :sunglasses:) and several of these would be useful.

My project will be free to use as well as hoping for some paying features to keep it up, and it will require guides and wiki articles. I also post changelog/updates some other place, and have a custom solution to push recent stuff to my site. I’d also like to share roadmap, get feedback/ideas submitted.

I temporarily had some custom solution that registered a message in a channel as a feedback, and synchronized like/dislike and any edits to the messages into Fibery entities. Having it directly inside Fibery would be much nicer.

I’d want to use it much like how it’s outlined.

Some features that would be nice for these:

  • Syntax-specific highlighting in codeblocks, e.g.
    ```js
    console.log(“hello”)
    ```
  • Simple feedback possibility on guids/articles. I’ve looked for documentation services/platforms that offer these. I saw that you have reactions available in the changelog sketch, could it be suitable for that, but would it be limited to logged-in users?
    image
  • If a guide is broken into pages/a collection, some way to easily navigate to the next one, or at least a clear way.
  • If you have related content in a collection like like this, will people find it when it’s hidden behind a “show N” button? For people using Fibery it’s easier because we use Fibery all the time and know better the existence of this button, but does outsiders just looking for articles? I’ve had co-workers not look for content inside this button :pensive:
  • The list view could be incredibly useful too as, like a different way to approach guide hierarchy compared to side-panel with nested folders and Documents, although it’s limited to Databases
    image
  • Thanks to Fibery’s web of related and linked content, is there a potential for using it, at least partially, for type definitions? Though hard to compete with doc generators, as they do this task very well :pensive: And Fibery is meant for more repeatable content, whereas code (documentation) require so many different non-repeated things.
4 Likes

This would be the single biggest advance in Fibery thus far, given our particular use cases. As an agency, we have a continual workflow of projects that are getting done with clients. There are multiple steps in our process that need client interaction, such as:

  • Approval of user stories for next sprint
  • View of fees that are due to date
  • Scheduling of next Sprint internal review or client review
  • Feedback on existing user stories / backlog
  • Reporting of project process

It’s extremely difficult to carry out these workflows without having some form of portal interface for a client. The key, however, is the ability to limit access to records / views / entities so that a client only sees their own data, not another client’s data

Super interested to see what is possible here.

1 Like

Collaborative whiteboards to get stakeholder feedback without having to pay for licenses would be a winner in my book.

It seems you need per-entity permissions more for this case. Space-per-client is quite heavy and the problem here is databases proliferation. For 10 clients you will have 10 spaces and most likely 50+ different databases. I don’t think this is a good solution. With per-entity permissions you can separate access by Client entity and all linked entities will be visible per-client only.

Not sure, it looks like a personal problem, and we are looking for teams problems more.

2 Likes

Can you provide some details? What are the flows?

Current solution will not rely on record-level access unfortunately, so I am not sure your case will be solved in an efficient way. Free read-only users will be released soon (and a bit later we will add Comment permissions to them as well), but still without per-entity access it will be hard to invite them.

1 Like

For me this whole thread is just about making something visible to external parties - notion do this quite well IMO. In sharing info with external folks you very often don’t want people changing things but you might want to capture peoples comments or feedback - and I wouldn’t want to pay for people to just view and comment on somthing.

The only caveat to the above is when I conduct stakeholder workshops to capture information on jobs to be done, pains, gains, need them to do things like stack rank problems to be solved etc etc.

These workshops need to be collaborative and get people involved in the process rather than just sharing a screen with them and me doing it for them. This is where making the whiteboard more ‘editable’ by external users would work well. Everyone loves a sticky note right?

These stakeholders are not going to be regular users of the system so again I would be reticent to pay for them to just use it on an adhoc basis. Mural / Miro allow for this.

Hope this helps.

5 Likes

Got it, thank you! It is relatively easy to implement, we will take this into consideration

1 Like

If you guys move forward on this, I would find these aspects in particular useful:

Some time ago we looked at an Atlassian guide on how to use Confluence as a public-facing User Guide and it looked intriguing.

However, and I’m probably in the minority, I’d much rather see you guys prioritize some other stuff, much of which I’d call the “rough edges” of Fibery, before doing work on publishing a Fibery space to the web. My team uses Fibery for work management, and could really use some simple improvements that would avoid the daily frustrations in Fibery, before we have the ability to publish to the web, which won’t help our daily quality of life:

  • Improved commenting and Notifications - discussed in various areas here already
  • Fix of multitude of formatting bugs: Odd key combos, such as trying to paste in comments commits them; trying to add referenced entities when doing a soft return “shift” + “Return” puts the reference on another line, and a host of others
  • Inability to create an inline entity 100% using the keyboard when typing “#”. The last few steps you can do when creating a new entity straight from the “ctrl” + “K” command with the keyboard do not work when creating inline
  • Can’t see closed entities in search, but you can see them when referenced around Fibery with the strikethrough, and you can see them grayed out in Collections when typing in those fields. So it’s odd that you can’t see them in the search dialog. Request is here: Seeing “Closed” Entities grayed out in Search Dialog
  • Would much rather see Bi-directional integrations/sync before pushing data to the web. Without this, I don’t really think the Fibery integrations are true “integrations,” but rather API connections that are custom built for user ease-of-use
  • Dashboards - This is a feature all of my team looks for, because they expect it, but it doesn’t exist.
  • Ability to create a Context View and see multiple locations of the same Entity in the cards. Context views are a very useful feature (I’m talking about filtered views that adjust for each entity in an App based on the filter). Example of this: I have a Sprint DB. I have stories connected to it. The stories have tasks. However, in each sprint I want to do some one-off tasks that don’t belong in a Story. I can set up a board that will update with each new Sprint via these Context Views. However, I can only see one “type” of the Tasks due to this limitation: Either the ones directly related to the Sprint, or the ones in Stories that are in the Sprint via lookup. This is a limitation that hurts us in various areas of Fibery, and would also be solved with Polymorphic relations. When creating relation, ability to have many Types from which to choose, and not just one Type that also would be something I’d like too see completed before pushing the Fibery Space to the Web
  • Whiteboards do not yet represent real relations. I have stopped using them for over a year waiting for this feature, as they are not useful without this. Without better integration with Fibery entities, the Whiteboard are more or less just a way to diagram within Fibery, but you can do this more elegantly with other apps, some free, and just embed into Fibery. I really hope you guys realize the potential of integrating Whiteboards with Fibery Entities. One of my favorite features of Fibery is actually the self-created “map” in the Workspace Map. Even if something like that could self-create inside apps it would be a hugely helpful feature.

I hope you guys don’t come down on me as in the past when I posted feedback, but you are asking these questions:

So I’m trying to answer all three of those!

Cheers and keep working hard to get Fibery complete (and I know most of what I mentioned above you will deliver at some point!)

1 Like

I think this would be AWESOME :sparkling_heart:

My own primary use case would make good use of #2but it would also require per-entity permissions scoped by user. “Full users” = our employees, and “free/limited users” = our clients.

If per-entity permissions are not available for this kind of “free/limited user” access, an equally good alternative for my case would be a lower-cost “limited user” – but I know that is tricky to define in a way that makes sense in general.

For example my “free/limited users” (our clients) would have access only to specific views and specific entities (i.e. only those related to that client), plus editing or commenting ability in some of those, and also the ability to create some others (e.g. tickets).

I don’t know how to define this in a general way that makes sense, because these “free/limited users” appear to need all the same access and capabilities as regular users, but limited to specific views and entities. It looks very arbitrary.

For my case at least, it is only the “business perspective” that wants to make a distinction between limited users (our clients) and regular users (our employees); because our clients will make much less use of Fibery than our employees, so there is the natural desire from the business perspective to pay less for their access. But it is quite difficult to make a clear distinction from the technical side. This is why “charging by usage” can look like a good option for some cases from the customer’s point of view.

1 Like

This sounds like a big system to develop (allowing people to “sign up”, etc. in particular), so while I could definitely see some significant possible value, I would also not want to see it detract much from other long-standing requests, as @B_Sp notes. That said I am not sure that it is so much work, and I am curious why you are proposing it. Perhaps because you have realized it could be done fairly easily and may be of good value for your users.

My use case seems like a pretty classic software dev team one, where change log and docs would be a great start, but overall feedback management (let’s set aside “replacing the forums” in entirety for the moment), feature requests and bug reports in particular, would make it especially appealing. To do that it would need to allow for front-end submission (new entity, e.g. feature request), potentially an approval queue (front-end submissions should not necessarily just show up publicly right away), and a way for people to react/vote on and ideally comment on things. If these features could be enabled on a per-“type” basis (e.g. reactions enabled for Docs or Change Logs, but no comments, comments and reactions enabled for feature requests, etc.), the that would be ideal.

As I touched on at the beginning, what I find surprising about much of what is suggested here in the original proposal is that it clearly encompasses e.g. Native Forms & Conditional Workflows using Tripetto SDK, at least in part, or Form View and required fields. Yet that received only cautious confirmation for some unspecified future time from Fibery team to-date. Assuming that this overall feature set outlined above would require a lot of work above and beyond that, it seems like a bit of a departure from core focus, despite its potential utility to many teams…

So I am curious to hear from @mdubakov to clarify the potential dev time on this. Maybe I have assumed too pessimistically.

1 Like

Thank you for supporting my comments, and this is a great point you make! Would also like to hear details about 1) the origin of this potential feature vis a vis other high priorities here in the community, and 2) how much dev time the team thinks it will take them to release.

I am not sure this is relevant to Publish Space feature. Your case should be resolved with Free read-only users (with comments ability and maybe some Add Entity ability) + per-entity permissions. As far as I understand, you will invite clients as guests and will not publish any Space.

2 Likes

In general this idea is relatively easy to implement for read-only cases (user guide, changelog, etc), but not so easy for community/feedback collection. Indeed to complete these harder cases we will have to have Forms, registration, etc.

Form View is one of the top request, but it has a blocker (permission on Views). Now it is close to completion and at least it will open this feature for real consideration. So we will see.

So far only read-only publishing is in spike mode, we will not dig into more complex cases till Forms and better permissions.

2 Likes

We need it totally. Our actual use cases.

2 Likes

We’ve started the first feature

3 Likes

It would awesome to see more of this implemented, especially the external users feature!

I’ve been using Fibery as a project management solution for an electrical :zap: service company. Currently I use it for:

  • Information organization (client and job info)
  • Material ordering/management
  • Task Mangement

While it works very well for those tasks, I’ve always wanted to add some sort of client dashboard and scheduling feature. I’ve tried Calendly and even gone so far as to try and integrate it with Fibery with Integromat, but it never really worked as intended. My dream would be able to make something on Fibery to do the same job. The format would be as follows:

  1. New client signs up/existing client logs in.

  2. The landing page shows all of the projects for a given client (entities) and gives them an option to request a new project (add new entity).

  3. The projects (entities) could show waitlist order and/or scheduled date, duration, project status, and could be a place for documents/photos or cloud storage links.

  4. Ideally they would also be able to add comments to the projects (entities) and see and potentially edit linked information (contact info).

I actually think I could build something pretty close to this with the current features in Fibery, but I need a way for clients to see only the projects (entities) assigned to them so that the rest of the projects in the database are hidden.

My hope is that between the features in this thread and [PLANNED] Entity-level permissions it might be possible to build this. I don’t know exactly how the add entity/form submission feature would be implemented but I figure it would probably be easiest to make permission control part of the automations. That way you could have blind or read only form submission for feedback uses and editable form submission for collaborative uses. Basically (when user adds entity → add user as read-only/editable). I’m still a little confused about how the linking permissions (for contact info, etc.) might work but it seems like their are some good ideas out there already in other threads.

I’d love :two_hearts: to hear feedback on the idea if there is another product/solution that I’m missing that might be really obvious. Thanks!

1 Like