Changes for page RealtimeLivetable
Last modified by Vincent Massol on 2024/02/26 17:54
Change comment:
There is no comment for this version
Summary
-
Page properties (1 modified, 0 added, 0 removed)
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, andeasilycustomizable449 +** 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