Changes for page RealtimeLivetable

Last modified by Vincent Massol on 2024/02/26 17:54

<
From version < 71.5 >
edited by Clément Desableau
on 2020/05/25 11:04
To version < 72.1 >
edited by Clément Desableau
on 2020/05/25 12:05
>
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -446,10 +446,33 @@
446 446  ** handle all the logical operations: filtering, sorting, pagination, URL hash, ...
447 447  ** intermediate between the macro and the layout script
448 448  ** when it received a change notification from the layout script, it apply the changes and fetch the new data from the server accordingly, then pass the new data to the display layout
449 -** works like an API, can communicate with other XWiki widgets, and easily customizable
449 +** works like an API, can communicate with other XWiki widgets, is easily extendable
450 450  
451 451  As the user may want to switch between the Livetable available layouts, the logic script could dynamically import the layout scripts it needs. The available layouts should be specified in the macros.
452 452  
453 +== Editing mode vs Designing mode ==
454 +
455 +There are two main actions to user could perform on the Livetable: modifying the data, or modifying the structure of the data. Those are two different things, first each one needs different rights, but more importantly they do not serve the same purpose.
456 +
457 +When you are inserting new data or modifying existing one, you are relying on a the data structure you don't want to change. On the other hand, when you are modifing the structure of the data, you don't care about the data it actually contain. Moreover, as it is going to bring important changes for everyone, we need to differenciate it from the default editing mode.
458 +
459 +A simple solution for that is to add a button above the Livetable that let the user go to "designing mode" if it has the rights. Then the user validate his changes to go back to edit mode.
460 +
461 +Actions specific to edit mode:
462 +
463 +* adding new rows
464 +* modifying existing rows
465 +* batch operations
466 +* local layout changes (columns order / visibility)
467 +* local sorting and filtering
468 +
469 +Actions specific to design mode:
470 +
471 +* adding / removing columns
472 +* changing columns displayers
473 +* global layout change (columns order / visibility)
474 +* global sorting and filtering
475 +
453 453  == The table layout technologies ==
454 454  
455 455  For each layout, we might need to use a library to help us displaying the data.
... ... @@ -506,7 +506,7 @@
506 506  
507 507  We can also use some utility libraries to help us during the development, like libraries for drag-and-drop, custom selects, or menus.
508 508  
509 -= Implementing existing features =
532 +== Implementing existing features ==
510 510  
511 511  The features of the first version should still be present in the new one.
512 512  
... ... @@ -528,7 +528,7 @@
528 528  
529 529  As several display layout would be available (table, cards, ...), we also need to consider if we want these features to be implemented in the same way for each layout. If it's the case, that means less development time, and more coherence between the layouts. However, certain layout could have a better suited implementation that would be more intuitive for the user.
530 530  
531 -== Sorting ==
554 +=== Sorting ===
532 532  
533 533  For the moment, we can only sort the table according to one column.
534 534  
... ... @@ -552,7 +552,7 @@
552 552  
553 553  In our final solution, we will need to get the sort-system as accessible and readable as possible.
554 554  
555 -=== Solution 1 ===
578 +==== Solution 1 ====
556 556  
557 557  This is our custom solution for multi-sorting column.
558 558  
... ... @@ -590,7 +590,7 @@
590 590  * right-clicking might not be intuitive for the user, and he might never know it's possible
591 591  * the colors of the sort levels, even though they are common, might not looks good in some themes, or might not be wanted by the user (solution: every level stays black)
592 592  
593 -=== Solution 2 ===
616 +==== Solution 2 ====
594 594  
595 595  This second solution is a variation of the first one. Instead of displaying the direction and the level together, we can display both information separately:
596 596  
... ... @@ -616,7 +616,7 @@
616 616  
617 617  (Note: with this solution we could still keep the behavior of the right-click as an alternative way to open the sort level sub-menu.)
618 618  
619 -=== Solution 3 ===
642 +==== Solution 3 ====
620 620  
621 621  We create a sub-menu above the table where we can specify the order of the columns in the multi-sort (like in Notion). This solution would work on any layout.
622 622  
... ... @@ -632,7 +632,7 @@
632 632  
633 633  We could still display the triangle icon in the table header to indicate that the column is currently sorting the table. Clicking on it would open the sort menu.
634 634  
635 -== Filtering ==
658 +=== Filtering ===
636 636  
637 637  For the moment, the filter only try to see if the rows match the specified text. It is not possible to check for the inequality of a number, nor for the range of a date for example.
638 638  
... ... @@ -640,7 +640,7 @@
640 640  
641 641  Also, for now it's not possible to combine filters in another way than a "AND" logical operator between the columns. A solution could be implemented to be able to combine different columns with a "OR" operator (e.g. name="jean" OR age≥25), or to be able to combine different filters in the same column (e.g. age≤20 OR age≥50) The combination of "AND" and "OR" operators should be kept intuitive though.
642 642  
643 -=== Solution 1 ===
666 +==== Solution 1 ====
644 644  
645 645  For now, we can only have 1 filter for each column, and we can only match equality.
646 646  
... ... @@ -686,7 +686,7 @@
686 686  * the filters can take much more width than the column content
687 687  * not lightweight at all
688 688  
689 -=== Solution 2 ===
712 +==== Solution 2 ====
690 690  
691 691  We create a sub-menu above the table where we can specify the filters we want to apply to each columns (as Notion does). This solution would work on any layout.
692 692  
... ... @@ -702,17 +702,17 @@
702 702  * filters not accessible directly: we are adding an extra step to access the filters
703 703  * filters not viewable by default: we can't know with a glance how the columns are filtered
704 704  
705 -=== Filtering by Tags ===
728 +==== Filtering by Tags ====
706 706  
707 707  There is currently a way to filter by tags, from the outside of the Livetable. As the script layer should behave like an API, it should be easy to communicate with it.
708 708  
709 -=== Global search ===
732 +==== Global search ====
710 710  
711 711  We can also add a global search input above the Livetable, that is going to search if the input text can be found anywhere in the entries of the data source.
712 712  
713 713  Any entries containing the query text in one of their properties will be returned. This filtering system should combine with the normal one, with an "AND" operator.
714 714  
715 -== Filtering operators ==
738 +==== Filtering operators ====
716 716  
717 717  Filtering a string is not the same that filtering a number, a date, or a list of values. Thus, we should not provide the same actions for all type of filters, but adapt according to the filter type.
718 718  
... ... @@ -772,7 +772,7 @@
772 772  * the filters are case aware: lowercase matches both lowercase and uppercase, while uppercase only matches uppercase
773 773  * the operators written in words can take up too much space depending the chosen implementation. This would be the case in the Solution 1.
774 774  
775 -== Pagination ==
798 +=== Pagination ===
776 776  
777 777  The pagination is already functional and nothing but its design might be changed.
778 778  
... ... @@ -780,15 +780,15 @@
780 780  
781 781  Similarly, we could display a "load more" button at the bottom of the Livetable so that the user manually fetches new entries.
782 782  
783 -== Data export ==
806 +=== Data export ===
784 784  
785 785  In the new design, we need to keep the feature allowing the user to export the content of the Livetable to csv format.
786 786  
787 787  This is not the priority, be we could add other formats, like excel or json.
788 788  
789 -= Implementing new features =
812 +== Implementing new features ==
790 790  
791 -== Modifying the cell value ==
814 +=== Modifying the cell value ===
792 792  
793 793  The cell in the Livetable can be modified simply by double-clicking on it. The cell text will be replaced by a text field, a select, or whatever input according to the type of the column.
794 794  
... ... @@ -796,7 +796,7 @@
796 796  
797 797  If the user presses "Tab" while editing a cell, the changes are kept and the next cell is focused in editable mode.
798 798  
799 -== Adding a new row ==
822 +=== Adding a new row ===
800 800  
801 801  The user should be able to easily insert a new row in the table.
802 802  
... ... @@ -806,7 +806,7 @@
806 806  
807 807  When the user click on it, the action that follows could be either of:
808 808  
809 -=== Solution 1 ===
832 +==== Solution 1 ====
810 810  
811 811  We simply redirect the user toward the add-new-entry page.
812 812  
... ... @@ -819,7 +819,7 @@
819 819  * we leave the Livetable page to create a new entry
820 820  * there are now two buttons with the same effect on the page
821 821  
822 -=== Solution 2 ===
845 +==== Solution 2 ====
823 823  
824 824  We display a wizard in a modal allowing the user to fill all the properties of the new entry. This solution is implemented in Notion.
825 825  
... ... @@ -832,23 +832,23 @@
832 832  * way more complicated than solution 1
833 833  * we have to create another wizard doing the same thing than the one in the add-new-entry page
834 834  
835 -=== Handling rows in the wrong page ===
858 +==== Handling rows in the wrong page ====
836 836  
837 837  When inserting a new row or modifying an existing one, there is a possibility that the row has to be displayed in a different page that the current one, because of the Livetable configuration (sorting, filtering, ...). When this happens, we cannot just move the row to the new page it belongs, as it would be confusing for the user (the row would just disappear with no indication).
838 838  
839 839  To avoid that, we can hold the modified row in the current page with a different state, shown by a different display style. In front of the row, we can display an icon representing an "i" in a circle (for "information"), that explains on hover the current state of the row, and that it will be back to normal on the next user action (change sort, filters, modify another row...).
840 840  
841 -== Selecting rows and Batch operations ==
864 +=== Selecting rows and Batch operations ===
842 842  
843 843  This feature has been asked by many users: it would be nice to be able to select rows in the table, and to execute an action for all of them.
844 844  
845 -The action could be: deleting the entry, changing the rights, ...
868 +The action could be: deleting the entry, changing the rights, modifying value...
846 846  
847 847  This would not be complicated to set up: we only need to add column on the left of the table where we display a checkbox for each row. In the column header, there is a checkbox that allow to quickly check / uncheck all the present rows in the table.
848 848  
849 849  Once we select at least one row, a menu appears (or become enabled) above the table, and let the user perform the desired action.
850 850  
851 -== Columns operations ==
874 +=== Columns operations ===
852 852  
853 853  There are several operations on the columns the user might consider, like reordering or hiding some of them. These action would only affect the user display and would have no effect on the server or the other Livetables.
854 854  
... ... @@ -856,19 +856,19 @@
856 856  
857 857  Moreover, we can think of a system that allow the user to create a new page based on the current Livetable configuration.
858 858  
859 -=== Showing / Hiding columns ===
882 +==== Showing / Hiding columns ====
860 860  
861 861  We can create a sub-menu above the table, showing all the columns the Livetable can display, each column associated with a checkbox allowing the user to toggle its visibility.
862 862  
863 863  If some columns are hidden in the Livetable, we should display an icon in the sub-menu title to indicate that not all the columns are shown. The icon could be an exclamation mark or an eye (or both).
864 864  
865 -=== Reordering ===
888 +==== Reordering ====
866 866  
867 867  The easiest way for the user to reorder columns is by drag and dropping them at the place they want.
868 868  
869 869  We could also allow the columns listed in the sub-menu above the table to be order-able.
870 870  
871 -=== Resizing the columns ===
894 +==== Resizing the columns ====
872 872  
873 873  This is not the priority but if anyone wants this feature, it could be implemented to the Livetable.
874 874  

Get Connected