ad hoc formulas in views - or in fact at least ability to use ad hoc lookups without having to create a separate field. In our project we restrict number of creators, but still would like people to configure their own views (to be able to explore and collect their own insights).
history of view changes - it’s pretty easy at the moment for people to override each other changes or to forget (or not even know) who changed what and when. We specifically restrict view management to small number of people - which can be difficult as it is creating bottlenecks, but the alternative is too much chaos.
paginated search (or an equivalent workaround) - with a lot of content and some frequently occurring keywords the limit of 60 search results is well… very limiting (especially in the context of product management)
It sounds like these two things are somewhat in opposition, no?
Would it make sense to encourage users to create whatever views they would like in My Space, but not allow views in other Spaces to be changed?
seems like a sticking plaster fix for a fundamental challenge with permissions.
It wouldn’t stop people from messing up shared views, only allow you to retrospectively attempt to revert changes.
Perhaps I wasn’t too clear - that’s exactly what we do now. When I said “would like people to configure their own views” I meant “My space”. And when I said “we specifically restrict view management to small number of people” - I meant global workspace.
Ability to configure views in “My space” is unfortunately only limited to whatever fields have been exposed to them.
In the context of my team doesn’t seem like “sticking a plaster fix” - that’s exactly how software version control works. You have collective code ownership with ability to see the history of who changed what when.
History of view changes does stop people messing up shared views - as when I notice that my friend John added a column yesterday I can go to them and ask what is the purpose of that column. And even so - I wouldn’t downplay ability to retrospectively reverting changes - as knowing who removed “my favourite and the most useful column” is a pretty good start of a conversation (compared to not knowing who might I need to talk to).
I understand what you’re saying, but I guess I don’t see views as being analogous with source code. I can see why seeing the history of an entity is really useful, but I would hope that views would not need regular changes/updates in the long term.
When you say, “added a column…what is the purpose of that column” do you mean, “added a new field…what is the purpose of that field”?
Or do you really mean column?
Because, the way I see it, showing/hiding a particular field may come down to personal preference (for which My Space is a great solution).
Whereas if someone truly thinks a new field is needed (e.g. a lookup) then should your friend John be allowed to do this? Limiting this capability to Creators (following suitable round table discussion if needed) may actually be advisable, otherwise the database could get ‘polluted’ with loads of fields of which only a small subset is actually used/useful for any given user (though not necessarily the same subset).
Perhaps this is related to the idea you were getting at with ‘ad hoc formulas in views’? If this means something like ‘per-user fields’ then that’s a really interesting proposal but I’m not sure it would be on the radar any time soon.
Have you taken a look at mu Tripetto SDK recommendation?
If this was integrated, much in the way Viziydrop was integrated, it would be an incredibly powerful way to create interfaces and conditional logic in data entry.
Many of us end up using apps like JotForm and Typeform just to get around the interface of apps like Airtable and Google Sheets. A robust form creation & chatbot app covers a wide range of uses.
In general, I think a meta layer is important: describing what fields are for, how tables fit together, etc. I.e. it should be possible to make structures in Fibery directly self-documenting (i.e. not in a page talking generally about the workspace, but directly on fields etc.).
Within My Space you can create views of Tasks (or any other data) in whatever way makes sense for you. I’m not deep into Asana, but I don’t immediately see anything that’s not possible in Fibery in this regard.
Here’s my current My Tasks view in Asana. The board lanes (circled in orange) are private to me, and they aren’t part of the tasks’ public fields nor any projects. In Fibery, it seems like I can only pick public fields as board rows or columns.
Per-user fields would still be useful for adding personally meaningful marks to tasks. I use the FVP method to choose which task to work on when it gets overwhelming, but since that kind of workflow isn’t supported by Asana, I write down my task list in Notion to be able to attach marks to tasks (which involves just prefixing task names with a dot ‘.’). This particular use case could be doable without a full-fledged per-user fields: allow users to favorite entities with a shortcut key and make favorited entities visually distinct.
Well, the images you show (putting tasks into groups that you define) effectively imply per-user properties. I guess you could call these ‘fields’ or something else (folders, sections, groups, tags) but either way, it’s not something that’s in the works, sorry.
However, Fibery does allow you to mark items (or views) as Favourites, and they will show up in your Favourite section, as well as being indicated with a star.
@Chr1sG - I think we are already 90% of the way to being able to do what @ento wants, with the existing Card view:
Create a new Task States DB to represent all the various custom States (Columns) that a Task can have. The entities in this States DB represent the various States that a Task can be in – i.e. the Columns that anyone might want to use in a Tasks Card View.
Tasks get a new many-to-many relation to this Task States DB
Make a Tasks Rule to automatically link the appropriate Task State(s) to each Task.
We need the capability for Card views to Filter Columns by a To-Many relation - entities (ROWS) can currently be filtered by a to-many relation, but COLUMNS cannot.
Card view can already filter which Task States (Columns) should be displayed, via the manually-applied “Hide Column” option – but this capability needs to be extended to the My Filters / Columns section so it can be customizable per-User.
Additionally, a manual re-ordering of the Card view Columns should optionally be remembered per-user.
Ah, found the star button! The order of favorite items in the sidebar appears to be the order in which you clicked on the button, which might be fine for my use case. I’ll try using that for task tracking.
It just occurred to me that I could make a private Space with a personal status database with a 1:n relationship to tasks. Then, I can make a board that pulls in tasks I’m interested in and set the columns to use the status database. Tasks without a personal status will show up in the “No Status” lane. However, having been purely a solo user of Fibery, I’m not sure how relations to a database in a private Space will show up on the shared Space side to collaborators.
A database of personal notes and other fields could be done similarly with a 1:1 relationship set up against the task database. However, in this case, I’m not seeing an ergonomic way of creating a view that shows all tasks that don’t yet have a corresponding row in the notes database and also shows fields from the notes database. I don’t know if I’d put this as one of my top 3 missing features in Fibery, but being able to extend an existing database in an ad-hoc throwaway manner could be potentially powerful…? (Unless it’s already possible of course; I’ve been dipping in and out of Fibery and haven’t explored all its features nor kept up with the feature releases.)
What other users can see/do depends on their permissions. If your space is ‘No access’ for everybody else, they won’t see your ‘personal status’ entities.
You can use a filter (on any view) to show only tasks that are not yet linked to a ‘note’ entity.
Not sure what you’re trying to achieve.
If you do filter to show only tasks that do not have a linked note, then what is the point of showing fields from the note database? I mean, you can create lookup fields in the task database to show fields from the linked ‘note’ but they will be empty