I would like to propose the addition of a “Gallery View”. This view would display entities as a predefined number of blocks arranged horizontally, much like a grid. However, unlike a Kanban board, it would not have the functionality of moving entities between different columns or stages. Instead, it would function more like a list view but with blocks instead of rows.
The Gallery View would provide a visually appealing and efficient way to manage and view entities. It would be particularly useful for workflows that involve a large number of entities, as it would allow users to see more information at a glance without the need for scrolling.
The proposed Gallery View in Fibery could offer several advantages over the existing Table, List, Feed, and Board views:
Visual Appeal: Gallery View could provide a more visually engaging way to display data, with each entity represented as a block containing all its relevant information.
Space Utilization: Unlike Board View, which can leave empty spaces if there aren’t many entities in each stage, Gallery View could utilize space more efficiently by arranging entities in a grid.
Information Density: Gallery View could potentially display more information for each entity at a glance, reducing the need for clicking and scrolling, which is often required in Table, List, and Feed views.
Flexibility: Gallery View could offer more flexibility than Board View, which is typically used for workflows that involve moving entities between stages. Gallery View could be used for a wider variety of workflows that don’t involve this kind of movement.
Simplicity: Gallery View could be easier to understand at a glance, especially for users who are not familiar with kanban boards (Board View) or prefer a more visual representation than what’s offered by Table, List, or Feed views.
Here are some use cases where a Gallery View could be particularly beneficial:
Product Catalog: For a product inventory, Gallery View could display all product details (name, SKU, price, image) in a single block, providing a quick overview of each product without having to look at multiple columns or rows.
Employee Directory: In an employee database, Gallery View could display an employee’s name, position, department, and photo in one block, providing a quick overview of each employee’s role in the organization.
Real Estate Listings: For a real estate company, Gallery View could display property details (address, price, number of bedrooms/bathrooms, photo) in a single block, providing a quick overview of each property.
Event Calendar: For an event management company, Gallery View could display event details (name, date, location, image) in a single block, making it easier to see all relevant information about each event at a glance.
Art Portfolio: For an artist or designer, Gallery View could display each piece of work (title, medium, dimensions, image) in a single block, providing a visually appealing way to showcase their portfolio.
Project Management: For project management, Gallery View could display each project’s details (name, status, due date, team members) in a single block, providing a quick overview of each project.
Navigation : With the Gallery View, navigating between entities becomes more intuitive. Users can easily click on the horizontally listed entity blocks (in a responsive way), streamlining the navigation process.
In conclusion, Gallery View could offer a visually appealing, space-efficient, information-dense, flexible, and simple way to display data in Fibery, making it a valuable addition to the platform’s existing views.
I like @Yuri_BC’s idea of a Gallery View (no more votes left tho, sorry :crying_cat_face🙂. I would think this would be like a tiled gallery used on many web pages.
Personally, I would also want an option to have a Grid View (yes yes, currently the nice experimental new table is called that), that allows the exact opposite of this Gallery view: Allow me to manually place tiles.
To me both these views are two sides of the same coin and potentially could just be extensions of the Board View with it’s ability to customise the tiles:
If not setting Columns/Rows as a property I could have an option to pick which of the two should be fixed, and which should be automatic
Picking the size of cards could work as it does
Choosing a sorting function would then generate @Yuri_BC’s Gallery, not choosing a sorting function should allow me to drag and place my cards
A number of times (e.g. sprint planning) we’re currently stuck between a number of views that don’t work well:
The whiteboard that is improving, but still has issues
A kanban board that becomes very quickly sparse and also does not allow me to group more than one layer
A table view, which is hard to tame.
I think the new table (currently Grid View) may be able to help some, but many times I’m actually just looking to do something like a card-sort with digital post-its and if I could do that on Fibery, that’d be
This is a very interesting manually placed ‘Tiles view’ feature you suggest, as a more configurable Gallery view. Have you seen any other app that has implemented that already?
I think what will make your suggestion possible, is a ‘queue’ feature which allows entities to have a particular ‘weight’ field which automatically updates when manually drag-dropping it to another location. This is a bit similar to the Calendar view, where the date field is automatically updated when drag-dropping an event entity to another day block. The queue feature I have requested in other topics as I see it very useful for a number of use cases.
With regard to the Gallery View that automatically lists entities as blocks in a predefined number of columns, this needs to be responsive in the sense that when viewing the gallery on a small screen or mobile, it converts automatically to less amount of columns. This is something that sets it apart from the kanban board view, which currently shows a horizontal scrollbar on smaller screens, in order to maintain the drag-drop functionality between columns.
I have actually tried as a workaround to create a Gallery view using the List view, and adapting the CSS to make the rows have a maximum width. I have not figured out yet how to make them show up side by side as inline blocks.
I’ve not really seen this anywhere as such. There are similar (but different) variants ranging from my phone’s app screen layout, dashboards that allow for a chess-board like configuration, Trello (and other kanban boards) or digital paper like Miro or Whimsical. The current Whiteboard is nice because it allows me to place different entities alongside each other. Sadly, importing entities one-by one is cumbersome and error-prone (compared to Miro’s JIRA-import).
Your “queue” description actually triggered the idea, that I could implement this in the current Board View (tho rather clunkily) by giving my cards a Row and Column number and use that for sorting… in that case dragging and dropping cards would set the relevant fields…
For your Gallery View, I agree on the responsiveness. Though I think that should ideally work automagically with the Card Size and the definition on which direction the Gallery is to grow. With no Columns specified, the whole shebang should flow quite naturally.
@mdubakov The gallery view requested in this topic is not merely about displaying images in cards, but to have the cards listed horizontally without multiple board columns. With only one column in a board view, the cards are stacked vertically, not horizontally.
A gallery view is a list of cards listed horizontally, which automatically wraps the next row of cards under it when exceeding the page width, in a responsive manner even when the window is resized. With CSS this can be accomplished with one column, and applying float: left to the card (and a width and height to the card to display them all as a grid).
I mostly agree with this. My only request of a “Gallery View” is to have the ability to drag and drop cards to reshuffle them if I decide to do so and have the view remember where I left the cards when I access a view later.
I currently have several board views driven by a single select column in the database called “Order” with values from 1-6. I then set the Board View with Columns setting to “Order” and together with card cover images setting described above I get a “Gallery View.” The odd part is that when I drag and drop cards to a different position, the view remembers the card positions but doesn’t change values of values for “Order” in each DB entry despite the “Order” values that drove the original layout are now invalid.
Bottom line: A “Gallery View” can be created using the “Board View” using column selection of a single select column in the DB and card cover images, but it requires storing presentation data in the DB which may or may not be ignored but still must exist in order to function.
Okay I have on my face. I went to build screenshots and realized that the “Order” column data is actually updating correctly. That said it still feels odd and frustrating to have to maintain data to run a specific view that doesn’t actually have anything to do with the record(s) themselves. It feels like those two pieces should remain separate.
I believe Fibery does maintain some internal custom/manual sort order data. May only be used in Table or other certain views. But it should be usable in a “Gallery” view, I agree.
The gallery view can be used to replace the pinned fields, since that allows you to add more info to the fields but still have them horizontally listed in a responsive layout.
Fibery could easily create a beta version of the Gallery View by simply “deleting” the columns from the Board View.
Maintain exactly the same functions and card styles as Board View. Just remove the column variable, allowing the items to be queued (they can continue to have sizes Small, Medium and Large, as already exists in Board View).
It wouldn’t be the best Gallery possible, but I imagine it would be quick and easy to implement, and a beta version that could meet at least 60% of use cases.
on my face. I went to build screenshots and realized that the “Order” column data is actually updating correctly. That said it still feels odd and frustrating to have to maintain data to run a specific view that doesn’t actually have anything to do with the record(s) themselves. It feels like those two pieces should remain separate.